On Wed, Feb 01, 2012 at 10:56:19AM -0500, Tom Baker wrote:
> 2012-01-30 DCAM call - 11:00 EST
>
> Attended: TomB (chair), DianeH, StuartS, AaronR, MichaelP, RichardU, CoreyH, GordonD,
> KaiE, JonP, AntoineI, MarkM
> This report: http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-20120130
Here's my attempt to _interpret_ the call. These free paraphrases are meant
to attract correction and clarification...
Kai sees DCAM as a model for describing the constructs in metadata. The
model would be expressed natively as an RDF vocabulary of properties and
classes (e.g., where Description Sets and Descriptions are Named Graphs),
analogously to how the SKOS vocabulary describes thesauri and the FOAF
vocabulary describes people. However, this model would in principle be
usable in contexts that are not RDF-aware -- just as the SKOS model is in
principle usable without RDF.
Jon sees DCAM as a bridge between RDF and XML -- a context for expressing
the semanticss and constraints of an application profile in a generic
manner. One arrives at DCAM by starting from two different ends -- working
backwards from RDF, but also working backwards from XML.
Corey sees the need for a formalized way to express semantics and
constraints that is more generic than XML per se, but validatable like XML
schemas, because alot of systems are and will continue to be XML-based but
not RDF-aware. The need is to express data in XML but still fit with the
RDF data model. This is less about validating RDF per se than about
mapping RDF out to systems that support only XML.
Aaron sees the value of DCAM and DCAP as expression of constraints not just
on one particular XML implementation, but (generically) on a variety of
serializations -- "a format-independent model for defining metadata for a
DCAP" (Jon).
There was general agreement that DCAM should be the point where XML and
RDF meet.
One starting point should be a "gap analysis": what do we want to express
that is not already expressible in RDF? Tom has started such an analysis
with his comparison of the constructs and terminology used in DCAM, DC-TEXT,
and RDF 1.1, with some proposals for DCAM 2.0 (e.g., harmonizing
dcam:memberOf and dcam:VocabularyEncodingScheme with skos:ConceptScheme and
skos:inScheme).
Antoine and Jon argued for a test-driven approach to developing DCAM --
provide examples and test cases in at least RDF and XML. Indeed, just
trying this might be easier than discussing it in the abstract. Testing
should start early in the process.
--
Tom Baker <[log in to unmask]>
|