I'm not sure if it's useful/relevant, but a while ago, I did some experiments with mapping DSP constraints into Schematron constraints for the DC-DS XML format
http://efoundations.typepad.com/efoundations/2009/09/experiments-with-dsp-and-schematron.html
to enable XML validation.
It's so long ago I can barely remember the detail, but re-reading it just now, leaving aside the syntax-specific stuff, I think there is a useful point there about the relationship between a description set/graph and a set of constraints which it might be worth highlighting in this discussion:
===
As an aside, it's also worth noting that a single description set may be matched against multiple profiles, depending on the context (or indeed against none: there is no absolute requirement that a description set matches any DSP at all). The same description set may be tested against a fairly permissive set of constraints in one context, and a "tighter" set of constraints in another: the same description set may match the former, and fail to match the latter. To paraphrase James Clark's comments on XML schema [1], "validity" should be treated not as a property of a description set but as a relationship between a description set and a description set profile.
===
[1] http://blog.jclark.com/2007/04/validation-not-necessarily-harmful.html
Pete
________________________________________
From: DCMI Architecture Forum [[log in to unmask]] on behalf of Thomas Baker [[log in to unmask]]
Sent: 22 December 2011 18:48
To: [log in to unmask]
Subject: DCAM examples, patterns, and constraints
In the DCAM telecon report [1]:
> Corey: DCAM can have examples in RDF. It should serve as a bridge between RDF
> and XML models.
...
> Jon: DCAM explicitly describes a domain model. So it works well for
> defining requirements for producing valid data which can then be published
> with appropriate semantics. The technical approach to validating and
> publishing needs to be documented with examples, and the examples might
> explicitly suggest an approach using schema-based validation and OWL-based
> semantics.
...
> Stuart: Not only substance of revision, but form of presentation. DCAM got
> itself into trouble - hard to understand - because it distilled everything
> down, addressed itself to technical people. Those of us who observed the
> development of DCAM saw there were lots of examples. These examples were
> distilled out of the end result. Misses the mark for people who are not
> "initiated" in that kind of specification. Would really hope that we end up
> with a revision of this approach.
One clear result of yesterday's call is that the revised DCAM needs to have
concrete examples. I'm thinking that it might not take many examples simply to
illustrate the constructs of DCAM itself -- e.g., a statement pattern for using
a term from a vocabulary encoding scheme as value, a statement pattern using a
literal value, a statement pattern for linking a value to a separate
Description of the value, etc. Would we need more than five or six?
However, as Jon suggests (above), the value of DCAM lies in providing a
framework for expressing constraints that can be used for schema-based
validation of metadata records. I'm wondering how we can do this without
introducing the notion of a constraint language. Even though Mikael's DSP
specification of March 2008 did not advance beyond the status of Working Draft
[3], we could perhaps use the DSP draft for a few examples, if only in an
Appendix. Karen started to do something like in the DCMI RDA Task Group wiki
in June 2009 [4] -- an example we might follow.
Tom
[1] https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1112&L=dc-architecture&D=0&P=23699
[2] http://dublincore.org/dcmirdataskgroup/apDesigns
[3] http://dublincore.org/documents/dc-dsp/
[4] http://www.isotopicmaps.org/tmcl/
--
Tom Baker <[log in to unmask]>
|