Re: Link: relation registry and 303

On Jan 29, 2009, at 11:39 AM, Tim Berners-Lee wrote:

> This architectural decision has been made and the cost in time
> of reopening it would be huge.

Sunk cost argument.  The cost of continuing to implement and maintain  
this architectural decision, if I understand it correctly, are hugely  
huger.

> Further, there is a very large
> number of large resources in the Linked Open Data community which use
> the architecture and Linked Data clients which would have problems  
> with an IANA site
> which equates a document and a property.

That's not necessarily the only alternative.  I just asked Jonathan if  
we'd all be happy if the IANA site returns a 404 for the URIs in  
question.

> The semantic web architecture has been developed on top of the  
> Internet
> architecture. (You cannot be expected to derive it from the HTTP  
> spec.)
> I can imagine IANA being hesitant to adopt linked data. It took a long
> time for IANA to move toward publishing linked hypertext documents,  
> as plain text
> was the rule for many years.

Let's be clear, I haven't talked to IANA yet and I don't think  
Jonathan has either.  It's my reservations we're talking about, and  
it's too soon to tar IANA.  I was brought in to provide help  
discussing with IANA, which I will do as part of my job, but I wanted  
to make it clear that I wasn't a supporter of the idea.  I support the  
semantic Web, but I resist putting new costs onto the rest of the Web,  
partly due to pessimism over whether those costs/architectures will be  
accepted or rejected.

>
> I would note that it would in fact be great for everything at IANA  
> to have URIs which work in the linked data world.  All kinds of  
> technology would benefit from having URIs for IANA concepts.
> It would also be a good example for governments etc all over the  
> world.

I still haven't followed the logic for how 303s make the world a  
better place.  Conversely, I haven't followed the logic for why 200s  
in GET responses for URIs registered as link relations, is bad.   
However, Jonathan did convince me that it was at least unaesthetic  
which is why I'm now asking about 404s.  Another alternative of course  
would be to use a URN scheme instead of http scheme.

>
> However, if not, in the meantime, while the IANA does not wish to be  
> compliant with the
> linked data architecture, one could simply replace the iana.org
> domain name with w3.org and run a compliant registry there.
> So a possibility would be for Mark's draft to replace the namespace  
> for
> describedBy in this way.

You'd have to convince Mark of this one.

