[open-bibliography] New BNB sample data available

Karen Coyle kcoyle at kcoyle.net
Mon Feb 7 21:59:03 UTC 2011


It's not that it's a problem, but it does mean that you and I are  
talking about different things.

It appears that if you wish to use a different prefLabel than one  
already established for a concept, and the difference is *not* that  
you will be using a different natural language, then you must define a  
new concept with a new identifier. SKOS, like FRAD, seems to have two  
intertwined identifiers: the URI and the preLabel. If you change the  
prefLabel, or prefer to use a different one, you need to create a new  
vocabulary entry with a new identifier. This seems to me to be a  
constraint on vocabularies that may not be ideal in practice.

I was hoping that URIs would predominate, and that prefLabels would be  
just that: preferred labels, not identifiers. That would mean that the  
prefLabel could change, or that different communities could PREFER  
different labels, because the label would not be a determinant of the  
identity of the concept. From this discussion I am concluding that is  
not the case. Thus SKOS is very much like the traditional string-based  
thesauri.

kc

Quoting "Young,Jeff (OR)" <jyoung at oclc.org>:

> I agree they use different identifiers. Why is this a problem?
>
> Karen Coyle <kcoyle at kcoyle.net> wrote:
>
> I agree that you have stated these as equivalents, but do you agree
> that these two concepts use different identifiers?
>
> kc
>
> Quoting "Young,Jeff (OR)" <jyoung at oclc.org>:
>
>> Karen,
>>
>> I disagree that "language is the only option we have to create different
>> prefLabels." My LCSH vs. MESH illustration shows how skos:ConceptScheme
>> can be used as another dimension. If I had asserted owl:sameAs between
>> the two concepts, then we would agree that the two skos:prefLabels end
>> up colliding. Instead of using owl:sameAs, though, I used
>> skos:exactMatch. This is a weaker form of "equivalence" that preserves
>> the separate identities of the LCSH and MESH concepts while recognizing
>> "a high degree of confidence that two concepts can be used
>> interchangeably across a wide range of information retrieval
>> applications".
>>
>> http://www.w3.org/TR/skos-reference/#L4858
>>
>> I assume that MESH terms are jargon whereas LCSH terms are more suitable
>> for laymen. I think the definition of skos:exactMatch is a pretty good
>> match for this situation.
>>
>> Jeff
>>
>>> -----Original Message-----
>>> From: Karen Coyle [mailto:kcoyle at kcoyle.net]
>>> Sent: Monday, February 07, 2011 12:16 PM
>>> To: Young,Jeff (OR)
>>> Cc: open-bibliography at lists.okfn.org; public-lld
>>> Subject: RE: New BNB sample data available
>>>
>>> Jeff, these seem to be different schemes, not different prefLabels.
>>> They've been given equivalence, but have different identifiers. My
>>> point is that prefLabel choice is not just a question of language, but
>>> language is the only option we have to creating different prefLabels
>>> for the same identified concept.
>>>
>>> kc
>>>
>>> Quoting "Young,Jeff (OR)" <jyoung at oclc.org>:
>>>
>>> > In SKOS, different communities can have their own prefLabels for the
>>> > same concept like so:
>>> >
>>> > mesh:abc a skos:Concept ;
>>> > 	skos:inScheme mesh:scheme ;
>>> > 	skos:exactMatch lcsh:xyz ;
>>> > 	skos:prefLabel "the established MESH heading" .
>>> >
>>> > lcsh:xyz a skos:Concept ;
>>> > 	skos:inScheme lcsh:scheme ;
>>> > 	skos:exactMatch mesh:abc ;
>>> > 	skos:prefLabel "the established LCSH heading" .
>>> >
>>> > Jeff
>>> >
>>> >> -----Original Message-----
>>> >> From: public-lld-request at w3.org [mailto:public-lld-request at w3.org]
>>> On
>>> >> Behalf Of Karen Coyle
>>> >> Sent: Sunday, February 06, 2011 11:02 AM
>>> >> To: Simon Spero
>>> >> Cc: open-bibliography at lists.okfn.org; public-lld
>>> >> Subject: Re: New BNB sample data available
>>> >>
>>> >> Quoting Simon Spero <sesuncedu at gmail.com>:
>>> >>
>>> >>
>>> >> > In regards to the requirement that preflabel must be unique
>> within
>>> a
>>> >> scheme,
>>> >> > this is an essential property of controlled vocabularies
>>> (ambiguity
>>> >> > control).  See e.g. NISO Z39.19 section 5.3.1 (not sure what the
>>> >> paragraph
>>> >> > number is in 2788, but it's roughly the same wording).
>>> >> >
>>> >> > It's been LC policy since 1876 :-) [Cutter rule # 173].
>>> >>
>>> >> Right, but the context of that rule is a thesaurus or controlled
>>> >> vocabulary in which the "prefLabel" *is* the identifier for the
>>> >> "thing." There were no URIs in 1876. FRAD continues this by
>>> >> essentially having two identifiers -- one for machines (URI) and
>> one
>>> >> for humans (prefLabel). This makes sense, to some degree, because
>>> you
>>> >> do want to communicate unambiguously to both machines and humans,
>>> but
>>> >> I'm not totally convinced that prefLabel is the way to do that,
>>> since
>>> >> different communities are likely to favor different prefLabels.
>>> (Think
>>> >> of the difference between MeSH subject headings and LCSH subject
>>> >> headings for the same thing.) Communicating to humans unambiguously
>>> is
>>> >> devilishly hard, as we know.
>>> >>
>>> >> kc
>>> >>
>>> >> >
>>> >> > Simon
>>> >> > p.s.
>>> >> > Amusingly, Z39.19 uses the term polyseme polysemously to mean
>>> >> homonym.
>>> >> > Lexical semantics meta!
>>> >> > On Feb 6, 2011 8:57 AM, "Antoine Isaac" <aisaac at few.vu.nl> wrote:
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Karen Coyle
>>> >> kcoyle at kcoyle.net http://kcoyle.net
>>> >> ph: 1-510-540-7596
>>> >> m: 1-510-435-8234
>>> >> skype: kcoylenet
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Karen Coyle
>>> kcoyle at kcoyle.net http://kcoyle.net
>>> ph: 1-510-540-7596
>>> m: 1-510-435-8234
>>> skype: kcoylenet
>>>
>>
>>
>>
>>
>
>
>
> --
> Karen Coyle
> kcoyle at kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>
>
>



-- 
Karen Coyle
kcoyle at kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet





More information about the open-bibliography mailing list