status of LeeF's comments

Many moons ago, LeeF sent some very useful comments on the RDFa Primer:

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Jun/0001

I was tasked with going through them and determining the status of how
we've addressed these comments. For clarity, I've not deleted any lines
from Lee's email, so that full context is available.

Summary of OPEN ISSUES:
- encoding of RDF sequences using UL, OL.
- assumed namespaces are not linked to their URIs.
- what happens to the nodeValue of an HTML node with content=? (rdf:label?)
- the Dreamhost referral account at http://www.shutr.net needs to be
checked (who does it benefit? Likely copied-and-pasted from somewhere else.)

Summary of QUESTIONS FOR LeeF (and others):
- is Section 2.5 clear enough now regarding the copy-and-paste'ability
being improved by declaring namespaces more locally?
- is it now clearer how the subject is determined to be <> or a bnode?
- is Section 4's intro now clearer regarding changing the subject?
- is the Primer's treatment of bnodes sufficient for a Primer?

DETAILS:

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

We've done just that. The Primer now talks about "structured data."

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

Those are gone.

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

Section 1.1 added.

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

Added.

> 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, there has been discussion, but we haven't fully resolved this. This
should be an OPEN ISSUE.

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

The URLs are there, but they're not links.

Let's make this an OPEN ISSUE for the next/final version of the Primer.

> section 2.1:
> 
> s/Blog/blog

Fixed.

> 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 believe this is done appropriately now. (Question for LeeF.)

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

Although we don't use META in this Primer anymore, the issue of what
happens with the nodeValue is still not clarified.

This is an OPEN ISSUE that MarkB is working on regarding rdfs:label.

> 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.2 now talks about class= defining a type. rdf:type is now used
everywhere.

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

This now says "is parsed to generate", which I believe is far more correct.

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

OPEN ISSUE: if this is a personal account, we need to turn that off. If
it benefits W3C, then that's fine.

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

This is the currently in-discussion issue.

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

I believe this is clearer now, though it may still be an issue.
(Question for LeeF.)

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

Done.

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

It now says "most", which I believe is correct. (Question for LeeF.)

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

The details of CURIEs have been cast aside for now, left for the Syntax.
It would be very good to hear from LeeF (and others) if this is thought
to be a good idea, and if the treatment of bnodes is otherwise sufficient.

-Ben

Received on Sunday, 1 April 2007 19:00:54 UTC