1. UKOLN is supported by: The JISC Information Environment Metadata Schema Registry (IEMSR) Open Forum on Metadata Registries 2005 Rachel Heery Assistant Director R&D, UKOLN www.bath.ac.uk A centre of expertise in digital informaion management

2. IEMSR project background Funded by the UK Joint Information Systems Committee (JISC) One of several shared services for the JISC Information Environment Development partners –ILRT, University of Bristol –UKOLN, University of Bath Associate partners –Becta (British Educational Communications and Technology Agency) –CETIS (Centre for Educational Technology Interoperability Standards)

3. IEMSR distinctive features Emerging from (digital) library tradition Focus on ‘term sets’ (schemas, data element sets) Registers application profiles (how term sets are used locally) as well as term sets Provides client for creation and registration of term sets and application profiles

4. Building on previous work (1) DESIRE Registry http://desire.ukoln.ac.uk/registry/ –Introduced registration of application profiles –Mapped (sample of) terms –Used intermediate vocabulary as interlingua : Basic Semantic Registry –Registry based on SQL SCHEMAS http://www.schemas-forum.org/ –Explored registry as ‘metadata portal’ –Investigated use of RDF schema to express application profiles

5. Building on previous work (2) Meg Registry http://www.ukoln.ac.uk/metadata/education/regproj/ –Introduced a client to create machine readable Dublin Core schemas and application profiles –Introduced RDF as model for registry and use of RDF Vocabulary Description Language (RDF Schema) CORES http://www.cores-eu.net/ –Encouraged a common approach amongst standards makers to declaring their metadata terms –Investigated re-use of metadata terms (‘mixing and matching’) –Further work on client software

6. Motivation for metadata registries Proliferation of metadata –Digital libraries, e-learning, institutional repositories resource description, rights management, preservation –Appropriate metadata element set has to be identified for every new system and project Requirement for –Locating appropriate metadata term set –Ensuring authoritative version –Declaring term set in use –Facilitating evolution of metadata term sets

7. The IEMSR and the IE Effective exchange of metadata essential to interoperability –IE Technical Standards specify "baseline" of Simple DC and/or UK LOM Core –Also exchange of richer metadata between services –Use of metadata "application profiles" Increasing requirement to disclose metadata semantics –Issues of authority, currency, provenance, trust IEMSR as shared/infrastructural service –Machine interface and human web interface

8. IEMSR Provides services based on information about metadata "terms" and related resources Terms defined and managed as sets created for some functional purpose Information provided to registry in the form of machine-readable data sources Services to human readers, software agents

9. IEMSR Schema

10. Functions Disclosure of terms Discovery/selection (and re-use) of terms Discovery of relationships between terms –support for mapping, inferencing Pointers to related resources –guidelines, bindings, transformations… Verification of provenance/status of terms and related resources

11. JISC-funded content providers institutional content providers external content providers brokersaggregatorscataloguesindexes institutional portals subject portals learning management systems media-specific portals end-user desktop/browser presentation fusion provision OpenURL resolvers shared infrastructure authentication/authorisation (Athens) JISC IE service registry institutional preferences services terminology services user preferences services resolvers IEMSR IEMSR: machine to machine use © Andy Powell, UKOLN

12. IEMSR web interface However… metadata exchange in IE currently based on prior co-ordination between human data/service providers IEMSR also as presentational service –Human-readable interface ("unstructured") –Disclose/discover metadata semantics, usage –Promote appropriate reuse of existing solutions –Minimise duplication of effort "Metadata vocabulary portal"

13. JISC-funded content providers institutional content providers external content providers brokersaggregatorscataloguesindexes institutional portals subject portals learning management systems media-specific portals end-user desktop/browser presentation fusion provision OpenURL resolvers shared infrastructure authentication/authorisation (Athens) JISC IE service registry institutional preferences services terminology services user preferences services resolvers IEMSR metadata vocabulary portal IEMSR: web interface © Andy Powell, UKOLN

14. IEMSR: Use Scenarios Content provision service discloses application profile Metadata schema developer explores existing implementation choices, reuses existing components Metadata creation tool accesses machine- readable description of selected application profile Aggregation or presentation service accesses information on application profile

15. Metadata Application Profiles Implementers adopt metadata standards in pragmatic way –optimise for requirements of application Metadata "application profile" as declaration of usage of metadata term set –(re-)use of existing terms –constrained, customised for context of application But metadata standards based on different "meta- models", conceptual frameworks

16. Data modelling Terms defined within the context of particular conceptual models IEMSR designed to handle –Dublin Core –IEEE Learning Object Metadata (LOM) Different underlying models…

17. DCMI Abstract Model DC metadata description as set of statements about a subject resource Each statement –describes a relationship between the subject resource and a second resource (value) –consists of a reference to a property a reference to a value All DC elements (and element refinements) are properties –related by (e.g.) refinement relationships See http://www.dublincore.org/documents/abstract-model/

