Title:        Report from public comment period on DCMI Abstract Model
Creator:      Pete Johnston
Identifier:   http://dublincore.org/documents/2007/04/02/abstract-model/comments-received.html
Date:         2007-04-23
Note:         This report replaces an earlier version posted from from 2 to 23
              April 2007, now available at 
              http://dublincore.org/documents/2007/04/02/abstract-model/comments-received-20070402.html.

Report from public comment period on DCMI Abstract Model

Period: 5 February - 5 March 2007

This document summarises the principal comments received during the public comment period on the DCMI Abstract Model (Version 2007-02-05) Proposed Recommendation, a revised version of the current DCMI Recommendation (Version 2005-03-07).

Proposals for moving forward are presented in the sections below.

Literal Values and Non-Literal Values

Emerging in part from discussion of the DCAM and in part from the concurrent discussion of the document proposing the assignment of domains and ranges for DCMI properties, and in particular issues surrounding OWL-DL compatability, it is necessary to distinguish clearly between values that are literals and values that are non-literals.

For example, given the following statement (using DC-Text 2006-05-24) 

Description (
  Statement (
    Property URI ( some:prop )
    ValueString ( "foo" Lang ( en ) )
    )
  )

does that map to the single RDF triple 

_:x some:prop "foo"@en .

or to two RDF triples 

_:x some:prop _:blank .
_:blank rdf:value "foo"@en .

Options available include:

  1. Use knowledge of the range of the property to infer value type

  2. Use knowledge of the value type (either from a statement in a description of the value or from a new statement component used to specify the value type)

  3. Statement carries explicit indication of whether value is literal or non-literal

For option 1, to determine the range of the property, the processor requires that information about each property, either "built-in" or obtained at run-time.

Having obtained a URI for the value type, either from the property range (option 1) or from the description set (option 2), the processor still has to determine whether that URI identifies a subclass of rdfs:Literal, so needs additional information about the class, either "built-in" or obtained at run-time.

Option 3 seems a more scalable and dependable approach, but requires a significant change to the DCAM description model.

Further, if the value is a literal, the statement

Proposals

References

Rich Representations

Various questions were asked about rich representations

It became clear during discussion that representing rich representations usefully requires describing them as resources in their own right, with MIME type, language, encoding, etc. From the one-to-one principle, it therefore follows that they are better treated as separate resources in the model, instead of making them part of a single statement.

Proposals

References

Abstract Syntax

Alistair Miles requested a clearer separation of syntax and semantics and suggested that the DCAM should be replaced by a specification focusing only on describing an abstract syntax for DC metadata, while defining semantics by specifying a mapping to RDF graphs and referring to the RDF Semantics. Further, it was suggested that rules for merging DC description sets should be defined in terms of merging RDF graphs, and inferencing rules for DC description sets should be defined in terms of RDF/S inferencing.

Proposals

References

DCAM and RDF

Several questions related to the relationship between DCAM and RDF, and the representation of specific DCAM constructs using the RDF model.

Proposals

References

URI Comparison

Some questions were raised about how to determine when URIs occurring in DC description sets are treated as equivalent. It should me made clear that the DCAM uses the same rules for comparing URIs as RDF.

Proposals

References

Reference Model/Information Model etc

The term "reference model" is undefined and its use is unclear. Also clarify relationships between DCAM and three models in section 2.

Proposals

References

Editorial changes to several definitions

Some definitions suffer from an element of repetition/circularity, particularly in the use of the words "describe", "described", "description".

Definitions of "has domain" and "has range" should be based on "property/value pair" notion used in resource model.

Proposals

References