Skip to content
Site map |

DA3 Usage Scenarios

DART DA3 Usage Scenarios

DART Project, module DA3
Suzanne Little (little@itee.uq.edu.au)
2006-02-20

Objectives

The metadata schema registry (MSR) for the DART work package DA3 is intended to provide a centralised repository of metadata schemas and ontologies. The MSR will act as an authorative information source and promote the sharing and reuse of the schemas. The aim of the MSR is to enable users to create new schemas, submit schemas to the registry and search and browse the registry. The characteristics required of the DART MSR include:

  • no requirement for a common model such as Dublin Core or IEEE Learning Objects Metadata;
  • support for XML Schema and RDF Schema formats (possibly also OWL?);
  • user interfaces for submission, browsing, searching and editing registry entries;
  • no protocols required for software agent access at this stage.

Participants and Terminology

  • SchemaDocument: the document that describes the schema in XML or RDF schema formats.
  • User: human user of the system. Has two main tasks: submission of the the SchemaDocument to the Registry or retrieval of information from the Registry.
  • Registry: the application that manages, verifies and stores the SchemaDocuments and their metadata. Also provides APIs for search, browse, submission and retrieval.
  • RegistryInterface: web-based interface for uploading and downloading SchemaDocuments, capturing metadata from the User about the SchemaDocument, providing the search/browse interface to the Registry.

Registry components:

Metadata

(Initial thoughts on types of metadata that might be required. Possible sources for metadata terms include: IEMSR, ISO/IEC 11179, SchemaWeb, Dublin Core.)

Metadata Field Description Example
Title The title of the schema Crystallography Schema (CIF)
Description A (short) human readable description of the schema contents and purpose This XML Schema describes the syntax of CIF files for describing crystallographic structures.
Identifier A uri of the schema for the registry http://dart.edu.au/dmsr/cif/200606012/
Format Currently either XML Schema or RDF Schema XML Schema
Administrator The organisation or authority who created and manages the schema. Also record address, phone, email and website details for this organisation. Name: ACME Co; Address: PO Box 1111, Brisbane 4001; Phone: (07) 3333 4444; Website: http://www.acme.com; email: admin@acme.com
Contact A nominated contact within the administrating organisation and their contact details Name: John Smith; email: jsmith@acme.com
Author (alt) The name and contact details of the schema's creator/administrator where a schema is submitted by an independent individual Name: John Smith, Organisation: ITEE, UQ; Phone: (07) 3365 4444; email: jsmith@itee.uq.edu.au
Publisher The organisation which makes the schema available for use The DART Metadata Schema Registry
Date.Created The date the schema was created 2006-03-06
Date.Submitted The date the schema was submitted to the registry 2006-03-15
Date.Updated The last date any changes were made to the schema or its metadata where no version change was made 2006-05-05
Version Version number for the schema 1.3
Replaces/
IsReplacedBy		 Identifier of schema which this schema replaces or is replaced by Replaces: http://dart.edu.au/dmsr/20050208/
Coverage The subject, area or domain to which the schema applies (value is possibly from a controlled vocabulary) CIF (crystallography) files
ExampleInstance A url to an example instance of the schema http://dart.edu.au/dmsr/examples/cif/20060612.xml
ReferenceDocument One or more urls to descriptive reference documents explaining or providing human-readable definitions of the fields in the schema (in txt, html or pdf format) http://www.acme.com/cif/schema-description.pdf

Metadata Fields Used by Other Registries

The IEMSR online demo provides the following metadata fields -- Description; Format; Date created; Date modified; Publisher -- when browsing the schemas.

SchemaWeb provides the following metadata fields -- Name; Description; Namespace; Location; Website; Contact Name; Contact Email; Local Version -- when browsing the ontologies/schemas.

METeOR (Aust. Institute of Health and Welfare) provides the following metadata fields -- Metadata item type; Synonymous names; METeOR identifier; Registration status; Definition; Classification structure; Guide for use; Steward; Origin; Reference Documents; Revision Status; Value domains based on this classificiation scheme; Dataset specification type; Submitting organisation -- when browsing classification schemes or data set specifications.

