No automation without representation

(1)

University of Amsterdam New Media and Digital Culture

Master Thesis

-How issue reporting systems (do not) change urban

politics-By: Readers:

Danny Lämmerhirt Dr. Carolin Gerlitz

Dr. Niels van Doorn

(2)

Abstract

This study analyses SP API, an issue reporting API that is used in several cities across Europe. It regards the API from the viewpoint of data publics and thereby problematizes the creation of data-driven representations of the municipality. The study describes how SP API is embedded in an information infrastructure and a network of manifold other stakeholders like citizens, civil servants, software developers and municipal authorities. Thereby it is shown how the data representations of the municipality are means of efficiency measurement rendering civil servants an object that can be monitored while citizens become a hybridized data subject/object, being both creators of data but also objects of data creation.

The study further argues that SP API can be understood as a cybernetic feedback system aimed at self-regulating the provision with public services. It thereby renders service requests and responses visible while black-boxing the municipal organisation and municipal-internal processes. Finally the study argues that it is this dialectics of transparency and opacity that characterize a particular constellation of political power where municipalities monitor their parts, while citizens and civil servants constitute self-regulating feedback systems. This, so the study, reproduces political hierarchies instead of rendering them flat.

(3)

Acknowledgements

I thank the Rosa-Luxemburg Foundation for funding my studies and making it possible that I could take on my studies at the University of Amsterdam.

My special thanks goes to my supervisor Carolin Gerlitz for her patient guidance and her helpful commentaries during the work process.

I want to thank my friends Max Kortlander and Philip Glückler for all the serendipitous moments we shared together and the ideas we came across. Without you parts of this work would not exist in the way they do.

(4)

List of figures

Figure 1: Excerpt of Helsinki´s SP API documentation...22

Figure 2: Image of the eight different functions of Mobile Trouble Shooter...24

Figure 3: Excerpt of a GET service list query, retrieved in XML...30

Figure 4: Screenshot of a service request map used by the Finish newspaper...45

website www.metro.fi Figure 5: Screenshot of the Open311 dashboard...49

(6)

1 Introduction

In 2012 the European Union started a programme called Smart City Service Development Kit (short: CitySDK) (Forum Virium n. pag.). The CitySDK programme is part of a larger transition in the political field which strives to turn governments into platforms. The term platform originates in the web economy where it describes a communications-oriented system between manifold devices, software, browsers and user groups (end-users, developers, hosts of databases, web services and applications) that are connected and integrated (Langlois et al. 4, O´Reilly, Web 2.0 5). Multiple examples for such platforms can be found: YouTube videos can be embedded on blogs (Langlois et al. 4), Facebook and Twitter both integrate third-party applications in their services or spread their social widgets (like-, share- and tweet-buttons) across external websites (Bucher, Twitter API n. pag.; Gerlitz and Helmond 2); and taxi app Uber is integrated in the Starbucks app (Boroyan n. pag.).

Tim O´Reilly, inventor of the term Web 2.0, coined the concept of ‘government as a platform’ and proclaims that it renders governments programmable. This metaphor technically means that government databases are opened for various external users, services and software, similar to the foregoing platform examples (Government 14). O´Reilly promotes the government as a platform as a panacea that enables new forms of interaction between multiple stakeholders and government (Government 14). Communities could use such platforms to build new services on top of governmental databases and to enhance the range of public services while the government becomes a mere “manager of a marketplace’ stimulating an ecosystem of private enterprises attached to the governmental platform (O´Reilly, Government 16). Janssen and Estevez thematize governmental platforms in their concept of lean government. Lean government is a form of state governance whereby the state uses platform technologies ‘to do more with less’ (7). In their terms doing more with less implies that the state reduces its complexity by shrinking the size of its administration and opening its organization and processes towards private entrepreneurs and civil society (1). Important drivers for lean government would be the current financial crisis, a shortage of public sector budget coupled with the rationale of a ‘New Public Management’ which proclaims to outsource activities while introducing performance measurements for the remaining activities (2-5). The accounts of O´Reilly and Estevez and Janssen show that government as a platform is not a value-free concept but connotated with manifold meanings ranging from civic empowerment and

(7)

innovation to financial austerity, public budget management, efficiency measurements and the outsourcing of responsibilities.

Key for such an integration is the so-called application programming interface (API), a specification that enables different software to interact with each other (Baya and Morrison 5; Jacobson, Brail and Woods 5). APIs enhance interoperability, which is the capacity of functionally similar systems to work together (Belford n. pag.). Interoperability not only enables the above-mentioned integration of government databases with external applications on multiple devices and operating systems but also syndication across applications (Bechmann 75). Besides this networking function, APIs capture data about user interactions and store them on databases for further use, as thoroughly discussed in the cases of Facebook´s Like button and of Google´s multiple web

applications (Bechmann 74; Gerlitz and Helmond 2). Furthermore they enable access to databases under the circumstance that they are publicly accessible (Lomborg and Bechman 256).

The history of APIs reveals how APIs have been used in different ways to connect computer systems. Starting in the early 2000´s APIs have been initially employed to syndicate content

between e-commerce websites and to manage sales and commerce (Lane n. pag.). Salesforce.com was the pioneering enterprise offering such services which are nowadays known as software-as-a-service (Lane n. pag.). Shortly after, eBay introduced an API to standardize how external

applications can be integrated with eBay´s services (Lane n. pag.). Social media platforms like Twitter or Facebook followed and introduced their APIs which have already been discussed partly in the introduction. Google Maps introduced its API in 2006 allowing users to contribute data to its maps (Crampton 27). Today marketing companies such as PricewaterhouseCoopers emphasize the importance of APIs for all types of enterprises and talk about the API economy (Baya, Gruman and Parker 14). For instance cloud services rely on APIs (Nijim and Pagano 12). These services entail fitness trackers and wearables (an example is the connection of Nike Fuelband to Nike´s databases) or the use of personal IT devices in companies to access a companies resources (Nijim and Pagano 12).

CitySDK employs the same principles and attempts to build an open, publicly available government platform for multiple end-users such as software developers or citizens. Part of CitySDK is the implementation of a uniform issue reporting API across European cities. Labelled as Smart

(8)

to create an immediate contact between citizens and civil servants (Forum Virium n. pag.). Besides this simple communication function SP API is promoted as a panacea enhancing political

participation and economic growth at once. CitySDK argues that ‘smart participation allows citizens to have a two way interaction with their local council. It means that they can report issues, make complaints or raise issues, take part in consultations or participate in local democracy” (Manchester Digital Development Agency n. pag.). SP API is an adaption of the Open311 API which strives to give voice to citizens more easily. Open311 allows citizens to send issues in the form of API calls to municipal servers and to retrieve issues that have been sent to the city as well as governments responses. Therefore Open311, like SP API, is a two-way communication interface allowing for interaction between citizens and civil servants. The official website describes it as follows:

