Common requirements
Contents
- 1 DCMI Registry Task Group
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
Requirements Relating to Search & Discovery
NSDL Registry
- 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
- Search the Registry to discover:
- 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
Requirements Relating to Data Entry
NSDL Registry
Submitting, Creating and Editing Schemas, Schemes and Application Profiles
- Add Organization description
- Edit/Update Organization description
- Deprecate Organization description
- Add Element Set, Vocabulary or Application Profile description
- 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.]
- Edit/Update Element Set, Vocabulary or AP description
- Deprecate Element Set, Vocabulary or AP description
Requirements Relating to Versioning and History
NSDL Registry
General Assumptions on Versioning
- URIs will remain stable so long as the semantics of the term do not change
- URIs of individual term values won't contain version information
- 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
- A 'versioned snapshot' must include the version designation (either 'number' or 'date')
- Individual values in a vocabulary may be created, updated, or deprecated, but not deleted
- Namespaces of vocabulary schemas won't be versioned
- 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.
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).