KMR Group, NADA, KTH (Royal Institute of Technology), Sweden
Eduserv Foundation, UK
|Is Replaced By:||http://dublincore.org/specifications/dublin-core/interoperability-levels/2009-05-01/|
|Status of Document:||This is a DCMI Working Draft; it has been replaced by a DCMI Recommended Resource|
|Description of Document:||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 Working Draft represents work in progress for which the authors seek feedback.|
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. Therefore, this document is presented for discussion purposes only.
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. 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.
"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.
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 "DCAM-interoperable". Over and above the RDF abstract syntax, DCAM provides:
This level corresponds to explicit use of the DCMI Abstract Model in the metadata.
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 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.
Powell, A., M. Nilsson, A. Naeve, P. Johnston, T. Baker. DCMI Abstract Model. DCMI Recommendation.
Nilsson, M. Description Set Profiles: A constraint language for Dublin Core Application Profiles. DCMI Working Draft.
Johnston, P. Expressing Dublin Core metadata using the DC-Text format DCMI Recommended Resource.
Nilsson, M., T. Baker, P. Johnston. The Singapore Framework for Dublin Core Application Profiles. DCMI Recommended Resource.
Weibel, S., J. Kunze, C. Lagoze, M. Wolf. Dublin Core Metadata for Resource Discovery. IETF Request for Comments.
Scholarly Works Application Profile.
< http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile> <!--