Print

Print


On 12/22/11 8:34 PM, Jon Phipps wrote:
>
> On Thu, Dec 22, 2011 at 1:48 PM, Thomas Baker <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>
>     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.
>
>
> In the spirit of keeping the 'specification' as abstract as possible and to avoid introducing yet another formal language, perhaps we could describe the DCAM constraints as concepts (perhaps with a UML expression?) with specific examples from existing constraint grammars in languages like RelaxNG, XML Schema, Schematron, OWL. I think one of the things that made DCAM difficult to implement as an 'abstract' model was that it specifies a formal language and a single expression of that language in XML Schema. I wasn't there, but it seems to have been a desire to make the DCAM model itself machine processable for validity and consistency checking. While this is worthwhile, it might be less important now.


+1. No need to confuse people with yet-another formalism at this stage. Writing human-readable yet precise expression of the constraints, and give examples (OWL, Pete's schematron examples, etc) should to the trick!

Now, what you may want to do is to maintain a separate listing of useful semi-formalized patterns, which appear in the constraints. This could use UML if the min document still use UML, as it is the current DCAM. And if you want to use RDF as a base, then a mixture between "OWL-like" and "whatever-we-need" could still do the trick, as done for the "axioms" in the SKOS Reference (http://www.w3.org/TR/skos-reference/).

Then at the end of the main editorial effort, we could see whether there's a workable way to publish this as an annex/side document. But again, don't make it stand in the path of the main document!

Antoine


>
> It would also be very worthwhile to expand the definition [1] of the connections between the DCAM concepts of 'Descriptions' and (Metadata) Records / (Named) Graphs, 'Statements' and XML Elements / RDF Statements, 'Value Surrogates' and XML Values / RDF property objects, in order to clarify DCAMs role as a bridge between record-bounded and graph-bounded metadata.
>
> Jon
>
> [1] http://wiki.dublincore.org/index.php/FAQ/DCMI_Abstract_Model#A_technical_summary_of_DCAM
>