NSDL Registry Use Case Documentation (Vocabularies)

From Metadata-Registry
Revision as of 17:52, 27 March 2010 by TomJohnson (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Registry Use Cases (Vocabularies)

Use Case 1: A Visitor wishes to register an Organization

Purpose
An NSDL project has a small subject vocabulary that they wish to register and needs to register their organization and at least one Maintainer
Primary Actor
Visitor
Prerequisites
Visitor must be associated with the Organization

Sequence

  1. Visitor accesses the Registry and initiates Organization Registration
  2. Visitor enters basic information about the organization -- Name, address, phone, domain (if available), URL, description, and enters self (and may designate others in addition) as organization contact by including name and email
  3. Visitor submits form and Registry sends confirmation email to all organizational contact(s).
  4. Registry asks if Visitor wishes to register as a Maintainer for that organization
  5. If yes, see Use Case 8
  6. Organization contact(s) responds to confirmation email, verifying email address(es)
  7. Registry assigns PURL to organization and stores organization info in database
  8. Registry notifies Registry Manager(s) that Organization has been added
Result
Organization is registered. Visitor is now a Registered User and an Organization Contact associated with the registered organization.

Use Case 2: Maintainer Enters a Full Vocabulary Description

Purpose
A Maintainer associated with an Organization wishes to enter the description of a Vocabulary into the Registry. This step is necessary before registering specific terms or uploading terms from an extant vocabulary. It is important to note that this use case describes the entry of a description of a vocabulary and not the vocabulary itself.
Primary Actor
Maintainer
Prerequisites
Organization must be registered. Maintainer must be associated with that Organization and logged in

Sequence

  1. Maintainer accesses the Vocabulary Maintenance page and selects 'Describe new Vocabulary'
  2. Registry displays the 'Describe Vocabulary' form, containing a list of Organizations with which Maintainer is associated
  3. Maintainer selects Organization, adds a description of the vocabulary, organization-defined URI for the vocabulary (if exists), and rights information (see note 1)
  4. Maintainer submits form
  5. Registry assigns PURL to vocabulary description, stores vocabulary info in database and sends confirmation email (no response required)
  6. Registry notifies Registry Manager(s) that Vocabulary description has been added
  7. Registry displays a list of other Maintainers associated with this Organization and asks if Maintainer wishes to add them to this Vocabulary and also offers Maintainer the opportunity to Register other Maintainers or add existing Maintainers to this Organization
  8. Maintainer selects from list and/or adds Maintainer registration information for other Maintainers
  9. Registry sends other Maintainers a confirmation email indicating that they have been added to this Vocabulary
  10. Registry offers Maintainer the opportunity to:
    1. Add terms to the new Vocabulary (If yes, see Use Case 3); or
    2. Upload an existing vocabulary encoded in an acceptable syntax (If yes, see Use Case 4-4a); or
    3. Add no vocabulary terms
Result
Vocabulary description is entered into the Registry.

Notes

  1. It might be useful to allow insertion of a full rights text block, a URL of a rights document, or a link to the Creative Commons Rights selection wizard that the MediaWiki setup uses: http://creativecommons.org/technology/web-integration Question (Diane): Does this imply that the rights statement would be attached to terms as well, if/when terms are added?

Use Case 2a: Maintainer Enters a Description of a Top-Level Vocabulary Only

Purpose
A Maintainer associated with an Organization wishes to enter the description of a Vocabulary into the Registry. In this case the Vocabulary has terms available in some form locally but is not yet ready (or may never be ready) to expose their terms to the registry. It is important to note that this use case describes the addition of a description of a vocabulary and not the vocabulary itself.
Primary Actor
Maintainer
Prerequisites
Organization must be registered. Maintainer must be associated with that Organization and logged in

Sequence

  1. Maintainer accesses the Vocabulary Maintenance page and selects 'Describe new Vocabulary'
  2. Registry displays the 'Describe Vocabulary' form, containing a list of Organizations with which Maintainer is associated
  3. Maintainer selects Organization, adds a description of the vocabulary, organization-defined URI for the vocabulary (if exists), and rights information (see note 1 above)
  4. Maintainer submits form
  5. Registry assigns PURL to vocabulary description, stores vocabulary info in database and sends confirmation email (no response required)
  6. Registry notifies Registry Manager(s) that Vocabulary description has been added
  7. Registry displays a list of other Maintainers associated with this Organization and asks if Maintainer wishes to add them to this Vocabulary and also offers Maintainer the opportunity to Register other Maintainers or add existing Maintainers to this Organization
  8. Maintainer selects from list and/or adds Maintainer registration information for other Maintainers
  9. Registry sends other Maintainers a confirmation email indicating that they have been added to this Vocabulary
  10. When queried by Registry to offer Maintainer the opportunity to add terms, Maintainer opts to add no terms.
Result
Vocabulary description is entered into the Registry.

Use Case 3: Maintainer Registers Terms with a Vocabulary

Purpose
The Maintainer of a Vocabulary wishes to add specific terms to a Vocabulary hosted in the registry. In this case the vocabulary terms are also hosted in the registry.
Primary Actor
Maintainer
Prerequisites
Vocabulary description must be registered. Maintainer must be associated with that Vocabulary and logged in

Sequence

  1. Maintainer accesses "Vocabulary Maintenance' page and selects 'Maintain Vocabulary'
  2. Maintainer selects Vocabulary from a list of vocabulary descriptions with which they are associated
  3. Maintainer adds the required data and some optional data for each term [what data yet to be determined]
  4. Maintainer adds term declaration
  5. Maintainer optionally adds relationships between new term and other existing terms
  6. Registry assigns a permanent term URI (PURL) to each term using the base URI established when the top level vocabulary was registered
  7. Maintainer submits terms
  8. Registry validates terms and when the terms pass validation routines, the terms are stored in the Registry
  9. Registry notifies Registry Manager(s) that terms have been added to a Vocabulary
Result
Hosted terms added to Vocabulary

Use Case 4: Maintainer Uploads Vocabulary Terms to the Registry

Purpose
In this case a Maintainer who has already registered the vocabulary as a whole may contribute individual terms via an upload process, subject to validation of the file. In this case, the intent is that the Registry will be hosting the terms, not reflecting terms hosted elsewhere. Maintenance of terms uploaded in this manner may be via service interaction with the vocabulary owner or manually within the registry.
Primary Actor
Maintainer
Prerequisites
Vocabulary must be registered. Maintainer must be associated with that Vocabulary and logged in

Sequence

  1. Maintainer accesses 'Vocabulary Maintenance' page and selects 'Maintain Vocabulary'
  2. Maintainer selects Vocabulary from a list of Vocabularies with which they are associated
  3. Maintainer chooses the 'upload file' option
  4. Maintainer chooses the file to upload from his/her browser window, and submits the file
  5. If the organization has already assigned URIs for the terms, and included these term URIs in the uploaded file, their URIs will be maintained "as is" in the Registry
  6. If there are no supplied term URIs in the uploaded file, the Registry will generate term URIs based on the URI generated or supplied when the top level vocabulary was registered
  7. The Maintainer (and the Organization Contact for the Organization) receive a validation report from the registry, confirming that required elements are present, and, if no URIs were supplied, that the Registry has generated valid URIs for the terms. The notification includes the caveat that the file must be reviewed by the Registry Manager before being inserted into the registry.
  8. If the file does not validate, the notification includes error messages associated with the process, a link to a FAQ detailing the error messages and possible next steps, and the email of the Registry Manager and/or Vocabulary Editor/Reviewer
  9. The Registry queues the file for the Registry Manager and/or Vocabulary Editor/Reviewer
  10. The Registry Manager submits the final file to the Registry. Notification of this event is sent to the Maintainer and the Organization Contact
Result
The Vocabulary terms are registered. Updates to the Vocabulary terms can be made individually or by uploaded file.

Use Case 4a: Maintainer Uploads non-Hosted Vocabulary Terms to the Registry

Purpose
In this case a Maintainer who has already registered the vocabulary as a whole may contribute individual terms via an upload process, subject to validation of the file. In this case, the terms are hosted and maintained elsewhere, and may only be updated via service interaction with the maintaining organization or manual uploading of replacement files.
Primary Actor
Maintainer
Prerequisites
Vocabulary must be registered. Maintainer must be associated with that Vocabulary and logged in

Sequence

  1. Maintainer accesses 'Vocabulary Maintenance' page and selects 'Maintain Vocabulary'
  2. Maintainer selects Vocabulary from a list of Vocabularies with which they are associated
  3. Maintainer chooses the 'upload file' option
  4. Maintainer chooses the file to upload from his/her browser window, and submits the file
  5. If the organizaion has already assigned URIs for the terms, and included these term URIs in the uploaded file, there URIs will be maintained as is in the Registry
  6. If there are not supplied term URIs in the uploaded file, the Registry will generate term URIs based on the URI generated or supplied when the top level vocabulary was registered
  7. The Maintainer (and the Organization Contact for the Organization) receive a validation report from the registry, confirming that required elements are present and, if no URIs were supplied, that the Registry has generated valid URIs for the terms. The notification includes the caveat that the file must be reviewed by the Registry Manager before being inserted into the registry.
  8. If the file does not validate, the notification includes error messages associated with the process, a link to a FAQ detailing the error messages and possible next steps, and the email of the Registry Manager and/or Vocabulary Editor/Reviewer
  9. The Registry queues the file for the Registry Manager and/or Vocabulary Editor/Reviewer
  10. The Registry Manager submits the final file to the Registry. Notification of this event is sent to the Maintainer and the Organization Contact
Result
The Vocabulary terms are registered. Updates to the Vocabulary terms can be made only via service interaction or manually by uploaded file.

Use Case 5: Maintainer Adds Information to Registered Term

Purpose
A Maintainer who already has vocabulary terms registered comes back to the registry to update the terms.
Primary Actor
Maintainer, Registry Manager
Prerequisites
Must be registered as a Maintainer with the relevant Vocabulary and logged in

Sequence

  1. User searches for the term he/she wishes to update
  2. The Registry associates the user with the Vocabulary, and presents a menu of choices for updating
  3. The user chooses the appropriate task, and is presented with a form
  4. The user completes the form, which sends the update through validation and reports back to the user
  5. The user okays the transaction, and it goes to the queue of the Registry Manager or the Editor/Reviewer
  6. Registry Manager or Editor/Reviewer approves the transaction
Result
Updated term appears in the Registry

Use Case 6: Maintainer Changes Semantics of Term

Purpose
A Maintainer wishes to change the semantics of an existing registered term
Primary Actor
Maintainer
Prerequisites
Must be registered as a Maintainer for the relevant vocabulary and logged in

Sequence

  1. User searches for the term he/she wishes to update
  2. The Registry associates the user with the Vocabulary, and presents a menu of choices for updating
  3. The user chooses the appropriate task, and is presented with a form; the form includes a check box indicating that the term semantics will change with the current transaction
  4. The user supplies a new term name, and new URI
  5. The user completes the form, which sends the update through validation and reports back to the user
  6. The user okays the transaction, and it goes to the queue of the Registry Manager or the Editor/Reviewer
  7. Registry Manager or Editor/Reviewer approves the transaction
Result
'New' term appears in the Registry with a new URI; the old term status changes to 'deprecated'

Use Case 7: Maintainer Changes Status of Term

Purpose
A Maintainer wishes to change the status of an existing registered term
Primary Actor
Maintainer
Prerequisites
Must be registered as a Maintainer for the relevant vocabulary and logged in

Sequence

  1. User searches for the term he/she wishes to update
  2. The Registry associates the user with the Vocabulary, and presents a menu of choices for updating
  3. The user chooses the appropriate task ('Change status'), and is presented with a form with a pull-down list with available statuses
  4. The user chooses a new status and submits the form, sending the update through validation and reporting back to the user
  5. The user okays the transaction, and it goes to the queue of the Registry Manager or the Editor/Reviewer
  6. Registry Manager or Editor/Reviewer approves the transaction
Result
Term appears in the Registry with a different term status


Use Case 8: User registers as a Maintainer associated with a Vocabulary

Purpose
A Registered User wishes to be registered as a Maintainer for an existing Vocabulary
Primary Actor
Registered User
Prerequisites
Must be registered as a user and logged in

Sequence

  1. Registered User initiates Maintainer Registration
  2. Visitor selects Vocabulary from list and submits form.
  3. Registry sends confirmation email to Registered User and notification email to Organization Contact (notification will include information on how to contact the Registry if the Maintainer does not have authorization to assume that role).
  4. Registered User replies to confirmation email and user relationship to vocabulary info is stored in database as confirmed.
Result
Registered User is now a Maintainer associated with a registered Vocabulary.

Example Registries