Difference between revisions of "NSDL Registry Use Case Documentation"

From Metadata-Registry
Jump to: navigation, search
(NSDL REGISTRY USE CASES)
 
(4 intermediate revisions by one user not shown)
Line 1: Line 1:
=NSDL USE CASES=
+
=NSDL REGISTRY USE CASES=
 
==Use Case 1: Publishing a description of an Element Set==
 
==Use Case 1: Publishing a description of an Element Set==
 
An NSDL project provides a resource discovery service for Web-based educational materials. That service utilizes a simple metadata schema developed specifically for that purpose. The organization wishes to publish this information to the wider community via the NSDL registry.  To publish requires the following steps. The Element Set publisher:
 
An NSDL project provides a resource discovery service for Web-based educational materials. That service utilizes a simple metadata schema developed specifically for that purpose. The organization wishes to publish this information to the wider community via the NSDL registry.  To publish requires the following steps. The Element Set publisher:
Line 41: Line 41:
 
#*Display annotations
 
#*Display annotations
 
#A commentator wants to annotate an element with usage notes and comments regarding a scheme outlining experience gained in using that scheme.
 
#A commentator wants to annotate an element with usage notes and comments regarding a scheme outlining experience gained in using that scheme.
==Creating and editing schemas using the NSDL schema creation tool==
+
 
The tool should allow a user to create, maintain and remove resource descriptions which they own within the NSDL registry.
+
=Use Cases from the SWAD Europe Thesaurus Activity (Edited and augmented with comments)=
#Add Agency description
+
==Use Case 1: Indexing a Web resource for exposure - inclusion - in 'the Semantic Web'==
#*Create description of Agency
+
#A human end-user browses through hierarchical views on to a particular thesaurus or some other KOS in order to select controlled terms that he/she believes best indicate the subject (or some other property) of the Web resource. These terms will then be embedded in the Web resource's metadata.
#*Save description of Agency
+
#*This implies:
#*Submit description of Agency to registry
+
#**Ability to search all terms (including cross-references) from all subject-oriented controlled vocabularies
#Edit/Update Agency description
+
#**Views of search results that ascribe each result to a particular vocabularies
#*Open existing description of Agency
+
#**Ability to 'capture' results (single and multiple) for use within a metadata instance. Presumably the captured result would include the URI of the vocabulary as well as the individual term(s).
#*Amend description of Agency
+
 
#*Save description of Agency
+
==Use Case 2: Indexing a Web resource for the benefit of a specific user community==
#*Re-submit description of Agency to registry
+
#Similar to the previous use case, but where the user is a subject specialist - for example a SOSIG (social sciences) cataloguer.
#Remove Agency description
+
#The user may wish to be offered preferred/non-preferred terms from more than one potential thesaurus - with thesauri entry points for each - plus the ability to browse through each thesaurus from these points. In this sense, the use case is also "finding the right thesaurus".
#*Open existing description of Agency
+
#An advanced version of this scenario might be where a cataloguer wishes to "create my own thesaurus" for a specific purpose (and even share it with other cataloguers) by finding points at which to federate more than one thesaurus, and to then draw up (and save) a subset of the merged thesauri for use in cataloguing.
#*Remove existing description of Agency (Do not permit removal if used in relationships?)
+
#*This implies:
#Add Element Set description
+
#**The ability to characterize thesauri by specialty? Or, alternatively, to rank results of term searches by preponderance of results within particular vocabularies?
#*Create description of Element Set
+
#**The ability to switch from search to browse easily when a relevant target vocabulary is found
#*For each Element in Element Set, create description of Element
+
#**'My Vocabularies' capability seems too advanced for the project at this stage?
#*Save description of Element Set
+
 
