W3C home > Mailing lists > Public > public-esw-thes@w3.org > November 2005

Re: notes at contepts vs notes at terms

From: Sue Ellen Wright <sellenwright@gmail.com>
Date: Tue, 1 Nov 2005 09:51:38 -0500
Message-ID: <e35499310511010651i6eec79fcvd56d465657e183fb@mail.gmail.com>
To: Ron Davies <ron@rondavies.be>
Cc: Mark van Assem <mark@cs.vu.nl>, "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, public-esw-thes@w3.org
>From a terminological standpoint, what Ron writes is absolutely appropriate
(also his use of "concept" because concepts occur at all levels and are
many-faceted). Because of diversification and neutralization of concepts
when we move from one language to another, multilingual resources have to
distinguish between apparent sub-concepts that seem trivial sometimes in one
language, but which form critical distinctions in another. In terminology
management, however, these issues would all be handled with notes on concept
rather than notes on terms. (We use a special note called a "transfer
comment", which would certainly violate the principle of simplicity that is
the focus of SKOS.) We would need these kinds of notations in a
terminological extension.
 Sue Ellen

 On 11/1/05, Ron Davies <ron@rondavies.be> wrote:
>
> In a posting way back on 1 March 2005, I mentioned a couple of problems
> with the underlying SKOS model in terms of thesaurus management. The one
> issue seems to have attracted a lot of attention ('notes at term level') and
> some progress seems to be being made on accommodating that issue. However I
> feel I also have to raise again the second problem, that of semantic
> associations between non-preferred terms (or tokens as Mark suggests).
>
> Frequently in multilingual thesauri, we want to capture a relationship of
> equivalence between different tokens used as altLabels in different
> languages. This feature is frequently used in multilingual thesauri such as
> the OECD Macrothesaurus, the ILO Thesaurus or Agrivoc (there are undoubtedly
> others, but these are the ones that I know about). In semantic terms, these
> altLabel tokens have some close relationship (usually they all equivalently
> express an underlying shared concept [1] that has been specifically excluded
> from the accepted concepts within the thesaurus itself, often for reasons of
> literary warrant). In practical terms, the different altLabel tokens are
> then managed together as a single unit: for example, in doing a translation
> into a new thesaurus language, there would be a special effort to try to
> find an equivalent altLabel in the target language corresponding to that
> excluded concept, and in revising or adapting the thesaurus to local
> conditions and use, the non-descriptors may be promoted together to
> descriptor level (or descriptors demoted to non-descriptors, while retaining
> the semantic relationship between the altLabel tokens that exists in the
> original descriptor/concept record).
>
> If SKOS is meant to be a way of interoperating for query expansion and
> similar kinds of uses, this feature is not (I think) necessary. In fact, in
> my personal opinion, I think at this stage we should be keeping SKOS as
> simple as possible to promote wide implementation.
>
> However if we talk about SKOS as a way of exchanging thesaurus information
> for purposes of thesaurus management (which I know is one of the uses that
> Alistair talks about), then it is both a necessary and reasonable
> requirement. Otherwise multilingual thesaurus won't be able to use SKOS for
> management purposes without a significant loss of information.
>
> I'm hoping that some of the proposals being put forward for accommodating
> notes on altLabel tokens will also be able to accommodate this multilingual
> requirement.
>
> Ron
> [1] Sorry if this use of the word concept offends but I don't know what
> other word to use here.
>
> At 12:29 1/11/2005, Mark van Assem wrote:
>
> Hi Alistair,
>
> I'm leaving the "use cases" that I wrote about for later, in this post I
> to summarize what I think Sue Ellen Wright, Bernard Vatant, Phil Carlisle
> and Stella Dextre Clark have been saying (please correct me if I'm wrong!)
> [1,2,3,4,5]. I'm hoping Sue and Stella can find time to provide some more
> examples.
>
> About the word "term": I agree that it is overloaded. Should I call "the
> thing in the range of the skos:prefLabel and skos:altLabel properties" a
> Label or a Token?
>
> If a class e.g. Label is introduced instead of the literal currently
> defined as the range of skos:prefLabel and skos:altLabel, additional
> information can be attached to Labels. The categories of information that
> can be attached to instances of a class Label or Token are (summarizing
> other people's posts):
>
> - scope notes for terms, also referring to other terms to use [4]
> - lexical information about the term [2,5]
> - scope of usage of the lexical term [5]
> - etymological, register-related, standardization
> related [2] (I hope Sue can find time to clarify this further)
>
> (what follows is not summarizing [1-5])
>
> Furthermore, some examples from MeSH [6]:
>
> - TermUI (local identifier)
> - date created
> - source thesaurus (MeSH groups different thesauri into one)
> - abbreviation
>
> which mostly fall under a category "editorial information". I also
> remember someone posting that some thesauri attach different definitions to
> different terms.
>
> A class Label would make it possible to extend the SKOS schema for
> categories of information (attached to Label) we can't foresee right now.
>
> You provide an alternative way to attach notes to labels [7]:
>
> ex:conceptA a skos:Concept;
> skos:prefLabel 'Animals';
> skos:altLabel 'Fauna';
> skos:editorialNote [
> skos:onLbl 'Fauna';
> rdf:value 'Check with Mr.X. whether to keep "Fauna".';
> ];
>
> I think this is a solution, but in principle this method could be used
> everywhere you normally use a class to group information about an entity. I
> think the more usual way to do this in RDF or OWL is introduce a class.
> Also, this is harder to maintain (changing skos:altLabel 'Fauna' without
> changing skos:onLbl 'Fauna' leads to errors).
>
> Of course we can choose not to support this kind of information attached
> to terms, but then we should say so explicitly.
>
> Cheers,
> Mark.
>
>
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2005Oct/0119
> [2] http://lists.w3.org/Archives/Public/public-esw-thes/2005Oct/0109.html
> [3]http://lists.w3.org/Archives/Public/public-esw-thes/2005Oct/0101.html
> [4] http://lists.w3.org/Archives/Public/public-esw-thes/2005Aug/0019
> [5]http://lists.w3.org/Archives/Public/public-esw-thes/2005Aug/0018
> [6] http://www.nlm.nih.gov/mesh/xml2006sample.txt
> [7]http://lists.w3.org/Archives/Public/public-esw-thes/2005Aug/0017.html
>
>
> --
> Mark F.J. van Assem - Vrije Universiteit Amsterdam
> mark@cs.vu.nl - http://www.cs.vu.nl/~mark
>
>
>


--
Sue Ellen Wright
Institute for Applied Linguistics
Kent State University
Kent OH 44242 USA
sellenwright@gmail.com
swright@kent.edu
sewright@neo.rr.com
Received on Tuesday, 1 November 2005 14:52:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:54 GMT