We're offering a REST interface to the following data sources:
If you're looking for our data from our collections, sorry, we don't have that quite yet!
Update 6/2/2009: I've added archaeological sites to the publications API, which means that KML output is now possible. Accordingly, if you use the default XML you just get back the simple records for publications, but if you request KML you get a list of sites relating to the publications returned by your query. The descriptions of these contain links to the publications. The placemark names are the site codes used in the official records and correspond to those used in MOLA site summaries and the LAARC. The plain XML doesn't include sites related to each publication, though - you have to get the KML, but it's not readily parsed to get at the publications per site- so let me know if it would be useful to have this too. The problem is ending up with loads of placemarks for the same site.
I have also added the ability to request KML about a specific publication, which does of course include individual sites for that publication, but this is just one publication at a time.
Incidentally I've also got decent KML now for lots of MOLA sites, which you can grab from this page. Mash them at will!
More on how to use these changes below.
Update 6/6/2008: I've got a first pass of rendering object data as CDWALite, which you can see here, but note that this is a glitchy and partial mapping. Also, I want to change the URL handling so that you can put in something clean and stable, and possibly use accession numbers rather than the database primary key, as at present.
I've put hooks into the code for plain text and JSON renderings of the output, too, but don't know if or when I'll actually do them. Let me know it they might be useful (or get your hands dirty with some XSLT instead).
Well I'll be chuffed if these services are used at all and I don't anticipate that the server will be hammered, but please be reasonable, and if you're going to feed our data into your site, think about using some form of caching to ease the load on our server and yours. If it's all too much for us I guess we'd have to introduce some sort of limits.
There's no agreement to provide a service at any level whatsoever here, so don't go ahead and look for angel funding to build your funky startup that totally depends on a high quality of service from our events API, at least not without talking to us! I'd love to hear your feedback and ideas, though, so please let me know what you think.
You can see a web page with all our publications here. In order to search programmatically, use a URL of the following form:
http://www.museumoflondon.org.uk/MuseumofLondon/food/rest.aspx?source=pubs&mode=xml
together with the following optional parameters:
You can study the use of most of these parameters and the available values by using the web form and examining the URLs that result from a query. Some parameters are problematic because the terms don't overlap as you might expect e.g. Essex (Southend on Sea) returns the Prittlewell Prince, but Essex doesn't; similarly London doesn't get things that are in the London boroughs, so beware. Here is a multi-parameter query that gets a single publication at present. Most of the querystring is the same as when you use the webpage
These links show that the XML output is pretty raw but I think self-explanatory. I will look at providing alternative forms if anyone has any great ideas.
The events database holds details of events (not exhibitions) at three main sites, as well as outsites when they happen. You can look at them through the regular web interface here . There is already an RSS feed here, which shows all events for the next 14 days. The new API makes that queryable, and is way cooler anyway. Heres a sample query.
The base URL is: http://www.museumoflondon.org.uk/MuseumofLondon/food/rest.aspx?source=events
There are currently two three output formats: plain XML straight from our database; RSS2; and RSS2 with xCal, DC and geo extensions as used by Upcoming (here's a link to a sample of their version). Set the output format by adding: mode={rss2 or xCal or xml}. Leaving it out returns the plain XML.
You can see some of the parameters in action by using the web form but there are more. Some require values you'll have to figure out. I may add others in the future.
You can now query the people in the database of 19th Century photographic London at the PhotoLondon website we launched recently. Right now, you will just get a list of people matching your criteria (100 records per page) with no details. I will soon produce a detailed machine-friendly record page for each person (an example of a human-friendly one is here)
The querystring takes most of parameters you can see on the form including surname, forename, search text (but not multiple words like the form), gender, year of birth/death, "alive in..." year, place of origin, photographic occupation, non-photographic occupation, and presence of attached images. Here's an example search so you can see what you'll get back right now. Here's a wider one.
This service (using "source= os2ll") was built for a specific problem, namely, that we had loads of data with Ordnance Survey grid references but needed latitude and longitude for web mapping applications (with KML and the like). It takes a parameter "gr", which is a comma separated string of up to 100 OSGB references of up to 12 characters long (but always an even number). They can be purely numeric e.g. 512300245600, or use the letter convention for grid squares e.g. TQ709098.
Sample URL: http://www.museumoflondon.org.uk/MuseumofLondon/food/rest.aspx?mode=xml&source=os2ll&gr=tq709098,SW465987,tl123456,51232456,512300245600
The output is very simple XML that includes the original grid reference, the latitude and the longitude. If it's useful, I can create a transformation to output KML instead, but this would require a lot of editing in order to give names to points etc.
Overall, I'd suggest you might look at the resources mentioned below, though you may need to get an API key.
The hard part of the coding for this was done by Rhys Jeremiah who made his labours available on the Hairy Spider blog. He offers a one-at-a-time web service for doing what I've done, but because (a) the web service code itself wasn't available and (b) I wanted to batch process data and (c) I needed to work with strings including letters, rather than pairs of numbers for easting/northing, I extended his work and stuck the REST interface on top. Rhys' work was invaluable and forms the bulk of this service, and he has kindly given his blessing to me making it available. If the code is of interest, please ask.
The accuracy of this geocoding is not 100%. Some of our results in London (which is all I've used this for in anger) are tens of metres away or more, which can equate to different streets. So don't use the output of this service for directing the emergency services to an accident or anything. But it may be a leg-up if you have a situation like ours.
If you have postcodes (UK) zip codes (US) or place names (global) you want to geocode instead, have a look here . An example of the output. It doesn't seem to manage everything (e.g. couldn't find Dunton Bassett, which does exist) but does find other even smaller places and deals with spaces too. It's based on (I believe) the uber-cool NGA GEOnet Names Server but I don't know how they get the REST interface onto that, perhaps they harvested it. Look there for more detailed and sophisticated place name searches.
Better still is nearby.org.uk, which offers basically what I was after in the first place and I'm glad to have now found it! Check out the web service here.
Jeremy Ottevanger (jottevanger@museumoflondon.org.uk)
June 2008