Interoperability Levels for Dublin Core™ Metadata
KMR Group, NADA, KTH (Royal Institute of Technology), Sweden
Eduserv Foundation, UK
|Description:||This document discusses the design choices involved in designing applications for different types of interoperability. At Level 1, applications use data components with shared natural-language definitions. At Level 2, data is based on the formal-semantic model of the W3C Resource Description Framework. At Level 3, data is structured as Description Sets (records). At Level 4, data content is subject to a shared set of constraints (described in a Description Set Profile). Conformance tests and examples are provided for each level. The authors expect this document to evolve as the trade-offs and benefits of interoperability at different levels are explored and welcome feedback from its readers.|
Table of contents
- Level 1: Shared Term Definitions
- Level 2: Formal Semantic Interoperability
- Level 3: Description Set Syntactic Interoperability
- Level 4: Description Set Profile Interoperability
The evolving assumptions which over the past decade have led from fifteen elements [RFC2413] to the Singapore Framework for Dublin Core™ Application Profiles [DCAP] can be captured in a layered model of interoperability. The model of levels presented here addresses the need felt in many communities to position various projects with various degrees of interoperability with Dublin Core™ but lacking an appropriate terminology.
The intention is to provide a "ladder of interoperability", specifying the choices, costs, and benefits involved in designing applications for increased levels interoperability. This document describes the possible levels of interoperability with Dublin Core™ metadata of a specification (or application). These levels are helpful for determining the scope of a project that wants to be "Dublin Core-compatible" and to set expectations for users of "Dublin Core-compatible" specifications.
The levels come with simple litmus tests that serve as guidelines for determining the level of interoperability. The levels build on each other, so a level-3-conforming specification automatically conforms to level 1 and 2, and a level-4-conforming specification conforms to the previous three. At this point there is no wider consensus on these levels. The authors expect this document to evolve as the trade-offs and benefits of interoperability at different levels are explored and welcome feedback from its readers.
Level 1: Shared term definitions
The fifteen-element Dublin Core™ (as in the NISO, ISO, and IETF standards) provides a vocabulary of concepts with natural-language definitions. Leaving aside considerations of machine-processability ("formal" semantics), such vocabularies provide a basis for sharing meanings within and between groups of people -- an "informal" interoperability which does not require the use of URIs to reference terms, formally specified domains and ranges, or higher-order constructs such as the DCMI Abstract Model [ABSTRACT-MODEL]. For example, the reuse of DCMI term definitions and mappings to DCMI terms provided by IEEE Learning Object Metadata could be seen as providing "informal conformance" with Simple Dublin Core™.
This level corresponds to using the natural language definitions of the Dublin Core™ terms.
- The use of the term URIs is not a requirement - terms may be referenced in any way.
- Conformance with the specified domains and ranges of the terms is not a requirement.
- Conformance with the DCMI Abstract Model is not a requirement.
- Historically speaking, informal interoperability with "Dublin Core™" has meant use of the fifteen elements, though the concept of informal interoperability is applicable in principle to any metadata terms defined in natural language.
- Is there a partial mapping to Simple Dublin Core, defined as "the legacy 15 elements, repeatable, used with literal strings"? If yes, the specification is informally interoperable with Dublin Core™ metadata.
- IEEE LOM reuses the DC term definition and provides a mapping to Simple Dublin Core™.
Level 2: Formal semantic interoperability
"Semantic" interoperability is based on a precise and correct use of the formal RDF semantics embodied in the RDF graph data model and in RDF-based vocabularies such as DCMI Metadata Terms. "Semantics" in this sense does not refer to well-formed natural-language definitions (which is how the word "semantics" has traditionally been used in the Dublin Core™ community). Rather, it refers to formally stated relationships between terms and rules for using such statements to draw automatic conclusions (logical inferences). This includes use (or inferrability) of URIs and conformance with formally specified domains, ranges, and sub-property relations. Regardless of its native encoding format, a specification could be said to be "semantically interoperable" if it were to supply a complete mapping to RDF triples, for example via a GRDDL transform.
This level corresponds to implicit or explicit use of the RDF semantics underlying DCMI terms. Thus, any usage of the terms needs to be precise in its conformance with the RDF model and the domains and ranges of terms.
- While the specification/application need not explicitly encode data using URIs, it must be possible to infer the term URIs.
- Conformance with the specified domains and ranges of the terms is a requirement.
- Conformance with the sub-property semantics of the used properties.
- Conformance with the DCMI Abstract Model is not a requirement.
- Is there a "complete" mapping to RDF that is consistent with the specified domains and ranges of the used terms? If yes, the specification is semantically interoperable with Dublin Core™ metadata.
- All RDF data is by definition semantically interoperable with Dublin Core™ metadata.
- All data with GRDDL transforms to RDF is semantically interoperable with Dublin Core™ metadata.
- Data using the 2008 specification "Expressing Dublin Core™ metadata in XHTML and HTML meta tags" is semantically interoperable with Dublin Core™ metadata.
Level 3: Description Set syntactic interoperability
On top of the unbounded graphs specified by RDF, the DCMI Abstract Model layers the notions of bounded Descriptions and Description Sets, providing a basis for the validation and exchange of metadata records [ABSTRACT-MODEL]. Metadata structured according to the DCMI Abstract Model -- for example, data creating using recent syntax guidelines from DCMI -- could be said to be "DCMI Abstract Model-interoperable". Over and above the RDF abstract syntax, the DCMI Abstract Model provides:
- The notion of a "description set" as a bounded entity with a specific identity -- as in the library- and repository-community notion of a "record" that can be managed.
- The notion of a "description" as a bounded entity with a specific identity, even if the description is embedded in a record.
- An extended model of "statements" as graphs using various combinations of Value URIs, Value Strings, and Vocabulary Encoding Scheme URIs. (The formal notion of Vocabulary Encoding Scheme is specific to the DCMI Abstract Model.)
- Conventions for distinguishing between the "representation" of a described resource and the "identification" of that resource with a URI.
- Conventions for "representing" one single value resource with multiple value strings.
This level corresponds to explicit use of the DCMI Abstract Model in the metadata.
- The metadata must be structured using the DCMI Abstract Model notions of Descriptions and Description Sets.
- The Statements in a Description must use the structure defined by the DCMI Abstract Model.
- Is there a complete mapping to DC-TEXT [DC-TEXT]? If yes, the specification is DCMI Abstract Model-compatible.
- All data using the DCMI Abstract Model-compatible metadata expressions published by DCMI.
Level 4: Description Set Profile interoperability
The specification "Description Set Profiles: A constraint language for Dublin Core™ Application Profiles" [DC-DSP] provides an information model and XML expression of structural constraints on a Description Set. An application such as the Scholarly Works (Eprints) Application Profile can be said to be "Description-Set-Profile-interoperable" if it provides formal constraints on a Description Set that are compatible with those in the Description Set Profile specification.
A related specification, Singapore Framework for Dublin Core™ Application Profiles [DCAP], outlines a package of documentation elements needed in order to present a metadata application for maximum interoperability and reusability -- elements such as Functional Requirements, a Domain Model, and a Description Set Profile covering the complete metadata set.
- Is there a '''complete''' Description Set profile? If yes, the specification is interoperable on the level of the Description Set Profile specification.
- Scholarly Works Application Profile [SWAP]
[ABSTRACT-MODEL] Powell, A., M. Nilsson, A. Naeve, P. Johnston, T. Baker. DCMI Abstract Model. DCMI Recommendation. http://dublincore.org/specifications/dublin-core/abstract-model/2007-06-04/
[DC-DSP] Nilsson, M. Description Set Profiles: A constraint language for Dublin Core™ Application Profiles. DCMI Working Draft. http://dublincore.org/specifications/dublin-core/dc-dsp/2008-03-31/
[DC-TEXT] Johnston, P. Expressing Dublin Core™ metadata using the DC-Text format DCMI Recommended Resource. http://dublincore.org/specifications/dublin-core/dc-text/2007-12-03/
[DCAP] Nilsson, M., T. Baker, P. Johnston. The Singapore Framework for Dublin Core™ Application Profiles. DCMI Recommended Resource. http://dublincore.org/specifications/dublin-core/singapore-framework/2008-01-14//
[RFC2413] Weibel, S., J. Kunze, C. Lagoze, M. Wolf. Dublin Core™ Metadata for Resource Discovery. IETF Request for Comments. < http://www.ietf.org/rfc/rfc2413.txt>
[SWAP] Scholarly Works Application Profile. http://www.ukoln.ac.uk/repositories/digirep/index/SWAP