Meeting minutes
<AndyS> present
<AndyS> present?
<AndyS> who is here?
<AndyS> present?
Scribe?
olaf: I did not had time to work on SPARQL the past few days
olaf: I made an effort to make a go case by case for every kind of pattern and discuss why this case to be covered or not
olaf: The one that is really problematic is the SERVICE one
olaf: The problem is specifically around bnode
olaf: The doc is in the repo
lisp: didn't we say we also go through errata?
… some of them seem easy to address, others I didn't understand what the problem is
… how do we proceed?
<AndyS> https://
lisp: I have looked at the full errata list
AndyS: They need to be sorted out. We have done some already.
… Do you think there are any that are particularly difficult?
lisp: I propose I will write a note to the WG mailing list
… where I distinguish them into the three categories
… cat1 purely editorial, cat2 actual changes, cat3 not even clear what the problem is
<gb> Issue 21 SPARQL Query Errata (2/5) (by afs) [spec:bug]
<gb> Issue 22 SPARQL Query errata (3/5) (by afs) [spec:bug]
<gb> Issue 23 SPARQL Query Errata (4/5) (by afs) [spec:bug]
<gb> Issue 24 SPARQL Query Errata (5/5) (by afs) [spec:bug]
AndyS: The four GitHub issue mentioned above contain the errata from the official errata list
… some of them are already addressed.
olaf: The last definition defines how to evaluate an EXIST in a context of a solution mapping
olaf: There is completely different way to define this by defining a new symbol for the algebra syntax and place it at the beginning of any group graph pattern
olaf: If applied directly, it leads to more joins than what is needed
<AndyS> w3c/
<gb> Pull Request 257 Correlated EXISTS (by afs)
olaf: S: This goes more in the direction on this PR ^
AndyS: This goes more into the direction of what pfps describe
AndyS: The injection is there. The new operator is "get current row", it fetches from the context of the evaluation
AndyS: As you go down to a nested exist, you get the combined correlated row passed down
AndyS: Instead of having an argument in eval this use an aside stack
olaf: I think the two operations can be merged
olaf: There is the new parameter to inject the solution mapping and the new operator to use it
olaf: I think that the one pfps has in mind
pfps: There is no separated stack for injected solution mapping, it is part of the call stack
olaf: I would be happy to write an other document with the merged idea (the one from pfps email)
AndyS: We don't have to write everything into notes
AndyS: We have to commit to something
pfps: Aside from the horrible computational cost, no other points
<Zakim> gtw, you wanted to ask for example where blank nodes in SERVICE would cause problems
pfps: The problem is that SPARQL functions should be able to look at blank nodes
gtw: If we assume we find some way to convey them in a VALUE clause, is there a deeper problem?
pfps: It depends on what you think about identity of blank nodes
pfps: If you SERVICE you called is on the same data, you might like your blank node identity to be the same
pfps: If it's on different data, you might prefer that blank nodes do not match anything on the other side
pfps: We don't have a good definition of SERVICE, so we don't know what is supposed to happen
pfps: Suppose you have an RDF dataset that share blank nodes between graphs, a part need to be protected and you use SERVICE for that, you want to keep blank node identity
gtw: But SERVICE document state it uses SPARQL protocol that does not allow to communicate blank node identity
AndyS: There is no syntax to move concrete blank node ids around
AndyS: There is negation in SPARQL, even if blank node are not going to match, you can't ignore them
AndyS: if you can find a way to move them around great, but you are outside of the spec at this point
lisp: There is at least 1 implementation that run SERVICE clauses in process in the same evaluation environment but runs it has a view
lisp: In that case, what pfps is concern about is a real concern
lisp: For the "SERVICE for access control", what happens with blank nodes is an issue
AndyS: An other example is to use SERVICE for full text search
gtw: I think this is opening a big area of features but I am afraid this is outside of the spec
<gtw> https://
gtw: We don't have a mechanism to pass blank nodes in SERVICE through SPARQL protocol
pfps: Assuming we had it, we are done
AndyS: If we don't introduce a mechanism (as someone said, we don't want to introduce new features)...
pfps: We have the problem of some queries with EXISTS are malformed, it's an errata
pfps: We can say "we need a new mechanism to fix SERVICE in EXISTS" or we can say "deep stop at SERVICE" which could be possible but a little bit awkward
pfps: SHACL prohibits service completely
olaf: I was considering the idea that SERVICE is not allowed in EXISTS
<lisp> +1 to service does not propagate state
AndyS: If you assume that SERVICE are their own separated world, then forbidding them in EXISTS make sense
AndyS: I don't want to say "the spec does not define this case" but I prefer that against this becoming a blocking issue
TallTed: If I recall correctly, SERVICE is not forbidden in SHACL, it's more an unwelcome guest (there but nobody wants to acknowledge it)
<AndyS> "SPARQL queries must not contain a federated query (SERVICE)"
<AndyS> at https://
lisp: I don't think it would be a limitation on the current spec to state "the state is not propagated inside of a SERVICE clause"
<Zakim> Tpt, you wanted to state that not propagating into SERVICE would be sad for systems that do dynamic federation (introducing SERVICE calls automatically)
pfps: Indeed, both SHACL 1.1 and 1.2 prohibit SERVICE