This is an alternative to the list generation as outlined in an alternative specification. The main difference is that this version does not realy on any "triggering" mechanism, which makes the markup a bit simpler, though it also leads to possible restrictions.

The user view

Processing lists is triggered by a separate attribute @member. This means that elements sharing the same parent, sharing the same predicate either as a value of the @rel or @property, and having an @member attribute set form a list in document order. For example, the <code> elements in the following RDFa code:

<li about="http://www.worldcatlibraries.org/isbn/9780262912423" typeof="bibo:Book">
  <span property="dc:creator" member>Grigoris Antoniou</span> and
  <span property="dc:creator" member>Frank van Harmelen</span>
</li>

yield:

<http://www.worldcatlibraries.org/isbn/9780262912423> a bibo:Book;
    dc:creator ( "Grigoris Antoniou" "Frank van Harmelen" ) .

The lists can contain a mixture of literals and URI references:

<li about="http://www.worldcatlibraries.org/isbn/0123735564" typeof="bibo:Book">
  <span property="dc:creator" member>Dean Allemang</span> and
  <span rel="dc:creator" member resource="http://www.cs.rpi.edu/~hendler/foaf.rdf#jhendler">
     <span property="foaf:name">Jim Hendler</span></span>
</li>

leading to:

<http://www.worldcatlibraries.org/isbn/0123735564> a bibo:Book;
  dc:creator ( "Dean Allemang" <http://www.cs.rpi.edu/~hendler/foaf.rdf#jhendler> ) .
<http://www.cs.rpi.edu/~hendler/foaf.rdf#jhendler> foaf:name "Jim Hendler" .

Lists can be mixed:

<li about="http://www.worldcatlibraries.org/isbn/0123735564" typeof="bibo:Book">
  <span property="dc:creator" member>Dean Allemang</span> and
  <span rel="dc:creator" member resource="http://www.cs.rpi.edu/~hendler/foaf.rdf#jhendler">
     <span property="foaf:name">Jim Hendler</span></span>;
  <span property="dc:publisher" member>Morgan Kaufmann</span> and
  <span property="dc:publisher" member>Elsevier</span>, publishers.
</li>

Leading to

<http://www.worldcatlibraries.org/isbn/0123735564> a bibo:Book;
  dc:creator ( "Dean Allemang" <http://www.cs.rpi.edu/~hendler/foaf.rdf#jhendler> ) ;
  dc:publisher ("Morgan Kaufmann", "Elsevier" ) .
<http://www.cs.rpi.edu/~hendler/foaf.rdf#jhendler> foaf:name "Jim Hendler" .

(Note that in all these examples the HTML5 syntax is used, ie, the member attribute is allowed to stand alone in the element. In XHTML, or other XML dialects, the member="" is to be used.)

The specification view

Handling of collections does not change the core processing model. Instead, management of collections and containers are defined via a (conceptual) pre-processing step on the DOM tree of the RDFa source: nodes in the DOM tree are modified (more specifically, attributes values are modified) and some new elements are added to the DOM tree for the creation of new triples. All modifications of the DOM tree are such that, once the DOM tree is modified, the normal RDFa Core processing steps can be executed to generate the necessary collection or container triples.

List transformation of the DOM

In what follows the term "new bnode id is generated" means that a string of the form "_:xxx" is created that is distinct from all other similarly formatted strings, whether appearing in the original RDFa source or as a result of an earlier, similar steps of generating a new bnode id in a list transformation.

The modification of the DOM tree is made starting from the top element. The steps below are executed on all element nodes of the DOM tree as follows.

1. If any of the child element of the node have the @member attribute set, then
   1. If a child element does not have a @property or @rel, then the node is disregarded from further processing
   2. For each child element with the @member attribute set the predicate in a @property or @rel attribute is retrieved (in case both occurs on the element, @property has the higher priority)
   3. All child elements with the @member attribute set are regrouped in separate lists (in document order), keyed by their common predicates
   4. For each lists of children with a common predicate:
      1. A new element is created as a new child of the (top) node with
         1. The @rel attribute is set to "http://www.w3.org/1999/02/22-rdf-syntax-ns#first"
         2. A new bnode id is generated and the variable current_subject is set to this id
         3. The @resource attribute is is set to the value of current_subject
      2. For each child node sharing the common attribute
         1. The @property or @rel attribute's value (whichever had the common predicate as an original value) is set to "http://www.w3.org/1999/02/22-rdf-syntax-ns#first"
         2. The @about is set to the value of current_subject
         3. A new element is created as a new child of the (top) node with
            1. The @about attribute is set to the value of current_subject
            2. The @rel attribute is set to the value of "http://www.w3.org/1999/02/22-rdf-syntax-ns#rest"
            3. If the child element is the last one in its respective array, then the @resource attribute is set to the value of "http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"
            4. Otherwise, a new bnode id is generated, its value assigned to current_subject, and to the value of the @resource attribute of the child element.

Note: it is not specified what element is added to the node in steps 4.1 and 4.2.3; these elements in the DOM tree are ephemeral and the implementation is free to use any element name (the DOM tree may become invalid as far as the host language is concerned, but that does not have any bearing on the general RDFs processing).

Note: this specification describes the conceptual transformation of the DOM tree; implementation are not required to implement collections and containers exactly in these terms. They can, for example, fold these steps directly into the core processing steps.

Transformation Example

The following code shows what serialized form of the transformed DOM tree for the first example. The names of the elements added to the DOM, and their exact position, may differ from one implementation to the other.

<li about="http://www.worldcatlibraries.org/isbn/9780262912423" typeof="bibo:Book">
  <link_element rel="dc:creator" resource="_:xy1" />
  <span about="_:xy1" property="rdf:first" member>Grigoris Antoniou</span> and
  <link_element about="_:xy1" rel="rdf:rest" resource="_:xy2" />
  <span about="_:xy2" property="rdf:first" member>Frank van Harmelen</span>
  <link_element about="_:xy2" rel="rdf:rest" resource="rdf:nil" />
</li>

Possible questions

Why not reusing the HTML constructs like <ul/>?

First of all, these elements are HTML specific, and RDFa is defined for any XML dialects. But even in HTML it might become a restriction. Indeed, the sentence in the example should look on the screen as follows:

A Semantic Web Primer, by Grigoris Antoniou and Frank van Harmelen

instead of a bulleted list. It is of course possible to define CSS rules to generate the same visual effects for <ul> but those CSS rules are not obvious, are rarely used and most of the HTML authors are not familiar with them. On the other hand, adding the necessary attributes to list elements is not a huge load on the author…

Is it implementable?

Yes, Ivan has done it:-)

Open Issues

How should this appear on the RDF API level?

The question is whether the API should reflect, shall we say, the original DOM or the transformed DOM when, e.g., creating Property groups? If the mechanism is defined as a preprocessing step, then it might be o.k. to stick to the transformed DOM (similarly to the fact that, if some syntax is used for lists in, say, Turtle, the triple store still contains the rdf:first, rdf:next, etc, predicates).