Open311 refers to a standardized protocol for location-based collaborative issue-tracking. [...] Open311 technologies use the internet to enable [...] interactions to be asynchronous and many-to-many. This means that several different people can openly exchange information centered around a single public issue. This open model allows people to provide more actionable information for those who need it most and it encourages the public to be engaged with civic issues because they know their voices are being heard. (Open 311, n. pag.)

Since all interactions become retrievable in form of data as defined by Open311 this issue reporting and answering process creates new open data while forming a communication chain from citizens to governments to citizens (C2G2C) (Cavallo, Lynch and Scull 5). Open311 and SP API promise to provide what the Open Knowledge Foundation envisions as a ‘read/write’ society. In such a society citizens use open data to be ‘directly informed and involved in decision-making’ (Open Knowledge Foundation n. pag.). Smart Participation API strives to reform the ways citizens engage with their local governments using a communication channel that captures such communication data as a by-product. The creation of a new two-directional communication channel that is integratable with multiple devices and services and that makes the communication between citizens and

municipalities openly accessible indeed appears to be promising to foster transparent communication between citizen and government. However, as Clare Birchall argues that

(9)

transparency and secrecy stand in a symbiotic relationship. Her argument is that transparency implies a secrecy or opacity of other facts, a phenomenon she calls transparency-as-secrecy (Secrecy 7-9).

Drawing on the concept of transparency-as-secrecy this study questions a technocentric affirmation of data-driven transparency and asks how the governmental issue reporting platform around SP API is suggestive of particular forms of transparency and openness that render other phenomena opaque. Thereby it asks if and how citizens are empowered using SP API and which issues can be raised and rendered open. In short it asks what type of ‘read/write” society SP API brings into being and to whose benefit. Drawing on platform studies, critical software studies and ethnography of infrastructure the study depicts the technological infrastructure behind SP API and how it is embedded in institutions, organizations and stakeholders. Relating to debates about open data and data publics the study further asks how SP API creates forms of transparency which constitute particular forms of civic participation.

1.1 Platform critique

Platforms are critically discussed by scholars like Tarleton Gillespie. He argues that a platform is strategically framed as ‘a figurative 'platform' of opportunity’ (354). Gillespie claims that all platforms promise to empower users while obfuscating their ‘normative and technical restrictions’ (352). Hence platforms deserve scrutiny, since they are not mere communication intermediaries (which Smart Participation API and Open311 claim to be) but have politics inscribed in the way they organize communication (359). Platforms offer a vast array of connotations. Gillespie points out in his analysis of content-intermediaries like YoutTube that platforms promote ideas of

empowerment. They offer ‘something to build upon and innovate from [,...] a place from which to speak and be heard [and an] open-armed, egalitarian facilitation of expression, not an elitist gatekeeper’ (352). Being a communication and mediation channel between software that sets distinct rules to connect heterogeneous entities, APIs can be seen as political devices regulating these technical restrictions (Cramer and Fuller 149).

How APIs mediate processes is relevant since they connect multiple stakeholders, each with their own interests in using the platform. Puschmann and Burgess take the prominent example of Twitter

(10)

and analyse how Twitter´s API mediates between stakeholders such as platform providers and end users, but also third parties such as researchers, data analysts, commercial web service providers and governments (44). The authors argue that the Twitter API is an instrument which negotiates between these stakeholders and regulates access to the service´s data. The API would favour advertisers´ and media companies´ interests by selling end users´ data to them. Furthermore they criticize the elitism in re-using Twitter data. Only persons with legal permission and technical capacities may retrieve and use data and only organizations with necessary technological and financial resources are able to compete and use data the way corporations do (50-1).

Other critical platform studies similarly scrutinize API politics, the way APIs organize

communication and service syndication and to which ends. These studies regard APIs as important influencers in socio-technical infrastructures and assemblages. Drawing on software studies Taina Bucher analysed how the Twitter API shapes the conditions of communication and access to data. The API exercises political power by configuring social activities and ‘the worlds imagined’ by it (Bucher, Twitter API n. pag.). Other studies focused on how an API´s design of data points is a crucial enabler of business models based on the accumulation of customer data, the creation of an application ecosystem and cross-platform syndication. Contributions in this field comprise ‘the economy of data intraoperability on Facebook and Google’ which analyses ‘the differences [original emphasis] in data strategies’ of Facebook and Google using APIs to integrate external services with their standards and to create data hubs with distinct data points (Bechmann 74-5). Gerlitz and Helmond particularly analysed Facebook´s economy of data flows made possible by the Facebook ‘Like’ Button that is organized via Facebook´s Open Graph API (Gerlitz and Helmond 2). Other critical work regards the changes in terms of use and their implications for third-party developers and users (such as researchers) (Lomborg and Bechmann 256; Bucher, Twitter API n. pag.). As Lomborg and Bechmann argue, APIs enable the exchange of data points. Hence an analysis of the API documentation allows to see which data are accumulated by an API (Lomborg and Bechmann 256). All of these approaches extrapolate APIs and study their architecture and functionalities in order to identify their ramifications for different stakeholders to which they are connected. While they do not work with the dichotomy of transparency and opacity, they implicitly describe power constellations stemming from the platform and API design, rendering some data transparent for some stakeholders while obfuscating other parts of data for others. They consider platforms and

(11)

APIs as socio-technological or socio-material assemblages, constructed to allow for normative and technologically restricted use of open communication channels, whilst the capture and opening of data serves commercial or other strategic ends. As Puschmann and Burgess demonstrate with their account on Twitter´s platform politics, such ends vary across the stakeholders and may fail to be brought into accordance with each other (Puschmann and Burgess 46-9).

1.2 Open data and APIs

This study proposes to deconstruct the narrative of SP API as a political panacea in a similar vein. To do so it is relevant to regard the data SP API renders open and transparent. But firstly it is necessary to understand the relationship between APIs and open data. Open Knowledge Foundation is a major promoter of open data. It distinguishes open data bulks, i.e. a whole set of open data from open data services based on APIs (James n. pag.). According to Open Knowledge Foundation open data is machine-readable data, free to use for commercial and non-commercial purposes. It must always be accessible as a bulk of data, i.e. a whole data set. Contrary APIs are interfaces which allow to access and interact with open data in manifold ways, for instance by integrating web services, programs or applications that use and interact with open data (James n. pag.).APIs may only contain a part of an open data bulk in order to utilize it in a specific context such as a mobile app (James n. pag.). This is what makes APIs potentially interesting for the further use of data sets. Every person who is able to write a software that integrates an API, can translate open data into data visualizations and applications. Thereby particular open data is put into a particular context

constructing a particular perspective. But it is not only important to look how APIs render open data accessible. Rather the data which are opened by an API need scrutiny themselves.

