W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: [TF-PP] Possible starting points

From: Luke Wilson-Mawer <luke.wilson-mawer@garlik.com>
Date: Tue, 29 Sep 2009 14:32:13 +0100
Message-ID: <4AC20C5D.7090804@garlik.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:08:28 GMT