[Bigdata-developers] trac739 zlpp fixed (mildly interesting)

[Jeremy C. <jj...@gm...>]

I drilled down on defect 739 this morning which had to do with zero length property paths with variables at either end.

The specification is not very practical: it says that such a zlpp matches every node in the graph.
http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#defn_evalPP_ZeroOrOnePath

however, I noted that sometimes bigdata was giving the right answer, and sometimes the wrong answer: and the times when it was getting the right answer was when the cardinality estimate for the zlpp was higher (because the property inside it  had more matches).

Thus the fix was to correct the implementation of
com.bigdata.rdf.sparql.ast.ArbitraryLengthPathNode.getEstimatedCardinality(StaticOptimizer)

to return the correct Long.MAX_VALUE in this case, even though we don't implement it correctly (and we actually return zero values rather than infinite); and then the rest of the optimizer does the right thing.

The result is that in the test cases presented (by my colleague) in which we have a zlpp that may match or may not, we now get correct results but in the artificial case

select *
{ ?s <eg:noSuchProperty>? ?o }
LIMIT 100

we continue to incorrectly return no results.

Note this sparql endpoint gets this query right:
http://resource.geolba.ac.at/PoolParty/sparql/tectonicunit

so it is not impossible …. (not that I would advocate this)



Jeremy