Re: ISSUE-79 (EL++): REPORTED: EL++ Variants

On Wed, 28 Nov 2007, Bernardo Cuenca Grau wrote:
>
> The variant of EL++ included in the Tractable fragments Document is based on 
> the one in the 2005 IJCAI paper by Carsten and others:
>
> http://lat.inf.tu-dresden.de/~clu/papers/archive/ijcai05.pdf
>
> At the time of writing, however, I also included domain and range axioms in 
> the description of the fragment. Obviously domain  axioms are directly 
> expressible in EL++, as described in the paper above, but this is not the 
> case with range axioms. At the time of writing, I had some informal 
> discussions with people, including the people in Dresden and my understanding 
> was that range axioms, even if not directly expressible could be easily added 
> and handled while preserving the nice properties of EL++.
> It seems from what Carsten says that this is not the case and therefore the 
> variant of EL++ in the tractable fragments document  seems to be broken.

Right, because of an interaction with complex role inclusions.

> I have a question, however, concerning the  interaction between range 
> restrictions and role inclusion axioms. Note that the EL++ version in the 
> fragments document does impose some restrictions in the use of (complex) role 
> inclusion axioms, namely the same ones as SROIQ imposes.

The document is a bit confusing in that respect stating that "The
language EL++, as presented here, is not a fragment of OWL DL, since
it provides complex inclusion axioms on Object Properties.", but also
"in particular, this document enforces the regularity condition on
complex property inclusion axioms required in OWL 1.1. With this
restriction, EL++ is a fragment of OWL 1.1."

> My question is 
> whether these restrictions are not sufficient.  If they do not suffice, I 
> agree with Carsten in that identifying a variant of EL++ that allows for 
> domain and range and imposes reasonable constraints in the use of role 
> inclusion axioms would be  a good thing to have and that version should be 
> the one included in the document.

I suppose that they are sufficient, but I never checked the details. 
Actually, these restrictions were precisely what I meant in my last
mail when talking of a new variant. So there is actually no disagreement
here, only somebody has to verify that things remain tractable. I'll
try to do that until the Manchester F2F.

> I think that the issue whether this fragment which should be called ``OWL 
> Light" is a much more controversial one. In principle I think there should be 
> no single ``OWL Light'', but a reasonable menu of choices for such an OWL 
> Light that each particular user could pick depending on his application 
> needs.

I disagree for the reasons given in my mail(s). Anyway, we should maybe
not mix these two issues.

greetings,
 		Carsten

--
*      Carsten Lutz, Institut f"ur Theoretische Informatik, TU Dresden       *
*     Office phone:++49 351 46339171   mailto:lutz@tcs.inf.tu-dresden.de     *

Received on Wednesday, 28 November 2007 20:55:55 UTC