On 4 March 2012 21:40, Greenberg, Jane <[log in to unmask]> wrote:
> My sense all along is that the DCAM doesn't need to be presented in-and-only RDF. Perhaps I'm wrong (?). It is conceptual. RDF is but one way.
I think that's the historical origins of DCAM... a fear that DC
shouldn't 'bet the farm' on the success of the RDF project, and that
there could be a syntax-neutral description of the underlying
structure that we care about, distinct from some of the technical
details of W3C's RDF.
However, and not suprisingly given the overlap in people/goals/etc, it
turns out DC's abstract model was pretty close to RDF. There are some
bits of RDF that don't get highlighted in DCAM, and there are themes
in DCAM (e.g. notion of record) that are only partially standardised
over at W3C (e.g. explicit idea of a 'graph', SPARQL named graphs).
Others btw in the RDF community also share DC concern for describing
constraints on the content of specific records (our 'application
profiles'), overlaid on top of basic RDF-like descriptions.
So DCAM is partially an exercise in functional requirements: "What
kinds of descriptions are we interested to exchange, what do all our
various notations share?"; but it's also a bit of a euphemism for, or
re-articulation of, RDF. And there's nothing wrong with that; I tried
similar a while back in the first draft of the old ABC work -
http://www.ilrt.bris.ac.uk/discovery/harmony/docs/abc/abc_draft.html
The risk we've always had by keeping a wary distance from RDF here,
.... that concern that we're backing betamax while VHS (e.g. XML,
JSON, whatever) 'wins' ... this risks reinventing bits of RDF, and not
engaging fully with other trends in the RDF scene like Linked Data.
cheers,
Dan
|