W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > January 2010

Re: Updated RDFa Syntax 1.1 draft uploaded

From: Ivan Herman <ivan@w3.org>
Date: Fri, 15 Jan 2010 11:37:58 +0100
To: Shane McCarron <shane@aptest.com>, public-rdf-in-xhtml-tf@w3.org
Message-Id: <FAD16BBA-0993-40CB-8BBE-5347C0BEEC9B@w3.org>
Hi Shane,

Some comments on the draft text on issues that we may not have discussed...

- To be honest, I am not sure where we are now with the question whether I _must_ use safe curie syntax or not in an @about. My personal preference is still that safe curie has become unnecessary with the new curie processing. We have to keep it there for backward compatibility but that is it.

However, I am not sure the current text is consistent. The way I read 5.4.3 (second and third example) is that the user 'could' use safe CURIE but it is not required. On the other hand, the first bulleted item of 5.4.4 says that a URI or CURIE should be expressed as safe CURIE.

- I try to envisage the changes we will have to do on the text if the @vocab mechanism is defined. 

I think we can safely assume that some mechanism will be around, which means that the value of @property="bla" will have a clear meaning in terms of a URI if there is a corresponding @vocab doing that for 'bla'. 

How would we combine this with the XHTML keyword mechanism we have now? I presume the way of looking at those (ie, 'next', 'stylesheet', and the like) is that, conceptually, we have a @vocab defined for all RDFa content pointing at file defining those values. That would certainly unify things nicely. 

However... at the moment those values are defined for @rel/@rev only. Such restriction would not make sense for @vocab in general. One can envisage two mechanisms:

	1. the @vocab format would not only define the URI-s but also the RDFa attributes that can be used for that term. Ie, some are usable for @typedef (ie, class definitions), some for @property, some for all of them. A bit convoluted...
	2. remove the restriction on @rel/@rev. Ie, all CURIE-s, regardless of where they come from, may use the terms coming from a valid @vocab, including the xhtml ones. I know this is not semantically kosher, but I am not sure it is so harmful.

The second alternative has the merit of simplifying the choices. The list of 5.4.4 would become something like:

    - @href and @src support only a URI
    - @about, @resource support a URIorCURIEorVOCABTERM (with an optional safe CURIE syntax)
    - all other attributes support a list of URIorCURIEorVOCABTERM-s (each with an optional safe CURIE syntax)

I believe this is simpler both conceptually and implementation-wise (with an underlying mapping mechanism from terms to URI-s for valid vocab terms)

- A related note which will also come up for RDFa+HTML5. At present, a Wiki page is maintained at the whatwg site on 'valid' @rel values[1]. I am not sure that will be the final mechanism; there are discussions, also related to the LINK HTTP header, on looking at alternative registration mechanisms (see [2]). What I presume this means is that the corresponding RDFa mechanism should be flexible enough to cope with whatever comes up (I believe that what we discussed yesterday does go in this direction). That, however, refers back to the previous point on how we define the @rel/@rev keyword values...

Cheers

Ivan


[1] http://wiki.whatwg.org/wiki/RelExtensions
[2] http://tools.ietf.org/html/draft-nottingham-http-link-header-06





On Jan 13, 2010, at 23:39 , Shane McCarron wrote:

> Sorry for the delay - there were some technical difficulties.  However,
> I have uploaded a very drafty RDFa Syntax 1.1.  You can get to it via
> the drafts page at http://www.w3.org/MarkUp/Drafts
> 
> Thanks!
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf







Received on Friday, 15 January 2010 10:37:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:34 UTC