This is a great post and there are some really interesting discussions here. I wanted to put in my 2 cents in regards to the federated search issue. I recently wrote an article on how one might attempt to efficiently go about doing a search across museums, “We have OpenSearch, now what?“. Some folks here may find it interesting/useful.

I should be able to give you a link in a few weeks, though the details will be a work in progress for a while longer. I’ll see if I can share our core schema too, though it’s particular to our collections and digitisation projects.

How are you describing the metadata in OAI? We’re using CDWAlite for our works of art, and a qualified DC for everything else, but it feels a bit like we’re cheating on some of the fields…

I’m in the middle of implementing an OAI repository so this is all really relevant (and my ramblings aren’t yet coherent). The repository is a requirement from an external funder, but I’m hoping to use it to get lots of cool stuff in place at the same time. I want it to also serve OpenSearch results, and to act as an index to every instance of our objects in various online projects. We don’t currently have a single catalogue search and the OAI repository is a chance to implement that in a human- and machine-queryable way. It also ties in with our push to create a common basic schema for all our object records, with extensions for objects with more metadata or related media and authority records. It’s a bit daunting but the possibilities are very cool.

I’ve used OAI before (for Exploring 20th Century London) and it worked well for getting data from a range of collections and content management systems into a single repository that could then be used as the source for the actual website. It did mean an overhead in mapping fields, but we needed to do that anyway for the final website. Having a repository instead of using a federated search also meant we didn’t have to worry about slow response times from partner sites - especially smaller museums who already have a lower visibility in the project because they contribute fewer records.

On another note, some of the discussions at MW2008 have really made me wonder about well-implemented single search fields vs advanced search. Advanced search might only be used by a small number of specialist researchers (and our research shows they always want that ability) but having well-defined fields means we can quickly build interfaces or mashups over those streams.

FWIW, I once ended a paper with http://www.laughinglibrarian.com/images/CeilingLibrarian.jpg but it was probably too obscure a cat reference and everyone just looked at me funny. Kittens FTW.

My only concern is with intensive searching and browsing each search comes back to our servers, whereas with OAI it would be running locally. I haven’t thought that through all the way yet, it might not even be a problem.

I’m planning tomorrow to set up a test installing of the Delphi toolkit from Berkeley to see what it thinks of our metadata — that might be one further argument for an OAI approach so the semantics could be teased out of several collections at once.

OpenSearch supports output of results as RSS or Atom too. That gives you some of the advantages of OAI, in that you can add your Dublin Core metadata to each item in the feed. We’re trying this now at the National Maritime Museum - publishing RSS feeds extended with terms from the PNDS application profile.

ps. I *could* have built it mid-session if I’d wanted to.. * cough * ;-)

Mike - pity you’re not still on the project since we could have done with your advice a few times recently. There will be partner time-out limits and caching involved which should help the usability of the final product you’ll be glad to hear. When implemented within WebQuests it will only search over the partners involved in that particular WebQuest. Creative Journeys may well have a ‘remove museum from search’ option as well.