At the start of the Art Maps project (January 2012), we began with two things; a copy of the Tate Collection database containing information on more than 70, 000 artworks; and the desire to use crowd-sourcing techniques to gather geographic information about the artworks. On the surface, this would not have been a particularly difficult desire to satisfy; we could have very quickly put together a workflow for an existing crowd-sourcing platform, recruited members of the public and (with enough public response) have achieved the results that we wanted. It was when we began discussing the nature of location and how it relates to artworks that we realised the simple solution above might be one that would work, but not one that would capture fully what we were asking the public. (This discussion has been covered more fully in earlier blog posts).

What is important to understand though is that place as it relates to an artwork is not a quantifiable attribute. Although we can assign a value of a place (latitude and longitude) to an artwork this does not contain the meaning of that relationship. For example in the case of a landscape painting depicting a building, if we assign a place to that artwork do we mean that the place is the coordinates of the building, or where the artist was stood, or something else entirely?

How then do we capture the semantics of this relationship? Or rather, in the development of a software platform, how do we allow a participant to provide the semantics of the relationship? Between humans, we use language and discussion to convey meaning and in the online world one common way in which we do this is to blog about things. We therefore started down the path of thinking: ‘how can we take a blogging platform and allow the public to do what they naturally do (that is, talk/blog) and incorporate into that the facility to crowd-source geographic information about artworks?’

The platform design process went through a few iterations (and will most likely continue to iterate) until at this point we have arrived at an architecture as shown below.

Art Maps platform design architecture

The Art Maps Azure Core is a Windows Azure Cloud Service that contains the database of artworks (referred to as ‘objects’ within the application code), and the locations that are associated with them where locations are stored as point locations with a latitude and longitude. The database is exposed to external services as a RESTful API and can be updated by authorised clients. The authorised clients that exist at present are a plugin for the WordPress blogging platform and an iOS application that is a modified version of the WordPress iOS application.

We chose to start with WordPress as a base platform for user interaction as it is a mature and open source blogging platform that provides good support for extending its base feature set. Using WordPress as a base platform gave us all of the basic functionality such as user management so that we could concentrate on the core functionality of the ArtMaps platform. The WordPress plugin and iOS application provide a front-end to the data contained within the Azure Core service (the most immediately visible part of this being the map screen within Art Maps), and a way for users to provide suggestions of locations of artworks or confirm other user’s suggestions.

Users are encouraged to provide their thoughts on their actions regarding artwork location by blogging them. We here take advantage of existing blogging practices and protocols to distribute this ‘conversation’ amongst user’s own blogs and the Art Maps platform. When users blog about an artwork, the Art Maps platform provides a skeleton structure to the blog post. When posted, this triggers a pingback so that the Art Maps platform is notified automatically that the blog post has been made. The structure provided to the blog post gives a guide to automated processing of the post (this currently has been left for future work). This is a process that we call semi-structured blogging. The Art Maps platform is open source.


Definitely true. One thing I found quickly starting at the British Museum was how naive Linked Open Data has been to historical (albeit 'real world') geography. I'm mapping our geographic vocabulary to Geonames, for instance, right now; DBpedia's geographical resources are broader but not so concretely defined.


Barry - indeed for a lot of simple attributes, would be suitable - and that exercise in translation from the existing Tate database (only 75000 entries) could be mechanically achieved with some additional crowdsourcing of missing elements.

However, our research is about how people relate art to place. While simple relationships "where the artist sat" might lead to a simple array of (latitude, longitude) , e.g. unknown (0 locations), sat in one place (1) or wandered around a bit and finished in the studio (n), we run into issues with "where does this represent" - how about heaven, MIddle Earth or Chronos; and then once we ask "where does it make you think of" it gets interesting! For the more interpretative elements we simply cannot know a priori all the conceptualisations people might have... which is what makes it fun!

Regarding "how then do we capture the semantics of this relationship?" - have you thought about exposing these semantic relationships using Semantic Web / Linked Date technologies, for instance embedded RDF in HTML attributes (RDFa) within your content?

This is dual purpose as you could both allow easier re-use of the data than your custom API, and map to vocabularies such as that are routinely crawled by Google, etc.