W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2003

Re: Enumeration in RDF?

From: Benja Fallenstein <b.fallenstein@gmx.de>
Date: Wed, 17 Sep 2003 01:36:25 +0300
Message-ID: <3F679069.1040404@gmx.de>
To: Garret Wilson <garret@globalmentor.com>
Cc: Dan Brickley <danbri@w3.org>, Art.Barstow@nokia.com, www-rdf-interest@w3.org

Garret Wilson wrote:
> Dan Brickley wrote:
>> * Art.Barstow@nokia.com <Art.Barstow@nokia.com> [2003-09-15 11:49-0400]
>>> Do the latest RDF specs define a way to do enumeration
>>> (e.g. a Bag may contain only 4 strings)?  If so, please
>>> send me the pointer.
>> http://www.w3.org/TR/rdf-schema/#ch_collectionvocab
>> The rdf:List collections mechanism allows the members of a list to be 
>> enumeated in a way that makes it clear the whole list has been
>> represented.
> But as one can always add an infinite number of rdf:first properties to 
> any rdf:List resource (see your citation about), does this really help 
> ensure that nothing more is added to a list---or even, as you put it, 
> "makes it clear the whole list has been represented?"

While the RDF semantics do not define this (because they don't deal in 
cardinalities), it is sensible to interpret rdf:first and rdf:rest to 
have a cardinality of one. (I don't know whether OWL actually specifies 

If you assume this, then given two triples,

     foo:xxx   rdf:first   foo:abc
     foo:xxx   rdf:first   foo:def

you can conclude that foo:abc and foo:def are the same thing, because a 
list can have only one first element.

If you *know* that foo:abc and foo:def aren't the same (e.g. through 
owl:differentIndividualFrom, or what it was), then you have arrived at a 

I.e., with rdf:List, you know that there cannot be additional rdf:first 
or rdf:rest triples "somewhere out there" that change the elements of 
the list. If there are additional rdf:first triples, then either there 
are two different nodes for the same resource, or someone has stated a 

- Benja
Received on Tuesday, 16 September 2003 18:38:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:47 UTC