Re: comments/review of RDFa Primer (20060516 version)

Lee,

Thanks very much for this useful feedback! I won't get to any editing  
this month, but this is a perfect start for WD#3 of the Primer.

-Ben

On May 31, 2006, at 11:14 PM, Lee Feigenbaum wrote:

> 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 04:29:40 UTC