ISSUE-5: REPORTED: Doubts about n-ary datatypes

Part II...

> MAJOR RESTRICTION
> ==================
> 
> The data predicate facility only allows relations between values of 
> properties with the *same root individual* (i.e., subject).
> 
> So, while I can define the set of individuals whose (own) height is 
> greater than their (own) girth, but not the set of individuals whose 
> own height is greater than their spouses girth (which is most of us!).
> 
> It is possible to extend this support to comparisons between property 
> values rooted in different individuals (i.e., full concrete domain 
> support --- Calling Carsten), though one must take more care to 
> remain decidable. I think this would be a reasonable thing to 
> support, but it's a definite extension on OWL 1.1.

I agree with both: first, this is very useful expressive power and
second, (in contrast to unary vs. n-ary datatypes), this *is* a
significant extension.

What we know about it is the following:

- The standard definition of "conforming" does no longer work, i.e., there
   are conforming datatypes that lead to undecidability if plugged into OWL
   with the extended datatype operator that you mention. An example is:

   the rationals with =0, equality, and incrementation

- We know how to adapt the notion of conformity such that it works with
   the extended operator. I don't want to go into much detail here, let's
   just call this omega-conformity. Omega-conformity is much stronger than
   conformity. Here is an example of a datatype group that is omega-
   conforming:

   the rationals with all binary comparisons, i.e., =, <=, >=, etc

- In principle, we know how tableau algorithms can deal with the extended
   operator. A combination with full SROIQ has not been done (only with SHIQ),
   but it should be feasible. There are certainly no implementations. On the
   other hand, we are not defining a standard here for the next 5 months,
   but for many years to come. So the question is whether we really only
   want to include things that are already implemented.

In summary, we are again faced with a choice here:

1. there are applications that need datatypes that are not conforming
    (i.e. because addition is needed), but that do not need the extended
    operator

2. there are applications that need the extended operator, but are
    happy with omega-conforming datatype groups.

Thus, it does not seem reasonable to admit only omega-conforming
datatypes in general. On the other hand, I think we should also not
easily discard the idea of the extended operator.

Another issue is that there are a bunch of different design choices
for how exactly the extended operator should look. Anyway, enough for now.

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 Friday, 9 November 2007 09:44:38 UTC