Difference between revisions of "Common requirements"

From Metadata-Registry
Jump to: navigation, search
(Requirements Relating to Search & Discovery)
(Use Cases)
 
(7 intermediate revisions by one user not shown)
Line 35: Line 35:
 
==== Requirements Relating to Data Entry ====
 
==== Requirements Relating to Data Entry ====
  
 +
===== NSDL Registry =====
 +
 +
<b>Submitting, Creating and Editing Schemas, Schemes and Application Profiles</b>
 +
 +
#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
 +
 +
[http://wiki.metadataregistry.org/NSDL_Registry_Functional_Requirements#Requirements_for_User_Functions_and_Interfaces Link to Documentation]
  
 
==== Requirements Relating to Versioning and History ====
 
==== 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 [http://metadataregistry.org/blog/2008/03/26/timeslices-and-versions/ details].
 +
 +
[http://wiki.metadataregistry.org/Versioning Link to Documentation]
  
 
==== Requirements Relating to Authentication and User Management ====
 
==== Requirements Relating to Authentication and User Management ====
  
 +
===== NSDL Registry =====
 +
 +
Although [http://wiki.metadataregistry.org/NSDL_Registry_Functional_Requirements#User_Registration_and_Authentication 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 ====
 
==== Requirements Relating to Services ====
  
 +
===== NSDL Registry =====
 +
 +
The NSDL Registry services plan is described fully in this [http://hdl.handle.net/1813/9373 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 ===
 +
 +
===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 [http://www.slideshare.net/cetismdrsig/becta-vms Becta VMS]<br/><br/>
 +
 +
"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)" -- [http://www.ariadne.ac.uk/issue43/johnston/ Pete Johnston] <br/> <br/>
 +
 +
==== General Use Cases ====
 +
 +
Many general use cases are available on the [http://www.w3.org/TR/skos-ucr/ SKOS Use Cases and Requirements] page.
  
 
==== Use Cases Relating to Search & Discovery ====
 
==== Use Cases Relating to Search & Discovery ====
Line 51: Line 105:
  
 
==== Use Cases Relating to Data Entry ====
 
==== 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 [http://wiki.metadataregistry.org/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29 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.
 +
 +
----------
  
  

Latest revision as of 07:05, 27 August 2008

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
  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