UKOLN is supported by:

1. Metadata Schema Registries,Metadata Application Profiles,& the Information Environment JISC Development Team, London Monday 18 April 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,bbindings • Support for services to human readers, software agents

3. Data Source Data Source Data Source Data Source MSR

4. 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 • External evaluators (ESYS) • Building on previous work in MEG Registry Project (JISC/Becta) http://www.ukoln.ac.uk/projects/iemsr/

5. 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

6. 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

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

9. 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

10. 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

11. The IEMSR and the IE

12. 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

13. 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”?

14. 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

15. 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)

16. 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

17. 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)

18. 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)

19. IEMSR Project : Progress to Date

20. 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

21. Metadata Application Profiles revisited

22. 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" not necessarily directly comparable • must always take framework into account • Consider DC and LOM….

23. DCMI Abstract Model • DC metadata description as set of statements about a subject resource • Each statement consists of • a reference to a property • a reference to a value • (optionally) a reference to an encoding scheme • All DC "elements" are properties • Compatible with RDF model • Metadata applications typically based on description sets • sets of descriptions of related resources

24. 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")

25. LOM 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

26. LOM Application Profile • Specifies which LOM data elements are used in a class of LOM instances • May • provide additional information on how LOM Data Elements are interpreted in the context of the application • 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

27. DC AP v LOM AP • DC AP describes DC metadata description set • LOM AP describes constraints on LOM tree structure • Subject to constraints in LOM standard • LOM Data Element != DC Element • LOM AP != DC AP

28. The IEMSR Architecture & Tools

29. 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

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

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

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. IEMSR Web Site IEMSRRegistry Server API query results IEMSR Web Site IEMSR Data Creation Tool

40. View Agency

41. Browse Agency list

42. View DCAP

43. Browse Agency list

44. View Agency

45. View Metadata Vocabulary

46. View DCAP

47. Issues, challenges, thoughts

48. 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 • "Validation" of LOM APs • TELCERT project • Centralised v distributed registry services • IEMSR as "semi-distributed" • Reads/indexes data distributed on Web • But single point of provision of service • Distributed model? • W3C work on RDF query languages, protocol

49. Issues, challenges, thoughts • Users of machine-oriented IEMSR interfaces • 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"

50. Metadata Schema Registries,Metadata Application Profiles,& the Information Environment JISC Development Team, London Monday 18 April 2005 Pete Johnston Research Officer, UKOLN UKOLN is supported by: www.bath.ac.uk