Pneumatics And Open Data
What do I regard as interesting when working with compressed air and a public data set?
I can only speak of my own experience in this regard, and my outside perspective on databases (which is at risk of exoticising a mundane pragmatic reality). I perceive the tentative open data movement in the UK as follows.
Councils and other administrative bodies of government have been sitting atop untapped reservoirs of data, facts and measurements of the communities they serve, cater to and make decisions for. This data is gathered to help inform their decisions, as part of the paper trail necessary to office administration or maybe just because the data generating machine has set itself up as a self perpetuating, autopoietic entity that guarantees its existence by generating ever increasing amounts of data (more on that some other time…)
The process of open data is for the data to made readily available, and easy to use. The Open Data movement as we have it now is an imperfect machine. It’s stated aim is quite clear to discern from the outside: create a hub or platform that facilitates ease of access to the data upon which governance is based (or from which governance infers its decision making) and then an army of developers will generate entrepreneurial growth and a number of citizens will enhance public discourse and citizenry through the FOI shackles being lifted from them. I feel ill advised to comment on the latter but I feel it has to be noted given the growth in data journalism (I hope the forthcoming ‘Linked Data/Linked Stories’ talk at Future Everything will illuminate me further in this regard). But I feel thats close to the simplest tenet underneath the movement, a sort of ‘build it and they shall come’ ethos but simply applied to making THE hot resource of the post social-web more readily available.
There will be a necessary dischord between what the council has accumulated and what a developer will deem useful. This is inevitable as the data collated was never intended to fuel the next killer app, in many cases it’s the residue of the councils real world activities. Heather Craggs of DeLib vividly illustrated this as she spoke of the process of ‘I Heart My City’. Their endeavour was a matter of expectations and data architectures. However in the ideal scenario what transpires is the data is usable and amenable to the developers ends and the harmonious union of extant data and computational power (and of course the nous of a development team) combines in interactive infographics which enable better querying of the data which is the authorised view on the quotidian days of the machinery of governance that caters to us and our communities.
DeLib’s tribulations are a sterile instance of the much more inflammatory, much wider process of classification described by Bowker and Leigh Starr in their seminal Sorting Things Out: Classification And It’s Consequences. Every database begins with a classification, with an ordering of the enterprise or business which it is intended to make sense of. This ordering is an abstraction (a model) of the work the entity in question conducts: such a process brings certain features into relief at the expense of others to better facilitate the ordering. So far, nothing radical uttered. And indeed DeLibs case isn’t anything radical, rather the facts of the matter is that the financial database from which their source data was drawn from didn’t contain information of the exact location of where the money was being spent, most likely because it was a financial database whose primary concern was the streamlining the process of account balancing. And of course keeping an accurate log for paper trail purposes. Without adopting too utilitarian a perspective one can see that there is a limit to how well a database can be future proofed for all potential, eventual uses, and it’s principal applications will in part be determind by the enterprise that sets it up (Harwood would take this concept in a different direction, arguing that the enterprise has to subjugate itself before the confines of the relational machine in order to make best use of the dividends the machine will offer).
My instant reaction was to be dumbfounded that such information wasn’t somewhere in the database. As part of my work for YoHa I was tasked with unfolding the database origins of the 5 column .CSV that ends up on the councils webpage. I was tracing the Bowker/Starr process in reverse, excatavating an archaeology of classification.
That’s why I feel YoHa’s latest work hits a lot of the right notes, but it has to be considered processually. Air, like data, is an abundant resource, and like data air can be put to work. This is what pneumatics concerns itself with. Crucial to both translations of a resource is the work done, and what machine we construct to do the work. One of Harwoods persistent themes is that the data made available on data.gov websites is only designed to be fed into another machine. This machine could be as simple as Excel software (a software machine), or a more intricate and scalable machine such as evidenced by Iconomical’s wheredoesmymoneygo.org). Most data visualization tools are machines which make data intelligible either via agglomeration or otehrwise. What we have done with the contraption is built another software machine which we can feed the data into, but this software has very particular outputs, informed by a mechanical logic different in intensity to the logic which governs software visualization machines. In both cases however a labour of translation is taking place.
YoHa and I approached pneumatics from an amaetur perspective; even the humblest valves were alien to us (this has an important point relative to expertise, open data and citizen engagement, see the cornerstone argument of the forthcoming ‘Challenging Openness’ debate at Future Everything). We had to work out how to put air to work for us so that we could visualize the data (see forthcoming post concerning visualization as engagement not merely illustration). Harwood’s stock and trade is building contraptions, useless objects which through their tenuous technological existence make manifest a certain nexus of technological forces and the soci0-political forces with which they are entangled. With this project we have built something which marshalls the power of compressed air to do something very specific. Ditto the financial database; (and most databases, for though databases scale database integration seems to elude most enterprises which put them to use and more often than not bespoke databases proliferate within differing departments. Some of the discourse which arises out of this process is being investigated by YoHa and Alexandra Joensson in their collaboration with Liverpool PCT and FACT) it’s quite an efficient machine which permits you to do somethings very well but others not so much. What exactly our machine does well is less tightly defined: it’s direct uses are not intimately related to it’s purpose (which as BCC sees it is to engage people with Open Data).
The data has to organised according to certain tenets to conform to relational database normalisation. Other considerations which consider how the data will be organised, and what data will be recorded will bear far more human inflections (see again Bowker & Starr, section III: Classification and Work Practice). This whole process is occluded from the Open Data movement (for more on this topic from a man far better versed in the detail of Open Data please see this link here). Which is why Open Data shouldn’t be conflated with open governance. This is not a tin hat soliloquy, some of these decisions will be motivated by utterly boring rationales. And yet these decisions might influence the granularity with which you can appreciate where money is being spent, or as Tim Davies notes, make posing a question of the data more difficult (in other words occlusion of mediation can make a complex matter appear simple)
One could, if they wished (and I do) see the construction of a pneumatic contraption as analagous to the mapping/atomisation of an enterprise that accompanies any databases creation. We choose which valves to use, when to trigger them, what level of pressure will relate to which actuator. As with any mechanical assemblage the end product will attain a coherence of sorts. As might open data, a process pockmarked by fissures of what councils wish to be accountable for, might attain something resembling solidity to the outside eye.
There are issues of expertise bedded in here aswell. Those who are making the most of open data need to have a certain capacity for it (see forthcoming blog post for more). In open data we can witness a similar array of technological forces being marshalled. Already I get the feeling the pendulum could go one of two ways. We may end up with useful scenarios where forays like Delib force councils to reconsider their data gathering practices: data must now be gathered in a manner sensible to the eyes of all not merely those in authority.