Metadata Schema Registries in the Partially Semantic Web

Metadata Schema Registries in the Partially Semantic Web: the CORES experience Rachel Heery, Pete Johnston, UKOLN, University of Bath András Micsik, Csaba Fülöp, MTA SZTAKI, Budapest DC-2003, Seattle, Washington, USA 28 September – 2 October, 2003 http: //www. ukoln. ac. uk/

The CORES experience • The CORES project • The CORES registry – The registry & the schema creation tool – The registry data model • The CORES registry in practice http: //www. ukoln. ac. uk/

The CORES project http: //www. ukoln. ac. uk/

The CORES project • Funded within European Commission FP 5 IST Programme • Partners – – Pricewaterhouse. Coopers Luxembourg Fraunhofer Gesellschaft UKOLN, University of Bath MTA SZTAKI, Budapest • To encourage the sharing of metadata semantics – Standards Interoperability Forum – Metadata Schema Registry http: //www. ukoln. ac. uk/

The CORES registry http: //www. ukoln. ac. uk/

What is the CORES metadata schema registry? • Software application that provides access to information on metadata element sets, their constituent elements, and their use • Primarily to support disclosure and discovery, but also reuse • Information provided to registry in the form of machine-readable schemas • Interfaces for human readers and software applications http: //www. ukoln. ac. uk/

What is the CORES metadata schema registry? Schema CORES Registry

The registry data model • Builds on earlier work in DESIRE, SCHEMAS projects • Dublin Core "grammatical principles" – Element refinement – Encoding Scheme – Resource – Property (DC Element or DC Element refinement) – Value may be associated with Encoding Scheme http: //www. ukoln. ac. uk/

The registry data model • The concept of the "application profile" – Metadata elements are defined/managed as members of metadata element sets – Implementers “optimise” their use of metadata elements • May constrain usage of elements in context • May narrow "standard" element semantics • May draw elements from multiple element sets http: //www. ukoln. ac. uk/

Element Set m 1 1 1 m Element Agency m m m Encoding Scheme 0 (Controlled Vocab) Value m m 1 m m m Element Usage m 1 App Profile

The registry software • Software development by – András Micsik & Csaba Fülöp (MTA SZTAKI) • Enhancing MEG Registry project software – Dave Beckett & Damian Steer (ILRT) • Schema creation tool – – Java Swing, Jena RDF toolkit Forms-based authoring Save/reload as RDF/XML "Use" existing Elements by "drag-and-drop" from results of search of registry database – Submit data to registry (HTTP POST) http: //www. ukoln. ac. uk/

CORES Schema Creation Tool Drag Element to create Element Usage in App Profile Search registry for “title” Elements

The registry software • Registry server – Perl/CGI, Redland RDF application framework – Upload/publication API (HTTP POST) – Simple query API (HTTP GET) • Very basic, designed to support Schema Creation Tool – HTML interface • Browse, query, annotate, administer http: //www. ukoln. ac. uk/

CORES Registry HTML interface

The CORES registry in practice http: //www. ukoln. ac. uk/

The CORES registry, August 2003 • Registered – 11 Element Sets (152 Elements) – 86 Encoding Schemes – 9 Application Profiles (254 Element Usages) • Mostly DC-based • Sources – Schemas created using CORES tool – Existing RDFS data published on Web http: //www. ukoln. ac. uk/

Using existing RDFS data • CORES tools built on registry data model – uses RDFS – but also application-specific RDF vocabulary • Schema Creation Tool – does not load "pure" RDFS documents • Registry server – does read/index RDFS data – but requires supplementary data to describe application-specific attributes, relations http: //www. ukoln. ac. uk/

Using existing RDFS data • Use of existing RDFS/RDFVDL data is possible but not straightforward using CORES registry tools http: //www. ukoln. ac. uk/

Providing access to source Schemas • Schema creation tool – creates descriptions of entities in model – stores descriptions as Schema (RDF/XML) – does not assume one-to-one relations • between Element Set and Schema • between Application Profile and Schema – does not create description of Schema itself • Registry server – has no metadata about Schema – does not maintain record of source of data http: //www. ukoln. ac. uk/

Providing access to source Schemas • Registry provides access to descriptions of resources submitted, but does not provide direct access to source Schemas • Suggest adding Schema to model as entity, amend tools to generate/use rdfs: is. Defined. By statements http: //www. ukoln. ac. uk/

Availability of CORES registry server(s) • CORES as fixed-term project – Unable to guarantee long-term availability of current CORES registry service – Schema owners reluctant to invest effort in creating data for registry • Distinction between – Schemas created using the CORES tools – Service currently provided by MTA SZTAKI • Guaranteed by "Persistence Policy" till mid 2004 – The CORES registry software • Available from Sourceforge http: //www. ukoln. ac. uk/

Availability of CORES registry server(s) • Continued availability of Schemas is independent of availability of SZTAKI registry • Other service provider can provide registry server using CORES registry software – Re-index existing Schemas from Web • Data also available to other RDF/RDFS applications – But N. B. Schema Creation Tool uses CORES RDF vocabulary http: //www. ukoln. ac. uk/

Shared models for metadata • Registry based on DC metadata model • But metadata vocabularies may have own (unrelated) metadata model – "Element" != CORES Element/RDF Property • Some metadata vocabularies defined primarily in terms of XML tree structure – XML element != CORES Element/RDF Property • Even where vocabulary has RDF expression, additional effort – e. g. RDFS Class != CORES Encoding Scheme http: //www. ukoln. ac. uk/

Shared models for metadata • May be possible to map from "native" model to CORES model, but – requires element-by-element analysis – different process for every vocabulary – arguably, result of limited value to implementer working only with "native" model • Conversely, registry can not "predict" structural conventions of arbitrary XML encodings – Application Profile metadata includes optional pointer to XML Schema http: //www. ukoln. ac. uk/

Integrity and trust • Basis of Application Profile is reuse of existing Elements, Encoding Schemes – resources defined/published by others in a global space • Expectation that the URI will continue to denote what it denotes at the time of reuse • Requires level of trust – in source/owner of URI – in mediating service (registry) that exposes metadata about that resource http: //www. ukoln. ac. uk/

Conclusions • Registry data model is simplification of complex reality – Good "fit" for DC Application Profiles – More problematic where models diverge • Application-specific RDF vocabulary does limit interoperability – Review in light of recent RDF specs, OWL • Trust issues require work • Shared model is critical, especially where reuse encouraged http: //www. ukoln. ac. uk/

Acknowledgements • UKOLN is funded by Resource: the Council for Museums, Archives and Libraries, the Joint Information Systems Committee (JISC) of the UK higher and further education funding councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based. • http: //www. ukoln. ac. uk/

Metadata Schema Registries in the Partially Semantic Web: the CORES experience Rachel Heery, Pete Johnston, UKOLN, University of Bath András Micsik, Csaba Fülöp, MTA SZTAKI, Budapest DC-2003, Seattle, Washington, USA 28 September – 2 October, 2003 http: //www. ukoln. ac. uk/