Hi,

On point 3 below. If it is possible to handle the interesting cases by using a fully fledged resource (possibly blank), why not have the Abstract Model keep to:
- (simple) ValueString
- ResourceValues, to which a label/notation/other ValueString MAY be appended for cases such as indexing, and where a label/notation/other MUST be appended if there's no ValueURI.

Granted, the latter is not technically trival. But to me it is still at least as simple as the introduction of Literal-in-resource as a separate class. It also may be presented as a good metadata practice, which would make the pill easier to swallow for a reader.

I am aware that this does not really simplify the number of entities in the abstract model: you'd still have to coin something to indicate that you expect a value string within a specific context (label/notation/other).
But at least it makes it explicit that the construct is at the level of a Statement (in the current DCAM terminology, i.e. a property and a value) which is attached to the "value as a non-literal". Not at the level of the ValueString that appears in this statement, as hinted in DC-Text and the current "Value String" options at http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad

Finally, on Tom's question: "Would we cover all our major use cases today by distinguishing lexical labels (rdfs:label) and notations (skos:notation)?". I'm afraid this is opening a can of worm: if the RDF group keeps not discouraging the use of rdf:value, then your "labels" would also have to include rdf:values, which reads a strange mixture next to rdfs:label. But maybe for now DCAM can postpone the issue, keeping with the general notion of a "value string that represents a resource" (I'm borrowing "represents" from the current DCAM) and see what happens with RDF in the coming months.

Antoine


> 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.
>