Triply-Dev / YASGUI.YASQE-deprecated

Deprecated, see https://github.com/TriplyDB/Yasgui for the Yasgui monorepo
MIT License
73 stars 36 forks source link

Invalid warnings for predicate-object list when one of the objects is a blank node containing a predicate path #69

Closed dwvisser closed 9 years ago

dwvisser commented 9 years ago

Here's the simplest query I find that reproduces the issue:

PREFIX ex: <http://example.org/>

SELECT * WHERE {
  ?a ex:foo ?b ;
     ex:bar [ ex:baz/ex:buz ?c ].
}

The issue seems to be occur whenever a graph pattern contains:

  1. a predicate-object list, where
  2. the second (or later) object is a blank node, and
  3. the blank node contains a predicate path.

This bug is also filed at https://openrdf.atlassian.net/browse/SES-2255

LaurensRietveld commented 9 years ago

Are you sure this is valid SPARQL 1.1? If I look at the spec, I see that the BlankNodePropertyList ([99]) lists verbs (i.e. IRI/var) as possible property values, but not property paths

dwvisser commented 9 years ago

I think that TriplesSameSubjectPath allows this to be valid SPARQL, using

which leads into property paths.

dwvisser commented 9 years ago

Wait. I see your point. The construction I gave in my the second bullet of my last comment is only valid for the first predicate-object pair, not the subsequent ones, which is precisely what is manifesting here.

abrokenjester commented 9 years ago

Hm. I think this may be an error in the SPARQL grammar. It certainly seems arbitrary to allow property paths in a blank node object for the first object after a subject/predicate pairing, but not for any subsequent ones. It doesn't look like this was done by design, to me. Agreed though that YASQE implements what the current spec prescribes.

LaurensRietveld commented 9 years ago

If you have an EBNF for queries that sesame supports, it should be pretty straightforward to generate a JS grammar based on that. (see https://github.com/YASGUI/YASQE/tree/gh-pages/lib/grammar)

dwvisser commented 9 years ago

Thank you. I have tested and Sesame does successfully run the query, despite it not being valid according to the official SPARQL 1.1 grammar. I have posted the result on the Sesame issue tracker.