Tasks

These are the tasks that need to be supported by the MSR and the participants in each one:

  1. submission (aka: registration, uploading, entering) [User, Registry]
  2. metadata capture [User, Registry]
  3. verification and validation [Registry]
  4. search or query [User, Registry]
  5. browse [User, Registry]
  6. retrieval (aka: downloading) [User, Registry]
  7. updating (aka: editing, (metadata) maintenance) [User, Registry]

Example Scenarios

A metadata schema registry for the climatology field has been developed and implemented. It contains a dozen schemas in both XML and RDF schema formats. These schemas are used to structure data records from a variety of specific domains related to the study of climatology including water quality testing; meteorology reports; satellite imagery of vegetation density and distribution etc. The registry is available on the web and is used by researchers and administrators from organisations such as: CSIRO; University of Queensland; the Queensland Department for Environment; the Environmental Protection Agency; the CRC for Greenhouse Accounting etc.

Scenario 1

A team working for the CRC for Greenhouse Accounting has developed a schema for recording the level of air-born pollutants in an atmospheric sample. They wish to submit this schema, which is in XML Schema format, to the climatology metadata registry for use by other researchers in the field.

Possible Process:

  1. User goes to submission page on RegistryInterface website
  2. User fills in form to provide metadata related to the SchemaDocument
  3. User selects SchemaDocument location from local machine (or supplies a URL for SchemaDocument location)
  4. User pushes submit button
  5. RegistryInterface checks that all compulsory elements of the form have been completed (Error is returned to the User if the form is incomplete)
  6. RegistryInterface formats the metadata and passes the SchemaDocument (or its URL) and the metadata document to the Registry
  7. Registry validates the SchemaDocument (Error is returned to the User if it's invalid)
  8. Registry saves the SchemaDocument and metadata document and associates metadata document with SchemaDocument
  9. Registry passes success message to RegistryInterface
  10. RegistryInterface informs the User that submission has been successful and provides website address for browsing the submitted SchemaDocument

Scenario 2

A researcher from the University of Queensland wishes to make their research data from water testing at the Indooroopilly stretch of the Brisbane River available to other researchers in the climatology field. They need to find the appropriate schema for recording and structuring water analysis results (e.g. water temperature, oxygen levels, salt levels, pollutants etc.)

Possible Process:

  1. User goes to search page of the RegistryInterface website
  2. User selects to search for "water" in the domains field
  3. RegistryInterface constructs query and passes it to the Registry
  4. Registry returns list of matching SchemaDocuments
  5. RegistryInterface retrieves metadata about SchemaDocuments from Registry
  6. RegistryInterface provides list of SchemaDocuments and selected metadata to the User
  7. User browses SchemaDocuments until finding the appropriate one for their requirements
  8. User downloads the SchemaDocument

Scenario 3

The researcher from scenario 2 finds the schema for water testing results but it doesn't have enough detail on recording the level of pollutants. Further searches discover the air pollutant schema registered by the research team from scenario 1. The researcher is able to develop an updated version of the water quality schema which includes fields for recording pollutant levels based on the structure used for air pollutants. The researcher registers this new schema as an updated, alternative version of the original water quality schema.

Possible Process:

  1. continuing from scenario 2's possible process step 7
  2. User examines SchemaDocument but is dissatisfied with fields for recording pollutant levels
  3. User returns to search pages of the RegistryInterface website
  4. User searches for all SchemaDocuments which have the field 'pollutant'
  5. RegistryInterface constructs query and passes it to the Registry
  6. Registry returns list of matching SchemaDocuments
  7. RegistryInterface retrieves metadata about SchemaDocuments from Registry
  8. RegistryInterface provides list of SchemaDocuments and selected metadata to the User
  9. User finds the schema submitted in scenario 1 and decides that the data recorded about pollutants is better in that schema
  10. User downloads both the original water schema and the new air pollutant schema
  11. User incorporates sections of the air pollutant schema into the original water schema
  12. User follows process described for scenario 1 to submit the new schema and includes that this is an extension of the original water schema

Suzanne Little
Last modified: Mon Mar 6 10:51:09 EST 2006