Andy Powell wrote:
> The analogy with dc:title is slightly broken because in that case the value typically is just a string.
>
Thanks, Andy, I think I'm now on the right page.
I agree that this use of skos:prefLabel may work well (at times) for
dcterms:subject, although it begs the case where you might wish to
include both preferred and non-preferred, or where you don't know if you
have the preferred term. I think it comes down to the depth of your
metadata guidance rules, and whether you can confidently say that this
is your prefLabel (or whether you care at all -- some do more than
others). It makes sense to me to use any or all of the SKOS "label"
designations with dcterms:subject, and I believe that the definition of
dcterms:subject doesn't preclude that. (true?) But if what your
application allows as a value in dcterms:subject is something like an
uncontrolled string of keywords, then I don't think you've got a SKOS
prefLabel situation.
As for other properties, if I assume that any term that is NOT given a
range of "#Literal" in the documentation is a non-literal.... (sorry,
the documentation is confusing to me) then there are properties that to
me do not fit with skos:prefLabel, at least as defined. Where any value
might be transcribed directly from the resource being described, it may
not fit the prefLabel definition. Perhaps that is because I consider the
prefLabel to be a choice made from some possibilities, which
transcription does not allow.
I also find it ... dangerous to re-use SKOS for *things* rather than
*concepts*. As the SKOS documentation says (and someone on this list may
have written this):
"SKOS is an area of work developing specifications and standards to
support the use of knowledge organization systems (KOS) such as
thesauri, classification schemes, subject heading systems and taxonomies
within the framework of the Semantic Web."
So when I look at terms like extent, tableOfContents, provenance, I
don't see KOS, I see what librarians call description, and that is
description of a *thing* not *concepts* about a thing. It's the *is* v.
*is about* difference.
Because Dublin Core is so "wide open" in terms of guidance rules (and I
believe the only guidance "suggestions" are in Diane's document from
2005 referring to the DC-15 set), it may require an application profile
to further narrow down the definition of the values for specific
properties. But I think that if you use skos:prefLabel for a value then
you must limit the value to preferred labels. You can define that as you
like for your own application, but you could be excluding some uses by
others because of that definition. It is narrower than rdf:value.
kc
>
>> It is assumed that
>> the concept has been identified elsewhere. That is not the case with a
>> DCAM literal value.
>>
>
> If one looks at the suggested usage of dcterms:subject with a literal value, which is to insert a blank node between the property and the literal
>
> <dcterms:subject>
> <rdf:Description>
> <rdf:value>physics</rdf:value>
> </rdf:Description>
> </dcterms:subject>
>
> then one is modelling a situation in which the concept (or place or person or whatever) has been identified elsewhere (or, at least, that is how I interpret it) - you just don't know what identifier(s) it has been assigned. In that sense, the literal value is just a 'label' on some unknown thing (the concept, place, person or whatever). On that basis (and ignoring the issues raised by PeteJ for a moment) the use of skos:prefLabel still looks reasonable to me.
>
> Andy
>
> Andy Powell
> Research Programme Director
> Eduserv
>
> [log in to unmask]
> 01225 474319 / 07989 476710
> www.eduserv.org.uk
> efoundations.typepad.com
> twitter.com/andypowe11
> ________________________________________
> From: DCMI Architecture Forum [[log in to unmask]] On Behalf Of Karen Coyle [[log in to unmask]]
> Sent: 15 October 2009 18:01
> To: [log in to unmask]
> Subject: Re: Proposed change to expression of DCAM in RDF
>
> Andy,
>
> 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
> prefLabel.
>
> kc
>
> 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
>>
>> ________________________________
>>
>> Andy Powell
>> Research Programme Director
>> Eduserv
>>
>> [log in to unmask]
>> 01225 474319 / 07989 476710
>> www.eduserv.org.uk
>> efoundations.typepad.com
>> twitter.com/andypowe11
>>
>>
>>
>>> -----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
>>> the
>>> fact that the term "label" is used here is significant. I don't think
>>> the two can be considered equivalent.
>>>
>>> kc
>>>
>>> Thomas Baker wrote:
>>>
>>>
>>>> Dear all,
>>>>
>>>> David Wood suggests two changes in how DCAM constructs are
>>>> represented in RDF [1]:
>>>>
>>>> 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].
>>>>
>>>> 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].
>>>>
>>>> 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 [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.
>>>>
>>>> Tom (at DC-2009, Seoul)
>>>>
>>>> [1] http://dublincore.org/documents/dc-rdf/#sect-4
>>>> [2] http://www.w3.org/TR/skos-reference/#L2805
>>>> [3] 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
> 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
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
|