Clarifications needed for the Collection construct (with CR)

Resending my mail, since CR got lost in the previous mail:-(

Dear all,
I see certain things that need to be clarified related to the collection
Sorry for the long mail but I wanted to point it out in detail.
Thanks for your feedback!

In the syntax specification form 8th November 2002 [1] collections where
 introduced into the RDF syntax. To create a collection the following new
terms are included to the RDF namespace: rdf:parseType="Collection",
rdf:nil, rdf:rest, rdf:first and rdf:List. The collection itself, when
with the rdf:parseType="Collection" attribute-value pair, is constructed
blank nodes of the type rdf:List, which is a rdfs:Class. The blank nodes
always have a link to the current element of the list connected by the
property rdf:first, and a link to the rest of the list connected by the
rdf:rest. The end of the list is denoted by rdf:nil which is an instance of
class rdf:List, so, rdf:nil itself is a list.

The default way of generating a collection in RDF is to use the attribute-
value pair rdf:parseType="Collection". But someone could write his own
constructs. As you can read in [2] (chapter 3.2.3) there are currently no
constraints on collections. Multiple or none rdf:rest or rdf:first
definitions are
allowed, which means the following set of triples would also be valid:

genID:1  rdf:type  rdf:List .
genID:1  rdf:first  ex:aaa .
genID:1  rdf:first  ex:bbb .
genID:1  rdf:rest  ex:ccc .
genID:1  rdf:rest  genID:2 .
genID:2  rdf:type  rdf:List .
genID:1  rdf:rest  rdf:nil .

The question that arises, does it make any sense? What would it mean to
have a collection element with different values? Would it not make more
sense to enter a rdf:Bag instead? But there is also another question: Do we
need the collection construct at all? Before there had been three kinds of
containers, rdf:Bag, rdf:Seq and rdf:Alt.
There are some differences between containers and a collection. A
container in RDF is one resource containing all its members. The collection
is different, there are many resources linked with each other. These
resources are linked with their value(s) and the end of the collection is
denoted by the empty list as the object for the rdf:rest property. Now here
comes the main aim of this new construct: It defines a fixed finite list of
items with a given length and terminated by rdf:nil, at least this is what
can read in [4] section 4.2.
Reaching the goal? There is no restriction on the structure of lists in RDF.
As shown there can be more than one rdf:rest, more than one rdf:first and
even the existence of rdf:nil as the terminating object is nowhere forced.
By default the collection is constructed with blank nodes but even this can
be changed.

Example: A collection with non-blank node.
<rdf:RDF xmlns:rdf=""
  <rdf:Description rdf:about="">
    <ex:hasFruit rdf:resource="myCollection">
      <rdf:Description rdf:about=""/>
      <rdf:Description rdf:about=""/>
  <rdf:List rdf:ID="myCollection">
        <rdf:first rdf:about=""/>
        <rdf:rest rdf:parseType="Collection">
           <rdf:Description rdf:about=""/>

This example should generate the following triples:  ex:hasFruit  ns1:myCollection .
ns1:myCollection  rdf:type  rdf:List .
ns1:myCollection  rdf:first .
ns1:myCollection  rdf:rest  genID:1 .
genID:1  rdf:type  rdf:List .
genID:1  rdf:first .
genID:1  rdf:rest  rdf:nil .

The effect is that by entering a non-blank node someone could enter also
to the collection construct elements from outside. This means without
any restrictions this construct is not fixed!
What about other relevant RDF constructs? In [4] the following is stated:
A limitation of the containers is that there is no way to close them, i.e.,
say, "these are all the members of the container". This is because, while
one graph may describe some of the members, there is no way to exclude
the possibility that there is another graph somewhere that describes
additional members.
But we can also use blank nodes to identify the rdf:Bag itself. Blank nodes
#can not be referred from outside and therefore no further member can be
added. It even needs less triples and the graph is more easy to read. The
example of the fruit basket could be written as:

Example: The fruit basket using the bag construct.
<rdf:RDF xmlns:rdf=""
  <rdf:Description rdf:about="">
            <rdf:li rdf:resource=""/>
            <rdf:li rdf:resource=""/>
</rdf:RDF>  ex:hasFruit  genID:1 .
genID:1  rdf:type  rdf:Bag .
genID:1  rdf:_1 .
genID:1  rdf:_2 .

Without restrictions on the collection construct it is just a more complex
way of expressing things we already could express before using containers.
Possible restrictions can be:
1. Each collection in RDF must have exactly one terminating rdf:nil element.
2. Each collection element must have exactly one connection with the
rdf:first property.
3. Each collection element must have exactly one connection with the
rdf:rest property.
4. Collection elements in RDF have to be blank nodes.

It might be too restrictive to have all these restrictions and there also
be further reasons for introducing the collection construct.
The main difference at the moment is that a container is one resource
all values, while the collection contains different linked resources
the values. In [1] we can find in the appendix A.3 that the collection
was also introduced to support recursive processing in languages such as
Prolog. There should not be a special construct for each programming

Additional question:
What would be the fixed length of a collection? (Number of nodes of type
rdf:List that are linked (minus rdf:nil nodes), the number of rdf:first
connections? What about multi sets in collections?)

Best Greetings,
Karsten Tolle

[1]       RDF/XML Syntax Specification (Revises) Nov. 8th 2002, online at:
[2]       RDF Semantics, W3C Working Draft 23 January 2003, online at:
[3]       RDF Vocabulary Description Language 1.0: RDF Schema, W3C Working
Draft 12  November 2002, online at:
[4]     RDF Primer, W3C Working Draft 23 January 2003, online at:

Karsten Tolle

Received on Friday, 21 February 2003 09:04:32 UTC