W3C home > Mailing lists > Public > www-archive@w3.org > April 2009

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

From: Sean B. Palmer <sean@miscoranda.com>
Date: Fri, 17 Apr 2009 19:26:51 +0100
Message-ID: <b6bb4d890904171126m30dff603o9443b4e3f6a2ce67@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, www-archive <www-archive@w3.org>
On Fri, Apr 17, 2009 at 6:29 PM, Julian Reschke wrote:

> But DC is not using PURL, so this is just a similar problem.

But DC *is* using PURL. You even said so in your email:

  ‘Retrieving "http://purl.org/dc/elements/1.1/date" yields a 302 redirect.
  So is Dublin Core violating WebArch, and breaking RDF?’

The purl.org domain is the PURL server.

> That being said: if something as widely used as DC (it is, isn't it)
> violates the principle, what *effect* does it have? In practice?

I don't know, it's not my responsibility to defend TAG resolutions and
RDF specifications. I don't even agree with their design decisions.
But just ignoring them is going to create new problems.

And anyway, we're reviewing something which is supposed to become an
RFC. It would be a little strange for us to pick and choose which
standards we follow and which we don't!

> What seems to be problematic [i]s the "Information Resource"

Yes, but as soon as you start to use a URI for something in this way,
you will get this problem. And Link is so obviously close to the RDF
model that people are bound to say, “we can harvest RDF from this.”

What I'm saying is, you cannot avoid this problem by ignoring it.

As soon as I saw this URI extension relations mechanism in the draft,
I realised that it would cause trouble, so I suggested an alternative
which wouldn't.

Another alternative would be to remove the extension relations
entirely. This would be fine by me, and I think that extensibility in
this area tends to be overrated. Consider, for example, the URN nid
mechanism. Or even the TAG's current issue about URIs for media types:

http://www.w3.org/2001/tag/issues.html#uriMediaType-9

uriMediaType-9 is a strange issue because media types are so seldom
registered, and so seldom is there a good reason to create a new one,
that it's worth having a registry for them. You don't need URIs to
solve this.

On the other hand, the situation with @rel is a hot topic because of
the way that the HTML WG have tried to solve the extensibility
situation, by having a link types registry wiki. Some people object to
this, and Sam Ruby commented recently on the matter:

“If transparency and approachability are the solutions, then we need
something radically more transparent and approachable than a wiki
page.  Now that’s a sobering thought.”
— http://intertwingly.net/blog/2009/04/14/

Reversed domain names would solve the social problem without getting
into architectural permathreads about information resources. But
whatever the solution, as long as the issues are dealt with properly
then the specification will have integrity that it ought to have as an
RFC.

Kindest regards,

-- 
Sean B. Palmer, http://inamidst.com/sbp/
Received on Friday, 17 April 2009 18:27:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:21 GMT