Home | Background | Dissemination | Contacts |
Phase 1 | WP1: Project management | WP2: Model/Use | WP3: Tools | WP4: m2m | WP5: Validation | WP6: Policy | WP7: Evaluation |
This document builds on the high-level description of the functions of the IEMSR and the usage scenarios to provide some more detailed functional requirements for the IEMSR.
The entity types referred to here are described in more detail in the two documents: Model for Dublin Core Application Profile and Model for LOM Application Profile.
The IEMSR should support the following high-level functions:
Describe Metadata Vocabulary: the creation and/or maintainance of a description of a metadata vocabulary, its component properties and classes, and related resources. Results in the creation of a new or updated Schema Document.
Describe DC Application Profile: the creation and maintainance of a description of a DC Application Profile, its component entities and related resources. Results in the creation of a new or updated Schema Document.
Describe Set of Instances (Controlled Vocabulary terms): the creation and maintainance of a description of a set on Instances. Results in the creation of a new or updated Schema Document.
Describe Schema Document: the creation and/or maintainance of descriptions of these Schema Documents as distributed data sources for the IEMSR. Schema Documents may be:
documents created by the one of the first three functions above
RDF/XML documents already published on the Web
Submit/Withdraw Schema Document: request that a Schema Document is read and the content indexed and added to the registry database; or request that the content of a previously indexeddocument is removed from the registry database
Browse Registry Data: the navigation of the database through an HTML interface for human users
Query Registry Data: the provision of query services on that database through an HTML interface for human users
Administer Registry Database:
API
Although these are listed as distinct functions, multiple functions may be provided within a single software tool. Each function is described in more detail in the following sections.
The human administrator of a metadata vocabulary (or a third party) needs to be able to create a new description of a metadata vocabulary:
Create New Schema Document
Create Agency Description: create a description of the Agency responsible for the management of the metadata vocabulary, including descriptions of any related Text Document (home page for the Agency).
Create Metadata Vocabulary Description: create a description of the Metadata Vocabulary, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more classes in the metadata vocabulary:
Create Class Description: create a description of the Class, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more subclass relations required:
For zero or more properties in the metadata vocabulary
Create Property Description: create a description of the Property, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more subproperty/refinement relations required:
Save Schema Document: as local file.
The human administrator of a metadata vocabulary (or a third party) needs to be able to edit an existing description of a metadata vocabulary:
Open Schema Document: either from local file or from URL.
Edit Agency Description: edit the description of the Agency responsible for the management of the metadata vocabulary, including descriptions of any related Text Document (home page for the Agency).
Edit Metadata Vocabulary Description: edit the description of the Metadata Vocabulary, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more selected classes in the metadata vocabulary:
Edit Class Description: edit the description of the Class, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more subclass relations to be removed:
Remove Subclass Relationship Remove subclass relation between this class and a second class in the same or a different metadata vocabulary
For zero or more subclass relations to be added:
Add Subclass Relationship: (see above)
For zero or more selected properties in the metadata vocabulary
Edit Property Description: edit the description of the Property, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more subproperty relations to be removed:
Remove Subproperty Relationship: Remove subproperty relation between this property and a second property in the same or a different metadata vocabulary
For zero or more subproperty relations to be added:
Add Subproperty Relationship: (see above).
For zero or more selected classes in the metadata vocabulary:
Delete Class Description: delete the description of the Class, including descriptions of any related Text Document (human-readable specification or guidelines), and remove any subclass relationships in which this class is subject.
[Not sure whether this should delete node or flag node as deleted?]
For zero or more selected properties in the metadata vocabulary:
Delete Property Description: delete the description of the Property, including descriptions of any related Text Document (human-readable specification or guidelines), and remove any subproperty relationships in which this property is subject.
[Not sure whether this should delete node or flag node as deleted?]
For zero or more additional classes for this metadata vocabulary
Create Class Description (as above)
For zero or more additional properties for this metadata vocabulary
Create Property Description (as above)
Save Schema Document: as local file.
The human administrator of a DCAP (or a third party) needs to be able to create a new description of a DCAP:
Create New Schema Document
Create Agency Description: create a description of the Agency responsible for the management of the DC application profile, including descriptions of any related Text Document (home page for the Agency).
Create DCAP Description: create a description of the DCAP, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more binding schemas associated with the DCAP:
Create Binding Schema Description: create a description of Binding Schema, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more resource types described by instances of the DCAP:
Select Subject Resource Type: select an existing class from a metadata vocabulary.
Select Property for Use: select an existing property from a metadata vocabulary.
Create Property Usage Description: create a description of the Property Usage, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more encoding schemes in this property usage:
Add Encoding Scheme: add encoding scheme relation between this property usage and a selected existing class from a metadata vocabulary.
For zero or more resource types described by instances of the DCAP:
Select Subject Resource Type: select an existing class from a metadata vocabulary.
For zero or more metadata vocabularies used in the description of instances of this class:
Select Metadata Vocabulary for Use: select an existing metadata vocabulary and by doing so select all the properties in that metadata vocabulary.
For zero or more properties used in the description of instances of this class:
Create Property Usage Description: (as above)
Save Schema Document: as local file.
The human administrator of a DCAP (or a third party) needs to be able to edit an existing description of a DCAP:
Open Schema Document: either from local file or from URL.
Edit Agency Description: edit the description of the Agency responsible for the management of the DCAP, including descriptions of any related Text Document (home page for the Agency).
Edit DCAP Description: edit the description of the DCAP, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more selected binding schemas associated with the DCAP:
Edit Binding Schema Description: edit the description of Binding Schema, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more selected binding schemas associated with the DCAP:
Delete Binding Schema Description: delete the description of Binding Schema, including descriptions of any related Text Document (human-readable specification or guidelines).
[Not sure whether this should delete node or flag node as deleted?]
For zero or more additional binding schemas associated with the DCAP:
Create Binding Schema Description: (as above).
For zero or more selected property usages:
Edit Property Usage Description: edit the description of the PropertyUsage, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more encoding scheme relations to be removed:
Remove Encoding Scheme: Remove encoding scheme relationships between this property usage and a class
For zero or more encoding scheme relations to be added:
Add Encoding Scheme: (see above).
For zero or more selected property usages:
Delete Property Usage Description: delete the description of the PropertyUsage, including descriptions of any related Text Document (human-readable specification or guidelines), and remove any encoding scheme relationships in which this property usage is subject.
For zero or more selected subject resource type described by instances of the DCAP:
For zero or more additional properties used in the description of instances of this class:
Select Property for Use: (as above).
Create Property Usage Description (as above).
For zero or more additional subject resource types described by instances of the DCAP:
Select Subject Resource Type: select an existing class from a metadata vocabulary.
For zero or more properties used in the description of instances of this class:
Select Property for Use: (as above).
Create Property Usage Description (as above).
Save Schema Document: as local file.
[Not sure whether this should delete node or flag node as deleted?]
The human administrator of a DCAP (or a third party) needs to be able to create a new description of a DCAP, by using an existing DCAP as the starting point:
Note: the cloning of a DCAP does not imply any relationship between the newly created DCAP and the selecteed/cloned DCAP; this operation is simply a convenience for the DCAP creator. It does not imply that instances conforming to the newly created DCAP will necessarily conform to the selected/cloned DCAP. For example, where a property usage in the selected/cloned DCAP specified that usage of a property was mandatory, a propery usage in the newly created DCAP might specify that it is optional.
Create New Schema Document
Select DCAP: select an existing DCAP to serve as the the starting point for this new description of a DCAP
If agency which manages new DCAP is different from that of cloned DCAP
Delete Agency Description
Create Agency Description (as above)
Edit DCAP Description: (as above)
For zero or more selected binding schemas associated with the DCAP:
Edit Binding Schema Description: (as above).
For zero or more selected binding schemas associated with the DCAP:
Delete Binding Schema Description: (as above).
For zero or more additional binding schemas associated with the DCAP:
Create Binding Schema Description: (as above).
For zero or more selected property usages:
Edit Property Usage Description: (as above)
For zero or more selected property usages:
Delete Property Usage Description: (as above)
For zero or more selected subject resource type described by instances of the DCAP:
For zero or more additional properties used in the description of instances of this class:
Select Property for Use: (as above).
Create Property Usage Description (as above).
For zero or more additional subject resource types described by instances of the DCAP:
Select Subject Resource Type: select an existing class from a metadata vocabulary.
For zero or more properties used in the description of instances of this class:
Select Property for Use: (as above).
Create Property Usage Description (as above).
Save Schema Document: as local file.
The human administrator of a set of instances (or a third party) needs to be able to create a new description of a set of instances:
Create New Schema Document
Select Class to Instantiate: select the existing class of which these resources are instances.
For one or more instances:
Create Description of Instance: create a description of the instance, including descriptions of any related Text Document (human-readable specification or guidelines).
Save Schema Document: as local file.
The human administrator of a set of instances (or a third party) needs to be able to edit an existing description of a set of instances:
Open Schema Document: either from local file or from URL.
For zero or more selected instances:
Edit Description of Instance: edit a description of the instance, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more additional instances:
Create Description of Instance: (as above).
For zero or more selected instances:
Delete Description of Instance.
[Not sure whether this should delete node or flag node as deleted?]
Save Schema Document: as local file.
A Schema Document may be
a document created by the one of the first three functions above
an RDF/XML document already published on the Web
N.B. The publisher of a Schema Document may be a different Agency from the administrator of the Metadata Vocabulary/DCAP/set of Instances described by that Schema Document; and where descriptions of a Metadata Vocabulary/DCAP/set of Instances are available in multiple Schema Documents (in multiple languages), each of those Schema Documents may have a different Agency as publisher.
The human publisher of a Schema Document (or a third party) needs to be able to create a new description of a Schema Document.
Create Agency Description: create a description of the Agency responsible for the management of the Schema Document, including descriptions of any related Text Document (home page for the Agency).
Create Description of Schema Document: create a description of the Schema Document.
The human publisher of a Schema Document (or a third party) needs to be able to edit a description of a Schema Document.
Edit Agency Description: edit a description of the Agency responsible for the management of the Schema Document, including descriptions of any related Text Document (home page for the Agency).
Edit Description of Schema Document: edit description of the Schema Document.
Having created or edited a Schema Document and created or edited a description of that Schema Document, the human publisher of a Schema Document (or a third party) needs to be able to signal to the registry server that it should be read and indexed.
Note: Schema Documents may be any relevant RDF/XML data source, e.g. the schema documents published on the Web by DCMI. The IEMSR must support the use of these data sources with minimum extra work on the part of the submitter. In the MEG-CORES registry, the human effort required in generating additional data for the registry was very time-consuming and proved a considerable barrier to indexing existing data describing metadata vocabularies.
Note: As part of the submission process, the IEMSR should store a copy of the submitted document, so that it is still available in the case that the copy at the location maintained by the publisher becomes inaccessible.
The human-readable interface should allow a researcher to browse lists of all entities described (except instances, property usages, text documents and binding schemas):
For each Schema Document in database, view Schema Document Summary. Sort list by [Schema Document] Language [RFC3066] Value, [Schema Document] published by [Agency] Name, [Schema Document] Title.
For each Metadata Vocabulary in database, view Metadata Vocabulary Summary. Two different sort options:
For each Metadata Vocabulary in database, view Metadata Vocabulary Summary. grouped by [Metadata Vocabulary] Status. Within grouping, allow two different sort options:
For each Property in database, view Property Summary. Two different sort options:
For each Property in database, view Property Summary. grouped by [Property] Status. Within grouping, allow two different sort options:
For each Class in database, view Class Summary. Two different sort options:
For each Class in database, view Class Summary. grouped by [Class] Status. Within grouping, allow two different sort options:
A human researcher should be able to query the aggregated data:
Using simple keyword searches on literal values:
searches by e.g. date?
filter by language?
Display full Schema Document description:
View full Agency description:
Also:
View full Metadata Vocabulary description:
Also:
A representation of a Metadata Vocabulary and its components suitable for printing. (Includes detail views of components rather than just summary views.)
View full Metadata Vocabulary description:
Also:
Display full Property description:
Also:
Display full Property description:
Also:
Display full Class description:
Also:
Display full Class description:
Also:
Display full Instance description:
Also:
Display full DCAP description:
Also:
A representation of a DCAP and its components suitable for printing. (Includes detail views of components rather than just summary views.)
View full DCAP description:
Also:
Display full Property Usage description:
Also:
Display full Property Usage description:
Also:
Display full Binding Schema description:
Also:
Display full Text Document description:
Also:
Note: An Encoding Scheme is not defined as a distinct resource type in the data model. An Encoding Scheme is a Class which is associated with a Property Usage to prescribe the value space for a property.
Display full Encoding Scheme description:
Also:
Note: A Subject Type is not defined as a distinct resource type in the data model. A Subject Type is a Class which is associated with a Property Usage to specify the type of resource described by a Property Usage.
Display full Subject Type description:
Also:
The registry must provide one or more interfaces that allow applications to:
Appropriate authentication/authorisation mechanisms must be provided.
It would be useful to support a generic RDF Query/Update API as well as a schema-specific API.
If services are provided using SOAP bindings, equivalent services should be provided using REST/HTTP bindings.
In defining the API, consideration should be given to the current best practice recommendations of the W3C Semantic Web Data Access Working Group (DAWG).
The IEMSR should support the following high-level functions.
Note: thefollowing specification is based on the premise that descriptions of LOM Data Elements, LOM Datatypes, LOM Standard Value Spaces, LOM Vocabularies, and LOM Vocabulary Values are already available (pre-loaded to the registry database): the creator of a description of a LOMAP does not need to creare these descriptions, only to refer to them. For this reason, functions such as "Describe LOM Data Element" are not included below.
Describe LOM Application Profile: the creation and maintainance of a description of a LOM Application Profile, its component entities and related resources. Results in the creation of a new or updated Schema Document.
Describe non-LOM Vocabulary: the creation and maintainance of a description of a non-LOM Vocabulary and its constituent non-LOM Vocabulary Values. Results in the creation of a new or updated Schema Document.
Describe Extended Data Element Set: the creation and maintainance of a description of an Extended Data Element Set and its constituent Extended Data Elements.
Describe Schema Document: the creation and/or maintainance of descriptions of these Schema Documents as distributed data sources for the IEMSR. A Schema Documents is created by the one of the first three functions above
Submit/Withdraw Schema Document: request that a Schema Document is read and the content indexed and added to the registry database; or request that the content of a previously indexeddocument is removed from the registry database
Browse Registry Data: the navigation of the database through an HTML interface for human users
Query Registry Datae: the provision of query services on that database through an HTML interface for human users
Administer Registry Database:
API
Although these are listed as distinct functions, multiple functions may be provided within a single software tool. Each function is described in more detail in the following sections.
The human administrator of a LOMAP (or a third party) needs to be able to create a new description of a LOMAP:
Create New Schema Document
Create Agency Description: create a description of the Agency responsible for the management of the DC application profile, including descriptions of any related Text Document (home page for the Agency).
Create LOMAP Description: create a description of the LOMAP, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more binding schemas associated with the LOMAP:
Create Binding Schema Description: create a description of Binding Schema, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more LOM Data Elements used in this LOMAP:
Select LOM Data Element for Use: select a LOM Data Element.
Create Data Element Usage Description: create a description of the Data Element Usage, including descriptions of any related Text Document (human-readable specification or guidelines).
For a usage of a simple LOM Data Element with the LOM Datatype "Vocabulary", for zero or more non-LOM Vocabularies:
Add non-LOM Vocabulary as Value Space Extension: add relation between this LOM Data Element Usage and a selected existing non-LOM Vocabulary.
For zero or more usages of the LOM Data Element "9. Classification":
Add Classification Purpose: from standard LOM Vocabulary for Classification.
Add Taxonomy: add relation between this LOM Data Element Usage and a selected existing Taxonomy.
Save Schema Document: as local file.
The human administrator of a LOMAP (or a third party) needs to be able to edit an existing description of a DCAP:
Open Schema Document: either from local file or from URL.
Edit Agency Description: edit the description of the Agency responsible for the management of the LOMAP, including descriptions of any related Text Document (home page for the Agency).
Edit LOMAP Description: edit the description of the LOMAP, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more selected binding schemas associated with the LOMAP:
Edit Binding Schema Description: edit the description of Binding Schema, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more selected binding schemas associated with the LOMAP:
Delete Binding Schema Description: delete the description of Binding Schema, including descriptions of any related Text Document (human-readable specification or guidelines).
[Not sure whether this should delete node or flag node as deleted?]
For zero or more additional binding schemas associated with the LOMAP:
Create Binding Schema Description: (as above).
For zero or more selected LOM Data Element Usages:
Edit LOM Data Element Usage Description: edit the description of the LOM Data Element Usage, including descriptions of any related Text Document (human-readable specification or guidelines).
For a usage of a simple LOM Data Element with the LOM Datatype "Vocabulary", for zero or more non-LOM Vocabularies to be removed:
Remove Non-LOM Vocabulary as Value Space Extension: Remove relationships between this LOM Data Element usage and a non-LOM Vocabulary
For a usage of a simple LOM Data Element with the LOM Datatype "Vocabulary", for zero or more non-LOM Vocabularies to be added:
Add non-LOM Vocabulary as Value Space Extension: (as above).
For zero or more usages of the LOM Data Element "9. Classification":
Edit Classification Purpose: from standard LOM Vocabulary for Classification.
Remove Taxonomy: remove relation between this LOM Data Element Usage and a selected existing Taxonomy.
Add Taxonomy: (as above).
For zero or more selected LOM Data Element usages:
Delete LOM Data Element Usage Description: delete the description of the LOM Data Element Usage, including descriptions of any related Text Document (human-readable specification or guidelines), and remove any encoding scheme relationships in which this property usage is subject.
For zero or more additional LOM Data Elements used in this LOMAP:
Select LOM Data Element for Use: (as above).
Create LOM Data Element Usage Description (as above).
Save Schema Document: as local file.
[Not sure whether this should delete node or flag node as deleted?]
The human administrator of a LOMAP (or a third party) needs to be able to create a new description of a LOMAP, by using an existing LOMAP as the starting point:
Note: the cloning of a LOMAP does not imply any relationship between the newly created LOMAP and the selecteed/cloned LOMAP; this operation is simply a convenience for the LOMAP creator. It does not imply that instances conforming to the newly created LOMAP will necessarily conform to the selected/cloned LOMAP. For example, where a LOM Data Element Usage in the selected/cloned LOMAP specified that usage of a LOM Data Element was mandatory, a LOM Data Element Usage in the newly created LOMAP might specify that it is optional.
Create New Schema Document
Select LOMAP: select an existing LOMAP to serve as the the starting point for this new description of a LOMAP
If agency which manages new LOMAP is different from that of cloned DCAP
Delete Agency Description
Create Agency Description (as above)
Edit LOMAP Description: (as above)
For zero or more selected binding schemas associated with the LOMAP:
Edit Binding Schema Description: (as above).
For zero or more selected binding schemas associated with the LOMAP:
Delete Binding Schema Description: (as above).
For zero or more additional binding schemas associated with the LOMAP:
Create Binding Schema Description: (as above).
For zero or more selected LOM Data Element usages:
Edit LOM Data Element Usage Description: (as above)
For zero or more selected LOM Data Element usages:
Delete LOM Data Element Usage Description: (as above)
For zero or more additional LOM Data Elements used in this LOMAP:
Select LOM Data Element for Use: (as above).
Create LOM Data Element Usage Description (as above).
Save Schema Document: as local file.
The human administrator of a LOMAP (or a third party) needs to be able to create a new description of a LOMAP, where all instances conforming to the new LOMAP will also conform to an existing "base" LOMAP. i.e. the constraints expressed in the new LOMAP are a superset of those expressed in the existing LOMAP.
Note: this differs from the "cloning" case described in the previous section. For example, in this case where a LOM Data Element Usage in the "base" LOMAP specified that usage of a LOM Data Element was mandatory, a LOM Data Element Usage in the newly created LOMAP must not specify that it is optional. A LOM Data Element Usage specified in the base LOMAP canbe edited, but must not be deleted. The author must be able to confirm that the LOMAP being created/edited conforms to the constraints of the existing "base" LOMAP.
Create New Schema Document
Select LOMAP: select an existing LOMAP to serve as the "base" for this new description of a LOMAP
If agency which manages new LOMAP is different from that of cloned DCAP
Delete Agency Description
Create Agency Description (as above)
Edit LOMAP Description: (as above)
For zero or more selected binding schemas associated with the LOMAP:
Edit Binding Schema Description: (as above).
For zero or more selected binding schemas associated with the LOMAP:
Delete Binding Schema Description: (as above).
For zero or more additional binding schemas associated with the LOMAP:
Create Binding Schema Description: (as above).
For zero or more selected LOM Data Element usages:
Edit LOM Data Element Usage Description: (as above)
For zero or more additional LOM Data Elements used in this LOMAP:
Select LOM Data Element for Use: (as above).
Create LOM Data Element Usage Description (as above).
Save Schema Document: as local file.
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.
Create New Schema Document
Create Non-LOM Vocabulary Description: create a description of the Non-LOM Vocabulary, including descriptions of any related Text Document (human-readable specification or guidelines).
For one or more Vocabulary Values:
Create Description of Vocabulary Value: create a description of the Vocabulary Value, including descriptions of any related Text Document (human-readable specification or guidelines).
Save Schema Document: as local file.
Open Schema Document: either from local file or from URL.
For zero or more selected instances:
Edit Description of Vocabulary Value: edit a description of the Vocabulary Value, including descriptions of any related Text Document (human-readable specification or guidelines).
For zero or more additional Vocabulary Values:
Create Description of Vocabulary Value: (as above).
For zero or more selected Vocabulary Values:
Delete Description of Vocabulary Value.
[Not sure whether this should delete node or flag node as deleted?]
Save Schema Document: as local file.
A Schema Document is a document created by the one of the first three functions above.
N.B. The publisher of a Schema Document may be a different Agency from the administrator of the LOMAP/non-LOM Vocabulary/Extended Data Element Set described by that Schema Document; and where descriptions of a LOMAP/non-LOM Vocabulary/Extended Data Element Set are available in multiple Schema Documents (in multiple languages), each of those Schema Documents may have a different Agency as publisher.
The human publisher of a Schema Document (or a third party) needs to be able to create a new description of a Schema Document.
Create Agency Description: create a description of the Agency responsible for the management of the Schema Document, including descriptions of any related Text Document (home page for the Agency).
Create Description of Schema Document: create a description of the Schema Document.
The human publisher of a Schema Document (or a third party) needs to be able to edit a description of a Schema Document.
Edit Agency Description: edit a description of the Agency responsible for the management of the Schema Document, including descriptions of any related Text Document (home page for the Agency).
Edit Description of Schema Document: edit description of the Schema Document.
Having created or edited a Schema Document and created or edited a description of that Schema Document, the human publisher of a Schema Document (or a third party) needs to be able to signal to the registry server that it should be read and indexed.
Note: As part of the submission process, the IEMSR should store a copy of the submitted document, so that it is still available in the case that the copy at the location maintained by the publisher becomes inaccessible.
The human-readable interface should allow a researcher to browse lists of all entities described (except data element usages, text documents and binding schemas):
For each Schema Document in database, view Schema Document Summary. Sort list by [Schema Document] Language [RFC3066] Value, [Schema Document] published by [Agency] Name, [Schema Document] Title.
For each LOM Data Element in database, view LOM Data Element Summary. Sort list by [LOM Data Element] Number.
For each LOM Vocabulary in database, view LOM Vocabulary Summary. Sort list by [LOM Vocabulary] Name.
For each non-LOM Vocabulary in database, view non-LOM Vocabulary Summary. Sort list by [Non-LOM Vocabulary] Name.
A human researcher should be able to query the aggregated data:
Using simple keyword searches on literal values:
Display full Schema Document description:
Also:
View full Agency description:
Also:
Display full LOM Data Element description:
For a Simple LOM Data Element, also:
For a Simple LOM Data Element of datatype Vocabulary, also:
Also:
Also:
Also:
Display full LOMAP description:
Also:
A representation of a LOMAP and its components suitable for printing. (Includes detail views of components rather than just summary views.)
View full LOMAP description:
Also:
Also:
For a usage of a Simple LOM Data Element of datatype Vocabulary, also:
For a usage of a LOM Classification Data Element, also:
For a Simple LOM Data Element, also:
For a usage of a Simple LOM Data Element of datatype Vocabulary, also:
For a usage of a LOM Classification Data Element, also:
Display full Binding Schema description:
Also:
Display full Text Document description:
Also:
The registry must provide one or more interfaces that allow applications to:
Appropriate authentication/authorisation mechanisms must be provided.
It would be useful to support a generic RDF Query/Update API as well as a schema-specific API.
If services are provided using SOAP bindings, equivalent services should be provided using REST/HTTP bindings.
In defining the API, consideration should be given to the current best practice recommendations of the W3C Semantic Web Data Access Working Group (DAWG).