I find it hard to explain, but to me the difference that I see is that
the DCAM value "is" the value of the property, and in that sense,
although just a string, has the function of identifying. It stands
alone. If I say that the title of the book is "Moby Dick," you may
choose to display that, or not. The purpose of it is to state the title
of the book, not to format a display. It may or may not be the preferred
form for display to human users, and it doesn't necessarily have
anything to do with display.
The prefLabel is simply a display form, and does not in any way identify
the concept. Its purpose is to give you a display form that is more
human-readable than the identifier for the concept. It is assumed that
the concept has been identified elsewhere. That is not the case with a
DCAM literal value.
Now, it is possible that the two are structured similarly in terms of
their formal definition, but I don't think we should lose sight of the
*purpose* of each property. I believe I can say that a SKOS prefLabel is
a DCAM property that takes a literal value, but it does not therefore
follow that a DCAM property that is defined as a literal value is a SKOS
Andy Powell wrote:
> I agree that these can't be considered equivalent. The RDF Primer (http://www.w3.org/TR/rdf-primer/) says this about rdf:value:
> "RDF provides a predefined rdf:value property to describe the main value (if there is one) of a structured value."
> And, as you say, the SKOS Reference (http://www.w3.org/TR/skos-reference/#labels) says the following about skos:prefLabel:
> "The preferred and alternative labels are useful when generating or creating human-readable representations of a knowledge organization system. These labels provide the strongest clues as to the meaning of a SKOS concept."
> So it comes down to which is more appropriate for what we want to achieve?
> The use of skos:prefLabel doesn't look too unreasonable to me - indeed to a great extent, that SKOS wording captures quite nicely what I had understood us to be doing with our current use of rdf:value... providing a string to be displayed to human readers.
> Am I missing something?
> Andy Powell
> Research Programme Director
> [log in to unmask]
> 01225 474319 / 07989 476710
>> -----Original Message-----
>> From: DCMI Architecture Forum [mailto:[log in to unmask]]
>> On Behalf Of Karen Coyle
>> Sent: 15 October 2009 15:25
>> To: [log in to unmask]
>> Subject: Re: Proposed change to expression of DCAM in RDF
>> #2 - Although the domain of skos:prefLabel is unspecified, the property
>> does have a semantic definition and some "partner" properties (altLabel
>> and hiddenLabel) that have meaning. The documentation says:
>> "The preferred and alternative labels are useful when generating or
>> creating human-readable representations of a knowledge organization
>> system. These labels provide the strongest clues as to the meaning of a
>> SKOS concept."
>> This, to me, is quite different from the use of "value" in DCAM, and
>> fact that the term "label" is used here is significant. I don't think
>> the two can be considered equivalent.
>> Thomas Baker wrote:
>>> Dear all,
>>> David Wood suggests two changes in how DCAM constructs are
>>> represented in RDF :
>>> 1. Instead of using dcam:memberOf to relate a value to a
>>> DCAM Vocabulary Encoding Scheme [1, section 4.5], David
>>> suggests using skos:inScheme .
>>> 2. Instead of using rdf:value to relate a value to a
>>> DCAM Value String [1, section 4.6], David suggests using
>>> skos:prefLabel .
>>> Some first reactions:
>>> -- The domain of skos:inScheme was left unspecified in
>>> order to provide the flexibility to extend a concept scheme
>>> with classes of resource other than skos:Concept (i.e., the use
>>> of skos:inScheme does not imply that the subject is a concept).
>>> Also, skos:inScheme is better-known than dcam:memberOf.
>>> So #1 seems like a sound idea.
>>> -- The domain of skos:prefLabel was also left unspecified ,
>>> 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.
>>> Tom (at DC-2009, Seoul)
>>>  http://dublincore.org/documents/dc-rdf/#sect-4
>>>  http://www.w3.org/TR/skos-reference/#L2805
>>>  http://www.w3.org/TR/skos-reference/#L1541
>> Karen Coyle / Digital Library Consultant
>> [log in to unmask] http://www.kcoyle.net
>> ph.: 510-540-7596 skype: kcoylenet
>> fx.: 510-848-3913
>> mo.: 510-435-8234
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet