RE: Astounding silence about same-ness Re: Concept Equivalence, IFPs, skos:subjectIndicator and owl:sameAs

Bernard,

With large delay, my 2 cents on this problem

> -----Oorspronkelijk bericht-----
> Van: public-esw-thes-request@w3.org [mailto:public-esw-thes-
> request@w3.org] Namens Bernard Vatant

> Very good question. This issue of
> sameness-which-should-not-use-owl:sameAs is something I have kept
> nailing for quite a while, and once again recently in this forum [1].
> But, curiously enough, this kind of question - which I consider the
most
> important for Semantic Web scalability, is always meeting on SW lists
an
> astounding silence.

I actually don't know if such things are that vital now for the SW
community: owl:sameAs and owl:equivalentClass together already solve
quite a lot of problems from a knowledge representation point of view.

The problem is that SKOS (with its 'indirection') deals with
'classes-that-are-not-really-OWL-classes' and therefore have problems
that are more specific.
[though perhaps all the research efforts on smushing will result into
people realizing that owl:sameAs may have also some lacks with respect
to 'true' individuals (like people)]

> I have tried several explanations:
> 
> 1. The question does not make sense
> 2. The answer is too obvious, so people don't care to answer
> 3. The question is too complex, so people don't dare to answer
> 
> Neither is satisfying.
><snip> 
> So, I don't know. Something like a taboo, maybe.

I would say that it could be a mixture of 2 and 3 (certainly not 1)
2. You can always coin your own bernard:isEquivalentSubject property,
with the semantics that you will in your own application (e.g. the
documents who a have the first concept of an bernard:isEquivalentSubject
as subject will also have the second concept as subject). And if you are
really desperate and will to turn to some standardized property, you can
start using skosmapping:exactMatch, or even asserting dual skos:broader
(X skos:broader Y + Y skos:broader X).
3. Of course my solutions are far from optimal, and you might want to
have a standard like SKOS accounting for concept equivalence in a way
similar to the one it deals with concept hierarchy. (there might be
actually cases even within one concept scheme which could motivate it).
Then you have to wait for a more mature version, which you could even
have contributed by sending use cases and requirements ;-) 

Antoine

PS: regarding your dc:subject + blank node combination, this could do
the trick, of course. But 
(1) you will have anyway to create some rules that will enable your
system to behave the way you want it to each time it encounters a graph
like ((x, dc:subject, _:b), (y, dc:subject, :_b), [plus triples
involving x and y corresponding to the situation you want to derive
information from])
(2) in your data you will have graphs like ((doc, skos:subject, x), (x,
dc:subject, :_b)), which implies ((doc, dc:subject, x), (x, dc:subject,
:_b)). Not formally wrong, but it does not look like the ideal practice
you want to advice to newcomers.

Received on Wednesday, 22 November 2006 10:33:34 UTC