W3C home > Mailing lists > Public > www-tag@w3.org > September 2008

Re: rel=CURIE in RDFa, but rel=URI in Link:

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 26 Sep 2008 14:35:22 +0200
Message-ID: <48DCD70A.2040907@gmx.de>
To: Shane McCarron <shane@aptest.com>
CC: Dan Connolly <connolly@w3.org>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org WG" <www-tag@w3.org>, XHTML WG <public-xhtml2@w3.org>

Shane McCarron wrote:
> I understand what you are saying.  However, I guess my response is that 
> I believe the XHTML 2 Working Group has scope in this space explicitly 
> by charter.  The group, in conjunction with the Semantic Web Deployment 
> Working Group, has defined RDFa and it has gone through the W3C 
> process.  It will very soon be a Recommendation.  This Recommendation 
> includes an XHTML Module that defines @rel /@rev and a bunch of other 
> things, and shows how they integrate with XHTML family markup 
> languages.  It says that the lexical space for @rel /@rev is " (reserved 
> word | CURIE 
> <http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080619/#dt_curie>)+" and 
> defines the reserved words that are recognized by RDFa processors. If 
> someone else wants to extend that, they are going to need to find a way 
> to do it that is consistent with this Rec.  If there is no way for that 
> to happen, then it is an issue for the Hypertext Coordination Group, the 
> TAG, and / or the Director.

I think it's an issue that needs to be discussed and resolved anyway.

> As to raising this with the HTML WG, there are representatives of the 
> RDFa Task Force who have been doing so for ages in the context of the 
> W3C group and the WHATWG.  I personally have stayed out of that 
> discussion.  HTML5 is years from adoption, and there is plenty of time 

Unfortunately, this is not really the case. While *completion* will take 
a long time, HTML5 features are being implemented as we speak. So 
delaying that discussion would be a bad idea.

> to iron out wrinkles like these.  If HTML5 is to be a player in the sem 
> web community, then it will need to accommodate RDFa.  We have tried 
> hard to ensure that this is easy to do.  I hope that we succeeded.  I 
> know that we have a proof of concept integration with HTML4 that works 
> like a charm.

Which is great. I think that getting RDFa to work well in HTML4 is very 
important; I'm personally looking forward to get HTML4 documents 
including RDFa to successfully validate (even if I need to provide a 
different doctype).

> The main point of this thread was a discussion of whether the Link: 
> header extensions for HTTP would conflict with RDFa.  I and the RDFa 

That's what started the discussion, but I do not think it was the main 
point of this thread.

> Task Force believe that they do not conflict because the value space of 
> CURIE is a superset of the value space for the proposed Link: header 
> extensions AND the CURIE value space (IRI) is directly transformable to 
> the Link: header value space (URI) as per the relevant RFCs.

Not really.

1) You *can* transform a IRI to a URI for use in the Link header, but 
the recipient will have no knowledge about whether it needs to be 
transformed back and how. That will make it hard to use IRIs as 
identifiers. Unfortunately that is a hard problem to solve in an HTTP 
header (while maintaining compatibility with the Link header as already 
implemented).

2) The HTTP Link header draft suggests a IANA registry for "short" 
relation names; the HTML5 spec currently suggests a Wiki (!), and the 
XHTML2 WG seems to assume it can define these reserved words. That is 
another issue (<http://www.w3.org/html/wg/tracker/issues/27>), and I 
firmly believe that relation names should be portable across document 
formats (such as Atom) and protocols, and thus should be defined outside 
the context of a specific vocabulary. Thus I support the current 
proposal in the HTTP Link header draft to use an IANA registry.

BR, Julian
Received on Friday, 26 September 2008 12:36:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:06 GMT