Re: issue in OWL SS&FS and bug in mapping from RDF graphs

I have a related comment here - the requirement that class constructors in OWL 2 Functional such as 

ObjectIntersectionOf(arg1 arg2 ...)  

(and related connectives) have to have at least 2 arguments which are not structurally equivalent makes it difficult for applications to programmatically generate OWL 2 Functional, especially if  
the ontology is generated by an automatic translator. Often, such translations will be lossy - e.g., if the original FOPL version of the ontology contained a conjunction 

And(arg_1 ... arg_n) 

then this might have been translated into 

ObjectIntersectionOf(arg'_1 ... arg'_n) 

by the translator, with arg'_i's being the translated variants of the original arguments. Now, suppose all these arg'_i's turn out to be structurally equivalent in OWL 2 (because the translation 
was lossy). Then we will have produced 

ObjectIntersectionOf(arg'_1); 

and this is considered illegal OWL 2 Functional syntax, according to the spec. You might say - well, bad translator program! It should not generated bad OWL 2 Syntax. However, it should be 
mentioned that checking the subexpressions for structural equivalence in such a conjunction is not an easy task at all. As those subexpression can be nested, it requires some form of class 
expression simplification to get it right (as ObjectIntersectionOf's etc. might have to "dissappear"). 

My question is - should it really be that difficult to generate syntactically correct OWL 2 Functional? 

We encountered that problem when we fed a programmatically translated large ontology which contained ObjectIntersectionOf's with all conjuncts being structurally equivalent into the OWLAPI, 
which classified the ontology as OWL Full then (perhaps it should have been an OWL 2 syntax error? might be an OWLAPI bug, don't know). 

IMHO, requiring at least 2 non-structurally equivalent arguments in the Spec for these constructors makes programmatic ontology generation very complicated, especially for developers that cannot 
exploit the OWLAPI (e.g., developers not using  Java). I am not sure if ontology developers are willing to implement structural equivalence checkers and class expression simplifiers only to 
ensure that correct OWL 2 Functional syntax is generated - this might be a too high price to pay. 

Regards,

Michael Wessel


> Since the spec ways that the DisjoinedClasses takes a set of classes as
> arguments, then stating DisjointClasses( ex:foo ex:foo ex:bar ) is
> actually impossible — that is, that axiom is not a structurally valid OWL
> 2 DL axiom. Hence, there is no need to require the arguments in the
> structural spec to be different. The only thing we could do is maybe
> clarify the syntax and say that DisjointClasses( ex:foo ex:foo ex:bar ) is
> then syntactically incorrect. That would obviate the need for 2/ since an
> RDF graph containing a DisjointClasses axiom with structurally equivalent
> classes would also be syntactically incorrect.
> 
> Regards,
> 
> Boris

Received on Saturday, 12 April 2014 02:06:38 UTC