Thinking aloud: does a museum's obsession with polish hinder innovation?

I'm blogging several conversations on twitter around the subject of innovation and experimentation that I thought were worth saving, not least because I'm still thinking about their implications.

To start with, Lynda Kelly (@lyndakelly61) quoted @sebchan at the Hot Science conference on climate change and museums:

'Museums want everything to be slick and polished for mass audience, we lose capacity to be experimental and rapid'

which lead me to tweet:

'does big museum obsession with polish hinder innovation? ('innovation' = keeping up with digital world outside)'.

which lead to a really interesting series of conversations. Erin Blasco responded (over several tweets):

We can't pilot if it's not perfect. … Need to pilot 15 quick/dirty QR codes but we can't put ANY up unless there are 50 & perfectly, expensively designed & impressive. … So basically not allowed to fail and learn = not allowed to pilot = we spend a bunch of $ and fail anyway? … To clarify: it's a cross-dept project. One dept ok with post-it notes & golf pencils. Two others are not. Kinda deadlock.

I think this perfectly illustrates the point and it neatly defines the kind of 'polish' that slows things down – the quality of the user experience with the QR codes would rest with the explanatory text, call to action and the content the user finds at the other end, not the weight and texture of the paper or vinyl they're printed on. Suddenly you've got extra rounds of emails and meetings for those extra layers of sign-off, a work request or contract for design time, plus all the stakeholder engagement that you already, but does that extra investment of time and resources result in a better experiment in audience research?

