Dear all,
I believe we came out of the DCAM telecon two weeks ago [1] in rough
agreement:
-- that alot of systems are and will continue to be XML-based (or at any
rate "closed-world") but not RDF-aware, creating a need to express data
in XML but still fit with the RDF data model.
-- that the potential value of DCAM lies in its bridging function
between the closed world of data formats and the open world of a
sea of triples.
-- that arriving at DCAM should involve both working backwards from RDF and
working backwards from XML, towards an expression of metadata records, with the
constraints they embody, that is broader and more generic than any specific
encoding technology.
-- that DCAM, to be successful, would need to have both user-facing,
primer-style documentation light on jargon and a more detailed,
implementer-facing technical specification.
-- that the development of DCAM would need to involve an analysis of gaps in
expressivity between existing abstract models, such as RDF, and requirements
for data structures needed in metadata applications (i.e., application
profiles).
-- that DCAM should be developed using a test-driven approach, with
effective examples and test cases that can be expressed in various
concrete syntaxes.
It is less clear that we have agreement about the need or function of RDF
properties and classes for DCAM constructs (such as the dcam:Description,
dcam:DescriptionSet, dcam:inDescriptionSet posited by Kai in [2]) or the extent
of such an RDF vocabulary (e.g., see Mikael's strawman RDF vocabulary for the
"templates" and "constraints" of a Description Set Profile in [3]). Pete and
others have argued that any analogy to SKOS is confusing because SKOS is about
things in the world, whereas DCAM is clearly about things in data structures.
However, Gordon has pointed out that catalogers, for example, actually do think
of certain data constructs, such as "publication statements", as "things in the
world". And there was some support for the idea that a clear "punchline" for
DCAM, along the lines of the one-liner summarizing SKOS in plain language,
would be helpful.
Tom
[1] http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-20120130
[2] http://wiki.dublincore.org/index.php/DCAM_Revision_Tech
[3] http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad
--
Tom Baker <[log in to unmask]>
|