| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

MW2011 Opensearch unconference session

Page history last edited by Paul Rowe 9 years, 5 months ago Saved with comment

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:

 

 

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.