This is perfectly legal and Jena is correct in allowing it.

GraphNodePath can go down the TriplesNodePath route:

[105] GraphNodePath ::= VarOrTerm | TriplesNodePath

TriplesNodePath can go down the BlankNodePropertyListPath route:

[100] TriplesNodePath ::= CollectionPath | BlankNodePropertyListPath

And BlankNodePropertyListPath allows exactly the style of syntax you've
written:

[101] BlankNodePropertyListPath ::= '[' PropertyListPathNodeEmpty ']'

So the bug is with Virtuoso

Hope this helps,

Rob


On 15/10/2013 13:21, "Joshua TAYLOR" <[email protected]> wrote:

>Hi all,
>
>I recently posted an answer to a Stack Overflow question [1] that led
>me to write the query
>
>select ?prop ?c
>where {
>  dbpedia:Milano dbpedia-owl:wikiPageRedirects* [ ?prop ?c ] .
>}
>
>and submit it to the DBpedia public endpoint [2] (which has the
>appropriate namespace prefixes defined), but I get this error message:
>
>"""
>Virtuoso 37000 Error SP031: SPARQL compiler: Object of transitive
>triple pattern should be variable or QName or literal, not blank node
>
>SPARQL query:
>define sql:big-data-const 0
>#output-format:text/html
>define sql:signal-void-variables 1 define input:default-graph-uri
><http://dbpedia.org> select ?prop ?c
>where {
>  dbpedia:Milano dbpedia-owl:wikiPageRedirects* [ ?prop ?c ] .
>}
>"""
>
>If I explicitly define the prefixes
>
>prefix dbpedia: <http://dbpedia.org/resource/>
>prefix dbpedia-owl: <http://dbpedia.org/ontology/>
>select ?prop ?c
>where {
>  rdf:Milano rdf:wikiPageRedirects* [ ?prop ?c ] .
>}
>
>and bring it over to sparql.org's validator, I get no complaints, and
>it says the query is equivalent to
>
>  1 PREFIX  dbpedia-owl: <http://dbpedia.org/ontology/>
>  2 PREFIX  dbpedia: <http://dbpedia.org/resource/>
>  3
>  4 SELECT  ?prop ?c
>  5 WHERE
>  6   { dbpedia:Milano (dbpedia-owl:wikiPageRedirects)* _:b0 .
>  7     _:b0 ?prop ?c
>  8   }
>
>which makes sense, based on 4.1.4 Syntax for Blank Nodes [4] from the
>spec which says:
>
>"""
>The following two forms
>[ :p "v" ] .
>[] :p "v" .
>allocate a unique blank node label (here "b57") and are equivalent to
>writing:
>_:b57 :p "v" .
>"""
>
>I've looked through the SPARQL 1.1 grammar, and traced down through
>
>GroupGraphPattern
>GroupGraphPatternSub
>TriplesBlock
>TriplesSameSubjectPath
>PropertyListPathNotEmpty
>ObjectListPath
>ObjectPath
>GraphNodePath
>VarOrTerm
>GraphTerm [3]
>
>at which point
>
>[109]  GraphTerm  ::=  iri | RDFLiteral | NumericLiteral |
>BooleanLiteral | BlankNode | NIL
>[138]  BlankNode  ::=  BLANK_NODE_LABEL | ANON
>
>so it seems like it's not legal (unfortunately).
>
>At first I'd though this might be a Virtuoso bug, since this would be
>pretty useful behavior to have, but now it looks like it might be a
>bug in the (Jena-based) validator.
>
>This seems like it might be related to an earlier "bug" in the spec
>that prevents property paths _within_ blank nodes [5].  Is this a bug
>in Jena or in Virtuoso?  I'll file the bug report appropriately;  I
>just need to know where to send it.
>
>Thanks,
>//JT
>
>[1] http://stackoverflow.com/q/19380175/1281433
>[2] http://dbpedia.org/sparql
>[3] http://www.w3.org/TR/sparql11-query/#rGraphTerm
>[4] http://www.w3.org/TR/sparql11-query/#QSynBlankNodes
>[5] 
>http://mail-archives.apache.org/mod_mbox/jena-users/201202.mbox/%3C4F4019B
>[email protected]%3E
>-- 
>Joshua Taylor, http://www.cs.rpi.edu/~tayloj/




Reply via email to