museum dev

Some on-going work on museum APIs

2009-04-24T22:20:00.001+01:00

Just a quick note to say we haven't abandoned this blog, but at the moment I've been concentrating on working out issues around schemas/formats, content, and functions for re-usable and interoperable cultural heritage data on a wiki.

There's a list of things you can do if you work in a museum or are a developer interested in using museum data - jump in!

The Cosmos and Culture mashup competition

2009-04-09T17:35:00.006+01:00

[I'll probably be making more frequent updates on my personal blog, Open Objects, until things really get going in about July. If things are a bit quiet here, you can poke me there, on the museum API wiki or on twitter @mia_out.]

I'm really putting this post here so I've got something to point to during any discussions at a conference (Museums and the Web) I'm at next week. It's not perfectly written, and it doesn't necessarily totally reflect current thinking - but I guess that's in the nature of the thing. Perhaps the document is in perpetual beta. So consider this a draft, and remember that it's a document written for internal consumption, repurposed in two minutes before I go back to debugging some code.

[Update: I've put the presentation I gave internally about this on Slideshare.]

Cosmos Mashup Competition

Objectives

Make best use of the limited budget and staff time to get the highest impact web presence for Cosmos & Culture

Experiment with new ways of making objects available via the web

Experiment with new ways of attracting user-generated content

Provide our audiences with new visualisations and interpretative contexts for objects

How the competition works
We make raw data about C&C’s objects (name, date, caption text, people, locations, relevant celestial body, associated images etc etc) available.

Users come up with a mashup interface for this. This will integrate our object information with other freely available resources (examples could include Google Maps; sky mapping applications like Google Sky, Stellarium and Celestia; photo-sharing sites; Yahoo Pipe; IBM Many Eyes, astronomy news feeds … or something completely unexpected). The other resources will generally be a form of visualisation (maps, timelines, etc) or another data source.

The best mashup, as judged by a panel (made up of?) is awarded the prize fund. We will be judging in terms of creativity rather than purely technical accomplishment so if someone comes up with a great idea that they can’t quite execute, we can work this up to get it online.

[Working up the final project might take resources so we'd need to think about this - or we could pair them with another contestant.]

If feasible, we could run a ‘mashup speed dating’ ['hack matching'] event as part of the programme (between the data being released and the deadline for submission) – this would allow people to meet and share creative ideas, knowledge and skills. It would be easier to run this as part of Dana/Lates programme but we can look at different ways of doing it.

Audience
At the competition stage the field would be relatively small, as users will need some familiarity with mashups. Possible entrants could include design students, web designers, astronomers (many are very web literate) etc. Although a small field it enables us to target some sectors who might not normally be interested in a Science Museum web offer, and can be open to people around the world.

Once the finished web presence goes live it is open to all of our web audience.

Timescales
To avoid confusion with everything else going on at the Science Museum in 2009, we could open the competition in Autumn 2009 (there are various astronomy anniversaries we could tie into).

Period between the data release (or event) and the submission date should not be more than a month or it will lose momentum.

Possible benefits
We get users to develop a significant web presence for the exhibition – we don’t have time or budget to do this ourselves.
Fits aim of trying out new ways of interpreting objects.
We could get something really innovative.
The interface could have a life beyond the exhibition run and could be extended to the wider collection (or even to collaborations with other institutions if they are interested).
Shows we are serious about making the collection more accessible, and encouraging users to find their own stories about objects.
Makes use of raw information we are already generating for objects, so does not generate extra load on content team.

Feel free to comment! We're still working out the competition parameters, judging, etc.

If you've got data that might work well with our collections data, I'd love to hear from you.

If you're interested in the API side of things, you can join in on the museum API wiki.

The great API challenge in action

2009-03-23T13:32:00.003Z

Thanks to a bit of creative re-purposing, museum-api.pbwiki.com is open for sharing, discussing, arguing over and hopefully coming to some common agreements on APIs and data schemas for museum collections.

What you can do:

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, tell us what's worked, which ideas we should pinch

List the functionality of your API (through documentation, examples, whatever)

Talk about how you decided how to implement your API

Start a discusion with your questions, unresolved issues

Tip of the Day: saving web.config as Unicode

2009-03-06T12:16:00.003Z

Today's lesson: if you need to edit your .Net web.config file, think twice before doing it in anything but Notepad. If you have edited web.config in another application, it might be saved as ASCII, not Unicode.

The error on your site may be something like:

Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: There is no Unicode byte order mark. Cannot switch to Unicode.

Source Error:

[No relevant source lines]

To fix this, open the web.config in Notepad, choose 'Save As' from the File menu. In the 'Save As' dialogue box, make sure the filename is web.config, 'save as type' is 'All files' and Encoding is 'Unicode'.

There are probably other ways of fixing the error, but this is the 'lowest common denominator' fix, and if you're racing to get a live server back up, Notepad might be all you have.

I should point out that I didn't discover this by bringing the live web server down, so if you work for the Science Museum, don't panic!

The great API challenge

2009-03-05T18:12:00.000Z

Another MCG (museums computer group) discussion list post repurposed as a blog post... In a discussion about the Brooklyn Museum API following on from discussion of the NMOLP 'Creative Spaces' project, Richard Light asked:

Don't we need a standard for what a museum API looks like, and what it delivers? Even better, shouldn't we stop thinking that we need to invent everything we use, and just adopt something like the Linked Data paradigm?

I quickly checked with Daniel, our head of web, that it was ok for me to throw this open to the world, and posted in response:

Science Museum is looking at releasing an API soon - project-specific to start with, but with the intention of using that as an iterative testing and learning process, and I'd be happy to talk to other museums about what they're doing to try and come up with something with at least some core similarities in the schema and functionality. Anyone up for it?

So, are you up for it? I've had a few good responses already. My vague idea is maybe using digitalheritage.ning.com to share data schemas, API functionality, discuss the various acronyms we're using, etc.

You can leave a comment here, or join the ning, or @miaridge on twitter.

Competitions using APIs - any resources

2009-03-05T18:07:00.000Z

The original impetus for creating this blog was to provide somewhere to talk about our plans, ask for feedback, and generally make the process of running a mashup competition using a set of object data created for an exhibition really transparent.

The project is close to signed-off, and I'll go into more detail then, but in the meantime, here's a post I sent to the MCG (museums computer group) email list:

Does anyone have good examples, bad examples, personal experience, whatever, on competition models, licensing, preservation, timelines, platforms, other public domain data sources, visualisation tools, etc? You can email me offlist if that's easier, I can post a compiled list back here.

I was at JISC's recent dev8D event and got some good ideas there, and I'm happy to share the research I've already done if anyone is interested.

Hello!

2009-03-05T13:52:00.000Z

I suppose I should say what this is all about - I wanted somewhere I could ask questions, point people to discussions, make a home for collections of links and stuff in development. I work for the Science Museum in London, and for the 'National Museums of Science and Industry' generally.

So, um, that's it for now.