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

Re: Next telecon features & beyond

From: Alexandre Passant <alexandre.passant@deri.org>
Date: Fri, 13 Mar 2009 18:47:08 +0000
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <54B0E197-AFB3-4AA4-A0A1-17D0F7543B56@deri.org>
To: Lee Feigenbaum <lee@thefigtrees.net>

Le 13 mars 09 à 18:25, Lee Feigenbaum a écrit :

> Alexandre Passant wrote:
>> Hi,
>> Le 12 mars 09 à 06:49, Lee Feigenbaum a écrit :
>>> Next week I'd like to continue where we left off, with brief  
>>> discussions of some of the more "major" suggested features that  
>>> impact the query language itself. These include:
>>> Assignment
>>> Property paths - Andy
>>> Aggregates
>>> Negation
>>> Update
>>> Basic Federated Query
>>> Parameterized inference/control of inference
>> I thinks that Path Length [1] may also be included in that list, as  
>> a major feature.
>> As it strongly relates to property path: Andy, OpenLink, any  
>> objection to merge the two features in a single page ?
>> (As path length does not makes any sense without the path itself,  
>> it's obvious for the inclusion in that direction, but I want to be  
>> sure both of you agree on adding another feature (lenght) to your  
>> path initial proposal.)
> I don't see these as being the same at all.

I didn't meant they are the same, I meant that they're related and  
might be suggested as a single 'Path' feature that includes both  
regexp to define paths and filter for path length.

i.e. what is done in Corese [1] with the related PathLength example [2]

   <http://example.org/bob> $path ?y .
FILTER (match($path, foaf:knows)) // Regexp for the path
FILTER (pathLength($path) >= 1 && pathLength($path) <= 2) // length

Without any pathLength filtering, the query is simply a property path  
query as proposed in [3], but that way of using a variable (rather  
than including the regexp directly as in ":foo rdf:type/ 
rdfs:subClassOf* :bar") allows imho more extensibility, especially for  
that length feature.



[1] http://www-sop.inria.fr/edelweiss/software/corese/v2_4_1/manual/next.php
[2] http://www.w3.org/2009/sparql/wiki/Feature:PathLength
[3] http://www.w3.org/2009/sparql/wiki/Feature:PropertyPaths

> My understanding is that property paths allow me to specify in a  
> regular expression-like way an explicit chain that connects two  
> nodes. For path length, you need to start having variables match  
> arbitrary-length paths between nodes, right? (Once you ahve a  
> variable matching a path, then it's natural to add a function to get  
> the length of that path.) And that seems like a whole other ball of  
> wax to me.
> Am I misunderstanding?
> Lee

Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .
Received on Friday, 13 March 2009 18:47:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC