On Wed, Feb 01, 2012 at 12:21:49PM -0500, Tom Baker wrote:
> Kai sees DCAM as a model for describing the constructs in metadata. The
> model would be expressed natively as an RDF vocabulary of properties and
> classes (e.g., where Description Sets and Descriptions are Named Graphs),
> analogously to how the SKOS vocabulary describes thesauri and the FOAF
> vocabulary describes people. However, this model would in principle be
> usable in contexts that are not RDF-aware -- just as the SKOS model is in
> principle usable without RDF.
If this is a good summary of Kai's position, I should say that I am in
principle not entirely convinced that we should take the route of declaring an
RDF vocabulary as the basis for DCAM. What would convince me would test cases
demonstrating the utility of this approach. I would however like to point out
that there is a DCMI namespace for DCAM, currently with one class and one
An appendix to the Description Set Profile constraint language draft of 2008,
Mikael provided (without further comment) an "RDF variant"  which used the
hypothetical properties and classes (temporarily parked in the
scratch page at ) such as the following (see full list below):
Again, this RDF variant is an idea which, as far as I know, was never tested
or even seriously discussed on the mailing list.
As a exercise, can someone explain how a hypothetical class:
-- a class perhaps mapped to a Named Graph construct in RDF 1.1 --
would differ from the following equally hypothetical class?
Kai, how does Mikael's RDF variant relate to your idea of an RDF vocabulary for
DCAM? Jon, I understood you to say on the call that DCAM could have some
utility even without DCAP. Where is the boundary between a language of
metadata constructs and a language of constraints?
Properties and classes in a hypothetical DSP namespace (Mikael )
Tom Baker <[log in to unmask]>