update to RDFa Syntax

Hi all,

I've updated the RDFa Syntax document to be consistent with our latest
decisions (class vs. role), to fix a few bugs, and to address Lee
Feigenbaum's comments from this summer.

http://www.w3.org/2006/07/SWD/RDFa/primer/

Specific answers to Lee's comments:

> 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.)

I've come to think that the word "metadata" is indeed confusing, even if
it is often correct. So I'm trying out this new wording of "structured
data." Let's see what everyone thinks.

> 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.

I took those out.

> 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?

I've added a short audience subsection which probably needs some
fleshing out.

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

Added a note about this.

> 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. 

Yes, this is an ongoing discussion with some thoughts at:
http://www.w3.org/2001/sw/BestPractices/HTML/2006-rdfa-containers

> 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.

Done.

> section 2.1:
> 
> s/Blog/blog

Done.

> 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.

I've added a short note that it's easier to do cut-and-paste with deeper
XMLNS declarations.

> 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?

I've added a quick note to explain that it's not used.

> 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

I've tried clearing this up a bit with the change to class="", but this
might need more work. rdf:type fixed.

> section 2.4
> 
> "The RDF triples generated by the above markup is detailed in Section ??."
> 
> s/is detailed/are detailed

fixed.

> 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.

fixed throughout.

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

I doubt much referral bonus is going on there :) This is a default page
that Ralph has set up, though indeed we should probably take out the
dreamshot link. Ralph, can you take care of that?

> 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?

No, we haven't discussed this in detail for a few months. I'm not sure
that this is a big deal, because programs will probably figure out how
to do the right thing here.

> 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.)

Yes, it's a bit tough to explain everything up front...

> 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.

fixed.

> 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.

Yes, I've tweaked this a bit, though I'm still not 100% happy with the
current structure. We may need to revise this quite a bit.

> 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. :-)

This will likely be re-written as we think about the new way to do
bnodes as objects of triples.

-Ben

Received on Saturday, 21 October 2006 22:19:35 UTC