W3C home > Mailing lists > Public > semantic-web@w3.org > April 2015

Re: Easier SPARQL queries of ordered lists? (Simple List Conventions)

From: David Booth <david@dbooth.org>
Date: Thu, 16 Apr 2015 01:02:00 -0400
Message-ID: <552F4248.4010602@dbooth.org>
To: Sebastien Ferre <Sebastien.Ferre@irisa.fr>, semantic-web@w3.org
Hi Sebastien,

The Jena ARQ library actually provides a SPARQL extension, implemented 
as a "magic property", that gives exposes the ordering of elements in an 
rdf:List so that they can be returned from a SPARQL query in order. 
There is an example in the Simple List Conventions document:
http://goo.gl/8PNuAG#heading=h.f03x3eaqzz3a
It would be nice if a capability like that -- or some other improved 
support for lists -- were a part of standard SPARQL, but it is not. 
That's why I've written up the Simple List Conventions.

FYI, I have added an example that compares the Simple List Conventions 
with the Ordered List Ontology (OLO):
http://goo.gl/8PNuAG#heading=h.ei3lksj4vzki

Thanks,
David Booth

On 04/14/2015 09:59 AM, Sebastien Ferre wrote:
> Hi,
>
> On 04/14/2015 11:07 AM, David Booth wrote:
>> rdf:Lists are a pain for SPARQL queries, because it's hard to retain the
>> list ordering when querying, even if it is possible[1].  To work around
>> this problem, some list ontologies have been created[2][3], but I find
>> them overly verbose for routine use.  The Jena ARQ library also has a
>> feature that helps[4], but it is not standard SPARQL.
>
> I can only agree with the need for better query notations for lists
> and collections, and in fact more generally for any RDF structure based
> on blank nodes.
>
>> I'd like to propose a simpler convention that encodes each item as a
>> (value index) pair, and a simple vocabulary to go with it.  For example,
>> instead of writing this:
>>
>>    PREFIX : <http://example/>
>>    :jane :likes (
>>          "bananas"
>>          "apples"
>>          "oranges"
>>          ) .
>>
>> each item would have an explicit index, like this:
>>
>>    PREFIX : <http://example/>
>>    :jane :likes
>>          ( "bananas" 0 ) ,
>>          ( "apples"  1 ) ,
>>          ( "oranges" 2 ) .
>>
>> which can be easily queried like this, retaining order:
>>
>>    SELECT DISTINCT ?item {
>>      :jane :likes ( ?item ?index ) .
>>    } ORDER BY ?index
>
>
> The first thing that pops to my mind is that you could use
> containers to get the same result with standard notations,
> only assuming a function to get the index of the rdf:_n
> properties.
>
> # description
> :jane :likes
>       [ rdf:_1 "bananas" ;
>         rdf:_2 "apples" ;
>         rdf:_3 "oranges" ] .
>
> # query
>
> SELECT DISTINCT ?item WHERE {
>     :jane :likes [ ?rdf_n ?item ] .
> } ORDER BY (index(?rdf_n))
>
>
> However, the annoying thing with your notation and mine is that
> indices have to be given explicitly, which is both tedious and
> unreliable, especially when deleting and inserting elements in
> lists. Ideally, the indices should come for free.
>
> Why not imagine a "list element pattern" as an extension of SPARQL,
> like the following with the obvious meaning ?
>
>     ?item in ?list at ?index .  (or any syntactic alternative)


>
> It would be a kind of implicit triple pattern
> relating a list, an item of the list, and its position in the list.
> On your example:
>
> SELECT DISTINCT ?item WHERE {
>     :jane :likes ?list .
>     ?item in ?list at ?index
> } ORDER BY ?index
>
>
> My two cents,
>
> Sébastien Ferré
>
>
>
>> References
>> 1. Standard SPARQL query of rdf:List that retains list order:
>> http://stackoverflow.com/questions/17523804/is-it-possible-to-get-the-position-of-an-element-in-an-rdf-collection-in-sparql/17530689#17530689
>>
>>
>>
>> 2. Ordered List Ontology:
>> http://smiy.sourceforge.net/olo/spec/orderedlistontology.html
>>
>> 3. Collections Ontology:
>> http://www.essepuntato.it/lode/owlapi/http://purl.org/co/
>>
>> 4. Jena ARQ list:index example:
>> http://stackoverflow.com/questions/17523804/is-it-possible-to-get-the-position-of-an-element-in-an-rdf-collection-in-sparql/17528290#17528290
>>
>>
>>
>>
>
>
>
>
Received on Thursday, 16 April 2015 05:02:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:42 UTC