Re: New BNB sample data available

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:
Sankt-Peterburg (preferred,B,V)    ............     18th century-1914, reinstated in 1991
Saint Petersburg (C,O,English-P,U,N)
Saint Petersbourg (C,O,French,U,N)
St. Petersburg (C,O)
Leningrad (H,V)    ............     from 1924-1991
Leningrado (H,O)
Petrograd (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
>>
>>
>>
>>
>
>
>