Rob Kitchin argues that the word ‘data’ is misleading since it does not represent a ‘given’ (data originates in the Latin word ‘datum’ which means given), but rather a deliberately captured aspect of reality that is ‘inherently partial, selective and representative’ (Kitchin 29). Instead of being mere facts, ‘[d]ata do not exist independently of the ideas, instruments, practices, contexts and knowledges used to generate, process and analyse them’ (Kitchin 29).

Similarly Gitelman and Jackson argue that data must be imagined before they can be expressed as data. The authors emphasize that a close-reading of such data conceptions may reveal the

(12)

Birchall´s concept of transparency-as-secrecy it is fair to argue that social actors may imagine, construct, collect and interpret data differently and that such interpretations bring certain aspects of reality in our field of view while obfuscating others. These thoughts are politically relevant.

Following authors like Rob Kitchin, Nikolas Rose, Marylin Strathern or Michael Power data are rhetorics rather than evidences that can be taken to engage with politics, to evaluate political processes and to audit and hold accountable organizations such as the state (Kitchin 32; Rose 673; Power, Counting 770; Strathern 1).

For Rose politics and numerical data stand in a symbiotic relationship. He argues that democratic political life depends on numerate and calculating citizens and a ‘numericized’ political sphere (Rose 691). Hence voting numbers gauge majorities and minorities attributing political legitimacy to power-holders while surveys and polls represent citizen feedback in relation to political programs. Numbers also facilitate to judge political programs, for instance measuring success of labour policies regarding unemployment statistics (674). In line with forgoing arguments of Kitchin Rose says that such numbers are forged in a central locale, i.e. centres of calculation with own politics of what to compile, compare and calculate (676). Power elucidates the importance of classification practices which allow to express phenomena as calculable quantitative data. He argues that such quanta reflect a moral imperative of objectivity that places confidence in auditing practices and performance measurements (Counting 766). Such an imaginary objectivity enables to evaluate, audit and legitimize or penalize actions and to foster trust in someone´s reliability

(Counting 770). However for Power trust in an auditee demands trust in the techniques of auditing (Power, Accounting 380). Thus he advocates for a critical reading of the classification schemes these performance measurements are based on in order to deconstruct their significance (Counting 778).

Open government data is an object of a somewhat similar dispute. Discussions ask for the politics and convictions crystallized in open data, the meanings they convey and the different ends to which they are published. President Obama´s Memorandum on Transparency and Open Government, released one day after his inauguration in January 2009, marked the birth of open data followed by the creation of the US open data repository data.gov (Pyrozhenko 2). The memorandum aimed at fostering transparency, public participation and collaboration (Pyrozhenko 2) and should end a culture of secrecy that characterized the preceding Bush administration (Birchall data.gov 185).

(13)

Successively David Cameron initiated the creation of the UK open data repository data.gov.uk and also the G8 signed up to an Open Data Charter in 2013 (Kin-sing Chan n. pag.). Similarly to the aforementioned initiatives the charter declares that governmental data has to be open by default thereby exporting the idea of open data to other nations (Kin-sing Chan n. pag.). Open data is controversially discussed and various agendas, problems and visions collide in it (Gray 4). Research endeavors regard for instance effects on local public participation (Worthy 1), political motivations of crowdsourcing innovation (Pyrozhenko 3), its empowering effects for elites (Gurstein n. pag.) or its potential risks of a neoliberalisation and marketisation of public services (Bates 389-391,394; Longo 41-42).

1.3 Data publics

A particular branch of research, namely the debate around data publics, is in line with concerns of Power, Kitchin or Gitelman and Jackson who all discuss the relational construction of data based on knowledge, data imaginations, measuring technologies etc. In its core data publics thematize a ‘post-social experience’ of the state through data representations (Ruppert, Transparent 10). Regarding the cases of the UK Transparency Agenda (Ruppert) and the US open data repository data.gov (Birchall) both authors argue that data representations are actively produced by an assemblage of different factors (Birchall, data.gov 186; Ruppert, Transparent 3). Those factors comprise data capture and storage technologies, data processing and visualization software, software developers, statisticians, data intermediaries (such as the content on data repositories), bureaucrats, politicians and end-users (Ruppert, Transparent 8). Birchall and Ruppert share the concern that data publics are an elitist phenomenon, where mainly experts like data scientists, software developers and journalists (Ruppert, Transparent 6) or more generally entrepreneurs (Birchall, data.gov 186) are able to cope with abundant and complex open data bulks to produce state representations. The political ramifications of such a process are interpreted differently by the authors. Ruppert argues that the manifold data representations of the state are influenced by the experts who create them (Transparent 7-9). This is why she claims to analyse the particular politics which are inscribed in such interpretations (Transparent 7-9). Birchall is more drastic saying that the mere provision of data replaces the obligation for politicians to get into dialogue with citizens. Instead political antagonisms would be replaced by pure provision of data that pre-empts political

(14)

communication (Data.gov 186-7). Hence data-driven transparency as promoted by data.gov would produce a highly delimited relationship between government and citizens (data.gov 187).

Both authors also thematize the role of citizens as auditors and discuss their potential to hold governments accountable (Birchall, data.gov 186; Ruppert, Transparent 3). Data publics are therefore problematizing how technologies to store, process and disseminate data, imaginations of data, human interpretation and political agendas create multiple data representations of the state for different stakeholders. To refer to Rose´s and Power´s foregoing concepts this implies a question of who can hold whom accountable for what by which means; hence it implies a reconfiguration of power relations.

Such a post-social relationship between citizen and state is implicit in the concept of SP API. The API promotes a transparent C2G2C-communication channel that aims at mediating political

communication in order to render civil issues and governmental responses visible. As a platform SP API is embedded in different technologies like municipal databases or web services developed by private software developers. Following Kitchin we may ask how SP API as a data capturing infrastructure contributes to a particular representation of municipal governments and shapes the way citizens can hold governments accountable. Analysing issue reporting systems from the perspective of data publics appears to be fruitful for several reasons. The data publics debates have been looking at open data repositories and analysed the implications on a macro-level. Thereby they posed general concerns about the creation of multiple perspectives on the state based on large data sets. However issue reporting systems offer a very specific set of actors, technologies and

organizations which allows for a specific analysis of one particular device, namely SP API. Secondly the technological and organizational assemblage around an API is different from a data repository opening a whole bulk of data. An API can have its very own politics inscribed in its design which influence the creation of data-driven state representations. Also issue reporting APIs like Open311, on which SP API is based, gain importance since they are increasingly installed in cities around the world (Open311 n. pag.). So far concerns of the data publics debate have not been applied to issue reporting systems like SP API. Research in the field has been focussing on API-design issues (Offenhuber) and data structures inscribed in the API (Nalchigar and Fox), on correlations between demographics and use frequency of issue reporting services (Cavallo, Lynch and Scull) or the correlation between trust, long-term civic engagement and the design of ICT

(15)

