From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>

Date: Wed, 13 Jan 2010 14:14:23 +0000

Message-ID: <492f2b0b1001130614g5f3a772er5f2eb5bd0823562d@mail.gmail.com>

To: Axel Polleres <axel.polleres@deri.org>

Cc: SPARQL Working Group <public-rdf-dawg@w3.org>

Date: Wed, 13 Jan 2010 14:14:23 +0000

Message-ID: <492f2b0b1001130614g5f3a772er5f2eb5bd0823562d@mail.gmail.com>

To: Axel Polleres <axel.polleres@deri.org>

Cc: SPARQL Working Group <public-rdf-dawg@w3.org>

The anchors seem to be different for Firefox and Safari maybe because they are automatically generated. I hope that is no longer the case in the published versions. > two last minimini remarks: > > - some small XML markup error in the editor's note now ( <p> </p> appear in the brower) That didn't show up in Safari, but I saw it in Firefox and it is fixed now. > - subsections of already informative sections probably don't need to be marked informative again (section 3.1, section 3.1.1). That also applied to the subsections of Section 6.1 and I fixed that now. Thanks for your help and comments, Birte > best, > Axel > > > On 13 Jan 2010, at 12:24, Birte Glimm wrote: > >> [snip] >> > "1 -- The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG." >> > >> > is not a problem, because it only applies to consistent AG, so E-equivalence is not required for inconsistent AGs (i.e. simple equivalence, >> > as we define it now is a viable alternative to define SG >> > in that case, as much as leaving it undefined would be.) Agreed? >> >> It took me a long time, but I think I can now agree. But that >> condition is exactly where the disagreement was. I'll rephrase the >> condition to make it clearer because that's how I think it should be >> understood following your argumentation: >> "The scoping graph, SG, for a consistent active graph AG is uniquely >> specified and is E-equivalent to AG." >> Right? >> I parsed it more like: >> "The scoping graph, SG, must correspond to the active graph AG and it >> must be consistent, uniquely specified, and E-equivalent to AG." >> That's where I went wrong. >> >> The other conditions are clear then. >> >> [snip] >> >> This made me think further about entailments from inconsistent SGs and >> unfortunately I think we do need stronger conditions for inconsistent >> graphs. The current current definition is motivated by the fact the >> systems might just not notice the inconsistency, in which case the >> query answers can be incomplete, which is acceptable IMO. >> Strictly speaking, however, nothing prevents me from implementing an >> algorithm that generates infinite answers in that case and still >> satisfies the conditions because everything is trivially entailed, C1 >> only limits bnodes, and C2 only restricts subjects. So if I have in AG >> (and SG): >> :a :b :c. >> :d :e "<". >> :e rdfs:range rdf:XMLLiteral. >> then this graph (trivially) also entails: >> :a :b "a". >> :a :b "aa". >> :a :b "aaaa". >> ... >> and a query such as >> SELECT ?o WHERE { :a :b ?o } >> can generate infinite answers without violating C1 or C2. This is not >> what we had in mind when we made consistency checks non-mandatory, but >> we might have to change to your restriction C2 which restricts not >> only subjects but also predicates and objects. >> >> [snip] >> >> I basically took the below suggested text plus adding the condition >> explicitly, see >> http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml#id40144238 >> >> > Reflecting what I wrote above, I would suggest to add here: >> > "The condition does not apply for inconsistent AGs. >> > The current understanding of the WG is that this condition does thus not >> > restrict on how we define SG in case of an E-inconsistent AG and at >> > current we just define SG the same way as for consistent graphs." >> > >> >> One >> > >> > and here add: "alternative" >> > >> >> way around this would be to define SG only if AG is consistent. If >> >> AG is inconsistent, one then has to specify conditions independent of >> >> SG that prevent infinite answers (an inconsistent graph trivially RDFS >> >> entails any RDF triple). Another possibility would be to specify an >> >> entailment regime for a subset of RDFS that cannot express >> >> inconsistencies, e.g., by 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." >> >> >> > >> > Does that work for you? >> Yes. >> >> >> Sorry for being so picky with this, but I think it is quite essential >> >> to get that right and I find the current discussion very useful. >> > >> > No problem at all, as long as you also allow me an equivalent level of pickiness. :-) >> Thanks for your persistence ;-) >> >> Birte >> >> > Axel >> > >> >> Birte >> >> >> >> >> >> 2010/1/12 Axel Polleres <axel.polleres@deri.org>: >> >> > 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 >> >> >> >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Dr. Birte Glimm, Room 306 >> >> Computing Laboratory >> >> Parks Road >> >> Oxford >> >> OX1 3QD >> >> United Kingdom >> >> +44 (0)1865 283529 >> >> >> > >> > >> >> >> >> -- >> Dr. Birte Glimm, Room 306 >> Computing Laboratory >> Parks Road >> Oxford >> OX1 3QD >> United Kingdom >> +44 (0)1865 283529 >> > > -- Dr. Birte Glimm, Room 306 Computing Laboratory Parks Road Oxford OX1 3QD United Kingdom +44 (0)1865 283529Received on Wednesday, 13 January 2010 14:14:56 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 17:01:01 UTC
*