LC Response to ISSUE-76

Hi Jeni,

This is a response from the RDFa Working Group to your last call 
comments on RDFa Core 1.1, specifically those filed under ISSUE-76.

Many of the changes prompted by your feedback are already available in 
the document we are preparing for our second last call:

   http://www.w3.org/2010/02/rdfa/drafts/2011/ED-rdfa-core-20110306

A diff marked version of which is available here:
 
http://www.w3.org/2010/02/rdfa/drafts/2011/ED-rdfa-core-20110306/rdfa-core-diff.html

Please find comments in-line on specific issues from here:

> ISSUE-76 
> 
> Some specific comments around RDFa Profiles.
> 
> (Ed) Section 2.2 Examples: When profiles are first introduced here, I think it would be helpful to:
> 
>   (a) use typeof="rdfa:PrefixMapping" or typeof="rdfa:TermMapping" rather than the slightly obscure typeof=""

The Working Group all agree this is a wise suggestion, and the changes 
are now visible in the draft mentioned above.

>   (b) provide an example of the RDFa Profile in Turtle, so that it's clearer what RDF triples it contains

Ditto, as above.

>   (c) be explicit about the assumption of content negotiation of some kind that means that requests to http://www.example.org/vocab-rdf-dc will result in the RDFa document at http://www.example.org/vocab-rdf-dc.html

We've changed the relevant text to now reference the URI 
http://www.example.org/vocab-rdf-dc.html, hopefully this removes any 
need to discuss content negotiation in the RDFa Core 1.1 specification.

Additionally, Section 9. RDFa Profiles, explicitly states that RDFa 
Profiles "... MUST be defined in an approved RDFa Host Language 
(currently XML+RDFa and XHTML+RDFa [XHTML-RDFA]).".

We hope this addresses, or alleviates, your concern.

> (Tech) Section 4.2 Host Language Conformance says:
> 
>> The Host Language may define a default RDFa Profile. If it does, the RDFa Profile triples that establish term or URI mappings associated with that profile must not change without changing the profile URI. RDFa Processors may embed, cache, or retrieve the RDFa Profile triples associated with that profile.
>>
>> Note: Host Languages are required to change the URI of their default profile if items are added or removed from the default profile document. The URI change is required to accomodate RDFa Processors that statically embed the terms defined in the profile. Host Languages are expected to change their profiles very rarely.
> 
> Will this restriction cause problems for HTML5 + RDFa given that HTML5 says that the rel attribute may take values defined in http://wiki.whatwg.org/wiki/RelExtensions, which is not going to be static and may change very rapidly? Or will the profile for HTML5 set a default vocabulary and thus possibly interpret NMTOKENs that should be ignored as CURIEs?

This comment, together with Profile Management in general was the topic 
of much discussion within the Working Group. Generally the group has 
taken the approach of not defining a default vocabulary, but rather 
defining in Host Language Profiles which rel values (terms) will 
generate triples. The specific text quoted above has now been changed to 
read:

   The Host Language may require the automatic inclusion of one or more
   default RDFa Profiles. If it does, the RDFa Profile triples that
   establish term or URI mappings must not change without changing the
   associated profile URI. RDFa Processors may embed, cache, or retrieve
   the RDFa Profile triples associated with that profile.

   Note: Maintainers of Host Languages are required to change the URI of
   a default profile if items are removed from the default profile
   document. The URI change is required to accommodate RDFa Processors
   that statically embed the terms defined in the profile. The working
   group expects default RDFa Profiles to change very rarely.

As such, it will be under the remit of the Host Language maintainers to 
update the associated profile as needed, RDFa Core places restrictions 
on this updating, such as requiring a URI change should existing 
definitions change or be removed. We hope that this approach will ensure 
expected results, whilst allowing the pool of terms/rels host language 
define to evolve reasonably.

> Section 9 RDFa Profiles:
> 
> (Ed) 1st paragraph: For all that it's been developed by members of the RDFa WG, I don't think it's appropriate to call out JSON-LD as a particular syntax for RDF. Given that there are so many syntaxes available, I think it's reasonable to restrict the ones you list to those that are currently published by the W3C.

This reference has been removed now.

> (Ed) Step 4 says:
> 
>> For every extracted triple that is the common subject of an rdfa:prefix and an rdfa:uri predicate, create a mapping from the object literal of the rdfa:prefix predicate to the object literal of the rdfa:uri predicate.
> 
> I don't think that triples can be subjects of the rdfa:prefix or rdfa:uri predicates (unless you're getting into reification). I think it should be reworded to something like:
> 
>   "For every resource that is the subject of a triple with a rdfa:prefix predicate and a triple with a rdfa:uri predicate, create a mapping from rdfa:prefix object literal of that resource to the rdfa:uri object literal of that resource."
> 
> (Ed) Step 5 similarly.

Initially we accepted your proposed text as is, however some concerns 
were raised about over use / confusion of the term resource, and steps 4 
and 5 now read:

   For every subject with a pair of predicates that have the values
   rdfa:prefix and rdfa:uri, create a key-value mapping from the
   rdfa:prefix object literal (the key) to the rdfa:uri object literal
   (the value). Add or update this mapping in the local list of URI
   mappings after transforming the 'prefix' component to lower-case.

   For every subject with a pair of predicates that have the values
   rdfa:term and rdfa:uri, create a key-value mapping from the rdfa:term
   object literal (the key) to the rdfa:uri object literal (the value).
   Add or update this mapping in the local term mappings.

We hope that this texts serves to address all related concerns.

> (Tech) 4th paragraph says:
> 
>> If any conflict arises between two RDFa Profiles associated with URIs in the @profile value, the declaration from the RDFa Profile associated with the left-most URI takes precedence.
> 
> In general, profiles that are processed further down the tree (encountered later) override those that are specified further up the tree (encountered earlier). It seems a bit weird that within an individual @profile attribute this precedence is reversed, such that profiles that are encountered *earlier* in the attribute override (or take precedence over) those that are encountered *later*. I would have anticipated that the right-most URI would take precedence.

We've now aligned the precedence throughout the specification, as such 
the text now reads:

   Profiles referenced on the same element are processed from beginning
   to end of the value of @profile. If any conflict arises between two
   RDFa Profiles associated with URIs in the @profile value, the
   declaration from the RDFa Profile associated with the right-most URI
   takes precedence.


> (Tech) Appendix B: The RDFa Vocabulary for Term Assignments declares rdfs:ranges on the rdfa:prefix (xsd:NMTOKEN), rdfa:term (xsd:NMTOKEN), rdfa:uri (xsd:anyURI) and rdfa:vocabulary (xsd:anyURI) properties. However, none of the examples in the rest of the spec use datatypes. Should the rdfs:ranges be removed? I think it should be made clear in Section 9 that the values of these properties must be plain literals, if that's the intention.

Following your feedback, we've now removed all range declarations from 
appendix B.

Many thanks for your valuable feedback on these issues,

Best Regards,

Nathan Rixham, on behalf of the RDFa Working Group.

Received on Thursday, 10 March 2011 18:12:21 UTC