On 29/01/14 14:53, Andy Seaborne wrote:
[[ Rushed answer - more later ]]
Technically, every basic pattern involves a path in SPARQL 1.1
?s :p ?o .
is path.
ARQ compiles/optimizes paths down to triple patterns where ever possible
by applying expansion rules for "/" "|" "^"
see com.hp.hpl.jena.sparql.algebra.optimize.TransformPathFlattern
and com.hp.hpl.jena.sparql.path.PathCompiler
and what can't be remains is evaluated as a path expression at run time.
The path expression engine can deal with any legal paths but, because
of query exspansion, it's the unbounded paths that get left for run time.
?x foaf:knows/foaf:knows/foaf:name ?name .
==>
(bgp
(triple ?x foaf:mbox <mailto:alice@example>)
(triple ?x foaf:knows ??P217)
(triple ??P217 foaf:knows ??P216)
(triple ??P216 foaf:name ?name) )
where ??P... are system generated variables and hidden from "SELECT *".
At run time, PathEngine executes remaining paths but it's not property
path sensitive. It should be.
Ideally, rewrite the path expression to have explicit (propfunc ...) so
it shows in the algebra rather than juts do it implicitly by changing
PathEngine.doOne.
Do raise a JIRA for it - maybe even turn it into a GSoC project. It's
too small on it's own (?) but combine with property functions to runtime
backwards inference and it's a nice project for someone.
Andy
The function that needs to change is :
com.hp.hpl.jena.sparql.path.eval
PathEngine.doOne
specifically the call to Graph.find.
If that consulted the property function registry
(also check other .find calls in that package - there are very few).
Test cases (JUnit code ideally) would be good; patches are better.
Andy
PS and any speed ups would also be good. The code can be become
expensive if it's in an intense part of the query.
On 29/01/14 14:07, Joshua TAYLOR wrote:
On Wed, Jan 29, 2014 at 12:32 AM, Rob Vesse <[email protected]> wrote:
Most likely no, did you try printing the algebra for the query?
This would show you whether the query plan contains a propertyfunc
operator or not.
Thanks, I haven't worked with these kind of extensions before, so I
didn't really know where to start. Here are the algebra expressions
for simplified queries. The property function is called in the first
case (with (triple _ p _)), but not in the second (with (path* p)).
Neither algebra contains a propertyfunc operator, though. Do I need
to expand this farther or something?
Query: select * { ?s <java:CBDSPARQLExample$sameBlank> ?o }
Algebra: (bgp (triple ?s <java:CBDSPARQLExample$sameBlank> ?o))
Query: select * { ?s <java:CBDSPARQLExample$sameBlank>* ?o }
Algebra: (path ?s (path* <java:CBDSPARQLExample$sameBlank>) ?o)
Through some more experimentation, the property function isn't called
for (seq … p …), either. I think this is problematic. For the `*`
case, things might be complicated, but consider a sequence pattern.
According to 9.2 Examples [1] from the SPARQL 1.1 recommendation,
[[[
Sequence: Find the names of people 2 "foaf:knows" links away.
{
?x foaf:mbox <mailto:alice@example> .
?x foaf:knows/foaf:knows/foaf:name ?name .
}
This is the same as the SPARQL query:
SELECT ?x ?name
{
?x foaf:mbox <mailto:alice@example> .
?x foaf:knows [ foaf:knows [ foaf:name ?name ]].
}
]]]
Of course, the SPARQL recommendation doesn't address Jena's property
functions, but with the current behavior, property functions will be
called in:
Query: select * { ?s <java:CBDSPARQLExample$sameBlank> [
<java:CBDSPARQLExample$sameBlank> ?o ] }
Algebra: (bgp
(triple ?s <java:CBDSPARQLExample$sameBlank> ??0)
(triple ??0 <java:CBDSPARQLExample$sameBlank> ?o)
)
but not in:
Query: select * { ?s
<java:CBDSPARQLExample$sameBlank>/<java:CBDSPARQLExample$sameBlank> ?o
}
Algebra: (path ?s (seq <java:CBDSPARQLExample$sameBlank>
<java:CBDSPARQLExample$sameBlank>) ?o)
I did run those queries on some data, and observed the log output
indicating that the property function is run in the first case, but
not the second. I think this is counterintuitive behavior, since what
the SPARQL rec says is equivalent has different behavior. I haven't
looked into how property paths are matched, so I don't know how hard
this is to adjust.
If this seems like something that isn't intended behavior (or even
just isn't documented), I'd be happy to make a minimal example
demonstrating the issue and put it on JIRA.
//JT
[1] http://www.w3.org/TR/sparql11-query/#propertypath-examples
