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

Dear RDFa WG,

  my review of RDFa Core 1.1 follows.  I paid particular attention to the integration of RDFa into non-XHTML host languages, as that's the context in which I'm mainly using RDFa.
  
Some comments are not strictly for the review but occurred to me while doing the review.  I marked them with (!).

Cheers,

Christoph

> Syntax and processing rules for embedding RDF through attributes

This subtitle is very instructive.

Abstract:
> The embedded data already available in the markup language (e.g., XHTML) is reused by the RDFa markup, so that publishers don't need to repeat significant data in the document content.

Not sure how easy it is to maintain this in non-XHTML host languages.  So I would probably weaken this claim.  In XHTML, part of this "feature" is due to the fact that RDFa has been designed to support @src and @href, and that by default it assumes to find literal objects in text nodes.  Particularly the latter is, for sure, often the case in presentation-oriented XML languages, but not generally in other languages; imagine <setting key="speed" value="120"/> in a data-oriented language.  (Note that I am particularly concerned with embedding RDFa into a non-presentational host language, namely the OMDoc semantic markup language for mathematical knowledge.)

> This document is a detailed syntax specification for RDFa, aimed at:
> …

In this list, I miss "those looking to integrate RDFa into a new markup language".

> A sample test harness is available. This set of tests is not intended to be exhaustive.

Will that remain the case?  Or are they intended to be exhaustive eventually, but just not yet?

1. Motivation:
> RDF/XML … validate … Schema

I don't think that _that_ paragraph is really necessary to motivate RDFa.  RDFa can't be validated by those means either.

> In most cases the values of those properties are the information that is already in an author's XHTML document.

This should read "XML" instead of "XHTML".

2.1 The RDFa Attributes
> It also introduces the idea of 'compact URIs' — referred to as CURIEs in this document — which allow a full URI value to be expressed succinctly.

Here, I would also mention terms.

3. RDF Terminology
> For a more thorough explanation of RDF, please refer to the RDF Concepts document [RDF-CONCEPTS] and the RDF Syntax Document [RDF-SYNTAX].

Maybe some clarification is needed w.r.t. the "RDF syntax", because one does, of course, not have to know the RDF/XML syntax when implementing an RDFa processor, but OTOH a lot one has to know about RDF happens to be specified in the RDF/XML spec for historical reasons.

3.6 Turtle
I realize that Turtle is only introduced here, whereas it is already used for the sample listings in section 2.

3.9 Markup Fragments and RDFa
> A good example of the latter is the licensing fragment provided by Creative Commons.

It would be good to provide a reference here.

(!) A comment for future discussion: Would it make sense to specify an algorithm for "normalizing" a fragment?  I mean making it self-contained, so that it can be pasted somewhere else.

3.10 A description of RDFa in RDF terms
> Objects which are URI references are represented using @href, @resource or @src

I would probably separate @href and @src, or at least mention @resource first, as the former are optional, and owed to the XHTML+RDFa 1.0 heritage.

> and an optional language expressed using a Host Language-defined mechanism such as @xml:lang).

(!) Not sure if this has been asked before, but why is there no @lang attribute in RDFa, which would work independently from any host language?  (Compare @prefix vs. xmlns.)

4.2 RDFa Host Language Conformance
> If the Host Language uses XML Namespaces [XML-NAMES], the attributes in this specification should be incorporated in the namespace of the Host Language.

He had a discussion about that last week or so.  What does that mean?  Suppose the namespace of the host language is xmlns:h="http://host.org".  Should the RDFa attributes be used as <h:element h:about="URI"/>, or as <h:element about="URI"/>?  The latter (i.e. putting attributes into the empty namespace) is what, according to Toby, all currently existing host languages do.

(!) However, I would strongly advise providing for the alternative possibility to put RDFa attributes into some non-empty namespace, possibly xmlns:rdfa="http://www.w3.org/ns/rdfa#".  Now that we are specifying RDFa Core, we can't take the peculiarities of all potential and all future host languages into account.  There might well be host languages that already have different uses for one of the RDFa attributes and thus wouldn't be able to satisfy the following requirement:

> If the Host Language has its own definition for any attribute defined in this specification, that definition must be such that the processing required by this specification remains possible when the attribute is used in a way consistent with the requirements herein.

… at least not without changing the spec of the respective host language.  However, integrating RDFa into a host language should be possible with as few changes to the host language as possible.

It's just a suggestion to use the RDFa namespace for attributes.  One might interpret it as a conflict if rdfa:prefix were both an attribute (according to my suggestion) and a property (according to the profile specification).  So we might want to choose another namespace.

> The Host Language may define a default RDFa Profile.

If it does, I assume that a document does not have to explicitly reference this profile via @profile.  Or would that actually be a good practice?

5. Attributes and Syntax
> href (optional)
> a URI for expressing the partner resource of a relationship (a 'resource object', in RDF terminology);

