RE: Change proposal

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