NSDL Registry Functional Requirements

From Metadata-Registry
Revision as of 07:01, 1 November 2006 by Jon (Talk | contribs)

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

Requirements for Administrative Functions and Interfaces

User Registration and Authentication

Administrative Management and Maintenance

Administrators of the Registry are a special class of user, authorized to perform all regular user tasks, as well as higher level tasks accomplished only by administrators. All functions described below are in addition to the user functions described elsewhere. Functionality will be phased from Year 1 to Year 2 of the project, with some tasks done manually in the first year, eith additional automation introduced the second year. See Use Case definitions of Actors, Terms and Statuses for appropriate terminology.

Users

  1. User Authorization
    • Change authorization level for any existing user
    • Add new users for any agent/responsible entity
    • Modify user information
    • Delete users

Data Handling

  1. Manage Data Verification Processes
    • System queue will categorize routine and problem verification reports according to Organization, Vocabulary and Date for easier triage
    • System will allow specification of particular errors for addition to error trapping and handling routines
  2. Schema updating
    • System will support routine updating of SKOS schema as well as local administrative data schema

Notifications

Data elements included in all notifications

    • Date/time of notification
    • Date/time of notified activity
    • Name/email of agent initiating activity
    • Contact for questions
    • Basic explanatory text about the registry
    • Link to help text (specific section based on notification type)

Specific notifications

  1. Notifications for Registry Users
    • Confirmation of email address [requires response]
      • What the registry allows this person to do, based on his/her role (or link to text in help system)
  1. Notifications to Agent Admins
    • Notification of successful agent registration (with next steps)
    • Notification of changes to Agent data
    • Notification of Vocabulary registration
    • Notification of changes to Vocabulary registration data, properties and concepts
    • Notification of addition/removal of Vocabulary Maintainer
    • Notification of addition/removal of Agent contact
  1. Notifications to Agent's organizational contact
    • Confirmation of Agent registration and email address [requires response]
      Note: email domain of organizational contact MUST be the same as the registered organizaion's domain, which must be a resolvable domain
    • Notification of changes affecting submitted data (Vocabulary, properties, concepts), whether made by Registry Administrator or Agent Admin
  1. Notifications for Concept Registration
    • For submitted files
      • Confirmation that data has validated, and is under review
      • Confirmation that data has been accepted, with links to the data itself
    • For information entered via user interface
      • User will receive immediate confirmation during input session of successfully entered data, or errors
      • Organizational contact for vocabulary owner will receive aggregated notification of additions and changes, at daily intervals (at some point may make intervals configurable)
      • User will receive aggregated notification of additions and changes, either at logout or at daily intervals (at some point may make intervals configurable)
  1. Notifications for Vocabulary Users
    • Additions and changes to vocabularies (at top-level and concept-level) for which they are registered users
    • [Optional] Notification of newly registered vocabularies -- all or selected communities (tags)
  1. Notifications for Administrators
  1. Error Notifications
    • Validation errors
    • Errors discovered during review processes
    • Mail bounces (to vocabulary owners when mail to maintainers or others listed as contacts fails)
  1. Other Notifications
    • Any registered user can sign up for RSS feeds

Registry Administrator Functions

  1. Review and approve all submissions (first year)
    • System will log submissions and post administrative info and transactions to database
    • System will queue submissions for administrator, record actions, prompt completion
    • System will identify potential problems for priority administrative attention (duplication, conflict)
  1. Manage Interactions with Users
    • System will integrate HelpDesk functions to assist interactions (second year)
      • Submission problems will be identified and automatically entered at the time of submission (Incomplete submissions, repeated errors, etc.)
      • Email interactions between administrators and submitters will be managed and tracked within the system
      • System will prompt administrator to complete problem solving or pass to another administrator
      • System will allow keyword and structured searching of email interactions

Reporting

  1. System will support regular and real-time reporting based on database queries for statistical reports
    • Activity reports by:
      • Time period (week, month, year, to-date)
      • Organization
      • Vocabulary
      • Maintainer
      • Type (added value, changed value, changed status, uploaded file, slurped file, etc.)
  2. System will support regular and one-time reporting based on database queries for quality control
    • Errors by:
      • Time period (week, month, year, to-date)
      • Organization
      • Vocabulary
      • Maintainer
      • Type (missing data, incorrect data, bad default, file error, validation, etc.)
    • Email interactions, by:
      • Organization
      • Vocabulary
      • Maintainer
      • Error type

