- From: Simon Spero <ses@unc.edu>
- Date: Wed, 9 Feb 2011 15:01:03 -0500
- To: "ZENG, MARCIA" <mzeng@kent.edu>
- Cc: "Houghton,Andrew" <houghtoa@oclc.org>, Antoine Isaac <aisaac@few.vu.nl>, public-lld <public-lld@w3.org>, SKOS <public-esw-thes@w3.org>
- Message-ID: <AANLkTim7o6ODvJ0CsCAFhDDWULKeA4MOmSMf3FkXZS9O@mail.gmail.com>
[Adding SKOS list to the discussion]
It is possible to capture a lot of the semantics that are being discussed
here by reifying the language tag as a separate xsd:language data property,
and using OWL2 Key Properties to declare equivalencies on skos-xl style
labels.
For one possible way of doing this, see
http://www.ibiblio.org/fred2.0/ontologies/kosstest.owl .
For this simplified case, I specify that two labels are the same if they
have the same string value, are in the same language, have the linguistic
register (e.g. formal, vulgar, technical, etc.), and are in the same concept
scheme.
Further, two labels are the same if they are the established form/prefLabel
of the same thing, are in the same linguistic register, and are in the same
language.
I also state that the Label objects can only be the
establishedForm/prefLabel of one thing.
The toy* ontology is deliberately inconsistent. There are two Label
objects (:label-a-vulgar and :label-a-vulgar-clone) which have identical
strings,registers,languages, and which are in the same scheme.
ObjectPropertyAssertion(:hasRegister :label-a-vulgar :vulgarRegister)
ObjectPropertyAssertion(:inScheme :label-a-vulgar :scheme-sand-nightmare)
DataPropertyAssertion(:hasTextValue :label-a-vulgar "A (Wot Is Fer
Orses)"^^xsd:string)
DataPropertyAssertion(:isInLaguage :label-a-vulgar "en"^^xsd:language)
ObjectPropertyAssertion(:hasRegister :label-a-vulgar-clone :vulgarRegister)
ObjectPropertyAssertion(:inScheme :label-a-vulgar-clone :scheme-sand-nightmare)
DataPropertyAssertion(:hasTextValue :label-a-vulgar-clone "A (Wot Is
Fer Orses)"^^xsd:string)
DataPropertyAssertion(:isInLaguage :label-a-vulgar-clone "en"^^xsd:language)
The first key definition entails that these two labels are inferred as being
owl:sameAs:
HasKey(:Label (:hasRegister :inScheme) (:hasTextValue :isInLaguage))
The two labels are assigned as the established labels of two concepts,
each of which has a distinct label in the same language and concept scheme,
but in a different register:
DataPropertyAssertion(:hasTextValue :label-a-formal "A (The Roman
letter)"^^xsd:string) [...]
DataPropertyAssertion(:hasTextValue :label-b-formal "B (The Roman
letter)"^^xsd:string) [...]
ObjectPropertyAssertion(:hasEstablishedLabel :concept-a :label-a-formal)
ObjectPropertyAssertion(:hasEstablishedLabel :concept-a :label-a-vulgar
ObjectPropertyAssertion(:hasEstablishedLabel :concept-b :label-b-formal)
ObjectPropertyAssertion(:hasEstablishedLabel :concept-b
:label-a-vulgar-clone)
Because hasEstablishedLabel is declared as an inverse functional property,
this entails that :concept-a and :concept-b are the same concept, and hence
that both have the established Labels :label-a-formal and :label-b-formal.
The second key definition now states that two labels are the same if they
are established label of the same thing, and have the same scheme, register,
and language.
HasKey(:Label (:hasRegister :inScheme ObjectInverseOf(:hasEstablishedLabel))
(:isInLaguage))
This entails that :label-a-formal and label-b-formal must by owl:sameAs.
However, the two labels have different values for hasTextValue, which is a
functional property: thus we have an inconsistency.
FunctionalDataProperty(:hasTextValue)
This inference is handled correctly by HermiT and Pellet. Fact++ does not
like language data properties.
Simon
On Wed, Feb 9, 2011 at 12:34 PM, ZENG, MARCIA <mzeng@kent.edu> wrote:
> Andy,
> Yes, this is extremely helpful! Thank you for the detailed explanation and
> examples.
> Marcia
>
>
> On 2/9/11 12:29 PM, "Houghton,Andrew" <houghtoa@oclc.org> wrote:
>
> Marcia, there might be a misunderstand of “language” in regard to
> skos:prefLabel or other SKOS label properties. The SKOS label properties use
> the xml:lang attribute which contains language identifiers as defined by
> IETF BCP 47, Tags for the Identification of Languages [1,2]. IETF BCP 47
> defines the language tag as: language [“-“ script] [“-“ region] (“-“
> variant) (“-“ extension) [“-“ privateuse]. The token language is defined by
> ISO 639, e.g., en. The optional token script is defined by ISO 15923, e.g.,
> The optional token region is defined by ISO 3166, e.g., US. Using your
> examples: American English, xml:lang=”en-US”; British English,
> xml:lang=”en-GB”; Indian English, xml:lang=”en-IN”. Scripts are handled in a
> similar fashion: Turkish Kurdish Latin script, xml:lang=”ku-Latn-TR”; Iraq
> Kurdish Arabic script, xml:lang=”ku-Arab-IQ”; Georgian Kurdish Cyrilic
> script, xml:lang=”ku-Cyrl-GE”. As far as community/audience one could define
> an extension or use the privateuse parts of BCP 47 depending upon need. BCP
> 47 allows one to use x- subtag [“-“ subtag]* as “private agreement” tags,
> thus, an audience such as Painters could be described as
> xml:lang=”x-painters” or painters in the US speaking English,
> xml:lang=”en-US-x-painters”. Hope this helps your understanding that SKOS
> delegates language, country, script, community and audience to the XML
> language specification property xml:lang which takes all these factors into
> account by using the time honored IETF BCP 47 specification token that
> describes all these aspects.
>
> Andy.
>
> [1] http://www.w3.org/TR/REC-xml/#sec-lang-tag
> [2] http://tools.ietf.org/html/bcp47
>
>
>
> *From:* public-lld-request@w3.org [mailto:public-lld-request@w3.org<public-lld-request@w3.org>]
> *On Behalf Of *ZENG, MARCIA
> *Sent:* Wednesday, February 09, 2011 11:27
> *To:* Antoine Isaac; public-lld
> *Subject:* Re: Application-specific prefLabels
> *Importance:* Low
>
> Antoine,
> Thanks for confirming the language for preferred term. I think what I
> tried to say is not just the language attribute of a preferred label.
> There are two attributes here, one is language, (and sub-languages and
> dialects, and shared) another one is community/audience.
>
> In the thesaurus standard this was mentioned a little bit:
>
> [This is in the context of multilingual thesaurus:]
>
> “It is possible also to treat different dialects or sublanguages as though
> they were separate languages. For example, American English, British
> English and Indian English may be treated as different languages, and the
> three presented separately in one "trilingual thesaurus". Many of the terms
> will be common to two or three of the languages, but other terms are
> different. *Similarly, the terminology preferred by scientists could be
> presented as a different language to that of marketing and sales personnel.
> *If the thesaurus is treated as monolingual, one preferred term is
> assigned to each concept, and the alternative scientific term or dialect
> term appears as a non-preferred term (see 6.6.2 and 8.2g). Treating it as a
> multilingual thesaurus allows equal status to be given to each dialect or
> sublanguage.”[1]
>
>
> I believe that in addition to the scientists vs. marketing and sales
> personnel, there are also differences for age groups, ethnic groups, doctors
> vs. healthcare vs. patients, and many. As more ontologies are used for
> shared visions, it would be useful to address such different needs in order
> to reuse good concept schemes.
> Again, I also believe that SKOSXL will be able to express them and allow to
> indicate relationships between different labels.
> If
> skos:prefLabel can have a wider definition, adding the statements like that
> in the above cited paragraph, it may provide the flexibility to treat this
> issue as well (while may need to think a code for representing the
> communities like languages do).
>
> Thanks for other answers as well.
>
> Marcia
> [1] ISO 25964 Thesauri and Interoperability with Other Vocabularies. Part
> 1... 9.1.
>
>
> On 2/9/11 6:29 AM, "Antoine Isaac" <aisaac@few.vu.nl> wrote:
>
>
> @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<http://aisaac@few..vu.nl><
> 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<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<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 <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 20:01:38 UTC