Re: Review Comments for draft-nottingham-http-link-header-05

On Fri, Apr 17, 2009 at 1:28 PM, Julian Reschke wrote:

> However, allowing an XML namespace to be an Information Resource,
> but disallowing that for a RDF property still looks very arbitrary to me.

Well the idea is that XML namespaces are in a sense apart from the
web. You can see this in the fact that an XML namespace URI doesn't
have to resolve to anything. It can return a 404 over HTTP for
example, and yet you can still use it as an XML namespace.

When RDF wanted to use URIs to identify all sorts of things, an
attempt was made to integrate it properly with the web and not keep it
in some sense separate like XML namespaces. This is what the TAG
ruling that I cited is all about.

> Where exactly is the incompatibility?

Well what I was proposing is that the specification for Link header
extension relations could be done by analogy to XML namespaces. That
would mean that extension relations could:

1. Resolve to nothing, 404ing.
2. Resolve to an information resource, 200ing.

And quite possibly, but not certainly:

3. Resolve to an arbitrary resource, 303ing.

That would be a grey area. In my previous email I thought that it
wouldn't be allowed, that XML namespaces had to be either undefined or
information resources, but I now find this not to be supported by
Webarch.

In this scenario, you're getting a situation where people can create
extension relations which aren't web friendly (1.), and which aren't
RDF compatible (1. and 2.). That's if you take the route of using XML
namespaces as an analogy for how extension relations work in Link.

On the other hand, you could spell it out. You could say, extension
relations must return a 200 or a 303. This would stop people from
getting angry like they did at the XML Special Interest Group's
decision, and prevent the creation of a link-uri list like the old
xml-uri list :-)

But this would also mean that extension relations could be
incompatible with RDF. And in that case, to test whether an extension
relation is compatible you'd have to dereference it. This is arguably,
therefore, not a good solution.

Or you could say, extension relations must return a 303. Then it would
be web friendly and RDF compatible, but it would make extension
relations harder to implement. So this too has a problem.

If the IANA want their registered relation type URIs to be compatible
with RDF, they'll have to make them return 303s too.

If you just have the specification be silent about the issue of what
extension relations identify on the web, then people will ask the
question. It is a slippery area, but you can't avoid it if you're
using URIs in this way.

> Section 2.2 does not mention RDF at all. Could you please be
> more specific?

§ 2.2 defines an information resource, and if you compare that with
the definition of property in the RDF Concept, Schema, and Semantics
recommendations, you'll find them to be incompatible.

Note that § 2.2's definition of “information” is quite strict, as can
be seen from the fact that it doesn't even consider a printed document
to be information that has high fidelity to a message.

Avoiding this altogether may be a good idea, as you suggest. But can
you suggest a way to avoid it that doesn't ditch the use of URIs as
extension relations altogether? Otherwise, these difficulties will
have to be addressed.

I'd prefer reversed domain names, but it's just a suggestion.

Kindest regards,

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Friday, 17 April 2009 13:45:43 UTC