Hi, thank you for the interesting pointers.
On 29.01.2018 17:01, Andy Seaborne wrote: > EXISTS is important when verifying data (SHACL, and I presume, ShEX). > NOT EXISTS is probably more common in query situations. I agree, never used EXISTS without NOT, though indeed I just use SPARQL for querying. > > What I'd like to see in this paper is discussion about SQL because, in > the abstract, this isn't much different from SQL features. > > In practical usage I've seen, the graph pattern in EXIST / NOT EXISTS > do not seem to be very complicated - BGP, FILTER, GRAPH. Sometimes, I use NOT EXISTS in combination with sub-queries but to be honest, I never thought about any possible issue in doing so. Clearly, this is because I didn't read the eval specs carefully enough to recognize that only the GP case is covered. > > There is/was a W3C community group to move this forward. > > The SPARQL 1.1 spec replaces variables by their value which leads to > some problems documented at: > > > https://w3c.github.io/sparql-exists/docs/sparql-exists.html#identified-issues > > > > The community group is inactive - there are (were) two proposals, > > One proposal (disclosure - this is mine) > > https://w3c.github.io/sparql-exists/docs/sparql-exists.html#proposal-b > > is based on the idea of SQL correlated subquery; the variables in the > inner query take only the values of the current binding by joining, > where the variables are set, with a VALUES table. It leaves the > variables in-place and makes sure they are bound to the value in the > row being filtered (rather than replace it by its row binding). > Several spec problems go away as the variable is still there. It is a > purely algebra/execution solution. It works for nested patterns and > is closer to the spec. > > The other proposal (Peter Peter Patel-Schneider) > > https://w3c.github.io/sparql-exists/docs/sparql-exists.html#proposal-a > > is based on injecting the variable values to be joined after > sub-patterns are evaluated. It is a mix of syntax and execution. It is > simpler to describe, but not implement. It does not apply to nested > patterns and it has had less investigation. Well, in that case I'd also go for the first proposal. Just as a follow up question: Given that you'd have been decided for one of the proposals, how would the whole process continue? I mean, how does it work in revising the specs? SPARQL 1.2 or is it possible to modify an existing spec? I guess this would be strange right, because somebody would have to tell developers of the existing triple stores that there have to be done some changes in their implementation. Lorenz > > Andy > > On 28/01/18 10:56, Lorenz B. wrote: >> Hi all, >> >> just if somebody is interested in reading about the different behavior >> of triple stores when evaluating FILTER EXISTS. [1] >> >> Not sure how often this feature is used nowadays, but anyways >> interesting to know ( though I'd never write the SPARQL query as given >> in the example of the paper, seems odd) >> >> >> Cheers, >> >> Lorenz >> >> [1] https://arxiv.org/pdf/1801.04387.pdf >>
