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

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

From: Toby Inkster <tai@g5n.co.uk>
Date: Fri, 18 Jun 2010 00:22:16 +0100
To: Norman Gray <norman@astro.gla.ac.uk>
Cc: Semantic Web <semantic-web@w3.org>
Message-ID: <20100618002216.73a2ce56@miranda.g5n.co.uk>
On Thu, 17 Jun 2010 23:19:40 +0100
Norman Gray <norman@astro.gla.ac.uk> wrote:

> What is it that's so wrong/bad/wicked with rdf:List?  Can anyone
> point me to some reading?

rdf:Lists are tricky to query in the current version of SPARQL, and
pretty annoying to deal with in RDF tools that don't include explicit
functions to deal with them. They also look ugly when output in RDF
serialisations that don't have syntactic sugar for them (e.g.
N-Triples, RDFa).

That said, there are some modelling situations where they're useful,
and in those cases, you should probably use them, but before doing so,
you should consider whether there's a better way.

If you need to keep a bunch of resources in order, there are often
other options. For example, next/previous predicates:

	<#chapter1> :next <#chapter2> .
	<#chapter2> :next <#chapter3> .
	# ...

Sometimes you have a bunch of resources which have next/previous
relationships along multiple dimensions/axes/lines. Take for example,
the London Underground - what is "next" from Victoria station? Even if
you pick a convention on whether "next" means to go North or to go
South, you still have to worry about stations which are on multiple
lines. We've moved from a situation whether nodes have inherant
next/previous relationships to one where nodes can participate in
multiple sequences.

This can still be modelled with next/previous predicates:

	:nextAlongVictoriaLine rdfs:subPropertyOf :next .
	:nextAlongDistrictLine rdfs:subPropertyOf :next .

	<#Victoria> :nextAlongVictoriaLine <#Pimlico> .
	<#Victoria> :nextAlongDistrictLine <#SloaneSquare> .

But this method is starting to look less ideal. Lists offer a neater
way of defining things:

	<#VictoriaLine> :stations (<#Brixton> <#Stockwell> ...) .
	<#DistrictLine> :stations (<#Richmond> <#Kew> ...) .

That's a good way of modelling the order of stations along a line. But
if you're using SPARQL 1.0, then try figuring out which lines Green
Park is on and you'll find yourself in a muddle. A good solution is to
supplement your rdf:List data with some non-list data for each station,
linking back to the lines without using lists:

	<#Victoria> :servedBy <#CircleLine> ,
	                      <#DistrictLine> ,
	                      <#VictoriaLine> .

I do actually have a railway vocab <http://ontologi.es/rail/vocab#>
which models data much like that.

	<#someStation> rail:located_at [
		rail:distance [ unit:metres 123 ] ;
		rail:along_route <#someRoute>
		] .
	<#someRoute> rail:stations (<#someStation> ...) . 

So yeah, my suggestion would be that if you need to publish data about
ordered nodes rdf:List is a good way of doing it, especially if the
order of the nodes is not intrinsic to them. But try to back it up with
some additional non-List triples for people who don't care about the
order.

> And what's the alternative, if I want to say in RDF that a particular
> thing is related to an ordered set of other things -- perhaps an
> article has a particular sequence of authors?

Using my technique of a list backed up with non-list triples, something
like:

	<#doc> ex:authors (<#carol> <#alice> <#bob>) ;
	       foaf:maker <#alice> , <#bob> , <#carol> .

> [4] refers to an OWLList ontology (and a broken link to a rationale).
> I follow how that ontology works, but don't get the significance of
> the apparently minor ways in which it's different from rdf:List.

It seems to be more or less the same as rdf:List. I'd certainly not use
it as you gain nothing, but sacrifice rdf:List's syntactic sugar in
Turtle and RDF/XML, and sacrifice any special support for rdf:List
that RDF toolkits have to offer.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
Received on Thursday, 17 June 2010 23:23:43 GMT

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