- From: Luke Wilson-Mawer <luke.wilson-mawer@garlik.com>
- Date: Tue, 29 Sep 2009 14:32:13 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
I missed one: Luke Wilson-Mawer wrote: > Seaborne, Andy 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. I think variables unlock a some really compelling features, but > because property paths is a time permitting feature and variables > introduce a fair amount of issues, I think it best to leave them out > and concentrate on the core. Perhaps implementors will solve some of > these problems. >> 3/ With access to the length of the path matched >> Issues include how multiple paths between two nodes are handled (two >> lengths possible). >> > 0. I don't fully understand the issues that come from allowing access > to the length of the path. >> 4/ With access to the path matched (path-valued variables is one >> possibility) >> Issues as 3 + what is a path value "datatype". -1. This follows from my answer to 2). >> >> 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. I don't see the advantage of having a common syntax. >> Then >> >> 6/ Do nothing in this round - too early to standardise. >> > -1. Property paths have been implemented in a few places, and I think > they add a lot of power to the language. Even if we only standardise > a rump, I think it opens the door for more exciting features in the > future. >> Andy >> >> >> http://www.w3.org/2009/sparql/wiki/TaskForce:PropertyPaths >> http://www.w3.org/2009/sparql/wiki/Feature:PropertyPaths >> >> [1] >> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0315.html >> >> -------------------------------------------- >> Hewlett-Packard Limited >> Registered Office: Cain Road, Bracknell, Berks RG12 1HN >> Registered No: 690597 England >> >> > >
Received on Tuesday, 29 September 2009 13:32:48 UTC