On Sun, Jan 29, 2012 at 02:25:11PM -0500, Jon Phipps wrote:
> If we look at the DCAM as the data model component of a DCAP and constrain
> our thinking to the world of the DCAP, then I think that provides us with a
> clearer picture of the DCAM's utility.

Yes, I agree.

>                                        A DCAM's constraints should be able
> to be expressed in any constraint language and it's semantics in any open
> or closed world data model, independent of syntax.

I think you meant to say the constraints of a _DCAP_ (i.e., a specific
application profile) -- not the "constraints" of DCAM itself -- should be
expressible using any constraint language.

I think I can agree, though with some heavy qualification.  As I see it, the
"constructs of DCAM" (whatever they may be) should be usable with multiple
constraint languages, and I think it's fair to say that Mikael's DC-DSP draft
[1] was intended more as one useful constraint language rather than as _the_
one and only.  I'm thinking, for example, of the more complex requirements
Gordon has described for ISBD for expressing "mandatory if applicable" types of
constraints.

I agree with "independent of (concrete implementation) syntax".

I'm not sure what you mean by expressing a DCAP's _semantics_ in any open or
closed world _data_model_.  To me, "semantics" means the formal grammar of
properties and classes, not primarily natural-language definitions.  Such an
underlying grammar can be used to express application profiles based on many
different domain models and using descriptive terms that, while perhaps
expressed in terms of a different "data model", are at least compatible with
the grammar of RDF properties and classes.  But I'm not sure that's what you
mean...

[1] http://dublincore.org/documents/dc-dsp/

> If you look at many of the RDF-validation techniques, by necessity they
> share the closed world assumption of the DCAM.

An interesting insight!  Counter-examples, anyone?

> I have often said that the
> DCAM provides a bridge between data expressed as XML and RDF and it boils
> down to this simple difference in the basic assumptions about the world of
> data defined by the model.

I like the principle.

> The test of the DCAM architecture is its independence of the syntax used to
> create, validate, store, and publish data. DCAM-defined data should be able
> to be published as RDF or XML or JSON without altering the model.

Independence of (concrete) syntax is a feature of RDF too, and RDF is
acquiring support for Named Graphs.  By "DCAM architecture", are you assuming
DCAM plus a constraint language for expressing DCAPs (as you imply above?).

>                                                                   It should
> be independent enough that it may be difficult or even impossible to fully
> express a DCAM in just RDFS/OWL or RIF, or RelaxNG, XML, or Schematron
> schemas.
>
> We could punt and say that you should just use the RDF data model to define
> the data model for a DCAP, but that would be a disservice having come so
> far.

A disservice because the RDF data model (also known as the RDF "abstract
syntax") does not itself have a constraint language for specifying application
profiles?

> What's most needed is further refinement and especially testing of the DCAM
> as an actionable DCAP component. Can we express a DCAM's semantics and
> constraints in RDFS/OWL? In RelaxNG? In DDL? And we have to be able to show
> useful examples.

I agree wholeheartedly with the need for useful examples, and for examples that
use different concrete syntaxes.  I also agree that the very notion of a DCAM
does not make sense independently of a framework for defining application
profiles.

Tom

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