Talk:Imeji Standard Metadata Profiles
Jump to navigation
Jump to search
Profile as is:
- Lots of buttons (+/-)
- Space usage not optimal
Profile edit idea:
Previous discussion[edit]
Open questions:
- May the user be allowed to change the standard metadata profile (delete statements, change cardinality etc.)?
- Would be a problem if we support standardized exports (especially with transformations)
- Idea: The standard metadata profiles stays untouched but the user may create derivatives from them (children that inherit all statements from the standard metadata profiles). These derivatives are copies that are saved under another name but are fully editable. That way the standard metadata profiles and their standardized exports are always available. To support export for the derivatives the mappings should work in a similar fashion, that is the user may create derivatives of the standard mappings in order to retain the used standard statements while also be able to add or delete statements in an easy way. Standard mappings shall be documented to let the editor identify each statement at a glance. --Jroeder 13:19, 22 April 2013 (CEST)
- I agree with Jörg. We have 2 object:s the profile and the mapping. When using a template, the user gets both predefined, but can modify them. The original standard template is not affected by the changes. But we could think a way to create new templates and/or to share profiles and mappings between collections.--Bastien 16:56, 30 April 2013 (CEST)
- GUI issue: How can we best display such profiles (it is possible that we have a deep hierarchy, long profiles etc.)
- Probably a start to optimize profile layout? As it gets very overloaded when one has many metadata statements. Talk:Imeji_Standard_Metadata_Profiles
- Idea: When editing a profile the statements are displayed as a text list, the statement can be unfolded if I want to edit this specific one. (Therefore we do not have as many buttons, check boxes etc. which can be distracting).
- See also Git:Improve metadata profile editing, Git:Metadata fields parent-child hierarchy,
