Timelines and Linked Data.

We’ve made a few timeline engines recently. First we made one for English Heritage, which gave us some challenges dealing with historical dates. Then we made another timeline for the Wellcome Library. This uses a completely different approach to rendering the interactive timeline. You can see it in action here. We’re also developing a new Timeline for English Heritage, but that’s not public yet. It builds on our learning from the Wellcome Library project.

All these timelines are single page web applications written in JavaScript, which make a request for their timeline data from a publicly available URL. For example, the Wellcome Library timeline loads in a large chunk of JSON from here:


In theory, other people can do what they like with this data. And obviously as long as you can supply the data, you can make as many timelines as you like once you have the engine to display them. In all our timeline implementations we’ve made it easy for editors to build the content for the timeline in a CMS.

This is for one particular CMS but the approach would be the same for any kind of repository. Regardless of how the data is actually stored, you need a front end that makes sense to editors assembling sequences of events to plot on the timeline, and a back end that coerces this data into the JSON format required by the JavaScript application that renders the timeline in a browser. In these cases the front end is the out of the box UI of the CMS itself, but a more sophisticated Timeline editing tool could make it really easy for anyone to build a timeline.

For a timeline like the Wellcome Library, there’s no getting around the fact that getting the data together is a big editorial job. But there may be a way of speeding up that process, or even bypassing it altogether for some timelines, if the information you want to display on the timeline is available via a sparql query from somewhere else. A timeline is a sequence of events, with each event having simple fields like title, description, date (of course), thumbnail, image, “read more”...

If we can concoct a Sparql query that returns the necessary data, all we need to then is transform it into the JSON that the timeline engine needs, something which is fairly simple to do. For example, here’s a SPARQL query directed against DBpedia that returns Led Zeppelin albums:


This gives us all the data we need.

And here’s another that gives us battles of the 100 years’ war:


This web site allows you to build SPARQL queries and see them plotted on the Wellcome Library timeline engine.

There is a snag when using DBpedia as a source. The images in the DBpedia data often result in 404s. For example, this triple:

<http://upload.wikimedia.org/wikipedia/commons/5/58/LedZeppelin2IIAlbumArtLarge.jpeg> .

..gives us a URI that ends up with a 404.

Often the image paths are consistently different, so they can be fixed with a search and replace operation – yielding images from DBpedia. For example:




But if you have a source of RDF that can accept a Sparql query over the web, and you have the data to supply the required fields of a timeline event, then you can generate a timeline very quickly.

Coming soon

  • This timeline app is an example of a consumer of linked data. But we might as well re-express those timelines as RDF, for others to consume too. For consuming from JavaScript the JSON format is probably more directly useful.
  • Once you’ve built your timeline from a Sparql query, you can edit the JSON to improve it, tweak the text, select better images etc. We’ll add a nicer editing UI than a raw JSON editor, so that it’s easy to build a timeline whether you made it from linked data or from scratch.