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

RE: Change proposal

From: Antoine Isaac <Antoine.Isaac@KB.nl>
Date: Wed, 31 May 2006 15:39:46 +0200
Message-ID: <68C22185DB90CA41A5ACBD8E834C5ECD031FF011@goofy.wpakb.kb.nl>
To: "Mark van Assem" <mark@cs.vu.nl>, "Alistair Miles" <a.j.miles@rl.ac.uk>
Cc: <public-esw-thes@w3.org>

Hello Mark and Alistair,

When writing my previous mail I was thinking of this term-as-class
solution, and actually found some additional drawbacks it might be
honest to include in the doc Mark wrote (though I still favour this
solution in a first move ;-) )

Actually what could happen with the term-as-class solution is the
creation of several instances of Terms referring actually to the same
term. If we assume that the link between Terms and their lexical
representation is "hasLexicalForm" (friends terminologists, please
forgive me ;-)) we could have, e.g. in the end of an automatic thesaurus
extraction process applied to the thing underlying alistair's example in

X hasLexicalForm "grinding mill" (from concept A) and 
Y hasLexicalForm "grinding mill" (from concept B)

So a best practice guide would have to advise developers so that they
avoid implementing tools producing such results (e.g. searching amongst
all the term to see if one has the lexical form which correspond to the
one of the Term to be introduced)
An alternative, and of course more elegant, solution would be to declare
the OWL version of this propery as "inverseFunctional": if two instances
are linked to a same lexical form, then they are equivalent. The problem
is that if we do that for a datatypeProperty (which hasLexicalform would
be) then we end in OWL Full. Which would perhaps make this solution less




> -----Oorspronkelijk bericht-----
> Van: public-esw-thes-request@w3.org [mailto:public-esw-thes-
> request@w3.org] Namens Mark van Assem
> Verzonden: dinsdag 30 mei 2006 22:47
> Aan: Alistair Miles
> CC: public-esw-thes@w3.org
> Onderwerp: Re: Change proposal
> Hi Alistair,
> > and just haven't got round to it. Basically, what you've got below
> > to me like it should be broken into maybe 10 separate items for the
> > issues list. I keep meaning to have a go at separating the issues
> Given the lack of time I would recommend adding this to the same page
> the Change Proposal list under a header "Issues", just to record it
> those who will continue SKOS development after the TF's end.
> How and if the current text should be broken into parts shouldn't
> us now, as we are probably not going to change SKOS in this TF anymore
> anyway (and still earlier change proposals ahead in line [1]). Adding
> link to your doc with its more elaborate description would round it up
> nicely :-)
> Cheers,
> Mark.
> [1]http://www.w3.org/2004/02/skos/core/proposals
Received on Wednesday, 31 May 2006 13:40:07 UTC

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