Requirements for User Functions and Interfaces

Note: See Use Case definitions of Actors, Terms and Statuses for appropriate terminology.

Submitting, Creating and Editing Schemas

The tool should allow a user to upload, create, maintain and remove resource descriptions which they own within the NSDL registry.

  1. Add Organization description
    • Create description of Organization
    • Save description of Organization
    • Submit description of Organization to registry
  2. Edit/Update Organization description
    • Open existing description of Organization
    • Amend description of Organization
    • Save description of Organization
    • Submit updated description of Organization to registry
  3. Deprecate Organization description
    • Open existing description of Organization
    • Deprecate existing description of Organization (Do not permit deprecation if used in relationships?)
  4. Add Element Set description
    • Create description of Element Set
    • Save description of Element Set
    • Submit description of Element Set to registry
  5. Upload or Create elements
    • If element descriptions 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.]
    • User verifies that upload has completed correctly, and submits the element descriptions to the Registry
    • Alternatively, for each Element in Element Set, create description of Element
    • Save element description
    • Submit individual descriptions or set to the registry
  6. Edit/Update Element Set description
    • Open existing description of Element Set
    • Amend description of Element Set
    • For each Element to be amended, open existing description of Element, amend description of Element
    • For each Element to be added, create description of Element
    • For each Element to be removed, remove description of Element (Do not permit removal if Element used in relationships?)
    • Save description of Element Set
    • Re-submit description of Element Set to registry [NOTE: see Versioning page for beginnings of versioning policy for this function]
  7. Deprecate Element Set description
    • Open existing description of Element Set
    • Deprecate existing description of Elements in Element Set, deprecate existing description of Element Set (Do not permit removal if any Element used in relationships, or if Element Set used in relationships?)

