Subject: [CODE4LIB] Anyone else watching rev=canonical?

From: Brett Bonfield <[email-masked]>
Date: Tue, 14 Apr 2009 17:19:02 -0400

Summary: URL shortening services, such as TinyURL, are a problem. The
folks who have proposed rev=canonical have written some useful
software around it, but rev=canonical has some potentially
insurmountable issues.

I suggest the following posts if you find this at all interesting:

The post that drew attention to URL shorteners (by the creator of del.icio.us)
http://joshua.schachter.org/2009/04/on-url-shorteners.html

A summary of the work on rev=canonical, with good links and also a new
bookmarklet
http://simonwillison.net/2009/Apr/11/revcanonical/

An interesting post that makes the case for rev=canonical
http://adactio.com/journal/1568

An interesting post that makes the case against rev=canonical
http://www.mnot.net/blog/2009/04/14/rev_canonical_bad

"I (used to) like rev=canonical”
http://decafbad.com/blog/2009/04/13/i-like-revcanonical

An interesting assessment of the issues involved
http://intertwingly.net/blog/2009/04/14/Canonical-Reverse-Or-Wisdom-Defying-Shorturl

I'm not sure what happens now, but I hope the conversation results
quickly in as much software as is needed.

Brett

Brett Bonfield
Director
Collingswood Public Library
[email-masked]
856.858.0649

---

From: Brett Bonfield <[email-masked]>
Date: Tue, 14 Apr 2009 17:35:23 -0400

On Tue, Apr 14, 2009 at 5:30 PM, Jonathan Rochkind <[email-masked]> wrote:
> Wait, is this the same or different than <link rel="canonical">, as in:
>
> http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
>
> <link rel="canonical"> seemed like a good idea to me.  But when I start
> reading some of those URLs, it's not clear to me if they're talking about
> the same thing or not.

Different. Which is one of the problems with rev=canonical.

Brett

---

From: Jonathan Rochkind <[email-masked]>
Date: Tue, 14 Apr 2009 17:30:04 -0400

<link rel="canonical"> seemed like a good idea to me.  But when I start 
reading some of those URLs, it's not clear to me if they're talking 
about the same thing or not.

Jonathan

---

From: "Houghton,Andrew" <[email-masked]>
Date: Tue, 14 Apr 2009 19:10:20 -0400

> From: Code for Libraries [mailto:[email-masked]] On Behalf Of
> Brett Bonfield
> Sent: Tuesday, April 14, 2009 6:48 PM
> To: [email-masked]
> Subject: Re: [CODE4LIB] Anyone else watching rev=canonical?
> 
> On Tue, Apr 14, 2009 at 5:53 PM, Houghton,Andrew <[email-masked]>
> wrote:
> >> From: Code for Libraries [mailto:[email-masked]] On Behalf
> Of
> >> Brett Bonfield
> >>
> > Another issue is that Google, Microsoft, et al. couldn't see that
> their
> > proposal was already taken care of by HTTP with its Content-Location
> > header and that if they wanted people to embed the canonical URI into
> > their HTML that they could have easily done:
> >
> > <meta http-equiv="Content-Location" content="canonical-URI" />
> >
> > rather than creating a new link rel="canonical" and BTW their
> strategy
> > only works in HTML, it doesn't work in RDF, JSON, XML, etc., but
> using
> > HTTP as it was intended, e.g., Content-Location header, it works for
> > all media types.
> 
> Similar issues are arising with the proposed rev=canonical. That is,
> there are different ways to provide the info that rev=canonical is
> providing.
> 
> However, just to be clear, rev=canonical != rel=canonical.
> 
> They are discrete responses to distinct issues.

Agreed.  Another issue with rev=canonical is that I don't believe that
rev= is going to be supported in HTML 5.

Andy.

---

From: Brett Bonfield <[email-masked]>
Date: Tue, 14 Apr 2009 19:17:39 -0400

> rev= is going to be supported in HTML 5.

That's correct. As a couple of the posts I pointed to mention, the
current plan isn't simply to deprecate rev (and then explain why rev
has been deprecated) but to omit it completely.

Brett

---

From: "Houghton,Andrew" <[email-masked]>
Date: Tue, 14 Apr 2009 19:10:20 -0400

Andy.

---

From: Brett Bonfield <[email-masked]>
Date: Tue, 14 Apr 2009 18:48:10 -0400

On Tue, Apr 14, 2009 at 5:53 PM, Houghton,Andrew <[email-masked]> wrote:
> Another issue is that Google, Microsoft, et al. couldn't see that their
> rather than creating a new link rel="canonical" and BTW their strategy
> only works in HTML, it doesn't work in RDF, JSON, XML, etc., but using

Brett

---

From: "Houghton,Andrew" <[email-masked]>
Date: Tue, 14 Apr 2009 17:53:24 -0400

> Sent: Tuesday, April 14, 2009 5:35 PM

Andy.

---

From: Casey Bisson <[email-masked]>
Date: Tue, 14 Apr 2009 23:42:11 -0400

Google's Matt Cutts tweeted a few days ago that he didn't understand  
why Twitter and similar services don't simply resolve short URLs to  
their long form and store/display them that way.

Things like that have been on my mind for a while, but I've only just  
put some of those thoughts to words:

http://maisonbisson.com/blog/post/13719/not-sure-that-rev-canonical-is-really-the-solution/

And from the perspective of linked data, making our applications query  
the URLs that users submit to them just makes sense. It might seem  
like science fiction to suggest that Twitter resolve a URL to identify  
its canonical version and RDF that enriches the tweet, but Facebook's  
link sharing actually does that (though it looks for meta tags rather  
than RDF).

--Casey

> ...rather than creating a new link rel="canonical" and BTW their  
> strategy
> only works in HTML, it doesn't work in RDF, JSON, XML, etc...