thinking more about OneBoxing WorldCat Local

I just checked with our implementation guy at OCLC about including some code in the header of our WorldCat Local instance that would allow us to add customized widgets into WorldCat Local search result screens. Sounds like it's a no go for now. WorldCat Local has a refreshingly simple branding customization options compared to what we're used to with Innovative's OPAC. But that simplicity will keep us from inserting some magic Javascript to achieve the OneBox effect.

I'm not sure if I was clear enough about what I'm interested in. Another way of looking at this is analagous to Google Ads. Google has established that placing context sensitive ads alongside search engine results is an effective way to drive traffic to advertiser websites.

If WorldCat Local becomes our library's search engine, shouldn't our library be able to put context sensitive "ads" next to results? These "ads" (or OneBoxes) would appear based on the search term and offer things like:

• links to library created research guides that seem relevant to search at hand
  
• links to course reserves if a prof's name is searched
• results from a site search of our library's site
• image results from ARTstor (ala Google images)
  
• results (if any) from the library's digital collections

To offer something like this, OCLC wouldn't need to do anything unprecedented. Lots of web applications (including this one I'm using right now, Blogger) allow you to embed bits of HTML. Javascript widgets inside OPACs have been around for awhile too, a prime example being LibraryThing for Libraries. If OCLC put the search results data into some nicely formated JSON and allowed Javascript to be inserted in various places, it wouldn't be hard for libraries or third parties to build these little things.

The WorldCat API is nice and all, but who (besides Terry Reese) wants to build an entire interface from scratch using it?

Click on the image above for an illustration of the WorldCat Local OneBox concept.

Using the WorldCat API in link resolving for books

The new WorldCat Navigator-based Summit Catalog just went live on Monday.

One of the connectors that we needed to update at Watzek was our link resolver. Upon receiving a citation for a book, the resolver used to do some screen scraping of the INNREACH-based Summit catalog to figure out whether the book was available at our local library and/or within the Summit consortium. This feature is also built into our ILL requesting system so that patrons don't ILL request books in Summit.

Now that Summit is on WorldCat, the logical move was to use the WorldCat API to check if a book is in our local catalog or in Summit and provide links accordingly. The API lets you throw an ISBN at it and optionally returns the OCLC numbers of holding libraries near you. By simply doing an array_intersect in PHP with a list of the Summit libraries' OCLC symbols:

array ("Chemeketa"=>"CHK","Clark"=>"CCV","COCC"=>"CEO","Concordia"=>"CCD","Central Wash"=>"CWU","Eastern OU"=>"EOS","Eastern WU"=>"WEA", "George Fox"=>"GFC", "George Fox Portland"=>"WEV", "LCC"=>"OLE","Lewis & Clark"=>"OLP","Lewis & Clark Law"=>"ONS","Linfield"=>"OLC", "Linfield Portland"=>"OLL", "Marylhurst"=>"MRY","Mt Hood CC"=>"MHD","OHSU"=>"OGE","OHSU"=>"OGI","OHSU"=>"OQH","OIT"=>"OIT","Oregon State"=>"ORE","Oregon State"=>"OR1","Pacific U"=>"OPU", "PCC"=>"OQP","PCC"=>"OQY","PSU"=>"ORZ","Reed"=>"ORC","SMU"=>"WSL","Souther Oregon U"=>"SOS","Seattle Pacific"=>"OXF","Seattle U"=>"WSE", "Seattle U"=>"W9L","TESC"=>"ESR","U of Oregon"=>"ORU","U of Oregon"=>"UOL", "U of Portland"=>"OUP", "U of Puget Sound"=>"UPP","U of Wash"=>"WAU","U of Wash Law"=>"ONA", "Willamette U"=>"OXG", "Warner P"=>"OWP", "Western Ore U"=>"WOS","Whitman"=>"HTM");

it's easy to figure out if the book is held in Summit and/or in our library.

If you don't have an ISBN, the SRW features of the API allow one to do author/title search. If an author/title search results in just one match, it's easy to check if Summit holds the book. If there is more than one match, I just left it for the user to check the catalogs themselves, but there are other approaches that one could take.

Link resolvers seem to be used most often for articles, but research databases like Philosopher's Index have lots of books in them. Here's an example. Lots of people put books in RefWorks, which offers OpenURL linking out. Often, these citations (some examples) have no ISBNs and are often a little funky. Hence, the resolver can have problems with them. Here's an example of a book citation from RefWorks.