Re: New BNB sample data available

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
>
>
>
>



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

Received on Tuesday, 8 February 2011 20:54:49 UTC