UKOLN - Projects - IEMSR - Functional Requirements for the IE Metadata Schema Registry

Introduction
Dublin Core Application Profiles
LOM Application Profiles
Notes
References

1. Introduction

This document builds on the high-level description of the functions of the IEMSR and the usage scenarios to provide some high-level 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.

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:
- Title
- Version
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:
- Title
- Version
Schema Documents, sorted by title of schema document, version of schema document. Display in list:
- Title
- Version

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
- display full agency description
- display summary list of
  - Metadata vocabularies administered by this agency, sorted by title of metadata vocabulary, version of metadata vocabulary
  - DC application profiles administered by this agency, sorted by title of DCAP, version of DCAP
  - Schema documents published by this agency, sorted by title of schema document, version of schema document
  From entry in summary list researcher can navigate to full display for that entity.
Metadata vocabulary
- display metadata vocabulary description
- display summary list of
  - Properties in this metadata vocabulary, sorted by label of property
  - Classes in this metadata vocabulary, sorted by label of class
  - Application profiles that use any terms from this metadata vocabulary, sorted by title of DCAP, version of DCAP
  From entry in summary list researcher can navigate to full display for that entity.
Property
- display property description (including URI, label and QName)
- display summary list of
  - Properties that are subproperties of this property, sorted by label of property, title of metadata vocabulary, version of metadata vocabulary
  - Property usages that use this property, sorted by title of DC application profile, version of application profile, label of subject type, label of property usage
  From entry in summary list researcher can navigate to full display for that entity.
Class
- display class description (including URI, label and QName)
- display summary list of
  - Classes that are subclasses of this class, sorted by label of class, title of metadata vocabulary, version of metadata vocabulary
  - Property usages that use this class as an encoding scheme, sorted by title of DC application profile, version of application profile, label of subject type, label of property usage
  From entry in summary list researcher can navigate to full display for that entity.
- display full list of
  - Instances of this class, sorted by label of instance
DC application profile
- display DCAP description
- display summary list of
  - Property usages in this DC application profile, sorted by label of subject type, label of property usage
  - Binding schemas that express this application profile, sorted by title of binding schema, version of binding schema
  From entry in summary list researcher can navigate to full display for that entity.
Property Usage
- display property usage description
- display summary list of
  - Classes used as encoding schemes, sorted by label of class
  - Datatypes used as encoding schemes
  From entry in summary list researcher can navigate to full display for that entity.
Schema Document
- display schema document description
- display summary list of
  - Metadata vocabulary described by this schema document
  - Properties described by this schema document, sorted by label of property
  - Classes described by this schema document, sorted by label of class
  - DC application profile described by this schema document
  - Property usages described by this schema document, sorted by label of subject type, label of property usage
  From entry in summary list researcher can navigate to full display for that entity.

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

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