OK, thanks for the history precisions, Pete!
Sorry for asking so many dumb questions... and for continuing :-)
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.
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.
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].
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...
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 :-)
3. Can't the cases where values-as-resources are needed be handled by using a fully fledged resource (possibly blank)? 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?
Antoine
[1] I have checked the discussion around RDF-ISSUE-27, http://www.w3.org/2011/rdf-wg/track/issues/27, http://www.w3.org/2011/rdf-wg/meeting/2011-04-14#resolution_3.
One argument against keeping rdf:value is that in many cases rdf:value could be replaced by some local property. rdf:value was created and used as a trick to deal with complex predication in a simple triple context. But it's a trick that exists only by convention, not in the model, and this convention is not very strong.
> Hi Antoine,
>
>> Thanks, Pete! I think it is clearer to me, now.
>> Though it may look weirder, in a way. The production rules are the same for
>> DC-Text, aren't they? I is just the mapping to RDF that changes.
>
> Ah, OK. I guess I misunderstood what you meant by production rules :)
>
>> In that case, I would have rather expected the distinction to be made
>> strongly in DCAM (where is matters, if one wants a good alignment with RDF
>> there)
>
> I think this was the motivation (or one of them) for introducing the "non-literal value surrogate" and "literal value surrogate" containers.
>
> The previous version of the DCAM
>
> http://dublincore.org/documents/2005/03/07/abstract-model/
>
> omitted them and it wasn't clear whether "value string" was supposed to map to
>
> (a) the simple single triple, literal-as-object case
> (b) the two triple, second triple with rdf:value predicate and literal object case
> (c) sometimes (a) and sometimes (b) depending on whether other components were present (!)
>
>> and hidden in DC-Text (where it does not really matter, unless DC-
>> Text is meant as a complete implementation of DCAM and all the distinctions
>> it could make).
>
> DC-Text was intended to be a complete implementation of DCAM.
>
> IIRC, I/we did briefly toy with including constructs like
>
> Statement (
> LiteralValueSurrogate (
> ValueString( )
> )
> )
>
> Statement (
> NonLiteralValueSurrogate (
> ValueString( )
> )
> )
>
> but it just seemed simpler to "flatten the structure down" to
>
> Statement (
> LiteralValueString( )
> )
>
> Statement (
> ValueString( )
> )
>
> It's probably not ideal, or at least it's probably incomplete in a "formal" sense, e.g. I think we left undefined how/whether to interpret "contradictory" cases like
>
> Statement (
> LiteralValueString( )
> ValueURI( )
> )
>
> Pete
|