On Tue, Feb 28, 2012 at 02:54:34PM -0500, Richard Urban wrote:
> Tom are you suggesting that Karen's "patterns" for DSPs are a *model* that we
> can follow for coming up with DCAM patterns, or that these *are* DCAM
> patterns?  

On the telecons we seem to roughly agree that the design of DCAM should be
motivated by, and illustrated by, actual examples.  Put another way, if DCAM is
a language for talking about things that are either cannot be expressed -- or
cannot be expressed in plain language -- by RDF (the _model_) alone, then we
should be able to say _what_ DCAM would allow us to express.

As Antoine has suggested, it might be easier simply to start with examples (or
patterns) and work back to abstractions rather than the other way around.

Several types of "patterns" have been put forward - see [1], which includes
patterns of various sorts from DC-RDF, DC-DSP, Mikael, Gordon, Alistair, and
Karen.

> Currently Description Set Profiles seem very oriented towards syntaxes that
> should be used in particular contexts or "applications."  But I find that
> many of the things that DSPs want to do is provide some ontological
> distinctions about the kinds of things described and which properties (and
> classes of values/vocabularies) that should be used to describe them.  This
> seems close to the idea of *interpretations* that Alistair alludes to in
> several of his e-mails and is part of the model-theoretic semantics of
> RDF[1].   

The idea behind DC-DSP [2] is to provide a language for specifying the expected
contents of Description Sets -- statements made, with which properties and
cardinality constraints... -- in a generic way can be compared or matched
against instances of Description Sets -- i.e., against actual metadata records,
in whatever DCAM-conformant syntax they may be expressed.  DC-DSP is really
about trying to express, in an abstract form, syntactically validatable
constraints.

Although DCAM is, in theory, grounded in RDF semantics, DSP is all about
syntactic validation, which to my way of thinking is quite orthogonal to
model-theoretic semantics per se.

[...]

> * "mandatory" would require the specification of some class of resources that
>    universally has some property.  To do this would require a more expressive
>    tool, like OWL.

If you are designing an interpretation of the world, perhaps, but what if you
just want to be able to validate instance data in a closed-world sense -- i.e.,
throw up an error message if a description lacks a statement using a property
that is "mandatory"?

> I'll see if I can come up with a quick categorization of the patterns we have
> so far along these lines.  

A categorization is a good next step!  Note that I have folded the examples
from DC-DSP into [1].

[...]

Tom

[1] http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns
[2] http://dublincore.org/documents/dc-dsp/

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