- From: ZENG, MARCIA <mzeng@kent.edu>
- Date: Tue, 8 Feb 2011 15:06:14 -0500
- To: Karen Coyle <kcoyle@kcoyle.net>, "Young,Jeff (OR)" <jyoung@oclc.org>
- CC: public-lld <public-lld@w3.org>
- Message-ID: <C9770C66.150A2%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 Tuesday, 8 February 2011 20:08:39 UTC