Hi Kai,

On Sun, Mar 04, 2012 at 03:19:54PM +0100, Kai Eckert wrote:
> I just updated the wiki page with the results of a brainstroming
> session in Dagstuhl[1] last week:
> 
> http://wiki.dublincore.org/index.php/DCAM_Revision_Tech

Pondering this path of turning DCAM elements into a formal RDF vocabulary...

I can see some value of having DCAM "glosses" on RDF structures -- e.g.,
"Description Set" as a gloss for RDF Named Graphs (whatever they end up being
called in RDF 1.1).

However, my preference would be to map DCAM to existing native-RDF properties
and classes whenever possible.  This is already done in DCAM/2007 where it says
that a Syntax Encoding Scheme is an rdfs:Datatype -- full stop.  

Ideally, then, the dcam:DescriptionSet you have penciled into [1] would be
mapped to a class for Named Graph in the upcoming RDF 1.1. (Does anyone here
know if the RDF Working Group is planning to declare classes for types of Named
Graph?)

I would indeed prefer to de-emphasize the only two existing terms in the
current DCAM namespace -- dcam:VocabularyEncodingScheme and dcam:memberOf -- in
favor of the more widely known and understood skos:ConceptScheme and
skos:inScheme.

This is not to say that it wouldn't be useful, in some cases, to have an RDF
representation of DCAM, but I'm thinking of DCAM more as a gloss on an
underlying set of RDF/S (and SKOS) URIs.  If DCAM properties and classes were
intended as equivalents of native-RDF properties and classes, I wonder if
maintaining a parallel set of terms is worth the extra maintenance burden (and
potential confusion).

If DCAM really can be seen as a front-end for RDF properties and classes, could
one not think of its RDF representation as a sort of application profile -- one
that uses RDF (and SKOS) properties and classes directly?

[1] http://wiki.dublincore.org/index.php/DCAM_Revision_Tech

> Main change: The graph container is now the description set,
> descriptions would not be a class in RDF, they are only implicitely
> defined based on the notion of statements with the same subject.

The wiki draft [1] still lists dcam:Description.  An instance is intended
simply to be inferred from the existence of statements with the same subject,
not explicitly declared?

> Interesting question: What happens to the record? Again this seems
> to be a question that relates to similar questions in the RDF
> community: How to distinguish the content from the serialization. It
> would be interesting to keep it somehow, but maybe it will belong
> rather to best-practice than to DCAM.

+1 _not_ to turn the serialization of a Description Set into an instance of a
separate class.  I believe the RDF Working Group is making a similar
distinction, but RDF 1.1 class for a serialization would presumably apply only
to serializations of RDF Named Graphs, whereas the dcam:Record you propose
would include serializations of Description Sets in any one of many different
non-RDF syntaxes.  If I correctly understand, the RDF Working Group
distinguishes three meanings of Named Graphs: mutable, immutable, and
serialized.  I would want DCAM to follow whatever emerges from that discussion,
and I do not believe any of the three proposed types of RDF Named Graphs are
intended as sub-properties of each other as would be the case in dcam:Record
rdfs:subClassOf dcam:DescriptionSet.

Also:

-- I see the DCAM Vocabulary Model as shown in Section 2.3 [1] as mapping
   to RDFS, not SKOS.

-- I still have doubts about whether the Value Surrogate constructs are well
   conceived.  In DCAM/2007, their usefulness lay in capturing two common patterns
   of data elements, held in records, that describe values:

   -- for Non-Literal Value Surrogates: combinations of Value URIs, Vocabulary
      Encoding Scheme URIs, Value Strings, Value String Languages, and 
      Syntax Encoding Scheme URIs.

   -- for Literal Value Surrogates: combinations of Value Strings, Value String 
      Languages, and Syntax Encoding Scheme URIs.

In DCAM/2007, these two "patterns" could automatically be mapped to RDF triples
by following DC-RDF [2] -- but only because DC-RDF made an assumption which
today appears simplistic: that Value Strings in Non-Literal Surrogates would
translate into triples using the predicate rdf:value.  Not only is the use of
rdf:value currently being discouraged, but one might want to use dcterms:title,
foaf:name, skos:prefLabel, or any one of several other predicates to "label"
the object resource.

It does not seem desirable, or even possible, to capture all such possible
usage variants in the form of extensions to DCAM (this would make DCAM
uncontrollably complex!), especially if we assume that notions of best practice
will evolve.  However, it does seem reasonable to try to capture and document a
dozen or two common best-practice patterns that people could copy for their own
use.  The "start from examples" thread in the DCAM discussion points in
this direction.

Could those dozen or two best-practice patterns be usefully captured with
constructs along the lines of the DCAM/2007 Literal and Non-Literal Value
Surrogate?  Maybe so, but I'm thinking we should approach the question through
the examples and not necessarily take this conclusion as given.

Tom

[1] http://dublincore.org/documents/abstract-model/#sect-2
[2] http://dublincore.org/documents/dc-rdf/

-- 
Tom Baker <[log in to unmask]>