- From: Carsten Lutz <clu@tcs.inf.tu-dresden.de>
- Date: Fri, 09 Nov 2007 10:44:25 +0100 (CET)
- To: public-owl-wg@w3.org
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