(Sorry, that title came from my military vocabulary…)
I’m excruciatingly tired from two days of database training (complete with obscenely early arisals and late-night email catchup, because the job doesn’t disappear just because I do). Still, I was… excited! thrilled! transfixed! …to read that the Big O had made yet another VCR (very cool refinement) to my beloved Open Worldcat. Lorcan Dempsey writes, “if you have an ISBN, ISSN or WorldCat Number for an item you will be able to construct a URL that will resolve to the OpenWorldCat Find in a library page for that item, if such a page exists. Furthermore, you will also be able to construct a URL which will limit Find in a Library results on that page to a specified region.”
It’s not just a feature–and one you can twiddle with ad infinitum, ad right into heaven; this VCR heralds that Open Worldcat is further developing its own language and syntax. Go ahead, I know you want it: read more about this fruit-juicy meta-goodness. I would play around with OWC URLs all night, using the geographic limiters and asking the logical questions that arise–e.g., what about similar items with different ISBNs?–were I not copying tax documents for Steven the Accountant. (Hey, we’ve got almost two weeks to file!)
[With the continuing heatwave in the midwest, I was already thinking about The Seven Year Itch…]
This is seriously cool, but at the same time it’s unfortunate that OCLC is implementing a proprietary way to put citation information into a URL. An OpenURL 1.0 resolver would be over-the-top cool and could include the geographical information in the resolver data area.
XML output would be a plus also (“Why yes, I do want everything, thanks”).
Lorcan et al., comments re Tom’s question? Btw, XML output has got to be the easy part.
I also agree with Thomas Dowling in this. Why reinvent the wheel when the technology and standards already exist for OpenURL? I like OpenWorldCat but dislike proprietary solutions.
Obviously, as a marketing guy at OCLC, I’m going to say nice things about Open WorldCat and Find in a Library. But as a library user, web freak and search engine watcher, I’d be interested anyway.
One little trick I enjoy very much is the ability to do a forced, WorldCat libraries Google search built into a URL link. So, if I’m writing a web page about summertime fun, and want to make a link to “Find info in your library about sunburn,” I can just link it to the following
http://www.google.com/search?client=safari&rls=en-us&q=SUNBURN+site:worldcatlibraries.org&ie=UTF-8&oe=UTF-8
Substitute any other string for the word “SUNBURN” in the above URL, and you have a one-click way to use Google to search Open WorldCat for your requested string.
Fun stuff.
Can you explain each item in that string for us?
I have followed up the original post with another on OpenURL.
http://orweblog.oclc.org/archives/000740.html
The Google search string, broken down:
client=safari —- the browser used. Browsers that have search toolbars—Opera, Mozilla, and Safari, among surely others—add this. I’m sure Google uses it for statistics, but it’s pretty much irrelevant to the search; it should probably be dropped from links, like the session code some websites use.
rls=en-us —- I believe this is “result language”? If you ask the system to show results in a certain language, this is where it’s coded into the URL. If your users won’t be looking for things necessarily in just one language (US English, in this case), then drop it.
q=SUNBURN+site:worldcatlibraries.org —- The query string. Space characters are replaced with plus signs. “site:” says “include results only from this domain”. So, “search only in the domain ‘worldcatlibraries.org’ for the word ‘sunburn'”. (Google is not case sensitive.)
ie=UTF-8&oe=UTF-8 —- Input and output encodings. Tells Google how to interpret the code it’s receiving, and what to send back. In this case, Unicode each way. Again, it’s probably better to drop this from links; you probably shouldn’t assume your users are using the same browser, language, and codepages to see the world as you are.
Is this what you were looking for?