- From: Antoine Isaac <Antoine.Isaac@KB.nl>
- Date: Wed, 31 May 2006 15:39:46 +0200
- 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 [1] 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 interesting... Cheers, Antoine [1] http://lists.w3.org/Archives/Public/public-esw-thes/2006May/0022.html > -----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 looks > > 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 as > the Change Proposal list under a header "Issues", just to record it for > those who will continue SKOS development after the TF's end. > > How and if the current text should be broken into parts shouldn't worry > 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 a > 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