CanLII and URL Formation
Using CanLII a fair bit lately, I’ve noticed something that may or may not have been there in the old version having to do with obtaining a decent URL for a case.
The problem in a nutshell is that by the time to get to the case you’re looking for, the resultant URL is made up of all of the decisions taken (or taken for you) until that point, and there doesn’t appear to be a straightforward way from the resulting case page to reduce it to the minimum necessary.
Let me assume something close to the best case scenario: that you know the name of the case you’re searching for — by no means the usual search situation, I’d imagine. Even so, in my test I’ve put Hamilton v. Open Window Bakery into text entry box 2 on CanLII’s main page, the one labelled “statute name / case name / citation / docket number”. I get three results: the two OCA decisions and the SCC judgment. It’s the last I want, so I click on the link to be taken to the case itself. The URL that results is as follows (wrapped by me to fit the window):
http://www.canlii.org/eliisa/highlight.do?language=en&search
Title=Search+all+CanLII+databases&path=/en/ca/scc/doc/2004/2004scc9/
2004scc9.html
This is an unnecessarily ugly lump of code to wield in any fashion, but typical of any search engine’s response to a search.
Now, you don’t have to be a genius or even a legal researcher, if that’s not the same thing, to see that if you take out the search stuff
/eliisa/highlight.do?language=en&searchTitle=Search+all+
CanLII+databases&path=
you’re left with the essence:
http://www.canlii.org/en/ca/scc/doc/2004/2004scc9/2004scc9.html
But it’s a pain to bring a text editor into what should be no more than a one click matter.
As it turns out, the answer for some cases, at least, takes two clicks. Where judgments have been translated into the other official language there’s a link to that version in the upper right hand corner of the case page which takes you to the short URL dans l’autre langage; click once again on that page’s link to first language, and you’ve returned with a URL purged of all of the search process matter.
Trouble is, this doesn’t work where there’s no translation. In such a case you have to go through the process of invoking the document in a PDF format by using the provided link and then in the address bar changing the .pdf extension to a .html extension. And by that time you might as well have called up Notepad and done the bowdlerization yourself.
This is probably for most folks a very minor matter indeed, given that print is still king, even where the web is used to obtain the judgment. And I would not like my concerns here to take any of the shine off the great job that CanLII has done. But because I work almost exclusively in the realm of pixels, I would find it helpful if there were a single button on each page that rendered the base URL for the document in question. I think that having to work with a string that long that is not natural language will lead to mistakes. And…it’s just plain ugly.
That problem wasn’t there in the old version. It was very easy to get the URL stripped of everything but the address info.
You’ve identified the shortest way I know of – the pdf and retyping route where the pdf exists.
Where it doesn’t, if you don’t want to use the text editor route, use the reflex record to find a case citing yours, go to that case, use its reflex to find the original, and go back. That’ll take you to the clean URL.
A direct way to avoid that long URL is to knows the year, month and jurisdiction of the case. Then you go to the appropriate page and click on the case.
I’ve been looking for a shorter undocumented approach but haven’t found it.
Kudos (well deserved) to the CanLII folk for what they’ve done, but we wouldn’t have this problem if the CanLII folk weren’t so intent on a unique interface for Canada.
For example, here’s what you see at AustLII
You are here: AustLII >> Databases >> High Court of Australia >> 1998 >> [1998] HCA 55
[Database Search] [Name Search] [Recent Documents] [Noteup] [Download] [Context] [Help]
and at BaiLII
You are here: BAILII >> Databases >> United Kingdom House of Lords Decisions >> Barker v. Corus (UK) Plc [2006] UKHL 20 (3 May 2006)
URL: http://www.bailii.org/uk/cases/UKHL/2006/20.html
Cite as: [2006] 2 WLR 1027, [2006] UKHL 20, [2006] 2 AC 572
David
Actually, the reflex route gives you the clean URL regardless, so if you know a case which refers to the one you want, and it’s on CanLII
You don’t have to actually go to the pdf location, you can right click on the link and copy the shortcut.
What CanLII could do is make a live link to the clean URL in the line that has the CanLII cite, for example,
Home > Ontario > Court of Appeal for Ontario > 2004 CanLII 21044 (ON C.A.)
David
Simon, the solution isn’t that difficult, but would likely require a bit of coding changes.
The 2 standard types of CGI form input on web pages, GET and POST, are used in different ways. GET embeds the variables within the URL, and tends to be the standard method for search engines – making it easier to copy & send url’s that replicate the search. For the search results page, this makes total sense, and was the right way to go.
For the links to the cases within the search results, I would then switch gears, and use the POST method instead. The POST method makes it possible to still embed information about the search history (ie. the variables) within subsequent pages, but the URLs would remain in a simpler format.
A light bulb came on –
Switch to the other language format and then put your cursor over the link to the original language version on the top right and right click, then highlight and click on copy shortcut, then paste into one’s editor.
Another solution is even simpler. Have a link on the page that will produce a version of the case without search terms highlighted. That linked version would be the ‘clean’ URL.
The label identifying that link can be on the same line as the pdf version link
Very interesting post. It certainly is not a minor matter, as far as accessibility and usability of the legal information is concerned.
It might be noted that conceptually – if not always practically – identification and location of web resources are considered two different things. Accordingly, there are two related concepts – URL is an expression that is meant to help locate the resource; URI is an expression that is meant to help identify the resource (not necessarily to locate it).
A specification document by W3C – RFC 3986 ‘Uniform Resource Identifier (URI): Generic Syntax’, from January 2005, explains the difference: “Section 1.1.3. URI, URL, and URN …
A URI can be further classified as a locator, a name, or both. The term “Uniform Resource Locator” (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network “location”).” (http://www.rfc-editor.org/rfc/rfc3986.txt)
As legal cases are now put on the Web, each case should have an unique, stable URI. It may be possible to access a case through different access mechanisms (systems); then different URLs would be used.
This raises two questions: (1) have the developers chosen a stable system of assigning URIs to legal cases? Certain users may want to refer to parts of legal cases. Then the URI naming maybe should be extented to the internal structure of the case as well; (2) do the developers envisage access through their search facility only or through case URIs directly? They should provide case URIs explicitly perhaps.
How many of the problems being discussed here would be avoided if we could get access to the alphabetical listings of the judgments?
John: You’d get a clean URL, for the same reason you get a clean URL if you go to the case in the year/month list. I suppose I shouldn’t mention that you won’t go there unless you already know the case is there. (By analogy to the old saw about always finding something in the last place you look for it, should you find it at all.)
Those crazy addresses… you are right, normal simple human readable addresses must be there.
We are in the process of tiding up the new CanLII. The clean address we use to provide in the metadata of every decision will be back. They will be there for every file and all the time.
And you know what? CanLII’s addresses last. To alleviate the potential problems associated with changes in the file designation, we have maintained the access to all documents published before the new CanLII through their former address.
In meantime, sorry for the inconvenience,
Daniel.