reporting tools correlate (Harding et al.). Taken these factors together, the study argues that a research of SP API, its technical functions and the socio-technological assemblage surrounding it offers fruitful insights in how a particular technology contributes to the creation of distinct data representations of the state, hence to the creation of new data publics.

This study strives to synthesize critical platform studies with critical data studies and concepts of data publics. It asks how a municipal issue-reporting platform based on SP API allows citizens to create certain types of data, how it thereby renders a certain reality of the city transparent and how this serves the interests of stakeholders differently. As it will be shown such stakeholders comprise citizens, civil servants, municipal departments and governments, API providers and software developers. Research question one asks for the technological capacities of SP API and the

municipal data infrastructures in which the API is embedded. Research question two asks how these factors contribute to establish data representations of the municipality and distributes power to single stakeholders of the platform. Thereby it is also analysed how SP API constructs new data

publics by distributing auditing roles between citizens and municipalities. The study strives to problematize the relationship between the technicity and infrastructural embeddedness of SP API and the forms of civic participation it allows for.

(16)

2 Methodology

The study roughly follows Bowker´s et al.´s concept of information infrastructures. This concept serves to understand SP API´s technicity, i.e. its technological functions, but also its embeddedness in a municipal information-infrastructure. Susan Leigh Star uses the term of embeddedness to describe that infrastructures are integrated in other social and technological arrangements. Bowker et al. argue in a same fashion that information infrastructures are relations between technological, institutional and social actors which are aligned in an

infrastructure (99). In order to analyse the embeddedness of SP API Bowker et al. propose an infrastructural inversion that depicts ‘infrastructure in the making“ (99). Infrastructural inversion is a methodology developed by Geoffrey Bowker that enables us to analyse how technical artefacts embody standards, how human beings adapt their behaviour to these standards and how agencies and relations are distributed (99). The leading question then is to analyse how work and organizational practices are distributed across humans, institutions and knowledge structures such as databases (102). This methodological framework is supplemented with concepts of data publics, critical data studies, sociology of numbers and sociology of knowledge but also critical platform studies. Emphasis is placed on Philip Agre´s capture model as well as the cybernetic concept of self-regulating systems. These two concepts are applied as frameworks to explain how SP API restructures the interaction between citizens and the municipality. A thorough description of both models as well as an explanation why they have been chosen as explanatory models follows in the respective chapters three and five.

In order to answer research question two a framework shall be employed drawing roughly on Evelyn Ruppert´s and Clare Birchall´s above-mentioned concepts and treats them as guidelines for the inquiry. The study asks how the data infrastructures around SP API and associated stakeholders create data representations of the state. In line with Evelyn Ruppert it asks how a socio-technological actor-network around SP API distributes capacities for various stakeholders to actively produce state representations. Thereby it analyses how these state representations distribute roles of auditor and auditee. Additionally the dichotomy of data subject and data object as superficially thematized by Clare Birchall will be regarded. At first glance the term data subject is underspecified and contains multiple meanings. The British Information Commissioner´s Office defines it as ‘the individual whom particular personal data

(17)

is about’ (IOC n. pag.). This governmental definition of a data subject corresponds with Birchall´s conception of a data object. She argues that data objects are humans acted upon by data, while data subjects act upon data (data.gov 193). This definition leads to another aspect of Birchall´s discussion on data subjects: the dichotomy of data provision and meaningful political response. Birchall´s distinction between provision and response plays a role in how power is distributed across data subject and object. She argues that political antagonisms would be replaced by pure provision of data that pre-empts political communication (data.gov 186-7). SP API promises to be a transparent channel between citizens and governments, where not only civic issues but also governmental responses become visible. By using Birchall´s ideas about data provision and political response the study may analyse if governmental responses or mere data provision becomes visible.

2.1 Empirical sources

Inspired by Taina Bucher´s approach of technography and Susan Leigh Star´s ethnography of infrastructures, different empirical sources are utilized to depict how SP API and its

neighbourhoods of relationship take shape (Bucher, Programmed Sociality 72; Star 385). The sources comprise API documentations and developer forums and status reports of technological implementation procedures. In order to describe city-internal issues around the implementation procedure and the organizational use of SP API, expert interviews with implementing parties (the project managers of Helsinki´s and Amsterdam´s SP API implementation have been interviewed) have been conducted (for full transcripts of the interviews see appendix 1). Also business literature theorizing the organizational and entrepreneurial implications of APIs for non-web-based companies was analysed (Baya, Gruman and Parker 8). While this branch of literature focuses on managerial issues, its explanations of the organizational impact gives useful insights about the organizational implications of APIs.

2.2 Chapter structure

Chapter 3 describes the technicity of SP API as a grammar of actions. It will be analysed how

(18)

comprehensive analysis of SP API and underlying database reveals how data can be queried, structured, analysed and classified. To answer this question the embeddedness of SP API and databases in municipal politics will be regarded. Different stakeholders and political decisions will be described that led to a particular design of SP API in relation to municipal databases.

Chapter 4 discusses the functional differences between SP API and a relational database.

Thereby it depicts how SP API can be understood as a means of inclusion and exclusion while the relational database is a device marked by inclusion and recombination of data. These tech-nological aspects will be complemented with a discussion about governmental classification practices which try to establish particular relationships between the citizen and the state. Finally it will be reflected how the technicity of SP API and municipal databases, together with a par-ticular transaction-based relationship between citizens and states can be conceptualized as a form of power. It shows how subjects are created by data classifications identifies two forms to express the relationship between state and citizen: the first one is based on the identity and the biological properties of an individual, while the second one is based on transactions between citizen and state. Chapter 5 describes how the C2G2C-communication of SP API can be grasped by using the principles of cybernetics. It thematizes how the C2G2C-communication can be envisioned as a self-regulating system based on an input-output cycle and a black-box. Using this analogy the chapter demonstrates that SP API creates transparency of some parts of the municipality and obfuscates other parts. The chapter will present the service request map and the Open311 dashboard and discuss what they render visible and how they are suggestive of a particular representation of the municipality. Then it turns towards the parts of the municipal-ity which remain opaque for citizens. It argues that this opacmunicipal-ity is relative and that the municip-ality gains some informational advantages using SP API. Chapter 6 offers a conclusion of the main findings in relation to the data publics debate and offers perspectives for future research.

(19)

3 The technicity of SP API

The following chapter describes the technicity of SP API as a grammar of actions. It will be analysed how SP API regulates the interaction between citizens, civil servants and municipal databases. The comprehensive analysis of SP API and underlying database reveals how data can be queried, structured, analysed and classified. To answer this question the embeddedness of SP API and databases in municipal politics will be regarded. Different stakeholders and political decisions will be described that led to a particular design of SP API in relation to municipal databases. The implications both for organizational and communicative structures are regarded later.The design of Helsinki´s Smart Participation API is the role model for the other member cities of CitySDK. Hence it firstly shall be scrutinized and later compared with the API versions of the other cities. Their categorisation practices shall be discussed in order to infer potential uses of these APIs.

