W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2006

Re: altLabels in different langauges

From: Mark van Assem <mark@cs.vu.nl>
Date: Wed, 24 May 2006 23:33:32 +0300
Message-ID: <4474C31C.90500@cs.vu.nl>
To: Ron Davies <ron@rondavies.be>, Sue Ellen Wright <sellenwright@gmail.com>
CC: public-esw-thes@w3.org

Hi Ron, Sue,

> Thanks for a very nicely and succinctly worded summary of the issue in 
> your previous message.


> alt-labels for a single concept in the first place.) So you are really 
> no further ahead.

You are probably right that in general my proposal is senseless. But on 
a technical level this *is* a way out to be able to keep the assumption 
that the different labels are translations of each other. It would only 
work for thesauri one has under own control. It is not my *preferred* 
solution (see below).

> I agree with Susan's comment. There are things we should expect SKOS to 
> do well (e.g. interoperability with Semantic Web applications), and 
> there are things we should not expect SKOS to do (e.g. lossless transfer 
> of multilingual thesaurus data as in Paul's case). Wisdom may consist of 

That is why I would like to hear your views on the Change Proposal I 
made [1]. I still do not understand what is against adding a class Term 
and a property between skos:Concepts and skos:Terms to the schema so 
that we are able to represent a bit more of the original thesaurus data. 
For example, I understand that the people at FAO are developing a new 
OWL model for AGROVOC in which they want to be able to relate terms to 
each other. So they will probably end up with their own OWL schema next 
to their port to SKOS. This does not seem to be the way we should be headed.

I acknowledge that the addition makes the model a bit more difficult, 
but I am still in the dark as to why the trade-off should be in favour 
of the more simple model with labels attached to skos:Concept.

 > Wisdom may consist of knowing what you want to do and what tools you
 > need to do it.

I totally agree. But it would be unwise to *not* have a model that would 
be able to handle more of the thesaurus data without much additional cost.

I am not saying we should change SKOS now, but I am saying that we need 
to explore this issue more deeply before the "definitive" SKOS is put 
out into the world. Maybe some more experience with the current model 
can help us finding out how the trade-off really lies.


Received on Wednesday, 24 May 2006 20:33:46 UTC

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