The link to "link groups" above is broken.

Looks very maintainable.

There is another very simple solution to the entire hash-versus-slash debate: whenever you would want to identify anything with a hashless URI, suffix it with #referent. The meaning of x#referent is: I identify whatever x is about. And x is simply an information resource (about x#referent). Of course this does not put the httpRange-14 resolution to the test, like your approach does.

See http://www.marcdegraauw.com/2007/02/20/the-referent-convention/ for details.

What doesn't convince me, is that the accept header is ignored and the redirect to the "uncool"*.html URI.

The URI of the person should redirect to the personal profile document, the personal profile document should derefence to the best representation according to the accept header. Why to force semweb clients to at least partially understand and download html?

Yes, I agree that the server should honor accept headers. Alas, my service provider doesn't support the content negotiation module so I can't. :-(

It would be useful to have a way to specify how to get from the information resource back to the non-information resource.

A reverse-link relationship seems appropriate, because a forward link suggests that it might be something to follow, and that wouldn't be useful in this case.

There isn't a link relation that quite has the semantics of a Location, or Content-Location header, but a rel=alternate link is close-ish, so that could be reversed to give:

<link rev="alternate" href="norman-walsh" />

Or you could use the RFC2068 Link header to do the same.

Any better ideas? I've seen rel=bookmark suggested, but that doesn't seem quite right.