 |
 |
Looking at the DCAM scratchpad[1] after the call, I think that's an excellent start. Maybe we could do something similar and see if we could map DCAM 2.0 terminology to expressing it in RDFS/OWL and RelaxNG/XMLSchema and do that same kind of gap analysis? I'm sure we can also find examples of metadata instance records from different communities and contexts -- libraries, government, industry, biomed -- that could be used for test modeling and concrete examples. Another thought: If possible, perhaps we should make an effort to express the DCAM in UML at some point? Jon (who would love to volunteer to do some of this but can't possibly afford even a fraction of the time) [1] http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad On Mon, Jan 30, 2012 at 10:22 AM, Thomas Baker <[log in to unmask]> wrote: > 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]> >