W3C home > Mailing lists > Public > semantic-web@w3.org > June 2010

Re: What is it that's wrong with rdf:List

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Sun, 20 Jun 2010 12:23:49 +0100
Message-ID: <4C1DFA45.80405@talis.com>
To: Pat Hayes <phayes@ihmc.us>
CC: Paul Gearon <gearon@ieee.org>, Norman Gray <norman@astro.gla.ac.uk>, Semantic Web <semantic-web@w3.org>


On 19/06/2010 10:05 PM, Pat Hayes wrote:
>
> On Jun 19, 2010, at 11:54 AM, Andy Seaborne wrote:
>
>>
>>
>> On 17/06/2010 11:35 PM, Paul Gearon wrote:
>>> The main problem with an RDF list is that there is no mechanism in
>>> SPARQL to query or update them. SPARQL only allows you to form queries
>>> that explicitly describe connections, while an arbitrary list can have
>>> any number of elements down its length. That means that you can refer
>>> to, say, the 2nd, 3rd, or 4th elements in the list, but there is no
>>> way to refer to ALL the elements in the list, since you don't know how
>>> long the list is.
>>>
>>> SPARQL 1.1 will fix this problem with "property paths".
>>
>> with
>>
>> { <list> rdf:rest*/rdf:first ?x }
>>
>> this is only a partial solution:
>>
>> 1/ Order in a list is not preserved
>
> ? Preserved by what? Lists in RDF have an order (that is, the elements
> of the list are put into an order by the list.) What is it that doesn't
> 'preserve' this?

The SPARQL property path expression that Paul mentioned does not provide 
any guarantee on order of results returned, nor do further operations of 
the SPARQL algebra for graph patterns preserve order.  SPARQL looses the 
ordering.  It can't properly return lists either, only members of a list.

>
>> yet the nature of a list is that it is ordered (e.g. authors of a paper).
>>
>> 2/ { ?list rdf:rest*/rdf:first ?x } does not do what you might think
>> it does. A tail of an rdf:List is itself a list so if you have (1 2 3)
>> then there are lists (1 2 3), (2 3) and (3) in the graph. (This isn't
>> as major as the lack of order.)
>
> This is how lists are in LISP (c. 1959) and in every list-processing
> language since. Don't go blaming RDF for this.

I'm not blaming RDF, I am stating a consequence of the use of property 
paths to access RDF lists.

Lisp doesn't have triples :-)

>
>>
>> As Paul says, update is not pretty.
>>
>> The complete solution would be to have lists as first class data
>> object in the RDF model (as well as bags).
>
> Um, they are. Lists as described by the RDF List vocabulary are
> *exactly* the LIsp model of a list. What more do you mean by
> 'first-class'? SPARQL could easily allow list-specific querying which
> presumes that the RDF uses the rdf:List vocabulary correctly (and
> produces unpredictable results if not, say.)

Because the basic RDF model is triples, and lists are encoded as 
triples, there are two views, list vocabulary (if the list is sensibly 
formed) and purely triples view.  If there is to be a global assumption 
that list are to be understood, maybe it would be more convenient to 
have lists in the RDF abstract model, not just triples.

I'm not advocating change - in fact, any change to RDF would be a very 
bad thing IMHO.  There is data out there, there is code out there. 
Changing, whether adding or removing features breaks one or both.  So 
unless there is a fundmental barrier, let's live with what we have got.

	Andy

>
>> Like RDF containers, modelling as triples, then exposing the triples
>> means the gory details are passed onto the application and assumes
>> everyone plays the game.
>>
>> Nathan - this is the nature of lists that SPARQL is dealing with. It
>> could have imposed a list concept but that would only be for SPARQL,
>> not RDF in general.
>>
>> Andy
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC (850)434 8903 or (650)494 3973
> 40 South Alcaniz St. (850)202 4416 office
> Pensacola (850)202 4440 fax
> FL 32502 (850)291 0667 mobile
> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>
>
>
>
>
Received on Sunday, 20 June 2010 11:24:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:36 GMT