Re: Clarifications about Protege

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications about Protege

Olivier Dameron
On Thu, 19 Jan 2006 15:48:51 +0100, Raj M Verma <[hidden email]>
wrote:

> My questions are...
>
> Does the disjointedness in Protege work heirarchically? I mean, If we
> explicitely mention that Concept1 and Concept2 are disjoint with each other,
> then does that mean that subconcepts of Concept1 are also disjoint from the
> subconcepts of Concept2, implicitely? (from Protege's perspective)

Yes it does (fortunately :-)

> For example, consider Human and Bush as two disjoint concepts in the same
> level, where Male and Female are subconcepts of Human that are disjoint from
> each other, and Saddam and Laden are the disjoint subconcepts of Bush.
> Suppose we explicitely mention these disjointedness between Human and Bush,
> Male and Female, Saddam and Laden... Now the question is, does it imply that
> Saddam and Laden are also disjoint from Male and Female??

In this case, yes.

> I believe that, 'in reality', most of the Onotlogies for practical purposes,
> will have to specify a lots and lots of disjointedness. So why don't we make
> the disjointedness between (siblings of) every concept and subconcept in the
> entire Ontology as default, that only non-disjointedness should be
> explicitely mentioned.

I guess that one aspect of the possible answer here would be
scalability: if A and B are said explicitely to be not disjoint, then
the logic consequence is that you will have to state which subconcepts
of A are not disjoint with which subconcepts of B. You would have to do
so transitively (i.e. for each subconcept of A say with which
subconcepts of B of subconcepts of the subconcept of B the are not
disjoint), and you would have to do so "horizontally" if the overlap
concerns more than two concepts (and most of the time it does).

As an example, the FMA ontology of anatomy has a concept Breast, with
obviously two disjoint subconcepts LeftBreast and RightBreast. But it
also has two other disjoint subconcepts MaleBreast and FemaleBreast. 1.
If disjointness is not the default, you need to add two constraints to
your superclass-subclass hierarchy:
- disjoint(LeftBreast, RightBreast)
- disjoint(MaleBreast, FemaleBreast)
2. If disjointness were the default, you would have to add at least the
following constraints:
- nonDisjoint(MaleBreast, LeftBreast)
- nonDisjoint(MaleBreast, RightBreast)
- nonDisjoint(FemaleBreast, LeftBreast)
- nonDisjoint(FemaleBreast, RightBreast)
Now of course, this was just a simple example. If you think about the
class Finger, which is still not that complicated, you will have two
disjoint subclasses LeftFinger and RightFinger, but also another set of
mutually disjoint subclasses {Thumb, Index, MiddleFinger, RingFinger,
LittleFinger}. Non-disjointness has to be a binary relationship,
whereas Disjointness can take as many arguments as you want (but 2 or
more is better). Thus, i think it would be easier to describe fingers
using disjointness rather than non-disjointness.

> Consider some anotomical Ontology(FMA for instance)... when we want to
> describe about the parts of a human body, then each and every part is
> different from the other, no matter in which heirarchical position of the
> taxonomy they are... So here we have to explicitely mention the
> disjointedness for each and every simple concept... this is simply too much
> work for the knowledge engineers using the editor...

Not that much work:
- you only need ti state disjointness between sibling concepts
- there is a nice button (or you can also use the owl-wizards by the
Manchester team) for making all the subconcepts of a concept mutually
disjoint in one click (and another button for making a concept disjoint
from all its siblings)

> I can't imagine the Ontologies where we really need a great deal of
> non-disjointedness between different concepts of the terminology... there
> could be some top-level or upper-level ontologies, but I'm still skeptical
> about using high degree of non-disjointedness in those things...

It is because you read the ontology as a human and not as a computer :-)
If you look at the FMA (frame-based), then you find the four
subconcepts of Breast that we mentionned previously. For you, it is
obvious that LeftBreast and RightBreast are disjoint, just like
LeftBreast and RightBreast are disjoint. Yet, from a purely logical
point of view, there is nothing to distinguish them, as I don't think
that frames have this explicit notion of disjointness /
non-disjointness. The same ontology in owl would make it explicit.

I don't think disjointness should be restricted to upper level
ontology: Matthew Horridge great owl tutorial makes this necessity very
clear about mundane things as pizzas.

> I'll be glad if someone can discuss abt the (dis)advantages of this default
> non-disjointedness in Protege... I know that it is the essence of Open World
> Assumption that comes along with OWL based on Description Logical reasoning,
> but when programming it, I think we can somehow make it more
> devising-ontology-with-protege-friendly ;) what do you think?

Agreed.
We should add these points to the wiki.
I will try to do it by the end of next week if nobody does it before :-)

Olivier
-------------------------------------------------------------------------
To unsubscribe go to http://protege.stanford.edu/community/subscribe.html