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

  • Whenever you search in PBworks, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, and Slack. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.

View
 

FrontPage

This version was saved 12 years, 5 months ago View current version     Page history
Saved by Mia
on June 28, 2010 at 10:42:29 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 in the UK or worldwide.

 

If you'll be in London on July 7, why not join us for an evening's discussion of 'Linking museums: machine-readable data in cultural heritage'?

 

[Update - I've put some very rough thoughts on Science Museum linked data - would love your comments/feedback.]

 

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.