JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  May 2011

DC-ARCHITECTURE May 2011

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

What is the DCMI Abstract Model, and what is its current status?

From:

Thomas Baker <[log in to unmask]>

Reply-To:

DCMI Architecture Forum <[log in to unmask]>

Date:

Tue, 17 May 2011 16:57:11 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (157 lines)

----------------------------------------------------------------------
NOTE: This text has also been posted to the new DCMI wiki as a proposed
answer to a Frequently Asked Question, 
http://wiki.dublincore.org/index.php/FAQ/DCMI_Abstract_Model.  It is 
posted here to stimulate discussion of its interpretation and of its 
conclusions.
----------------------------------------------------------------------

What is the DCMI Abstract Model, and what is its current status?

The DCMI Abstract Model (DCAM) [1] is a specification which defines an abstract
syntax for metadata records that is independent of, but mappable to, a
diversity of concrete implementation syntaxes such as HTML/XHTML, XML, and any
of the concrete syntaxes defined for RDF.  The DCAM was developed as a basis
for defining validatable metadata records, in a variety of popular
implementation syntaxes, whose contents could straightforwardly be exposed as
RDF triples. 

=== A technical summary of DCAM ===

Most of the components of DCAM's abstract syntax correspond unambiguously to
components of the RDF abstract syntax [7].  However, the DCAM and RDF were designed
for different purposes.  Whereas the purpose of RDF is to "describe reality",
the purpose of DCAM is to specify metadata record structures. To do this, DCAM 
defines several grouping constructs not covered by the RDF standards as of 2011,
notably: 

* Description Sets - the basis for "records" describing more than one resource
* Descriptions - sets of statements about a single resource
* DCAM Statements - like an RDF statement with additional context about the 
  statement's value
* Value Surrogates - alternative slots for information describing
  string values versus values identified by URIs or blank nodes

These grouping constructs are used to cluster, at various levels of
granularity, sets of syntactic slots holding the URIs and string literals used in
instance metadata -- the URIs used for identifying described resources, values,
properties, vocabulary encoding schemes, or RDF datatypes, and the literals
used as language tags or text strings -- in short, the components of a metadata
record that can be tested or validated.

The DCMI Abstract Model was designed to be used together with a constraint
language [3] for specifying the contents of application-specific metadata
record formats in a form independent of particular concrete encoding syntaxes,
as exemplified in an application profile [4].  The record formats thus
specified were intended to be implemented using concrete encoding syntaxes. Two
concrete syntaxes for the representation of DCAM description sets were defined:
an HTML/XHTML metadata profile [5] and an XML format [6]. In addition, a
mapping between the DCAM abstract syntax and the RDF abstract syntax was
defined, allowing DCAM to be used with any concrete syntax for RDF [7].

=== History of DCAM ===

The DCMI Abstract Model and its family of related applications [8] were in
active development between 2003 and 2008.  Work on the DCAM was originally
undertaken in response to a proliferation of "Dublin Core" implementations
among which interoperability was problematic due to an uncontrolled diversity
of underlying models and syntaxes, negating many of the potential advantages of
using a common vocabulary.  

RDF, standardized by W3C with a more robust second version in 2004, was
recognized by the DCAM authors as an obvious basis for their abstract model.
At the time, however, RDF was seen by a large part of the Dublin Core community
as a research project -- less as a fundamentally new way of conceptualizing
metadata than as an ordinary XML format, though one perceived as over-complex.
Instead of adopting RDF, therefore, its authors defined the DCAM project as one
of clarifying and formalizing the native-DCMI model of metadata that had
emerged from early Dublin Core workshops [9] in a form that could be aligned
with RDF over time.

By the late 2000s, the technological landscape had significantly changed.  The
idea of Linked Data, introduced in 2006 as a more accessible and focused
variant of the Semantic Web vision of 2000, had acquired significant momentum
-- a trend which validated DCAM's grounding in RDF.  However, new developments
in the mainstream Semantic Web community overlapped with some of the more
innovative aspects of the DCAM approach.  Notable examples include the notion
of a SKOS Concept Scheme in W3C's Simple Knowledge Organization System, which
provided a widely understood near-equivalent to the DCMI-specific notion of a
Vocabulary Encoding Scheme [10]; the renewed effort to clarify the semantics of
Named Graphs, which as of 2011 promises eventually to provide an RDF construct
analogous to the Description Set [11]; and the development by W3C of RDFa, a
specification for embedding RDF metadata unobtrusively into normal Web pages,
which provided an alternative to the DCAM-based HTML/XHTML encoding guidelines
[12,13].

