- 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