#*Submit description of Element Set to registry
+
==Use Case 3: Query support for improved search and browse via a Web search engine==
#Edit/Update Element Set description
+
#By "improved" searching we tend to mean improved query recall (the end-user's search term is expanded with synonyms/partial equivalents).
#*Open existing description of Element Set
+
#By browsing we tend to mean support for the user to narrow down/refine their search term(s) in order to produce greater accuracy/relevancy in search results.
#*Amend description of Element Set
+
#*This implies:
#*For each Element to be amended, open existing description of Element, amend description of Element
+
#**Multiple types of relationship and hierarchy views of search results
#*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?)
+
==Use Case 4: Query support for improved search and browse via some Web Application/tool==
#*Save description of Element Set
+
#Similar to the previous Use Case, but in a specialist community context and via a tool that is tailored to the needs of that community - such as a portal that supports cross-search and browse. #Depending on the success of user interface designs, and of course user requirements, this sort of tool enhancement could take the form of automated query expansion (invisible to the user), or offer the end-user browse options to aid them to refine their search term(s). This sort of support implies mappings across thesauri/KOS. We note that generally when we refer to mapping across vocabularies we might be referring to a range of contexts - from an "open-world" context (e.g. mapping an open blog categorisation scheme to an open web directory) to a more specialist, library-oriented context (mapping across coherent, managed KOS).
#*Re-submit description of Element Set to registry
+
#*This implies:
#Remove Element Set description
+
#**Crosswalking requirements beyond (but similar to?) the schema crosswalking we've already envisioned.
#*Open existing description of Element Set
+
#**Possibly tool to support assertions of relationships across controlled vocabularies, allowing users to build crosswalks? Alternatively use usage data to suggest relationships (to do that we'd need to have some way of capturing use of vocabularies)?
#*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?)
+
 
#Add Encoding Scheme description
+
==Use Case 5: Multilingual image retrieval==
#*Create description of Encoding Scheme
+
#Although visualising images is independent of language, embedded metadata can be expressed in any natural language, so here thesaurus/KOS support can be used to translate end-user image-related queries to other languages. We note that there may be links here to use cases encountered for the Simile project.
#*For each Value in Encoding Scheme, create description of Value
+
#**Note: Should take note and be aware of image and multilingual requirements but probably outside the scope of the current project
#*Save description of Encoding Scheme
+
 
#*Submit description of Encoding Scheme to registry
+
==Use Case 6: Tool to parse a document and suggest metadata==
#Edit/Update Encoding Scheme description
+
#A service could be used to receive a full Web resource (for example blog entries - or items, which are metadata about blog entries). The service could extract appropriate document content in order to speculate (via automation) what it is about and thus suggest thesaurus terms with which to mark it up. (In other words, this is like an extension of a query to a thesaurus service that in effect says: "give me a list of preferred and non-preferred terms in some thesaurus Y matching some submitted keyword").
#*Open existing description of Encoding Scheme
+
#**Note: This might certainly be something that we could work with iVia to prototype?
#*Amend description of Encoding Scheme
+
 
#*For each Value to be amended, open existing description of Value, amend description of Value
+
==Use Case 7: Multilingual support for a specialist community==  
#*For each Value to be added, create description of Value
+
#Similar to the image retrieval Use Case mentioned here, but for a specific community. In this Use Case an end-user may require translation services say for the W3C glossary. This represents a requirement for term mappings across languages in specific contexts where terms used may have specialist meanings not normally otherwise attached to their usage in the course of natural language discourse.
#*For each Value to be removed, remove description of Value
+
#**Note: Out of scope for the current project?
#*Save description of Encoding Scheme
+
 
#*Re-submit description of Encoding Scheme to registry
+
==Use Case 8: Schema mapping support for a specialist community==
#Remove Encoding Scheme description
+
#As addressed to some extent by the HILT terminologies server in 2003, there is a need to support cross-search and cross-browse tools with mapping across the range of schemas used by searchable data provider services on the Web. This is in order to make end-user query expressions more accurate and mappable across target schemas. Portal cross-search tools for example could make good use of such tool support. This level of support applies at the schema "collection level" as opposed to at "item level". The latter is related to subject indexing by data providers at the record level and is a related but independent area, also referred to in this list of Use Cases.
#*Open existing description of Encoding Scheme
+
#*Note: Do we cover most of this in our crosswalking requirements?
#*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)
+
 
#Add Application Profile description
+
==Use Case 9: Searchable representations of UML models used in software development==
#*Create description of Application Profile
+
#*[Note: this one occurred on the list of use cases but was unexplained]
#*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
+
#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
+
#Remove Application Profile description
+
#*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)
+
==Creating and editing annotations==
+
#Add commentator description
+
#*Prompt for details on first attempt to create annotation
+
#Edit commentator description
+
#*Amend description
+
#Add annotation description
+
#*Click on annotations button
+
#*Enter details of annotation
+
#*Specify whether public or private
+
#*Specify type of annotation
+
#*Specify whether it is public or private annotation
+
#Edit annotation description
+
#*Open existing annotation
+
#*Amend text
+
#Remove annotation description
+
#*Delete annotation
+
==Creating and Editing Schemes (Controlled Vocabularies)==
+
==Creating and Editing Schema Crosswalks==
+

