- From: Lee Feigenbaum <feigenbl@us.ibm.com>
- Date: Wed, 31 May 2006 23:14:02 -0400
- To: public-rdf-in-xhtml-tf@w3.org
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