Re: Comments on PR-rdfa-syntax-20080904

[sorry, try again as plain text]

*** Summary ***

While I believe the document likely contains all the information
necessary I can't tell for sure. The way it currently is organized
leads me to suggest it needs one or two more revisions before
proceeding any further. IMHO it could use compressing, making more
formal, and significant chunks moving to other docs - some of the
informative bits to the primer, the CURIE def to another spec.
Pragmatically, as it stands I suspect most publishers/consumers &
parser authors will simply get confused.

*** General Points ***

a large proportion of this doc is informative (and a lot of small
sections gives the impression of it being piecemeal, rather than a
coherent spec)

I think it would allow more flexibility in future spec creation if
CURIES were defined in an independent spec

while Relax NG might not be as widely adopted as DTDs, for the
purposes of a specification like this, such a description would be a
lot more helpful than the DTDs

consider merging 3.1 Statements with 3.2 Triples

the distinction rendered data vs. structured data doesn't seem clear

how does a parser distinguish between intentional RDFa and HTML tag soup?

*** Substantive Points ***

* How to Read this Document *
"...authors don't need to understand RDF to use it"

While I appreciate the intent, I believe this statement to be wrong -
accurate communication (of data) requires both the producer and
consumer to understand the language. Suggest rewording to something
along the lines of:
"...authors don't need complete understanding of RDF to use it"

* 3.1. Statements *

"A statement is a basic unit of information that has been constructed
in a specific format to make it easier to process"

ew.

* 3.7. Graphs

appears unfinished...

* 4.1. Document Conformance *

This seems a bit messy both substantively & editorially. For starters,
where is @version in the http://www.w3.org/1999/xhtml namespace?

* 4.3. RDFa Processor Conformance *

"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]. (Whether
these additional triples are made available in one or more additional
[RDF graph]s is implementation-specific, and therefore not defined
here.)"

This seems over-constrained. If I have a doc which contains RDFa plus
GRDDL plus [something not yet defined] RDF-in-HTML data, I would
expect them to at least be able to be interpreted as a single graph.
i.e. the graph scope should be the document, not the RDFa processor's
interpretation. (That's assuming "default graph" is meant to mean what
I think - it's not defined here as far as I can see). I don't see how
Appendix C. Deployment Advice fits in here either.

* 5.2. Evaluation Context *
This section seems loosely defined for normative material. I don't
think it'd take much effort to tie it to the XML DOM, in a similar
fashion to 5.5. Sequence (SAX).

Use of [] on the CURIE attributes seems inconsistent.

// here I got lost

* 9.3. @rel/@rev attribute values *

unnecessary repetion of HTML defs - a single example would do (i.e. rel="cite")


*** Editorial ***

various places:
mark-up => markup

* 2.1. The RDFa Attributes *

the "X in RDF terminology" bits should perhaps be linked to
corresponding places in the RDF Primer

* 3. RDF Terminology *

Sytax => Syntax

There are a few unfulfilled refs like <em>[triples]</em>

In the informative sections, it may be more reader-friendly to use
'property' rather than 'predicate'.


*** Nitpicking ***

* Abstract *

"The modern Web is made up of an enormous number of documents that
have been created using HTML."
=>
"The current Web is primarily made up of an enormous number of
documents that have been created using HTML."

----

"RDFa is a specification for attributes to express structured data in
any markup language."
Is RDFa specified for any language other than XHTML? Where?

----

"rendered data can be copied and pasted along with its relevant structure"
Yuck, something more like this seems more appropriate:
"rendered data can be manipulated and reused along with its relevant structure"

----

* Motivation *
"RDF/XML [RDF-SYNTAX] provides sufficient flexibility to represent all
of the abstract concepts in RDF [RDF-CONCEPTS]."
- with certain limitations, e.g. properties which can't be expressed
as qnames can't be serialized as RDF/XML, e.g. http://example.com/1234

----

'hard-wired' - not sure everyone will understand, anyone got a synonym?

Received on Wednesday, 10 September 2008 15:24:49 UTC