W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > May 2008

ISSUE-7 : Response to Comments from Christian Hoertnagl

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 08 May 2008 12:57:43 -0400
Message-ID: <48233107.3020401@digitalbazaar.com>
To: Christian Hoertnagl <hoe@zurich.ibm.com>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>

> I've read the 27 October 2005 draft of RDF/A Syntax and do have the
> following technical comments.

Christian, this is a response to your e-mail sent on Thu, 22 Dec 2005
15:13:28 +0100.


Your message has been in the issue tracker all this time
and we apologize for not responding to it sooner. As you can imagine,
many of your technical comments on the October 27th, 2005 draft have
been addressed in some way or another. Below is a point-by-point
response to each one of your comments.

> Also, are there any patent statements in
> relation  to this technology,

There are currently no known patent assertions by any contributing
member of the workgroup:


The standard W3C patent/licensing statement is included in the "Status
of this Document" section:


> and what reference implementations are available?

The RDF in XHTML Task Force decided that the best way to ensure parser
conformance was not to create a reference implementation, but rather a
test suite. Parser conformance can be tested via a suite of unit tests
developed by the RDF in XHTML Task Force, which can be found here:


A test harness is available at the following location:


There are currently several mostly conformant implementations of RDFa

PyRDFa (written in Python by Ivan Herman)
librdfa (written in C by Manu Sporny)
Ben's Bookmarket (written in Javascript by Ben Adida)
ARC (written in PHP by Benjamin Nowack)
SPREAD (written in Perl by Shane McCarron)
Cognition (written in Perl by Toby Inkster)

> #1
> section 2.3: According to first two paragraphs in section 4.3.3 the
> link element would have to be reified, thus leading to 6 (not 2)
> triplets overall.

The current Last Call draft does not support reification, thus the
paragraphs that you mention have been removed from the document.

> #2
> section 2.4: How should abiguities between CURIEs and URIs been
> resolved within the scope of this specification? The XML sniplet in
> section 2.4 suggests that CURIEs appear in square brackets, but e.g.
> the 5th sniplet in section 3.1 has no such brackets. There are also
> cases (e.g. last sniplet in section 5.2 which contain unbracketed URIs
> with colons which must not be resolved as CURIEs. With this mixed
> conventions it would appear that a resolution mechanism for RDF/A has
> to have knowledge about "common" schema names (such as mailto), which
> seems undesirable. A better alternative may be to require that all
> CURIEs be bracketed.

The Syntax Document is now very clear as to where Safe CURIEs, URIs, and
regular CURIEs can and cannot be used:


> #3
> section 3.1: According to section the 3rd object in the 12th
> XML  sniplet would have to be written as "Portrait of
> Mark"^^rdf:XMLLiteral
> (not "Portrait of Mark") when obtained from either of the last two
> RDF/A examples in this section (but not when obtained from the 11th
> sniplet).  If "string" serves as a shorthand notation for
> "string"^^rdf:XMLLiteral, the document should say so, because it uses
> both
> versions (e.g. the last XML sniplet in section 5.1.1 cites "Mark
> Birbeck"^^rdf:XMLLiteral).

The newest Syntax document would not generate an rdf:XMLLiteral for
either examples that are not specifically marked as an "rdf:XMLLiteral".

The whole issue of XML Literals has been discussed in depth and we have
only come to a conclusion in the past several months as to how
XMLLiterals should be used. Note that the newest version of the Syntax
Document notes that all active namespaces must be preserved when
generating a triple that contains an XML Literal. There are a number of
test cases that have been added to the RDFa test suite to ensure that
namespaces are preserved correctly.

In short, when explicitly requested by @datatype, or when the content of
an element contains markup, we expect the RDFa parser to produce an XML
string with appropriate namespace inclusion.

> #4
> section 4.1, 2nd paragraph: The upper limit of 3 triplets per RDF/A
> element only applies if you do not consider subject reification (which
> would lead to 4 additional triplets per reified statement).

The current Last Call syntax document does not support reification.

> #5
> section 4.2.1: The meta element's closing tag is missing from the XML
> sniplet (add "/>").

This section has been re-worked considerably since you reviewed it. Many
apologies for taking so long to respond.

> #6
> section 4.3: The document defines [RDF/A element] in section 2.2, but
> sometimes refers to [RDF/A statement] instead.

The language in the RDFa Syntax Last Call document does not use either
term anymore.

> #7
> section 4.3.3: What namespaces do the meta and link tags have to
> belong to? Any, none, the XHTML namespace, ... ?

If no @about is specified, the meta and link tags apply to whatever
their parent subject is currently. If an @about is specified, the meta
and link tags apply to the subject specified by @about.

Any reserved @rel/@rev values placed into the meta and link tags belong
to the XHTML namespace. You can view all of the reserved values here:


If a tag doesn't belong to the XHTML namespace, in other words a
non-reserved word is used, a triple is not generated for that tag.

> #8
> section 4.3.3, 3rd paragraph: According to section 4.1, an [RDF/A
> element]
> can generate up to 3 triplets. Which triplet stemming from the context
> statement ought to be reified as the subject under the circumstanced
> detailed in the 3rd paragraph? Maybe the language in the 3rd paragraph
> should also say: "... the RDF triplet represented by the [context
> statement] ..." (not "the [RDF/A statement]"). Or does [RDF/A
> statement]
> implicitly refer to a set of triplets?

