JISC IE Metadata Schema RegistryUsage Scenarios for the IE Metadata Schema Registry |
 |
 |
JISC IE Metadata Schema RegistryUsage Scenarios for the IE Metadata Schema Registry |
|
|
| Home | Background | Dissemination | Contacts |
| Phase 1 | WP1: Project management | WP2: Model/Use | WP3: Tools | WP4: m2m | WP5: Validation | WP6: Policy | WP7: Evaluation |
The following accounts illustrate how different human users and software tools might interact with the IEMSR. Two possibilities are considered:
The term "the IEMSR" refers to the the registry server, which will provide services based to human users via an HTML interface and to software tools via one or more application interfaces.
The term "metadata editor" refers to a software tool for creating and editing ("document-level") descriptions of documents and schemas describing metadata vocabularies and metadata application profiles. In the thin registry option, this is the only metadata available to the registry; in the thick registry option, it is used to identify data sources/schemas that the registry reads, and also to provide "provenance" metadata so that a user of the registry can obtain a description of the source/schema from which data was obtained.
The term "LOMAP editor" and "DCAP editor" (applicable only for the "thick registry" option) refers to software tools for creating and editing ("component-level") structured descriptions of LOM Application Profiles and DC Application Profiles (and metadata vocabularies).
This document is neutral on the implementation of these three tools. They may be browser-based applications or stand-alone tools; they may be tools developed specifically for this purpose or they may be general-purpose tools configured for this application.
A LOM Application Profile (LOMAP) is a specification of how the information model described by the IEEE LOM standard is adopted to the requirements of a particular metadata application [2].
The schema designer for a learning object repository has created a LOM Application Profile for use by that service. The LOMAP is based on the UK LOM Core LOMAP and is described in a human-readable document. The designer has also created
The designer wishes to make information about this LOMAP available to users of their service (including content providers and presentation services), and to the developers of other learning object repositories.
The designer uses the metadata editor to create a description of each existing resource, including its location, status, purpose/intended use or audience, a classification according to a registry-specific type vocabulary, and descriptions of the relationships between resources. The designer submits these descriptions available to the registry.
The designer uses the LOMAP editor and specifies that they are creating a new LOMAP description rather than editing an existing LOMAP description. The designer provides a description of the LOMAP itself including the status of the LOMAP, its purpose/intended use or audience, and its maintainance agency/owner.
The editor presents a list of existing LOMAPs that can be used as a "base" for the new LOMAP. The designer selects the UK LOM Core as the base LOMAP for their new LOMAP. The editor presents a view of the LOM structure. Each LOM data element in the structure has associated with it the usage attributes specified by the UK LOM Core LOMAP.
For each LOM data element, the designer describes the usage of the LOM data element in the context of this LOMAP. For some LOM data elements, they leave the usage attributes specified by the UK LOM Core unchanged. For some LOM data elements specified as "optional" by UK LOM Core, they change the constraints to specify that in the context of this LOMAP, those LOM data elements are mandatory; for others they specify that in the context of this LOMAP, they are not permitted. If the designer attempts to remove or make optional a LOM data element that is specified as mandatory by UK LOM Core the editor presents a warning.
For some LOM data elements, the designer specifies that values should be drawn from their controlled vocabularies. These "local" controlled vocabularies are used in addition to the LOM standard vocabulary. Where a VDEX document is available, the location of the VDEX document is supplied [See Note 1].
The designer also specifies the use of named taxonomies for the LOM Classification category for the purposes of "discipline", "idea", and "educational level". Where a VDEX document is available, the location of the VDEX document is supplied.
The designer provides descriptions of the XML Schemas (and any supporting documents) used to describe the XML binding for this LOMAP [See Note 2].
The designer saves the description of their LOMAP (the schema) and makes it available from their Web server. Having authenticated to the registration interface, the developer uses the metadata editor to create a description of the schema, including its location, and submits the description to the IEMSR.
A content provider must make learning objects available to two learning object repositories. They know that LOM metadata supplied to each service must conform to two different named LOM Application Profiles. They wish to obtain
The content provider uses a search interface to the IEMSR to search for LOMAPs by title. They discover several possible candidate LOMAPs. By examining the metadata displayed about the owner and purpose of the LOMAP, they are able to identify the two specific LOMAPs required.
For each of the two LOMAPs, they are able to access the descriptions published by their owners, including a description of the LOMAP, the LOM data element usages, and the controlled vocabularies and taxonomies used within the LOMAP (including access to VDEX documents where supplied). They can also access the XML Schemas required, plus human-readable documentation that indicates which constraints of the LOMAPs are not implemented by the XML Schemas.
The thin registry option does not provide a LOMAP editor.
The content provider uses a search interface to the IEMSR to search for LOMAPs by title. They discover several possible candidate LOMAPs. By examining the metadata displayed about the owner and purpose of the LOMAP, they are able to identify the two specific LOMAPs required.
For each of the two LOMAPs, they are able to select a display option that provides the full description of the LOMAP, the LOM data element usages, and the controlled vocabularies and taxonomies used within the LOMAP (including access to VDEX documents where supplied). They can also access the XML Schemas required, plus human-readable documentation that indicates which constraints of the LOMAPs are not implemented by the XML Schemas.
They can obtain information on the "provenance" of the data and access the source schema(s) from which it was provided, which they can download and open in the LOMAP editor.
The developer of a learning object repository wishes to discover what LOM Application Profiles are in use in the context of UK Higher Education.
The developer uses a browse interface to the IEMSR to browse descriptions of LOMAPs grouped according to their intended purpose/audience. They discover several possible candidate LOMAPs.
For each of the LOMAPs, they are able to obtain more metadata describing the status and intended uses of the LOMAPs and the contact details of their owners/maintainance agencies.
For relevant LOMAPs, they are able to access the descriptions published by their owners, including descriptions of the LOM data element usages, and all the controlled vocabularies used within the LOMAP (including access to VDEX documents where supplied). They can also access the XML Schemas for an XML binding of the LOMAP, plus human-readable documentation that indicates which constraints of the LOMAPs are not implemented by the XML Schemas.
The developer uses a browse interface to the IEMSR to browse descriptions of LOMAPs grouped according to their intended purpose/audience. They discover several possible candidate LOMAPs.
For each of the LOMAPs, they are able to obtain more metadata describing the status and intended uses of the LOMAPs and the contact details of their owners/maintainance agencies.
For relevant LOMAPs, they are able to obtain descriptions of the LOM data element usages, and all the controlled vocabularies used within the LOMAP (including access to VDEX documents where supplied). They can also access the XML Schemas required, plus human-readable documentation that indicates which constraints of the LOMAPs are not implemented by the XML Schemas.
They can obtain information on the "provenance" of the data and access the source schema(s) from which it was provided, which they can download and open in the LOMAP editor.
(Assumes structured description of LOMAP at component-level so requires thick registry)
A schema developer wishes to survey the usage of a specified LOM data element.
The developer browses the list of LOM data element names and selects the required element name. The LOM data element display includes the definition of the property provided by the LOM standard, and a set of links to usages of this property in various LOMAPs. The description of each usage of this LOM data element includes usage guidelines, the obligation/occurrence conditions, and controlled vocabularies used to constrain values of the data element. A list of the terms in the controlled vocabulary is available.
(Assumes structured description of LOMAP at component-level so requires thick registry?)
The developer of a forms-based LOM XML authoring tool provides a "Select LOMAP" function for "instance" metadata creators, so that the XML document that they create conforms to the chosen LOMAP. In the past this has been based on supplying a set of configuration files that describe a fixed number of LOMAPs bundled with the authoring tool. The developer enables the tool to access the descriptions of LOMAPs using the IEMSR query API so that authoritative descriptions of new LOMAPs (or new versions of existing LOMAPs) can be obtained from a single source.
The administrator of a content provider organisation configures the tool so that three LOMAPs are available to metadata authors. The administrator uses a "Preferences - Show LOMAPs" function that queries the IEMSR and presents a list of titles of available LOMAPs. A default set of widely used LOMAPs is pre-selected by the tool developer. From this list of available LOMAPs the administrator de-selects some of the pre-selected LOMAPs and selects those LOMAPs that are to be available to metadata authors in their organisation.
The metadata author in the content provider organisation launches the authoring tool and selects one of the three available LOMAPs. They obtain a form that is tailored for the selected LOMAP: text boxes are displayed only for the LOM data elements used in that LOMAP, and are labelled as specifed by the LOMAP. The cardinality constraints on LOM data elements for that LOMAP are applied. Where values for LOM data elements are associated with a controlled vocabulary, the values are available for selection. Usage guidelines are available for each LOM data element. Data is saved using the XML binding specified for that LOMAP.
(Assumes structured description of LOMAP at component-level so requires thick registry?)
The schema designer working on the development of a learning object repository is designing a LOMAP to meet the requirements of a specific user community. The new LOMAP must conform to the mandatory core requirements specified by the UK LOM Core LOMAP.
The designer uses a browse interface to the IEMSR to browse LOMAPs grouped according to their intended purpose/audience and to explore several LOMAPs designed for similar purposes and notes the availability of several controlled vocabularies that they may wish to deploy in their new LOMAP. When reviewing LOM data element usages within a LOMAP, they are able to navigate to a display of the standard description of the LOM data element, and from there to review other usages of that LOM data element in other LOMAPs.
The designer uses the LOMAP editor and specifies that they are creating a new LOMAP description rather than editing an existing LOMAP description. The designer provides a description of the LOMAP itself including the status of the LOMAP, its purpose/intended use or audience, and its maintainance agency/owner.
The LOMAP editor presents a list of existing LOMAPs that can be used as a "base" for the new LOMAP. The designer selects the UK LOM Core as the base LOMAP for their new LOMAP. The editor presents a view of the LOM structure. Each LOM data element in the structure has associated with it the usage attributes specified by the UK LOM Core LOMAP.
For each LOM data element, the designer describes the usage of the LOM data element in the context of this LOMAP. For some LOM data elements, they leave the usage attributes specified by the UK LOM Core unchanged. For some LOM data elements specified as "optional" by UK LOM Core, they change the constraints to specify that in the context of this LOMAP, those LOM data elements are mandatory; for others they specify that in the context of this LOMAP, they are not permitted. If the designer attempts to remove or make optional a LOM data element that is specified as mandatory by UK LOM Core the editor presents a warning.
For some LOM data elements, the designer specifies that values must be drawn from the controlled vocabularies they discovered while browsing other LOMAPs. The designer selects the required controlled vocabularies by interacting with the IEMSR via the editor. These "local" controlled vocabularies are used in addition to the LOM standard vocabulary.
The designer also constructs a new controlled vocabulary for one LOM data element, to be used in addition to the LOM standard vocabulary for that LOM data element.
The designer also specifies the use of named taxonomies for the LOM Classification category for the purposes of "discipline", "idea", and "educational level".
The designer saves the description of their LOMAP (the schema) and makes it available from their Web server. Having authenticated to the registration interface, the developer uses the metadata editor to create a description of the schema, including its location, and submits the description to the IEMSR.
(Adapted from MEG Registry scenarios.)
A Dublin Core Application Profile (DCAP) is a declaration specifying, at a minimum, which properties are used within a particular metadata application. Optionally, an application profile may describe how those properties have been constrained or adapted for particular purposes. A DCAP is represented as a set of property usages [2].
The schema designer for a service has created a new metadata vocabulary developed for use in a DCAP. The metadata vocabulary is described in a human-readable document.
The designer wishes to make information about this metadata vocabulary available to other schema designers.
The designer uses the metadata editor to create a description of the document describing the metadata vocabulary, including its location, status, purpose/intended use or audience, a classification according to a registry-specific type vocabulary. The designer submits this description to the registry.
The designer uses the DCAP editor and specifies that they are creating a description of a new metadata vocabulary rather than a DCAP. The designer provides a description of the metadata vocabulary including its status, its purpose/intended use or audience, and its maintainance agency/owner.
If the designer has already created an RDF Schema representation of the properties, classes and datatypes in the metadata vocabulary, then the designer can use this data for the registry and does not need to re-describe these resources. If they have not created an RDF Schema representation, then the designer uses the DCAP editor to create a description of each property in their metadata vocabulary, and each class (vocabulary encoding scheme or type) and instances of that class (controlled vocabulary terms) [See Note 3].
The designer saves the description of their metadata vocabulary (the schema) and makes it available from their Web server.
Having authenticated to the registration interface, the developer uses the metadata editor to create a description of the schema(s), including its location, and submits the description to the IEMSR.
The schema designer for a service has created a DC Application Profile for that service, based on the use of properties from the Dublin Core metadata vocabularies and from a supplementary metadata vocabulary developed for the purposes of the application. The DCAP is described in a human-readable document. The designer has also created a set of W3C XML Schemas to support the creation of metadata records conforming to the DCAP for exchange using the OAI Procol for Metadata Harvesting.
The designer wishes to make information about this DCAP available to users of their service, and to the developers of other services.
The designer uses the metadata editor to create a description of each existing resource, including its location, status, purpose/intended use or audience, a classification according to a registry-specific type vocabulary, and descriptions of the relationships between resources. The designer submits these descriptions to the registry.
The designer uses the DCAP editor and specifies that they are creating a description of a DCAP rather than of a metadata vocabulary. The designer provides a description of the DCAP including the status of the DCAP, its purpose/intended use or audience, and its maintainance agency/owner.
The designer describes the property usages within this DCAP using the DCAP editor to interact with the IEMSR and select the required properties, and specifies how they are used in the context of this DCAP. For each property usage they indicate the type of the subject resource to which it applies. For some properties, the property usage includes constraints on the values of the property, specified by selecting classes (encoding schemes) from existing metadata vocabularies.
The designer also creates descriptions of their human-readable guidelines for this DCAP, and for the XML Schemas that provide an XML binding.
The designer saves the description of their DCAP (the schema) and makes it available from their Web server.
Having authenticated to the registration interface, the developer uses the metadata editor to create a description of the schema(s), including its location, and submits the description to the IEMSR.
A content provider must make resources available with metadata conforming to two different named DC Application Profiles. They wish to obtain
The content provider uses a search interface to the IEMSR to search for DCAPs by title. They discover several possible candidate LOMAPs. By examining the metadata displayed about the owner and purpose of the DCAP, they are able to identify the two specific DCAPs required.
For each of the two DCAPs, they are able to access the descriptions published by their owners, including a description of the DCAP, the property usages, and the controlled vocabularies used as encoding schemes. They can also access the XML Schemas required.
The content provider uses a search interface to the IEMSR to search for DCAPs by title. They discover several possible candidate LOMAPs. By examining the metadata displayed about the owner and purpose of the DCAP, they are able to identify the two specific DCAPs required.
For each of the two DCAPs, they are able to access the descriptions published by their owners, including a description of the DCAP, the property usages, and the controlled vocabularies used as encoding schemes. They can also access the XML Schemas required.
They can obtain information on the "provenance" of the data and access the source schema(s) from which it was provided, which they can download and open in the DCAP editor.
The developer of a portal product wishes to discover what DC Application Profiles are in use in the context of UK Higher Education to describe digital images.
The developer uses a browse interface to the IEMSR to browse descriptions of DCAPs grouped according to their intended purpose/audience. They discover several possible candidate DCAPs.
For each of the DCAPs, they are able to obtain more metadata describing the status and intended uses of the DCAPs and the contact details of their owners/maintainance agencies.
For relevant DCAPs, they are able to access the descriptions published by their owners, including descriptions of the property usages, and all the controlled vocabularies used as encoding schemes in the DCAP. They can also access the XML Schemas for an XML binding of the DCAP.
The developer uses a query interface to the IEMSR to search for property usages with a subject resource type of dcmitype:Image or any subclasses of that class. They discover several property usages that are members of possible candidate DCAPs.
For each of the DCAPs, they are able to obtain more metadata describing the status and intended uses of the DCAPs and the contact details of their owners/maintainance agencies.
For relevant DCAPs, they are able to obtain descriptions of the property usages, and all the controlled vocabularies used as encoding schemes in the DCAP. They can also access the XML Schemas for an XML binding of the DCAP.
They can obtain information on the "provenance" of the data and access the source schema(s) from which it was provided, which they can download and open in the DCAP editor.
(Assumes structured description of DCAP at component-level so requires thick registry)
A schema developer wishes to survey the usage of a known property, and particularly the use of any controlled vocabularies to control values of this property.
The developer either browses the list of property names (qualified by metadata vocabulary names), and selects the required property, or searches for it by property name/identifier. The property display includes the definition of the property provided by the owner of the metadata vocabulary, and a set of links to usages of this property in various DCAPs. The description of each property usage includes a description of constraints on values (encoding schemes). A list of instances of the class (terms in a controlled vocabulary) may be available where the controlled vocabulary is small.
The display of the class includes a set of links to other property usages that use the same class to constrain values.
Note 1: 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.
Note 2: This assumes that the description of a LOMAP indexed by the registry is distinct from an XML Schema or set of XML Schemas that describes the XML binding.
Note 3: What do we do about literal datatypes? DC itself doesn't use them, but other metadata vocabularies used in DCAPs might.
[ 1] Model for a LOM Metadata Application Profile (LOMAP)
http://www.ukoln.ac.uk/projects/iemsr/wp2/lomap/
[ 2] Model for a Dublin Core Metadata Application Profile (DCAP)
http://www.ukoln.ac.uk/projects/iemsr/wp2/dcap/
Web page content by
Pete Johnston of UKOLN
Page last revised on:
12 May 2004
Email comments to webmaster@ukoln.ac.uk