Chronicling the Lives of Objects – Horizon Services Campaign

A chronicle (Latin: chronica, from Greek χρονικά, from χρόνος, chronos, “time”) is a historical account of facts and events ranged in chronological order, as in a time line (Wikipedia). Chronicle is also the name of the platform being developed by Horizon to support its Services Campaign projects. These projects are categorised by the necessity of keeping an electronic record of facts and events relating to a thing. Take for example the Memory Machine project, the thing in this instance is the physical artefact (the Memory Machine), and the electronic record is the content being added to it. So far so boring, the platform could be little more than a database.

Where the Chronicle platform gets interesting however, is as a tool to support the concepts of ownership, sharing, and gifting. Take again the example of the Memory Machine; the physical artefact itself is owned by an individual. It’s intended use though is for third parties to have the capability to share content that that party has some ownership of. The physical heirloom may also (ideally) gain an heirloom status in which it is gifted and regifted. These actions begin to create new layers of complexities that mean our simple database begins to look a lot more complicated.

The Chronicle platform is being designed and built to support these interactions but also to ask its own questions such as:

  • What does it mean to delete something from the record? should it even be possible or should a record remain indelible?
  • If a record is indelible, what are the implications for privacy and ownership rights?
  • How are changes of ownership handled?

You can follow the progress of the development of Chronicle at and on Bitbucket at

Featured image by Peterborough.Chronicle.firstpage.jpg: en:User:Geogrederivative work: Hchc2009 (Peterborough.Chronicle.firstpage.jpg) [Public domain], via Wikimedia Commons

Source: Chronicling the Lives of Objects – Horizon Services Campaign

Wander/Highfields Workshop

Originally posted here
On Wednesday 27th April 2016 we will be running a workshop on user-generated locative media experiences on campus at the University of Nottingham. We would like to invite participants who have a special interest in the Highfields Park and Lakeside areas of the University of Nottingham, for example local history groups, employees of the University or City Council who have responsibility or interest in the areas. The workshop will introduce participants to 3 pieces of software:

as well as the University of Nottingham Manuscripts and Special Collections. Participants will then be asked to use the software tools provided to create their own locative media experiences (either in groups or on their own) which they will then be able to share with other participants. Wandering Highfields Park will be encouraged and some digital recording equipment (cameras, camcorders) will be available to use on the day.

Lunch will be provided and reasonable travel expenses can be reimbursed.

For all enquiries or if you would like to attend, please email Dominic Price at

Agenda: download

Date: 27/04/16
Time: 10am to 4.30pm
Digital Humanities Centre
The University of Nottingham
Humanities Building
University Park
Nottingham, NG7 2RD

When OAuth doesn’t quite fit

One of the key themes in Horizon, since it started 5+ years ago, has been ‘keeping personal data personal’. What we’ve tended to mean by this is that an individual should retain all the rights to the digital data that they produce (social media content, data from smart meters in the home, data from activity loggers, and so on) and that the individual should be the ultimate gatekeeper of access to that data. This simple idea is a reversal of the way that most current service providers implement their systems, the usual method is that user data is uploaded to the service providers servers and the service provider then maintains and controls access to that data.

In order for us to experiment with the concept of data being owned and controlled by the user, we have over the years built (to greater and lesser degrees of success) systems that attempt to interface with service providers systems and extract users’ data. Most commonly, the way to achieve this is through the use of a service provider’s application programming interface (API) and the most common way of authenticating with these APIs is through the OAuth protocol. I’m not going to go into the pros and cons of OAuth, speaking as an application developer it’s pretty easy to use and well supported, the problem that we have is that OAuth doesn’t quite fit the needs of our use cases.

OAuth is described as: “OAuth is a simple way to publish and interact with protected data. It’s also a safer and more secure way for people to give you access. We’ve kept it simple to save you time.” ( What this means is that OAuth is intended as a 3 party protocol in which the User can give access to their data held by a Service Provider to a 3rd Party. It’s a bit of a simplification but in general this is achieved by API requests being signed by both the user and the 3rd party to guarantee that the request has been authorised by both parties. The issue for us is that we want to remove the 3rd party from that process, we want to give users a way to access their own data in a complete private way. If we act as the 3rd party in the OAuth process, it gives us some level of access to a user’s data, access that we don’t want.

There are ways around this but they are less than perfect. One way is to distribute the 3rd party access tokens with an application, this means that the application will just work. The downside is that those access tokens are then open to abuse and will likely be cancelled by the service provider. Another way is to get the user to register their own OAuth application with a service provider, a confusing task for the average user though (some, like the Facebook app registration are confusing enough for developers!). Some providers, like Github and Google, do provide ways of generating API keys quickly and easily but these of course only work with those services.

It’s an annoying problem, and one that I see being asked quite a lot in various developer problems, because it can only really be changed by the service providers modifying their systems.