Re: Link: relation registry and 303

This architectural decision has been made and the cost in time
of reopening it would be huge.  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.

There are best practice documents such as
http://www.w3.org/TR/swbp-vocab-pub/#recipe2
to help developers set up web sites.

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.

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.

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.

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
>