There was an informal breakout session at the 2011 Museums and the Web Conference where the idea of rapidly producing functional Opensearch interfaces to collections (and more) was discussed. These are my notes and a short guide to hopefully allow everyone interested to get up and running quickly.
How do I start?
If you're just here for the how-to:
What is Opensearch?
"OpenSearch is a collection of simple formats for the sharing of search results." -- opensearch.org. It provides a useful bridge between flat HTML pages and a full API, giving people a machine-readable interface to your data. Search results are returned as an RSS feed, a tried and true technology in a well-defined XML format.
Why Opensearch?
It's simple, but still useful.
Because it's RSS, with proper namespace resolution your data can be marked up very simply (baseline Dublin Core) or in a more complex and interesting way (CDWAlite, Qualified Dublin Core, etc).
If we lost you at 'namespace' then this site is a good place to ask more questions. RSS can be viewed in the browser - no code required, though there will be funny brackets - and it's easy for scripters to play with. This often means that you'll get more people using it, which is nice.
It's discoverable.
A quick view-source on a collections page will reveal the presence of Opensearch. Even better, it links to a standard document which describes and gives examples of the features supported by this implementation. Using only this document a program or person can easily understand how to ask for results and know how they will receive them. If other formats are like ordering a coffee in Starbucks (half-tall grande what?!), OpenSearch is like a take-away joint with pictures of food that you can point to.
It's extensible.
Every Opensearch implementation can define its own extensions to the basic search parameters. So in addition to (or instead of) a simple keyword search, you can allow filtering by artist, location, or anything else. As mentioned above the results format can also be extended to include custom metadata beyond the basic format.
Final word:
It lets us standardize how to ask for data, and guarantees a minimum result format.
Examples, please?
The one that got this back on my radar is Europeana: http://europeanalabs.eu/wiki/EuropeanaOpenSearchAPI. For some reason they're limiting access to partners, so it's not a very useful example. A blog post with some examples is here.
View-Source on these pages to find the link to their Opensearch Description file:
- The Powerhouse Museum in Australia implements Opensearch.
- The Walker Art Center has an implemention on their Collections site:
- ArtsConnectEd.org has an extended version running:
- http://artsconnected.org/resource/list (again, build a search and then try subscribing)
- The extension description is actually not up-to-date. It was extended to support the exact same format as the general site search.
- The British Museum has Opensearch running:
- More examples of the XML format can be found on the Open Search in an Afternoon page
- Open Context uses OpenSearch, and expresses search results as Atom feeds (with options many more query parameters, including geospatial):
- Add yours here!
More resources:
Older discussion about extending Opensearch: http://groups.google.com/group/mashedmuseum/browse_thread/thread/6b9e24f1d0966178
Earlier MW2011 session - exchanging data between collection management systems
The conference started with a meet up discussing exchange of data between museum systems. One goal was to talk about LIDO, the new metadata XML standard.
LIDO (Lightweight Information Describing Objects) is a joint effort between the CDWA Lite, museumdat, SPECTRUM and CIDOC CRM communities. It is a detailed format supporting a wider range of museum objects and richer information about them. More here: http://cidoc.icom.museum/WG_Data_Harvesting(en)(E1).xml
The consensus was that the first problem to be resolved is not the format of the shared data, but HOW to get to the data. Most systems support manual import and export of XML files, but for most users this is too cumbersome or technical. If users can get to the data, then the format problems can be resolved as a second pass. Most key data elements can be mapped between the common formats (CDWA Lite, Dublin Core, LIDO). OpenSearch was suggested as the simplest way to support getting to the data.
Example uses
Exhibition organiser needs to copy object details into a document or spreadsheet
Office word processor or spreadsheet extended to allow searching of collections management system (CMS). Matching object records returned with options to select key fields and embed content in current document or spreadsheet.
Digital Asset Management System (DAMS) duplicates core object information maintained in CMS
Automatic process when a record is added in the DAMS. searches related collections management system by object accession number to retrieve and duplicate key description information
CMS reconciles object tags with 3rd party tagging project
CMS queries 3rd party system and retrieves list of tags to reconcile with CMS' copy of each object record's tags.
CMS reconciles geolocations with 3rd party geocoding project
CMS queries 3rd party system and retrieves geolocations to reconcile with CMS' copy of each object record's geolocation.
Exchange full records between internal systems
Exchange full records between external system of similar museums
Other notes
Exchanging full records brings up other problems, such as reconciling authority terms. Providing access to data via OpenSearch would be a simple first step that would support some of the simple use cases.
Aggregation projects are simpler as (most of) the data is going one-way.
Comments (3)
Mia said
at 11:49 pm on Apr 12, 2011
The Europeana API access limit is due to copyright/licensing issues, IIRC - they're aiming to open it up. (Full disclosure: I have an API key for a research project, though I don't now work for a Europeana partner).
Charlie said
at 4:20 pm on Apr 28, 2011
I just added some documentation on the Museum APIs page for the OpenSearch implementation that was just added to the Indianapolis Museum of Art website (http://www.imamuseum.org). We picked up the Drupal OpenSearch feed module and tweaked it just a little. Our OpenSearch exposes our entire site, which includes the collection. I also included an example of how to retrieve only collection results as well.
http://museum-api.pbworks.com/Museum%C2%A0APIs
Mia said
at 4:46 pm on Apr 29, 2011
Nice one, thanks Charlie.
You don't have permission to comment on this page.