UKOLN is supported by:

1. The JISC IE Metadata Schema Registry &Metadata Application Profiles British Library, Boston Spa Tuesday 24 May 2005 Pete Johnston Research Officer, UKOLN UKOLN is supported by: www.bath.ac.uk

2. Metadata Schema Registry • Application that provides services based on information about "metadata terms" (and related resources) • "Metadata term" = "unit of meaning" deployed in metadata descriptions • Functions might include • Disclosure/discovery of information about "terms" • Verification of provenance/status of "terms" • Discovery of relationships between "terms" • support for mapping, inferencing • Pointers to related resources • usage in metadata application profiles, guidelines for use, bindings • Support for services to human readers, software agents

3. IEMSR project • Funded under JISC Shared Services programme, Jan 2004 – July 2005 • UKOLN, University of Bath • ILRT, University of Bristol • CETIS, Becta as "contributing partners" • advice, evaluation, assistance with liaison with users • Building on previous work in MEG Registry Project (JISC/Becta), CORES (European Commission) http://www.ukoln.ac.uk/projects/iemsr/

4. IEMSR project • Primary outputs • Description of requirements • Models for metadata application profiles • Pilot metadata schema registry service • Pilot Web site • Data creation tool(s) for DC & LOM implementers (plus documentation) • Open-source software • Recommendations re policy framework

5. IEMSR project • Outcomes • Consensus on models for DCAP, LOMAP • Improved disclosure/discovery of metadata semantics • Foundation for richer services (mapping, inferencing etc) • Benefits • Consistency in creating APs • Collaboration between LOM and DC communities • Wider access to/re-use of existing solutions • Reduced duplication of developer effort • Improved interoperability between applications

6. IEMSR project: Progress • Investigation of user requirements • CETIS, Becta, • Curriculum Online/Tagging Tool, JORUM • Functional requirements document • Data models for DC AP, LOM AP • RDF binding for models • Registry server • Web site • Initial prototype; tabbed browse • Data Creation Tool • Workshop (March 2004) • Evaluation by ESYS

7. Metadata Application Profiles

8. Metadata Application Profiles • Metadata standards provide sets of "terms", defined to support some function • resource discovery, resource (re)use, preservation etc • Implementers adopt metadata standards in pragmatic way • optimise for requirements of application • Metadata "application profile" as declaration of usage • (re-)use of previously defined terms • customised for context of application • may reference "terms" from multiple sources ("mixing and matching")

9. ApplicationProfile A NamespaceSchema 1 ApplicationProfile B NamespaceSchema 2

10. The trouble with "terms" • "Metadata terms" defined with reference to conceptual frameworks ("meta-models") • Multiple frameworks/meta-models exist • Different metadata standards reference different meta-models/frameworks • possibly incompatible • "Metadata terms" of different types • used in different ways • not necessarily directly comparable • Comparison (match) and combination (mix) must always take framework into account • Consider DC and LOM….

11. 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 • (optionally) a reference to an encoding scheme • All DC "elements" are properties • related by (e.g.) refinement/subproperty relationships • Metadata applications typically based on description sets • sets of descriptions of (related?) resources

12. Description Set Description Statement Resource URI Resource URI Property URI Property URI Value URI Value URI Vocab Enc Scheme URI Vocab Enc Scheme URI Property URI Property URI Value string Value string Syntax Enc Scheme URI Syntax Enc Scheme URI Property URI Property URI Rich representation Rich representation

13. LOM "Abstract Model" • No explicit LOM abstract 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

14. Value Value Value Value Value Value LOM Instance Category Element Element

15. DC AM & LOM AM • DCAM & "LOM AM" describe • the types of terms that are used in metadata descriptions • how those terms are used in combination • how those combinations of terms should be interpreted • But • different types of terms • DC Element ! = LOM Data Element • used in different ways • Statements v documents • interpreted according to different rules • So "reuse" of "terms" across models potentially problematic if models not compatible

16. DC Application Profile • Specifies which properties occur in a class of description sets • Does not define new properties • References ("uses") properties already defined • DCAP as set of "property usages" • May • provide additional documentation on interpretation of the property • provide an application-specific label • specify constraints on the occurrence of statements referring to the property • specify constraints on the permitted values of the property (i.e. "encoding schemes")

17. Examples • OAI-DC (Simple DC) Application Profile • "Simple DC" • 15 properties of DCMES • All optional, all repeatable • Value strings • RDN-DC Application Profile • Additional properties from DC Terms, RDN Terms • Encoding Schemes • RSLP CD • Multiple resource types

18. LOM Application Profile • Specifies which LOM data elements are used in a class of LOM instances • Subject to constraints in LOM standard • May • provide additional information on how LOM Data Elements are interpreted in the context of the application • specify obligation for use • describe constraints on their occurrence • specify the use of vocabularies to provide values for LOM data elements where the datatype in the LOM standard permits • specify taxonomies and classification schemes for use for specified 'purposes' with the LOM Classification data element

