- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Wed, 09 Feb 2011 12:29:47 +0100
- To: public-lld <public-lld@w3.org>
@Marcia: Yes, so this is a case where skos:prefLabel perfectly fits!
There can only be one preferred term in AAT per language.
They also hint that a preferred term can be "shared" by several languages. But that's not an issue for SKOS, you can just create several prefLabels with the same literal value but different language tags, as Jeff says.
@Karen:
> *display of the thesaurus,* but not necessarily for instance data
When AAT in the documentation you says that "the preferred term is the most commonly used term in American English, based on usage in authoritative scholarly sources and general reference works", this is not "instance data" as we interpret it. The usage here is in *text*, so where little formal control. In environments like museum catalogs, AAT would be used as a source of authoritative preferred labels to solve ambiguity issues.
> in music uniform titles, you use the plural form of the type of musical composition (symphonies) unless the composer wrote only one, in which case you prefer the singular (symphony). There's a case where the context determines the preferred label within a single application.
Hmm, that's a tricky one, indeed. I'd say then that for the sake of music uniform title you could still coin an extra ex:labelForMusicTitle which could either have as object the prefLabel (as defined by e.g., the "prototypical" use of the concept for document indexing) or one of the altLabels. This is the kind of application-specific triples I'd envision...
But anyway I'm entirely ready to accept that "SKOS covers the simplest case, and in many real life situations we won't be working with the simplest case", as you put it...
@Jeff: colleagues of mine been working with an RDF version of AAT for quite a while. Of course this is not an official conversion, nor an openly available one. But you can get an idea of the data being by browsing the search demo that uses it [1].
Cheers,
Antoine
[1] http://e-culture.multimedian.nl/demo/, http://e-culture.multimedian.nl/demo/session/localview?active=http%3a%2f%2fe-culture.multimedian.nl%2fns%2fgetty%2faat%23300037772 for the "chairs" concept.
> Yes, Antoine, those are indicated sometimes, see example
> from AAT:
> *ID: 300264820
> *
>
> *crèches (Christmas) *(*preferred*,C,U,English-P,D,L,PN)
> *crèches** (Noël) *(French-P,D,U,PN)
> *crèche (Christmas) *(C,U,English,AD,U,SN)
> *crèche** (Noël) *(French,AD,U,SN)
> *Christmas cribs* (C,U,English,UF,U,N)
> *Christmas crib* (C,U,English,UF,U,N)
> *Nativity group* (C,U,English,UF,U,N)
> *kerststallen* (C,U,Dutch-P,D,U,U)
> *Krippen* (C,U,German-P,D,U,PN)
> *Krippe* (C,U,German,AD,U,SN)
> *presepi* (C,U,Italian-P,D,U,PN)
>
>
> Here the flag means:
>
> *“*If the language is followed by "P" (as in "English-P") this means that this is the preferred name for the place in that language. Multiple languages may be included for a single name, because one spelling of the name may be preferred in multiple languages. See also Preferred Name above.”
>
>
> from TGN:
> *ID: 7010273
> *
>
> *Names:
> *S*ankt-Peterburg *(p*referred,*B,V) ............ 18th century-1914, reinstated in 1991
> S*aint Petersburg *(C,O,English-P,U,N)
> S*aint Petersbourg *(C,O,French,U,N)
> S*t. Petersburg *(C,O)
> L*eningrad *(H,V) ............ from 1924-1991
> L*eningrado *(H,O)
> P*etrograd *(H,V) ............ used between 1914 & 1923
>
>
> I hope these examples demonstrate the intention of the point for communities. I will find other examples if I could. :-)
> marcia
>
>
>
>
> On 2/8/11 4:58 PM, "Antoine Isaac" <aisaac@few.vu.nl> wrote:
>
> Marcia, Karen
>
> A quick note: assuming that these display labels may be quite application-specific, and of less "important/preferred/standard/whatever" status, you may represent them using specializations of skos:altLabel. For instance aat-schema:aCommunitySpecificLabel (btw. I don't know what's like this in AAT--I thought they had a pretty clear distinction between preferred and non-preferred terms, cf. [1])
>
> Antoine
>
> [1] http://www.getty.edu/research/tools/vocabularies/aat/about.html#info
>
> > Thanks, Marcia. It's great to have an actual example so I know I'm not just making this up. :-)
> >
> > kc
> >
> > Quoting "ZENG, MARCIA" <mzeng@kent.edu>:
> >
> > > Karen,
> > > I am just jumping into the discussion without reading previous discussed issues completely so please ignore if my comments may not be relevant. (I am not on open-bibliography@lists.okfn.org so I took it out in this email.)
> > >
> > > A quick supporting fact: Getty's Art and Architecture Thesaurus is a typical example of a schema allows multiple user-community-preferred terms for the same concept. (So are other Getty vocabularies).
> > >
> > > Re your particular point on the prefLabel: In the FRSAD model, a set of attributes for nomens (where the entity of nomen can be considered as matching the skosxl:label) is defined in the model, including what you indicated for community's preferences, i.e. 'audience' -- "The community or user group for which the nomen is the preferred form."
> > > Other attributes include: type of nomen, scheme, reference source, representation, language, script, script conversion, form, time of validity, and status. Again, additional attributes may be defined in a specific implementation.
> > > The FRSAD model also provides for relationships between different types of entities and entities of the same type. Therefore between nomens there also can be relationships.
> > >
> > > Using SKOSXL all these attributes should be able to be built in the extension specification.
> > > I consider FRSAD as a conceptual model which specified common entities and attributes and relationships that required for subject authority data. SKOS extensions can be the data models (vary) to reflect these requirements.
> > >
> > > Marcia
> > > p.s. There are limits of how FRSAD was models, e.g., using the entity-relationship model. I hope the next generation of FR-family will present a more up-to- date model.
> > >
> > > On 2/8/11 2:19 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
> > >
> > > Jeff, I'm not having trouble understanding this. I think I'm not
> > > getting across to you, though. I do not want for there to be a karen
> > > scheme and a jeff scheme. What I am advocating is that there could be
> > > a somebody scheme, and there could be different choices for
> > > prefLabels. In fact, one person's altLabel may be another person's
> > > prefLabel. SKOS cannot do this, but I think it could be needed. What
> > > it comes down to is that there could be an identified *something*
> > >
> > > http://something.st/aThing
> > >
> > > and I may wish to label that as:
> > > aabbcc
> > >
> > > and someone else may wish to label it as
> > > zzyynn
> > >
> > > But we may want to use the same identifier for the purposes of
> > > interoperability and for efficiency.
> > >
> > > To my mind, SKOS models the traditional thesaurus structure and its
> > > use of a human-readable *identifier* too closely. Like many of the
> > > other aspects that keep the "S" in "SKOS" this one I think will limit
> > > its usability in the end.
> > >
> > > kc
> > >
> > > Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> > >
> > >> Karen,
> > >>
> > >> Let's use you and I as an example. Assume that this FRBR Event already
> > >> exists somewhere, but doesn't have any prefLabel assigned:
> > >>
> > >> ex:World_War_I a frbr:Event ;
> > >> frbr:hasTerm "World War I" ;
> > >> frbr:hasTerm "Great War" ;
> > >> frbr:hasTerm "WWI" .
> > >>
> > >> If you want to assign a prefLabel for your community, you could do so
> > >> like this:
> > >>
> > >> karen:ww1 a skos:Concept ;
> > >> skos:inScheme karen:myScheme ;
> > >> skos:prefLabel "World War I" ;
> > >> foaf:focus ex:World_War_I.
> > >>
> > >> I could do the same for my community:
> > >>
> > >> jeff:gw a skos:Concept ;
> > >> skos:inScheme jeff:myScheme ;
> > >> skos:prefLabel "Great War" ;
> > >> foaf:focus ex:World_War_I .
> > >>
> > >> Here is a SPARQL query that would allow your community to determine its
> > >> prefLabel for the FRBR Event:
> > >>
> > >> SELECT ?prefLabel
> > >> WHERE {
> > >> ?concept
> > >> skos:inScheme karen:myScheme ;
> > >> skos:prefLabel ?prefLabel ;
> > >> foaf:focus ex:World_War_I .
> > >> }
> > >>
> > >> Does this help?
> > >>
> > >> Jeff
> > >>
> > >>> -----Original Message-----
> > >>> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> > >>> Sent: Tuesday, February 08, 2011 11:59 AM
> > >>> To: Young,Jeff (OR)
> > >>> Cc: open-bibliography@lists.okfn.org; public-lld
> > >>> Subject: RE: New BNB sample data available
> > >>>
> > >>> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> > >>>
> > >>> >
> > >>> > I think we agree that the MESH and LCSH Concepts are
> > >>> owl:differentFrom
> > >>> > despite their skos:exactMatch relationship. I assume this is the
> > >>> source
> > >>> > of Karen's confusion on the identity of "the thing" (concept) they
> > >>> > presumably have in common.
> > >>> >
> > >>>
> > >>> Jeff, I have no problem with MeSH and LCSH -- those are different
> > >>> vocabularies, and often the terms are not equivalents. I'm concerned
> > >>> about future vocabularies when we've gotten vocabularies out beyond
> > >>> institutional silos and different folks want to be compatible but do
> > >>> not want to use the same display for their users. This would mean
> > >>> using the same URI but a different human display. It seems to me that
> > >>> RDF would potentially allow that, but SKOS seems to close down that
> > >>> possibility.
> > >>>
> > >>> kc
> > >>>
> > >>>
> > >>> >
> > >>> >
> > >>> > I admit this proposal is disconcerting because it uses both
> > >>> skos:Concept
> > >>> > and frbr:Concept, but it would resolve the problem of different
> > >>> > prefLabels in different schemes for the same thing. For example:
> > >>> >
> > >>> >
> > >>> >
> > >>> > mesh:concept1 a skos:Concept ;
> > >>> >
> > >>> > skos:inScheme mesh:scheme ;
> > >>> >
> > >>> > skos:exatcMatch lcsh:concept1 ;
> > >>> >
> > >>> > skos:prefLabel "The MESH term" ;
> > >>> >
> > >>> > foaf:focus frbr:concept1 .
> > >>> >
> > >>> >
> > >>> >
> > >>> > lcsh:concept1 a skos:Concept ;
> > >>> >
> > >>> > skos:inScheme lcsh:scheme ;
> > >>> >
> > >>> > skos:exactMatch mesh:concept1 ;
> > >>> >
> > >>> > skos:prefLabel "The LCSH term" ;
> > >>> >
> > >>> > foaf:focus frbr:concept1 .
> > >>> >
> > >>> >
> > >>> >
> > >>> > # The primary entity
> > >>> >
> > >>> > frbr:concept1 a frbr:Concept ;
> > >>> >
> > >>> > frbr:hasTerm "The LCSH term" ;
> > >>> >
> > >>> > frbr:hasTerm "The MESH term" ;
> > >>> >
> > >>> > frbr:hasTerm "other term" .
> > >>> >
> > >>> >
> > >>> >
> > >>> > Note that FRBR:Concept doesn't have a property to express prefLabel
> > >>> (and
> > >>> > IMO shouldn't). This same pattern would work for other types of
> > >>> primary
> > >>> > entities like frbr:Person, frbr:CorporateBody, etc.
> > >>> >
> > >>> >
> > >>> >
> > >>> > Jeff
> > >>> >
> > >>> >
> > >>> >
> > >>> > From: sesuncedu@gmail.com [mailto:sesuncedu@gmail.com] On Behalf Of
> > >>> > Simon Spero
> > >>> > Sent: Monday, February 07, 2011 4:33 PM
> > >>> > To: Karen Coyle
> > >>> > Cc: Young,Jeff (OR); open-bibliography@lists.okfn.org; public-lld
> > >>> > Subject: Re: New BNB sample data available
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Mon, Feb 7, 2011 at 1:49 PM, Karen Coyle <kcoyle@kcoyle.net>
> > >>> wrote:
> > >>> >
> > >>> > Quoting "Young,Jeff (OR)" <jyoung@oclc.org
> > >>> > <mailto:jyoung@oclc.org> >:
> > >>> >
> > >>> > I agree that you have stated these as equivalents, but do you
> > >>> > agree that these two concepts use different identifiers?
> > >>> >
> > >>> >
> > >>> >
> > >>> > kc
> > >>> >
> > >>> >
> > >>> >
> > >>> > The constraint is stronger than that; If two Things have different
> > >>> > preferred labels in a given language in the same conceptScheme,
> > >> then
> > >>> it
> > >>> > is necessarily true that they have different identifiers, *and* that
> > >>> the
> > >>> > identifiers are owl:differentFrom.
> > >>> >
> > >>> >
> > >>> >
> > >>> > Notice that LCSH has different schemes for juvenile and
> > >> non-juvenile
> > >>> > headings (some of which have the same preferred label/Descriptor).
> > >>> > Terms can be in different registers
> > >>> > <http://www.ttt.org/clsframe/datcats02.html#register> without being
> > >>> in
> > >>> > different languages. There's even an ISO registry of register -
> > >>> > http://www.isocat.org/rest/dc/1988 .
> > >>> >
> > >>> >
> > >>> >
> > >>> > Also, if distinct uris which refer to Concepts which exactMatch, the
> > >>> > Concepts have the same extension, but the uris need not refer to the
> > >>> > same Concept object (in fact, in the case discussed above, the URIs
> > >>> > cannot be referring to the same object).
> > >>> >
> > >>> >
> > >>> >
> > >>> > BTW, SKOS explicitly declines to make exactMatch reflexive, though
> > >>> it
> > >>> > does make it Symmetric and Transitive, which means that if A exactly
> > >>> > matches anything, it exactly matches itself.
> > >>> >
> > >>> >
> > >>> >
> > >>> > Simon
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> 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 Wednesday, 9 February 2011 11:29:46 UTC