Re: notes at contepts vs notes at terms

Hi Ron, Sue,

> 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 

Could you give some concrete examples from these thesauri?

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

Sue also refers to a future terminological extension of SKOS. I think 
it might be possible to make the SKOS Core a little bit more complex 
(by introducing a class Label or Token as range for alt/prefLabel) 
that allows extension, while in the current design (literals as range 
for alt/prefLabel) this would be much more difficult to accomodate.

Regards,
Mark.

P.S. sorry for my sloppy wording by using "term"; so deep into this 
community-of-practice that I thought it was the right word to use.

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

-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        mark@cs.vu.nl - http://www.cs.vu.nl/~mark

Received on Tuesday, 1 November 2005 15:42:02 UTC
https://lists.w3.org/Archives/Public/public-esw-thes/2005Nov/0005.html
lists.w3.org
CC-MAIN-2024-26
13866
application/http; msgtype=response
sha1:NEX6JGS6RNRMW4HAGSGINTGRLNCK3WHB
<urn:uuid:5250a3b8-5237-4370-8993-e80c74cb96eb>
2024-06-18T12:32:39Z
104.18.22.19
application/xhtml+xml
sha1:F67VTT4T6WNCKZULL6K4H5WZJOH5MFTY
<urn:uuid:11293c4d-94b3-4d9c-95c8-62d1d3685893>
https://lists.w3.org/Archives/Public/public-esw-thes/2005Nov/0005.html
response
<urn:uuid:3b87c2b6-99d0-45ce-a954-853d03eaa327>
isPartOf: CC-MAIN-2024-26
publisher: Common Crawl
description: Wide crawl of the web for June 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-185
software: Apache Nutch 1.20 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/