Maybe say that @href is, in contrast to @resource, intended to be navigable.

6. CURIE Syntax Definition
Maybe it should be said somewhere that the "default prefix" for CURIEs is not determined by the default XML namespace, as authors experienced with XML namespaces might otherwise think so.

> in RDFa the 'default prefix' mapping is http://www.w3.org/1999/xhtml/vocab#
> …
> the mapping to use with the default prefix is the current default prefix mapping;

From these explanations, it's not yet clear what the default prefix is – whether it is always http://www.w3.org/1999/xhtml/vocab# (really? – or just in XHTML+RDFa?), or whether it depends on the host language and/or the state of processing.

> If there is no current default prefix mapping, then this is not a valid CURIE and must be ignored.

Can that be the case?

> the mapping to use when there is no prefix is not defined, which effectively prohibits the use of CURIEs that do not contain a colon (however, see General Use of Terms in Attributes) ;

I know what you intend to say, but it's still somewhat confusing.  And, unfortunately, I can't come up with a better suggestion right now.

7.1 Overview
> This specification does not say […] whether more triples might be generated during processing than are outlined here.

seems to contradict the following requirement from section 4.1, at least w.r.t. the default graph:

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

7.3 Chaining
> Federal Republic of Germany

This example is flawed.  At the time Einstein was born, "Germany" was not called "Federal Republic of Germany", but "German Empire".  However, the DBpedia article "Germany" describes Germany as it is now, i.e. the Federal Republic of Germany.  I'd suggest to circumvent such temporal issues by taking a person born in a different country, or a (West) German born after 1949 ;-)

7.4 CURIE and URI Processing
I presume that the notion of a "safe CURIE" merely exists for backwards compatibility with RDFa 1.0.  If so, that should be noted somewhere, so that authors don't think they have to learn it.  In that sense, I don't consider remarks such as 

> The author could also use a safe CURIE, as follows:
> <div about="[dbr:Albert_Einstein]">

in section 7.4.2 helpful.  Is there any case where you really need safe CURIEs?  The only tricky case I could imagine is when you want to distinguish URI schemes from namespace prefixes, but even in the case of non-safe CURIEs, CURIE evaluation is always tried first, so if there is e.g. a prefix "mailto:" defined, there is no way of using URIs with the "mailto:" scheme anyway, unless one binds it to another prefix.  (Or am I wrong?)

> Note that it is generally considered a bad idea to use relative paths in prefix declarations.

I think there is some official recommendation (maybe XML names?) that states that; maybe you could cite it.

7.4.1 Scoping of Prefix Mappings
> CURIE prefix mappings are defined on the current element and its descendants

Maybe add sth. like: "… unless overridden by a descendant", i.e. a note that the innermost binding takes precedence.

7.4.2 General Use of CURIEs in Attributes
> An empty attribute value (e.g., typeof='') is still a CURIE, and is processed as such.

So what kind of subject, and what rdf:type does typeof='' generate?  Does it generate a new bnode for the subject?  Sequence step 8 says

> If present, the attribute must contain one or more URIs, obtained according to the section on URI and CURIE Processing, each of which is used to generate a triple as follows:

– so does typeof='' generate _:b123 rdf:type <> ?  Maybe the case of typeof='' should be clarified by an example in section 8.1.1.4.

7.4.3 General Use of Terms in Attributes

> One ramification of these rules is that, if an attribute has the datatype TERMorCURIEorAbsURI, and the value matches the production for term but there is no local default vocabulary, then the term is ignored.

IMHO this remark is hardly more concise than the text just before, and it expresses exactly the same.

7.4.4 Use of CURIEs in Specific Attributes

> @href and @src are as defined in the Host Language (e.g., XHTML), and support only a URI.

What exactly is the influence of the host language here?  Could there be a host language that defines @href to be CURIEorURI?

7.5 Sequence

> This specification assumes that certain elements are present in the Host Language (e.g., head). If these elements are not supported in the Host Language, then the corresponding processing rules are not relevant for that language.

There is no general processing rule that depends on the head element.  head is only mentioned in section 8.1 again.  (See comment below)

8.1.1.1 The current document
> This means that any metadata found in the head of the document will concern the document itself:
> …
> In (X)HTML the value of base may change the initial value of current subject:
I wouldn't use any such XHTML+RDFa-specific features here.  It's of course OK to use XHTML for examples, but they should not assume any mechanisms that are specific to XHTML as a host language, i.e. mechanisms that go beyond RDFa Core.  I would rather refer to a corresponding example section in the XHTML+RDFa spec.

Generally, you might want to make explicit once more that all examples of section 8 assume XHTML as a host language, and that elements such as head, div, span, etc. might not exist in other host languages.

9. RDFa Profiles
> RDFa Processor developers are permitted and encouraged

Isn't there a suitable RFC 2119 keyword for that?

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701