>
> If anyone at IANA needs help figuring out how to do this, I would be  
> haoppy to hep,
> as would typically various people in irc://irc.freenode.net/swig .
>
> Tim
>
> On 2009-01 -28, at 13:47, Jonathan Rees wrote:
>
>>
>> (This message reports on TAG ACTION-184: contact Lisa D of IESG, cc
>> www-tag, to explain about 303, with cool URIs and webarch as
>> references, due 2009-01-29.)
>>
>> Mark Nottingham has prepared a draft [1] on the HTTP Link: header, an
>> HTTP 1.1 extension for communicating links between resources.  One
>> application, among others, is 'resource descriptor discovery', the
>> subject of my recent memo [2] and Eran Hammer-Lahav's draft [3].
>> Link: and RDD are different and shouldn't be confused. My particular
>> interest is in RDD, which as proposed relies on Link:, so that makes
>> Link: interesting.
>>
>> Link: headers refer to relations using URI-references.  Because
>> relations (we presume) are not "information resources", the
>> httpRange-14 rule says servers shouldn't respond with a 200 when the
>> URI denotes a relation.  In particular, if the URI-reference is
>> relative (e.g. 'describedby'), the relation URI, in this case
>> http://www.iana.org/assignments/relation/describedby, should not  
>> yield
>> a 200.
>>
>> The question is how to bring about such 200-eschewing (or
>> 303-embracing) at www.iana.org - who should contact IANA about
>> 303, and how the request should
>> be posed.  IANA has a relationship with IETF, but not with the  
>> TAG.  I
>> contacted Lisa Dusseault, Applications Area Director for the IETF,  
>> and
>> Mark Nottingham, Link: RFC editor and HTTPbis chair, for advice.
>>
>> I did not succeed in persuading Mark or Lisa to take on the cause.
>
> Were your discussions on an archived list?
>
>
>> Note: In talking with them, rather than use the term "information
>> resource", which is not an IETF kind of term and might have been
>> confusing, I used "network data object or service" which here I'll
>> abbreviate NDOOS.  NDOOS is the phrase used in RFC 2616 (it's the
>> definition of "resource").  NDOOS and IR are different, but not in  
>> any
>> way that bears on this issue.
>>
>> One argument I advanced was that used for the httpRange-14  
>> resolution:
>> A 2xx response could lead to someone wrongly thinking that the URI
>> identified an NDOOS.
>>
>> Lisa and Mark's responses will all be familiar to anyone who's been
>> following this permathread. (There's a FAQ somewhere, isn't there?)
>> Paraphrasing:
>>
>> 1. Anyone doing HTTP GETs is going to have to deal with 2xx for  
>> things
>> that are not NDOOSes, since this happens in so many cases, e.g. XML
>> namespaces.  To attempt to put this kind of semantics into 2xx is a
>> lost cause.
>>
>> 2. Why can't a single string identify a relation for some purposes  
>> and
>> a document for others?
>>
>> 3. Who says a relation can't be a NDOOS?  What you get back from the
>> 200 is a representation of the relation, right?
>>
>> 4. What practical effect could this possibly have?  What benefit  
>> would
>> there be to anybody besides HTTP/URI architects?
>>
>> 5. It's not the business of HTTP to convey semantics such as
>> information about what a URI denotes.  HTTP is only about access.
>>
>> 6. Isn't 303 used for a lot of things other than avoiding 200s?  How
>> does 303 help if it's so unspecific?
>>
>> 7. Not interested in the debate.
>>
>> all of which I answered as best I could citing RFC 3986 and so on,  
>> but
>> not well enough to win any converts.
>>
>> I attempted a second assault using the principle of standards
>> conformance.  RFC 2616 section 9.3 can't (in my view) be read as
>> permitting information *about* a relation in place of the relation
>> itself (which would be nonsense) or data produced by the relation
>> (also nonsense).  Thus 2xx for a relation is off-label.  Off-label  
>> use
>> of a protocol may be overlooked for some random web site, but we're  
>> talking
>> about the keepers of the standards here, so set a good example and
>> don't do it.
>>
>> Response from Mark:
>>
>> "I think you're reading *way* too much into this text...  2616 is
>> flawed, as all documents are, and it should be read in the context of
>> how it was produced.  If you're doing networked access of HTTP
>> resources, it should be followed carefully... If you're doing other
>> things, it has much less relevance."
>>
>> The obvious next step is to contact IANA saying the request comes  
>> from
>> the W3C TAG, and see what they say.  (They may just turn around and
>> ask Lisa or Mark what this is about, and they will give their
>> opinions, as above.)  My assessment is that the chances of getting
>> 303s are slim - I hear IANA has not always been very responsive to
>> even much more conventional requests from IETF. But at worst they'll
>> say no.
>>
>> An alternative to asking for 303s is to ask for 404s.  As IANA need  
>> do
>> nothing in order to bring this about, this becomes more a question  
>> for
>> Mark and the Link: header RFC.  I know 404 isn't ideal but at least  
>> it
>> is consistent with the httpRange-14 rule.  A parallel set of URIs
>> (different base URI, perhaps) could name the descriptions of the
>> relations; such URIs would also be needed for 303 redirects.  Make
>> these document URIs be well known, perhaps in the Link: RFC, and at
>> least part of the problem is solved.
>>
>> If the request(s) to IANA fails, or even if it succeeds, it might  
>> help
>> if the httpRange-14 rule got a little more clout by being taken up
>> either in a W3C recommendation (webarch volume 2??) or in an RFC.  I
>> am considering dipping into the active HTTPbis effort, and can
>> think of a couple of different ways to clarify the situation there.
>>
>> I'm happy to continue to represent the TAG here, even though my own
>> approach (not relevant here) might be slightly different and as a  
>> result I
>> might not be 100% evangelical.  I'll seek direction on a future
>> telecon.
>>
>> -Jonathan
>>
>> [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-03
>> [2] http://www.w3.org/2001/tag/doc/more-uniform-access.html
>> [3] http://tools.ietf.org/html/draft-hammer-discovery-00
>>
>