WorldCat Search API Terms of Service issues
Oct 4th, 2008 by Karen
Bruce Washburn from OCLC left a comment on my post about building an iPhone app for WorldCat.
We think an iPhone app for WorldCat is interesting too. We’ve been doing some thinking and experimenting with that idea on the API team, and would really like to hear more about the shape you think a WorldCat iPhone app would take. And you noted a question about how widely you could distribute your app, based on the API Terms. Could you tell us more about how you think your application might present a conflict?
My issues/questions about the Terms of Service stem from the area that discusses Service Levels.
If you are not able to determine the library affiliation of users of your API-based application, the WorldCat API will support indexes and data at the level currently offered to WorldCat.org visitors. For these users, we require that you provide a path to obtain library holdings information as appropriate in your user interface when WorldCat data is presented, with links to participating library OPACs. The WorldCat API provides the OPAC URLs to support these links. The display of library holdings works best when the end user’s location (IP address, ZIP code, or country) can be provided in the link.
The documentation on Service Levels basically says that if you can’t verify a user is one of yours that you may only use certain search indexes and you MUST link back to through WorldCat to local library holdings. Seems reasonable right? Except that the default service level, the one that you need to use if you can’t verify someone is one of your users, doesn’t allow you to limit searching to a particular library. This is not helpful. Particularly since I was thinking about using the WorldCat Registry to allow people to choose a particular library or libraries to default their search to. Let’s be real most users want to see search results from libraries that they can actually get items from. Geographic limits just don’t cut it because it doesn’t take into account the fact that geographic proximity does equal borrowing privileges. Just because I live in the Houston-area doesn’t mean I have borrowing privileges at Rice. Just because I don’t live in upstate NY doesn’t mean that I might have borrowing privileges at Syracuse University. For me this is a huge issue that I want to see OCLC solve not just in the WorldCat API but in WorldCat.org as well.
Some have suggested that OCLC doesn’t want to make these particular indexes available because they are afraid it will undercut the potential revenue of WorldCat Local. But I think that this is a false fear, WorldCat Local offers features and functionality that are not available in WorldCat.org or the WorldCat API. Additionally, for a library to develop their own version of WorldCat Local would be a substantial investment involving either extraction or programming to access real-time, status and holdings information. Most libraries have neither the time nor resources to do this. Also, there is no efficiency gained by individual libraries reinventing WorldCat Local. A better use of my development resources would be to have my staff work on other innovative uses of the WorldCat API.
Another issues I see is with the fact that any applications we build have to use our API key. In the case of the WorldCat Wordpress Widget there is no way to hide the API key from users. Why is this a problem, well what if we want to distribute the widget to our faculty so they can use it in their personal blogs that aren’t on the university blog server. Giving the widget with the key in it to our campus IT people so they could install it on the campus blog server would be reasonable. It seems some application can be build so that the key is hidden. This seems to be what OCLC done with the Facebook app they are distributing. I would guess/hope I would be able to do the same thing with an app for the iPhone/iTouch.
Both of these issues are hampering some of our development efforts at UH. This doesn’t mean that the WorldCat Search API is a bust, it just means that we are still trying to define the boundaries of how useful it can be and in what contexts.
Karen, the API can definitely be hidden in some way - my issue right now is the way that OCLC doles out an individual API key per developer. Each distinct application should have its own API key in my mind.
Ah, but wouldn’t this mean that ILS patron databases, which store access information, would have to be exposed to OCLC?
And have you looked at the OCLC iPhone app? It’s visible on this page when you’re using Mobile Safari.
As others have noted, the search relevance might need a tweak or two.
Not necessarily. We could build apps that allow users to choose their library affiliation(s). I’ve been thinking about doing exactly this and am finishing up a post on it. It would be very much like what Google Scholar does when you set your preferences. At the very least WorldCat.org should consider doing this. It isn’t like they don’t have the information. (WorldCat Registry) I’d love to be able to search UH and HCPL holdings simultaneously. If I could do this via WorldCat I’d use their interface instead of the individual library catalog.
You have or are going to forward these concerns to OCLC, right?
Karen, that makes sense. The tradeoffs are interesting, though.
When you search in the WorldCat web version, you can change location via zipcode easily enough, but that’s often too broad and doesn’t take into account library variations, agreed.
The mobile version presumes that you’re just interested in one library, when often the local search is unsatisfying and a search of preferred libraries would be more useful.
Google Scholar sets a cookie without requiring the login, which seems like a good method for implementation.
On a related note, it would be really useful if LibX could engineer a method for searching multiple libraries in its toolbar, too.
And to Jonathan, I think OCLC and the Cluetrain Manifesto should friend one another. Too much communication is locked up in authenticated mailing lists.
I don’t think I’d get any value from the ability to limit WorldCat searches to my local library network.
I search for books on WorldCat in preference to using my local library network web site because WorldCat has more books, so I have a greater chance of verifying that I have the search (e.g., author or title) correct and because I can get from WorldCat to my library network web site in one click with no retyping, but not vice versa. In effect, I’ve broken search into two parts: getting validated bibliographic data from WorldCat, and then clicking over to the library network to check availability and so on. By restricting searches, I’d lose the ability to distinguish between invalid searches (e.g., typos) and books the library network doesn’t have.
While sorting results by zip code is a little nutty, it’s not altogether useless. If my library network doesn’t have something but a geographically-close library does, I can get it via a third-level ILL, where I go to the library and fill out an actual paper form.
It’s true that I can’t get availability data from WorldCat — I need to go to the library network web site — but because it’s the web site for a network and not just the site for the local town library, the same problem is repeated one level down. I want to see both availability in my local branch and in the network as a whole (since I have one-click ILL for the network), but the network web site doesn’t let me specify my local library.
So … it would make things a little easier if WorldCat let me specify my library affiliation, since WorldCat could then display my local library network first. But because my affiliation is a network and not an individual library I’m still too many clicks away from the information I want. Similarly, I’m a patron and not a library, so I don’t have access to the WorldCat API, but even if I did it wouldn’t be much use without an API to the library network. Since that’s not going to happen, I’m hoping for a really nice screen scraper for Christmas.