The current Last Call syntax document does not support reification.

> #9
> section 4.3.3: Add definition or reference to [unique anonymous ID].

Unique anonymous ID generation is performed in a different way now.
There are several sections on blank node (aka: bnode) generation in the
new Syntax Document. Information on what a bnode is and how they are
generated can be found here:


> #10
> section 4.4.2: What's the prescribed behavior of an RDF/A reader it
> the href attribute were missing from the XML sniplet in this section?

There are now multiple ways of specifying the object for a triple:


If an object is not specified, but a subject and predicate is - there is
support for storing the incomplete triple until an object presents
itself in the document:


This new method is how "chaining" is performed, and it is quite a
powerful addition since the version of the document on which you commented.

> #11
> section Why would the leading and trailing whitespaces (e.g.
> before "E = mc...") disappear during exclusive canonicalization? Add a
> reference and give more detail on which exact node set should undergo
> canonicalization (perhaps specify as XPath expression). What charset
> should be used (e.g. UTF-8)?

Canonicalization is now explicitly defined in the processing rules:


Note the text that states:

The value of the [XML literal] is a string created by serializing to
text, all nodes that are descendants of the [current element], i.e., not
including the element itself, and giving it a datatype of rdf:XMLLiteral.


The actual literal is either the value of @content (if present) or a
string created by concatenating the value of all descendant text nodes,
of the [current element] in turn. The final string includes the datatype
URI, as described in [RDF-CONCEPTS], which will have been obtained
according to the section on CURIE and URI Processing.

> #12
> section reference to RDF/A element's value misleading,
> because it's really a DOM subtree (including two sup elements, etc.)
> or node set.

That section has been extensively reworded and the process for building
XMLLiteral values has changed quite a bit since the version of the
document that you reviewed.

> #13
> section The 4th XML sniplet should list 2 triplets, the other
> stating that Einstein created "<>".

Good catch - you are correct. Unfortunately, we no longer use that example.

> #14
> section 5.2, 2nd paragraph: typo in "exapmle"

Thanks for the correction - there are currently no "exapmle"
misspellings in the current Last Call syntax document.

> #15
> section 5.2: Define or provide reference to explain syntax that uses
> underscore namespace prefixes, as e.g. in "_:a" (anonymous).

The new Last Call syntax document does so in the following sections:


> #16
> section 5.3: Add document that defines reification to bibliography
> (e.g. RDF Semantics).

There is currently no reification support in the Last Call RDFa Syntax

I hope you will find that there have been many improvements since your
review and we'd like to hear back from you if you feel that your
comments were not adequately addressed.

Thank you for all of your feedback, Christian - and again, apologies
that it took us so long to get back to you.

-- manu

Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Dynamic Spectrum Auctions and Digital Marketplaces
Received on Thursday, 8 May 2008 16:58:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:27 UTC