3.1 Technicity of SP API and databases

SP API is an adaption of the public Open311 API (Helsinki loves developers n. pag.). Open311 is based on Representational State Transfer (short: REST). In a nutshell REST, like every API, is a set of constraints between computer systems, namely clients and servers. Cramer and Fuller argue that this characteristic makes APIs ‘tactical constraints of the total possible uses of hardware“ and ‘specialized machine[s], breaking the [hardware] down into a subset of itself“ (149). In less abstract terms it means that REST describes commands that two or more types of software can exercise in order to understand each other. These commands may also comprise organizational assets, capacities or data which shall be available and understandable for external users (Jacobson, Brail and Woods 5, 22). As Jacobson, Brail and Woods argue API structures can be read like a contract telling developers and other users which data and business capacities they can expect from an API, documented in the API specification (4-5).

When using REST APIs, the API host server (in our case the municipal database) sends representations of the data it contains while a client (every database-external software)

(20)

exchange representations of resources REST uses Hypertext Transfer Protocol (HTTP) (Jacobson, Brail and Woods 60). HTTP is the transportation standard for data across the internet, based on a request-response cycle between clients and servers (Zapier n. pag.). REST APIs govern how communication is exercised defining correct HTTP requests that the software on the hosting server of an API can understand (Zapier n. pag.). Two factors are important to understand how REST APIs and SP API in particular relate to municipal databases: the use of

distinct commands based on the building elements of HTTP and the fact that SP API is an open standard. SP API utilizes HTTP building elements (Richardson and Amundsen xxii) which

constitute above mentioned ‘tactical constraints’.

The study regards two of these factors especially interesting for the further analysis of SP API´s technicity: the object identifications (Uniform Resource Locator, or short: URL) and the HTTP methods. The URL can be regarded as a name that is given to data stored in a database. They can describe general resource classifications (SP API uses ‘services’ as a

resource classification) and a unique identifier (in our case ‘service_name’). Both URL patterns may allow for different actions. Resource classifications enable listing, data retrieval or the creation of a new resource while the unique resource ID may be appropriate for changes inside of a particular resource. Which data get assigned a URL is the decision of the API host

(Jacobson, Brail and Woods 28). In our case the municipalities participating in CitySDK are the API hosts and classify these URLs according to their public services. The distribution of URLs to database resources is a political decision that defines which data on a database are

addressable by an API (Richardson and Amundsen 3). The API host therefore is an important gatekeeper which regulates informational flows between a database and external software by assigning URLs.

Methods describe the actions that a client may address to resources stored on the APIs server (request verbs). Several verbs are possible but the following four are the most commonly used ones by REST APIs: GET (client asks server to retrieve the representation of a resource), POST (client asks server to create a new resource by sending a representation of it), PUT (client asks to edit a resource, sending a representation of the desired future state) and DELETE (client asks to remove a resource) (Richardson and Amundsen 33). Thus APIs potentially allow for a variety of interactions with a database like retrieving existing data, storing new data, or modifying and deleting them. In the case of SP API two interactions are possible between a

(21)

client and a server. Via GET a client may retrieve data points, and via POST, it can create new data points.

More specifically it enables the

1) ‘Listing of service request types [corresponding HTTP request: GET service list] 2) Submitting [of] service requests [corresponding HTTP request: POST service]

3) Querying [of] individual or multiple service requests and their descriptions and status [cor-responding HTTP requests: GET service definition, GET service requests and GET service request] (Helsinki Loves Developers n. pag.)

Hence SP API is not only a set of constraints breaking down a computer into its subsets. Through the attribution of URLs and HTTP methods the API also defines the relationship between citizen and municipality by classifying municipal services that are stored as data representations in a database. The API offers pre-defined issue categories, i.e. public service orders which define the possible modes of participation. The API therefore embodies a grammar of action.

3.2 SP API as a grammar of action

The concept of the grammars of action is part of Philip Agre´s model of capture and theorizes how human behaviour and work can be reordered using linguistic metaphors in order to make recordable by computer systems (746). To do so human activities are expressed in linguistic metaphors, which can be represented, stored and calculated upon by computers (744). An ontological analysis of work tasks into single tasks is necessary to define such linguistic metaphors. Afterwards these units are strung together to express a stretch of human activity (746). Linguistic metaphors may comprise manifold forms such as barcodes which indicate the number of products a cashier draws over a scanner in a given time (745). The point is that once expressed in a representational metaphor, a computer can store (i.e. capture) data about these activities which can be tracked and calculated upon (746). Grammars of action are an

(22)

ontological issue of how to describe single work processes in a machine-readable format, to which human behaviour must be adapted (754). The capture of an entity´s state is technically solved restructuring work flows and activities using ‘linguistic metaphors for human activities assimilating them to the constructs of a computer system´s representation languages’ (Agre 744-5). SP API embodies such a grammar of action for its URLs describe service categories which are linguistic metaphors representing a part of municipalities´ work processes. Together with HTTP methods these URLs define how a human may interact with the API in order to parse data that are related to these service categories on a database. As we will see in the following chapters this grammar of action is the key element for both the communication between citizens and municipalities (for it defines the possible interactions between citizen and municipality) and for the creation of open data. As shown below the grammar of actions also has implications for the functions of the interfaces which are integrated with SP API.

SP API is public, which means that it is available to external users with a restricted amount of contractual arrangements (Jacobson, Brail and Woods 7). In SP API´s case these arrangements are inscribed in the functions of SP API. SP API is written down in a documentation which is openly accessible to everybody but especially addressed to software developers. It shows the parameters a developer has to program into her/his software in order to address a database. The image below shows an excerpt of Helsinki´s API documentation and some parameters. As it will be described in chapter four, these parameters are metadata which contextualize a service request.

(23)

Figure 1: Excerpt of Helsinki´s SP API documentation.

The documentation renders visible the specifications a software has to contain and predefines the possible ways a software can interact with it. This is a major limitation for citizens using an API. Only those citizens, able to write a software will be able to address the API and to create an interface which makes the API actionable. Following Ruppert´s model of the data subject (consisting of the roles of auditor, consumer and entrepreneur) the use of open data APIs rein-forces power asymmetries between citizens who are technical lay persons (mere consumers of data) and software developers (entrepreneurs). Birchall argues that regular citizens do not dis-pose of the capacities necessary to make sense of the vast variety of open data. Only entrepren-eurs disposed of the technical and intellectual capacities to make sense of open data and trans-late it into a ‘digestible form’ such as apps that can be monetized (data.gov 190-1). Birchall´s conclusion is that the market economy would influence, which data are made accessible, and accountability would be ‘limited by the conditions of profitability’ (data.gov 191). There is a tight relationship between political and economic mechanisms surrounding SP API. CitySDK for instance has stimulated the development of apps built on SP API, announcing a competition

