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

Received on Monday, 12 March 2007 13:25:14 UTC