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

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

FrontPage

This version was saved 14 years, 6 months ago View current version     Page history
Saved by Mia
on September 4, 2009 at 1:29:16 pm
 

Helping museums make content re-usable; helping programmers access museum content

 

Hello!  This is a site for sharing, discussing, arguing (nicely) over and hopefully coming to some common agreements on APIs and data schemas for museum collections.  It's being led by the Science Museum, London, but we're interested in working with other museums in the UK or worldwide. 

 

If you want to get stuck in, I'm looking for feedback on a draft API for use in a mashup competition about the Science Museum's 'Cosmos and Culture' exhibition.  Let me know what you think.

 

A note on definitions - this is about access to and re-use of cultural heritage data.  I'm pretty acronym agnostic, and apart from the resources required to re-write output scripts, I don't think acronyms compete.  Wikipedia defines 'API' (application programming interface) as "a set of functions, procedures, methods or classes that an operating system, library or service provides to support requests made by computer programs" - there's some discussion of implementation formats on the wiki if you want to dive in.

 

If you want to get in contact, try @mia_out on twitter (unless your account is restricted, of course), or get my email address from the register your interest page.  Or just leave a comment somewhere appropriate!

 

What you can do - if you work in a museum

Any or all of these would be useful:

  • Upload or copy and paste some examples from your collections data schemas - whether that's nicely marked up xml, a table structure from the databases that feed your website, even plain old HTML from an online page.
  • Link to your API
  • List the functionality of your API (through documentation, examples, whatever)
  • Talk about how you decided how to implement your API
  • Share your questions, unresolved issues
  • Explain the project to your collections documentation people, and ask for their help
  • Subscribe to the 'recent changes' feed, and pop in when you see something that interests you

 

What you can do - if you are a developer

  • Try any of the APIs listed, report back - was it useful, could it be made more useful?
  • Tell us what do you look for in an API, or link to APIs you think are done really well
  • Subscribe to the 'recent changes' feed, and pop in when you see something that interests you

 

I find the navigation on wikis a bit annoying: here's a link of all the pages in this wiki so you can get a good overview of what's on the site.

 

I'm not terribly sure how to organise a discussion like this, so I'm open to suggestions.  I'd also like to see some collections people contributing so feel free to invite non-technical people.

 

Background, timelines, goals, etc

Some background: the Science Museum is looking at releasing an API soon (May 2009 for internal use, northern hemisphere autumn for external use) - it'll be project-specific to start with, but we're creating it with the intention of using that as an iterative testing and learning process to design an API for wider use. We could re-invent the wheel, but we'd rather make it easy for people to use what they've learnt using other APIs and other museum collections - the easiest way to do that is to work with other museums.  And hey, it means we'll end up with a better product.

 

Our initial project is a 'mashup competition' based on object metadata from our 'cosmos and culture' gallery.  So related to that, I've posted to the MCG (museums computer group) email list and our nascent 'museumdev' blog (Competitions using APIs - any resources) asking for comments on competition models, licensing, preservation, timelines, platforms, other public domain data sources, visualisation tools, etc.  The project team is cool with me being really transparent and experimental during this planning and design phase so I'm open to any suggestions or ideas.

 

Please feel free to edit pages or add any stuff that you think might be of use.  If commenting feels more natural than editing a page, go for it.

 

The original wiki

This wiki was originally started by Mike Ellis, and used for discussion around how best to communicate the benefits of the "machine connected" approach to (non-technical) cultural stakeholders - you'll see traces of it around.  It's still useful work so please contribute where you can.  Specifically -

 

Comments (0)

You don't have permission to comment on this page.