But kudos to Erin for gettings things this far! (An interesting discussion followed with Erin and @artlust about possible solutions, including holding stakeholder evaluations of the prototypes so they could see how the process worked, and 'making the pilot-ness of it a selling point in the design, letting audiences feel they're part of something special', which made me realise that turning challenges into positives is one of my core design techniques.)

For Linda Spurdle, the barriers are more basic:

Innovation costs, even my plans to try things cheap/free get scuppered by lack of time. For me less about risk more about resources

Which also rings perfectly true – many potential museum innovators were in this position before the museum funding cuts took hold, so innovating your way out of funding-related crises must be even more difficult now.

On the topic of innovation, Lindsey Green said the 'definite reluctance to pilot and fail impacts innovation'. Rachel Coldicutt had just blogged about 'digital innovation in the arts' in Making Things New, pointing out that the question 'privileges the means of delivery over the thing that’s being delivered', and tweeting that 'innovating a system and innovating art aren't the same thing and perhaps there's more impact from innovating the system'.

If the quest is to, as Rachel problematises in her post, 'use digital technologies to remake the Arts Establishment', then (IMO) it's doomed to failure. You can't introduce new technologies and expect that the people and processes within a cultural organisation will magically upgrade themselves to match. More realistically, people will work around any technology that doesn't suit them (for entirely understandable reasons), and even the best user experience design will fail if it doesn't take account of its context of use. If you want to change the behaviour of people in an organisation, change the metrics they work to. Or, as Rachel says, '[r]ather than change for change’s sake, perhaps we should be identifying required outcomes'. Handily, Bridget McKenzie pointed out that 'The Museums for the Future toolkit includes new eval framework (GEOs = Generic Environmental Outcomes)', so there's hope on the horizon.

The caveats: it's not that I'm against polish, and I think high production values really help our audiences value museum content. But – I think investing in a high level of polish is a waste of resources during prototyping or pilot stages, and a focus on high production values is incompatible with rapid prototyping – 'fail faster' becomes impossible. Usability researchers would also say polished prototypes get less useful feedback because people think the design is set (see also debates around the appearance of wireframes).

It's also worth pointing out my 'scare quotes' around the term 'innovation' above – sadly, things that are regarded as amazing innovations in the museum world are often delayed enough that they're regarded as pretty normal, even expected, by our more digitally-savvy audiences. But that's a whole other conversation…

So, what do you think: does a museum's obsession with polish hinder innovation?

Update, January 2013: Rob Stein has written 'Museum Innovation: Risk, Experimentation and New Ideas', which resonated strongly:

A common pitfall for museums is an unhealthy addiction to monumental undertakings. When massive projects loom with ties to outside support and countless staff hours invested in a single deliverable, it becomes very difficult to admit the possibility of failure. As a result, we shy away from risk, mitigate the probability of embarrassment, and crush innovation in the process.

Sharing hard-won wisdom about museum games – introducing 'Lift your (museum) game'

One outcome from MW2011 was the creation of 'Lift your (museum) game', a site for people who make museum games to share their hard-earned wisdom – project evaluation, research, references, methods, rants, lessons learnt from real projects – about making museum games. Inspired by a question from Martha Henson about whether any sites already existed to gather resources like those discussed during the panel discussion after the Games session at Museums and the Web 2011 (with Dave Schaller, Elizabeth Goins and Coline Aunis), I created the wiki during the closing plenary and watched in awe as Kate Haley Goldman immediately started populating it with links.

Museum games have to compete in a highly competitive market, especially for casual and social games, and I suspect 'worthy' will only take us so far these days. I'm hoping the dialogue around this site will help people avoid the pitfalls of 'death by museum committee' when designing games and push for excellent gameplay in museum games. There are some great museum game projects and research going on, and pooling resources could help multiply the benefits of that work and provide a resource for people just starting out. Also, if you're a games agency or designer, this could be a great place to pass on any tips or links (or warnings) you'd like potential museum clients to know about. I've got a few papers on crowdsourcing games for museums coming up, so I'll be adding links and resources as I go – it's easy to add your resources or questions, just sign up at http://museumgames.pbworks.com.

One of the key themes of MW2011 for me was 'standing on the shoulders of giants' – there's so much good work going on in the museum digital sector, and so many amazing people are willing to share what they've learnt along the way, and hopefully this museum games wiki is a contribution to helping us all see further and do better.

Founding visions (and learning from the past for the future of museums)

I've got a few presentations coming up that explore a re-imagining of museums, so I've been thinking about the original founding visions of specific museums (based on e.g. What would a digital museum be like if there was never a physical museum?), and whether there's dissonance between mission statements based in institutional history and those you might write if we were inventing museums today.

For an example of where my thoughts are wondering, check this out (from the excellent 'Museums should not fear the art snobs'):

…it was only with the emergence of aestheticism and competition from universities in the late 19th century that curators started making exhibitions for each other and for people of their class. Most earlier Victorian museums were educational institutions (not just institutions with education departments). In Britain, both the Liberal Henry Cole (founding Director of the V&A) and the Tory John Ruskin created museums that aimed to achieve the widest possible audience in the name of public education. The Met was founded “for the purpose…of encouraging and developing the study of the fine arts, and the application of arts to manufacture and practical life…and, to that end, of furnishing popular instruction.” In 1920, the Met’s president Robert de Forest wrote that it was “a public gallery for the use of all people, high and low, and even more for the low than for the high, for the high can find artistic inspiration in their own homes”.

So I'm curious, and if you're up for it, I have a little task for you (yes, you, over there) – what was the founding statement for your museum, and what is your current mission statement? And if you're feeling creative, what would you like your favourite museum's mission statement to be?

Some leads on game design in the UK

Today I passed on a query from @fayenicole: '…know anybody who could run a retro-style game design workshop for teenagers at the British Museum?' on twitter and got a bunch of responses. Since people were so generous with their time, I thought I'd take a few minutes to collate them so they're available the next time someone has a similar query. Feel free to add further suggestions in the comments, particularly for people or agencies who are keen to work with museums and cultural heritage organisations.

@guylevans: 'Gameduino' looks interesting, its an Arduino shield which allows for 8 bit gaming experiments http://gameduino.com
Billy Abbott @cowfish: Not sure on the general design but @Pixelh8 is king of beepy tunes and also might know some people.
Nicholas Butler @loudmouthman: I might point you to @MrPointyHead, @Cowfish and possibly @DigitalMaverick for additional thoughts .
Ben Vost BeeVee23: I do, but he's not on Twitter. Simon Goodwin has worked on games since the Spectrum days and currently works for CodeMasters
Simon Bennett PsiBennett: Possibly www.gamerzevents.com
Sebastian Deterding @dingstweets suggested @hidingseeking.
Thanks also to @philmarston for suggestions.
@re6smith: ask @AndrewRilstone a game designer friend of mine
James Kemp @greencoatboy: I know a whole load of game designers http://www.clwg.org/
Carl Huber wetwebwork: @PlayerthreeUK , maybe? http://bit.ly/eSI1oT
Nate Cochrane @natecochrane: Is Braybrook available or the Yak?
And of course thanks to @doctorow for retweeting my message so that other people saw it.

In other news, I learned this week that 'MT' means 'modified tweet' and signifies when someone's shortened or otherwise changed something they're retweeting. Mmm, learning.

Documentation for collections data from Science Museum, National Media Museum, National Railway Museum (NMSI) released as CSV

I originally posted this on the Science Museum API documentation wiki.

About this data

These data sets contain information about objects from the collections of the Science Museum, the National Media Museum and the National Railway Museum. These datasets include many items not on display in our galleries, as well as authority records about related people and organisations, events and image files.

The collections include objects relating to aeronautics, agriculture, astronomy, cinematography, medicine, materials, space, television, time measurement, transport and more. They range in size from contact lenses to Concorde 002.

We've published three data sets:

218,822 object records (currently in 4 files, each up to 15mb) (NMSI_object1_20110304.csv, NMSI_object2_20110304.csv, NMSI_object3_20110304.csv, NMSI_object4_20110304.csv)
40,596 media records (metadata about images already published online) (NMSI_media_20110304.csv)
173 event records (NMSI_events_20110304.csv)

We hope to publish our lists of c9000 people and organisations related to these objects soon, alongside a table linking objects to events.

The data is supplied in CSV (comma-separated format, exported from Excel). The first line of each file contains the field headings. Files may be up to 15mb in size.

The data is released under the Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA) licence (http://creativecommons.org/licenses/by-nc-sa/3.0/). Please contact us if you would like to use this data under different conditions.

Why we're releasing the data

We have been providing access to a searchable database of our collections online at http://collectionsonline.nmsi.ac.uk/ for some time now, but through staff attendance at various hack days, we've learned that this interface does not support programmatic search or exploration of the data. We've also learned (through the Cosmos & Culture project) that a number of people found the XML provided by the default .Net service that published the API too complex. CSV is a very simple format, accessible to a wider range of people. We hope that it will be usable by most people.

We're publishing the data in CSV format now as a relatively lightweight experiment. We'd like to understand whether, and if so, how, people would use our data. We'd also like to explore the benefits for the museum and for programmers using our data – your feedback would inform decisions about future investment in more structured data as well as helping shape our understanding of the requirements of those users.

We hope you will be creative with it, but please use it responsibly. If you're not sure whether the museum would be comfortable with your idea, please drop us a line to discuss it.

How you can help

You can help us to improve this resource – let us know if you have any information about our objects, or if you find any errors, though we will probably not republish this data set in the short-term. Please quote the Object Number/s and email: Collections.Online@nmsi.ac.uk

We'd like this experiment to help us understand the needs of potential users but we can only do that with your help – we'd love to hear your comments on how you've used the data, and how we could improve it. If possible, we'd like to feature mashups or other applications made with our data. Please email us at web.team@nmsi.ac.uk, send @sciencemuseum a message on twitter or leave a comment at http://sciencemuseumdiscovery.com/blogs/museumdev.

Objects

NMSI_object1_20110304.csv, NMSI_object2_20110304.csv, NMSI_object3_20110304.csv, NMSI_object4_20110304.csv.

Column title	What is it?
ID_NUMBER	The unique identifier for a record, based on the museum's own accession number. The number may refer to a single object or (historically) to a collection of objects.
ITEM_NAME	Object name – a simple name or common name. Where possible this is from an established thesaurus (i.e. http://museum-api.pbworks.com/f/NMSI_draft200903_object_name.csv)
TITLE	A short one-line caption or brief description of the object, derived from the existing data. The title should be a summary capturing the essence of an object. Often includes related place and date.
MAKER	The name of the person or company or other organisation that made the object. The Maker field is indexed and linked to the People/Organisation records (to be released shortly) – links should be made by matching strings (internal IDs are not available).
DATE_MADE	The date when an object was made (production date). Dates should be recorded consistently and ranges should be in the format <earlier year>-<later year> e.g. 1671-1700. Approximate dates are written as e.g. c. 1936. This field also contains various strings, including ‘Unknown'.
PLACE_MADE	Place names are indexed in the database and linked into a hierarchy (Getty Thesaurus of Geographic Names with in-house modifications i.e. http://museum-api.pbworks.com/f/NMSI_draft200903_place.csv) and should be recorded consistently because they are derived from a term list. Where known with certainty or reasonable probability the town or city of production is recorded. As a minimum the nation/country of origin or the probable nation/country of production should be recorded. If there is some uncertainty this can be explained in the general description.
MATERIALS	Records what the object is made of and what part of the object is made of that material.
MEASUREMENTS	Record the type of measurements that are most useful for an object, with ‘overall' being the most usual dimensions recorded. Overall will be the amount of space the object takes up when it first arrives in the museum and is stored. Measurements must be recorded consistently in metric units. Compulsory measurements are Size and Weight. The default units of measurement are millimetres and kilograms. Example: overall: 51 mm x 95 mm x 80 mm, 0.371kg,
DESCRIPTION	In this field we try to describe what the what, when, why, where, who information about the object, what it is, what it does, is made of, who made it, where was it made and what makes it unique. This field should be exported as plain text (without markup). The information here is used by the museum to audit an object so it should be described well with each part defined. It should also contain all the information about the object so that an interpreted description can be written (suitable for publication). Technical terms have been avoided as far as possible. Names, dates, places and significant events should be recorded here in a normalized form but will also be recorded in other indexed fields. As far as possible the following are recorded: <number of objects> <name of object, qualifier> <model name, number> <what is the type of object?> <specific information>:<made by…> <type of object> <place made> <date made> <any associated relevant fact> <materials> <colour><serial number><containers> <accessories> <dimensions> <condition and completeness> <identification of parts> <acquisition/provenance information> <story of display, conservation etc.> <other details>
WHOLE_PART	Mostly an internal field.
COLLECTION	A broad subject specialism applied during the Acquisition/ Entry process. NMeM National Media Museum NRM National Railway Museum SCM Science Museum. Collection terms are listed at http://museum-api.pbworks.com/w/page/36515349/NMSI-Collections-list

For more information on authority records, see http://en.wikipedia.org/wiki/Authority_control

Media

NMSI_media_20110304.csv

This table contains information relating object records to images already published online at http://collectionsonline.nmsi.ac.uk/.

You can use it to construct URLs to images of the objects. (The images are hosted on a site built with a third-party solution so the URLs aren't ideal.)

objects.ID_NUMBER is the equivalent to media. OBJECT, giving you a link between the object and media tables (e.g. 1999-719). The media. MEDIAKEY (e.g. 125972) can then be included in a URL, e.g. the image file URL uses the media key: http://collectionsonline.nmsi.ac.uk/grabimg.php?wm=1&kv=125972

Column title	What is it?
MEDIA_ID	e.g. 10327065.jpg
OBJECT	The object ID_NUMBER e.g. 1999-719
MEDIAKEY	e.g. 125972
CAPTION	Optional. E.g. ‘Class 84 locomotive at Barrow Hill, sanding and filling in progress, August 1984'

Events

NMSI_events_20110304.csv

Currently this data set has fairly random coverage but we would be interested to see whether people find the content useful. If the object was linked to any significant event (historical, political, developmental or other milestone events) or if an object featured at some significant and well-known event or activity, it might be recorded in this table.

Column title	What is it?
Event Name	Includes location and date/date range.
Event Short Name	Event title without location or date (usually)
Event Category	Values include era, war, exhibition, expedition (term list?)
Occurrence Type	E.g. one-time, periodic, annual. Optional
Event Start Date	Single date as year or y/m/d. Mixed formats (sorry!). Also includes BCE dates expressed as negative integers e.g. -3100 Optional
Event End Date	As for Event Start Date. Optional
Display Date	?
Duration	Integer – use with Duration Unit. Optional
Duration Unit	E.g. days, months, years. Use with Duration. Optional
Event Description	Text. Optional
Description Source(s)	May be a URL. Optional
Sort Name	Internal use version of event name

Produced for the Science Museum, London. Last updated by Mia Ridge, March 2011. With thanks to the web, database and documentation teams at NMSI for their support and assistance. Thanks also to @rboulton for testing the documentation.

Documentation for collections data from Science Museum, National Media Museum, National Railway Museum (NMSI) released as CSV

I originally posted this on the Science Museum API wiki. This version dates to March 2011, as I documented things before leaving to do a PhD.

Documentation for collections data from Science Museum, National Media Museum, National Railway Museum (NMSI) released as CSV

About this data

We've published three data sets:

218,822 object records (currently in 4 files, each up to 15mb) (NMSI_object1_20110304.csv, NMSI_object2_20110304.csv, NMSI_object3_20110304.csv, NMSI_object4_20110304.csv)
40,596 media records (metadata about images already published online) (NMSI_media_20110304.csv)
173 event records (NMSI_events_20110304.csv)

We hope to publish our lists of c9000 people and organisations related to these objects soon, alongside a table linking objects to events.

The data is supplied in CSV (comma-separated format, exported from Excel). The first line of each file contains the field headings. Files may be up to 15mb in size.

Why we're releasing the data

We hope you will be creative with it, but please use it responsibly. If you're not sure whether the museum would be comfortable with your idea, please drop us a line to discuss it.

How you can help

Objects

NMSI_object1_20110304.csv, NMSI_object2_20110304.csv, NMSI_object3_20110304.csv, NMSI_object4_20110304.csv.

Column title	What is it?
ID_NUMBER	The unique identifier for a record, based on the museum's own accession number. The number may refer to a single object or (historically) to a collection of objects.
ITEM_NAME	Object name – a simple name or common name. Where possible this is from an established thesaurus (i.e. http://museum-api.pbworks.com/f/NMSI_draft200903_object_name.csv)
TITLE	A short one-line caption or brief description of the object, derived from the existing data. The title should be a summary capturing the essence of an object. Often includes related place and date.
MAKER	The name of the person or company or other organisation that made the object. The Maker field is indexed and linked to the People/Organisation records (to be released shortly) – links should be made by matching strings (internal IDs are not available).
DATE_MADE	The date when an object was made (production date). Dates should be recorded consistently and ranges should be in the format <earlier year>-<later year> e.g. 1671-1700. Approximate dates are written as e.g. c. 1936. This field also contains various strings, including ‘Unknown'.
PLACE_MADE	Place names are indexed in the database and linked into a hierarchy (Getty Thesaurus of Geographic Names with in-house modifications i.e. http://museum-api.pbworks.com/f/NMSI_draft200903_place.csv) and should be recorded consistently because they are derived from a term list. Where known with certainty or reasonable probability the town or city of production is recorded. As a minimum the nation/country of origin or the probable nation/country of production should be recorded. If there is some uncertainty this can be explained in the general description.
MATERIALS	Records what the object is made of and what part of the object is made of that material.
MEASUREMENTS	Record the type of measurements that are most useful for an object, with ‘overall' being the most usual dimensions recorded. Overall will be the amount of space the object takes up when it first arrives in the museum and is stored. Measurements must be recorded consistently in metric units. Compulsory measurements are Size and Weight. The default units of measurement are millimetres and kilograms. Example: overall: 51 mm x 95 mm x 80 mm, 0.371kg,
DESCRIPTION	In this field we try to describe what the what, when, why, where, who information about the object, what it is, what it does, is made of, who made it, where was it made and what makes it unique. This field should be exported as plain text (without markup). The information here is used by the museum to audit an object so it should be described well with each part defined. It should also contain all the information about the object so that an interpreted description can be written (suitable for publication). Technical terms have been avoided as far as possible. Names, dates, places and significant events should be recorded here in a normalized form but will also be recorded in other indexed fields. As far as possible the following are recorded: <number of objects> <name of object, qualifier> <model name, number> <what is the type of object?> <specific information>:<made by…> <type of object> <place made> <date made> <any associated relevant fact> <materials> <colour><serial number><containers> <accessories> <dimensions> <condition and completeness> <identification of parts> <acquisition/provenance information> <story of display, conservation etc.> <other details>
WHOLE_PART	Mostly an internal field.
COLLECTION	A broad subject specialism applied during the Acquisition/ Entry process. NMeM National Media Museum NRM National Railway Museum SCM Science Museum. Collection terms are listed at http://museum-api.pbworks.com/w/page/36515349/NMSI-Collections-list

For more information on authority records, see http://en.wikipedia.org/wiki/Authority_control

Media

NMSI_media_20110304.csv

This table contains information relating object records to images already published online at http://collectionsonline.nmsi.ac.uk/.

You can use it to construct URLs to images of the objects. (The images are hosted on a site built with a third-party solution so the URLs aren't ideal.)

Column title	What is it?
MEDIA_ID	e.g. 10327065.jpg
OBJECT	The object ID_NUMBER e.g. 1999-719
MEDIAKEY	e.g. 125972
CAPTION	Optional. E.g. ‘Class 84 locomotive at Barrow Hill, sanding and filling in progress, August 1984'

Events

NMSI_events_20110304.csv

Column title	What is it?
Event Name	Includes location and date/date range.
Event Short Name	Event title without location or date (usually)
Event Category	Values include era, war, exhibition, expedition (term list?)
Occurrence Type	E.g. one-time, periodic, annual. Optional
Event Start Date	Single date as year or y/m/d. Mixed formats (sorry!). Also includes BCE dates expressed as negative integers e.g. -3100 Optional
Event End Date	As for Event Start Date. Optional
Display Date	?
Duration	Integer – use with Duration Unit. Optional
Duration Unit	E.g. days, months, years. Use with Duration. Optional
Event Description	Text. Optional
Description Source(s)	May be a URL. Optional
Sort Name	Internal use version of event name

Science Museum API documentation

I originally posted this on the Science Museum API wiki in 2008, this version dates from about March 2011 (when I left the Science Museum Group to start a PhD).

At that point, the APIs available related to various exhibitions, collections etc were: APIs: Collections, Pledges, Countries, Object Wiki, Exhibitions.

Science Museum API documentation

These documents describe the functionality of the Science Museum APIs.

The APIs have been released as a trial. As such, they should be considered 'beta', and things may change without warning.

If you are interested in devloping using these APIs, or want to ask any questions or make any suggestsions about them, please email us at web.team@nmsi.ac.uk or leave a comment at http://sciencemuseumdiscovery.com/blogs/museumdev.

In addition to the APIs documented here, we have an XML-based API with objects from the exhibition Cosmos & Culture at http://www.sciencemuseum.org.uk/objectapi/cosmosculturepublic.svc/MuseumObjects.

‘Things’ and our collections data

I originally posted this on the Science Museum developers blog.

Frankie Roberto has made a web app based on the object records from the collections of the Science Museum, the National Media Museum and the National Railway Museum released yesterday. In his words:

I thought I’d have a quick play with the data last night, and so managed to import them into a database and built a quick web app called ‘Things’:
http://what-is-this.heroku.com/

The main thing I wanted out of the data was to be able to browse by type-of-thing (eg ‘steam engines’). Given that this information isn’t easily accessible from the existing data, the first thing that ‘Things’ does is ask people to help classify the objects.

It’s sort of like tagging. But easier. :-)

If I get enough things classified I may have a go at seeing if an algorithm can learn from the data and classify the rest.

Let me know what you think.

Source code is here: https://github.com/frankieroberto/things – patches welcome!

Given the number of crowdsourcing projects around*, the next step for the museum may be working out how to manage and make the most of user-created data we get back from projects like this. This would be an excellent problem to have.

* I’ve also got lots of data to handover based on tags and facts added by people playing with the astronomy collections on Museum Metadata Games, which was again only possible because the Powerhouse Museum has an API and the Science Museum made an earlier, XML-based API.

Update on collections data and geocoded NRM data

I originally posted this on the Science Museum developers blog, Filed under: collections,data,requestforcomment — mia @ 6:05 pm

I’m glad to see the news about the release of objects from the collections of the Science Museum, the National Media Museum and the National Railway Museum has spread so far and wide already.

A few people have commented on the licence (Creative Commons Attribution-NonCommercial-ShareAlike, CC BY-NC-SA) and on the format (CSV). As tomorrow is my last day, I can’t really speak for the museum but the intention is to learn from how people use the data – the things they make, the barriers they face, etc – and iterate (as resources allow) until we get to an optimal solution (or solutions). So please get in touch if you’ve got requests or think you can help clear up some of the issues these kinds of projects face, because there’s a good chance you’ll help make a difference.

The licence is a pragmatic solution – it’s clarification of existing terms rather than a change to our terms, because this avoided a need for legal advice, policy review, etc, that would have added several months to the process.

And yes, I know CSV is quick and dirty, but it’s effective. The museum sector is still working out how to match the resources available with the needs of mash-up type developers who work best with JSON and those who are aiming for linked open data; my hope is that your feedback on this will help museums figure out how to support people using open data in various forms. A simple solution like this also means it’s easy for the museum to re-run the export to update the data as time goes on, and that anyone, geek or not, can open the files without being startled by angle brackets and acronyms. Also, did I mention it was quick?

Finally, we’ve already had some useful feedback and even some improved files. Richard Light sent us a geocoded version of records from the National Railway Museum (NRM) (index of locations: http://api.sciencemuseum.org.uk/collections/updates_from_other_people/Richard_Light/nrm-geo-sort.xml (63kb), full file http://api.sciencemuseum.org.uk/collections/updates_from_other_people/Richard_Light/nrm-geo.xml – 20mb, browser-beware).

I’ll let Richard explain in his own words:

I converted the source CSV to XML using my CSV Converter program, which is a home-made program I wrote to do a “mail-merge” on CSV data, with the aim of easily generating other formats such as XML.

The geocoding was carried out by calls to my place URL-ifier program. This uses the standard Geonames query API, but splits a place description into its component place names (e.g. “Swindon, Wiltshire, England” becomes three place names) and searches for a “Swindon” contained within places “Wiltshire” and “England”.

I wrote an XSLT transform which copied the source document, and each time it found a place field, it called out to my URL-ifier using the document() function:

<xsl:template match=”PLACE_MADE[text()!="]“>
<xsl:variable name=”geonames”
select=”document(concat(‘http://light.demon.co.uk/scripts/getPlaceURL.exe
?amp;q=’, text()))/*/text()”/>
<xsl:copy>
<xsl:if test=”$geonames!=””>
<xsl:attribute name=”geonamesId”><xsl:value-of
select=”$geonames”/></xsl:attribute>
</xsl:if>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>

Where this was successful in inferring a Geonames identifier, it added a “geonamesId” attribute to the PLACE_MADE field. So the result is a copy of the source data, with added geocoding.

All of the NRM data was geocoded in a single XSLT operation, but this operation had to call my URL-ifier, and hence the Geonames API, many times. There are limits on how hard you can hit this service, so care needs to be exercised! (You can get your own Geonames identifier for free, and then have your own allocation of API calls, if you want to use this service in a serious way.)

Now that the data contains Geonames URLs, you have access to all the background information about each place. All Geonames entries have lat/long co-ordinates (which is what you need to stick a pin on a map in your browser, using e.g. KML markup), but in addition will often have info such as population. You just need to make an HTTP request for the Geonames URL, specifying that you want RDF back, e.g.: http://light.demon.co.uk/scripts/cgiforwarder.exe?url=http://sws.geonames.org/2633352/&accept=rdf and process the RDF/XML which comes back.

Personally, this kind of thing makes it all worthwhile – we can’t easy export our entire geographical hierarchy, so being able to geocode the imperfect data we have is really useful.

If you’ve done something interesting with our data we’d love to feature it. We’re also curious to know who’s having a look at it, even if you’re not at the point of having something to share.

Finally, I’d almost forgotten to thank the many wonderful people who’d contributed to the Museums and the machine-processable web site or come along to #linkingmuseums meetups to work out how to get to re-usable museum data. I’ll be keeping up the wiki in future, and can be contacted @mia_out.

Collections data published

I originally posted this on the Science Museum developers blog.

I’m very excited about sharing this with you – we’ve just released 218,822 records about objects from the collections of the Science Museum, the National Media Museum and the National Railway Museum.

We’ve released the files as a lightweight experiment – we’d like to understand whether, and if so, how, people would use our data. We’d also like to explore the benefits for the museum and for programmers using our data – your feedback will inform decisions about future investment in more structured data as well as helping shape our understanding of the requirements of those users. The files are in CSV format – because it’s a really simple format, viewable in a text editor, we hope that it will be usable by most people.

We’ve published three data sets:

218,822 object records
40,596 media records
173 event records

The files are released under the Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA) licence. Please get in touch if you’ve got ideas that require a commercial licence.

The files are available at
Documentation for collections data from Science Museum, National Media Museum, National Railway Museum (NMSI) released as CSV. This page includes information about the fields available and the collections included.

The documentation page includes contact addresses, or you can leave a comment below.