Warning:
This wiki has been archived and is now read-only.
JLists
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.
Contents
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.
- If any of the child element of the node have the
@member
attribute set, then- If a child element does not have a
@property
or@rel
, then the node is disregarded from further processing - 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) - All child elements with the
@member
attribute set are regrouped in separate lists (in document order), keyed by their common predicates - For each lists of children with a common predicate:
- A new element is created as a new child of the (top) node with
- The
@rel
attribute is set to "http://www.w3.org/1999/02/22-rdf-syntax-ns#first" - A new bnode id is generated and the variable
current_subject
is set to this id - The
@resource
attribute is is set to the value ofcurrent_subject
- The
- For each child node sharing the common attribute
- 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" - The
@about
is set to the value ofcurrent_subject
- A new element is created as a new child of the (top) node with
- The
@about
attribute is set to the value ofcurrent_subject
- The
@rel
attribute is set to the value of "http://www.w3.org/1999/02/22-rdf-syntax-ns#rest" - 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" - 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.
- The
- The
- A new element is created as a new child of the (top) node with
- If a child element does not have a
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).