W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2011

ISSUE-76 Triage

From: Nathan <nathan@webr3.org>
Date: Thu, 27 Jan 2011 00:56:35 +0000
Message-ID: <4D40C2C3.1090906@webr3.org>
To: RDFa Working Group <public-rdfa-wg@w3.org>
Here's Jeni Tennison's comments on RDFa Profiles, and my replies in line:

Jeni's indented, my comments indented.

VOID:
==================================

   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 already agreed and resolved to change under ISSUE-62 LC response
"@prefix MUST be processed beginning-to-end.
@profile MUST be processed beginning-to-end."
http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0085.html


Editorial:
===========================

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

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

agree with both (a) and (b)

   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 need to state that a request to the URI should result in an RDFa 
document, and that content negotiation may be in place, but should not 
attach any additional URIs to the representation returned (.html) as 
this is misleading and not required. (opacity axiom )

   Section 9 RDFa Profiles:
   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.

Agree, suggest changing text to:
""Profiles MAY also be defined in other formats such as RDF/XML 
[RDF-SYNTAX-GRAMMAR], Turtle [TURTLE], or some other suitable format.""

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

   Step 5 similarly.

Agree, but feel the wording still needs tweaked slightly, best to 
avoid the term resource.


Tech Issues:
===========================

   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?

We need to address and resolve this, should open a bug.
aside: 'accomodate' should be 'accommodate'


   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.

Given other LC feedback and my own thoughts, I'm tempted to say the 
range should be changed to literal/string, and the text in section 9 
should be expanded to introduce the rdfa:prefix/term/uri properties. 
This could be editorial.
Received on Thursday, 27 January 2011 00:58:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:08 GMT