NMM, YQL, COBOAT, CODS

Jim O'Donnell organised a talk on Tuesday at the National Maritime Museum from Christian Heilmann of Yahoo! Mia wrote up her notes already and I've not got much to add, but it was a very enjoyable presentation, and when he reached the juicy bit about YQL and BOSS, both of which I'd left for another day's exploration, I learned a lot. Clearly there's a lot of potential there (especially now it's augmented by YQL Execute, announced yesterday), and it looks like it will let you do a bunch of things that Pipes can't do, or is a pain to do (the GUI is great and yet infuriating with Pipes). YQL gives a common API meta-interface (I guess that's the word) for loads of other APIs and for things with no API; it also handles all the crap with authentication, tokens etc; and it will act as the gatekeeper for your API so you don't get hammered by unreasonable numbers of requests.

As with similar tools/services (Pipes, Dapper, dbpedia, and various things nearer the surface like GMaps), YQL is clearly a blessing from both ends of the telescope: we get to use it for its intended purpose - to be "select * from Internet" is the grandiose ambition - knitting together data sources from Yahoo! and beyond; and we also get to offer our data in a developer-friendly way to encourage its reuse by creating OpenTables [note that these are purely a machine-friendly description of how to access data: no data is handed over as such]. Jim has already been busy creating Open Tables and experimenting with YQL.

Following the talk we headed for a pint (and one of themost jaw-dropping jokes I've heard, from Chris), and it was good to talk to Tristan from Cogapp. When I stopped raving incoherently about the marvel that is Solr (yes, still in love even as I gradually find out more about it), Tristan cleared up some questions for me about Cogapp's COBOAT app. They recently open-sourced this (as far as possible), in the context of the Museum Data Exchange project with OCLC (see Gunter Waibel's recent post), where it plays the role of connecting various collections management systems to an OAI Gateway-in-a-box, OAICatMuseum (well seems like it's only used with TMS in the project, but the point of COBOAT is that it just makes life easier for mapping one data structure to another, and another CollMS would slot in just fine).

For me, both COBOAT and OAICatMuseum are of interest for the role they could play in our the revamped Collections Online Delivery System* we'll build this year, resources allowing (in other words, don't hold your breath. Mission critical, yeah, but worth paying for? I await the answer with interest). Integrating and re-mapping data sources, an OAI gateway, and sophisticated and fast search are key requirements, as is a good clean API, and taking these two applications along with Solr I feel like I may have identified candidates for achieving all of these aims. We're a long way from a decision, of course, at least on the architecture as a whole, but I have some tasty stuff to investigate, and I'm already well down the track in my tests of Solr.

Thanks again to Jim for arranging the talk. He's got another great guest coming up, hopefully I can make it to that one too.

*I'm resigned to this thing being called CODS but still hoping for something less, well, shit

WorldCat/OCLC get the rough end of the Guardian's stick

Well I've always had huge admiration for OCLC and for their WorldCat service (and FindInALibrary, built upon it). My admiration has arisen in large part from the papers and reports that have come out of its distinguished personnel, and I've never known that much about its core business and how it works with libraries to make WorldCat what it is. The Guardian has a pretty critical piece (Why you can't find a library book in your search engine), which does allow OCLC's Karen Calhoun to come back but lays into a proposed rule changes that, says author Wendy Grossman, basically stops the reuse of any WorldCat data as of next month.
Now the article leaves me pretty confused about just what's to be protected. Is it the descriptive metadata about individual publications that OCLC people wrote, or data about which libraries those publications may be found in, or both? Can libraries themselves can use their own data? Does WorldCat exclude Google from its pages? Grossman would seem to imply so. I'm certainly in favour of WorldCat being truly open with a public API, and getting its stuff in all the search engines; and anything that makes it easier to know whether something is in your local library is good. AFAIK WorldCat doesn't have a really open and powerful API and this, frankly, is not sustainable. But I wonder whether Grossman is conflating metadata about books and that about copies of books in libraries in her article, in which case some of the contrasts she makes between what OCLC do and what OpenLibrary, Talis, LibraryThing etc offer may be false and unfair.

I guess I need to do some investigation myself, really. On the face of it the proposed rule change sounds unwelcome, but I'm too much of a fan of OCLC to take that criticism unquestioningly.

Showing us the way

I presume it's uncontroversial to say that it would be useful to have terminologies available as web services. Right now, you can browse various sources of reference terms that are useful to museums (amongst others): sources like the british & irish archaeological bibliography (including its approved term lists); the National Monument Record Thesauri; and the museum codes and SPECTRUM terminology termbank maintained by the Collections Trust (to highlight some UK examples). I'm certain it would be useful to have these available as web services (some more so than others); likewise other thesauri that AFAIK aren't available to programme to: ULAN and AAT, for example, which are collected under the CCO initiative.

There's every chance that I misunderstand some or all of these "services" in terms of how they're used and by whom (I'm very shaky on the status of CCO and its relationship to AAT, for a start). But I'm sure that there are many ways in which a programmatic interface to their contents could be used. Which is why (to get to the point of this post) the service that OCLC's top geeks have come up with here is a great example for us in the museum world to look at (blogged here on Hanging Together). This is a collection of esssentially library-related thesauri onto which they have created web services. I like the look of FAST best of all; it could be really useful for us in the dusty bones world too.

Lorcan Dempsey also blogs today about the WorldCat identities API and other cool services. I fancy the name look-up service: aside from anything else it gives us a URL to refer to for those individuals in the WorldCat database. Here's a not-so-random entry.


So once again we can learn a lot from libraries leading the way. One of the cool things, though, is that OCLC are a cross-domain organisation, and people like Dempsey think constantly about breaking down the barriers between libraries, archives and museums. If they've sprinkled their magic onto library terminologies, I'm sure they'll be only too happy to help the museum world to take similar steps.

Names authorities

The Virtual International Authority File OCLC project looks like another possible step in the right direction, different from but kind of paralleling this JISC project. I don't really understand either but need to get 'em down here for their relevance to the Semantic Web (which in this context probably merits capitalisation)