================================================================ Section 0. Contact and confidentiality ================================================================ Contact e-mail:
Do you mind your use case being made public on the working group website and documents :
================================================================ Section 1. Application ================================================================ In this section we ask you to provide some information about the application for which the vocabulary(ies) and or vocabulary mappings are being used. Please note: -- If your use case does not involve any specific application, but consists rather in the description of a specific vocabulary, skip straight to Section 2. -- If your application makes use of links between different vocabularies, do not forget to fill in Section 3! 1.1. What is the title of the application?
1.2. What is the general purpose of the application? What services does it provide to the end-user?
The NSDL Registry currently provides services to developers/owners and users of controlled vocabularies. The Registry will ultimately handle: 1) Metadata schemas, 2) Application profiles, 3) Crosswalks and mappings, as well as 4) Controlled vocabularies. The Registry is intended to provide a complete development and vocabulary management environment for developers and managers of controlled vocabularies.
Most services will be organized around vocabulary “owners” and vocabulary “users” who register their use of particular vocabularies. Owners will have access to various services: 1) Namespace management and URI resolution, 2) configurable output of vocabulary specification, 3) access to user information and statistics, 4) multi-developer vocabulary development support, 5) inter-vocabulary relationship management. Unregistered users will be able to search and browse vocabularies by SKOS property; registered users will be enabled to do that plus register vocabularies, and register usage of particular vocabularies for the purpose of enabling notifications of change, appropriately configured output, etc.
*1.3. Provide some examples of the functionality of the application. Try to illustrate all of the functionalities in which the vocabulary(ies) and/or vocabulary mappings are involved.
The Registry is in one sense an authoring tool, allowing entry and management of structured data. In another sense it is a URI resolution service, providing mediated access for humans or machines. Because the Registry is strongly service-based, the provision of services supporting the management of standard metadata is a critical part of the functionality.
SKOS is used as the basis for concept registration and management. RDF output is enabled at both the vocabulary/scheme and concept level. We are also planning to enable a two-stage process for asserting strong relationships between concepts in different vocabularies, which will allow owners of each vocabulary to be involved in creating mappings between their respective vocabularies.
We believe that SKOS Mapping is of critical importance to us in order to support this.
1.4. What is the architecture of the application?
The Registry is designed as a set of tightly integrated REST-based web services. It uses PHP, and a MySQL relational database.
What are the main components?
- Owner/agent registration and maintenance.
- User registration and user management services.
- Top-level vocabulary registration and description service.
- Concept and vocabulary versioning and change management services.
- Managed purl-like namespace services.
- Vocabulary change notification and usage registration.
- A SKOS editor that verifies and validates content properties.
- Support for metadata schema vocabulary integration.
Are the components and/or the data distributed across a network, or across the Web?
Across the web
1.5. Briefly describe any special strategy involved in the processing of user actions, e.g. query expansion using the vocabulary structure. 1.6. Are the functionalities associated with the controlled vocabulary(ies) integrated in any way with functionalities provided by other means? (For example, search and browse using a structured vocabulary might be integrated with free-text searching and/or some sort of social bookmarking or recommender system.)
Because we intend to support vocabulary development within the NSDL Registry, we will allow configuration of output based on term status in regard to the development process, so, for instance, output of not-yet-published concepts can be prevented by the owner or the user. As part of this strategy, “cloning” of concepts from one vocabulary into another will be enabled, supporting re-use of relationships and properties.
To support this, we have extended the standard SKOS properties to include a ‘status’ property with a controlled vocabulary of status concepts.
1.7. Any additional information, references and/or hyperlinks.
http://metadataregistry.org [the production Registry]
================================================================ Section 2. Vocabulary(ies) ================================================================ In this section we ask you to provide some information about the vocabulary or vocabularies you would like to be able to represent using SKOS. Please note: -- If you have multiple vocabularies to describe, you may repeat this section for each one individually or you may provide a single description that encompasses all of your vocabularies. -- If your use case describes a generic application of one or more vocabularies and/or vocabulary mappings, you may skip this section. -- If your vocabulary case contains cross-vocabulary links (between the vocabularies you presented or to external vocabularies), please fill in section 3! 2.1. What is the title of the vocabulary? If you're describing multiple vocabularies, please provide as many titles as you can.
The NSDL Registry currently supports all the GEM (Gateway to Educational Materials) vocabularies and the NSDL (National Science Digital Library) vocabularies, as well as internal vocabularies used for the registration and management processes. Other vocabularies, most associated with the NSDL Projects, will also be added within the next six months. For a list of the current supported vocabularies, see: http://metadataregistry.org/vocabulary/list.html.
The Registry is designed to support several hundred vocabularies.
2.2. Briefly describe the general characteristics of the vocabulary, e.g. scope, size...
Registered vocabularies vary greatly in size, from a few concepts to several hundred. We expect several very large vocabularies (10,000+ concepts) to be registered.
2.3. In which language(s) is the vocabulary provided? In the case of partial translations, how complete are these?
Currently only monolingual vocabularies/schemes are supported, but relationships may be created between related multilingual concepts in multiple schemes.
*2.4. Please provide below some extracts from the vocabulary. Use the layout or presentation format that you would normally provide for the users of the vocabulary. Please ensure that the extracts you provide illustrate all of the features of the vocabulary.
Below is a link to an RDF representation in SKOS of one of the registered vocabularies. RDF: http://metadataregistry.org/uri/NSDLEdLvl.rdf
2.5. Describe the structure of the vocabulary. What are the main building blocks? What types of relationship are used? If you can, provide examples by referring to the extracts given in paragraph 2.4. 2.6. Is a machine-readable representation of the vocabulary already available (e.g. as an XML document)? If so, we would be grateful if you could provide some example data or point us to a hyperlink.
Below is a link to different representations in SKOS of one of the registered vocabularies.
XML Schema: http://metadataregistry.org/uri/NSDLEdLvl.xsd
And a representation in HTML and RDF of a single concept:
Content negotiation is performed to resolve the served format when the URI is requested without an extension:
2.7. Are any software applications used to create and/or maintain the vocabulary? Are there any features which these software applications currently lack which are required by your use case? 2.8. If a database application is used to store and/or manage the vocabulary, how is the database structured? Illustration by means of some table sample is welcome. 2.9. Were any published standards, textbooks or written guidelines followed during the design and construction of the vocabulary? Did you decide to diverge from their recommendations in any way, and if so, how and why? 2.10. How are changes to the vocabulary managed?
Currently there is no change management in the Registry, but the next version (due very soon) will incorporate most of the Use Cases described here: http://metadataregistry.org/wiki/index.php/SKOS_Concept_History_Management
2.11. Any additional information, references and/or hyperlinks. ================================================================ Section 3. Vocabulary Mappings ================================================================ In this section we ask you to provide some information about the mappings or links between vocabularies you would like to be able to represent using SKOS. Please note: -- If your use case does not involve vocabulary mappings or links, you may skip this section! 3.1. Which vocabularies are you linking/mapping from/to?
Potentially any of the vocabularies registered can be mapped to other vocabularies. At present we don’t have enough registered vocabularies for that capability to be activated, but we do support concept-to-concept relationship mapping between concepts in different vocabularies.
*3.2. Please provide below some extracts from the mappings or links between the vocabularies. Use the layout or presentation format that you would normally provide for the users of the mappings. Please ensure that the examples you provide illustrate all of the different types of mapping or link. 3.3. Describe the different types of mapping used, with reference to the examples given in paragraph 3.2. 3.4. Any additional information, references and/or hyperlinks.