comments/review of RDFa Primer (20060516 version)

Hi everyone,

[The following comments are my personal comments on the RDFa Primer. They 
do not represent my employer's views or the views of any groups with which 
I am associated, including the RDF Data Access Working Group.]

I spent some time going through the Primer, and have some feedback on it. 
I'm coming at this as someone who is very familiar with RDF and only 
mildly familiar with RDFa. Overall, I very much like the document's 
teach-by-example style, and think that with another example or two to 
foster more thorough coverage of the possibilities of RDFa that it will be 
in very good shape indeed. A couple of my comments wish for more detail on 
some parts of RDFa which I realize might not be appropriate for the 
Primer. Will there be a formal document containing a mapping from RDFa 
parts of XHTML to RDF at some point (or will that be part of the XHTML 
specification itself)?

thanks,
Lee

Throughout the document:

"When publishers can express the document's metadata,..." and other 
phrases:

RDFa isn't only for marking up metadata about a document. It's at least 
equally important to mark up the structured data which is the actual 
content of the document. I think it might be better not to use the term 
"metadata" for the semantic content in RDFa. Perhaps sticking with 
"structured data" or "semantic data" would be better. (That is, it seems 
that the abstract uses "data" to mean human-readable content and 
"metadata" to mean a machine-readable version of the same content, which 
doesn't match my understanding of the terms.)


There are a couple of location where scare quotes are used where I don't 
think they're really necessary, and, if anything, they detract from the 
message of the Primer. "content" and "structure" come to mind, though I 
didn't write down the sections.


A section near the beginning of the document expressing the target 
audience of the document would be useful. Is familiarity with HTML 
assumed? With XHTML in particular? With XML namespaces? With RDF?


A reference near the beginning to Turtle (or N3) notation would be 
helpful.


Has there been any discussion in the TF of a way to encode RDF lists 
and/or collections by piggybacking (somehow) on ul, ol, or dl? I suppose 
that any such construct would lose a bit of locality, but no more than is 
currently lost by tracing up to the nearest about="..." attribute. 



section 1:

"We note that RDFa makes use of XML namespaces. In this document, we
assume, for simplicity's sake, that the following namespaces are defined: 
dc for Dublin Core, foaf for FOAF, cc for Creative Commons, and xsd for 
XML Schema Definitions."

Some links to the respective vocabularies would be handy.


section 2.1:

s/Blog/blog


section 2.2:

Where possible, it might be a good idea to keep the namespace declarations 
as deep in the DOM as is possible for the examples, to reinforce the 
copy-and-pasteability of RDFa data. In this case, the 'cal' namespace 
could be declared on the <p> element which represents the Vevent. Later: 
A-ha, this is shown in 2.5. That's good, but it might be worth mentioning 
in 2.5 that declaring NS prefixes locally also helps with copy-and-paste.


When showing the version of <meta> with the content attribute, my 
immediate reaction is: in this case, what is the function of the actual 
content of the <meta> element. This isn't answered at this point in the 
document, @@ is it mentioned elsewhere?


section 2.3

"She notes, however, that the vCard schema does not require declaring a 
vCard type — i.e. there is no need to declare an rdfs:type."

I'm guessing that this is a reference to the role="cal:Vevent" from the 
previous example. However, there was no mention yet of anything having to 
do with RDF predicates and in particular any connection between role="..." 
and rdf:type, so this is confusing. Also: s/rdfs:type/rdf:type


section 2.4

"The RDF triples generated by the above markup is detailed in Section ??."

s/is detailed/are detailed


section 2.6

I'm not a big fan of the use of the word "generates" in this context. It's 
not RDFa (a standard) that's doing any sort of generating. There may (or 
may not) be software that understands RDFa that does actually generate 
triples. I'd suggest using a different verb. Perhaps "corresponds to", 
"licenses", or "leads to"; though I'm not a huge fan of any of those 
either, so perhaps "generates" is best, even if a bit 
misleading/inaccurate. Actually, later in the document in section 3 the
following phrasing is used:

"An RDFa-aware browser would thus extract the following RDF triples:"

which I find much more palatable.


section 3.1

Which one of you is trying to grab some DreamHost referral bonuses via 
http://www.shutr.net? :-)


section 3.2

I understand the logical reasons for literal datatypes to default to 
XMLLiteral, yet a large part of me very much wishes there was a way to 
have
it default to xsd:string instead, especially in the absence of any mixed 
content. Has there been discussion of this?


Reading this section, I'm curious as to why the subject of the triples 
generated here is <> whereas in section 2.2 the <p role="cal:Vevent"> 
generated triples with a blank node subject. (Later: It's explained at the 
end of section 4 briefly that a bnode is generated by meta and link 
elements without an id-bearing parent element. Veterans of RDF and 
eagle-eyed readers will still be confused about this at this point in the 
Primer, though.)


section 3.3

It might be nice to include a parenthetical that the "rel" attribute 
expresses a *rel*ationship to help provide the mnemonic for remembering 
the attribute.


section 4

As per my comment in section 3.2, the first example in section 2 doesn't 
use the current document as the subject (and the second used an explicit 
'about' attribute), so what the intro to section 4 is claiming isn't quite 
correct.

section 4.4.*

This is a lot of detail for a topic which won't concern many readers of 
RDFa. And for those whom it does concern, it won't really apply in the 
beginning until and unless browsers begin supporting clickable CURIEs in 
square brackets. All this is not to say that I think this should be 
removed, because I think it belongs. But I think that treatment of bnodes 
as per meta and link elements with non-id-bearing parent elements deserves 
equal attention, so I hope that that topic isn't actually skipped in the 
final Primer. :-)

-- 
Lee Feigenbaum
IBM Software Engineer, Internet Technology Team
feigenbl@us.ibm.com
1-617-693-3765

Received on Thursday, 1 June 2006 03:14:16 UTC