- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 19 Oct 2011 14:21:37 +0100
- To: Pierre-Antoine Champin <pierre-antoine@champin.net>
- CC: "public-rdf-wg@w3.org" <public-rdf-wg@w3.org>
On 19/10/11 13:55, Pierre-Antoine Champin wrote: > On 10/15/2011 08:35 PM, Andy Seaborne wrote: >> SPARQL 1.2 will not solve anything I'm afraid. SPARQL 1.1 Query has >> gone as far as it can, except maybe a little extra syntactic sugar with >> >> { ?list rdf:rest*/rdf:first ?member } >> >> It's much better than handling Seqs. >> >> SPARQL Update can manuipuate lists but it's ugly: >> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011JanMar/0389.html >> >> The fundamental problem in SPARQL is that any order is lost; so this >> list access works for some cases, where the order does not matter. > > well, as SPARQL 1.1 already allows > > SELECT ?member > WHERE { :my-list rdf:rest{3}/rdf:first ?member } > > I would *so* love SPARQL 1.2 for allowing > > SELECT ?rank, ?member > WHERE { :my-list rdf:rest{?rank}/rdf:first ?member } > ORDER BY ?rank Yes, but it's not so easy :-( The SPARQL-WG, in the requirements phase, explicitly did not adopt a goal of providing list support. The fact property paths give a partial solution is a bonus. A complete solution for going beyond the level of property paths would probably require a "path" value type so you could return the path matched and make tests on it. (Sounds like a list to me!) The "well-formed" RDF List case is easier than the general case with cycles and DAGs. The major lack is that the results do not naturally come back in order guaranteed by spec, which is a very reasonable user expectation. Andy > pa
Received on Wednesday, 19 October 2011 13:22:28 UTC