Re: Proposed change to the OWL-2 Direct Semantics entailment regime

Your argument is all about the systems Manchester, Oxford, and your company are implementing and their users.
You are completely forgetting the support of the OWL profiles with lower expressivity (such as OWL-QL), in which distinguished variables are crucial in applications (DB queries, information integration) and the current spec would leave them out and the cost to adapt would be big. 
As I said, I also don't see how OWL-DL systems with UNA can easily adapt.
I also got this comment from the RACER implementors: "The standard might explicitly allow implementation to impose restrictions on the use of non-distinguished vars, and then I think including them will not be harmful."
I will collect the opinions of all the system implementors of OWL-QL I know of (Rome, Bolzano, IBM, CNR). Be sure that they will agree with me. Should we really play this game, rather than trust each other?
cheers
--e.

On 5 Dec 2010, at 18:41, Bijan Parsia wrote:

> On 5 Dec 2010, at 17:06, Enrico Franconi wrote:
> 
>> OK, so you oppose the extension.
>> The original question was directed to OWL implementors, and so I understand you speak with this hat on. Could you please specify how can the extension be bad for you? I'd be interested to hear why leaving many more opportunities to other implementors to meet the standard and the long-standing theory can hurt you.
>> cheers
>> --e.
>> 
>> The reason to oppose the extension being, from your side?
> 
> Obviously, you know where I (and Manchester) stand.
> 
> I think you are coming from the perspective of "What's one more?" as if adding sanctioned regimes is costless. As long as you persist with that perspective I think you are going to fail to understand a lot of people, or think that we're being perverse and contrary. But we really aren't being. Just as there was picking and choosing of profiles (hence the exclusion of the very useful and (at least one user) requested horn-SHIQ) in order, in part, to keep them to a manageable number, so too is it reasonable to pick and choose regimes. This can lower costs (both for the specification process -- CR, remember?) and for implementors who strive for "coverage" of W3C specs. It also lowers costs for customers by reducing the amount of stuff they must sort through, learn, make judgements about. Furthermore, it encourages convergence of behavior (or, at least rationalization of behavior).
> 
> By not including your favoured regime, we simplify things considerably (variables behave uniformly, queries are more portable across regimes, answer sets grow more monotonically, etc.)
> 
> Even if we ditched the skolemization of BNodes in data, I still think the case for only having one kind of query variable is very compelling. The performance implications are profound and we make it the case that *reasonable* implementations can handle arbitrary sparql queries across all specified regimes. No "This query has an inequality and thus won't work with FaCT++". And that's what many engines do today exclusively (KAON2, Racer, HermiT AFAIK).
> 
> Now, I think both having only distinguished variables and skolemizing BNodes is the superior choice even though the latter imposes some implemetnation burden and "willfully violates" some specs. The gain is that we can sensibly  query more RDF data in a way that is consistent with their experience of those queries evaluated on RDF and RDFS engines. We have a simple, uniform story for the core cases of the entire stack.
> 
> Adding a kind of expressivity that adds new concepts,  complicates the results picture, *and* introduces more classes of query that *in principle* run on some engines but not others (due to undecidability) requires a compelling, perceptible value add for users. The value add of undistinguished variables is, at best, very subtle. The value add for the implementors who want this is pretty low too, afaict: First, given that, you say, they impose UNA they aren't *too* concerned with spec conformance. Second, they can brag about being more expressive and be mostly conforming anyway. This shouldn't be a make or break trade off for most implementors.
> 
> I think having non-distinguished variables, etc. as community extensions is perfectly fine. So is returning class expressions as variable bindings. Or a more expressive sort of distinct (e.g., leaned answer sets). There are lots of things going into SPARQL today that proceeded that way.
> 
> Cheers,
> Bijan.

Received on Sunday, 5 December 2010 18:06:46 UTC