W3C home > Mailing lists > Public > semantic-web@w3.org > October 2013

Re: SPARQL-friendly alternative to rdf:Lists?

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sat, 12 Oct 2013 17:56:24 +0100
Message-ID: <52597F38.8040403@epimorphics.com>
To: semantic-web@w3.org


On 11/10/13 15:02, David Booth wrote:
> rdf:Lists are notoriously difficult to use in SPARQL if one wishes to
> retain the *order* of the items in the list.  James Leigh and David Wood
> made a nice proposal a few years ago to address this problem directly at
> the RDF level,
> http://www.w3.org/2009/12/rdf-ws/papers/ws14
> but for whatever reasons, that work was not included in the charter of
> the current RDF working group.  As a result people often use some other
> means of representing ordered lists in RDF, such as by [item, index] pairs.
>
> For those who use an alternate way to represent an *ordered* list of
> items in RDF (instead of rdf:List), I am wondering:
>
> 1. What *ordered* list representation do you prefer, and why?
>
> 2. Have there been any efforts toward standardizing alternative
> *ordered* list representations in RDF?  E.g., has anyone written up a
> spec on how they prefer to do it?
>
> Thanks,
> David

I agree that RDF needs a built-in list type.  Encoding in triples does 
not provide a practical list type; it eventually shows through somehow. 
  The same can be said for a few other datastructures (e.g. bags).

This is RDF 2.0 territory - to be effective data modeling will change 
(because people have been working around RDF lists); toolkits are going
to have to change APIs.  Not "1.1" territory.

The retention of order in query results is complicated.  Combining 
results from subpatterns is typically a join, which is not order 
preserving and that gives the system options for different strategies 
for efficiency.

As a half way step, Jena provises some access properties for lists in 
SPARQL:

http://jena.apache.org/documentation/query/rdf_lists.html

but operators in SPARQL itself would be better.

Another step is to not assume that access language is SPARQL but more 
navigational in style.  There is scope and need for both.

Handling lists in persistent storage at scale is a non-trivial change 
but I think it's worth the effort.

	Andy
Received on Saturday, 12 October 2013 16:56:56 UTC

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