W3C home > Mailing lists > Public > semantic-web@w3.org > March 2007

Species as disjoint classes in ontology design [Was: Question on DL negation]

From: Michael Schneider <m_schnei@gmx.de>
Date: Thu, 08 Mar 2007 14:09:46 +0100
Message-ID: <45F00B1A.2050002@gmx.de>
To: rhm@PioneerCA.com
CC: semantic-web@w3.org

[changed subject (please rename, if you do not agree with this subject)]
[removed public-owl-dev from CC-list, because no development issue]

Hi, Dick!

Richard H. McCullough wrote on Wed, 7 Mar 2007:

 > I'm not saying that disjointness is assumed, I'm saying that
 > disjointness is a fact.
 > In real-world concept formation, all species of a genus are mutually
 > exclusive
 > and mutually exhaustive.
 > I don't know what terminology you use.  Perhaps you would call this
 > a taxonomy, instead of an ontology.
 > I consider non-disjointness to be "bad", because that means that units
 > in the intersection have multiple genii -- which means you are mixing
 > together two different definitions (contexts) for these units.

There are definitely many domains, which are best modeled taxonomically, 
so that every class (the "genus") is subclassed in a way that its child 
classes (the "species") are regarded to be pairwise disjoint. A 
zoological taxonomy would be one example. So I am not going to object to 
this. What I was about was that there are also other important cases 
where this modeling principle isn't adequate anymore.

Imagine for instance some enterprise, which owns a big archive 
containing all the documents which the enterprise has ever dealt with. 
They now want to classify all those documents for easy and flexible 
retrieval, and perhaps other processing tasks. Putting the documents 
into a single filesystem-like hierarchy, where every document will live 
in exactly one leaf-folder, doesn't really work. Every document can be 
regarded according to different characteristics. So a better way would 
be to define a bunch of classes, which stand for grouping criteria 
important to this enterprise, and then put each document into whatever 
class it belongs to (technically, perhaps, by marking the documents with 
according tags/properties). Now, neither will this result in a real 
taxonomy of classes, nor will there always be disjointness between 
classes (at least not /intended/ disjointness). The different classes 
should better be seen to live all side by side on the same (top)level, 
at best there will be some local hierarchies, and there might also be 
some additional (semantical) relations defined between those classes, to 
later support some computational processing.

Now, I really would call something like this an "ontology", and I 
believe that such kinds of "business ontologies" will become a very 
important issue within a few years.

Yet another example: If you like, have a look at


This is a test platform, an experimental Wiki, based on the new 
SemanticMediaWiki software, which is meant to be the successor of the 
MediaWiki software, which Wikipedia is based on. There, you can see how 
people create "Categories" for articles and build sub-category 
relationships between them. There is no real planning in this, like 
there is no real planning in the creation of Wikipedia articles. The 
category system just grows evolutionary. This category system actually 
/is/ a taxonomy, but you would not really expect all the subcategories 
of some category to be intended to be disjoint. Nonetheless, I strongly 
believe, that the (dynamic) result of such a "wild" taxonomy creation 
process will be of great value.

So to put it together: There will always be many circumstances, where a 
taxonomy with disjoint classes is a proper modeling decision, but there 
will also be important circumstances, where a disjointness assertion 
would be not adequate, even wrong, or at least it would be hindering 
(Semantic Wikipedia). There are even circumstances where grouping 
classes in a taxonomic way would not be a good modeling (my business 
example above). The important point is that a Semantic Web ontology 
language like OWL has to support each of the above mentioned types of 
modeling. It cannot simply introduce implicit disjointness assumptions. 
Whenever a disjointness assumption is really adequate, it should be 
stated explicitly.


> Dick McCullough
> mKE do enhance od "Real Intelligence" done;
> knowledge := man do identify od existent done;
> knowledge haspart proposition list;
> http://mKRmKE.org/
> ----- Original Message ----- 
> From: "Michael Schneider" <m_schnei@gmx.de>
> To: <rhm@PioneerCA.com>
> Cc: <bparsia@cs.man.ac.uk>; <matthew.williams@cancer.org.uk>; 
> <semantic-web@w3.org>; <public-owl-dev@w3.org>
> Sent: Wednesday, March 07, 2007 6:22 AM
> Subject: Re: Question on DL negation
>> Hi, Dick!
>> Richard H. McCullough wrote on Tue, 6 Mar 2007:
>>> Your BTW3 really intrigues me.  You say that "disjointness" increases the 
>>> "complexity" of a DL, presumably a "bad" thing.
>> I wrote:
>>>> BTW3: I cannot see a feature "disjointness", neither for concepts, nor 
>>>> for roles. Doesn't the addition of disjointness adds significantly to 
>>>> the complexity of a DL? I thought that at least it would, when adding 
>>>> concept disjointness to OWL-Lite. Or can disjointness be expressed in 
>>>> terms of the other mentioned features? At least, I do not see how this 
>>>> were possible for /role/ disjointness, when only having the features of 
>>>> OWL1.0.
>> By "complexity", I really meant /computational/ complexity, in the sense 
>> of:
>>   http://en.wikipedia.org/wiki/Computational_complexity_theory
>> This is a general runtime (or space) measure for a given computational 
>> problem.
>> The complexity navigator at
>>   http://www.cs.man.ac.uk/~ezolin/logic/complexity.html
>> which Bijan pointed me to, shows the computational complexity (if already 
>> known) for the (computational) problem of deciding, if a given ontology is 
>> satisfiable or not. You can choose the different language features of the 
>> description logic you are interested in, and then you can see how the 
>> complexity class changes.
>> Adding some language feature to a given language, for instance the feature 
>> "class disjointness" to OWL-Lite, always has the /potential/ to increase 
>> the computational complexity of the satisfiability problem, because every 
>> reasoner for the augmented language (OWL-Lite+disj) now has to solve this 
>> problem for all possible ontologies of the old language (OWL-Lite) PLUS 
>> all those ontologies which contain the additional language feature 
>> (disjointness axioms). But such an increase in complexity doesn't always 
>> happen, I just /supposed/ that this was the case for the step from 
>> OWL-Lite to OWL-Lite+disjointness.
>> Unluckily, I cannot check this with the navigator, because there is no 
>> such "concept disjointness" checkbox. It seems that all I can do is 
>> comparing the complexity classes of OWL-Lite and OWL-DL, which is an 
>> upper-language of OWL-Lite+disj:
>>    * Complexity( OWL-Lite )  = ExpTime (complete)
>>    * Complexity( OWL-DL )    = NExpTime (complete)
>> And according to
>>    http://en.wikipedia.org/wiki/EXPTIME
>> it is currently unknown if ExpTime and NExpTime are different or not (most 
>> probably different, so this approach does not really provide me much 
>> help).
>> Anyway, you see now that I had a very specific (and very technical) notion 
>> of "complexity" in mind.
>>> In real-world concept formation, all species of a genus are disjoint,
>>> and I believe this is a "good" thing -- a major factor contributing to 
>>> the
>>> "simplicity" and the "power"of hierarchical classification.
>>> Perhaps it's only partial disjointness that is "bad"?
>>> I consider any intersection between species to be "bad".
>> But you can use DLs like OWL to model whatever you want, not only "natural 
>> species". And when comparing two general concepts, you cannot simply 
>> assume disjointness (it would often be wrong), you instead have to 
>> explicitly demand it, by adding a disjointness axiom. But, perhaps, I 
>> misunderstood, what you meant here?
>> Cheers,
>> Michael
Received on Thursday, 8 March 2007 13:10:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:55 UTC