Re: entailment review - part 2

Concerning today's resolution, I suggest the following rewording in the Editor's note:

"A consequence of not requiring a consistency check is that in the case of an inconsistency, not all conditions on extensions of basic graph pattern matching are satisfied. For example, the first condition

The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG.
explicitly mentions that the scoping graph must be E-equivalent (RDFS equivalent in this case) to the active graph and that AG must be consistent. Clearly that is not possible if the active graph is inconsistent. One way around this would be to specify an entailment regimes for a subset of RDFS that cannot express inconsistencies, e.g., be defining well-formed graphs for the regime as those that contain only syntactically valid rdf XML literals."

--->

"A consequence of not requiring a consistency check is that in the case of an inconsistency, not all conditions on extensions of basic graph pattern matching apply. For example, the first condition

The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG.

explicitly mentions that the scoping graph must be E-equivalent (RDFS equivalent in this case) to any consistent AG. The behavior for inconsistent active graphs is unspecified. One way around this would be to specify an entailment regimes for a subset of RDFS that cannot express inconsistencies, e.g., be defining well-formed graphs for the regime as those that contain only syntactically valid rdf XML literals. Several other alternatives, including different, implementation-dependent behaviors for systems that do/do not check consistency are currently being under discussion in the working group." 



best,
Axel


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 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 17:04:31 UTC