Reviewing Last Call RDFa

Reveiwing http://www.w3.org/TR/2008/WD-rdfa-syntax-20080221
and having had a brief chat with Ralph Swick about the document,

** Deployment path and architecture:

In general, is the deployment path for this spec that (a) it introduce  
new attributes into the HTML namespace, and that conforming RDF-aware  
HTML clients be expected in future to understand RDFa, or is it that  
the GRDDL transform link from (b) the document or from (c) the HTML  
schema?

** Purpose of the profile

Is the purpose of the profile to allow GRDDL engines to find RDFA, or  
to protect against a non-RDFa document being interpreted as an RDFa  
one, and that being taken as carrying more semantics than it actually  
was intended to by its author?  From discussion with Ralph I  
understand the position of this has changed since  I first looked at  
RDFa.  I think it should be made clear how this should work.
I don't think "you can do whichever you want" is a suitable answer, as  
the whole point is to have a set of standards which allow any client  
and server (well, reader and writer)  to communicate.

** DTDs

4.1   "There SHOULD be a DOCTYPE declaration in the document prior to  
the root element."  DTDs are a an obsolete technology. Suggest the  
spec not refer to them in any way.

4.3  "A conforming RDFa Processor MAY make available additional  
triples that have been generated using rules not described here, but  
these triples MUST NOT be made available in the [default graph]."

I feel this is an inherently weak method of specifying the meaning of  
an RDFa document.
The goal of a spec is to define the meaning of documents in a language.
Processing models which talk about what bits of software do and how  
they interact tend to be suboptimal ways of specifying this in that  
they assume a given software architecture

Wording along the lines of "The RDF semantics of the document includes  
the set of triples.
The point is that reader may hold the writer of the document to having  
communicated these triples in the document.
Other specifications may license the derivation of other triples, but  
that is another matter.
How the software passes these various triples from one module to  
another, and whether they are put in a graph is not something the spec  
should specify. The 'deafult graph' is fine as an abstract set of  
triples to discuss in the spec.

Tim BL

Received on Friday, 21 March 2008 20:48:20 UTC