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
[EMAIL PROTECTED]
1-617-693-3765
