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

Re: [TF-PP] Possible starting points

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 29 Sep 2009 16:55:40 +0100
Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <893DFB38-BFE6-43AF-B017-C8FEA6A08388@garlik.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
On 29 Sep 2009, at 16:34, Lee Feigenbaum 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.
>> 2/ Property paths with variables and IRIs or prefixed names.
>> (issues include restriction of what can be asked a la ?p* discussion)
>> 3/ With access to the length of the path matched
>> Issues include how multiple paths between two nodes are handled  
>> (two lengths possible).
>> 4/ With access to the path matched (path-valued variables is one  
>> possibility)
>> Issues as 3 + what is a path value "datatype".
>> 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].
>> Then
>> 6/ Do nothing in this round - too early to standardise.
>> 	Andy
>
> I'm +1 on #1 and -1 on everything else: I'm afraid of the complexity  
> of everything else, and think that doing #1 enables a whole range of  
> uses. It also lays the (syntactical) groundwork for #2, at least,  
> and I don't think it precludes systems that want to do something  
> else for #3 and #4.

On reflection so am I, I was 0 on 2/, but I think it opens the door to  
queries with immense complexity.

e.g. just

SELECT * WHERE {
   ?a ?p* ?b .
}

I pretty nasty, and will require a very large working set to avoid  
loops.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD
Received on Tuesday, 29 September 2009 16:06:34 GMT

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