Re: Link: relation registry and 303

Booth, David (HP Software - Boston) wrote:
> Mark & Stuart & Phil,

Hi David, everyone, sorry for being slow to jump into this one.

> 
> Would something like the following represent a reasonable compromise for the Link headers RFC?
> 
> For standard relations:
>  - Normatively define short names for the standard terms;

That's the easy one to agree to, yes.

>  - Informatively suggest that those who wish to model these relations in RDF use the corresponding URIs defined in POWDER to do so.

POWDER doesn't define a URI (HTTP Link header does). We /do/ make use of 
HTML profile but that is doomed in the HTML 5 WG hence we say that the 
profile attribute should only be used in *versions of HTML that support 
it* [1].

But, the use of absolute URIs in an RDF graph makes sense to me, yes, 
since RDF is nothing without URIs.

> 
> For extension relations:
>  - Normatively specify that extension relations are directly identified by absolute URIs (RFC3986 sec 4.3);
>  - Informatively suggest that those who wish to define extension relations follow the guidelines in "Cool URIs for the Semantic Web"
> http://www.w3.org/TR/swbp-vocab-pub/#recipe2
> (I'm guessing on this last URI -- I'm offline and cannot check it).

Well remembered! (one may worry about someone who can quote such URIs 
from memory but that's another issue altogether)

The problem with an absolute URI as a link relation is simply the number 
of bytes. Imagine something becoming as ubiquitous as @stylesheet (10 
characters) being written as 
http://www.iana.org/assignments/relation/stylesheet. A lot of server 
engineers would baulk at transmitting the extra 41 characters - hence 
the desire to make it relatively easy to register a new @rel type that 
can be nice and short (and even then large providers will need to be 
convinced it's worth the extra bandwidth).

My experience of registering a new @rel type is that, as of now, it's 
far from easy. I put in the request to register describedby on 19 Nov 
last year. Today I sent (another) polite  e-mail to them that boils down 
to a "what's happening with this please?" e-mail [2]. One way to make 
life easier for everyone might be to move the registration request 
across to Eran H-L's I-D on Discovery [3] which is in the IETF standards 
track and therefore closer to home than the remote lands of W3C, but, 
accepting that I made a bit of a hash of the application to start with, 
having corrected those mistakes I was rather hoping to have this done 
and dusted by now.

During the HTML 5 open session at TPAC last year (Henri will correct me 
if I'm wrong) the consensus was that the ideal solution was a single 
registry; however, that does not mean that multiple registries are 
necessarily unworkable. Having a registry on iana.org and one on w3.org 
and maybe a few others, would be manageable _assuming_ that the 
operators were cognisant and respectful of the others to at least the 
degree that ambiguity was avoided.

The XHTML WG managed to create some new @rel types readily enough by 
putting them in their own namespace [4]. These are defined in a Rec 
Track document and surely it's very unlikely indeed that the same 
strings would be used in a different registry to mean something else.

My preference would be:

1. Standards organisations establish their own system for registering 
link relationships. These are published by those organisations in an 
easily accessible manner (e.g. w3.org/link-relations/, 
http://www.iana.org/assignments/relation etc) as well as the individual 
standards track documents.

2. Someone, probably IANA, publishes a list of recognised registries - a 
registry of registries. This would be readily replicated or indeed 
replaced by another registry of registries in the unlikely event that 
iana.org ceases to function.

3. For operational purposes, the value of a rel attribute is a nice 
short string.

4. For applications that require them, such as RDF, any @rel value can 
be rendered as an absolute URI with its registry's URI as a base.

5. UAs would be free to use any means they choose to go from a token to 
an absolute URI so that, again, no single service is required. One can 
imagine a variety of look up services being operated, none of which 
would be normative, most of which would be useful.

As for point 4 it seems clear to me that a 303 response is the correct 
one for any of those registries to give if an absolute URI is dereferenced.

Phil.

[1] 
http://www.w3.org/2007/powder/Group/powder-dr/20090120-diff.html#assoc 
(or  in case W3C member access is a problem, 
http://philarcher.org/powder/dr/20090120-diff.html#assoc)

[2] http://lists.w3.org/Archives/Public/public-powderwg/2009Feb/0000.html

[3] http://tools.ietf.org/html/draft-hammer-discovery-01

[4] http://www.w3.org/TR/2008/PR-rdfa-syntax-20080904/#rdfa-attributes

> 
> 
> 
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
> 
> Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.
>  
> 
>> -----Original Message-----
>> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
>> On Behalf Of Mark Nottingham
>> Sent: Monday, February 02, 2009 4:14 PM
>> To: Williams, Stuart (HP Labs, Bristol)
>> Cc: Roy T.Fielding; www-tag@w3.org WG; Anne van Kesteren; 
>> Henri Sivonen
>> Subject: Re: Link: relation registry and 303
>>
>>
>>
>> On 03/02/2009, at 5:15 AM, Williams, Stuart (HP Labs, Bristol) wrote:
>>>>> I don't think that's a good idea.  Why not just require that the
>>>>> URI be entirely lowercase
>>>> That seems like an artificial and constraining requirement, but it
>>>> does have the benefit of simplicity. However, it would 
>> still require
>>>> case normalisation to take place for HTML (4 and 5).
>>>>
>>>>> , or that it can (in this context) be
>>>>> compared case-insensitive?
>>>> That was the original approach taken.
>>> 'original' as in the current round of recent drafts, or 
>> original as  
>>> in when the field was described as an sgml-name?
>> Ah, sorry -- 'original' in the scope of my drafts.
>>
>>
>>> Anyway, case-insensitive comparison, at least of the final path  
>>> segment if not the full URI would seem a reasonable pragmatic step.
>>>
>>>> Bifurcation has the benefit of limiting case insensitivity to just
>>>> registered values, instead of all URIs; I imagine that the Semantic
>>>> Web community would take some issue with that (although I'd love to
>>>> hear feedback from them).
>>> Speaking of "Bifurcation" seems a bit melodramtic - and 
>> promulgates  
>>> a notion of spliting which you earlier said was not your intent.
>> Now I'm confused. My intent isn't to be melodramatic at all. My  
>> current, unpublished draft has split the relation types into  
>> registered (token) and extension (URI), based upon discussion 
>> in early  
>> December. My intent is to either confirm this as the correct 
>> path, or  
>> find a new one.
>>
>>
>>>> SemWeb folks, if we were to do the above, and specify that link
>>>> relation URIs pointed to documents describing the relation, would  
>>>> that
>>>> work for you? If not, why? Please state your answer in terms of  
>>>> issues
>>>> that affect actual implementations using those link relations.
>>> I guess I more of a sem web person, but I don't specially 
>> speak for  
>>> the community.
>> Of course.
>>
>>> Personnally, (and probably preversely) I'd still take the 
>> view that  
>>> the rel values are URI names for the relations - I'd not be 
>> inclined  
>>> to give up on that view.
>>>
>>> Pragmatically, I'd probably (personnally) attribute no particular  
>>> significance to a 200 or 303 returned by dereferencing the 
>> relations  
>>> full URI name (might special case it for shortnamed rel values  
>>> anyway) and hope that whatever I got back directly or after  
>>> redirection had something to say about the relation I'm interested  
>>> in that I was prepared to believe. ie. I'd probably only believe  
>>> that the relation was a document if the description I'd obtained  
>>> explicitly said that it was. I'd ty to be robust to folks 
>> not doing  
>>> the 303 step, even though as things stand at the moment - 
>> I'd prefer  
>>> that they did.
>>
>> OK, thanks.
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>>
> 

-- 
Phil Archer
w. http://philarcher.org/

Received on Tuesday, 3 February 2009 15:11:28 UTC