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: Mon, 12 Mar 2007 07:20:03 -0700
Message-ID: <3663163887724DEE8D3C98BBDE662489@rhmlaptop>
To: "Michael Schneider" <m_schnei@gmx.de>
Cc: <semantic-web@w3.org>

Michael, you said
But I do not see where's the connection between such a
decision tree and my example above?

The contrast I'm trying to emphasize is:
1. predefine lots of classes & apply these same classes in all situations.
(This seems to be what you advocate in your example.)
or
2. use such a decision tree, i.e.,
predefine very few classes,
define most classes dynamically, as appropriate for the current situation 
(context).
(This is what I advocate.)

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: Monday, March 12, 2007 6:25 AM
Subject: Re: Species as disjoint classes in ontology design [Was: Question 
on DL negation]


>
> Hi again, Dick!
>
> Richard H. McCullough wrote on Thu, 8 Mar 2007 17:31:
>
>> 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.
>
> Perhaps, there has been some misconception. In my "business ontology" 
> example I meant that there really /are/ classes. These classes are 
> effectively defined by the enterprise itself, in order to model the way 
> how they want to group their documents (an ontology expert would only help 
> them as a technical consultant in creating their ontology). The enterprise 
> might, for example, be interested in having one class containing 
> correspondence documents, and one class containing contract documents. 
> Now, if there is some correspondence document which is also taken as a 
> contract document, then this document will happen to be in both classes. 
> It is completely up to the enterprise if they think that this is ok for 
> them or not. If it is ok for them, then there simply won't be disjointness 
> of those two classes. This non-disjointness would then be in the very 
> heart of the enterprises' view on their document archive, and so this 
> non-disjointness has to be mirrored in the modeling of this view, i.e. the 
> created document ontology. There would be no meaningful way to introduce 
> full disjointness between all classes in this case without doing wrong 
> modeling.
>
> BTW: By "tags/properties" I meant two different methods to specify which 
> classes a document belongs to: Either by directly telling the class 
> ("tagging", or defining a "rdf:type" statement in OWL). Or indirectly, by 
> attaching a bunch of property/value pairs to the document. Then, if the 
> set of property/value pairs of the document matches the specification of a 
> given class, given by a set of property restrictions, that document will 
> belong to this class. This approach is perhaps somewhat more flexible (you 
> don't need to explicitly tell for each document in which classes it 
> exists), but you then have to apply OWL inference in order to see if a 
> given document is a member of a given class or not.
>
> > 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.
>
> Hm? This looks like you create a binary decision tree with the different 
> properties seen as boolean predicates (true if the property is attached to 
> the document, false otherwise) for the inner nodes of this tree. Of 
> course, this results in disjoint brother nodes in each case, simply by 
> construction. But I do not see where's the connection between such a 
> decision tree and my example above?
>
> Bye,
> 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 Monday, 12 March 2007 14:25:28 UTC

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