=== Future development of DCAM ===

It is difficult to track the use of freely available specifications once they
are released on the Web, but as of 2010, the DCAM-related specifications, with
the possible exception of specific syntax guidelines, appear not to have been
widely implemented.  Rather than building a bridge from more traditional
metadata communities to the Semantic Web, the Abstract Model seems to have
fallen between two stools -- its use of the Description Set abstraction
perplexing to users more accustomed to metadata specifications defined in terms
of a concrete syntax, and its added layer of DCMI-specific terminology
confusing to users already comfortable with RDF.  

In 2010, DCMI undertook a critical review of the DCAM approach [14].
Discussion of the review at a joint meeting of the DCMI Architecture Forum and
the W3C Library Linked Data Incubator Group at DC-2010 [15] revealed a striking
lack of consensus about the meaning -- and value -- of the DCAM approach.  Some
discussants agreed with its authors in seeing the DCAM as an abstract syntax
for metadata records based on, and thus mappable to, RDF. Others, however, saw
the potential value of DCAM as a "meta-model" describing the components of
metadata descriptions at a high level of abstraction, independently of any
basis in RDF [16].

As written, the DCAM is clearly framed as the former -- i.e., as the basis for
automating the creation of validatable metadata records whose contents can
straightforwardly be exposed as RDF triples.  Attaining such degrees of
interoperability and automation implies a well-defined modeling basis, and the
authors of DCAM saw RDF as the only candidate model with any traction.

Proponents of the "DCAM as meta-model" view, in contrast, felt that the model
had value independently of RDF -- i.e., that the notion of "statements" grouped
into "descriptions" and enclosed within a "description set" are valid in the
absence of RDF's grammar of properties, classes, datatypes, and statements.
Whatever the merits of this latter view, it was clear that to define DCAM as a
meta-model independently of RDF, the base specification would need to be
extensively re-written.

As of 2011, the DCMI Abstract Model retains the status of a DCMI
Recommendation, reflecting the process of public comment periods and revisions
through which it has passed.  However, its authors have moved on to other
projects, and active development of the specification has ceased.  

[Disclaimer: the following paragraph is still under discussion by DCMI.]

In the absence of a strong set of reference implementations, the DCAM should be
viewed as a largely theoretical specification.  Regaining momentum on the DCAM
as a basis for specifying RDF-compatible metadata records would require more
resources -- authors, editors, and implementors with clear requirements -- than
DCMI can currently bring to bear.  Re-casting the DCAM as a meta-model on a
higher level of abstraction, on the other hand, would require equally as much
effort, together with a well-grounded story for the function and value of such
a meta-model in today's metadata landscape.  For now, DCMI has chosen to leave
the specifications in place -- both for their value as historical contributions
and potentially as sources of requirements for future projects -- with the
clarifications offered here.

[1] http://dublincore.org/documents/abstract-model
[2] http://wiki.dublincore.org/index.php/Glossary/DCMI_Abstract_Model
[3] http://wiki.dublincore.org/index.php/Glossary/Description_Set_Profile
[4] http://wiki.dublincore.org/index.php/Glossary/Application_Profile
[5] http://dublincore.org/documents/dc-html/ 
[6] http://dublincore.org/documents/dc-ds-xml/
[7] http://dublincore.org/documents/dc-rdf/
[8] http://wiki.dublincore.org/index.php/Glossary/DCAM_Family_of_Specifications
[9] http://wiki.dublincore.org/index.php/Glossary/Dublin_Core_Grammatical_Principles
[10] http://www.w3.org/TR/skos-reference/
[11] http://w3.org/2011/rdf-wg/
[12] http://www.w3.org/TR/rdfa-syntax/
[13] http://dublincore.org/documents/dc-html/
[14] http://wiki.dublincore.org/index.php/Review_of_DCMI_Abstract_Mode
[15] http://www.w3.org/2005/Incubator/lld/wiki/F2F_Pittsburgh
[16] http://lists.w3.org/Archives/Public/public-lld/2010Oct/0098.html

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

February 2024
January 2024
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
September 2022
August 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
November 2021
October 2021
September 2021
August 2021
July 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
September 2020
August 2020
July 2020
June 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager