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

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

From: Richard H. McCullough <rhm@PioneerCA.com>
Date: Thu, 8 Mar 2007 17:31:24 -0800
Message-ID: <0EA830D5080145738955FC7DE29CDB3C@rhmlaptop>
To: "Michael Schneider" <m_schnei@gmx.de>
Cc: <semantic-web@w3.org>

Michael
I completely understand what you said, but I disagree with your conclusion

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.

I can use the same tags/properties with a different processing method.
This is the approach I use with my mKE program.
1. Don't predefine any classes.
2. When you want to search for documents, classify (partition) the
documents using one property at a time -- this gives you a collection
of nested taxonomies -- disjoint at all times.

mKE can quickly transform one taxonomy into another taxonomy,
using its built-in commands
    integrate
    differentiate
    classify
    measure (custom method provided by user)

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: <semantic-web@w3.org>
Sent: Thursday, March 08, 2007 5:09 AM
Subject: Species as disjoint classes in ontology design [Was: Question on DL 
negation]


>
> [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
>
>   http://ontoworld.org/wiki/Semantic_MediaWiki
>
> 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.
>
> Cheers,
> Michael
>
>> 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
>>>
>>>
>
>
>
>
Dick McCullough
mKE do enhance od "Real Intelligence" done;
knowledge := man do identify od existent done;
knowledge haspart proposition list;
http://mKRmKE.org/
Received on Friday, 9 March 2007 01:33:16 UTC

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