Re: entailment review - part 2

On 12 Jan 2010, at 14:50, Birte Glimm wrote:

> 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 ...

My understanding is that an inconsistent AG implies nothing.
It's simply up to the extension for a particular entailment regime to define 
what happens in case on an inconsistent AG. I don't really see what's the hack here.

For this WD, I'd simply suggest to weaken the resp. Editor's note... 
but I have to dial in now and don't have a concrete proposal yet. ;-)

Axel

> ... 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:57:44 UTC