Submitting, Creating and editing annotations

  1. Add commentator description (Shouldn't this be a user registration/authentication function, with some mandated public data and other optional?)
    • Prompt for additional details and permission to expose data on first attempt to create annotation
  2. Edit commentator description
    • Amend description
  3. Add annotation description
    • Click on annotations button
    • Enter details of annotation
    • Specify whether public or private
    • Specify type of annotation (chose from controlled list?)
    • Specify whether it is public or private annotation
  4. Edit annotation description
    • Open existing annotation
    • Amend text
  5. Remove annotation description
    • Delete annotation

Submitting, Creating and Editing Schemes (Controlled Vocabularies)

The tool should allow a user to upload, create, maintain and remove Vocabulary and vocabulary term descriptions which they own within the NSDL registry.

  1. Add Organization description
    • Create description of Organization
    • Save description of Organization
    • Submit description of Organization to registry
  2. Edit/Update Organization description
    • Open existing description of Organization
    • Amend description of Organization
    • Add vocabulary maintainers for an Organization
    • Save description of Organization
    • Submit updated description of Organization to registry
  3. Deprecate Organization description
    • Open existing description of Organization
    • Deprecate existing description of Organization (Do not permit deprecation if used in relationships?)
  4. Add Vocabulary description
    • Create description of Vocabulary
    • Save description of Vocabulary
    • Submit description of Vocabulary to registry
  5. Upload or Create Vocabulary terms
    • If vocabulary terms were created in an external tool, and available in approved XML schema, uploaded the set of terms into the registry [Note: Uploaded terms are subject to validation.]
    • User verifies that upload has completed correctly, and submits the vocabulary terms to the Registry
    • Alternatively, for each Term in a vocabulary, create description of term and optional relationships
    • Save term description and optional relationships
    • Submit individual terms or set of terms to the registry
  6. Edit/Update Vocabulary description
    • Open existing description of Vocabulary
    • Amend description of Vocabulary
    • For each Term to be amended, open existing description of Term, amend description of Term (including term status)
    • For each Term to be added, create description of Term
    • Save description of Term
    • Re-submit description of Term to registry [NOTE: see Versioning page for beginnings of versioning policy for this function]
  7. Deprecate Vocabulary description
    • Open existing description of Vocabulary
    • Deprecate existing description of Terms in Vocabulary, deprecate existing description of Vocabulary (Do not permit removal if any Element used in relationships, or if Element Set used in relationships?) [Note: We might want a "top down" version of this rather than "bottom up" as described here.]

Submitting, Creating and Editing Application Profiles

  1. Submission, Creation and Editing follows the pattern for other functions described earlier, with some exceptions/additions
    • When submitter chooses encoding schemes managed by the Registry, a usage link will be created, allowing:
      • Notification to the vocabulary manager that a community or project is using their vocabulary
      • Notification to the community or project when changes or additions are made to the vocabulary (optional)
    • Source definitions and URIs for elements/properties declared in an application profile must be valid
      • Submitters should get immediate feedback when disparities are discovered, and submission should not be completed until the problem is solved

Sequence of Actions

  1. Add Application Profile description
    • Create description of Application Profile
    • For each Element Usage in Application Profile, create description of Element Usage. Note: a Element Usage does not automatically inherit the Encoding Schemes associated with the used Element. Any relevant Encoding Schemes must be explicitly associated with the Element Usage.
    • Save description of Application Profile
    • Submit description of Application Profile to registry
  2. Edit/Update Application Profile description
    • Open existing description of Application Profile
    • Amend description of Application Profile
    • For each Element Usage to be amended, open existing description of Element Usage, amend description of Element Usage
    • For each Element Usage to be added, create description of Element Usage
    • For each Element Usage to be removed, remove description of Element Usage (OK because no references)
    • Save description of Application Profile
    • Re-submit description of application to registry [NOTE: We'll need an upload option for this section, eventually]
  3. Deprecate Application Profile description
    • Open existing description of Application Profile
    • Deprecate existing description of Element Usages in Application Profile, deprecate existing description of Application Profile (OK because no references)

Adding Encoding Schemes

This section is intended for Syntax Encoding Schemes only. For Controlled Vocabulary Schemes, see the section on adding Controlled Vocabulary Schemes

  1. Add Encoding Scheme description
    • Create description of Encoding Scheme
    • For each Value in Encoding Scheme, create description of Value
    • Save description of Encoding Scheme
    • Submit description of Encoding Scheme to registry
  2. Edit/Update Encoding Scheme description
    • Open existing description of Encoding Scheme
    • Amend description of Encoding Scheme
    • For each Value to be amended, open existing description of Value, amend description of Value
    • For each Value to be added, create description of Value
    • For each Value to be removed, remove description of Value
    • Save description of Encoding Scheme
    • Re-submit description of Encoding Scheme to registry
  3. Deprecate Encoding Scheme description
    • Open existing description of Encoding Scheme
    • Deprecate existing description of Values in Encoding Scheme (OK because no references), deprecate existing description of Encoding Scheme (Do not permit if Encoding Scheme used in relationships)

Submitting, Creating and Editing Schema Crosswalks

External Service Interactions

  1. Possible external service relationships, with interactions:
    • With other Registries:
      • 'Slurp' vocabulary terms for display (but not updating); may be accomplished via web services or harvesting, scheduled or on-demand
      • 'Metasearch'-style federated search of other registry data, for discovery, display, linking, etc. May include some interactions to enable other registries to note 'usage' of vocabularies by NSDL Registry users or relationships between vocabularies held in separate registries
    • With Organizations:
      • Harvest or 'slurp' appropriately encoded vocabularies from non-Registry systems held by Organizations. These interactions can be scheduled, manual on-demand, or initiated by the Organization based on their update transactions
      • Notification of transactions on Organization-owned vocabularies
      • Notification of use of Organization-owned vocabularies by external users, primarily via registration of Application Profiles

External User Interactions

Note: Maintainers are considered internal users, and their interactions are described in earlier sections.

Note: Currently, search involves two system objects: (1) the description of a schema or scheme (Description); and (2) the schema or scheme resource itself (Resource). Below we have denoted which object the function is operating on through the designations Description and Resource

  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

Outputs

  1. SKOS representation of Vocabulary in RDF (at vocabulary and concept levels)
  2. XML Schema representation