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

  Christoph,

Thanks for your review.  My comments embedded below:

On 10/11/2010 6:53 PM, Christoph LANGE wrote:
> 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.)

Softened.

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

Added.

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

It will remain the case.  Exhaustive testing is not really a requirement.

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

Sure it can.  Or rather, we provide the infrastructure so that Host 
Languages that include RDFa can support validation if their authors 
choose to make that service available.

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

Removed - the grammar doesn't really matter.  It doesn't even need to be 
XML per se.

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

Added.

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

The group made a conscious decision to have examples up front even 
though the basis has not yet been established.  I added some forward 
references where appropriate.

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

Added a link.

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

This is a good idea!  I am not going to try to come up with that for 
last call.  However, see the new note in Sequence step 11.  Does this 
start to get where you want to be?

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

Reordered.

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

There is one in XHTML+RDFa and HTML+RDFa.  I don't think we considered 
defining our own - it seems like sort of a solved problem really.

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

Actually, this language is a mistake.  My mistake.  The intent of that 
language, which I have used in lots of specifications, is that when the 
attributes are used you don't need to use them with a prefix.  I have 
fixed the text.

> (!) 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 rdfa attributes are currently defined in the XHTML namespace - and I 
think it is adequate that they stay there.  Since this clause is a 
SHOULD, a host language MAY also use the attributes in their XHTML 
namespace.  However, I would note that no processor today knows how to 
deal with that.

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

You are correct.  RDFa Processors that support a specific Host Language 
will need to be aware of the host language's default profile.  Whether 
such a processor retrieves and caches the profile or hard codes the 
profile definition is up to the implementor (I hard code it, for example).

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

I added 'traditionally 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.
>

Added


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

The spec indicates that a host language can define a different default 
prefix mapping.  It also indicates that this can be overridden with @vocab.

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

Well - a host language could say there was no default prefix mapping.  
Remember that CURIEs are used outside of RDFa.

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

I came up with something.

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

The next sentence says that additional triples MUST NOT appear in the 
default graph.  I feel this is adequate.

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

I changed all the examples to cite the German Empire.  And that was a 
massive pain in the butt.


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

SafeCURIEs are included for backward compatibility.    I think it is 
important that we have at least one example that uses it.


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

I will look for 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.

Added.

> 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

It generates no type.  The rules for URI processing say that if there is 
no URI, it is ignored.  So... typeof='' creates a new bnode (according 
to step 7) and then no types are set for the subject (according to step 
8, since there is no value).


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

See above.

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

Agreed.  I removed it

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

Sure.

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

This should really have been about attributes.  Fixed.

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

Fixed... I hope.

> 9. RDFa Profiles
>> RDFa Processor developers are permitted and encouraged
> Isn't there a suitable RFC 2119 keyword for that?

Sort of.  I changed the language so that we can use the keyword 
RECOMMENDED.  Thanks!

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Monday, 18 October 2010 21:03:20 UTC