On Wed, Jan 04, 2012 at 06:50:17PM +0000, Pete Johnston wrote:
> > 2. Are there many concrete examples with rdf:value around there? If we
> > only have stuff like <http://example.org/123> dcterms:subject [ rdf:value
> > "Biology"@en] . this won't be very convincing...
>
> Yes, agreed... and I think the particular choice of rdf:value as the
> predicate in that second triple was the subject of some
> discussion/uncertainty. I think you could argue that in many cases the
> strings involved were names/labels for the thing denoted by the blank node,
> and rdfs:label was a better bet. And I see Tom has used a notion of
> ValueLabel in his outline, but then I'm not sure that caters very well for
> cases where the strings are e.g. codes of some form (like Dewey
> classification codes).
>
> > I'm aware that you already had discussions in the past years, but maybe the
> > answer you give could be used as a motivating case now :-)
>
> I can only really speak for myself but my own feeling now, looking back, is
> that the "value string in non-literal value surrogate" case was/is trying to
> cover what are really many different cases. I think it emerged from the
> "classical Dublin Core" notion of an "appropriate literal" - but when one
> examined that notion more closely, it could include all sorts of things:
> labels, codes, "structured strings" like the Box/Period/Point stuff, for
> which a "native RDF modeller" might use a number of different RDF properties.
The reminds me of the discussion in the Semantic Web Deployment WG which
led to the inclusion of skos:notation in the core SKOS model [1]:
A notation is a string of characters such as "T58.5" or "303.4833" used to
uniquely identify a concept within the scope of a given concept scheme.
A notation is different from a lexical label in that a notation is not
normally recognizable as a word or sequence of words in any natural
language.
[1] http://www.w3.org/TR/skos-reference/#notations
If DCAM is about providing a simple interface for designing metadata that is
expressible in triples, and there are significant differences between things
like "notations" and "labels", do we try to identify the most common use
patterns and provide a different slot in the model for the most common of the
different types of literal?
> > 3. Can't the cases where values-as-resources are needed be handled by
> > using a fully fledged resource (possibly blank)?
>
> Yes, and I do think it is appropriate to question which of the current DCAM
> "RDF shortcuts" are actually necessary/useful (on the basis of
> scenarios/requirements they address), and which might be recognised as
> artefacts of a context of eight or nine years ago and quietly consigned to
> history :)
Right. The RDF shortcuts of 2007 may not be optimal RDF shortcuts in 2011.
Would we cover all our major use cases today by distinguishing lexical labels
(rdfs:label) and notations (skos:notation)? Are there other types of literals
that are so common that we would need to accommodate them in the core DCAM
model?
> > 4. While thinking of all this, I thought another use case: "short-cuts" in
> > complex graphs. For instance, a document has a concept with a URI as
> > dc:subject. But one also wants to include in the dc:subject the label of that
> > concept, so that traditional indexing engines get the string they need to
> > index the document, without making another service call (or SPARQL query)
> > for the description of the concept. But is that part of the scenarios that were
> > envisioned for the complex value string?
>
> I suspect the motivating scenarios weren't spelled out and verified as
> requirements - and I agree with Karen that they should have been, and for
> this "reformulation", there is an opportunity to ensure that they are. Having
> said that, there are examples in the Listserv archive and in some of the
> specs themselves which I think reflect some of the common cases.
There is a good starter set of examples at [1]. Some examples that go beyond
DCAM per se and into the realm of the Description Set Profile constraint
language [2] can be found at [3].
[1] http://dublincore.org/documents/dc-rdf/#app-a
[2] http://dublincore.org/documents/dc-dsp/
[3] http://dublincore.org/dcmirdataskgroup/apDesigns
> But from my own perspective/memory, yes, that subject indexing case would
> have been a good example. The DCAM work was started back in 2002/2003 before
> we had any vocabs on the Web in SKOS and, IIRC, the notion of using URIs for
> concepts at all, let alone http URIs which might be dereferenced to obtain
> data which might provide a label, was still new to many in the Dublin Core
> community, so, yes, for the dc:subject case I think the norm would have been
> an "inline" pairing of
>
> - value string ("appropriate literal", which might have been either the name of the concept or a code)
> - vocabulary encoding scheme URI (or maybe not even a URI, but just a "qualified name" like dcterms:LCSH which it was assumed served as a unique name)
That is how I remember it too.
Tom
--
Tom Baker <[log in to unmask]>
|