Hi everyone,
> Telecon on Future Directions for DCAM - 2011-12-21 Wed 1100 EST
>
> Chair: Tom
> Expected: Tom, Stuart, Kai, Karen, Jon, Gordon, Corey, Mark
I won't be able to attend, in spite of my interest for the subject. But as I thought I'd be thinking about this anyway, I decided to write down something you may use as input. Feel free to ignore if all this is irrelevant and/or expressed already by others in a better way...
> ----------------------------------------------------------------------
> Questions for discussion - see http://wiki.dublincore.org/index.php/DCAM_Revision
>
> -- What requirement(s) does DCAM address? What is its purpose and audience?
> Can we formulate the purpose in a short statement?
A purpose I could buy now for such endeavour, would be to:
- give a foundation on "modern", semantic web-inspired data modeling, for the metadata practitioners who don't master the concepts.
- seek to tie the new technology on the table to requirements observed in the metadata community.
Apart from such clarifications on the goal, many bits on purpose and audience in the DCAM intro (e.g., on software and schema developers, http://dublincore.org/documents/abstract-model/) still apply, in my opinion.
In fact I agree very much with Pete's words ('providing a "lens" on the RDF model that reflects/captures some of the DCMI community's "traditional" conceptualisations.'), which give inspiration for the next questions:
> -- Should DCAM be based explicitly on RDF, or should it be formulated
> as something more abstract that can be instantiated in RDF?
I think there's no real interest in having have something more abstract than RDF. RDF is already an abstract model, in a way...
Of course you may say that you want to have something that can be ported to non-traditional-RDF environments. But think of it, much of the RDF concepts that DCAM "mirrors" can be fit seamlessly into other approaches.
DCAM should seek to relate systematically to RDF model, *when the required concepts are identical*. In this situation it is still worth documenting these useful concepts--the source (http://www.w3.org/TR/rdf-concepts/) is just too difficult to grasp. It's just that it should be clear to everyone that nothing is being re-invented.
DCAM should not shy away from minting new concepts, when these are needed. I'm thinking of all the named-graphs-like apparatus, even though hopefully RDF will come up with something :-)
The same should apply to the Description Set Profiles constraint language, where most of the difficulty lies. When some constraints can be reflected in RDFS/OWL, then the mapping should be explicit. If not, then don't be afraid to keep these constraint expressions in. They're supposed to reflect real requirements, after all.
Documentation-wise, I'm still amazed by the conciseness of the DCAM document. But of course that also explains why people are at odd with it ;-)
I think the main added value of working on that document should be on adding more context, in the form of examples but also some judgement on data representations (e.g, the whole "update your strings into fully-fledged resources when this is possible" thingy).
Note that that there is more RDF available openly to everyone, it shouldn't be difficult to find meaningful examples. Namely, examples that illustrate the concepts of DCAM, but also show what data expressed that way can be useful.
And I trust this is not too much work, in fact...
Best,
Antoine
|