- From: Michael Schneider <m_schnei@gmx.de>
- Date: Mon, 12 Mar 2007 14:25:04 +0100
- To: rhm@PioneerCA.com
- CC: semantic-web@w3.org
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
Received on Monday, 12 March 2007 13:25:14 UTC