- From: Paul Gearon <gearon@ieee.org>
- Date: Tue, 29 Sep 2009 10:22:30 -0400
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
On Tue, Sep 29, 2009 at 7:12 AM, Seaborne, Andy <andy.seaborne@hp.com> wrote: > This is a request for your views on starting points for the property paths time permitting feature. > > Please send +1/0/-1 for the options (which aren't meant to be mutually exclusive) or we might get telcon time. > > I've tried to list the main possibilities in terms of styles and approach as starting points: all have variations and areas of uncertainty (e.g. ordering of results). > > 1/ Property paths only mention IRIs or prefixed names. > > The most conservative choice. Still need to relate to entailment. +1 > 2/ Property paths with variables and IRIs or prefixed names. > (issues include restriction of what can be asked a la ?p* discussion) +1. Takes memory, but is not hard (I've implemented this in the past). > 3/ With access to the length of the path matched > Issues include how multiple paths between two nodes are handled (two lengths possible). -1. Existing transitive algorithms don't work well with this. Plus there are issues of syntax for binding the path-length variable. > 4/ With access to the path matched (path-valued variables is one possibility) > Issues as 3 + what is a path value "datatype". -1. Same issues as for 3, only more so. > For all of them: add an option to have > > 5/ A mechanism that will allow a variety of path matching schemes, and provide one such system. > Roughly, this would involve defining syntax so various different approaches can at least use common syntax but choose from 1-4 as to what the WG describes in this round of standardization and show the relationship to the syntax. E.g having a PATH keyword idea in [1]. -1 > Then > > 6/ Do nothing in this round - too early to standardise. -1. I'd at least like to see a "best" or "common" practice. Regards, Paul
Received on Tuesday, 29 September 2009 14:23:10 UTC