I believe that the intuitive model that most users have is that blank
nodes in the data are concrete RDF terms like URI and literals.
SPARQL could/should have been defined to reflect that - i.e. based on an
algebra throughout.
An active community wanted something else but it has turned out that a
majority of real users have not engaged with that idea.
Andy
On 17/06/16 01:39, Jeremy J Carroll wrote:
I agree with the intuitive understanding but as a user, I prefer if the
specification supports me when I am disappointed in a vendor’s implementation.
I think Peter is calling out that in this particular case, it does not.
Jeremy
On Jun 16, 2016, at 5:08 PM, Gregory Williams <g...@evilfunhouse.com> wrote:
On Jun 16, 2016, at 4:32 PM, Peter F. Patel-Schneider <pfpschnei...@gmail.com>
wrote:
So consider
BGP( _:x :p ?y )
against the active graph G = { :s :p _:x . }
The RDF instance mapping is σ = { ( _:x, :s ) }.
The solution mapping is μ = { ( y, _:x ) }.
The pattern instance mapping is P = { ( _:x, :s ), ( y, _:x ) }.
This is a solution because P( _:x :p ?y ) = (:s :p _:x) which is a subgraph
of G.
The point is that the _:x that came from the EXISTS substitution is a blank
node and can be itself substituted for in the RDF instance mapping. This is
counter to what I think is the desired meaning for EXISTS.
Note that this is all just a little bit sloppy. To make it all precise
would require an extra injection from blank node names to real blank nodes
but this extra precision doesn't make any difference here.
That’s an interesting case. I haven’t gone through the definitions in depth in
a while, but I think you’re right that the discussion of matching BGPs in §18.3
and the evaluation semantics of EXISTS in §18.6 probably don’t do the expected
thing. The existing errata surrounding EXISTS evaluation shows that this was an
area where the spec fell a bit short.
Do you have a system that is actually giving you the results you describe?
My intuitive understanding, and one which I suspect most if not all
implementations use, is that the “blank nodes” that §18.3 references are the
syntactic blank nodes in the *query*, and shouldn’t apply to blank nodes that
come from the *data* that are used in an EXISTS filter evaluation.
Unfortunately, I don’t think there’s any way for substitute() to express a
(non-syntactic) blank node in the algebraic representation.
Does that align with what you think the expected behavior is?
thanks,
.greg
