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]>
|