Re: entailment review - part 2

I think this might be used as another hack, but I can't believe that
this is intended and it looks like a hack. If we do that, then an
inconsistent AG implies that there is no scoping graph and, in the
absence of a scoping graph, condition 3 never applies and I can just
define whatever I want as query answer. I have to think how that can
be done properly though. The problem is that without a consistency
check, we don't know whether we are in this situation and if we are,
condition C1, which limits answers, is not usable as it is now because
it depends on SG. This would mean that we either have to reformulate
C1 so that it is independent of SG or to have different conditions for
consistent and inconsistent graphs (without necessarily being able to
distinguish in which situation we are).

I don't see the editorial note as wrong or too strict though because
at the moment, it is assumed that there is a scoping graph and the the
scoping graph can be inconsistent. The entailment regimes assumes that
SG is always equal to AG apart from bnode renaming. This means that if
AG is inconsistent, then SG is defined and SG is E-equivalent to AG,
but SG is not consistent as it would be required. Your suggestion is
to not have an SG at all.

Birte




2010/1/12 Axel Polleres <axel.polleres@deri.org>:
>
> On 12 Jan 2010, at 12:58, Birte Glimm wrote:
>
>> Axel,
>> we've spend some more thoughts on the inconsistency issue here.
>>
>> >>> > I am not sure, actually, condition 1. doesn't require consistency of SG, it only says:
>> >>> > "The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG."
>> >>> >
>> >>> > So, hmmmm, *actually*, this wording actually doesn't limit at all what the scoping graph to an
>> >>> > inconsistent graph is: In fact, this even seems to let open that the SG for an inconsistent
>> >>> > graph is e.g. empty, implementation dependent, etc.
>>
>> I now discussed that with Boris (Ian is super busy at the moment) and
>> in our understanding the SG is at best undefined if AG is inconsistent
>> or, rather, there is no scoping graph in that case.
>
> Yes indeed, but that is just what I meant: there is no condition on the scoping graph if AG is inconsistent.
> To my understanding, this allows us "to do what we want in case of inconsistencies, we just have to specify it:
> This understanding doesn't follows from the condition itself, but from that sentence right before the conditions:
>
> "The effect of a query on an inconsistent graph is not covered by this specification, but must be specified by the particular
> SPARQL extension."
>
> In particular, this doesn't preclude that an entailment regime specifies an SG even
> for inconsistent AGs, or say that it is implementation-dependent: if consistency is checked by the
> implementation we raise an error, otherwise we can specify a consistent SG. This would seem to be perfectly
> inline with what we currently have and make the resp. editorial note unnecessary.
>
>> Thus, if AG is
>> inconsistent, then you could do something that does not use a scoping
>> graph, but if you do that, you violate condition 3 that basically says
>> that SG must entail the answers.
>
> Still, slight disagreement here, because I really read here that you CAN
> specify a consistent SG for such cases, as long as you say how. And even if not, again the condition is void, since it only applies to "for any scoping graph SG" (= forall), so if there is no scoping graph, again the condition doesn't apply...
>
>> Condition 3 cannot be satisfied if
>
> ... ex falso quod libet.
>
>> you have no SG or SG is undefined and you cannot have an SG because SG
>> would have to be consistent (E-equivalence).
>>
>> Birte
>
> best,
> Axel



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Tuesday, 12 January 2010 14:51:27 UTC