The NSDL Registry

1. The NSDL Registry Diane Hillmann w Jon Phipps

2. What We’re Doing • Received an NSF grant in Oct. 2006, to: • Register metadata schemas, vocabularies, application profiles for use and re-use by NSDL projects • Support discovery and reuse of vocabularies at all levels • Build generalized functionality able to be used by others • Explore requirements for distributed registry system

4. Where We Are • Functional requirements and specifications complete • Services defined • Framework and technical structure defined • Registration process defined • Versioning issues identified (and approach determined) • URI Assignments specified

5. Functional Requirements • Use cases defined for Schemas, Vocabularies, Application Profiles • Vocabulary use cases most well developed • Basic user functions defined • Registry search and browse • Registration of vocabulary users • Registration of vocabulary owners and developers, top-level vocabularies, vocabulary terms

6. Services Defined • Vocabulary users • Registration as users of particular vocabularies • Notifications of changes and updates to those vocabularies • Vocabulary owners and developers • Statuses defined to support vocabulary development processes • Notifications of registered users • Configurable output mechanisms

7. Technical Framework • Infrastructure • PHP, MySQL • Interfaces • Users and administrators • REST-style web services • Inter-registry data interchange APIs • Outputs • Supports the “Cookbook” • Appropriate responses to machines and browsers

8. URI Assignments • Assignment is an aggregation of: • agentDomain (specified by owner or defaulted to the Registry domain) • vocabularyToken (based on the DC-UB notion of top-level vocabulary identification) • conceptIdentifier (preference for numeric, rather than semantically meaningful) Ex.: http://metadataregistry.org/registry/NSDLEdLevel/1002

9. Vocabulary Encodings extant • Based on need for testing “file upload” • GEM vocabularies • NSDL Education Level and Learning Resource Type (already registered) • KMODDL Voigt vocabulary • Animal Behavior Vocabulary (Lab of Ornithology)

10. Versioning (Basic Level) • Tracking all changes • Primarily for administrative purposes, “diffs” will be available to those with admin privileges • History • Users and maintainers will have access to term changes for vocabularies they use or manage

11. Versioning (Beyond Basics) • Snapshots of defined “versions” • Versioning needs defined by owners • Useful only for some vocabularies, and as a possible transition between development and “cooked” • Some changes to terms defined as “semantically significant” will require new URIs for terms

12. Supporting Vocabulary Quality Review • Defining semantic significance • Yes: changes in hierarchical placement for vocabularies where hierarchy is significant • No: changes in definitions that are primarily cosmetic • Automated validation and error detection • Ex.: duplicate prefLabels, conflict conditions for altLabels and prefLabels, lack of expected reciprocity in relationships, etc.

13. Additional Quality Supports • Assisted error resolution • Notifications of error conditions • Appropriate documentation • Helpdesk functionality • Support for community vocabulary development • Status at the term level • Vocabulary browse with filters

14. Demonstration • User/Agent registration • Top-Level Vocabulary registration • Additions of concepts, and properties • Reciprocality • Readability • Administrative functions

15. From here ... • File upload • adding already encoded vocabularies • Change history and versioning • Notifications • Documentation and help • Interface refinements • User testing

17. After that ... • Metadata Schemas • Test non-hosted interactions • Application Profiles • The Middle Kingdom • Crosswalks • Vocabulary mappings

18. Schemas & APs • Metadata Schemas • DCMI Registry is the basic model • “Recommends” vocabularies but is clearly agnostic about usage • Application profiles • Includes usage information: obligations, constraints, etc. • May link to content standards, guidelines • Registry needs to support both human and machine-readable versions

19. Working Documents • Registry Working Documents • Versioning • http://metadataregistry.org

20. The Metadata Management System • The problem at GEM • GEM is essentially an aggregation, with multiple partners • No “back end” for managing metadata • Multiple methods for collecting data • Manual methodologies for augmentation and transformation • Legacy data requiring updating • New partnerships to incorporate

21. What the MMS does • Provides a cost-effective and efficient method for managing metadata from a variety of sources • Manages data exchange and updating • Rationalizes routine and collection-specific transformations • Provides basis for provision of other services (search, etc.)

22. Broader Applicability • Support aggregation of metadata from institution-specific content “silos” to improve searching (a metasearch strategy) • Simple collection-item structure supports a “digital collection” registry • MMS development includes a “service orchestration” component, allowing automated management of service interactions

23. Overview • Operates as a service registry • Manages information necessary for harvesting and managing data from a particular collection “service” • Information available for update by service itself or by system administrator

25. Harvest Histories • Visible information by harvest, with links to log information • Lists validation checks • Optimized for problem solving by non-technical staff

28. Item Detail • Supports review of individual items within collections • All version of the item, from initial harvest through various transformations, available for viewing • Optimized for problem solving by non-technical staff

30. Individual Metadata Record • Qualified Dublin Core expression • Editable (in theory) but in practice not (would be stepped on by next harvest)

32. Working Documents • http://metadataregistry.org/wiki/index.php/Metadata_Management_System