Difference between revisions of "NSDL Registry Functional Requirements"

From Metadata-Registry
Jump to: navigation, search
(Creating and editing annotations)
m (Reverted edits by Brianh18 (Brianh18); changed back to last version by Diane)
 
(36 intermediate revisions by 3 users not shown)
Line 5: Line 5:
 
==Administrative Management and Maintenance==
 
==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.
+
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 [http://phoenix.ischool.washington.edu/wiki/index.php/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29#Actors Actors], [http://phoenix.ischool.washington.edu/wiki/index.php/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29#Terms Terms] and [http://phoenix.ischool.washington.edu/wiki/index.php/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29#Vocabulary_and_Member_Term_States_.28Statuses.3F.29 Statuses] for appropriate terminology.
  
 +
===Users===
 
#User Authorization
 
#User Authorization
 
#*Change authorization level for any existing user
 
#*Change authorization level for any existing user
Line 12: Line 13:
 
#*Modify user information
 
#*Modify user information
 
#*Delete users
 
#*Delete users
#Manage Data Verification Processes  
+
 
#*Review and approve all submissions (first year)
+
===Data Handling===
#**System will notify submitters that their data has validated, and is under review
+
#Manage Data Verification Processes
#**System will log submissions and post administrative info to database  
+
#*System queue will categorize routine and problem verification reports according to Organization, Vocabulary and Date for easier triage
#**System will queue submissions for administrator, record actions, prompt completion
+
#*System will allow specification of particular errors for addition to error trapping and handling routines
#**System will identify potential problems for administrative attention (duplication, conflict)
+
#Schema updating
#**System will notify submitter when process is complete
+
#*System will support routine updating of SKOS schema as well as local administrative data schema
#**System will notify agent/responsible entity when administrative changes affect submitted data
+
 
 +
==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===
 +
#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)
 +
 
 +
#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
 +
 
 +
#Notifications to Agent's organizational contact
 +
#*Confirmation of Agent registration and email address [requires response]<br>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
 +
 
 +
#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)
 +
 
 +
#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)
 +
 
 +
#Notifications for Administrators
 +
 
 +
#Error Notifications
 +
#*Validation errors
 +
#*Errors discovered during review processes
 +
#*Mail bounces (to vocabulary owners when mail to maintainers or others listed as contacts fails)
 +
 
 +
#Other Notifications
 +
#*Any registered user can sign up for RSS feeds
 +
 
 +
==Registry Administrator Functions==
 +
#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)
 +
 
 
#Manage Interactions with Users  
 
#Manage Interactions with Users  
 
#*System will integrate HelpDesk functions to assist interactions (second year)
 
#*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.)
 
#**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 within the system
+
#**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 prompt administrator to complete problem solving or pass to another administrator
#Reporting
+
#**System will allow keyword and structured searching of email interactions
#*System will support regular and one-time reporting based on database queries for quality control and statsitical reports
+
 
#*Review and monitor annotations
+
===Reporting===
 +
#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.)
 +
#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=
 
=Requirements for User Functions and Interfaces=
  
==Submitting, Creating and editing schemas using the Registry schema creation tool==
+
Note: See Use Case definitions of [http://phoenix.ischool.washington.edu/wiki/index.php/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29#Actors Actors], [http://phoenix.ischool.washington.edu/wiki/index.php/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29#Terms Terms] and [http://phoenix.ischool.washington.edu/wiki/index.php/NSDL_Registry_Use_Case_Documentation_%28Vocabularies%29#Vocabulary_and_Member_Term_States_.28Statuses.3F.29 Statuses] for appropriate terminology.
  
The tool should allow a user to upload, create, maintain and remove resource descriptions which they own within the NSDL registry.
+
==Submitting, Creating and Editing Schemas==
  
#Add Agency description
+
The tool should allow a user to upload, create, maintain and remove resource descriptions which they own within the NSDL registry.
#*Create description of Agency
+
#*Save description of Agency
+
#*Submit description of Agency to registry
+
 
+
#Edit/Update Agency description
+
#*Open existing description of Agency
+
#*Amend description of Agency
+
#*Save description of Agency
+
#*Re-submit description of Agency to registry
+
 
+
#Remove Agency description
+
#*Open existing description of Agency
+
#*Remove existing description of Agency (Do not permit removal if used in relationships?)
+
  
 +
#Add Organization description
 +
#*Create description of Organization
 +
#*Save description of Organization
 +
#*Submit description of Organization to registry
 +
#Edit/Update Organization description
 +
#*Open existing description of Organization
 +
#*Amend description of Organization
 +
#*Save description of Organization
 +
#*Submit updated description of Organization to registry
 +
#Deprecate Organization description
 +
#*Open existing description of Organization
 +
#*Deprecate existing description of Organization (Do not permit deprecation if used in relationships?)
 
#Add Element Set description
 
#Add Element Set description
 
#*Create description of Element Set
 
#*Create description of Element Set
 
#*Save description of Element Set
 
#*Save description of Element Set
 
#*Submit description of Element Set to registry
 
#*Submit description of Element Set to registry
 
 
#Upload or Create elements
 
#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.]
 
#*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.]
Line 61: Line 135:
 
#*Save element description
 
#*Save element description
 
#*Submit individual descriptions or set to the registry
 
#*Submit individual descriptions or set to the registry
 
 
#Edit/Update Element Set description
 
#Edit/Update Element Set description
 
#*Open existing description of Element Set
 
#*Open existing description of Element Set
Line 69: Line 142:
 
#*For each Element to be removed, remove description of Element (Do not permit removal if Element used in relationships?)
 
#*For each Element to be removed, remove description of Element (Do not permit removal if Element used in relationships?)
 
#*Save description of Element Set
 
#*Save description of Element Set
#*Re-submit description of Element Set to registry [NOTE: we will need to work out a versioning policy for this function]
+
#*Re-submit description of Element Set to registry [NOTE: see [http://phoenix.ischool.washington.edu/wiki/index.php/Versioning Versioning page] for beginnings of versioning policy for this function]
 
+
#Deprecate Element Set description
#Remove Element Set description
+
 
#*Open existing description of Element Set
 
#*Open existing description of Element Set
#*Remove existing description of Elements in Element Set, remove existing description of Element Set (Do not permit removal if any Element used in relationships, or if Element Set used in relationships? Maybe not remove at all, but mark "obsolete"?)
+
#*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?)
  
#Add Encoding Scheme description
+
==Submitting, Creating and editing annotations==
#*Create description of Encoding Scheme
+
#Add commentator description (Shouldn't this be a user registration/authentication function, with some mandated public data and other optional?)
#*For each Value in Encoding Scheme, create description of Value
+
#*Prompt for additional details and permission to expose data on first attempt to create annotation
#*Save description of Encoding Scheme
+
#Edit commentator description
#*Submit description of Encoding Scheme to registry
+
#*Amend description
[NOTE: Wouldn't this and the following be for syntax encoding schemes only, since we'll have a separate stream for vocabulary encoding schemes?]
+
#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
 +
#Edit annotation description
 +
#*Open existing annotation
 +
#*Amend text
 +
#Remove annotation description
 +
#*Delete annotation
  
#Edit/Update Encoding Scheme description
+
==Submitting, Creating and Editing Schemes (Controlled Vocabularies)==
#*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
+
  
#Remove Encoding Scheme description
+
The tool should allow a user to upload, create, maintain and remove Vocabulary and vocabulary term descriptions which they own within the NSDL registry.
#*Open existing description of Encoding Scheme
+
#*Remove existing description of Values in Encoding Scheme (OK because no references), remove existing description of Encoding Scheme (Do not permit removal if Encoding Scheme used in relationships)
+
[NOTE: Need to consider carefully whether anything used in instance data should be removed, and whether a change in status to "obsolete" might be better?]
+
  
 +
#Add Organization description
 +
#*Create description of Organization
 +
#*Save description of Organization
 +
#*Submit description of Organization to registry
 +
#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
 +
#Deprecate Organization description
 +
#*Open existing description of Organization
 +
#*Deprecate existing description of Organization (Do not permit deprecation if used in relationships?)
 +
#Add Vocabulary description
 +
#*Create description of Vocabulary
 +
#*Save description of Vocabulary
 +
#*Submit description of Vocabulary to registry
 +
#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
 +
#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 [http://phoenix.ischool.washington.edu/wiki/index.php/Versioning Versioning page] for beginnings of versioning policy for this function]
 +
#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==
 +
 +
#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===
 
#Add Application Profile description
 
#Add Application Profile description
 
#*Create description of Application Profile
 
#*Create description of Application Profile
Line 101: Line 217:
 
#*Save description of Application Profile
 
#*Save description of Application Profile
 
#*Submit description of Application Profile to registry
 
#*Submit description of Application Profile to registry
 
 
#Edit/Update Application Profile description
 
#Edit/Update Application Profile description
 
#*Open existing description of Application Profile
 
#*Open existing description of Application Profile
Line 109: Line 224:
 
#*For each Element Usage to be removed, remove description of Element Usage (OK because no references)
 
#*For each Element Usage to be removed, remove description of Element Usage (OK because no references)
 
#*Save description of Application Profile
 
#*Save description of Application Profile
#*Re-submit description of application to registry
+
#*Re-submit description of application to registry [NOTE: We'll need an upload option for this section, eventually]
[NOTE: We'll need an upload option for this section, eventually]
+
#Deprecate Application Profile description
 
+
#Remove Application Profile description
+
 
#*Open existing description of Application Profile
 
#*Open existing description of Application Profile
#*Remove existing description of Element Usages in Application Profile, remove existing description of Application Profile (OK because no references)
+
#*Deprecate existing description of Element Usages in Application Profile, deprecate existing description of Application Profile (OK because no references)
[NOTE: This should probably be a status change rather than removal]
+
  
==Submitting, Creating and editing annotations==
+
===Adding Encoding Schemes===
#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
+
  
#Edit commentator description
+
This section is intended for Syntax Encoding Schemes only. For Controlled Vocabulary Schemes, see the section on adding [http://phoenix.ischool.washington.edu/wiki/index.php/NSDL_Registry_Functional_Requirements#Submitting.2C_Creating_and_Editing_Schemes_.28Controlled_Vocabularies.29 Controlled Vocabulary Schemes]
#*Amend description
+
#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
 +
#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
 +
#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)
  
#Add annotation description
+
==Submitting, Creating and Editing Schema Crosswalks==
#*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
+
  
#Edit annotation description
+
=External Service Interactions=
#*Open existing annotation
+
#*Amend text
+
  
#Remove annotation description
+
#Possible external service relationships, with interactions:
#*Delete annotation
+
#*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
  
==Submitting, Creating and Editing Schemes (Controlled Vocabularies)==
+
=External User Interactions=
  
==Submitting, Creating and Editing Application Profiles==
+
Note: Maintainers are considered internal users, and their interactions are described in earlier sections.
  
==Submitting, Creating and Editing Schema Crosswalks==
+
Note:  Currently, search involves two system objects: (1) the description of a schema or scheme (<i>Description</i>); and (2) the schema or scheme resource itself (<i>Resource</i>).  Below we have denoted which object the function is operating on through the designations <i>Description</i> and <i>Resource</i>
 +
 
 +
#External users should be able to:
 +
#*Search the Registry to discover:
 +
#**Schemas, including those available in associated registries (<i>Description</i>)
 +
#**Relationships between schema elements in available schemas&#8212;intra-schema relationships (<i>Resource</i>)
 +
#***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 (<i>Description</i>)
 +
#**Vocabulary terms: by preferred term, broader/narrower relationships&#8212;inter-schema relationships (<i>Resource</i>)
 +
#***Relationships between the term of interest and other terms are a function of contextual browse
 +
#**Keyword searches on concept and element description texts (<i>Resource</i>)
 +
#*Searches should be filterable by:
 +
#**Organization
 +
#**Status
 +
#**Usage
 +
#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=
 +
#SKOS representation of Vocabulary in RDF (at vocabulary and concept levels)
 +
#XML Schema representation

Latest revision as of 08:01, 1 November 2006

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