Contents
- Introduction
- Dublin Core Application Profiles
- LOM Application Profiles
- Notes
- References
2. Dublin Core Application Profiles
The IEMSR should support the following functions:
- creation and maintainance of descriptions of metadata vocabularies and DC Application Profiles and their component entities i,e. creation of Schema Documents.
- creation and maintainance of descriptions of these Schema Documents, as distributed data sources for the IEMSR. Schema Documents may be
- schema documents created by IEMSR tools
- RDF/XML documents already published on the Web
- aggregation/indexing of the data from these data sources and the provision of query services on that database through
- an HTML interface for human users
- appropriate API(s) for software agents
- control/administration of the aggregation/indexing process
For the purposes of this document, the tool which provides the first function is labelled the DCAP editor, and that which provides the second is labelled the metadata editor. In practice these may be distinct or they may be provided by a single software tool.
2.1 DCAP editor
The DCAP editor should enable a human publsher of a DCAP:
- to create a description of a metadata vocabulary (including its constituent terms - properties, classes and instances of those classes - and the agency reponsible for its management), and to save that description in the form of a schema document
- to edit an existing schema document containing a description of a metadata vocabulary (including its constituent terms - properties, classes and instances of those classes - and the agency reponsible for its management), and to re-save that description in the form of an updated schema document
- to create a description of a DC application profile (including its constituent property usages and the agency reponsible for its management), and to save that description in the form of a schema document. As part of the DCAP creation process, the tool should allow the user to interact with the registry server
- to select an existing DCAP as the starting point for a new DC application profile. (The tool should handle any requirement to provide new identifiers for property usages etc)
- to discover and select relevant metadata vocabularies from which all the properties can be used in this DCAP
- to discover and select relevant properties from existing metadata vocabularies that can be used in this DCAP
- to discover and select relevant classes from existing metadata vocabularies that can serve as encoding schemes for properties used in this DCAP
- to edit an existing schema document containing a description of a DCAP (including its constituent term usages and the agency reponsible for its management), and to re-save that description in the form of an updated schema document
2.2 Metadata editor
The metadata editor should enable a human owner of a schema document:
- to create a description of a schema document to be indexed by the registry server. The schema document may be either
- a schema document created by the DCAP editor
- an RDF/XML document created externallly
- to edit an existing description of a schema document and request that the schema document is re-indexed by the registry server
- to edit an existing description of a schema document and request that the data from the schema document is removed from the registry server database (This may mean flagging as deleted rather than physically removing?)
Note: In the MEG-CORES registry it was possible to request the reading/indexing of schema documents from any URL, so, for example, it was possible to read the schema documents published on the Web by DCMI. However, the registry application relied on the availability of statements using an application-specific vocabulary, and in the MEG-CORES registry these had to be provided as a separate data source. This was very time-consuming and proved a barrier to indexing existing data describing metadata vocabularies. To address this, the IEMSR implementation should
- minimise the application-specific RDF vocabulary used to describe metadata vocabularies;
- provide tools that allow the agent submitting the externally created schema document to create any additional data required or to make inferences from existing data
2.3 Registry server
2.3.1 Human-readable user interface
The human-readable interface should allow a researcher to browse lists of all entities described (except instances or property usages):
- Agencies, sorted by name. Display in list:
- Agency name
- Agency home page
- Metadata vocabularies, sorted by title of metadata vocabulary, version of metadata vocabulary. Display in list:
- Properties, sorted by label of property, title of metadata vocabulary, version of metadata vocabulary. Display in list:
- Label of property
- Title of metadata vocabulary
- Version of metadata vocabulary
- Properties, sorted by QName (derive QName from preferred prefix/namespace name for metadata vocabulary). Display in list:
- QName of property
- Title of metadata vocabulary
- Version of metadata vocabulary
- Classes, sorted by label of class, title of metadata vocabulary, version of metadata vocabulary. Display in list:
- Label of class
- Title of metadata vocabulary
- Version of metadata vocabulary
- Classes, sorted by QName (derive QName from preferred prefix/namespace name for metadata vocabulary), title of metadata vocabulary, version of metadata vocabulary. Display in list:
- QName of class
- Title of metadata vocabulary
- Version of metadata vocabulary
- DC application profiles, sorted by title of DCAP, version of DCAP. Display in list:
- Schema Documents, sorted by title of schema document, version of schema document. Display in list:
The researcher should also be able to browse lists of entities grouped as follows:
- Metadata vocabularies grouped by status
- DC Application Profiles grouped by status
- Properties grouped by status
From an entry in a browse list, a researcher can navigate to full display of metadata for that entity, and from any of those full displays, navigate to a full display for a related entity:
- Agency
- Metadata vocabulary
- Property
- Class
- DC application profile
- Property Usage
- Schema Document
The researcher should be able to search the aggregated data:
Simple keyword searches on literal values:
- search for agencies, by keyword in name, description
- search for metadata vocabularies by keyword in title, description
- search for properties by keyword in label, definition, usage note
- search for classes by keyword in label, definition, usage note
- search for DC application profiles by keyword in title, description
- search for binding schemas by keyword in title, description
- search for schema documents by keyword in title, description
Other searches?
2.3.2 API
The registry must provide one or more interfaces that allow applications to:
- query the registry database
- add statements to the registry database
- remove statements from the registry database
- update statements in the registry database
It would be useful to support a generic RDF Query/Update API as well as a schema-specific API.
Both HTTP and SOAP bindings?
Authentication/authorisation?
2.3.3 Administration interface
[to be completed]
3. LOM Application Profiles
The IEMSR should support the following functions:
- creation and maintainance of descriptions of LOM Application Profiles and their component entities i,e. creation of Schema Documents.
- creation and maintainance of descriptions of these Schema Documents, as distributed data sources for the IEMSR.
- aggregation/indexing of the data from these data sources and the provision of query services on that database through
- an HTML interface for human users
- appropriate API(s) for software agents
- control/administration of the aggregation/indexing process
For the purposes of this document, the tool which provides the first function is labelled the LOMAP editor, and that which provides the second is labelled the metadata editor. In practice these may be distinct or they may be provided by a single software tool.
3.1 LOMAP editor
The LOMAP editor should enable a human publisher of a LOMAP:
- to create a description of a LOM application profile (including its constituent LOM data element usages and the agency reponsible for its management), and to save that description in the form of a schema document. As part of the LOMAP creation process, the tool should allow the user to interact with the registry server
- to select an existing LOMAP as the starting point for a new LOMAP. (The tool should handle any requirement to provide new identifiers for LOM data element usages etc)
- to discover and select relevant existing non-LOM vocabularies and taxonomies that can be used to provide values for LOM data elements in this LOMAP
- to create new non-LOM vocabularies and taxonomies that can be used to provide values for LOM data elements
- to edit an existing schema document containing a description of a LOMAP (including its constituent LOM data element usages and the agency reponsible for its management), and to re-save that description in the form of an updated schema document
- to confirm that the LOMAP being created/edited conforms to the constraints of an existing LOMAP (e.g. UK LOM Core)
Note: We need to consider what level of interoperability with VDEX we are proposing. Should IEMSR tools support the capacity to import vocabularies from VDEX documents? And expose vocabularies as VDEX? If other LOM tools are working with VDEX, and LOM implementers are creating VDEX documents, then it seems problematic if IEMSR doesn't use/provide them e.g. we shouldn't ask LOMAP creators to re-enter their vocabulary for the IEMSR if a VDEX document exists.
3.2 Metadata editor
The metadata editor should enable a human owner of a schema document:
- to create a description of a schema document to be indexed by the registry server.
- to edit an existing description of a schema document and request that the schema document is re-indexed by the registry server
- to edit an existing description of a schema document and request that the data from the schema document is removed from the registry server database (This may mean flagging as deleted rather than physically removing?)
3.3 Registry server
3.3.1 Human-readable user interface
3.3.2 API
The registry must provide one or more interfaces that allow applications to:
- query the registry database
- add statements to the registry database
- remove statements from the registry database
- update statements in the registry database
It would be useful to support a generic RDF Query/Update API as well as a schema-specific API.
Both HTTP and SOAP bindings?
Authentication/authorisation?
3.3.3 Administration interface
[to be completed]