RE: New BNB sample data available

When VIAF merges prefLabels from the various participants, we downgrade
them to viaf:hasEstablishedForm in relation to the VIAF cluster. I took
Antoine's hint this morning and updated the VIAF ontology to make this
property an rdfs:subPropertyOf skosxl:altLabel to improve its
interoperability.

http://viaf.org/ontology/1.1/viafOntology.owl#hasEstablishedForm

Marcia mentioned that in FRSAD, "scheme" is a property of Nomen
(mappable to skosxl:Label) rather than Thema (mappable to skos:Concept).
The rdfs:domain for skos:inScheme is unspecified, so it seems
permissible to go either or both ways in SKOS. VIAF does both.

Jeff

> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Antoine Isaac
> Sent: Tuesday, February 08, 2011 4:58 PM
> To: Karen Coyle
> Cc: ZENG, MARCIA; public-lld
> Subject: Re: New BNB sample data available
> 
> 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 15:01:30 UTC