DefiningImageAccess/Project/IEMSR

From ImageWeb

Jump to: navigation, search

IEMSR: JISC Information Environment Metadata Registry

"Metadata schema registries enable the publication, navigation and sharing of information about metadata. The IEMSR will act as the primary source for authoritative information about metadata schemas recommended by the JISC IE Standards framework."

The project plan for phase 3 of the project indicates a target community of DC and IEEE LOM users.

From the aims and objectives, the targets of this project seem to be related to schema selection and development, rather than operational use of schemas (though the marketing document suggests some operational use).

From the project plan section 9, the IEMSR focus on application profiles of DC and IEEE LOM is reinformced.


What is IEMSR is intended to provide?

From the IEMSR marketing plan document (http://www.ukoln.ac.uk/projects/iemsr/phase3/IEMSR-marketing-plan.pdf):

2.4 How could I use a metadata registry?

Metadata registries have multiple potential uses across a wide range of disciplines. Usage scenarios for registries might include the following (taken from Baker et al, 2003):

  • A cataloguer needs to know the best practice for describing a particular type of resources. (A query to a registry might return a list of metadata element sets classified by use.)
  • A federation of information providers wants to harmonise metadata usage among its members. (A registry might present descriptions of how metadata element sets have been applied so that a reader can compare areas of similarity and difference.)
  • An information provider needs to translate its metadata into the shared format of a digital library federation. (A registry might link to crosswalk services that can batchconvert records from one format into another.)
  • An implementer wants to construct an AP, re-using existing elements as far as possible. (A registry allows searching and browsing of data elements grouped into sets and profiles.)
  • A software developer wants metadata tools to update their configurations automatically. (A registry might point to or provide machine-processable schemas.)
  • Ten years from now, an archive needs to interpret and convert metadata records from 2002. (A registry might hold historical versioning information on standards or on particular applications.)
  • Chinese speakers want to view or process metadata prepared in Germany. (A registry might specialise in providing translations or annotations in multiple languages.)

The IEMSR does not intend to support all of the above uses. The project will focus on a small number of specific use cases to illustrate the functionality and benefits to stakeholders.

The marketing document also has a stakeholder analysis table:

Stakeholders Potential uses Importance
Schema creators Discovery and re-use of existing application profiles or individual terms. High
Service/System developers Easy access to information about existing schemas and application profiles. High
Data curators & service providers (e.g JISC projects & services) Access to machine-readable schemas and application profiles.

Publishing machine-readable schemas and application profiles used within service implementations.

High
Cataloguers Detailed information on application profiles which can support the training of cataloguers High
Funders Encourage re-use of existing application profiles and terms to save duplication of effort and promote interoperability.

Promotion, quality assurance and preservation of schemas and application profiles.

High
Commercial suppliers of software products and services to JISC Access to machine-readable schemas and application IE profiles deployed within JISC IE. Medium
Other registries Re-use application profile models, re-use source code. Medium

From these, I surmise that the main target for IEMSR is to provide global informartion about metadata standards for system designers and developers. Compare with our proposed data web schema registry, whose main target is to provide mapping rules for use by the software of a specific data web.

One useful point of contact may be indicated in the final row of the stakeholder table. I could see IEMSR used to hold advice for developers about creating mapping rules for common schema, and machine-processable mapping rules that can be submitted to a data web schema registry.

In a sense, a key purpose of IEMSR may be considered to be avoiding the need for systems like our data web schema alignment services. For common metadata, it is clearly higly desirable that common standards be used, but we also believe that individual researchers will tend to initially design schema to support their local needs, and think later about issues of alignment with other schemas.

Some consideration has been given to IEMSR as an operational mapping service (this from a meeting with Balviar Notay):

The IEMSR as a potential operational service was discussed. The following observations

were made:

  • Projects may need to do mappings between schemas. Would IEMSR offer this as a service?
  • Would the scope of the IMESR support other data types not described using DC and LOM, e.g. geographical data?
  • If the IEMSR becomes an operational service it will need to consider its own ‘presentation’, i.e. how it promotes itself within and outside the JISC IE. The IEMSR RSS feature demonstrated during the meeting was stated as a useful tool for raising awareness across programme and projects.
  • If the intention for the IEMSR is to act as a reference point, will the IEMSR create links to other registries in other thematic communities?

However, none of the use-cases in the marketing plan deal with automated schema alignment.

Personal tools
Oxford DMP online
MIIDI
Claros