18. DC Application Profile "A Dublin Core Application Profile (DCAP) is a declaration specifying, at a minimum, which properties are used within a particular metadata application. Optionally, an application profile may describe how those properties have been constrained or adapted for particular purposes" Specifies which properties occur in a description set Does not define new properties –References ("uses") properties already defined elsewhere DCAP as set of "property usages“ See CEN Workshop Agreement 14855 - Dublin Core Application Profile guidelines ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/MMI-DC/cwa14855- 00-2003-Nov.pdf

19. DCAP Property Usage Must reference ("use") exactly one property May provide additional documentation on interpretation of the property May provide an application-specific label May specify obligation for the use of statements referring to the property –(whether it is mandatory, optional, conditional) May specify constraints on the occurrence of statements referring to the property May specify constraints on the permitted values of the property, by specifying that they are instances of specified classes –(i.e. may specify "encoding schemes" for the property)

20. Property DCAP Property Usage usesProperty usesAs EncodingScheme Class hasPropertyUsage Binding Schema isExpressedBy m n 1 1 m 1m 1 administers Agency 1 m Schema Document isDescribedIn 1 Metadata Vocabulary administers 1 m 1 Schema Document isDescribedIn 1 hasTerm 1m 1 m m subjectType m 1

21. LOM Model IEEE LOM standard defines LOM instance as hierarchical tree/container structure LOM data element is component in hierarchy –aggregate LOM data elements –simple LOM data elements –related by containment relationships Each Simple LOM data element is associated with –LOM datatype –Value space Reference to a standard LOM Vocabulary

22. LOM Application Profile "A LOM Application Profile (LOMAP) is a specification of how the information model described by the IEEE LOM standard is adopted to the requirements of a particular metadata application. It specifies which LOM data elements are used, provides information on how they are interpreted in the context of the application, and describes constraints on their occurrence. A LOMAP may specify the use of vocabularies to provide values for LOM data elements where the datatype in the LOM standard permits it, and it may specify taxonomies and classification schemes for use for specified 'purposes' with the LOM Classification data element."

23. LOM Application Profile LOM AP describes constraints on LOM tree structure –Subject to constraints in LOM standard –LOM Data Element not equivalent to DC Property –LOM AP not equivalent to DC AP LOM AP as set of data element usages A data element usage –may provide additional documentation on how the data element is interpreted –may specify obligation for the data element –may specify permitted number of occurrences for the data element

24. LOM LOM aggregate data element LOM simple data element LOM Datatype contains LOM vocabulary contains hasDatatypehasValueSpace LOM Value Space Standard Value Space LOM data element m 1 m m m 1 m 1 1 1 includes Value LOM vocabulary value 1 m 1 Schema Document isDescribedIn 1

25. Taxonomy LOM data element LOM data element usage uses LOMDataElement LOM aggregate data element usage LOM simple data element usage extends ValueSpace Non-LOM vocabulary Classification data element usage hasPurpose uses Taxonomy LOM Classification purpose m 1 m n mm 1 n LOMAP contains m 1 Vocabulary datatype element usage

26. IEMSR project Primary outputs –Models for application profiles (delivered) –Schema creation tool(s) for DC & LOM implementers (in development) –Pilot metadata schema registry service (in development) –Open-source software –Recommendations re policy framework (later….)

27. IEMSR software development Components: Schema desktop client, registry server, registry Web interface. Client and registry server software based on the earlier MEG registry but with much updated data model Client is written in Java and uses the Eclipse SWT+JFace library to provide a natural interface across Microsoft Windows (win32), Linux (X+GTK) and OSX (Carbon) A development log is available from the project web site http://www.ukoln.ac.uk/projects/iemsr/ Open Source software development using SourceForge project

28. IEMSR creation and registration tool

31. Creating a Dublin Core Application Profile

34. Query registry server

35. Select property to use

36. Describe how property used in this DCAP

37. Query again; select again

38. Select encoding scheme

39. Browse Agency list

40. View Agency

41. View DCAP

42. Creating a Learning Object Metadata Application Profile

45. Browse LOM "tree"

46. Select LOM data elements to use

47. Select vocabularies for LOM data elements Not yet implemented, but coming soon!

48. IEMSR project Outcomes –Building consensus on models for DCAP, LOMAP –Improved disclosure/discovery of metadata semantics –Foundation for richer services (mapping, inferencing etc) –Open-source software Benefits –Consistency in creating Application Profiles –Collaboration between LOM and DC communities –Wider access to/re-use of existing solutions –Reduced duplication of developer effort –Improved interoperability

49. IEMSR web site http://www.ukoln.ac.uk/projects/iemsr/ Thank you! Questions?