(24)

for the best cross-city issue reporting app. The winners could receive price of 5000 Euros (hanna n. pag.). CitySDK is directly guiding this innovation process by creating an interface with restricting functionalities and by allocating money to a winning developer. The API but in-novation processes are further guided by CitySDK attributing money to winning applications. Thus agency is distributed among developers, data visualization software and the political and economic relationship between developers who design adequate interfaces for SP API and the municipalities initiating such competitions.

3.3 Applications built on SP API

There are several applications built on SP API integrated in different services like websites of newspapers or built as stand-alone apps (Helsinki loves developers n. pag.). There are three general types of applications: the issue reporting app, the city map indicating issue reports and the dashboard. While there is no corresponding dashboard application built on top of SP API, in the USA such an interface exists for Open311 API, the underlying standard from which SP API is derived. This dashboard uses specifications which are similar to SP API (SP API uses the same HTTP methods and general classifications (service_name etc.) as Open311 does, but adds some other parameters as well). Therefore the study wants to discuss the possible use cases of this dashboard as well. In order to understand how a citizen may request a service the study will describe the issue reporting app Mobile Trouble Shooter that is built on SP API. Mobile

(25)

Figure 2: Image of the eight different functions of Mobile Trouble Shooter

The app is based on a geo-locating service which allows the app to be synchronized with the SP API implementation of Helsinki or Lamia. The ‘settings’ function (second image from left in the top row) is necessary to activate the geo-locating function of the web. Once activated users may geo-locate an issue. The ‘submit request’ function shows an interface that translates the API parameters into a visual graphic interface. These parameters comprise category (this corresponds to the URL services) and type (which is classified as ‘description’ in the API documentation) (Helsinki loves developers n. pag.). Users may also describe the issue and add an image as well as their name. After the issue has been sent the details of these issues

(description, location, status of an issue etc.) can be seen in the ‘request details’.

So far it shall suffice to say that the app basically translates the API functions into a more user-friendly interface. The underlying API parameters that correspond to the app

functions will be discussed in the following paragraphs. It is useful to refer to Philip Agre once again. As he argues the capture of an entity´s state is technically solved restructuring work flows and activities using ‘linguistic metaphors for human activities assimilating them to the constructs of a computer system´s representation languages’ (Agre 744-5). The Mobile Trouble Shooter app offers commands like select a category, choose a name indicator, provide

(26)

description etc. (Niemi-Hugaerts 9). The activities of a user are guided and predefined by the app and thereby made ready to be stored in a computer system. At the same time the app gives users a certain freedom inside of the grammar of action. In the case of SP API citizens have a free choice when and where they report as well as what to report. This adds the distinct value to the issue reporting app since it allows to flexibly gather data about service requests which are for instance used to coordinate municipal work (a detailed description follows in chapter XY).

3.4 SP API as an open standard

SP API is based on the open API standard Open311. An open standard is a common API framework templatizing the use of APIs (Srivastava et al. 54). Open standards are easy to adopt and increase interoperability with databases using it. The reason for this is that open standards offer the general data structure (see above) in which unique identifiers for database resources can be integrated (Srivastava et al. 54). The use of a general data structure also allows to write apps which are applicable for different SP API implementations in different cities based on this common framework (Open311, n. pag.; Srivastava et al. 54). Helsinki offered such a template with its lead implementation. Amsterdam, Lamia, Lissabon and Barcelona adopted the

framework (Niemi-Hugaerts 7). Yet the cities used different unique identifiers for their services based on the cities´ internal work structures (Helsinki loves developers n. pag.; Hof, Interview 8 May 2015). This means that two municipal APIs may use the common URL ‘service_names’, while both municipalities may add different URL endings to this function. So for instance Helsinki calls a service ‘greenery’ while Amsterdam may subdivided it into services like ‘tree pruning’ or fallen trees. When apps are used across different cities they access the API function ‘service_names’ and automatically retrieve customized results per city (Hof, Interview 8 May 2015).

The design of this open standard was object of dispute among the participating cities as an interview with Jaakko Rajaniemi, the responsible person for the implementation of SP API in Helsinki, and other project protocols show. Helsinki promoted to design SP API in a same fashion as Open311, partly because this open standard is easy to integrate with other municipal databases and their classification patterns (Rajaniemi Interview 29 March 2015). According to Jaakko Rajaniemi another reason was the engagement of Helsinki´s public works department

(27)

which was involved in the design process from the beginning, collaborating with the designers of SP API to implement it in their databases. The interests of Helsinki´s Public Works

Department played a role in shaping the lead SP API. And thirdly SP API mainly focuses on public works because it is a generally shared responsibility of municipalities across cities (Rajaniemi, Interview 29 March 2015). Lamia proposed a different API-concept which did not gain traction by the other municipalities. In a written report on the design process of SP API, Lamia´s municipal staff suggested to integrate a crowdsourcing function in SP API with which citizens could propose topics for polls or surveys (Farmakis 8). Jaakko Rajaniemi says that these functions have been considered beneficial for Helsinki, but argues that such a technology affords a complex restructuring of municipal work processes. Here one can see once again Agre´s concerns about the ontological problems of grammatizing human behaviour with adequate linguistic metaphors. Rajaniemi says that teaching civil servants to work with the feedback system and to send responses is the main issue when implementing SP API

(Rajaniemi, Interview 29 March 2015). In Agre´s terms the difficulties of ‘imposition’ (746) of a grammar of action can explain why the city of Helsinki focussed on integrating issues which are easy to respond to.

The following analysis is based on requests for service lists of the single APIs (see appendix 2). These requests have been made using the URL of the service lists as documented by the API and displaying the results in a browser. SP API displays public sector services, namely public works. This was the initial idea of the lead project enabling citizens to send service requests to the municipality which are handled by Helsinki´s Public Works Department (Helsinki Loves Developers n. pag.). The other cities followed Helsinki´s lead and classified issues according to their public works. While Helsinki´s SP API focuses on maintenance of public properties, Amsterdam´s and Lamia´s versions also contain the removal of different obstacles on streets and public places that are relevant for their cities (such as bike staples in Amsterdam) or include specific issues like odor/noise nuisance. Generally the services comprise maintenance of green spaces, infrastructure, municipal real estates, but may also contain categories like vandalism or graffiti removal.

SP API can be regarded as a representation of the cities´ structures of public works departments, but also as a representation of how public works are classified. Manchester and

(28)

Rome largely modified SP API (Niemi-Hugaerts 19-24). Manchester used the API to enable enterprises accessing municipal council services more easily. Rome employed the API in order to create a platform for citizens to post and retrieve job offers in the Province of Rome (Niemi-Hugaerts 19-24). All these issues relate to public sector responsibilities or reflect economic development strategies (as in the case of Manchester and Rome).

