- From: Fred Zemke <fred.zemke@oracle.com>
- Date: Wed, 02 Aug 2006 12:24:46 -0700
- To: public-rdf-dawg@w3.org

Master list of my comments In the telecon on 1 Aug 2006, I was asked to state which of my comments I regard as closed. I also learned about the issue list. Following up on the telecon, I have assembled all my comments in this message (a very long one, I'm afraid) and interspersed remarks (beginning with ++) on subsequent developments, in many cases stating that the matter is closed in my mind. As for what is left, I would like to get the important issues onto the issue list. Here is my proposed additions to the issues list: 1. Material on entailment and general framework needs to be rewritten. One objective of the rewrite is to extend the scope of blank node identifiers to include FILTER clause in rule [21] FilteredBasicGraphPattern. 2. Should we rearrange rule [14] SolutionModifier to place OffsetClause before LimitClause, given that the OffsetClause is processed first. 3. Should items in the SELECT list be separated by commas. I have heard that this is part of an existing issue on punctuation which is being re-opened. 4. Duplicates from UNION: do we require a result sequence to have a precise count of duplicates, or is it more lax? 5. The domain of solutions is not clearly specified. This is particularly an issue for OPTIONAL and UNION. 6. Formal semantics of OPTIONAL is not clear. The current wording "if S is a pattern solution of A and of B otherwise if S is a solution to A but not to B" appears to reduce logically to just "S is a solution of A". This issue is likely to be handled at the same time as the issue on the domain of solutions to OPTIONAL, though I'd like to list it as a separate issue. 7. How does filter evaluation work if there is an unbound variable that is not within a BOUND function? 8. There is no bridge from the syntax to the semantics. In addition, reviewing http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0129.html I suggest one further editorial action, for rq24 5.4 "Basic graph patterns in SPARQL syntax", as follows: This gives an example of a basic graph pattern with a blank node identifier, and it says " with the scope of the blank node label being the basic graph pattern". What is still missing is an example of the results of such a query, and a contrasting example showing how the query behaves differently when the triple patterns are placed into separate graph patterns. That is, I would like to see a contrast between { _:x :p >v . _x :q ?w } and { { _:x :p >v } { _x :q ?w } } so the the reader can really appreciate what it means that in the latter example the blank node labels are in different scopes. Can this be handled editorially? **************************************************** Recap of all my comments: http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0114.html editorial comments on CR dated 6 april 2006 Some (hopefully) editorial comments: 2.1.1 Syntax for IRIs It would be helpful to have examples of the two abbreviated syntaxes. One might think that abbreviated syntaxes must be written in angle brackets. ++ solved in rq24 3.1.1 "Syntax for IRIs" 2.3 Triple patterns The last sentence of this section says "This definition also allows blank nodes in the predicate position." But the second component of a triple pattern is a member of I union V, where I is the set of IRIs and V is the set of variables. Thus it seems that SPARQL blank nodes are not permitted in the second position. Also the BNF for Verb says it may be VarOrIRIref or 'a', so it seems that a SPARQL blank node can not be a predicate. ++ solved; I don't see this sentence any more in rq24 4.2 "Triple patterns" 2.4 Pattern solutions The first two sentences in the box use the following terms: "variable solution", "substitution function", "pattern solution", and "variable substitution". How are these terms related? Taken literally, it says that "a variable solution is a substitution function" and a "pattern solution is a variable substitution". Thus the first and second sentence seemingly have nothing to do with one another. In that case, why is the first sentence, about "variable solution", found in a box called "Definition: pattern solution"? This is very confusing. The reader is left suspecting that in fact all four terms are interchangeable. Furthermore, scanning the rest of the document, one finds that "variable solution" is never used at all, and the term "solution" is frequently used without qualification (neither as "variable solution" nor as "pattern solution"). We should use our terminology consistently. ++ solved in rq24 4.3 "Pattern solutions", where "variable substitution" replaces the term "variable solution" that I complained about. In addition I see the new sentence that says that "solution" is short for "pattern solution". 2.5.1 General framework Definition of "basic graph pattern E-matching", first bullet talks about BGP and BGP' being "graph-equivalent". This term is not defined; instead "equivalent" is. we should use our terminology consitently. ++ not addressed yet in rq24, where the term is defined as "equivalent" and used as "graph-equivalent". There is a hot link from "graph-equivalent" which takes you to "RDF Concepts" Rec. Andy Seaborne in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0122.html asks if that link satisfies my concern. My answer is that I think this link is incorrect because BGP and BGP' are not graphs, they are basic graph patterns, and so the link should take you to the definition of "equivalent" in this specification. It is true that the definitions of "graph-equivalent" and "equivalent" (for basic graph patterns) are very similar, but they still have different domains. Alternatively, the text can be read as saying that the term "graph-equivalent" is being extended so that its domain includes basic graph patterns. That would be fine, but in that case the definition should be reworded to call it "graph-equivalent" rather than "equivalent", and the hot link still needs to take the reader to the extended definition, not the definition whose domain is only graphs. Perhaps the editor can make these changes editorially. However, I think the expectation is that the entire section will be rewritten, so I am not proposing that this be added to the issue list. 9 Specifying RDF datasets A graph is specified using an IRI, which can be a QName, but there are no examples of using a QName to specify a graph. This would be helpful. ++ solved in rq24 9.3.3 "Restricting possible graph IRIs" 10.1 solution sequences and result forms The first formal definition says that a "solution sequence" is a "list". Both of these terms imply ordering. Then the last sentence in the first box says "The solution sequence from matching the query pattern is an unordered collection...". This is contradictory. What we probably mean is that "The solution sequence from matching the query pattern is in an implementation-dependent order". ++ solved in rq24 10.1 "Solution sequences and result forms" by moving the sentence outside the box and rewording it. 10.1 Solution sequences and result forms the last sentence in the first box says "The solution sequence from matching the query pattern is an unordered collection...". This sentence is not part of the definition of "solution sequence" so it should be placed outside the box. ++ same solution as previous item. 10.1 Solution sequence and result forms It would be helpful if the stages of processing solution sequences were always mentioned in the same order. The order is given as ORDER BY, project, DISTINCT, LIMIT, OFFSET. The text to be rearranged is: a) In the box for the definition of solution sequence modifier (order modifier should be moved ahead of projection modifier) b) The arrangement of subsections (10.1.3 ORDER BY should be moved ahead of 10.1.1 Projection) ++ solved in rq24 10.1 "solution sequences and result forms" A.5 Escape sequences in strings It says that \U may only be used for Unicode code points in the range U+10000 through U+10FFFF. So the first two HEX digits must always be 00? If so, why not show the syntax as '\U00' HEX HEX HEX HEX HEX HEX ? A.6 "excape sequences in IRI references" - same comment. ++ not done in rq24, but this was only a suggestion so I don't care. ********************************************************* http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0115.html Comments on 2.5.1 "General framework" in CR dated 6 April 2006 2.5.1 General framework This section is difficult to read. All we are defining in the current edition of SPARQL is with simple entailment, so why bother to lay out a more general framework at all? The only practical consequence from this section seems to be that there is a scoping set which is the set of RDF terms in the dataset. If we must have a general framework, perhaps we can dispense with defining entailment, contenting ourselves with referencing [RDF-MT] for a discussion of entailment in general. 2.5 Basic graph patterns The definition of E-entailment regime, taken literally, says that any subset of P(RDFG) x P(RDFG) is an entailment regime, where P(RDFG) is the power set of RDFG, the set of all RDF graphs. In contrast, reference [RDF-MT] "RDF Semantics" never actually defines entailment, but I see two consequences from the discussion there: a) Entailment is a relation from a set of graphs to a single graph, not to a set of graphs. Thus we want a subset of P(RDFG) x RDFG. It seems the text also has this in mind, since the definition of "well-formed" contemplates that the range of E (ie, the projection of E on its second component) is not a set of sets of graphs but a set of graphs. b) Entailment involves the notion of correct inferencing: given a set of graphs S, they entail graph G if all interpretations of S are interpretations of G. Thus it is not true that just any subset of P(RDFG) x RDFG constitutes an entailment. 2.5 Basic graph patterns The definition of "well-formed for simple entailment" is difficult to apply. It seems that all RDF graphs are well-formed for simple entailment. For example, every graph G is entailed by the singleton set { G }. Therefore every RDF graph is in the range of simple entailment. Therefore every RDF graph is well-formed. So what is the point to this concept? Looking ahead, it seems that the reason for introducing "well-formed" is for the third bullet in the definition of "basic graph pattern e-matching". However, the fourth bullet of that definition already implies the third bullet. That is, if G E-entails (G' union S(BGP')), then G' union S(BGP') must be in the range of the entailment E, and so must be well-formed. Hence it seems that we can dispense with the notion of well-formed, since the only use of it is superfluous. 2.5.1 General framework After the definition of scoping set, it says "The scoping set may be characterized differently by different entailment regimes". I don't know what "characterized" means here. Does it mean that the entailment implies the scoping set? So that simple entailment uses one scoping set and RDF-entailment uses another scoping set? If in fact the scoping set is not an independent parameter, then the scoping set should be mentioned in the definition of "E-entailment regime". 2.5.1 General framework Definition of scoping graph says that "*the* scoping graph ... is *an* RDF graph". This does not make sense. One cannot use "the" to refer to something that is not pinned down uniquely. There is not one graph that is uniquely graph-equivalent to G. What we mean is "A scoping graph... is an RDF graph...". After making this correction, the definition of scoping graph does not imply the sentence immediately following the definition, "The [sic, should be "a"] scoping graph makes the graph to be matched independent of the chosen blank node names". For example, G is graph-equivalent to G, trivially, therefore G is a scoping graph for itself. But if G has a problem with blank node names, then the scoping graph G also does, so we cannot conclude that the scoping graph automatically solves this problem. The best that can be said that a suitably chosen scoping graph will make the graph to be matched independent of the chosen blank node names. Looking ahead to the use of the notion, it is currently treated as a parameter in the definition of "basic graph pattern E-matching". However, I doubt that one has a specific scoping graph in mind when one does a basic graph pattern E-match. That is, treating "basic graph pattern E-match" as a boolean-valued function, you don't want the scoping graph as one of the arguments to this function. Proposed resolution: Delete the definition of "scoping graph", and in the definition of "basic graph pattern E-matching", delete the phrase "with scoping graph G'", replacing it with a new bullet reading "there exists a graph G' that is graph-equivalent to G". 2.5.1 General framework The pattern solution S is not being treated with the same respect shown to the other parameters in the definition of "basic graph pattern e-matching". It should be listed as one of the "givens" at the start of the sentence. 2.5.1 General framework In the definition of "Basic graph pattern E-matching", regarding the first bullet: a) it would be clearer if it were reworded "There exists BGP' such that BGP' is a basic graph pattern ...". b) The notion of graph-equivalent is not defined for basic graph patterns, only for graphs. Rather, the defined term is just "equivalent". All together, the first bullet should read "There exists BGP' such that BGP' is a basic graph pattern that is equivalent to BGP" 2.5.1 General framework Summary of my proposed rewrite to the definition of "Basic graph pattern E-matching": Given: - an entailment regime E, - a basic graph pattern BGP, - an RDF graph G, - a pattern solution S, and - a scoping set B then BGP E-matches with pattern solution S on graph G with respect to B if: - There exists a basic graph pattern BGP' and a graph G' such that: + BGP' is equivalent to BGP + G' is graph-equivalent to G + G' and BGP' do not share any blank node labels - G E-entails (G' union S(BGP')) - The RDF terms introduced by S all occur in B ++ I don't believe these comments have been addressed in rq24. This does not surprise or annoy me, since it seems that we are waiting for the entailment experts, especially Pat Hayes, to weigh in on a rewrite of the material on entailment and the general framework. My comments may be of interest to them; in any case, I am waiting to see that proposed rewrite. In the meantime, I suggest that the topic of rewriting the material on entailment and the general framework should be added to the issues list. ****************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0116.html comment on CR 10.1 "solution sequences and result forms" 10.1 Solution sequences and result forms The proposed order for processing LIMIT and OFFSET seems counterintuitive. Suppose the solution sequence has solutions (S1, S2, ..., S9). Suppose the user asks for LIMIT 3 and OFFSET 4. With the current rules, LIMIT 3 will truncate the solution sequence to (S1, S2, S3) and then the offset is greater than the number of solutions so the final result is empty. Instead, in this scenario, I think the user expects to get (S5, S6, S7). Thus the offset should be applied first, reducing the solution sequence to (S5, S6, ..., S9), and then the LIMIT should be applied. From this standpoint, the BNF for SolutionModifier should be rearranged to put OffsetClause ahead of LimitClause. ++ mostly solved in rq24 10.1 "Solution sequences and result forms" The part that is not addressed is whether we should rearrange rule [14] SolutionModifier to place OffsetClause? before LimitClause? . I suggest adding this to the issues list. *********************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0117.html comment on A.7 "Grammar" A.7 Grammar There are no commas in the SELECT list. This looks like a poor design because it will be an obstacle to allowing arbitrary expressions in the SELECT list in a future version. I asked for arbitrary expressions in a previous round of comments, and was told that this was being deferred to the future. That is fine, but I want to insure that the ground is ready for that extension. ++ I believe this comment triggered reopening an issue on punctuation. ************************************************************ http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0128.html Re: Draft response to: Re: major technical: blank nodes This is a response to Pat Hayes's email in the archive dated 26 Jan 2006 16:50:59 -0600. Thank you for your detailed comments. They have been very helpful to me personally in understanding the draft. The reason for my reply is that I believe we can do a better job in our treatment of blank nodes in SPARQL. I first came to an earlier draft after reading the RDF Recommendations. I found the SPARQL draft very confusing and frustrating. My essential complaint was that SPARQL uses one term for two concepts: a) RDF blank nodes, which are nodes in a graph with no label, and b) SPARQL blank nodes, which are lexical tokens in a SPARQL query. Pat Hayes's email rejects this interpretation. However, let me give the reasons that I held it, based on my reading of RDF and SPARQL both: a) According to the "RDF Concepts and abstract syntax" Recommendation, section 6.6 "Blank nodes", the set of RDF blank nodes is distinct from the set of IRIs and "Otherwise, this set of blank nodes is arbitrary. RDF makes no reference to any internal structure of blank nodes". That is, RDF blank nodes have no label. b) The RDF Primer section 2.3 "Structured property values and blank nodes" Figure 6 "Using a blank node" shows a blank node as having no label. It goes on to describe "blank node identifiers" of which it says "...blank node identifiers are not considered to be actual parts of the RDF graph." c) In our own working draft Section 2.5.3 "Example of basic graph pattern matching" second sentence under the first box, it says "The label information is not in the graph." d) Section 2.8.3 "Blank nodes" says "Blank nodes have labels which are scoped to the query". However, RDF blank nodes have no notion of scope (they simply exist, just as IRIs and literals exist, with no notion of scope). Scope is a lexical concept (the portion of a query text in which an identifier has a single referent). My summary is that the consistent stance of the RDF Recommendations is that blank node identifiers are an artefact of serialization. Now if a reader comes to the SPARQL draft with that model, he finds it very confusing (certainly I did). For example, section 2.4 talks about how to extend a pattern solution S to graph patterns. It says "If v is not in the domain of S, then S(v) is defined to be v." Applied to SPARQL blank nodes such as _:a, this says S(_:a) is _:a. Fine; it is still a lexical token; there has been no mention of creating a blank node corresponding to the label _:a. As a result, the mapping of a triple pattern, such as ?x :v _:a is (S(?x), :v, _:a) and there still is no RDF blank node. Consequently, the result of the mapping is not an RDF triple. Then we come to setion 2.5.1 "General framework" and the definition of "basic graph pattern E-matching". This definition posits a basic graph pattern BGP' and a scoping graph G' such that "G' and BGP' do not share any blank node labels". But how can they? BGP' is a triple pattern and might contain SPARQL blank nodes; G' is an RDF graph and as such does not contain anything that can be called a blank node label at all (though serializations of G' might). After studying Pat Hayes's email, my conclusion is that the text is using blank node identifiers as proxies or surrogates for the blank nodes themselves. To clarify our text, my proposed resolution is as follows: a) We should adopt the term "blank node identifier" for what I have been calling SPARQL blank nodes. This would harmonize with RDF Recommendations, which use this term when talking about character strings associated with blank nodes for identification purposes. For example, section 2.1.4 would be renamed "Syntax for blank node identifiers". We should scan the document for other occurrences of "blank node", and, as appropriate, change to "blank node identifier". b) We state explicitly that for each distinct blank node identifier, a distinct blank node is created for the purposes of processing the query, different from any blank node in the graphs in the query's dataset. We can also say that the reader may wish to think of the blank node identifiers as proxies or surrogates for these created blank nodes. Perhaps this might go in Section 2.1.4. c) In section 2.1.8 "Result descriptions used in this document" in the definition of RDF term, the created blank nodes should be explicitly listed as part of RDF-B. (Note that even if one believed that blank node identifiers were blank nodes all along, this did not put them in RDF-B because they were not part of any graph.) d) In section 2.4 "Pattern solutions", definition of "pattern solution", we say that the domain of S is extended to include blank node identifiers by mapping each blank node identifier to the blank node that was created for it in item b) above. e) Somewhere we make the observation that the result of applying a pattern solution S to a triple pattern is an RDf triple. Thus if BGP is a basic graph pattern, then S(BGP) is an RDF graph. f) delete the definition of "basic graph pattern equivalence" (changes proposed below make it dispensable). g) delete the definition of "scoping graph", also unneeded. h) Reword the definition of basic graph pattern matching to use the notion of graph merge found in the RDF Recommendations. The revised definition is something like this: "Given an entailment regime E, a basic graph pattern BGP, an RDF graph G and a pattern solution S whose range is a subset of B, then BGP E-matches with pattern solution S on graph G with respect to scoping set B if G E-entails the graph merge of G and S(BGP)." Actually, with the statement that the created blank nodes are distinct from all blank nodes in the dataset, a simple set union will suffice, though we may wish to stick with the RDF notion of merge for consistency with RDF. i) If we want to keep the technique of renaming blank node identifiers, we move that outside the boxed definition into explanatory text. For example, "The graph merge referred to in the preceding definition can be thought of as using blank node identifiers as proxies for the blank nodes. In that case, care must be taken to ensure that the blank node identifiers of G are different from all blank node identifiers in BGP. Let G' and BGP' be serializations of G and BGP, respectively, such that all blank node identifiers in G' are different from all blank node identifiers in BGP'. Then G' UNION BGP' is the serialization of some graph G2. S is a solution for BGP using E entailment if G E-entails G2." j) In section 2.5.2 "SPARQL basic graph pattern matching" last paragraph, we can clarify that pattern solutions are unique, not just unique up to blank node renaming. The so-called "blank node renaming" is an artefact of serialization. The last sentence is thus "the serialization of a set of all pattern solutions is unique up to blank node identifiers". We can also delete the phrase "...possibly with blank nodes renamed" earlier in the paragraph, because a pattern solution is not actually concerned with assigning blank node identifiers. ++ Pat Hayes responded in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0139.html He disagreed with me in places, but agreed with my overall contention that it would be good to distinguish clearly between blank nodes in the query and blank nodes in the data. I see that rq24 is already headed in this direction; possibly, this is solved, or else it is just a matter of on-going editorial vigilance. No issue proposed at this time. *************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0129.html Comments on 2.1.4 "Syntax for blank nodes" in 6 April 2006 CR 2.1.4 Syntax for blank nodes It says "Blank nodes...will take part in the pattern matching". There are no examples of how pattern matching with SPARQL blank nodes works. Section 2.5.4 "Basic graph patterns in SPARQL syntax" gives an example of the syntax only, but does not discuss the semantics of the example that it presents. Section 2.8.3 "Blank nodes" and 2.8.4 "RDF collections" show how the abbreviations are expanded into SPARQL blank nodes, but do not show how the expanded patterns behave either. ++ partially solved in rq24 5.4 "Basic graph patterns in the SPARQL syntax". This gives an example of a basic graph pattern with a blank node identifier, and it says " with the scope of the blank node label being the basic graph pattern". What is still missing is an example of the results of such a query, and a contrasting example showing how the query behaves differently when the triple patterns are placed into separate graph patterns. That is, I would like to see a contrast between { _:x :p >v . _x :q ?w } and { { _:x :p >v } { _x :q ?w } } so the the reader can really appreciate what it means that in the latter example the blank node labels are in different scopes. Can this be handled editorially? 2.1.4 Syntax for blank nodes The preceding section 2.1.3 "Syntax for variables" says "Variables in SPARQL have global scope". Section 2.8.3 "blank nodes" says "Blank nodes have labels which are scoped to the query". It is not clear to me what the difference between the "global scope" of a variable vs. being "scoped to the query" means in practice. At any rate, I think it would be good to state the scope of blank nodes (or what I prefer to call blank node identifiers) in section 2.1.4, as a parallelism with 2.1.3, and possibly harmonize the terminology. ++ solved in rq24 3.1.4 "Syntax for blank nodes" ************************************************ http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0130.html Comments on UNION matching (CR 6 Apr 2006) 6. Matching alternatives Second sentence says "If more than one of the alternatives matches, all the possible pattern solutions will be found." Does this mean that if a solution is a solution of both patterns, then the solution occurs twice in the solution sequence? There are no examples of solutions with multiple cardinality. Such examples would be helpful. ++ not resolved; I don't see any examples in rq24 that address the question of duplicates. I am asking that the question of duplicates be added to the issues list. 6.2 Union matching - formal definition The definition is unclear about whether there are any constraints on the value of a solution on a variable that appears in one pattern but not in the other. Example: what is the result of SELECT ?x ?y WHERE { FILTER (?x = ?x) } UNION { FILTER (?y = ?y) } Suppose there is only one RDF term in the graph, <http:a>. There are all together four partial functions from the set of variables in the query {?x, ?y} and the set of RDF terms, namely: S1 (?x) = <http:a>, S1(?y) = <http:a> S2 (?x) = <http:a>, S2(?y) undefined S3 (?x) undefined, S3 (?y) = <http:a> S4 (?x) undefined, S4 undefined I believe that the desired set of solutions is {S2, S3}, i.e., S1 is not a solution of this query. However, arguably, S1 is a solution of FILTER (?x = ?x), and therefore belongs in the result set according to the definition as written. My proposed fix is: let P be pattern1 UNION pattern2. Then S is a solution of P if either of the following is true: 1. S is a solution of pattern1 and S is undefined on every variable that is contained in pattern2 but not in pattern1; or 2. S is a solution of pattern2 and S is undefined on every variable that is contained in pattern1 but not in pattern2. ++ not addressed in rq24. I hope to make a comprehensive proposal on the formal semantics, so I am not agitating for this specific solution. I think the issue of the domain of solutions to union patterns should be added to the issue list. 6.2 Union matching - formal definition The definition is unclear about duplicates. If s is a solution of GP1 and S is a solution of GP2, does the solution sequence contain a copy of S for each of GP1 and GP2? I believe the answer should be that duplicates are maintained because they might be meaningful to the user; if the user wishes to eliminate duplicates, the user can specify DISTINCT. In that case, the definition proposed in a separate comment needs to be rewritten because it would eliminate duplicates. I think the best approach would be to recognize that the UNION operator is constructing a solution sequence from the solution sequences of each operand. The proposed rewording is then: Let P be pattern1 UNION pattern2. Let V1 be the set of variables that appear in pattern1 and let V2 be the set of variables that appear in pattern2. S = (S1, S2, ... Sn) be a sequence of all partial functions on V1 that are solutions of pattern1. Let T = (T1, T2, ... Tm) be a sequence of all partial functions on V2 that are solutions of pattern2. Then a solution sequence of P is any permutation of the sequence (S1, ..., Sn, T1, ..., Tm). (Note: This definition involves a trick concerning partial functions. For example, each Si is a partial function on V1, therefore it is a partial function on the set of all variables in P that happens to be undefined on the variables that belong only to V2.) ++ not addressed in rq24. I think the issue of the cardinality of solutions to union patterns should be added to the issue list. ************************************************ http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0132.html Comments on optional pattern matching (CR 6 apr 2006) 5.1 Optional pattern matching last sentence of the largest paragraph says "The whole graph pattern of an optional graph pattern must match for the optional graph pattern to add to the query solution." The term "query solution" is not defined, but it also occurs in 10.1.3 "ORDER BY" where it refers to the solution sequence. In that case, the phrase "add to the query solution" presumbably means to add another solution to the solution sequence. However, that meaning does not always make sense here, because, given a pattern P of the form Pattern1 OPTIONAL { Pattern2 }, the cardinality of the solution sequence of P can be the same as the cardinality of the solution sequence of Pattern1, if for every match to Pattern1, either Pattern2 has a unique match or no match. Instead of using the verb "add", may I suggest the verb "widen"? It is true that OPTIONAL may increase the number of results, but the primary role of OPTIONAL is to widen the results with additional variables and SPARQL blank nodes found in the second pattern. ++ solved in rq24 7.1 "Optional pattern matching", where the wording has been changed to say "affect the query solution". 5.4 Optional matching - formal definition The definition is problematic because it uses two terms, "pattern solution" and "solution". It is not clear whether these are distinct concepts or the same concept. I believe most readers will think they are the same concept. In that case, the definition does not work because it is logically equivalent to "S is a solution of optional graph pattern if S is a pattern solution of A". Proof: Let S be a pattern solution of A. Now either S is a pattern solution of B or not. If S is a pattern solution of B, then S is a pattern solution of A and B and meets the criterion. If S is not a pattern solution of B, then S is a pattern solution of A but not of B, so S meets the "otherwise" part of the criterion. Thus in either case S satisfies the criterion. If "pattern solution" and "solution" are separate concepts, then we need to be more explicit about the distinction, preferably by coming up with a two-word phrase for the latter concept. If this is our intent, it still does not rescue the definition logically. A close reading of the actual words shows that we are defining "solution" as a recursive definition built on "pattern solution". For S to be a "solution" of Opt(A,B), then the first possibility is that S is a "pattern solution" of A and B. However, the intent is that B might itself be an optional graph pattern, and this close reading of the definition leaves the notion of being a "pattern solution" of an optional graph pattern undefined, so the recursion breaks down when defining Opt (A, Opt (B, C)). In addition, the definition does not work because the definition of a pattern solution is a total function whose domain is all variables. For example, consider the query { ?x ?y ?z . OPTIONAL { ?x ?z ?w } } applied to the graph with a single triple G = { (ex:a, ex:b, ex:c) }. Here is a trial solution: S(x) = ex:a, S(y) = ex:b, S(z) = ex:c, S(w) = ex:a. Note that I have deliberately defined S as a total function on all variables in the query. Now let's try to apply the definition of optional matching to this trial solution. We see that S is a solution for ?x ?y ?z and S is not a solution for ?x ?z ?w. Thus it would seem that S qualifies as a solution because it satisfies "S is a solution to A but not to A and B". However, I don't think S should be regarded as a solution to the query. Instead, I think that when S fails as a solution to B, then S should be undefined on any variables that occur only in B. Thus S2 defined by S2(x) = ex:a, S2(y) = ex;b, S2(z) = ex:c, and S2(w) undefined should be a solution to the example. My tentative fix is: given syntax pattern1 OPTIONAL { pattern2 }, call pattern1 the mandatory pattern and pattern2 the optional pattern. Any variable that appears in the mandatory pattern is called a mandatory variable. Any variable that appears in the optional pattern and not in the mandatory pattern is called an optional variable. A pattern solution S is a partial function from the variables in the query to RDF terms such that the following hold: a) S restricted to the mandatory variables is a pattern solution of pattern1. b) One of the following two cases is true: i) S is undefined on all optional variables, or ii) S is a pattern solution of pattern2 ++ my tentative fix was shown not to handle a desired capability. I am still working on the best way to formulate this. In the mean time, I request that the formal semantics of optional graph patterns should be added to the issue list. ************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0136.html Comments on the proper domain for solutions (CR 6 Apr 2006) 2.4 Pattern solutions The definition defines "variable solution" as a partial function and "pattern solution" as a total function. Since the heading on the box calls out "pattern solution", and only the definition of "pattern solution" is in bold, and "variable solution" never appears elsewhere in the document, the reader is led to believe that the important notion is "pattern solution", the total function. However, focusing on total functions is a mistake, as shown by the OPTIONAL and UNION syntaces, which explicitly require partial functions as solutions to patterns. ++ not resolved; rq24 4.3 "pattern solutions" still says that the domain of a pattern solution is V, the set of all variables. I am asking to add an issue on the domain of solutions, which pertains here, as well as other patterns. 2.4 Pattern solutions It says that a pattern solution is a total function on V, an infinite set. As pointed out in a separate comment, solutions in general are partial functions on V, when OPTIONAL and UNION are considered. The issue to be raised in this comment is that V is not the appropriate domain, even in the case of matching a triple pattern. Consider SELECT ?a ?b ?c WHERE { ?a ?b ?c } evaluated on a graph containing a single triple, (n:s n:v n:o). Then, according to the definition, a pattern solution is a total function mapping F:V -> {n:s, n:v, n:o} such that F(?a) = n:s, F(?b) = n:v, F(?c) = n:o, and F(v) is unconstrained for all other variables v. There are a countable infinity of these total functions. Now assemble these pattern solutions into a solution sequence and project to retain just the variables ?a, ?b and ?c. You still have an infinite sequence. Thus the result of the query appears to be an infinite sequence (whose every member is the same function on { ?a, ?b, ?c }). If one replies that the projection is to be done before assembling the solution sequence, I observe first that that is not the description in Section 10.1 "solution sequences and result forms", but more importantly, that will produce the wrong cardinality on other queries, for example, SELECT ?a ?b WHERE { ?a ?b ?c } on a dataset with two triples (n:s n:v, n:o1), (n:s, n:v, n:o2). In this example, projecting before assembling the solution sequence will result in only a single solution, whereas there should be two. Instead, I believe that the correct algorithm is to look at pattern solutions whose domain is the set of variables that appear in the specific query to be evaluated (not the infinite set V). And, as pointed out in a separate comment, the focus should be on partial functions rather than total functions. ++ not resolved. I request an issue on domain of solutions. ********************************************************* http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0135.html Comment on 11.2 "filter evaluation" (CR 6 Apr 2006) 11.2 Filter evaluation The rules do not say how to handle an unbound variable in an expression. Clearly it must be possible for the argument of BOUND to be unbound. I believe the desired semantics are that it is an error to have an unbound argument for any other function. This should be stated explicitly. Also, note that the first bullet says "SPARQL functions do not process node sequences. When interpreting the semantics of XPath functions assume that each argument is a sequence of a single node". Given that an argument might be unbound, it is not true that arguments are always a sequence of length 1; I think the truth is that the argument may be a sequence of length 0 or 1. ++ Andy pointed me to http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0012.html evidently someone else thinks that this could be specified better. I request an issue for this. *********************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0137.html Comments on 9 "Specifying RDF datasets" (CR 6 Apr 2006) 9 Specifying RDF datasets The text could be clearer about where the default graph comes from. The first paragraph hints at this, but the description is cloudy because of the use of "may". Thus the first sentence says "A SPARQL query may specify the dataset ...". The use of "may" in this sentence evidently refers to the user, who "may" choose to use the FROM clause. Third sentence "The RDF dataset may also be specified in a SPARQL protocol request". Does this mean that it is the user's responsibility to use at least one of these two techniques? What happens if the user uses neither? Is this an error? Or perhaps this would mean the default graph is empty? Or does some implementation-defined default kick in? The precise rules for determining the default graph need to be specified. ++ I am satisfied with Andy's reply in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0029.html 9 Specifying RDF datasets There is no statement of the formal semantics of the FROM clauses. ++ I am not satisfied with Andy's reply in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0029.html My reasons are: 1. There is no bridge from the syntax rule [9] DatsetClause to the abstract construct called a dataset in rq24 9.3 "Querying the dataset". This is an instance of my general issue that there is no bridge from syntax to semantics. 2. Andy says that it is implementation-defined whether to merge graphs to produce the default graph if there are multiple FROM clauses. However, the last sentence of rq24 9.2.1 "Specifying the default graph" says that the default graph is the merge. If Andy is correct, then that sentence needs to change. I am agreeable to an editorial resolution of this. ************************************************************* http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0131.html Comments on 10.1 "Solution sequences and result forms" (CR 6 Apr 2006) 10.1.1 Projection The last sentence of the formal definition uses set notation for the result of projecting a solution sequence into a new solution sequence. This is not desired, because: a) sets are not ordered, but solution sequences are b) sets do not permit duplicates, but the intent is that the result of a projection might have duplicates. This can be corrected by using some notation denoting a sequence. Earlier we used (S1, ..., Sn) to denote a sequence, and that could be done here, for example, ( (project (S1, VS), ... project (Sn, VS) ). Or we can use the mathematical definition of a sequence as a function whose domain is the positive integers, in which case the sequence is represented { (i, project (Si, SV) ) | i = 1, ..., n } ++ solved in rq24 10.1.2 "Projection" 10.1.3 ORDER BY The formal definition does not support the following features: a) ordering in descending order b) ordering by multiple sort keys. ++ Andy replied in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0027.html He noted that he had made an editorial improvement to the first sentence of rq24 10.1.1 "ORDER BY". I agree that the editorial change is an improvment, and perhaps that is all that can be done editorially, but I still feel that there is an unspecified gap between the syntax and the semantics. How does one know that one uses the increasing order with ASC and reverses that order with DESC? How does one know to do the lexicographic order when there are multiple sort keys? These are not weighty issues, but other specifications have done this, and so can we. I regard this as part of my general issue of connecting the dots from the syntax to the semantics. ********************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0134.html Comments on 2.6 "Multiple Matches" (CR 6 Apr 2006) 2.6 Multiple matches First sentence: "The results of a query is the set of all pattern solutions that match the query pattern, giving all the ways a query can match the graph queried." But sets eliminate duplicates, and we have the DISTINCT operator as an optional syntactic choice about whether to eliminate duplicates. Instead, this should say that the result of a query is a sequence of solutions. See section 10.1 "Solution sequences and result forms". ++ solved in rq24 2.2 "Multiple matches" 2.6 Multiple matches The semantics of the empty graph pattern has not been defined. I think the following queries are instructive: a) SELECT ?a FROM graph WHERE { } b) SELECT ?a ?b FROM graph WHERE { } c) SELECT ?a ?b FROM graph WHERE { ?a foaf:verb foaf:noun } d) SELECT ?a ?b FROM graph WHERE { ?a foaf:verb foaf:noun . OPTIONAL { ?a foaf:verb2 ?b } } One's initial impulse is that query a) should result in the set of all mappings of { ?a } to the scoping set (not the set of all total mappings of V to the scoping set; see related comment). Or equivalently, the user might view the result as an enumeration of the scoping set of the graph. Then query b) would result in the set of all mappings of { ?a, ?b } to the scoping set, or, naively, the cross product of the scoping set with itself. However, I believe that c) and d) should result in a subset of the result of b). Now in the case of d) in particular, OPTIONAL is intended to allow for a result which is a partial binding, ie, one that binds ?a but does not bind ?b. If it happens that there is no binding for ?b, then the result would not be a subset of the cross product of the scoping set with itself. My conclusion is that in order to support OPTIONAL and UNION, we have to permit a result that is a partial mapping. Coming back to query b), in order for it to contain query d) as a subset, the result of b) must be all partial functions from {?a, ?b} to the scoping set. Alterantively, a naive view might imagine augmenting the scoping set with a single "missing" element, distinct from all other elements, in which case the result of b) is the cross product of the augmented scoping set. And as for a), it seems the result must be the set of all partial functions of { ?a } to the scoping set, or equivalently, an enumeration of the augmented scoping set. As a different approach to this issue, consider these two queries: a1) SELECT ?a FROM graph WHERE { BOUND (?a) } a2) SELECT ?a FROM graph WHERE { !BOUND (?a) } I believe the following things: -- the result of a) should be the union of the result of a1) and a2) -- the result of a1 should be an enumeration of the scoping set, -- the result of a2 should be a single solution, in which ?a is not bound. ++ solved in rq24 6.2 "Empty graph pattern" **************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0133.html General problem with cardinality of results in CR 6 April 2006 The specification is imprecise about the cardinality of solutions in several places. I have heard it argued that all that matters is the set of solutions (ie, duplicates can be dropped as an implementation dependent or defined detail). The problem with that position is that the number of duplicates may be semantically meaninful to the user. This issue will become acute when we add aggregates, which has been deferred to a future release. When a user performs a count or sum, the user expects precise semantics about the number of duplicates to be counted or summed. If we fail to specify those semantics in this edition, then we will encourage differing implementations, which then will have entrenched positions on cardinality issues when we try to add the aggregates. Therefore it is important to resolve the cardinality issues at this stage. Even in advance of adding aggregates, the user may be interested in computing them on his own using the results of a SPARQL query. To assure portable and interoperable results, we need to define the number of duplicates precisely. I see at least the following issues on cardinality: a) the number of solutions to the empty pattern, SELECT ?A WHERE {}. I can see arguments for 0 solutions, 1 solution (the one that makes ?A undefined), n solutions where n is the cardinality of the scoping set (one for each possible binding of ?A) or n+1 (one for each possible binding, plus one in which ?A is not bound). ++ solved in rq24 6.2 "empty graph pattern". b) the number of solutions to a UNION, for example, SELECT ?A WHERE { { ?A ?A ?A } UNION { ?A ?A ?A } } c) the number of solutions when a triple pattern includes a blank node. For example SELECT ?A WHERE { ?A n:v _:B } on the graph G = { (n:a, n:v, "1"), (n:a, n:v, "2") }. Does this have one solution or two? Argument in favor of one solution: there is only one mapping S from the set of variables to the set of RDF terms such that S( ?A n:v _:B ) is a triple that can be merged into G to produce a new graph that is simply entailed by G. This is using the definition of basic graph pattern E-matching in section 2.5.1 "General framework". Argument in favor of two solutions: Section 2.5.2 "SPARQL basic graph pattern matching" last paragraph says that under simple entailment, pattern matching can be done by mapping both variables and SPARQL blank nodes to RDF terms, testing to see if the result of the mapping is a subgraph of G. Under this formulation, there are two solutions, one that maps _:B to "1" and the other that maps _:B to "2". This paragraph goes on to say that solutions are formed by restricting such mappings to just the set of variables. What is unclear is whether the act of restricting involves discarding duplicates. Note that the fact that there is a DISTINCT modifier shows that one can not presume that duplicates are discarded. I am posting separate, more detailed comments on specific sections with cardinality issues. ++ I think we need an issue on cardinality of UNION. As for cardinality of a basic graph pattern with a blank node identifier, my current interpretation of the document is that the general framework is normative and therefore the cardinality must be 1. ************************************************************ http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0141.html Comment on 4.1 "Group graph patterns" (CR 6 Apr 2006) 4.1 Group graph patterns The formal semantics of group graph patterns does not work in conjunction with the definiton of basic graph pattern matching (section 2.5.1 "General framework"). For example, let G be the graph <s> <v1> <o1> . <s> <v2> <o2> . Consider the pattern { ?x <v1> _:a } { ?x <v2> _:a } The pattern is a group graph pattern consisting of two triple patterns. According to the definition, we are looking for a solution S that is a solution of { ?x <v1> _:a } and a solution of { ?x <v2> _:a }. As a trial solution, consider the function S that maps ?x to <s>. I claim that S is a solution of both subpatterns. For the first pattern, according to the definition of basic graph pattern E-matching the question is whether the following graph <s> <v1> <o1> . <s> <v2> <o2> . <s> <v1> _:a . is entailed by G. The answer is yes. Similarly, s is a solution of the second pattern as well. The problem in logical terms is that "for all x there exists y such that P(x, y)" is not as strong an assertion as "there exists y such that for all x, P(x, y)". The current definition only supports the weaker assertion "for all there exist" rather than the desired assertion "there exists for all". Mathematicians generally use the term "uniform" to describe "for all there exists" situations (for example, the definition of uniform continuity). On the other hand, if one uses the alternative definition of triple matching in section 2.5.2 "SPARQL basic graph pattern matching", the uniform treatment of blank node identifiers in graph patterns is assured. This definition says that a solution is found by mapping variables and blank node identifiers to RDF terms. In that case the trial solution S must specify which node in G the blank node identifier _:a is bound to. Since there is no single choice that works, there is no solution to the pattern. ++ This comment as worded above is mistaken. It assumes that using the mapping algorithm for basic pattern matching makes the scope of a blank node identifier be the entire query. However, rereading rq24 5.2 "SPARQL basic graph pattern matching", I see that the scope is still just a basic graph pattern. Whether this is advisable from a usability standpoint is a separate question. I have not decided whether to raise that as an issue. *************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0189.html Blank node identifiers in FILTER clauses The scope of blank node identifiers is not clearly specified. However, as I have understood conversations in email and telecon, the definition of basic graph pattern E-matching in 2.5.1 "General framework" provides the only definition for the semantics of blank node identifiers, and therefore the scope of a blank node identifier is a basic graph pattern. My question is whether the scope can also extend into a Constraint in a FilteredBasicGraphPattern. For example, consider the data set with these three triples: <s1> <v> <o1> . <s2> <v> <o2a> . <s2> <v> <o2b> . The user wants to find those subjects which are related via the verb <v> to at least two objects. The desired solution sequence is { <s2> }. The user writes his query this way: SELECT ?x WHERE { ?x <v> _:a . ?x <v> _:b . FILTER (_:a != _:b) } Does this do what the user wants? It seems that the definitions in 2.5 "Basic graph patterns" only explain how to solve the basic graph pattern ?x <v> _:a . ?x <v> _:b . The solutions of this basic graph pattern are ?x = <s1> and ?x = <s2>. In the case of ?x = <s1>, this is because the dataset entails the addition of these triples: <s1> <v> _:a . <s1> <v> _:b . or in predicate calculus terms, it is possible to conclude from the dataset that (exists _:a, _:b) [ <s1> <v> _:a . <s1> <v> _b . ] Or using the mapping technique for simple entailment, map ?x -> <s1>, _:a -> <o1>, _:b -> <o1> and then restrict to just the mapping of ?x. Note that the definitions of section 2.5, using either entailment or mapping, do not provide for evaluating a Constraint during the process of finding solutions to a basic graph pattern. So both solutions ?x -> <s1> and ?x -> <s2> come to the FILTER clause, and the FILTER clause is unaware of any bindings to _:a or _:b. I do not know whether the result of FILTER (_:a != _:b) is true, false or error, but whatever the semantics of the FILTER clause is, it appears that it will treat the two solutions identically. If true, then both <s1> and <s2> are solutions; if false or error, then neither are. Thus the solution set appears to be either { <s1>, <s2> } or the empty set. Not what was desired! I see four possible resolutions: 1. (My preference) the scope of a blank node identifier is an entire FilteredBasicGraphPattern, not just a basic graph pattern. To do this, we need to extend the definitions in section 2.5 so that they define the solutions of a FilteredBasicGraphPattern rather than just the solutions of a basic graph pattern. I can see how to do this with the simple entailment mapping definition; I don't see how to do this with the general E-entailment definition. 2. We prohibit blank node identifiers in FILTER clauses as inherently meaningless or deceptive syntax. 3. We allow blank node identifiers in FILTER clauses, but they always raise an error, so that such FILTERs always fail. But in that case, why did we permit the syntax? 4. We allow blank node identifiers in FILTER clauses, and they reference distinct blank nodes, distinct from all blank nodes in the dataset. Thus _:a = _:b is false, and _:a != _:b is true. ++ this comment started an extended dialog. My summary is that it seems there is a consensus for choice 1. I suggest that we add this to the issue list. Presumably it will be resolved by the anticipated rewrite of the general framework. ***************************************************** http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0008.html Concrete vs. existential semantics I have been advocating for strict definitions of the number of rows returned by queries. As I understand it, Andy Seaborne has advocated an opposite view, that SPARQL should not define precisely how many duplicates are returned by a query. For example, in http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0005.html "In general, it isn't possible to conclude anything about numbers of things in RDF. It is in OWL." I have also heard the opinion that it does not matter whether duplicates are eliminated from a UNION or not; I don't have a name or message to cite for that opinion. More generally, I think there is an opinion that all SPARQL cares about is that the result sequence, after eliminating duplicates, is correct. Thus the result of a SELECT is not precisely defined; only SELECT DISTINCT is. In this message I want to start a discussion on this. As an initial foray, I will frame the question in terms of "concrete" vs. "existential" semantics. I grant that it is difficult to impossible to be sure that two seemingly-different IRIs refer to distinct things. I also grant that it is difficult to impossible to be sure that two seemingly distinct blank nodes, conceived of as existentials, are known to be distinct. However, I wonder whether it is a good idea to base our semantics exclusively on these "existential" insights. I think the naive view is that two things are distinct if they look distinct. Two IRIs that are spelled differently are different. Two blank nodes with different node identity are different. (Blank node identifiers are proxies for node identity; two blank nodes with different identifiers are different). I think that in many instances, the users will want this kind of concrete interpretation of an RDF graph. Further, I believe that when one is working with a concrete interpretation, duplicates may carry semantic meaning and it is important to define precisely how many duplicates are returned. I especially believe this is true when there are financial figures involved. For example, imagine a purchase order encoded in RDF. Each purchase order has an IRI. Various facts about the PO are assembled using verbs: bill-to, ship-to, and the line items. Since bill-to, ship-to and line items are all compound objects, they may be represented by blank nodes, which in turn connect via various verbs to literals or IRIs. Let's look at the line items in particular. A line item consists of a part number (an IRI), a quantity (an xsd:integer), and a unit price (an xsd:decimal). The user wants to find the total price of a particular PO. The query looks something like this: SELECT ?quantity ?price WHERE some:IRI po:po _:lineitem . _:lineitem po:quantity ?quantity . _:lineitem po:price ?price . Since SPARQL has no aggregates or expressions in its SELECT list, the user intends to simply fetch all rows, multiply ?quantity * ?price and take the sum himself. Now it can happen in a PO that the quantity and price of two line items are identical. However, suppressing such duplicates would be fatal to this application. Note that adding the part number to the SELECT list will not necessarily save the query, since the combination of part number, quantity and price is still not a guaranteed unique key for line items. The user is relying on distinct blank nodes to represent distinct line items. Of course, from the point of view of "RDF Semantics" that would be a redundant graph, for example, one that asserts "There exists a line item whose part is XYZ, quantity is 1 and price is 10.99" and asserts again "There exists a line item whose part is XYZ, quantity is 1 and price is 10.99". Thus one could say that this is a misuse of RDF. This may be technically true, but I wonder if insisting on this point will really serve the users. If you read the RDF Primer, the application design above makes sense. You have a line item; you don't want to bother creating an IRI for each line item; so you make a blank node for each line item. "RDF Semantics", on the other hand, is a dense document with talk about hypothetical universes that are interpretations of a graph. This is not the kind of material that will make its way into seminars, courses, how-to books, etc. The early days of relational databases encountered the same problem. The theorists said a relational table is a set, therefore it can have no duplicates, therefore it is up to the user to insert some additional piece of information to distinguish two otherwise-identical line items, to provide a unique key. Sounds great in theory; however, the vendors discovered that they had to accomodate the naive view that each row has its own identity and is distinct, without requiring a unique key. A slightly different response is that RDF and SPARQL are not targeted at such applications. However, the introduction to "OWL web ontology language guide" poses this scenario: "consider actually assigning a software agent the task of making a coherent set of travel arrangements." If eventually RDF databases and SPARQL queries are part of such a software agent, then it will be necessary to make concrete assurances about the total price of a travel plan. In addition, the vision is that the dataset will be aggregated from many sites, which means that there will not be a central authority to impose strict existential semantics. My suggestion is that we consider some syntactic way to support both a "concrete" interpretation and an "existential" interpretation. My tentative initial solution is a three-way switch: SELECT DISTINCT, SELECT ALL and SELECT LAX. SELECT DISTINCT promises to remove duplicates, SELECT ALL promises to deliver all duplicates, and SELECT LAX makes no promises either way. (Anyone have a better keyword for this choice?) I don't believe this is the complete solution to the issue. The reason is that the issue of duplicates becomes more complicated when using OWL entailment. OWL permits the deduction that two seemingly distinct IRIs or blank nodes are in fact equal. For example, if the reasoner can deduce that some:IRI1 = some:IRI2, what should the reasoner return for SELECT ALL? Does it return both even though it knows they are equal? If not, how does the user frame a query to ask for all synonyms of some:IRI1? What should the reasoner return for SELECT DISTINCT? Does it pick one of the two arbitrarily? ++ my comment was vigorously rebutted and I did not receive any messages in support of my comment. I understood the replies and I can see the opposing point of view. I continue to be concerned that we may lose the confidence of our users if SPARQL cannot be relied on to return results that can be meaningfully counted and summed. However I am not pushing to add this to the issue list at this time. ******************************************************* http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0042.html ready to exit CR? I am strongly opposed to exiting CR because of the issues I have raised with the specification, which I regard as serious and fatal. In my view the purpose of a specification is to specify. Examples do not constitute a normative specification. The document (both the CR and rq24) fails to specify in the following important ways: 1. There is no bridge from the concrete syntax to the abstract semantics. Consequently the document can not actually be said to specify the language at all, except that A.7 "Grammar" really does specify the syntax. 2. The scope of blank node identifiers has not been stated clearly. The consensus in an email thread appears to be that the scope is a FilteredBasicGraphPattern (rule [21]) but the definitions in 2.5.1 "General framework" do not support this and need to be rewritten. 3. The abstract semantics does not pay attention to the critical issue of the domain of solutions. Consequently the notion of "solution" is not well-defined. 4. The preceding problems are perhaps at their worst in the case of optional graph patterns. The grammar does not indicate what the first operand of a graph pattern is, and there is no discursive text on the subject either. Thus there is no bridge from the syntax to the abstract semantics. As for the abstract semantics, the definition of OPT(A,B) appears to reduce to just solving A with no role for B. 5. It is not clear whether UNION requires an implementation to count duplicate solutions precisely, which I personally advocate, though I could live with the alternative of stating explicitly that it is implementation-defined or -dependent how many duplicates are returned. ++ this message recapitulates some of my comments and indicates some that I feel are obstacles to progression. These issues are all enumerated earlier in this file and no additional issues need to be created. Fred

Received on Wednesday, 2 August 2006 19:25:55 UTC