W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2012

Re: RDFa Lite and non-RDFa @rel values

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Wed, 25 Apr 2012 12:28:54 -0400
To: Ivan Herman <ivan@w3.org>
CC: RDFa WG <public-rdfa-wg@w3.org>, Alex Milowski <alex@milowski.com>, Dan Brickley <danbri@danbri.org>, Stéphane Corlosquet <scorlosquet@gmail.com>
Message-ID: <7EF70CA8-5A54-432D-B3C1-2404E8059FDF@greggkellogg.net>
On Apr 25, 2012, at 2:31 AM, Ivan Herman wrote:

> Wow. Lots of mails while I was on the road yesterday...
> 
> This is a set of replies to a number of issues in one place; collecting those may help moving forward.
> 
> ---
> 
> Alex, you said:
> 
> [[[
> That means, the real question comes down to what we expect from this
> kind of markup:
> 
>  <a vocab="..." href="http://www.w3.org/" rel="nofollow"
> property="homepage">W3C's Home Page</a>
> 
> Should it be:
> 
>  <> <http://www.w3.org/1999/xhtml/vocab#nofollow> <http://www.w3.org/>
>  <> <...homepage> "W3C's Home Page"
> 
> or
> 
>  <> <http://www.w3.org/1999/xhtml/vocab#nofollow> <http://www.w3.org/>
>  <> <...homepage> <http://www.w3.org/>
> 
> ?
> ]]]
> 
> Well, in my view, none of the two. I believe the response should be:
> 
> <> <...homepage> <http://www.w3.org/> .
> 
> And nothing else.
> 
> The issue here is that, as we looked at this before, the predefined @rel values make very little semantic sense for RDF. That is the very reason that we did _not_ generate any triples automatically for those guys in HTML5. Hence the proposal of Stéphane to, essentially, drop those from the generated RDF is actually in line with this observation, because they are _not_ meant for RDF. (The user always has the possibility to use a CURIE or a full URI if he/she _wants_ a triple to appear there.)

Agreed.

> ---
> Gregg, you essentially proposed to remove @rel from the effect of @vocab in HTML5+RDFa. This is, in my view, really throwing the baby out with the bath water at this point. We know that there are genuine use case for the usage of @rel (beyond  RDFa Lite) and I cannot simply explain to any user why @vocab would become unusable for that. It would make @vocab much less usable.

Yes, this was sort of a "Thermo-Nuclear" option, that does go too far, but is in keeping with RDFa 1.1 Lite principles.

> ---
> Yes, the @rel values in HTML5 are a moving target. So what Stéphane's proposal means is to remove the _main_ pain points around this issue. I have no real data in hand here, but I am ready to bet that the @rel values listed in 
> 
> http://www.w3.org/TR/html5-author/links.html#linkTypes
> 
> will cover 90% of the non RDFa-related usage of @rel. Yes, there is a reference in the document to the microformat cases but those will stay much more esoteric in my view. Just because there might be some additional @rel values that may come up in a very low percentage of the cases we should not shy away solving the really widespread issue. Doing that due to incompleteness may be another case for the baby and the bath water.

Agreed; I think that covering these will result in the best experience. Note that it is just for the corner case where a single element has both @property and @rel/@rev, so I think it should result in what most people expect.

> ---
> Then there is DanBri's comment that I would like to take very seriously. We need finalization and stability NOW; we are getting to "The perfect is the enemy of the good" effect here. Any delay may seriously backfire as for the acceptance of RDFa. I know this is not a technical argument, but that is where we are...
> 
> Bottom line: I am still in favour of Stéphane's option 1. The only other alternative I can live with is to stay with the status quo and move on.

I think Stéphane's option 1 is the way to go. Not doing this will result in much more bad behavior than leaving the status quo, IMO.

Gregg

> Ivan
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> 
Received on Wednesday, 25 April 2012 16:29:57 GMT

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