JISC IE Metadata Schema Registry

1. Introduction

The two documents Functional Requirements for the IE Metadata Schema Registry [FUNCREQ] and Review of IEMSR Presentation Service/Supplementary Functional Requirements [SUPFR] outlined the functions to be supported by the IEMSR software tools, primarily from the viewpoint of functions to be performed by a human user rather than a software agent.

The development work during Phase 1 of the IEMSR project has resulted in the creation of three distinct functional components:

• the Registry Data Server The Registry Data Server is what the JISC IE Technical Architecture describes as a 'shared infrastructural service': it provides interfaces to other applications, but it is largely 'invisible' to the human user of those applications. The registry is an RDF application currently based on the Redland RDF Toolkit. It provides a persistent data store (using a MySQL database) and REST-based APIs for uploading data to the data store and for querying its content. The query interface supports SPARQL, the RDF query language under development by the W3C RDF Data Access Working Group. See Registry Tools Development - Data Server [TOOL-DATA-SERVER].
• the Data Creation Tool The IEMSR Data Creation tool supports the creation of RDF Data Sources for use by the Registry Data Server and the submission of those Data Sources to the Registry Data Server. It is written in Java and uses the Eclipse SWT and JFace libraries to provide a natural interface across different platforms. See Registry Tools Development - Desktop Client [TOOL-CLIENT].
• the User Web Site Server The IEMSR User Web Site is a presentational service. It provides a 'metadata portal' function: it allows a human user to browse and query the data that is made available by the IEMSR Registry Data Server - it offers 'read-only' access to the Registry Data Server. See Registry Tools Development - Web Site Server [TOOL-WEBSITE-SERVER].

Current versions of all these components are available from the project's Sourceforge site.

2. Data Sources for the IEMSR Registry Data Server

The IEMSR Registry Data Server stores data which describes metadata "terms" and various related resources. The types of resources covered by the IEMSR are described in two documents: Model for Dublin Core Application Profile (DCAP) ([DCAP-MODEL] and Model for LOM Application Profile (LOMAP) [LOMAP-MODEL]. That data is made available to the Registry Data Server in the form of IEMSR Data Sources. In some of the early IEMSR documents, Data Sources are referred to as Schema Documents or simply "Schemas". This terminology was changed in order to try to clarify the distinctions between three distinct types of resource:

• the digital objects read and indexed by the Registry Data Server;
• "conceptual schemas" or "information models" such as that defined by the IEEE LOM standard;
• "structural schemas" or "document schemas" such as XML Schema, RELAX NG Schema etc that define the structure of a class of digital objects (typically a class of XML documents)

The data stored and made available by the IEMSR Registry Data Server includes descriptions of "conceptual schemas" and "structural schemas"; those descriptions are created in the form of IEMSR Data Sources. These are the digital objects which are submitted to the IEMSR Registry Data Server, the "metadata records" of IEMSR. Note that a single Data Source may provide descriptions of multiple Metadata Vocabularies, DC Application Profiles, LOM Application Profiles, Non-LOM Vocabularies etc

The IEMSR Registry Data Server is based on the Resource Description Framework (RDF); that is, an IEMSR Data Source is a set of RDF triples, usually in the form of an RDF/XML document though in principle it may be RDF data in another format. Some such Data Sources are created using the IEMSR Data Creation Tool; others are created by other applications. Some of the data required by IEMSR has been created quite independently of IEMSR and is published on the Web using the RDF Vocabulary Description Language (RDF Schema). For example, DCMI and other publishers of Metadata Vocabularies make available RDF/XML documents that provide descriptions of their vocabularies in this way. The RDF representation used by IEMSR is built on RDF Schema precisely so that this data can be used. (This applies only for the case of Dublin Core and vocabularies that are used in the context of the Dublin Core Abstract Model; the representation of LOM used by IEMSR is not based on RDF Schema and has been developed for specifically for IEMSR, so there is no existing public data to be used).

3. Functions Available

This section compares the current functionality of the tools against the requirements specified (and any additional requirements gathered during Phase 1). It attempts to highlight functions that are not available or partly available and to suggest priorities for further development work.

Also, to support the process of prioritising development, it attempts to categorise the functions of the IEMSR components according to the following "functional areas":

• Create/Edit Data Source
  The process of creating, amending and deleting descriptions of Metadata Vocabularies, DC Application Profiles, LOM Application Profiles and their components and related resources (Text Documents, Binding Schemas, VDEX Documents etc). This process results in the creation of a new Data Source or an amended version of an existing Data Source. It does not change the content of the Registry Data Server data store. See Section 3.1.

• Load Data Source to/Withdraw Data Source from Registry Data Server See Section 3.2.

  • Load Data Source to Registry Data Store
    The process of submitting a new Data Source to the Registry Server. This process results in the addition of a new set of RDF data (the content of the Data Source and a description of the Data Source) to the Data Store
  • Re-load Data Source to Registry Data Store
    The process of submitting an amended version of an existing Data Source to the Registry Server. This process results in the removal of one set of RDF data (the content of the previous version of the Data Source) from the Data Store and the addition of a new set of RDF data (the content of the Data Source) to the Data Store
  • Withdraw Data Source from Registry Data Store
    The process of removing an existing Data Source from the Registry Server. This process results in the removal of a set of RDF data (the content of the Data Source and the description of the Data Source) from the Data Store
  • Get Data Source from Registry Data Store
    The process of obtaining a copy of a Data Source from the Registry Data Store.
• Accept Query/Present Result Set
  The processes of accepting a query from a user and sorting/filtering/formatting the result set generated as a result of query. The accept query process generates a query to the Registry Data Server based on human user input/action; the present result set process generates a human-readable display. See Section 3.3.
• Search Registry Data Store
  The process of issuing a query to the Registry Data Server. This process generates a result set. See Section 3.4.

The functions are also labelled according to whether they apply to resources related to Dublin Core (Metadata Vocabularies and DC Application Profiles and their components and related resources) and whether they apply to resources related to LOM (LOM Application Profiles and their components and related resources).

Some functions are common to both Dublin Core and LOM, and are referenced at several points within other functions. These have been labelled separately, though it should be noted that where one of these common functions is available, it may not be available at all the points where it is required (e.g. within a single Data Source the description of several different Agents may be required).