Hi Antoine,
> 1. About your reference to issues with the way the previous DCAM handled
> mapping to RDF. Why is a test such as your (c) not ok for deciding what to
> map a "DCAM value string" to, in RDF? It is deterministic.
I think we wanted to be able to allow for, and distinguish between:
(a) the case where a "value string" mapped to a literal object; and
(b) the case where a "value string" (a single "value string" with no other "value string", no VES URI, no "value URI") mapped to a blank node plus rdf:value triple.
> It may also match quite well the potential uses. To me, a first case that
> requires the value-string-in-non-literal construction is "literals on which
> something else needs to be asserted"--a kind of qualification on values.
> But in that case, you could keep "value string" as a general umbrella notion,
> and then say that the mapping to RDF will depend on whether the value is
> qualified with that "something else" that makes it more complex to
> represent in RDF.
I think we were trying to cater for case (b) where there was no "something else" to mark it out from case (a).
> People won't create blank nodes for the sake of creating blank nodes. In fact
> it could be a value of DCAM to act as an abstraction layer on top of RDF's
> rdf:value trick, which is not core to RDF as a data model by the way [1].
Yes, understood.
> 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.
> 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 :)
> The RDF Group discussion
> around rdf:value [1] hints that this could be possible. If there are not many
> cases that require value-string-in-non-literals, and many of these cases can
> be handled by upgrading the non-literal as a fully-fledged resource, then the
> urgency for a weird construction is lower...
>
>
> 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.
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)
Pete
|