Latest revision as of 13:50, 29 August 2005

NSDL REGISTRY USE CASES

Use Case 1: Publishing a description of an Element Set

An NSDL project provides a resource discovery service for Web-based educational materials. That service utilizes a simple metadata schema developed specifically for that purpose. The organization wishes to publish this information to the wider community via the NSDL registry. To publish requires the following steps. The Element Set publisher:

  1. Uses the Schema Creation Tool (SCT) to add Agency description (if not already present)
  2. Submits new Agency description to registry
  3. Uses SCT to add Namespace/Element Set description
  4. Uses SCT to add Element/Term descriptions for Element/Terms in Namespace/Element Set, including association of Element/Term with Encoding Scheme(s) where appropriate
  5. Submits new Namespace/Element Set and Element/Term descriptions to registry
  6. May check results by browsing Namespace/Element Set descriptions via registry Web interface

Use Case 2: Publishing a description of an Application Profile

An NSDL project provides a resource discovery service for Web-based educational materials. That service utilizes a simple metadata schema developed specifically for that purpose. The schema uses a number of Elements drawn from the cross-domain Element Sets of the Dublin Core Metadata Initiative; a domain-specific Element that was created by another portal service for their own schema; and a number of new Elements specific to this service. The organization has developed a number of controlled vocabularies for several of the Elements in this schema; the service also specifies the use of some standardized forms for dates and identifiers within metadata instances. The organization wishes to publish this information to the NSDL community via the registry. In the terms of the registry data model, this organization's schema is an Application Profile. To publish requires the following steps. The Application Profile publisher:

  1. Uses the SCT to add Agency description (if not already present)
  2. Submits new Agency description to registry
  3. Uses tool to add Namespace/Element Set description
  4. Uses tool to add Element/Term descriptions for Element/Terms in Namespace/Element Set, including association of Element/Term with Encoding Scheme(s) where appropriate
  5. Submits new Namespace/Element Set and Element/Term descriptions to Registry
  6. May check results by browsing Namespace/Element Set descriptions via registry Web interface.

Use Case 3: Indexing a standard schema for a Element Set

An international standards body makes schema for their cross-domain Element Set available in RDF/XML on their Web server. NSDL implementers wish to "use" Elements from the Element Set in their Application Profiles. Either the representative of standards body or the registry administrator:

  1. Uses the SCT to add Agency description (if not already present).
  2. Submits new Agency description to registry
  3. Uses the NSDL SCT to add Element Set description (assumes external schema on Web does not contain required data)
  4. Requests registry to read Element descriptions from URL
  5. May uses the NSDL SCT to enhance Element descriptions for registry-specific data (or may leave incomplete)
  6. Submits updated Element descriptions to registry
  7. May check results by browsing Element Set descriptions via registry Web interface

Use Case 4: Exploring Element Usage

A schema developer wishes to survey the usage of the DCMI "audience" element, and particularly the use of any controlled vocabularies to control values of this element.

  1. The developer
  2. Browses Elements via registry Web interface
  3. Displays description of Element "dcterms:audience", which includes pointers to the Encoding Schemes associated with the Element, and pointers to its usage by various Application Profiles
  4. Follows references to Element Usage descriptions, which included descriptions of how implementers have constrained the use of the Element, including the prescription of other Encoding Schemes

Use Case 5: Creating annotations

  1. Schema Creator creates a schema using the NSDL SCT and registers it in NSDL Registry. They then want to annotate the schema with information about the number of implementations, domains in which this schema is deployed, and pointers to user guidelines
    • The schema creator
      • Browses element sets via Registry web interface
      • Displays details of the chosen element set
      • Adds an annotation
  2. A schema creator searches the registry and displays an element set, then is interested in whether this schema is currently being maintained. He browses each annotation associated with the schema, looking in particular at the names of the annotator and associated organization.
    • Display details of chosen element sets
    • Display annotations
  3. A commentator wants to annotate an element with usage notes and comments regarding a scheme outlining experience gained in using that scheme.

Use Cases from the SWAD Europe Thesaurus Activity (Edited and augmented with comments)

Use Case 1: Indexing a Web resource for exposure - inclusion - in 'the Semantic Web'

  1. A human end-user browses through hierarchical views on to a particular thesaurus or some other KOS in order to select controlled terms that he/she believes best indicate the subject (or some other property) of the Web resource. These terms will then be embedded in the Web resource's metadata.
    • This implies:
      • Ability to search all terms (including cross-references) from all subject-oriented controlled vocabularies
      • Views of search results that ascribe each result to a particular vocabularies
      • Ability to 'capture' results (single and multiple) for use within a metadata instance. Presumably the captured result would include the URI of the vocabulary as well as the individual term(s).

