Difference between revisions of "Imeji Standard Metadata Profiles"
Jump to navigation
Jump to search
Kleinfercher (talk | contribs) m (→Enhancements) |
Kleinfercher (talk | contribs) m |
||
| Line 14: | Line 14: | ||
== Backend Specification == | == Backend Specification == | ||
* An administrator can upload standard profiles from the admin interface | * An administrator can upload standard profiles from the admin interface | ||
* Question: Can we manage those profiles in CoNE? Therefore | * Question: Can we manage those profiles in CoNE? Therefore they could be reused by other instances | ||
* xsd import is already realized for the import tool. To check what we can reuse. | * xsd import is already realized for the import tool. To check what we can reuse. | ||
* The profile will be stored as a template for a collection. This means there is always a 1:1 connection between profiles and collections | * The profile will be stored as a template for a collection. This means there is always a 1:1 connection between profiles and collections | ||
| Line 37: | Line 37: | ||
As we now provide standard metadata we can also provide standardized exports (via various transformations which are already available). | As we now provide standard metadata we can also provide standardized exports (via various transformations which are already available). | ||
Please add the export formats you want to have supported (if possible plus xslt from format of standard list above to export format): | Please add the export formats you want to have supported (if possible plus xslt from format of standard list above to export format): | ||
** the metadata | ** the metadata standards (as defined before) should be all supported by the export. Since the mechanisms should be generic (up to the XSLT file which might be defined for each format), this should not be a major effort. --[[User:Bastien|Bastien]] 17:01, 30 April 2013 (CEST) | ||
* [http://dfg-viewer.de/profil-der-metadaten METS/MODS for DFG-Viewer (as required by the DFG)] | * [http://dfg-viewer.de/profil-der-metadaten METS/MODS for DFG-Viewer (as required by the DFG)] | ||
Revision as of 08:42, 13 May 2013
Use Case[edit]
A metadata profile editor does not want to create an own metadata profile but he wants to integrate a standardised metadata set.
Possible walk through:
- The user creates a collection
- The user wants to create a metadata profile, therefore he can:
- Create an own metadata profile
- Use an existing profile as template
- Use a standard profile
- The user decides to use a standard profile: The metadata profile editor is populated with the standard metadata statements
Backend Specification[edit]
- An administrator can upload standard profiles from the admin interface
- Question: Can we manage those profiles in CoNE? Therefore they could be reused by other instances
- xsd import is already realized for the import tool. To check what we can reuse.
- The profile will be stored as a template for a collection. This means there is always a 1:1 connection between profiles and collections
- In the background a standard mapper element will be created for each profile
- The user can edit a standard profile
Frontend Specification[edit]
- Standard profiles are provided for selection (create metadata profile page) in a separate drop down or in an options drop down with other templates
- When the user edits a standard profile it should be clear for him that he leaves the standard (plus standard export)
- In the view page of metadata (image page), it should be possible to view the namespaces for standard profile (perhaps in a new tab)
Supported Metadata Standards[edit]
Which metadata standards should we support, please enhance the list. If possible link to the RDF representation of a standard:
Metadata Export[edit]
As we now provide standard metadata we can also provide standardized exports (via various transformations which are already available). Please add the export formats you want to have supported (if possible plus xslt from format of standard list above to export format):
- the metadata standards (as defined before) should be all supported by the export. Since the mechanisms should be generic (up to the XSLT file which might be defined for each format), this should not be a major effort. --Bastien 17:01, 30 April 2013 (CEST)