W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2007

Re: [SKOS] thesaurus USE patterns

From: Mark van Assem <mark@cs.vu.nl>
Date: Thu, 15 Feb 2007 12:01:28 +0100
Message-ID: <45D43D88.7010504@cs.vu.nl>
To: Bernard Vatant <bernard.vatant@mondeca.com>, SKOS <public-esw-thes@w3.org>


> Now the question is : does that belong to SKOS (core) scope? looks like 
> borderline. And if we open this door, who knows what is likely to enter ...

Without noting which things might enter it's like scaring someone with 
imaginary monsters under the bed :-)

What is a risk is that people will start using Terms to annotate with 
instead of with Concepts. But as we as a SW community should lead the 
way for others to represent thesauri etc. in RDF it is our job anyway 
to educate on the right usage.

> In a modular approach, seems to me terminological aspects should be 
> dealt in later on in some specific extension, SKOS-Term, whatever.

I don't understand this argument. I'd say it's the other way around: 
first the complete model that covers the requirements, then the 
simplifications. And again it is a question of perspective on what is 
complex and simple. Is adding one class to the model adding that much 

And this solution allows you to get rid of the problems with 
qualifiers and UF+ etc. The current model is just too simple to deal 
with the requirements posed on SKOS in a straightforward way.

> Problem if we include skos:Term in SKOS core, looks like we have to 
> revisit many things, e.g. prefLabel and altLabel.

So this is an argument about the process. Then we need an estimate of 
how much time it would require to change. I don't see why it would 
take that much time. The requirements for representing UF+ etc. 
clearly show why the change is justified.

> Some will use them as they stand now (datatype properties) and other 
> will use "hasTerm" (object properties). Making further federation of 
> such vocabularies very tricky.

That is a "backward compatibility" argument. Is the uptake of SKOS 
already that large that this is a real problem? And as you say 
yourself: for very useful applications you already need an extension. 
Why produce something that needs extension?

> And I think it would be a very bad idea to enforce "term reification" 
> (so to speak) by getting rid of prefLabel and altLabel as they stand.

Why is it a bad idea to get rid of pref/alt distinction?


> Bernard
>> Hi,
>>> but I don't see the advantage of it. The second point is right - "Z" is
>>> not a concept but a term and currently skos does not allow it to be a
>>> subject - but the whole USE-relationship is about terms anyway.
>> Long ago I proposed the inclusion of a skos:Term class that could be 
>> used to solve this problem. It is very straightforward then to manage 
>> the different kinds of links between terms, concepts and coordinations.
>> Having skos:Term allows to represent terms separate from concepts that 
>> use it. Terms are then roughly equivalent to WordNet's WordSenses and 
>> concepts to WordNet's Synsets. This allows all kinds of relationships 
>> between Synsets/concepts (which carry non-lexical meaning) and 
>> Terms/WordSenses (which do carry lexical meaning). This includes the 
>> various USE relationships. USE/USEFOR becomes "hasTerm" (or separated 
>> into prefTerm and altTerm but I dont think the pref/alt distinction to 
>> be appropriate anymore) in the example below (adapted from Jacob's).
>> -------------------------------------------------
>> :abc a skos:Term ;
>>     rdfs:label "C Programming Language" .
>> :def a skos:Term ;
>>     rdfs:label "C" .
>> :ghi a skos:Term ;
>>     rdfs:label "Vitamin C" .
>> :jkl a skos:Term ;
>>     rdfs:label "C" .
>> :c1 a skos:Concept;
>>     skos:hasTerm :abc ;
>>     skos:hasTerm :def .
>> :c2 a skos:Concept.
>>     skos:hasTerm :ghi ;
>>     skos:hasTerm :jkl .
>> -------------------------------------------------
>> And defining those problematic relationships becomes simple
>> * USE X + Y
>> -------------------------------------------------
>> coal mining USE coal + mining
>> :cm a skos:Term ;
>>     rdfs:label "coal mining" .
>> :c a skos:Term ;
>>     rdfs:label "coal" .
>> :m a skos:Term ;
>>     rdfs:label "mining" .
>> :conceptc a skos:Concept;
>>     skos:hasTerm :c .
>> :conceptm a skos:Concept;
>>     skos:hasTerm :m .
>> -------------------------------------------------
>> ... and finally the relationship:
>> -------------------------------------------------
>> :use1 a skos:UseAND ;
>>     skos:source :cm ;
>>     skos:target skos:ConceptAND [ skos:member :c ; skos:member :m ].
>> -------------------------------------------------
>> Because Terms are not used for indexing, the combination "coal mining" 
>> as a Term can point to the appropriate coordinated concepts "coal + 
>> mining".
>> * USE X OR Y
>> grinding mill
>>   USE grinding house OR grindery
>> ... well very similar, without stating the obvious concept definitions:
>> -------------------------------------------------
>> :use2 a skos:UseOR ;
>>     skos:source :gm ;
>>     skos:target skos:ConceptOR [skos:member :gh ; skos:member :g].
>> -------------------------------------------------
>> Of course we discussed this kind of thing before and the tradeoff is 
>> that this makes SKOS more complex, and the exposing of Terms as 
>> entities in their own right might be open to abuse (e.g. start 
>> indexing stuff with Terms). But it also allows more fine grained 
>> mappings and man'ment info to be attached to them.
>> Cheers,
>> Mark.

  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Thursday, 15 February 2007 11:02:01 UTC

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