On Thu, Oct 15, 2009 at 09:35:07AM +0100, Pete Johnston wrote:
>> 2. Instead of using rdf:value to relate a value to a
>> DCAM Value String [1, section 4.6], David suggests using
>> skos:prefLabel [3].
...
>> -- The domain of skos:prefLabel was also left unspecified [3],
>> so its use does not imply that the subject of a statement is
>> a SKOS concept. On the other hand, I believe the
>> correct use of rdf:value has long been unclear.
>> So #2 seems like a good idea too, though as part of such a
>> change we would need to understand better where the problem
>> with rdf:value lies.
...
> (a) According to
>
> http://www.w3.org/TR/skos-reference/#L1581
>
> the range of skos:prefLabel is the class of plain literals. The DCAM notion of
> value strings currently includes typed literals. See e.g. the example in 4.3 of
>
> http://dublincore.org/documents/2008/01/14/dc-rdf/
>
> where both a plain and typed literal are provided.
>
> So (with the current concept of "value string") I don't think skos:prefLabel
> would work as a straight substitute for the use of rdf:value?
>
> I see SKOS also has a skos:notation property but that seems to be explicitly
> for "non-natural-language" literals?
SKOS Reference [1] says:
Note that the range of skos:prefLabel, skos:altLabel and
skos:hiddenLabel is the class of RDF plain literals
[RDF-CONCEPTS].
By convention, RDF plain literals are always used in the
object position of a triple, where the predicate is one of
skos:prefLabel, skos:altLabel or skos:hiddenLabel. If a
graph does not follow this usage convention an application
may reject such data but is not required to. See also the
note below.
and
By convention, the property skos:notation is only used with
a typed literal in the object position of the triple, where
the datatype URI denotes a user-defined datatype
corresponding to a particular system of notations or
classification codes.
The example 4.3 of DC-RDF [2] does indeed show a
"non-natural-language" code in the object position of the
triple:
ex:subject32 rdf:value "EA32^^ex:SubjectEncoding"
I'm wondering whether rdf:value could in principle be replaced
with skos:notation _or_ skos:prefLabel depending on whether used
with datatypes or plain literals. Would any significant use
cases be left unaddressed (e.g., datatypes using natural
language)?
There are other dimensions to this question (e.g., the notion of
"preferred" as raised by Karen), but I'm wondering whether the
distinction between skos:prefLabel and skos:notation would at
least address the issue of plain versus typed literals. (And
are there indeed arguments for using two distinct properties
instead of the undifferentiated rdf:value?)
I'm also wondering whether there are also reasons to move _away_
from using rdf:value. As discussed in a thread on the
public-swd-wg mailing list in January [3], the inconsistent use
of rdf:value was recognized and discussed in 2001-2002 [4] and
AFAICT never really clearly resolved [5].
On Mon, Oct 19, 2009 at 10:33:49AM -0400, David Wood wrote:
> The two changes listed below by Tom would indeed solve my most
> pressing issues.
Dave, it would be helpful to know what it was about rdf:value
that created an issue for you.
Tom
[1] http://www.w3.org/TR/skos-reference/#L1581
[2] http://dublincore.org/documents/2008/01/14/dc-rdf/
[3] http://lists.w3.org/Archives/Public/public-swd-wg/2009Jan/0027.html
[4] http://lists.w3.org/Archives/Public/public-swd-wg/2009Jan/0038.html
[5] http://www.w3.org/2000/03/rdf-tracking/#rdfms-replace-value
--
Thomas Baker <[log in to unmask]>
|