| 
  • 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
 

Science Museum linked data

This version was saved 14 years ago View current version     Page history
Saved by Mia
on March 21, 2010 at 2:21:42 pm
 

This is very much a work in progress, and in fact I suspect it's not even the latest version, but hopefully at least it's more useful up here than on my hard drive, even in a very draft-ish state.

 

February, 2010.

This is a thoughts-in-development piece on how the Science Museum/NMSI could provide re-usable, interoperable, structured machine-readable data for use as linked data or APIs.

 

I've made it a document rather than a blogging it on http://openobjects.blogspot.com/ or putting it on http://museum-api.pbwiki.com/ directly because it's a bit too long (and probably a bit too incoherent) right now. I'd love to hear your thoughts though - twitter (http://twitter.com/mia_out) or email (myfirstname at miaridge.com).

 

URIs and concepts we could model

Concepts we could model:

  • objects,
  • types of objects,
  • people/organisations,
  • events,
  • places,
  • narratives (stories, themes, topics),
  • science subjects (science-y concepts like physics, chemistry, engineering, maths, psychology, astronomy)
  • news stories

 

Each of these would form part of a URI  e.g. http://sciencemuseum.org.uk/objects/[identifier]

 

 

I'm including here things that we generally have enough information about for it to make sense for us to link them. I'll talk about ways to link to the rest of the world below.

 

Objects - we have lots of these. Yay! Each record is about a specific accessioned object. As you can see from the diagram above, objects can be related to everything else (and to each other, in various ways). An object might be as big and iconic as Robert Stephenson's Rocket or as small as a spark plug.

Types of objects - a more generic view. It allows us to solve two problems - our collections don't cover everything we want to talk about, and we have lots and lots of certain types of objects.  So a page on spark plugs is a user-friendly layer of content about spark plugs for general readers and provides links to all 8000 spark plugs in the collection (I totally made that number up).

 

It lets us discuss topics that our collections don't cover comprehensively, and to create a user-friendly layer between the detail of our collection (8000 spark plugs) and general information about spark plugs.

 

[If you're not familiar with museum collections  - coverage varies according to what was collectable or collected - our collections may represent fashions in history of collecting more than an ideal uber-collection. Unlike, say, an art gallery, not every single item in our collection is a precious and unique diamond - for the general user, it might be enough to know what we have some information about dental forceps and a picture of one - but for the specialist researcher, browsing our collection of 300 of them might be the highlight of their week. (Maybe).]

Places - in our collections databases, we can look at the place an object was made, used, designed, destroyed, collected, restored, redesigned, invented, etc, etc. People and events also have various possible relationships to places.

 

People/organisations - ideally, we'd like to Wikipedia for every person and place, but not everyone we refer to in our collections has Wikipedia notability.  

 

Images - we also have lots of related images, which are a major asset but work better in relation to other things (like objects) than as concepts on their own.

 

Other hooks in our content include dates and materials - these might be particularly useful for facetted browsing or mashups made with our data, but don't particularly make sense as concepts on their own. We also produce contemporary science news through our (re-opening in June) Antenna gallery, and marking this up with hNews seems a no-brainer. Working out how to link to the original news stories, whether in Nature, the BBC, whatever, would be good - something we can build into the publishing platform (WordPress MU) to make it nice and easy for our content authors would be even better.

 

Vocabularies

This is one of the places I get stuck...

 

Notes on URIs

Some of our accession numbers are going to make things difficult because they contain '/'.

 

The objects we currently have online in this format are divided by collection, which is possibly a less permanent concept, so my preference would be for http://www.sciencemuseum.org.uk/objects/1878-3 rather than http://www.sciencemuseum.org.uk/objects/computing_and_data_processing/1878-3 (1873-3 is the accession or inventory number - these are about as permanent an identifier as you can get [insert museum-y discussion of the exceptions]).

 

Background-y bits

On Wednesday [you can tell how long ago I started this ] I went to the second London Linked Data meetup, held during dev8D.

 

For a while I've been wondering what we (Science Museum/NMSI) could do with linked data, but it's also taken a while for the issues to bubble up. 

 

The first two issues are data standards and vocabulary.  As the saying goes, 'the good thing about standards is that there are so many to choose from'.  http://museum-api.pbworks.com/Implementation-formats and http://museum-api.pbworks.com/RDFa bear witness to the difficulties of... finding out what developers prefer to work with (if they care at all), finding out what other museums can output to try and get some critical mass going...

 

The third is machine-readable interface design.  Tom Scott [Apis and APIs] advocates building APIs so that you're linking people to the concepts that matter to them, and making your website your API.  I think this is the right way to go, but it's made trickier by the fact that we're not a greenfield site - we've got exhibition microsites that are over ten years old.  We're gradually migrating all that data into a central repository, but it'd be good if we could make the data already online in those sites re-usable too.

 

So I've come up with a model that should allow us to make the most of all the data we've got online already as well as designing around concepts.

 

As well as 'objects' as a basic concept, museums come with a handy set of stable concepts built into our collections management systems.  Sometimes these are called 'subject authorities'.  They cover things like people and organisations, places, events and the relationships between them.  We often build various interpretative narrative layers on top of them - themes, topics, stories, whatever.

 

If we build permanent URIs around those concepts, we can link to them from the existing microsites. We can also wrap metadata around the elements already on the pages of those microsites so that the data is meaningfully machine-accessible in situ.

 

When designing the Cosmic Collections API last year, I'd considered building it into the 'human-facing' website architecture, so that a device could request XML or JSON versions of the pages alongside the (X)HTML pages.  In the end I went for a standalone API as an interim solution.  The Cosmic Collections competition was designed in part to answer some of my questions about the formats preferred by developers.

 

 

Comments (0)

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