Re: AllDisjoint in RDF mapping

> actually, I do have a little problem with disjointUnion - the problem is 
> that this would be the first OWL feature (I think) that combines two 
> definitions at the same time -- so if I say
> 
> Class A == DisjointUnion (B,C,D)     (with the obvious meaning, no 
> syntax implied)
> 
> then I am asserting both the definition of Class A AND the fact that 
> B,C, and D are disjoint.  From a human point of view, I wonder if it 
> isn't better to avoid the syntactic sugar and have this remain as two 
> assertions
> 
> Class A= Union(B,C,D)
> AllDisjoint(B,C,D)
> 
> just seems to me that the clarity in the modeling would be clearer

Let me add another perspective to this discussion.  I actually like the 
idea of owl11:disjointUnionOf, because it supports clean round-tripping 
between the internal representation and a user interface.  What do I 
mean?  The goal should be to have some mechanism that allows users to 
enter and display a disjoint union, e.g. in

   A = B xor C xor D

assuming xor represents disjoint union.  If we had no 
owl11:disjointUnionOf, then a tool would need to walk the ontology to 
discover whether any disjointness axioms exist between B, C and D.  This 
would be a very time-consuming operation and a lot of triples would need 
to be touched.  For example in the case of owl11:AllDisjoint we would 
need to look for rdf:first triples that have B, C or D as object and 
then walk up the reference tree - not very scalable for database 
projects because the triples would appear very similar to 
owl:intersectionOfs and other rdf:Lists.

Also, how would people edit such expressions?  If they enter "B xor C 
xor D" I assume this would create an owl:unionOf and an 
owl11:AllDisjoint under the hood.  But then these two are separate 
entities, and I wonder what should happen if the user deletes the xor 
row - should the AllDisjoint be deleted as well?  What happens if we 
have A = B xor C, and AllDisjoint(B, C, D) ?

Needless to say, the disjointUnionOf "syntactic sugar" significantly 
reduces redundancy in a file, because we do not need to list the same 
collection of classes twice.

So, while I agree that it may be nice to minimize the number of 
different ways to express semantically equivalent things, I do think 
that owl11:disjointUnionOf has some benefits, especially since (as Evan 
states) this is a very common design pattern known to the object world.

In defense of those against owl11:disjointUnionOf, removing the new 
keyword would improve compatibility with OWL 1.0-aware tools - 
owl:unionOf would need to be used so that tools can at least get parts 
of the semantics.

Holger

Received on Monday, 26 February 2007 18:41:41 UTC