Thompsonbry.systap added a comment.

There are two known issues with the property path operator that Nik and I 
discussed today. These are [1] and [2].  The first of these issues means that 
the operator is actually fully materializing the property paths *before* giving 
you any results.  [1] is a ticket to change that an do incremental eviction of 
the results.  That will fix the "liveness" issue you are seeing with that path 
expression.  The other ticket deals with another problem where the property 
path operator can become CPU bound if the necessary access paths are in cache 
since there is no IO Wait.  However, I suspect that [2] will disappear when we 
address [1].  As for the timing on this, we can elevate this to a critical 
issue and get it done in our next sprint for the 1.5.1 release.

Nik and I also discussed the inference vs materialization question as it 
relates to property paths.  Out of all the property hierarchies, only the 
geo-political one involves transitive traversal up more than a single 
predicate.  I suspect that (with the fix to [1]) that you can easily use 
property paths for all such expressions.

The draft of SPARQL property path support included a mechanism to bind the 
actual path onto variables.  Unfortunately this did not make it into the final 
specification of property paths.  Using property paths you can specify the path 
as a regular expression of predicates to be traversed, but you can not extract 
the actual vertices along that path.  However, the blazegraph property path 
operator internally *does* support this along with minimum and maximum 
traversal limits.  The ALP (Arbitrary Length Path) Service [3] exposes all of 
this using an ASTOptimizer.  See ASTALPServiceOptimizer in the 1.5.0 release.  
It is pretty scarce on documentation. I will fix that.  I will also add a page 
on our wiki for this.

Thanks,
Bryan

[1] http://trac.bigdata.com/ticket/1003 (Property path operator should output 
solutions incrementally)
[2] http://trac.bigdata.com/ticket/994 (Property Path operator can become CPU 
bound)
[3] http://trac.bigdata.com/ticket/1072 (Configurable ALP Service)


TASK DETAIL
  https://phabricator.wikimedia.org/T90116

REPLY HANDLER ACTIONS
  Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign 
<username>.

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev, Thompsonbry.systap
Cc: Thompsonbry.systap, Beebs.systap, Haasepeter, Aklapper, Manybubbles, 
jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, GWicke, daniel, JanZerebecki



_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to