Re: Need volunteer reviewers for RDFa Core 1.1 (pre-Last Call)

This review is based, in part, on comments I gave in previous requests for clarification, and where there is some confusion remaining in my own implementation.

General observations:

RDFa 1.1 introduces some incompatibilities with RDFa 1.0, and these should be specifically called out. Some direction could also be given to implementors who choose to support both RDFa 1.0 and 1.1 semantics (say, through a runtime argument). In general, the points of difference are minor, and can be accommodated reasonably easily by a parser. One that comes to mind is that  SafeCURIEorCURIEorURI can be mapped to different requirements for 1.0 and 1.1, but TERMorCURIEorAbsURI is sligtly different depending on if it's used in @property or @rel/r@rev/@typeof/@datatype. These are the mappings I use in my implementation:

    SafeCURIEorCURIEorURI = {
      :rdfa_1_0 => [:term, :safe_curie, :uri, :bnode],
      :rdfa_1_1 => [:term, :safe_curie, :uri, :bnode, :curie],
    }
    TERMorCURIEorAbsURI = {
      :rdfa_1_0 => [:term, :curie],
      :rdfa_1_1 => [:term, :curie, :absuri],
    }
    TERMorCURIEorAbsURIprop = {
      :rdfa_1_0 => [:curie],
      :rdfa_1_1 => [:term, :curie, :absuri],
    }

Section 2.2 introduces "terms" without referencing or defining it. Term is an important concept, and should probably be introduced before examples that use it:


A simple way of defining a portion of a document to use FOAF terms is to use @vocab<http://www.w3.org/TR/rdfa-core/#dfn-vocab> to define a default vocabulary URI:

<div vocab="http://xmlns.com/foaf/0.1/" about="#me">
   My name is <span property="name">John Doe</span> and my blog is called
   <a rel="homepage" href="http://example.org/blog/">Understanding Semantics</a>.
</div>

Same thing for "prefixes":

RDFa also permits external definition of collections of prefixes. The following RDFa Profile document, residing athttp://www.example.org/vocab-rdf-dc.html defines the standard RDF prefixes as well as the Dublin Core vocabulary prefix in

Section 6. Many readers will be familiar with a QName, but not a CURIE. At first glance, they seem much the same. It would be useful having a note describing why CURIE and not QName, and a brief description of where they diverge, for instance extracted from [CURIE]. Of course, the spec should also reference [CURIE]: http://www.w3.org/TR/2009/CR-curie-20090116/

Section 7.4. I believe the spec is too permissive over what can be a URI. Basically, anything that is NCNAME ':' ... is treated as am AbsURI (which isn't really well defined, either). I believe that there should be some other mechanism, for instance a white-list of schemes, that is used to validate potential URIs. Far too often, as a result of one problem or another, I find <dc:title> emitted, when it should be dc:title as a CURIE. Simply leaving out a necessary prefix mapping can go undetected, where in RDFa 1.0, it would have generated a processor error.

Section 7.4.3. There is still some open issue on if Terms are downcased, case-insensitive or something else (i.e., the "agent"/"Agent" issue).

Section 7.5 step 11. Production causes one or more literals to be generated through multiple predicates, but language says "Once the triple has been created".

Section 8.1.1.5 has a couple of sub-sections, which are too deep to be either included in the table of contents, or properly marked as a section. Consider reducing the section scope somehow, to allow these to be properly rendered.

Within 8.1.1.5 "Inheriting an Anonymous Subject". I think this was brought up on the list, but saying "An RDFa Processor _will_ generate the following triples" in a normative section should probably use MUST or MAY. With regards to BNodes, will or MUST is confusing, given parser flexibility in generating BNodes, and the irreproducibility of any given BNode identifier.

On a purely technical note, I think that it's great that the document uses RDFa to mark itself up.


 *   I note that the format declares a prefix dcterms: http://purl.org/dc/terms/ whereas the body of the document uses dc: ttp://purl.org/dc/terms/. This is, of course, correct, but somewhat inconsistent.
 *   It's great that you actually provide references to resolutions within the document, but the references do not actually tie back to the sections they come from. For example:

<http://www.w3.org/TR/rdfa-core/#C1> bibo:affirmedBy <http://www.w3.org/2010/02/rdfa/meetings/2010-05-20#resolution_1> .

There should also be the following, to relate the resolution to the chapter it contains, perhaps using bibo:annotates or dc:isPartOf

<http://www.w3.org/TR/rdfa-core/#C1> a bibo:Note, bibo:LegalDecision;
  bibo:annotates <http://www.w3.org/TR/rdfa-core/#white_space>;
  bibo:affirmedBy <http://www.w3.org/2010/02/rdfa/meetings/2010-05-20#resolution_1> .

(Even more, normative sections should probably also be a bibo:LegalDecision, in addition to bibo:Chapter).

Still these are real nits that no one but this audience is likely to ever come across.

Gregg

On Oct 10, 2010, at 7:51 AM, Manu Sporny wrote:

We are scheduled to take RDFa Core 1.1 into Last Call at the end of
October (that's in roughly two weeks). To those of you that are not
familiar with the term "Last Call", it's effectively a feature-freeze on
RDFa 1.1. The only changes that are kosher after Last Call are editorial
changes (in general, no new features are allowed).

In order to be fairly sure that we have a document that we're
comfortable with taking to Last Call, we need a few people to review the
RDFa Core 1.1 Last Call document and send in their comments.

You don't have to have any special prior experience with RDFa to review
the document. A mix of people that have never read the document fully
and those that understand RDFa 1.0 thoroughly would be good.

Could a few people step forward at this point and volunteer to review
RDFa Core 1.1 before we go to Last Call? The review would have to be
done before the end of the month, reviewing the currently published
document should be fine (as long as you understand that there will be a
few minor changes that go into the document in the next few weeks):

http://www.w3.org/TR/rdfa-core/

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Saving Journalism - The PaySwarm Developer API
http://digitalbazaar.com/2010/09/12/payswarm-api/