19. Examples • UK LOM Core • Usage of IEEE LOM to support disclosure/discovery/access/use of UK learning resources • RDN LTSN LOM Application Profile • Disclosure/discovery/access/use • Record sharing between RDN and LTSN partners over OAI-PMH

20. DC AP v LOM AP • Both describe information models for sets of instances • DC AP describes class of DC metadata description sets • by specifying terms (properties, classes) used • LOM AP describes class of LOM instances • by specifying constraints on LOM tree structure • DC Element != LOM Data Element • DC AP != LOM AP • Applications working across DC and LOM must take into account different meta-models

21. The IEMSR and the IE

22. 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 • Serialised using specified XML bindings • Also exchange of richer/different metadata • use of additional metadata "application profiles" • introduction of new "metadata terms" • Increasing requirement to disclose information about new "metadata terms" • Issues of authority, currency, provenance, trust

23. JISC-funded content providers institutional content providers external content providers authentication/authorisation (Athens) JISC IE service registry user preferences services provision IEMSR brokers aggregators catalogues indexes resolvers fusion institutional preferences services OpenURL resolvers media-specific portals institutional portals subject portals learning management systems terminology services presentation end-user desktop/browser shared infrastructure (based on Andy Powell's JISC IE Architecture diagram)

24. The IEMSR and the IE • IEMSR as shared/infrastructural service • Machine interface(s) ("structured") • However… metadata exchange in IE currently based on prior co-ordination between human data/service providers on metadata formats • typically based on XML rather than on higher-level data models • limited/controlled extensibility? • no “unknown terms”?

25. IEMSR: Use Scenarios • Metadata creation tool accesses machine-readable description of selected application profile • Obligation/occurrence constraints • Human-readable documentation for help info/tool tips • Controlled vocabularies/encoding schemes • Schemas for bindings • Presentation service requires information on selected application profile • What labels to use in display of harvested records • N.B. Application needs prior knowledge of mapping between AP info model and binding

26. JISC-funded content providers institutional content providers external content providers authentication/authorisation (Athens) JISC IE service registry user preferences services provision IEMSR brokers aggregators catalogues indexes resolvers fusion institutional preferences services OpenURL resolvers media-specific portals institutional portals subject portals learning management systems terminology services metadataportal presentation end-user desktop/browser shared infrastructure (based on Andy Powell's JISC IE Architecture diagram)

27. The IEMSR and the IE • Presentational service based on data from IEMSR • Human-readable interface ("unstructured") • "Metadata portal" for the IE • Disclose/discover metadata semantics, usage • Promote appropriate reuse of existing solutions • Minimise duplication of effort

28. IEMSR: Use Scenarios • Content provision service provider discloses application profile • Constructs & publishes description, submits to registry • Metadata schema developer explores/(re-) uses existing implementation choices • Selects terms for reuse in new application profile • Concerns of status, provenance, trust • Researcher surveys existing usage of metadata standards • How terms used in practice (within domain, community, area)

29. The IEMSR Architecture & Tools

30. IEMSR Development • Software development by ILRT • Dave Beckett, Nikki Rogers, Simon Price • RDF used throughout • Registry server • Redland, MySQL, Perl • REST interfaces, supporting SPARQL • redevelop as Java application using Jena? • Web Site • Java J2EE application • Apache Struts: Tiles, Java Beans • Data Creation Tool • Java application, Eclipse SWT+Jface libraries

31. Data Source Data Source Data Source Data Source IEMSRRegistry Server API IEMSR Web Site OtherPresentational Service IEMSR Data Creation Tool Other Data Creation Tool

32. IEMSR Data Creation Tool IEMSRRegistry Server API data response RDFDataSource IEMSR Web Site IEMSR Data Creation Tool

35. Query registry server

36. Select property to use

37. Describe how property used in this DCAP

38. Query again; select again

39. Select encoding scheme

40. IEMSR Web Site IEMSRRegistry Server API query results IEMSR Web Site IEMSR Data Creation Tool

41. View Agency

42. Browse Agency list

43. View DCAP

44. Browse Agency list

45. View Agency

46. View Metadata Vocabulary

47. View DCAP

48. Issues, challenges, thoughts

49. Issues, challenges, thoughts • Complexity of working with multiple meta-models • Not only an issue for IEMSR or AP developers, but for other applications working across LOM and DC metadata • Ongoing discussions between DCMI and IEEE LOM communities • Centralised v distributed registry services • IEMSR as "semi-distributed" • Reads/indexes data distributed on Web • But single point of provision of service • Distributed model?

50. Issues, challenges, thoughts • Users of machine-oriented IEMSR interfaces • demonstrate usefulness as m2m service? • IEMSR and other shared services • IEMSR as component in JISC IE • used in combination with other components, including other shared services • e.g. "which services deploy DCAP D or binding B?" • IEMSR + IESR • Scope/policy issues • which standards/profiles/terms are "in scope"? • authority, status, provenance, trust • "who says what about what"