 |
 |
Given the concerns raised here, coupled with those raised by Pete... is an alternative approach for the DCMI documentation [1] to allow for either the "rdf:value / dcam:memberOf" and/or "skos:prefLabel / skos:inScheme" approach to be used as appropriate? I.e. we just indicate both possibilities and leave it up to implementers to decide which is right in their particular situation. This acknowledges that there will be times when skos:prefLabel is the better solution and times when rdf:value is the better solution. ?? [1] http://dublincore.org/documents/dc-rdf/#sect-4 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: 16 October 2009 15:19 > To: [log in to unmask] > Subject: Re: Proposed change to expression of DCAM in RDF > > 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:DC- > [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 > ------------------------------------