- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Mon, 11 Jul 2016 08:59:22 -0700
- To: Andy Seaborne <andy@apache.org>, public-sparql-exists@w3.org
On 07/11/2016 08:08 AM, Andy Seaborne wrote: > On 07/07/16 15:13, james anderson wrote: >> good afternoon; >> >>> On 2016-07-07, at 15:42, Peter F. Patel-Schneider <pfpschneider@gmail.com> >>> wrote: >>> >>> >>> >>> On 07/07/2016 06:31 AM, james anderson wrote: >>>> good afternoon; >>>> >>>>> On 2016-07-07, at 14:12, Peter F. Patel-Schneider <pfpschneider@gmail.com >>>>> <mailto:pfpschneider@gmail.com>> wrote: >>>>> >>>>> >>>>> >>>>> […] >>>>> >>>> >>>> -1 >>>> >>>> what is the concrete benefit of the “add a note” approach, when not putting >>>> the entry in the table puts the reader in the position to need to correlate >>>> information at different locations in the document? >>>> >>>> best regards, from berlin, >>>> --- >>>> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com >>> >>> The only benefit is that this is a smaller change. It does not remove >>> ToMultiSet from the solution modifiers part of the algebra. >>> >>> I don't think that there are any negative consequences of the removal. I >>> believe that moving ToMultiSet results in a better document. However, the >>> SPARQL document is long and complex so I'm not completely sure of the lack of >>> negative consequences, thus I prefer the smaller change because I see only a >>> tiny added benefit from making the larger change. >> >> >> if to add that entry to the 18.2 table column were to introduce some >> contradiction into the recommendation, when a literal reading of the algebra >> indicates that form should be a permitted argument, then there is more to be >> repaired in the text than a single note can rectify. >> >> if that table is taken as the basis for a literal reading, the most direct >> correction would be to accept the text at 17.4.1.4 as is, with the >> understanding the the reader will not take it to be a literal specification >> and change the definition for exists in 18.6 to permit a “solution modifier”. >> > > Adding to the "Graph Pattern" column is not clean. The things already there > act on graph patterns. > > That's why ToMultiSet is in the solution modifiers column - it acts on a > solution sequence. That would be a counter-productive meaning for this column. (Of course, that may have been the intended meaning.) Anyway, ToList then shouldn't be in the column as it acts on a multiset of solution mappings. A much better meaning is that the symbols in the left column produce multisets of solution mappings, the symbols in the center column produce sequences of solution mappings, and the symbols in the right column produce something like sets of sets of pairs of nodes. Under this better meaning ToMultiSet belongs in the left column, and so do multisets themselves. After all, BGP isn't in an "RDF Graph" column even though it acts on RDF graphs. It is in the left column because it produces multsets of solution sequences, i.e., the semantic things that are produced from the translations of syntactic things that can be in a graph graph pattern. > EXISTS then misuses "graph pattern". The argument is "the algebra transalation > of a GroupGraphPattern" i.e. the {} so it uses Graph Pattern in a different > sense. > > Andy peter
Received on Monday, 11 July 2016 15:59:58 UTC