1. Becoming-resource: An introduction
As we enter a third decade of popular reckoning with the idea of networked computation, any notion of a divide between the physical and the virtual is proving less and less tenable with every passing day. Slowly at first, but with increasing momentum, the ordinary things and places that have constituted the cities around us since there were such things as cities are identifying themselves to the global informatic network, or being identified to it.
Real-world objects and arrangements of objects; structures and locations; events and situations: all of these are acquiring representations in the virtual space of the network.
As yet, by far the greater number of these representations are passive — descriptions, really. These descriptions leave the objects in question only the most limited ability to take account of one another, adapt to the circumstances of use, or otherwise respond to evolving conditions.
But it doesn’t need to end there, and oughtn’t. The networked city will only come into its own once it’s been reconceived as a framework of active resources, each endowed with some kind of structured, machine-readable presence and the possibilities for interaction this leads to.
What kinds of interaction? We can learn things from them. We can learn things about them. We can tell them to do things. Considered as a manifold of such resources, the city becomes a vast, active livable information surface.
At the moment, this is admittedly happening in a haphazard way, and only for certain classes of interesting things. Traffic cameras were some of the very first pieces of municipal infrastructure to show up on the Internet, as far back as the mid-1990s; networked meteorological stations have been around about as long. Metropolitan transit systems generally make their routes and timetables available online, very occasionally even the real-time dispositions of their fleets. Restaurant locations and opening hours are frequently available; increasingly, their health and cleanliness ratings are as well, though almost never in the same place.
Hundreds of thousands, if not millions, of real-world places have already been provisioned with handles letting the users of one or another social-networking service “check in” there: useful when we’re interested to know who is at that location right now, or at least in the very recent past, who has been there historically and who is there most often.
Some familiar structures have been granted the ability to speak to us through channels we’re already listening on, the first that we are aware of London’s Tower Bridge, endowed by designer Tom Armitage with its own Twitter account since 2008. Though not every piece of municipal infrastructure is going to be able to take advantage of such clever hacks, Tower Bridge’s twitterances surpass machine-readability in favor of the directly human, even the polite (“I am opening for the Stavros S Niarchos, which is passing upstream”).
Other objects in the landscape speak, but in a way that currently requires a greater effort at translation. The world’s cities are host to emplaced, communicating sensors in the greatest possible profusion: sensors for air quality and light level, sensors for motion and noise level, sensors for temperature and sensors for weight.
Occasionally, it’s even possible to connect with active elements of faraway streetscapes and make things happen from a distance. Around the world, a handful of cameras and gates, fountains and media façades — dynamic, building-scale display surfaces — have network addresses accessible to the public and are in some way programmable remotely.
All of these developments, consciously or otherwise, are attempts to translate the conventional urban fabric into an ensemble of resources available for network use — and ultimately, therefore, our own use. These initial steps are of necessity clumsy, incomplete and inconsistent, bound to lead to redundancy and the duplication of effort, but they clearly point the way toward a time in which urban environments around the world have been reimagined as supple, responsive ensembles of network-accessible functionality.
What stands in the way of this ambition? Consider a single dimension of the challenge described above, the characterization of place. A profusion of incompatible formats has blossomed as proprietary services, jockeying to be the sovereign lens through which the world is seen, each stake their claim to characterize urban places. The San Francisco dive bar Zeitgeist, for example, simultaneously shows up to the network as a “venue” on the location-sharing service Foursquare, a Place on Facebook and as a Google Place page.
Search for Zeitgeist, and what do you get? Maps of its location, pictures of its exterior and interior, reviews from Yelp! or Zagat or Citysearch. Google even offers ostensibly helpful “service” and “value” infographics, though by precisely by who these qualities have been judged, or against what metric they were calibrated, is unclear. But none of these things are moored to the place itself in any meaningful way. None of the comments on these pages feed into Zeitgeist’s own webpage, few are aggregated or otherwise taken note of by anyone other than the people looking at the particular service they were left on, and there is no way to poll any of them for qualities that might be salient to one’s experience of the bar.
And although it’s worth asking whether these discontinuities and heterogeneities can themselves give rise to interesting effects — are some destinations popular on Foursquare, for example, but not on its competitor Gowalla? — the lack of some stable, consistent way of describing and referring to places, or of distinguishing between an enterprise, its geographic location and the structure in which it is housed, is hampering the emergence of genuinely useful services.
If the existence of these dueling formats for the characterization of a business establishment is problematic, at least there are such formats in wide deployment, and people using them. It would be hard to argue the same of networked urban objects and their attributes, for which there remain no commonly accepted schemas of representation, no useful service-discovery protocols, and little in the way of relevant zero-configuration networking standards.
Consider setting out, here at the beginning of 2011, in an attempt to learn something useful from contemporary street furniture. Imagine that you wanted to create a real-time map of all the bike racks in a given neighborhood, and whether or not they were currently occupied. Or that you wanted to write a simple script that would notify you when a bike rack located within fifty meters of your present position became available.
If you were interested in yoking these devices, any data they might generate and their instructions into some kind of relationship with one another, you couldn’t. As yet, very few of the networked things we encounter in the street have been endowed with the capacity to share the data they generate in a format useful to anything else.
Still fewer accept instructions from afar, from anyone other than their owner — maybe the occasional soft-drink vending machine, Webcam or media façade, and these mostly commercial gimmicks. If the discrete components of the built environment are taking the most tentative steps toward speaking with us, their human users, they’ve only rarely been trained to speak with each other, to take account of and respond to conditions other objects might make them aware of, either in real-time or at all.
By contrast, what if there were commonly accepted schemas that would account for interactions between humans and networked objects, between one such object and another? In fact, better yet: what if all of that had been accomplished and then went away — evaporating from ordinary consciousness, as is the way of technologies once they’ve become well assimilated?
What would it mean to think of a city as a dense mesh of active, communicating objects — each one able to gather information from the environment around it, routinely share that information with other objects as well as human users, even act upon it where appropriate? And if we can treat the things we encounter in urban environments as system resources, rather than a mute collection of disarticulated buildings, vehicles, sewers and sidewalks, what might we do with them?
The possibilities are as varied and engaging as the number of urban places on Earth. Some are, to be sure, of the type that generally only prove exciting to bean-counters, the stuff of enhanced throughput and optimal resource utilization efficiency. Others are trivial things, really, interventions that will at best make bourgeois lives more comfortable still. But some speak directly to some of our oldest, deepest and most dearly held aspirations for the places in which we live and the selves we can become in them. And all become possible the moment the physical spaces and services we recognize as the lineaments of a city are first fused in a reasonably continuous fabric of computational awareness and response.
At the drier end of the spectrum of possibility is the prospect of letting each connected resource report on its own current status. For infrastructural elements like traffic signals, street lights and bus shelters, information about breakdowns and failures would propagate not merely to other objects on the network — permitting the entire ensemble to flex in adaptive response — but reach citizens as well, in terms they can relate to, understand and base their own plans on. Municipalities and their maintenance departments would be in a position to realize significant efficiencies in terms of improved oversight, reduced wastage and more timely repairs, and those reliant on uptime would be buffered against at least some of the hassle bound up in a default.
We would compelled to recognize an entirely new class of nonhuman urban actors. Of course, there’s nothing new about the idea that things might act, and instigate the acts of others. But it will be far harder to deny things agency when they speak: drawbridges and railroad crossings, storage lockers and bike racks, each able to say when they’re open and when they’re closed, when they’re available and when they aren’t. When widely deployed, such signalling would transform our places into on-demand cities that make the maximum use of otherwise underutilized facilities, and otherwise wrest the most from existing capacity.
For amenities no less than utilities, such reporting would mean a tighter and more useful coupling between demand and available supply: incredibly finely-grained, near-realtime reads on the state of a city and the events unfolding there. Not merely, in other words, to report on restaurants are open right now within walking distance, but whether or not each currently has tables available; not merely where a vehicle-charging station is, but how long the current waits are.
More urgently, we could bind together existing transportation networks, vehicles and infrastructures in a vastly more flexible meta-network of transmobility services, extending more regular coverage to more of the surface area (and volume) of a city, extending access to the many now underserved by existing transit provisions, and transforming notions of the “right to the city” from rhetoric to reality.
Drawing the torrential volumes of data provided by networked resources into appropriately designed visualizations will endow each of us with new powers of visibility — an endowment that amounts to nothing less than an extension of the human sensorium, rendering much of the world around us effectively transparent to inquiry.
We will come to such a vastly improved understanding of the places we live and the processes unfolding all around us that we will wonder how we ever managed to get by before. Such improved situational awareness will, among other benefits, act to sharply reduce or mitigate the fear that keeps so many from fully embracing the life available to them, allowing the broader community in turn to benefit from the energy and talent they have heretofore been unable to bring to the table.
The great ambition inscribed in all of these projects is to make cities more perfectly responsive to the needs of all their users, temporary as well as permanent, visitors as well as residents. It means leveraging the power of networked information processing to enable a lighter, more supple and responsive, even a playful way of interacting with the metropolitan manifold.
2. Developing for city-as-platform
Before any significant progress toward these aims is possible, it will be necessary to account for details of a highly technical, even an arcane nature. It may seem strange to couple soaring humanist rhetoric with talk of structured data, object models, zero-configuration networking, and so on. But the argument we are making is that top-level behavior — outcomes at the level of lives, experiences and memories — will ultimately depend critically on the design and granular behavior of artifacts far deeper in the urban “stack.”
It isn’t so much that that our choices will be determined by these things. But they will surely be conditioned. Our ability to use the city around us, our flexibility in doing so, just who is able to do so, will be shaped by decisions made about the technical design of objects, their interfaces and the precise ways in which they are connected and made visible to the network.
In the past, the parties responsible for developing technical definitions and standards of this sort have generally self-selected from a population with both a philosophical belief regarding the importance of a topic in software engineering, and the domain knowledge to do something about it. In practice, this has by and large meant working groups of developers acting under the auspices of the World Wide Web Consortium (W3C), the Institute of Electrical and Electronics Engineers (IEEE), or another standards body sufficiently large and influential to compel acquiescence with its dictates.
And this is all right because there has tended to remain a certain homogeneity between the disciplinary background and daily work of these volunteers and the things they’re attempting to represent. There is, after all, but a single Document Object Model. The working group responsible for developing such a thing is either going to consist outright of information architects and other specialists in document structure and ontology, or have reliable access to same. And while we would never suggest it was without complication, their task was made significantly easier as a consequence of the close conceptual, institutional and practical relationships between those producing the definition (software engineers), those making practical use of it (manufacturers of Web browsers) and the thing being defined (a template necessary to the consistent rendering of Web documents).
But here we clearly face a complication. Whatever working group eventually undertakes the task of producing technical standards for networked cities, they will have to come to some understanding regarding not merely the definition, but the meaning, of all sorts of urban artifacts and potential resources: subway stations and billboards, sewer drains and bollards, planters and tunnels.
Collectively, they will have to be at least as familiar with the work of Jane Jacobs, Jan Gehl and Holly Whyte as they are with that of Vint Cerf or Eric Raymond. They will need to understand the use, interpretation and resonance of sidewalks, walls, structures, and doors — and will have to understand that a door in Guangzhou implies subtly different things from its physically identical counterpart on Michigan Avenue. They will, in a word, need to be far more interdisciplinary in their composition than the equivalent groups producing definitions for the Web.
3. Born to be open
You will have gathered by now that we believe that the design of object models, APIs and other such specifications to be an inherently political act. Decisions made about the types of data provided, the degree to which such data can be modified by users, and the scope of access they are afforded will have an enormous impact on the ways in which a given networked artifact and all the services drawing upon it can be used downstream.
A precondition for the optimal use of the framework we’ve been describing isn’t a technical provision so much as a philosophical one. It is that the resources and systems of resources we wish to bring into being be designed so that they are open at every level, in the sense of that word used by software developers. That is to say, they consist materially of open platforms, and in the information they share, of open data.
What possible benefit could be derived from thinking this way, from building our strategies of placemaking around resources that are so nakedly available to all? There are at least four benefits to be derived from an open stance, two of the which flow from open access to data, and the balance of which depend on open platforms:
The primary advantage of open data in this context is that it resists attempts to concentrate power by leveraging asymmetries of information and differentials of access. If one has this data set, then all do.
We might more rigorously define the desiderata here as ensuring that the goods produced by data-collection resources are both nonrivalrous (i.e. my use of the resource doesn’t preclude your use, or any other) and nonexcludable (there’s no way to restrict the benefits produced by the resource to paid users). The trouble is, of course, that many digital offerings have turned out to be eminently excludable; it has proven to be depressingly easy to move services like WiFi from the unhindered access many of us once thought of as their natural state back toward locked, paid-access models. So, like other classes of things we perceive to be public goods, we need to both design networked urban resources so they reflect this understanding, and wherever possible, inscribe it in law.
Nor is it premature to begin doing so now. Despite the stutter-step and scattered adoption of networked technologies, we have clearly already gotten to the point where analysis of our actions generates value for others in the course of everyday urban activities. If anything, parties other than ourselves are currently better set up to derive meaningful value from parsing such data than we are.
Consider the situation related to us during a recent visit to Brisbane, Australia, in which the data collected by regional transit authority TransLink regarding use of local bus shelters — data, in other words, that reflected the daily decisions of tens of thousands of people — was recently licensed to an advertising agency under the terms of an exclusive, ten-year contract. TransLink presumably derived some revenue from this arrangement, but the very people whose actions produced something worth licensing were essentially excluded from direct benefit.
More pointedly, consider the analytic products and services for “digital out-of-home” advertising offered by the French concern Quividi, whose name is Latin for “he who has seen.” Their proposition is based on the inclusion, in the mounting frame of a dynamic display billboard, of a subtly concealed networked camera.
This camera captures images of passersby as they drift before the display, and applies a suite of analytics called VidiReports to the footage it garners. Quividi claims that VidiReports can discern audience demographics (gender; age, from four bands; and ethnic composition, derived from known indices of facial structure) and most relevantly whether or not people in these demographic categories appear to be paying attention to the content being displayed. (The attention metric is apparently derived from a characteristic index of reflectivity on the eyeballs of those actually watching the screen, and includes a “glance counter.”)
The value of such analysis to both existing and prospective advertisers is obvious and significant. Often, as in the case of this and other similarly inobtrusive data-collection devices, we will generate this value by simply passing by, even if we pay no attention to that which is being displayed — for a negative response is still a valid and useful data point. And given the extreme subtlety of the billboard camera’s design, and in fact the great pains the designers have gone to in order to render it inobtrusive, we will do so whether we know we are doing it or not.
That this kind of arrangement persists on private property may or may not be acceptable, in the long run. But we believe that it is absolutely intolerable in public space. Only a sustained and meaningful commitment to open data access will allow the greatest possible number to share in the benefit derived from what are, after all, their own activities.
4. Defining public objects
Coming to terms with the fact that a very wide range of everyday objects and surfaces in our cities will be capable of gathering and transmitting information — very often with neither our consent nor even necessarily our awareness — will not be easy, psychologically or jurisprudentially. It will require, among other adaptations, a new way of conceiving of the things we encounter in public space.
What is a “public object”? The outward-facing surfaces of buildings. Sidewalks. Parking meters, lamp standards, bus stops and newsstands. Municipal vehicles. Any artifact located in or bounding upon public rights-of-way. Any discrete object in the common spatial domain, intended for the use and enjoyment of the general public. Any discrete object which is de facto shared by and accessible to the public, regardless of its ownership or original intention.
Where such objects are capable of gathering, displaying, sending, receiving, storing or acting upon information, we believe they ought to operate in an open, transparent, accessible and extensible manner. You should certainly be able to draw data out of them, and — so long as those functions represent no threat — to run other functions on top of them. Accordingly, we believe that all public infrastructure capable of data collection of any type should, as a matter of policy and law, be furnished with open, read-access APIs. (This transparency cuts both ways: public infrastructure should be designed to record traces of its use, and share this data as well.) This policy of open access is designed to secure the goods of data collection and interpretation for the widest possible constituency.
Conversely, and happily, open access to data provides the maximum scope for the clever application of entrepreneurial acumen. There’s no reason in the world why developers cannot create and field for-profit applications and services built on data freely acquired, so long as they respect certain clearly-enunciated provisions in the licensure of same.
The bottom line ought to be that if you can develop a commercially-viable service making use of these freely-available resources, there’s nothing that should stand in your way. That way, the emphasis rests where it ought to: with the ease of use, the quality of interpretation, the analytic clarity, the power, pleasure or satisfaction your effort is able to offer its users. We are quite comfortable in asserting that open resources will give rise to the most vibrant ecosystem of third-party development, an ecosystem of entrepreneurs free to search the space of possibility and elaborate on niche opportunities previously unimaginable.
A further hope that we inscribe at the heart of an open-sourced networked urbanism is that we can take back an appropriate measure of control over the circumstances that literally govern our lives: we the uncredentialed, the nonexpert. We can teach ourselves what we need to learn, share whatever knowledge we glean, build on the insights of the others engaged in the same efforts.
Just as the novice programmer is invited to learn from, understand, and improve upon — to “hack” — open-source software, the city itself should invite its users to demystify and reengineer the places in which they live and the processes which generate meaning, at the most intimate and immediate level.
It is, of course, true that by no means everyone wants to. Experience with the Linux desktop operating system and other open-source tools suggests that the user experience of such alternatives remains under-refined compared to proprietary competitors. My own personal supposition is that the highly motivated and technically sophisticated developers responsible for almost all open-source and free production can almost literally not comprehend what it is like to be bewildered by what they would regard as the fundamentals of information technology — can do so, at any rate, only with the greatest difficulty and sustained effort. In my experience, it is the rarest of open-source development initiatives that allocates significant budgetary resources to the work of interaction designers, information architects, and other user experience professionals, or (just as likely) even thinks to retain them in the first place.
So free and open-source alternatives have tended to present potential users with the horns of a neat dilemma. On the one hand, open-source products by definition offer their users substantially greater and more granular control. On the other, that control generally comes at the cost of wrangling the thing’s behavior, through an interface designed by engineers for engineers, in precisely the manner all of our efforts toward ease of use are meant to preclude.
No: people clearly want to get on with the business of their lives. We should be clear as a first principle that taking advantage of high-level functionality no more require understanding the logic of the underlying system than driving a car requires a comprehensive grounding in the history of the internal combustion engine. And yet, if we conceive of our ensemble of resources as an open platform, the potential for self-education is there for those who would avail themselves of it.
Historically, the manufacturers of information technology haven’t been particularly good at framing the things they make in ways that allowed nonspecialist users to learn from them, let alone make full use of their power. But there have been important exceptions: think of the View Source command that is still offered in almost all Web browsers, that allows the user to study the HTML responsible for the structure and appearance of a given Web page, and that taught many an early Web developer the understandings that would become the tools of their trade. Some analogous provision for openness in the design of networked urban resources would be invaluable.
Finally, and perhaps counterintuitively, open platforms are simply more secure. Opening up access to an application’s source code furnishes that code to a relatively large number of developers, subjecting it to the rigorous critical inquiry of a pool of reviewers orders of magnitude larger than the one proprietary developers have available to them internally. This community of peers is relatively disinterested, motivated by desires other than that of shipping the product on schedule, and utterly disincentivized to paper over any flaws their inquiry might turn up. This kind of decentralized effort will highlight known vulnerabilities in the code, identify points of weakness that might offer leverage for malicious exploits, even lead to the development and release of patches, and has been observed to do all of this more efficiently than proprietary alternatives.
If for no other reason that the stakes are so high, any distributed system presenting as large an attack surface as a networked city truly needs the enhanced security that goes hand-in-hand with open development.
5. In practice
What we’re wrestling with here is a body of amorphous and slippery but absolutely central questions: just how do everyday urban activities generate data, and how is that data represented? How, specifically, is such data captured by the “cloud,” passed between services within it, and then offered back to individual users? Who is empowered to make use of it?
How questions like these ultimately get answered will make all the difference between cities that work for the people who live and dream in them, and ones which afford experiences of hassle, dismay and danger. But what might all of this look like in practice?
Here we offer a use case set in the shotengai, or main shopping street, of the quiet Hiro-o neighborhood of Tokyo. Even at quarter to nine on an intermittently rainy fall evening, the street runs lively with activity and noise. A gaggle of awkward-age schoolgirls laugh and pass around pictures on a mobile phone, as their well-dressed, harried-looking elders try to thread their way around or through them.
Cars, the preponderance of them taxis, slowly trundle the narrow street. Perhaps one out of every six or seven seems to be orbiting the block. The street itself is flooded with fluorescent overspill from the open storefronts of the businesses lining it, washed by the bright reds, blues and greens of LED signage. A recorded sales cry warbles from the chain drugstore at earache volume, distorted to the point of incomprehensibility.
The sidewalks of Hiro-o are like those of any big city neighborhood anywhere: overloaded with things one might want conceivably want to grab ahold of and treat as resources, whether this is to query the stock level in the soft-drink vending machine, post something on the community notice board, or find out if there’s space available in the tiny two-car parking lot nestled in a sidestreet, a gemlike miniature of its larger cousins elsewhere.
Everything in the public right-of-way also overflows with attributes we may wish to quantify or measure, from whether or not it’s actually raining at this very moment —and if so, how hard — to the sidewalk’s level of service (or pedestrian load factor) and the flow of traffic in the street itself. Maybe we’re interested in the average size of social groups, and in how long those groups tend to remain coherent. Or from what neighborhoods people have arrived in Hiro-o, and where they’re headed to when they depart.
All of these questions, curiosities and desires could be addressed — addressed decisively, resolved — by the reconsideration of the objects around us as networked resources. Some of them, indeed, are already well on their way: the cigarette vending machine scans the faces of would-be buyers in an effort to determine whether they’re old enough for legal purchase, and it and the newer models among the other vending machines alongside it bear ports from which a telltale CAT5 cable emerges, the traffic of bits down its length attested by the wink of a solitary yellow LED.
Every iPhone and cheap plastic clamshell keitai on the street is tied to a consumer, a reliable proxy for personal identity and location via the intercession of IMEI and credit-card or bank account numbers. If you wanted to find someone in this most complicated of all urban haystacks, you could certainly do much worse than to poll the aether for the unique signature of the device associated with their bank account — that is, if they haven’t outright told you where they are via Foursquare or Twitter or one of their burgeoning complement of local equivalents.
But while all of these things are surely interesting, they lack one or more of the crucial provisions we’ve been discussing: the accessible handle, the readiness to be discovered, the ability to tell the interface you’re seeing through how to parse and make sense of an object’s capabilities.
Put those together, and what do we have? How might the transition from “something found in the streetscape” to “self-describing resource” play out? Let’s take a closer look at a single such object: one of the spaces in that two-car lot:
As a networked resource, it would of course have a unique address in IPv6 namespace. It would further be characterized by an extensible object descriptor, and that description would include attributes for location, to a very high degree of precision; type (“parking space”); capacity (“compact car and below”); and ownership (“private”). This last qualifier is important because while municipal parking authorities generally have to turn a space in order to relieve street congestion, private operators presumably only want to maximize revenue. They don’t care how long one particular car occupies the space, as long as it’s paid for.
There would be a rate attribute, and one for rate type (“Fixed” or “Dynamic,” the latter reflecting a dynamic pricing market for parking resources). And the key to this particular resource’s utility, availability, which would toggle between two states, “Available” and “Unavailable.” (Perhaps as a grace note, a designer could provide for two further transition-state attribute values, like changing lines in the I Ching: “Becoming available” and “Becoming unavailable.”) Depending on the precise details of the lot’s business model, there might be an attribute for estimated time until availability.
These are the basics. With these attributes and the proper service-discovery settings, this space would show up as an asset on any suitably-equipped Internet device, from the lot manager’s iPhone and the in-dash GPS “navi” of the Prius turning the corner to the Tokyo Metropolitan Traffic Control Center — even the laptop screen of a Barcelona office worker, idly imagining what it might be like to live in Japan.
And then, of course, the add-ons, refinements and derivatives begin. uptime. percent utilization. charging available? (y/n.) sheltered? (y/n.) vandalism incidents affecting this space, 1 mo/1 yr/5 yr. theft incidents affecting this space, 1 mo/1 yr/5 yr. Historic high and low rent. trend. Various parties, for their own reasons, would find these data sets useful or interesting or necessary to the elaboration of their own business model…and note, too, that they are essentially available at no additional cost once the basic data collection has occurred.
The point isn’t just that a driver has found a parking space in a few minutes or seconds less than would otherwise have been the case. That in itself, to say the least, would hardly seem worth the massive effort it took to get there, even if multiplied at scale.
The point is the more efficient use of resources, the fewer wasted trips around the block, the lowered stress, the higher likelihood that that driver will be a pleasant person to be around over the next few minutes, the lower risk of disruption to social commitments and obligations, the neighbors that won’t be bothered by the churn of circling cars, the opportunities which might have been missed and will now be grasped. The point, further, is the occasion for better knowledge of the city this interaction makes possible, however granularly; the chance arising in the interplay of these elements for a nimble third party to present a genuine value proposition to driver, or lot operator, or both, or someone else entirely; and the notion that someone studying the data generated by many events like this one might come up with a new and entirely better way of doing things.
These things, writ large, are very much worth the effort, or so we believe. In fact, they constitute reason to be optimistic about the future of cities, at a time when reasons for optimism of any sort are growing thin on the ground.
Extend the model, always extend. The public-facing plasma monitor at the corner (type: display), the bottled-tea vending machine, the dome-mounted surveillance camera, the embedded traffic sensors: what would you do if you could have access to the flows of data coming off these things?
What tools and visualizations and analytical abstractions could you build on such flows? What businesses?
What new and unexpected social connections might emerge from their enunciation? What knowledge?
And this is just one neighborhood of Tokyo — not nearly the most interesting one, either, nor that most richly provisioned with potentially interactive street objects. Try to imagine what this percolation of activity looks like citywide, across the nation, globally: a hundred billion connected things, sending up flares and soundings, responding to same, waiting for the moment we pick them up and use them.
Thinking of a city this way introduces a set of very potent metaphors from informatics that aren’t, in the end, really any such thing at all: services, utilities, scripts and applications running on top of the platform for computation that is the contemporary city.
The point isn’t, at all, to introduce yet another brace of clumsy and inapposite jargon terms to urbanist thought, which is after all already well provisioned with same. It’s to bring the power lying behind these concepts to bear on our ability to conceive of and execute the experiences we think of as urban. And, eventually, to offer people a high-level language with which to describe the way they want to configure urban resources and compose situations.
Even if we’re limited to resources in the public realm, it suddenly becomes trivial to frame natural-language queries about the things we encounter in the world. What is the current number of seats available on the 4.15 ferry to Larkspur Landing? How does the number of people waiting at the westbound bus stop on Gray’s Inn Road vary by hour, by season, by weather? Is there any correlation between arrests for solicitation and the location of surveillance cameras in the Raval? What’s the most dangerous street intersection in Chengdu? How many times during the last month were gunshots audible from the roof of 4800 Baltimore Avenue? What are the top ten locations in Bangkok from which emergency services were called in the last three years?
We can run utilities — what percentage of the chairs in the Herald Square pedestrian plaza are available right now? Which running processes are involved in claiming them? — or write simple scripts: “Notify me when a group of three chairs becomes available.”
We can use the results of these queries directly and instrumentally, we can pass them onto other connected systems for action, or we can feed them into databases, visualizations, and analytical packages. Each answer turned up in this way can satisfy idle curiosity — nothing wrong with that — or further the development of insight, provide crucial support to a decision or bolster one or another side of a debate.
Each and every single one, moreover, is potentially the granule around which a community of shared concern can form. Shall we allocate more resources toward police booths or foot patrols, site the recycling station here or here, permit or forbid late-night entertainment in this block? If you think there’s no possible relationship between the low-level details of informatic design and the construction of a public that thinks of itself as such, pay close attention to what happens in the wake of introducing semantic object models for everyday things, and the high-level, natural-language queryability they enable. Among the very first things we’ll all learn from them is how surprisingly tight the coupling can be.
Given only the proper tools, we believe that people will build the most incredible ecology of bespoke services on open resources like these. If you’ve found the blossoming of iPhone or Android apps impressive, in other words, wait until you see what people come up with when they can query stadium parking lots and weather stations and bike racks and reservoir levels and wait times at the TKTS stand.
6. Design for networked cities and citizens
None of this will be without risk, none of this can be had without some loss. But the truth is that we are already experiencing certain losses as a result of the introduction of networked computation into our cities.
In fact, if there’s a way to characterize the current relationship between networked informatics and metropolitan experience, it’s that the former tend to cut against the ways we have historically understood city life and the things we have relied on cities to do for us. As we shall argue, the ability to trivially search the space of a city is leaching away at the constitution of a quality we have always recognized as urban savvy or savoir faire. The persistent retrievability of personal information is undermining the city’s capacity to act as a chrysalis for personal reinvention. Technologies like high-resolution positioning and algorithmic facial recognition are destroying any promise of anonymity we thought the metropolis offered.
It is only by consciously and carefully transforming the urban landscape into a meshwork of open and available resources that we can redress this imbalance. This transformation would neither have to be directed from the top down, nor accomplished all at once. But the greater the number of resources available, the greater the extent to which they are described properly and are capable of being used without further configuration, the better off we’ll all be. We will collectively stand that much greater a chance of winding up with networked places that reflect something of our own local values and traditions, wherever we live and whatever those values might encompass.
These are not the “smart cities” IBM, Oracle and Cisco want to deploy — or, more properly, to sell to municipal bodies the world over. They require neither greenfield sites nor the patronage of a paternalist government. These are simply the cities we already live in, and love, endowed with all the new capabilities and potentials an emerging technology can offer. If this is to be a century of networked cities, as the consultants and thinktanks keep telling us it will be, we passionately believe that any such thing not merely can, but must, be built on a foundation of respect, empathy and care. This, anyway, is the effort to which we’ve devoted ourselves at Urbanscale. We hope you’ll join us.