Common requirements

From Metadata-Registry
Jump to: navigation, search

DCMI Registry Task Group

Back to DCMI Registry Community Main Page

GOAL: Develop a set of functional requirements common to current registries, based on the experience and findings of current registry implementers and stakeholders. As part of this, investigate the dissemination functionality considered desirable in a registry, and appropriate use cases associated with this functionality.


Requirements Relating to Search & Discovery

NSDL Registry
  1. External users should be able to:
    • Search the Registry to discover:
      • Schemas, including those available in associated registries (Description)
      • Relationships between schema elements in available schemas—intra-schema relationships (Resource)
        • Relationships between the term of interest and other terms are a function of contextual browse
      • Available vocabularies, based on topical coverage, owning organization and purpose (Description)
      • Vocabulary terms: by preferred term, broader/narrower relationships—inter-schema relationships (Resource)
        • Relationships between the term of interest and other terms are a function of contextual browse
      • Keyword searches on concept and element description texts (Resource)
    • Searches should be filterable by:
      • Organization
      • Status
      • Usage
  2. Search result display options should include:
    • WordNet style tree display, with links
    • Browse result set in visually oriented display (Naomi's browse?)
    • Rank order by usage

Link to Documentation

Requirements Relating to Data Entry

NSDL Registry

Submitting, Creating and Editing Schemas, Schemes and Application Profiles

  1. Add Organization description
  2. Edit/Update Organization description
  3. Deprecate Organization description
  4. Add Element Set, Vocabulary or Application Profile description
  5. Upload or Create elements, terms or AP specifications
    • If element descriptions, vocabularies, or APs were created in an external tool, and available in approved XML schema, uploaded the set of elements into the registry [Note: Uploaded descriptions subject to validation.]
  6. Edit/Update Element Set, Vocabulary or AP description
  7. Deprecate Element Set, Vocabulary or AP description

Link to Documentation

Requirements Relating to Versioning and History

NSDL Registry

General Assumptions on Versioning

  1. URIs will remain stable so long as the semantics of the term do not change
  2. URIs of individual term values won't contain version information
  3. The Registry must be able to allow people/services to create dependencies on a 'versioned' snapshot of a particular SKOS/OWL representation of a vocabulary and it's relationships
  4. A 'versioned snapshot' must include the version designation (either 'number' or 'date')
  5. Individual values in a vocabulary may be created, updated, or deprecated, but not deleted
  6. Namespaces of vocabulary schemas won't be versioned
  7. Schema name versioning will only change if the version change would break backward compatibility

Versioning has been implemented in the NSDL Registry, see Jon Phipps' Registry Blog post for details.

Link to Documentation

Requirements Relating to Authentication and User Management

NSDL Registry

Although planning documentation for the current NSDL Registry User Management is available, these functions are being re-thought at the present time.

Requirements Relating to Services

NSDL Registry

The NSDL Registry services plan is described fully in this paper, from DC-2006. Basically services are aimed at Vocabulary Owners (management of vocabularies, schemas and APs), and users of various kinds (search, notification, URL resolution, etc).

Use Cases

Use cases

"Two main ways to use a vocabulary: 1) Visible to the user. Can be browsed to find suitable search terms. 2) Behind the scenes: non-preferred terms mapped to preferred terms or synonyms expanded ... can include expansion to broader and narrower terms, or translated terms." -- Mike Taylor on the Becta VMS

"The services offered by a metadata schema registry may cover many different functions, and different metadata schema registries may provide different sets of functions depending on their purpose, scope and context; those functions might include: 1. Disclosure/discovery of information about metadata terms 2. Disclosure/discovery of relationships between metadata terms 3. Mapping or inferencing services based on relationships between terms 4. Verification of the provenance or status of metadata terms 5. Disclosure/discovery of related resources (such as functional aggregations of terms, guidelines for use, bindings for metadata instances, etc)" -- Pete Johnston

General Use Cases

Many general use cases are available on the SKOS Use Cases and Requirements page.

Use Cases Relating to Search & Discovery

Use Cases Relating to Data Entry

NSDL Registry

The NSDL Registry has a number of use cases defined for entering data for Vocabularies, Schemas, and APs. The Vocabularies use cases include the following:

   * 1.1 Use Case 1: A Visitor wishes to register an Organization
   * 1.2 Use Case 2: Maintainer Enters a Full Vocabulary Description
   * 1.3 Use Case 2a: Maintainer Enters a Description of a Top-Level Vocabulary Only
   * 1.4 Use Case 3: Maintainer Registers Terms with a Vocabulary
   * 1.5 Use Case 4: Maintainer Uploads Vocabulary Terms to the Registry
   * 1.6 Use Case 4a: Maintainer Uploads non-Hosted Vocabulary Terms to the Registry
   * 1.7 Use Case 5: Maintainer Adds Information to Registered Term
   * 1.8 Use Case 6: Maintainer Changes Semantics of Term
   * 1.9 Use Case 7: Maintainer Changes Status of Term
   * 1.10 Use Case 8: User registers as a Maintainer associated with a Vocabulary

These are very specific and were created for the purpose of developing the NSDL Registry software.

Use Cases Relating to Versioning and History

Use Cases Relating to Authentication and User Management

Use Cases Relating to Services

Back to DCMI Registry Community Main Page