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

Re: RDF List and Collection questions

From: Jesse Weaver <weavej3@rpi.edu>
Date: Tue, 12 Oct 2010 14:00:38 -0400
Cc: Semantic Web <semantic-web@w3.org>
Message-Id: <7A17CC92-6227-47FE-98E8-A5959A7E7455@rpi.edu>
To: nathan@webr3.org
Hi Nathan.

On Oct 11, 2010, at 9:04 PM, Nathan wrote:

> Hi,
>
> One or ten questions here..
>
> Are two instances of rdf:List the same rdf:List if they have the  
> same rdf:first and rdf:rest values?
>
> Clarifications asked
> - Lists can be recursive - yes/no?
> - Lists can fork, in that two (or more) list chains can intersect  
> and share the same tail - yes/no?
> - Lists can use both bnodes or URIs - yes/no?
>
> Why are both rdf:List and rdf:Seq defined, does Seq offer something  
> that List does not (I can see things List offers that Seq doesn't  
> but not the other way around)? Are the two interchangeable?
>
rdf:List is a RDF collection, and rdf:Seq is a RDF container.  The RDF  
primer clarifies the difference in [1].  An RDF container cannot be  
"closed" while an RDF collection can, and I assume that is one of the  
"things List offers that Seq doesn't" that you are referring to.

Concerning the advantages of rdf:Seq over rdf:List, consider the  
bibo:authorList [2] property:

bibo:authorList rdfs:range [ a owl:Class; owl:unionOf (rdf:List  
rdf:Seq) ] .

The authors may be enumerated using either a rdf:List or a rdf:Seq.   
Suppose, though, that you wish only to list one of the authors in your  
RDF, uncertain of (or uninterested in) whether there are other authors  
and not knowing anything about the order of authors.  It would be a  
mistake to do the following:

:paper bibo:authorList (:author) .

Using a rdf:List, this says that there is only one author, but in  
fact, you are not certain that such is true.   Furthermore, :author is  
stated to be the first author, about which you are also uncertain.  A  
rdf:Seq would allow you to correctly state only that which is known.

:paper bibo:authorList
	[ a rdf:Seq ;
	  rdfs:member :author ] .

In short, rdf:Seq allows for more ambiguity than rdf:List in that you  
need not know the order of the container or anything about its size,  
but I suppose the question remains as to whether such an allowance is  
useful to users.

> rdf:Alt, does anybody use this? (I'm struggling to see why it's  
> defined in rdf to be honest)
>
According to statistics from [3], the BTC2010 dataset (~4 billion  
quads crawled from RDF documents on the web) contains the following  
numbers of (?s rdf:type ?o ?c) quads:

723,776 where ?o=rdf:Seq
42,778 where ?o=rdf:Bag
12,534 where ?o=rdf:List
2,934 where ?o=rdf:Bag

While these stats indicate usage, they do not give any indication of  
usefulness (for example, if all the rdf:Seq instances could be  
replaced by rdf:List instances, then who cares that there are so many  
more rdf:Seq instances than rdf:List).

> Do we actually need unordered and ordered lists in rdf? (something  
> niggles that we only need say List and consideration of whether to  
> treat it like an ordered or unordered list happens when processing,  
> based on context)
>
> Are any of Bag, Seq, Collection, Alt likely to be deprecated in the  
> future? are they used anywhere important (I think I saw mention of  
> OWL using them?)
>
OWL does use rdf:List.  For example, in the object of owl:unionOf  
triples (like in bibo:authorList above).  There are proponents of  
weakly deprecating RDF containers [4].

> Any pointers to discussion or any important notes that I may be  
> missing most welcome,
>
> Best,
>
> Nathan
>
>

[1] http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#collections
[2] bibo namespace: http://purl.org/ontology/bibo
[3] http://gromgull.net/2010/09/btc2010data/
[4] http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items&oldid=1990#Data_Model_Issues

Jesse Weaver
Ph.D. Student, Patroon Fellow
Tetherless World Constellation
Rensselaer Polytechnic Institute
http://www.cs.rpi.edu/~weavej3/index.xhtml
Received on Tuesday, 12 October 2010 18:01:16 UTC

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