- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Mon, 7 Feb 2011 13:30:52 -0500
- To: "Karen Coyle" <kcoyle@kcoyle.net>
- Cc: <open-bibliography@lists.okfn.org>, "public-lld" <public-lld@w3.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@kcoyle.net] > Sent: Monday, February 07, 2011 12:16 PM > To: Young,Jeff (OR) > Cc: open-bibliography@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@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@w3.org [mailto:public-lld-request@w3.org] > On > >> Behalf Of Karen Coyle > >> Sent: Sunday, February 06, 2011 11:02 AM > >> To: Simon Spero > >> Cc: open-bibliography@lists.okfn.org; public-lld > >> Subject: Re: New BNB sample data available > >> > >> Quoting Simon Spero <sesuncedu@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@few.vu.nl> wrote: > >> > > >> > >> > >> > >> -- > >> Karen Coyle > >> kcoyle@kcoyle.net http://kcoyle.net > >> ph: 1-510-540-7596 > >> m: 1-510-435-8234 > >> skype: kcoylenet > >> > >> > > > > > > > > > > > > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet >
Received on Monday, 7 February 2011 18:31:49 UTC