So far it can be concluded that all SP APIs relate to services specific for municipal departments. They either express municipal responsibilities of maintaining city infrastructure or they employ it as a platform to coordinate the relationships between economic actors (Rome´s job market) or enterprises and municipalities (Manchester). These categories define civic participation as mere transactions between citizens and public services or imply an economic agenda. The C2G2C-communication channel is already highly delimited by the issue categories (public works ser-vices) it renders transparent.

SP API formulates work tasks as linguistic metaphors which are the grammar of actions for app developers (they translate these linguistic metaphors into visual interfaces) and app users/citizens (they can flexibly interact with a predefined range of actions). As the next chapter will show the grammar of actions is important to increase interoperability between an app, the API and the underlying database. It will be shown that the grammar of actions used by SP API correlates with practices of database management. Hence the grammar of actions allows for technological interoperability across apps (which serve as capturing tools when using a gram-mar of actions), APIs and databases (which store the captured data). But also the gramgram-mar of actions has implications for labour processes of public works departments. This means that the grammar of actions also harmonizes the activities of citizens (who send service requests) and civil servants (who work based on these requests). Therefore the grammar of actions is the fun-damental element of the C2G2C-communication between citizens and public works depart-ments.

(29)

4 APIs and databases as devices of power

The next chapter problematizes the transactional relationship as a particular mode of power. Firstly it discusses the functional differences between SP API and a relational database. Thereby it depicts how SP API is a means of inclusion and exclusion while the relational data-base is a device marked by inclusion and recombination of data. These technological aspects will be complemented with a discussion about governmental classification practices which try to establish particular relationships between the citizen and the state. Finally it will be reflected how the technicity of SP API and municipal databases, together with a particular transac-tion-based relationship between citizens and states can be conceptualized as a form of power tied to a particular knowledge about the population.

4.1 How SP API relates to databases through relational data

SP API structures the results of a GET query and the submission of service requests in a hier-archical relationship. To do so it employs the data structures Java Script Object Notation (JSON) and Extensible Markup Language (XML) (Capiello et al. 15; Richardson, Amundsen 29-32). Both styles represent data in a hierarchy that organizes them for purposes of computa-tion (Cioffi-Revilla 60-2). JSON is based on objects to which keys (object´s attributes) and val-ues (description of attributes) are assigned (Zapier n. pag.). XML is a data model based on

nodes (similar to JSON´s objects) that are divided into child nodes which contain both a name

(attribute of the main node) and data descriptions (Zapier n. pag.). Below we can see an excerpt of a GET query that shows a comprehensive service list. This list can then be displayed in an app as described in the foregoing chapter. The service list was retrieved by typing the corres-ponding URL1_{in a browser. This service list is contained in Helsinki´s API implementation. For}

better readability the list was retrieved in the data structure XML.

(30)

<service_code>172</service_code>

<service_name>Vandalism</service_name> <description>

Give feedback if you find that property or equipment is broken. </description>

<metadata>false</metadata> <type>realtime</type>

<keywords> bench, parks, trashbins</keywords> <group>sanitation</group>

</service>

Figure 3: Excerpt of a GET service list query, retrieved in XML

We can see that this URL contains data which are clustered in a hierarchical relationship. All services relate to the overall classification ‘services’ and each single service has attributes such as service_code to which a value is assigned (in this example ‘172’). The attributes are clustered in a parenthetical form arranged from top to bottom and contain values in between them (in XML ‘service_code’ and ‘/service_code’ form a parenthetical attribute in which a value such as ‘172’ is nested). The services also have a human-readable service name (‘vandalism’), a

description and other metadata such as keywords which relate to the service.

Data structures like JSON and XML resemble old forms of structuring knowledge by arranging and categorising data in tables consisting of columns and rows (Goody, Table 53). Tables are '[a]n arrangement of [...] items of any kind, in a definite and compact form, so as to exhibit some set of facts, or relations in a distinct and comprehensive way, for convenience of study, reference, or calculation.’ (Goody, Table 54). Tables cluster concrete phenomena into discrete

(31)

classifications whose elements may be associated to each other, hierarchically or not (Goody Table 55-8). The same applies to JSON and XML: both data models structure certain attributes in columns to which values are assigned in rows. SP API specifies addressable data in a

hierarchical table of resources.

Thereby SP API describes relations between quantitative and qualitative data that are stored on municipal databases. Quantitative data may be numeric measurements of physical properties or representative descriptions of non-physical phenomena (Kitchin 29). They are structured, ‘easily storable, and transferred in a defined data model’ (Kitchin 33) such as tables or relational databases. This makes quantitative data easy to query, process, combine and analyse (Kitchin 33). SP API allows to relate quantitative data to service requests. These data comprise numerical metrics such as date, time and location (longitude/latitude) of a service request. Furthermore SP API also associates qualitative data to these requests. Qualitative data comprise unstructured text descriptions and photos of issues. We can see that the relational data described by XML or JSON correlate to the functions of Mobile Trouble Shooter app. The app is a visual interface that translates the relational data, inscribed in a hierarchical data model such as XML or JSON, into a human readable application. At the same time these data models correlate to the data structures of municipal databases (as described below in detail). Together with URLs and HTTP methods SP API is able to query municipal databases for single or multiple service requests according to their location, date and status (handled or not). How these data can be rendered into representations of the state is object of chapter five.

Cities participating in CitySDK use relational databases such as CKAN (Hof, Interview 8 May 2015) which contain the data resources SP API can address. CKAN is an open source data repository which was initially designed by Open Knowledge Foundation (CKAN n. pag.). Relational databases contain structured datasets clustered in tuples (rows of categories) and attributes (values of these categories) (Mackenzie 225). A tuple is a particular data structure arranged in a 2-dimensional spreadsheet (Cioffi-Revilla 60-2). Here one sees the structural resemblance of SP API employing tables to structure addressable data and the relational

database, consisting of spreadsheet-like tuples or tables (Mackenzie, databases 339). Relational databases employ data relations and Structured Query Language (SQL) to query and reorganize structured data in ever new ways (Mackenzie, Set 225). Drawing on Alain Badiou´s

(32)

mathematics of set theory Mackenzie further argues that relational databases can associate data in ever new relations (database 339-40). As it was shown above SP API retrieves data in certain relations to each other (issue categories, related to location and time for instance). One point is particularly interesting in these regards: the difference of belonging and inclusion in a dataset. As Mackenzie argues openness is the modus operandum of relational databases: they create new relations and allow to integrate new data (database 342). He distinguishes between data that belong to a database (elements) and data which are exchangeable (parts). In set theory, elements belong to sets, hence they are not changeable while parts, i.e. subsets like data and its relation to other data, can be included. Elements are fixated and parts variable. Mackenzie argues that the dichotomy between elements, that belong to sets and parts that are included in sets, is of major importance to understand how databases enact the creation of multiple data representations. For him it is less a question of which data belong to databases but the way they are included in databases to infer new relations from them. As he states: ‘no one belongs to a database as an element, but many aspects of contemporary lives are included as parts of database ‘ (databases 342) to infer ever new relationships. Hence databases are epistemic devices which are highly relational and inclusive. This is in line with other studies on databases and datasets arguing that datasets are not designed to represent ontological completeness but to detect viable and relevant relations between exchangeable data items (Amoore 27f.). Databases, their data relations and the relations across databases are therefore relative. In the case of joining databases data can be related to each other if a unifying factor can be found to which different data can be related.

