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

Re: Proposal for a SPEK vocabulary RE: Subjects and perspectives in SKOS : the jack of all trades ...

From: Leonard Will <L.Will@willpowerinfo.co.uk>
Date: Sat, 22 Oct 2005 22:05:40 +0100
Message-ID: <U1z8cZGkmqWDFAWX@willpowerinfo.co.uk>
To: public-esw-thes@w3.org

In message <GOEIKOOAMJONEFCANOKCAEHAHBAA.bernard.vatant@mondeca.com> on 
Fri, 21 Oct 2005, Bernard Vatant <bernard.vatant@mondeca.com> wrote

>don't forget that all the point of aspects and perspectives is to make 
>the notion of "valid" or "invalid" relationships *specific to a 

Bernard -

Sorry not to have grasped exactly what you are proposing, but perhaps 
pursuing these examples a bit further may help understanding.
>> At present it appears to me that you have the relationships (if I may
>> avoid the complexity of RDF by expressing them in a variation of
>> conventional thesaurus form, assuming English as the default language):
>> Wetness
>> fr      Humidité
>> UF-fr   Hygrométrie
>> UF      Moisture
>> BT      Measurement
>>         Hygrometry
>OK ... except for the last one. Agreed, you have to look closely at the 
>code to see that, but "Hygrometry" is not defined as an instance of 
>skos:Concept, but of spek:Term (actually maybe I should have defined 
>this class in another namespace). The semantics of the property 
>"usedTerm" is maybe unclear, but it intends to provide a bridge between 
>the SKOS framework where terms are attributes of concepts, and another 
>yet to be completely specified, where "Term" is a class (allowing e.g. 
>to put notes on synonyms, and so on)
>So ex:Hygrometry does not fit in the Thesaurus framework, and actually 
>you don't see it at all in the Thesaurus perspective.

Well, yes, the semantics are not at all clear to me. As far as I can see 
from your proposal, "usedTerm" has the definition "A term expressing the 
concept". If this does not mean "A term that may be used to label the 
concept", I'm not sure what it does mean. Is it perhaps "A term that 
involves this concept in its definition" or "A term which is used in the 
definition of this concept"?

The converse relationship, "forConcept", defined as "The concept 
expressed by this term" similarly seems to me only to be meaningful if 
defined as "A concept which can be labelled by this term".

Can you clarify what "expressing" means, if possible?

>> Measurement
>> UF      Measure
>> NT      Wetness
>> Hygrometry
>> fr      Hygrométrie
>> UF      Moisture level
>> UF-fr   Taux d'humidité
>> DEF-fr  Mesure du taux d'humidité dans l'atmosphère
>> DEF     Measurement of the moisture level in the atmosphere
>> Wetness is a property of materials, and not a kind, part or instance of
>> the activity "measurement" or of the material "moisture".
>Hmm. Not sure I follow you completely, but you are certainly right.

Therefore, "moisture" should not be specified as an "altLabel" (i.e. UF) 
for "wetness" and  "measurement" should not be specified as a broader 
term for "wetness".
>> Hygrometry is an activity, and therefore could be considered a kind of
>> measurement, but it is not a broader term of the property measured.
>Look more closely :)
>It is not declared as such, actually. As said above, it belongs to a different

My note above requesting clarification of "expressing" applies here too.

>> "Measure" is ambiguous - it might be the result of a measurement
>> activity, or a measuring instrument, or a part of the verb "to measure",
>> not normally acceptable in a thesaurus.
>> If you want to retain this example, a better set of relationships would
>> be:
>> wetness
>> UF      humidity
>>         moisture level
>>         dryness
>I'm amazed to see dryness as a synonym of wetness, but so be it ...
It's actually an example used in thesaurus construction standards - both 
"dryness" and "wetness" express the concept of "moisture content", so 
can be treated as equivalent. It's the issue of whether a glass is half 
empty or half full . . .
>> UF-fr   humidité
>>         taux d'humidité
>> RT      moisture
>>         hygrometry
>No, hygrometry is *not* a related concept.

Well, logically it is, though perhaps you have not defined it as such.

>> measurement
>> NT      hygrometry
>> NT-fr   hygrométrie
>> hygrometry
>> fr      hygrométrie
>> BT      measurement
>> RT      wetness
>>         moisture
>> DEF     Measurement of the moisture level in the atmosphere
>> DEF-fr  Mesure du taux d'humidité dans l'atmosphère
>> moisture
>> RT      wetness
>>         hygrometry
>Same remarks here. All you write above boils down to try and put 
>"hygrometry" is the same perspective as "wetness", the unique Thesaurus 
>perspective. It's exactly what SPEK wants to avoid :(

A thesaurus perspective would certainly wish to include these two 
concepts (or terms, if you wish). Are you saying that some of these 
would not occur in a thesaurus?

Sorry, but I'm afraid that I am not convinced that this approach of 
combining different perspectives is really helpful. You can have a list 
of terms and a list of concepts and there are many-to-many relationships 
between them.

In a thesaurus, several terms may represent a single concept, one of 
these terms being chosen as "preferred" and the others being 
"non-preferred". Any given term can represent only one concept, as 
defined in its scope note. Terms that might represent more than one 
concept are distinguished by the addition of parenthetical qualifiers.

In a terminological database, or a dictionary, as I understand it, a 
single term may represent many concepts, and these are given in a series 
of definitions. In this case the different meanings of the terms are 
often numbered or lettered. When the term is encountered in isolation it 
is not possible to know which meaning is intended; context is necessary 
for this, so entries in a terminological database cannot be used as 
isolated metadata elements to express the subjects of documents.

These two types of structure, linking terms and concepts in two 
different ways, have different purposes and structures, and I agree with 
Stella that "it is dangerous to expect the same model to work for 
several different applications".  I would have to see some realistic 
"use cases" to be convinced that it is helpful, rather than confusing, 
to combine them.

>I agree they have to be improved or completely changed. Actually I 
>built on an example in the SKOS Guide, maybe it was not a good idea.

I'll be interested to see any further examples that may help me to 
understand how your proposals would work in practice.

Best wishes


Willpower Information       (Partners: Dr Leonard D Will, Sheena E Will)
Information Management Consultants              Tel: +44 (0)20 8372 0092
27 Calshot Way, Enfield, Middlesex EN2 7BQ, UK. Fax: +44 (0)870 051 7276
L.Will@Willpowerinfo.co.uk               Sheena.Will@Willpowerinfo.co.uk
---------------- <URL:http://www.willpowerinfo.co.uk/> -----------------
Received on Saturday, 22 October 2005 21:06:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:06 UTC