Use Case 2: Indexing a Web resource for the benefit of a specific user community

  1. Similar to the previous use case, but where the user is a subject specialist - for example a SOSIG (social sciences) cataloguer.
  2. The user may wish to be offered preferred/non-preferred terms from more than one potential thesaurus - with thesauri entry points for each - plus the ability to browse through each thesaurus from these points. In this sense, the use case is also "finding the right thesaurus".
  3. An advanced version of this scenario might be where a cataloguer wishes to "create my own thesaurus" for a specific purpose (and even share it with other cataloguers) by finding points at which to federate more than one thesaurus, and to then draw up (and save) a subset of the merged thesauri for use in cataloguing.
    • This implies:
      • The ability to characterize thesauri by specialty? Or, alternatively, to rank results of term searches by preponderance of results within particular vocabularies?
      • The ability to switch from search to browse easily when a relevant target vocabulary is found
      • 'My Vocabularies' capability seems too advanced for the project at this stage?

Use Case 3: Query support for improved search and browse via a Web search engine

  1. By "improved" searching we tend to mean improved query recall (the end-user's search term is expanded with synonyms/partial equivalents).
  2. By browsing we tend to mean support for the user to narrow down/refine their search term(s) in order to produce greater accuracy/relevancy in search results.
    • This implies:
      • Multiple types of relationship and hierarchy views of search results

Use Case 4: Query support for improved search and browse via some Web Application/tool

  1. Similar to the previous Use Case, but in a specialist community context and via a tool that is tailored to the needs of that community - such as a portal that supports cross-search and browse. #Depending on the success of user interface designs, and of course user requirements, this sort of tool enhancement could take the form of automated query expansion (invisible to the user), or offer the end-user browse options to aid them to refine their search term(s). This sort of support implies mappings across thesauri/KOS. We note that generally when we refer to mapping across vocabularies we might be referring to a range of contexts - from an "open-world" context (e.g. mapping an open blog categorisation scheme to an open web directory) to a more specialist, library-oriented context (mapping across coherent, managed KOS).
    • This implies:
      • Crosswalking requirements beyond (but similar to?) the schema crosswalking we've already envisioned.
      • Possibly tool to support assertions of relationships across controlled vocabularies, allowing users to build crosswalks? Alternatively use usage data to suggest relationships (to do that we'd need to have some way of capturing use of vocabularies)?

Use Case 5: Multilingual image retrieval

  1. Although visualising images is independent of language, embedded metadata can be expressed in any natural language, so here thesaurus/KOS support can be used to translate end-user image-related queries to other languages. We note that there may be links here to use cases encountered for the Simile project.
      • Note: Should take note and be aware of image and multilingual requirements but probably outside the scope of the current project

Use Case 6: Tool to parse a document and suggest metadata

  1. A service could be used to receive a full Web resource (for example blog entries - or items, which are metadata about blog entries). The service could extract appropriate document content in order to speculate (via automation) what it is about and thus suggest thesaurus terms with which to mark it up. (In other words, this is like an extension of a query to a thesaurus service that in effect says: "give me a list of preferred and non-preferred terms in some thesaurus Y matching some submitted keyword").
      • Note: This might certainly be something that we could work with iVia to prototype?

Use Case 7: Multilingual support for a specialist community

  1. Similar to the image retrieval Use Case mentioned here, but for a specific community. In this Use Case an end-user may require translation services say for the W3C glossary. This represents a requirement for term mappings across languages in specific contexts where terms used may have specialist meanings not normally otherwise attached to their usage in the course of natural language discourse.
      • Note: Out of scope for the current project?

Use Case 8: Schema mapping support for a specialist community

  1. As addressed to some extent by the HILT terminologies server in 2003, there is a need to support cross-search and cross-browse tools with mapping across the range of schemas used by searchable data provider services on the Web. This is in order to make end-user query expressions more accurate and mappable across target schemas. Portal cross-search tools for example could make good use of such tool support. This level of support applies at the schema "collection level" as opposed to at "item level". The latter is related to subject indexing by data providers at the record level and is a related but independent area, also referred to in this list of Use Cases.
    • Note: Do we cover most of this in our crosswalking requirements?

Use Case 9: Searchable representations of UML models used in software development

    • [Note: this one occurred on the list of use cases but was unexplained]