So while the API can only address data resources in a limited way, the databases themselves are expandable and render ever-new data relations possible. SP API allows to retrieve a predefined set of relations. This set of relations can be modified by database-external software or by cross-relating these relations with other databases inside the municipality. SP API functions as a device of inclusion and exclusion of data relations while relational databases, gain their functions through inclusion and recombination of data relations. This has important

ramifications for our understanding of the data publics brought into being. The API represents a fixated set of transactions between citizens and civil servants thereby firmly assigning roles to both. Contrary a database may accumulate not only ever more relational data as inscribed in this

(33)

fixated API framework but it can also be expanded merging its data with data from other relational databases. The API creates a particular image of the city but the underlying municipal databases may recombine these data in different ways. This causes a potential information asymmetry between citizens, civil servants and municipal authorities, meaning that the input in the API (service requests) and the output (service responses) are rendered transparent, but not the further use of such data inside of the municipality. This information asymmetry will be explained in chapter five.

The next chapter describes the connection between practices of inclusion and exclusion in relation to citizens and municipality. It discusses how citizens and the state may relate to each other through data classifications the state and the individual can identify with. The chapter also shows how subjects are created by data classifications. It identifies two forms to express the relationship between state and citizen: the first one is based on the identity and the biological properties of an individual, while the second one is based on transactions between citizen and state. Then it relates these discussions to different modes of governmentality inscribed in the use of SP API and relational databases.

4.2 Classifications: how citizen and state relate to each other

Classification schemes are important for states to govern populations. Foucault described the relationship between state and individual as biopolitics. The state applies biopolitics to gain ‘power over life’ (i.e. biopower) by categorizing a population according to phenomena which are imagined as being characteristic for a population (Foucault, Ethics 73; Foucault, Society 135). The goal of categorization is to manage individuals at the scale of populations and to solve problems of governance related to a population (Foucault, Ethics 73; Foucault, Society 135). Ruppert specifies classification techniques and discusses censuses. Census classifications rely on ‘conventions of equivalence‘ (Ruppert, Category 39) so that diverse qualitative data can be encoded, classified and made object of statistical calculation (Ruppert, Category 39; Rose, Governing 675). Ruppert argues that statistical classifications of populations, as being used in censuses, ‘engage subjects in both the confirmation and creation of identification categories’ (Ruppert, Category 38). Census categories both objectify a population (express its

(34)

characterist-ics in parameters) and subjectify it (subjects identify with such categories) (Ruppert, Category 38). Before people are able to meaningfully fill out polls or surveys they have to identify with (i.e. subjectify to) the categories assigned to them (Ruppert, Category 39). Studies in line with this argumentation emphasize that the formulation of statistical categories always intervenes in the creation of the social, and that it, once normalized, can be utilized to administer and shape social development or political objects (Espeland and Stevens, Quantification 405). Classifica-tions are not only created by governments but can also be an expression of self-identification of populations or a tool for political recognition. Espeland and Stevens argue that the social move-ment of salaried executives in France only gained political weight to negotiate labour rights after the population parameter ‘cadre’ (engl.: salaried executives) was integrated into French na-tional statistics (Quantification 413).

Objectification and subjectification express a relationship between governments and people based on the recognition of population classifications. Arguably SP API employs such a double-identification, namely the objectification of citizens to public service categories; and the subjec-tification, that is the identification of citizens with this category. While Ruppert argues that sub-jectification occurs when a subject identifies personal characteristics with pre-defined census categories (Category 39) her concept is applicable to SP API because individuals have to identi-fy with an issue, i.e. understand and see the urge of using an issue reporting app before she/he can use an issue reporting app meaningfully. The SP API in these regards is a computerized method of managing bureaucratic information processes similar to the census or other govern-mental polls classifying people in order to make them visible and manageable. Since it affords that users adapt their behaviour towards linguistic metaphors, i.e. representations of public ser-vice structures, SP API can also be seen as a process in which citizens are subjectified and ob-jectified.

However, in order to understand which types of data-representations of the state are cre-ated when using SP API it is helpful to regard another classification practice which relates cit-izens and states according to the transactions that occur between them. Public service statistics are based on a classification of transactions between state and citizen. Those classifications may express a relationship between populations and the public services they make use of. For in-stance the state can relate to its population by evaluating the number of pupils finishing school

(35)

with a particular grade. The state may use these numbers as a measurement of educational suc-cess (Quantification 412).

These statistics, so Espeland and Stevens, are based on a commensurating practice, meaning that pupils´ performance is made comparable in a shared metric (grades) in order to manage their performance from the distance (Quantification 409-13). ‘Commensuration trans-forms qualities into quantities, difference into magnitude’ by measuring characteristics which are normally represented by different units with a common metric such as price or cost-benefit ratios (Espeland and Stevens, Commensuration 316). Once commensurated the performance of pupils and can be utilized to intervene in the educational system for instance by adjusting finan-cial aid to the educational sector (Quantification 412). Such a commensurated classification is in their point of view a bureaucratic system to regulate complexity at a distance and can have multiple uses, ranging from political intervention to legitimization of political actions (Quanti-fication 410-1).

Hence reforms of the state, for instance in the educational system are also based on eval-uation of public service statistics (Espeland and Stevens, Quantification 412). Here we can see in some ways a blend of the numericized democratic practices as propose d by Rose (see intro-duction) and classifications. By commensurating and aggregating classifications which are re-lated to numbering practices the state may evaluate its citizens and its own functions. However also social movements or citizens may make use of classifications and commensuration.

As it was shown classification practices are not always depending on objectivation and subjectivation initiated by the state. Rather such categorizations may be employed to claim political and social recognition (as explained in the account of Espeland and Stevens), or to hold the state accountable by commensurating different phenomena. An article by Bruno, Didier and Vitale champions statactivism, i.e. the mobilization of statistics for social movements. While these authors acknowledge that statistics and governmental classifications are a means of gov-ernance they repurpose these very statistics, creating new relations between data which reveal the state´s internal contradictions (203). Their account shows how statistical classifications can be used by groups of people in order to champion their agendas or to forge a collective identify which gives them political weight (209). Such interventions may be regarded to produce data subjects, if we follow the definition of data subjects that is proposed by this study. This means that interventions like statactivism are forms of reappropriating procedures or data creation and

No automation without representation - How issue reporting systems (do not) change urban politics