- From: Richard H. McCullough <rhm@PioneerCA.com>
- Date: Mon, 12 Mar 2007 07:20:03 -0700
- 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