Hi Karen,
> Sorry, I realize I wasn't clear. I'm advocating that our own metadata
> (whether DC or some other metadata like foaf) have clear guidance.
> Guidance is at a community level, but we can also define our community
> broadly, as DC has done. DC's RDF makes use of rdf:value, so it should
> be possible to provide guidance about that particular usage, or to
> offer alternatives if that is the intention.
Just to clarify, the use of rdf:value in the DC-RDF document is specifically to express the DCMI Abstract Model's notion of "value string". The DC-RDF document is entirely neutral about the use of any other name/label properties to describe the value. It certainly wasn't the intention to say "use rdf:value, not foaf:name" or "use rdf:value, not rdfs:label".
I think the DCAM notion of "value string" has its roots in DCMI's historical notion of representing things using an "appropriate literal". Now, arguably those notions are even more vaguely specified, than that of rdf:value :) But I think one of the intended uses was close to that sketched by Antoine when he talked about n-ary relations. Particularly relevant here, I think, is DCMI's history of developing "structured literal" syntaxes for representing things like periods and spatial areas. See e.g.
http://dublincore.org/documents/dcmi-box/
http://dublincore.org/documents/dcmi-period/
http://dublincore.org/documents/dcmi-point/
where a single literal may be used to capture several attributes of a thing - to "stand for some bits of data", as Antoine put it - data which (typically in RDF) would, or at least could, be expressed using additional triples (or in DCAM terms, a "description of the value").
> Over at the LLD activity
> (to which this discussion is now very relevant) I think we should set
> as a goal that our metadata best practices be as clear and simple as
> possible so that they can be implemented by users with a wide range of
> expertise.
The page I pointed to recommending the use of skos:prefLabel is part of a larger document by Ian Davis and Leigh Dodds of Talis
http://patterns.dataincubator.org/book/
And it is, I think, an attempt to do more or less that, distilling out some fairly common "patterns", based on their own experience of working with (and observing others working with) RDF, particularly in the form of "linked data".
For the most part, I think their patterns are intended to be very generally applicable - by which I mean they aren't specific to any particular domain or community or the use of a particular RDF vocabulary.
Anyway, it's a resource I've found very readable and helpful - as much for the nice potted discussions of the problems as for the suggested solutions.
Pete
|