This paper might be a pre-copy-editing or a post-print author-produced .pdf of an article accepted for publication. For the

definitive publisher-authenticated version, please refer directly to publishing house’s archive system.

390

Copyright © 2009, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.

Chapter XXVII

WikiCity:Real-Time Location-Sensitive

Tools for the City

Francesco Calabrese

Massachusetts Institute of Technology, USA

Kristian Kloeckl

Massachusetts Institute of Technology, USA

Carlo Ratti

Massachusetts Institute of Technology, USA

INTRODUCTION

The WikiCity project at the senseable city labo-

ratory at MIT is a multi-year research effort that

builds on different research strings, combining

under one common vision the aspects of sens-

ing, time- and location-based data structuring,

and the input and output articulation of this data

within the context of urban environments. These

different fields are combined both to offer new

ABSTRACT

The real-time city is now real! The increasing deployment of sensors and handheld electronic devices in

recent years allows for a new approach to the study and exploration of the built environment. The WikiCity

project deals with the development of real-time, location-sensitive tools for the city and is concerned with

the real-time mapping of city dynamics. This mapping, however, is not limited to representing the city,

but also instantly becomes an instrument for city inhabitants to base their actions and decisions upon in

a better informed manner, leading to an overall increased efficiency and sustainability in making use of

the city environment. While our comprehensive research program considers a larger context, this chapter

discusses the WikiCity Rome project, which was the first occasion for implementing some of WikiCity’s

elements in a public interface—it was presented on a large screen in a public square in Rome.

391

WikiCity

perspectives in analyzing a city’s dynamic and for

the conception and elaboration of novel tools for

citizens to make optimal use of their environment

(Calabrese, Kloeckl, and Ratti, 2007).

The WikiCity Rome project, on the occasion

of La Notte Bianca (White Night, www.lanot-

tebianca.it) in Rome on September 8, 2007, has

been an opportunity to present a first glimpse of

the more comprehensive WikiCity project to the

public. This first implementation allows people

access to the real-time data on dynamics that oc-

cur where they are at that moment, creating the

intriguing situation that the map is drawn on the

basis of dynamic elements of which the map itself

is an active part. ‘How do people react toward

this new perspective on their own city while they

are determining the city’s very own dynamic?’

and ‘How does having access to real-time data

in the context of possible action alter the process

of decision making in how to go about different

activities?’ are our guiding research questions.

The overall WikiCity research program consid-

ers such questions in a larger context that includes

the active uploading of information by citizens,

local authorities, and businesses regarding an ever

increasing field of data; an elaborate approach to

semantic data structures to enable novel ways of

querying the data; and a rich array of multimodal

access interfaces for users to interact with the

data in a meaningful way.

The remainder of this chapter is structured as

follows. Section 2 describes the project, taking

into account different aspects of creating an open

platform. Section 3 describes WikiCity Rome, first

implementation of the WikiCity concept. Section

4 describes relevant work related to the WikiCity

concept. Section 5 describes the design concept

and different application scenarios, while Section

6 deals with access modalities and interfaces.

Section 7 describes the software infrastructure

and its main elements. Finally, Section 8 describes

directions for future work and conclusions.

WIKICITY

People moving and acting in a city base their

decisions on information that is, in most cases,

not synchronized with their present time and

place when making that decision1. How often

have you arrived at the airport just to find out that

your flight has been delayed, or been surprised

by a traffic jam, or found that a product is out of

stock or a service operator busy at the moment

you need it.

In the same way, a person acting in a city con-

tributes himself to dynamics of which others are

not aware when making their decisions. Looked

upon in this way, a city resembles what Deleuze

and Guattari describe as a rhizome (Deleuze and

Guattari, 1977). The rhizome is a philosophical

network structure where every part is necessarily

connected with every other part of the system.

There are no preferential connections because

every connection alters the overall network struc-

ture. As a consequence, the rhizome cannot be

plotted since the plotting action itself is part of the

rhizome and thus in the very moment of plotting

its structure, the structure changes.

The WikiCity project, in a similar way, is

concerned with the real-time mapping of city

dynamics. This mapping, however, is not limited

to representing the city, but instead becomes in-

stantly an instrument upon which city inhabitants

can base their actions and decisions in a better-

informed manner. In this way the real-time map

changes the city context, and this altered context

changes the real-time map accordingly, with the

ultimate aim of leading to an overall increased

efficiency and sustainability in making use of the

city environment.

Will such a WikiCity lead to more people at-

tempting to be at the same place at the same time

or in an increasing number of different places at

different times? Designing a tool to address such

a question requires considering whether and how

the real-time map is capable of communicating

different and context-based information to users

392

WikiCity

in different circumstances and how people’s deci-

sions, which were taken on the basis of the real-

time information, are fed back into the system.

The project aims to create a common format

for interchange of real-time location-based data

and a distributed platform able to collect, manage,

and provide such data in real-time. This platform

is conceived as an open platform, meaning that

different users can access, upload, and modify

data on this system platform. WikiCity therefore

functions as an additional infrastructural layer of a

city, similar to electricity, transport, and telecom-

munications. Two relevant issues emerge from the

choice of this platform type: the reliability of data

sources, and the understanding of how different

data can be constructively combined in response

to a user’s query.

Information and Trust in an Open

Platform

Since the content is to be provided by an open

community and is ultimately going to be combined

in such a way that users may base decisions on

it, the issue of trust (with regard to content data)

deserves careful reflection. How do you know

you can trust information that is provided from

an open community? Whom do you trust, and can

you decide whom to trust? (cf. Foth, Odendaal, and

Hearn, 2007; and Beer and Burrows, 2007).

In conventional infrastructures this aspect is

most often resolved through publicly recognized

certifications and recognitions of singular and

well-defined agents; this underlying element of

trust is part of the reason why people choose to

rely on such infrastructures. How can we arrange

such a system of trust in WikiCity’s open platform,

which by definition is open and therefore cannot

be based on any single agent that attributes reli-

ability onto other agents?

In an open community platform, trust should

come from within the community of users. A

strong example is eBay’s member feedback his-

tory: with each new transaction, the two members

involved give each other feedback, and each new

piece of feedback is combined with the entirety

of the user’s feedback history in order to create

an overall rating. In this way, feedback provided

by a single user is merged with every additional

input provided in the future, and the decision

whether to trust a single input can be based upon

a comparison with the whole feedback history.

Another and perhaps complementary approach

leads to the definition about whom I want to trust

when accessing data from WikiCity. An open

platform might enable me to choose whose data

I want to rely on. I might want to consider data

trusted by myself, trusted by others whom I trust

directly (“first-level trusted data providers”), and

those whom they trust directly. In this way, we use

levels of separation as an indicator of trust.

Both of these approaches involve the addition

of elements to any set of data supplied to WikiC-

ity that enable users to evaluate its reliability.

Different levels of such trackability shall be

considered, giving the end user different possi-

bilities as to which data to consider and which to

ignore (e.g., I might be interested in considering

data from sources without any history of trust

in certain situations, and by my giving feedback

on their encountered reliability, a trust record is

created).

Making the Users Create the Links

While one of the challenging tasks in structuring

a data platform consisting of a diversity of data,

which one cannot and does not want to predict

or limit up front, is to describe the actual data,

another is to create relationships between data sets.

For a combined query regarding perfect places to

fly a kite, one would be interested in considering

weather data (wind, rain), daylight hours, and an

area’s topology and vegetation. Instead, knowing

the electrical resistance of a device present in that

location is of no use for this query, but how does

the platform know?

393

WikiCity

An interesting hint can be taken from a proj-

ect developed by Carnegie Mellon researchers:

reCAPTCHA (http://recaptcha.net) puts the 60

million daily descriptions of CAPTCHAs2 on the

World Wide Web to use in resolving words that

OCR (optical character recognition) programs

cannot read when digitizing books.

In a similar way we can imagine WikiCity

collecting different types of data on its open

platform, which people can use, through an API

(Application programming interface), to custom-

code their data-fusion applications. In this way,

specific pieces of information can be aggregated

and visually represented to end users through

an interface. When this happens, all data types

involved in this process receive an increase in

the level of attractiveness between each other. A

human has chosen that it makes some sense to

combine these data types for a real-world applica-

tion. This level of attractiveness can then be used

in a more open query of the platform in order to

suggest or give priorities to certain types of data

to be involved in the query reply.

WIKICITY ROME

Our group takes a bottom-up approach to devel-

oping WikiCity: the overall structure is created

stepwise through implementations on a reduced

scale. In a similar way, the aspect of trust as related

to data is approached gradually, combining tradi-

tional elements of trust with novel ones as outlined

above. We are at this stage working together with

established and publicly certified partners such

as telecommunications entities, telephone and ad-

dress directory services, satellite imaging, public

transport, and newspaper publishers in order to

establish a range of different data sets that can

be combined on the WikiCity platform. Next, we

aim to enlarge this base group of know-how and

content providers as well as open up the system

gradually to provide users with direct input and

output access on the platform itself.

Figure 1. Photos from the WikiCity Rome project

presented at La Notte Bianca, 08-09-2007

394

WikiCity

A first implementation of the WikiCity concept

was presented in Rome, Italy, during La Notte

Bianca on September 8, 2007. This demonstra-

tor (see http://senseable.mit.edu/wikicity/rome)

comprised the presentation, on a big screen in a

major square of Rome and on the Web through a

Web applet, of real-time population distribution

by the use of cell-phone data, the location of buses

and trains, real-time news feeds from a main Ital-

ian newspaper, and its mapping to certain events

happening in the city.

RELATED WORK

Recent literature has increasingly used the term

‘city’ in reference to a real-world space offering

social opportunities and cultural landmarks for

urban analysis (Thom-Santelli, 2007). Hitherto,

implementations have been based on ideal users

who perfectly fit a certain application. Recently,

social software service implementations try to

promote different user-specific interpretations of

urban landscapes and by that enable the develop-

ment of multiple meanings and representations of

city use. This also results in a move from represent-

ing the city as a structured lineup of buildings to

a space of interpretative cultural interaction.

The same direction is envisioned by Bassoili

(Bassoli et al., 2007) which states that a paradigm

shift in urban computing is just occurring, in the

sense that it is not only about the city, but that

the city itself and its inhabitants are part of the

application and vice versa—i.e., urban comput-

ing becomes part of the city. In consequence, the

context of the city is growing toward a platform

for the collective creation of content and social

interactions. Thus, the city itself is increasingly

perceived as a source of experience rather than

a place of trouble and hassle. The authors men-

tion disconnection, dislocation, and disruption as

the three main challenges when designing urban

applications.

A general trend in current research is that ap-

plications using wirelessly interconnected devices

have to integrate seamlessly into everyday life

until people don’t even recognize their presence

anymore. Thus, pervasive information needs can

be satisfied through smooth integration with so-

cial structures, fast personalized service access,

seamless sharing of information, multiple types

of interfaces, and ubiquitous networked user

services (Trevor and Hilbert, 2007).

DESIGN CONCEPT AND SCENARIOS

WikiCity is about envisioning new application

scenarios on the basis of a technology potential

involved in location- and time-sensitive informa-

tion. Different aspects of the concept design are

presented in this section. We start identifying

the agents the metafunctions and the technology

features involved in the system. Then we address

the concept of time as applied in the project, and

use the real-time control system as a working

metaphor. This leads to the elaboration of different

scenarios used to conceptualize the applications

of WikiCity.

Within the social context of a city, we have

identified three main groups of element: the vari-

ous agents involved, the specific environmental

conditions in which they operate, and the potential

of new technologies.

1. Agents: Private individuals, associations,

local authorities, companies, non-profit

organizations

2. Environment: City architecture, infra-

structures, landscape, waterways, climatic

conditions

3. Technology Features: Positioning, detect-

ing movement and interaction, evaluating

density, visualizing, sensing environment

values

395

WikiCity

Subsequently we identified the intersections

of the capacities and requirements of these three

element groups.

Considering people living in urban areas, we

distinguish among four main macro needs that

can be addressed in the design of services and

products for urban dynamics: safety, interaction,

comfort, and mobility.

On the basis of these macro needs, we identify

metafunctions—different for any specific geo-

graphic, cultural, or technological context—that

try to accommodate these needs. They are as

follows:

• Wellness / Health: How do people maintain

their physical and mental health and well-

being, and what do they consider these to

mean?

• Work: What do people do to interact con-

structively with their environment? How

and what do they create?

• Encounter / Community: How does the

pleasure of living together with many others

in one city translate into actual encounters?

How do people arrange to meet: where and

when and whom do they meet, and on which

occasions?

Figure 2. Application scenarios generated by intersection of agents, environment, and technology fea-

tures

396

WikiCity

• Filter / Selection: In the urban environment,

people are confronted with a massive amount

of events that may attract their attention.

What strategies do they use to filter out what

is not of interest, and how do they find and

focus on events that do match their range

of interests?

• Education: Assuming that learning is not

confined to school buildings: which occa-

sions and places do people identify with

enlarging their knowledge, and in what ways

do they proceed to do so?

• Commercial Exchange: What commodities

are included by society within the sphere of

commercial exchange? Value patterns are

continually changing, and items that are

free today might become valuable products

or services tomorrow. What products or ser-

vices are part of the commercial exchange

dynamic? Which ones are not a part of that

dynamic now but might become a part in

the future? How will this affect them?

• Recreation: What do people do for enjoy-

ment and pleasure. What constitutes pleasure

for people in a city, how can an urban envi-

ronment foster these activities and situations,

and what factors prevent them?

• Navigation / Orientation: Moving physi-

cally within a city requires knowing where

to go and how to get there. How do citi-

zens choose their routes through the urban

landscape, and how do they adapt to the

changes in that environment? How do they

rely on external communication elements

for this navigation, and how much do they

instead base their orientation on personal

knowledge?

• Discovery: An urban environment presents

risks and opportunities that are known to

a citizen, but it contains the potential of

unexpected discoveries in all aspects of

life. What elements of a city contribute to

constructive new discoveries by its citizens?

What behavior do people adopt in discover-

ing new aspects of their environment?

Figure 3. Technology features and metafunctions intersect to generate application fields

397

WikiCity

By examining the intersections of metafunc-

tions and potential technological features, we can

identify new application concepts for the WikiCity

project, as explained in the subsections below.

Time Value

A key characteristic of WikiCity is the circula-

tion of information on a real-time basis. Before

proceeding, we should clarify our interpretation

of the term real-time and the scope of its impli-

cations.

Often the term real-time refers to a system

in which data is processed within a small frac-

tion of time—for example, a sensor that returns

a measurement as a signal within a fraction of a

second. The difficulty with this definition is that

it does not provide a specification of the time

interval in question, and this makes it difficult

to judge any given system as to whether it does

or does not operate in real-time.

A more useful definition refers to real-time as

“the actual time during which a process or event

occurs” (Oxford, 2007). Consequently a real-time

process implies that there is a deadline before

which a given piece of data is useful to the system,

whereas that same data is not useful—or may even

be destructive—to the system thereafter. While

the deadline implies a process, identifying the

usefulness of respecting such a process’s deadline

implies the existence of a higher-level mission.

Considering now that it is evidently this mission

that defines the parameters of the deadline, we

end up with an idea of real-time in which there is

no stringent necessity to speed up data transfer to

arbitrarily defined “very fast” limits but rather to

identify reasonable deadlines for data-transmis-

sion that are related to specific missions.

Let us consider some examples to illustrate

what this implies for WikiCity and its position

within the framework of real-time systems. When

setting up the data integration for the public

transport vehicle position for the WikiCity Rome

project, we had initially arranged for a location

data feed in five-minute intervals. Visualizing

in this way the position of buses around the city

gives a good overall impression of the distribution

of buses around the city throughout the day. In

fact during a previous senseable city lab’s project,

Real-time Rome (see Calabrese, Ratti, 2006 and

http://senseable.mit.edu/realtimerome), such a

time interval was perfectly sufficient to overlay

the information with the cell-phone activity that

occurred at the same time in order to examine

how transport lines work regarding people’s

aggregation. In WikiCity Rome, our aim was

instead to turn the visualization into an instru-

ment useful for citizens while the information is

being processed, suggesting the possibility that

people could identify when a bus was about to

pass by a stop near their location. Seeing a bus’s

location of five minutes ago is clearly a case in

which such information cannot be considered

real-time anymore; it has passed its deadline of

usefulness, and the system has failed to deliver

information on time to accomplish the mission,

which in this case is catching the bus.

On the other hand, when we consider informa-

tion about upcoming, starting, and running events

displayed on a map at their relevant locations,

we must opt to visualize this data some minutes

before the start of the event (in order for people to

be able to attend the event); however, the deadline

for this visualization of the event is not critical

because the importance of displaying that the

event is ongoing, for most missions, decreases

as the event approaches its end.

The Real-Time Control System as a

Working Metaphor

In order to identify the functional elements needed

to construct such an instrument, we chose the real-

time control system as an analogy to start with. In

the past decades, real-time control systems have

been developed for, and deployed in, a variety of

engineering applications. In so doing, they have

dramatically increased the efficiency of systems

398

WikiCity

through energy savings, self-organization and

-repair, regulation of dynamics, increased robust-

ness, and disturbance tolerance.

Now: can a city perform as a real-time control

system?

Let us examine the four key components of a

real-time control system:

1. entity to be controlled in an environment

characterized by uncertainty;

2. sensors able to acquire information about

the entity’s state in real-time;

3. intelligence capable of evaluating system

performance regarding desired outcomes;

4. physical actuators able to act upon the system

to realize the control strategy.

A city certainly fits the definition of point 1.

Point 2 does not seem to pose problems either:

today’s deployment of a range of remote sen-

sors in urban areas allows for unprecedented

data collection and analysis. As an example, the

Real-time Rome project used mobile phones and

GPS devices to collect the movement patterns of

people and transportation systems a well as their

spatial and social usage of streets and neighbor-

hoods. Information regarding further aspects are

already collected continually by distinct comput-

ing systems that track product and service avail-

ability, environmental values, climatic conditions,

acoustic values, events, etc.

What about points 3 and 4? How to actuate

the city? Although the city already contains

several classes of actuators such as traffic lights

and remotely updated street signage, their range

of use is currently limited. A much more flexible

actuator would be the city’s own inhabitants:

they represent a distributed actuation system in

which each person pursues his individual inter-

est in cooperation and competition with others,

with the overall behavior of the system governed

by the interaction among individuals. People can

also form part of the overall intelligence of the

control system.

Toward the above goal, the WikiCity project

can be thought of as adding further, interaction-

oriented layers to a real-time map of the city and

making location- and time-sensitive information

accessible to users, giving them full control of the

database, where they can upload and download

data. In this way, people become distributed in-

telligent actuators and thus become prime actors

themselves in improving the efficiency of urban

systems.

Scenario Elaboration

Considering the above working analogy of the

real-time control system enables us to identify

the functional elements of the system making up

WikiCity. As a further step in concept and scenario

elaboration, the technique of storyboarding is

used to visualize dynamic situations enabled by

WikiCity in a modeled real-world situation. The

technical potential of location- and time-sensi-

tive services becomes apparent by applying it to

a coherent scenario. The following figure shows

an example of such a storyboard:

Various scenarios have been developed in

order to identify potential applications for the

WikiCity platform:

• Jogging Path: By considering real-time

environmental data like air quality, noise, or

pollen flow together with the traffic situation

and personal health conditions, the WikiC-

ity system can suggest ideal jogging routes,

taking these factor into account together

with the starting position of the user.

• Bus-Hopping: Instead of waiting at the

bus stop for a bus that theoretically adheres

strictly to a static timetable but in reality

deviates from it, having access to real-time

information about bus locations promotes a

more flexible approach to using the public

transport system, allowing the user to arrive

at the stop only when the bus is about to turn

the corner, or to use an alternate bus line to

399

WikiCity

get close enough to the destination to finish

the way by foot.

• Event Spotter: Walking through the city,

one is aware that many events that are both

interesting and close by will be missed sim-

ply because the typical pedestrian is unaware

of them. On the other hand, often programs

are planned in advance or at distant loca-

tions but are subsequently cancelled without

notification to potential attendees. Being

able to receive notifications about ongoing

or upcoming events within a set radius of

the user’s current location opens up a happy

combination of strolling through the city

and discovering events as one comes near

them.

• Sight Density: Sightseeing in a city often

involves finding long queues at popular sites.

Knowing in advance about the wait situation

at different sites will help the sightseer to

organize a visit that allocates more time to

actually seeing the sights than to waiting

for them. At the same time, because of the

increased level of organization resulting

from visitors’ being better informed, the

site’s management benefits by being better

able to deal with visitor access.

• Nearest Aid: When experiencing a minor

health issue, one would not want to call an

ambulance or even visit a hospital. Instead,

knowing about nearby pharmacies, wait-

ing ambulances, or other medical outposts

would allow a citizen to stop by and receive

adequate advice or treatment without going

through a more costly ordeal. Spreading

knowledge of such available places can be

a simple contribution to people’s well-being

in a city.

• Informed Shopping: It often happens that

one knows exactly what product one is

looking for but still ends up driving from

one place to the other to actually find it.

Product-availability information already

exists in digital form in logistics databases

for most shops. Being able to consider this

data together with proximity and store hours

would make moving physically through the

city in the search of a product or service

more efficient.

• Emergency Support: Emergency situa-

tions may benefit most from a real-time

system such as WikiCity since they consist

of a drastic alteration of the usual context

Figure 4. Jogging path scenario

Before jogging, Tom looks at the WikiCity

map for route suggestions based on air

quality, traffic, calmness of various paths,

and his physical condition.

The WikiCity map suggests three jogging

routes considering air quality, traffic

density, and Tom’s physical condition, each

indicating an approximate duration starting

from tom’s current position.

Tom chooses his preferred route for the

day and sets off for a run. After trying one

route, he can decide whether to record his

choice for later and leave suggestions for

others.

400

WikiCity

and produce an acute need for up-to-date

information on the state of the situation in

order to best cope with it. As an example, the

location and availability of potable water at

any given moment is crucial information to

have in areas affected by flooding or earth-

quake, since collecting it can be a difficult

undertaking.

As illustrated in the following figure, in order

for these scenarios to feed back into the develop-

ment process of the WikiCity system architecture,

this process helps to identify the attractiveness of

certain data types, which enable different appli-

cations. This is especially important in the early

phase of the project’s implementation, during

which careful selection of data providers can make

the project platform more or less versatile.

Proceeding with the design of application

scenarios for the WikiCity platform, we aim to

remain true to Deleuze and Guattari’s rhizome

metaphor. “The rhizome is a centered, non

Figure 5. Seven scenarios

Continued on following page

401

WikiCity

Figure 5. Continued

402

WikiCity

hierarchical, non-signifying system without a

General and without an organizing memory or

central automation, defined solely by a circula-

tion of states” (Deleuze, Guattari, 1977). What is

obtained is utopian freedom—liberation from the

constraints of hierarchal systems. The concept of

utopian freedom of movement supplied by Deleuze

and Guattari has previously been employed by

cyber theorists such as Wray (1998) as a means

of explaining how users freely traverse digital

space. While this analysis is intended to relate

to the Internet, it would seem that the concept of

the nomadic Internet user extends naturally to

explain the city dweller who, through the use of

technologies such as WikiCity, enters, traverses,

and leaves real and urban spaces.

However, an essential part of the Deleuze-

Guattari model of the rhizome is that utopian

elements can exist only in tension with dystopian

forces. The essence of the rhizome is that it exists

in contention with arboreal (and, for Deleuze and

Guattari, capitalist) interests that seek to curtail the

Figure 6. What data enables what scenarios?

403

WikiCity

potential freedom presented by the rhizome, and

the outcome is a continual battle of territorialism

and re-territorialism.

This dualism of the rhizome/arboreal model

might provide a useful framework for understand-

ing the limits or design aspects best avoided in

the implementation of WikiCity and help ensure

that the outcome is the liberated rather than the

disenfranchised citizen.

ACCESS MODALITY: INTERFACES

This section deals with the design of access

modalities that allow users to interface with the

WikiCity system, enabling the implementation of

the scenarios developed in the previous section.

Interfaces for WikiCity are about creating

connections between the tangible level of the city

that surrounds us and the functional layers of data

and their integration. Different kinds of interfaces

shall be considered in order to offer a broad range

of access modalities, lowering the difficulty of

connection and allowing access to this WikiCity

platform to be as open as possible.

The application scenario and the involved

agents, the type of data, and the environmental

context within which the scenario is located

determine the different interface modalities. A

multimodal interface approach shall be followed,

combining different input and output method-

ologies. For the actual project implementation,

however, available technology, project partners,

and time constraints will determine a step-by-step

approach to integrate the entire range of interface

modalities. We shall therefore distinguish two

main groups of interface designs for WikiCity: 2-D

display interfaces on the one hand and genuinely

multimodal interfaces on the other.

Figure 7. Access modality can be positioned more closely to the user, the built environment, or mobile

vehicles

404

WikiCity

2-D Interfaces: WikiCity Rome

WikiCity Rome has been the first implementation

of some of the elements composing the more com-

prehensive WikiCity research program. For this

occasion, a large (10x5 meters) public projection

was chosen and positioned on a public square in

Rome. During the entire twelve hours from 8pm

until 8am, a projection showed a satellite image

of Rome with overlays indicating:

• real-time cell-phone activity

• real-time location of public buses

• starting and ongoing event tags at their cor-

responding location

• live news feeds from journalists at the loca-

tion where they were reporting from

Certainly this public display as an interface

for the WikiCity Rome project implies some

limitations such as a static location, a lack of

interactivity and personalized queries, and a

fixed set of data types. On the other hand, it is

interesting to consider some of the less obvious

positive points of such a setting:

Low Access Barrier

A public display allows access to the displayed

information to anyone passing by the display

location. No prior experience or knowledge is

required beyond that of reading a map, or better,

a satellite view of one’s own town (which, as a

matter of fact, is not so easy a task, and always

presents difficulty when dealing with maps).

Figure 8. WikiCity Rome interface used for a 10x5-meter projection in a public square

405

WikiCity

Social Aspect of Consultation

a large public projection allows for a group of

people to observe—that is, to access—the Wi-

kiCity information, comment on it, and share

impressions, ideas, and proposals for actions to

be taken on the basis of the information read.

Unlike personal devices, such a large-scale in-

terface allows WikiCity to become a tool that

can effectively foster social dynamics between

users. Additionally, the aspect of difficulties in

map-reading mentioned above is alleviated by

knowledge exchange among the audience.

Regarding the different interface elements,

before describing each in more detail, here are

some general observations: Combining different

kinds of time- and location-based data brings up

the importance of the place of reference, which

in the WikiCity Rome case was the location of

the public projection, while in portable devices it

would be the present location or, similar to a loca-

tion-independent search, the chosen location of

interest. One visualization difficulty encountered

in WikiCity Rome was the clash between a big

amount of relevant information near the refer-

ence location and the small space available that

it refers to on the map. On the contrary, there is

much map space available farther away from the

projection location. Yet, a dense visualization of it

is not as relevant. The one element that reflects this

consideration in WikiCity Rome is the motion of

the buses’ visualizations, which show their respec-

tive line numbers only within an area around the

display location, while transforming into visually

less invasive, smaller elements without numbers

anywhere outside this area.

While on a personal device, it might be fea-

sible to approach this aspect by zooming in or

focusing only on specific locations, in the public

projection in Rome this was not an option since

both perspectives have to remain intact—that

is, the perception of possible action that can be

taken on the basis of locally relevant information

as well as the perception of the overall dynamic

showing the city in its entirety.

Interface Elements and Their Behavior

in WikiCity Rome

• Map: A satellite image from Rome modified

digitally to enhance contrast is used as the

base map layer.

• Cell-Phone Activity: In WikiCity Rome,

cell-phone activity, based on an aggregated

and anonymized data set, is used to suggest

the distribution of people within the city.

Since this is a type of data that tends to

change noticeably over a time interval that

is longer than the average time a person

could be expected to observe the projection

during La Notte Bianca, a blue flickering

has been chosen to correlate better to what

was visualized—that is, people moving.

• Public Buses: A yellow dot indicates the

real-time position of buses moving around

Rome. The number inscribed in the circle

indicates the bus number when the bus moves

within proximity of the projection’s location,

allowing for observers to decide whether to

take the bus or not. The length of the bus

tail indicates the velocity at which the bus

travels.

• Events: The event label shows up whenever

an event is starting and while it is occurring.

To avoid the risk of cluttering the map with

too many event labels open at a time, we

developed an algorithm that would control

dynamically the distance of the event labels

from the edge and between each other,

extending the guide lines accordingly. To

avoid clutter and to maintain readability, it

also controls the visibility of ongoing events

so as not to visualize more than three labels

at the same time.

• News Feed: Having a major Italian news-

paper as technical partner in the project, we

arranged to have various journalists report

live at short intervals about occurrences in

different parts in Rome. On the projection,

these location-tagged news feeds were pre-

406

WikiCity

Figure 9. Satellite map of Rome

Figure 10. Blue flickering indicating cell-phone

activity

Figure 11. Icon representing the public buses

Figure 12. Event label indicating name, place,

time, and image for an event

Figure 13. Location-referenced news-feed label

sented as scrolling text at the location where

they were reported from, creating a simple

but effective way of visually geo-referencing

information about city dynamics.

Multimodal Interfaces

In the search for connections between the data

realm and the user within the urban space, the

second focus for WikiCity interfaces shall be put

upon built structures. Throughout the urban envi-

ronment, inhabitants are surrounded by structures

such as urban furniture or built infrastructures,

many of which already carry various types of

information, even if mainly in a static way.

Information from the virtual realm of WikiCity

shall also be accessed through interaction with

these structures. Three approaches can be clearly

distinguished:

1. Embedded access in existing structures

2. Embedded access in existing structural

topologies

3. New structural typologies as a way to access

WikiCity

Different from mobile devices, the location is a

known constant in all three of these 3-D interfaces.

Furthermore, the information type accessible

through immobile 3-D interfaces can be limited

to a specific mix that results from the interface

typology and the environment surrounding it.

We are currently looking into different aspects

and research done within the range of “tangible

user interfaces” (TUI) to further enhance the

WikiCity interface considerations.

SOFTWARE IMPLEMENTATION

In order to realize the WikiCity application able

to provide the services described in Section 3, we

have identified two crucial aspects that drive the

development of the system.

407

WikiCity

• Semantic Web Technologies: The role of

semantics for interoperability and integra-

tion of heterogeneous data, including geo-

spatial information, is widely recognized

(see Berners-Lee, 2001 and W3C, 2007). By

the use of semantics, information process-

ing (retrieval or integration) can be based

on meaning instead of on mere keywords.

The W3C Semantic Web Activity Work-

ing Group has been working on a series

of standards in this sense. We think that

ontologies can be used in order to improve

interoperability and sharing of information

and knowledge among various data sources

and services. Moreover, we are developing

contextual, spatial, and temporal ontologies

and correlating them to allow analytical

processing and reasoning on multimodal

data.

• Decentralized Infrastructure: WikiCity

will not have a single authority running the

whole system. It will be composed of a col-

lection of authorities that will participate in

the whole system at various scales. So large

authorities running large databases, such as

telecom operators, will be part of the system

as well as small organizations or individuals.

As an analogy, it is exactly the same as the

Web is today: we have large information

systems belonging to large corporations that

are part of the Web, as well as people that

simply connect to the Internet and run a Web

server on their own machine. Decentralized

information is more pronounced in Web 2.0

applications (cf. Kolbitsch and Maurer, 2006;

Beer and Burrows, 2007), where people

can share information on somebody else’s

system, if allowed and encouraged to do

so. Moreover, some specifically addressed

peer-to-peer infrastructure will be evalu-

ated in order to make information flow from

sensors via (distributed) intelligence to the

end users and actuators of the WikiCity. As

a result, the WikiCity will be shaped as a

multi-centered infrastructure, where many

entities providing services exist and are

organized as in the Web, and where some

entities can self-organize in a peer-to-peer

manner for coordinating tasks and pushing

information.

Based on these observations, we have designed

the software architecture as composed of several

interacting elements, listed below.

• Data Authoring: WikiCity requires several

tools, scripts, and methodologies to extract

metadata from syntactically (including un-

structured, semi-structured, and structured

data) and semantically heterogeneous and

multimodal data from diverse sources (wire-

less sensor networks, mobile phone data,

citizens, etc.).

• Data Acquisition: The WikiCity application

requires an interface for data providers to

send the locational data (data stream) and

manage the real-time constraint imposed by

the application.

• Data Extraction and Processing: A new

type of browsing across data sources, based

on location and time constraints, is required

to support the data extraction. We are ex-

perimenting with data processing based on

Web-services composition and orchestration

to achieve this.

• Interactive visualization: A critical part

of WikiCity is the development of interac-

tive visualizations. This task involves the

creation of a variety of interactive tools for

browsing, searching, and navigating through

and among diverse, distributed collections

of information. New browsing methods are

being developed (e.g., browsing by timeline

or distance range) to support the new type of

data available. The User Interface is designed

in two ways: ! City Level: It is based on city maps, or other

abstract representations, where different

408

WikiCity

layers can be added. Such layers represent

real-time information available in WikiCity.

The user views the data as though watching

the city using a particular lens. ! Personalized: The interface is also based

on the user location (retrieved in an auto-

matic way by using location technologies or

defined by the user) and a specific query.

• Management Interfaces: Many of the com-

ponents of WikiCity will need interfaces in

order to be configured and managed (e.g.,

setup of sensor networks, interfaces for key-

distribution in encrypted P2P connections,

etc.).

In the following, some technical aspects about

the two most important components of the archi-

tecture are addressed.

Data Acquisition

A challenge for WikiCity is the question of how

an enormous amount of user-generated data can

be exploited to create meaningful and intuitive

outputs without causing information overflow. To

tackle this problem, as already explicated in the

previous section, we make use of semantic Web

technologies, and in particular of ontologies and

semantic Web services.

The ontology is described by means of the

Web Ontology Language (OWL, 2004). Gener-

ally, all data in the system are related to one or

more categories in the ontology, which is the basis

for a structured query system and well-defined

data maintenance. The Ontology Service is used

to upload and access information about the data

within the domain described by the ontology.

To manage the data stream coming from the

data providers, we use the Web services tech-

nology, which provides a uniform interface able

to manage the real-time constraint imposed by

the application. The connection between Web

services and ontology is obtained by semantic

mark-up of Web service (OWL-S, 2004). This is

obtained by defining, in the service profile, the

output data as individuals of one of the classes

defined in the ontology.

Figure 14. Interfaces in 2-D and 3-D as connections between the tangible and the virtual realm of a

city.

409

WikiCity

Moreover, we allow the definition of processing

services, which are semantic Web services that

are able to perform some processing on the data

described by the system’s ontology.

Data Extraction and Processing

A new type of browsing across data sources, based

on location and time constraints, is required to

support Data Extraction. To this end, we are us-

ing a combination of methods of ontology-based

information searching (see, for instance, Yu,

2003) and data processing, based on Web services

composition and orchestration (see BPEL4WS,

2007).

The services provided by this component can

be divided into two categories:

• The Query Service acts as a management

service for requests originating from user

services, in particular Data Provision Ser-

vices, which can query data from Semantic

Web Services.

• The Composition service is used to create

business choreography from a Processing

request. Such choreography is then executed

by retrieving the relevant data, sending a

request to a Processing Service and returning

the processed data back to the originating

User Service. This service makes use of a

BPEL4WS engine, which creates the busi-

ness process at run-time based on the client’s

request (Figure 15).

As an example of a business process, Figure

16 shows the BPEL orchestration process created

to answer the query of the storyboard described

in Section 4.5 (Jogging Path). Such process is

composed of 4 services’ invocation that allows

downloading data about: traffic, air quality, noise

level, adequate running path. Then a MergeData

service is used to process such data in order to

retrieve the best jogging path, corresponding to

the location where all the indications give good

results, in terms of traffic, air quality, noise level,

and adequate paths.

Figure 15. Scheme of the data search

410

WikiCity

Figure 16. Business process related to the query Jogging Path

Figure 17. Web-services connection scheme

A scheme of the Web-services connection is

depicted in Figure 17.

CONCLUSION

From a conceptual analysis, the benefits of

real-time location-sensitive information to city

inhabitants seem fairly clear, indicating how

this could contribute to the efficiency of vari-

ous real-world situations. Critical aspects have

emerged, however, as to how this new form of

information may impact some situations in terms

of diffusing or concentrating attention of users.

Further analysis of such potential situations will

feed back into the design of the way real-time

location-sensitive information is communicated

and made accessible.

411

WikiCity

While aiming at the construction of a diffused

network structure, we have seen that for the ini-

tial start-up phase a hybrid system is necessary,

which combines the two different approaches of

the centralized database and those located within

the internal network and in the service provid-

ers’ servers.

As such a first step, WikiCity Rome has man-

aged to combine a limited number of different

kinds of real-time data supplied by established

sources, integrating them into an interface that

was successfully used by a large number of

people during a one-night event. A more in-depth

analysis about the results of this pilot project is

still being carried out and will be finalized in

further work.

Upcoming research steps will focus on dis-

tinctive aspects of the overall concept, one of

them focusing on the integration of different

data types for the application in a multimodal

transport system. Without doubt, there is no one

ideal means of transport. Rather, different types

of trips require different means of transport; or,

better, within a constantly changing context, it is

often a combination of different means of trans-

port that leads to the most efficient and effective

implementation of a trip. Relying in such a way on

a combination of different transport systems not

only requires the smooth functioning of each of

those, but also poses crucial requirements on the

interoperability of the systems as well as a coher-

ent and integrated communication of the state of

each system in real-time and their combinatorial

potential to prospective users.

Another direction follows the adequacy of

a WikiCity real-time system for evacuation

purposes in an extended urban area (cf. Nakani-

shi, Ishida, & Koizumi in this volume). In such

emergency scenarios, the possibility for a system

to know the real-time presence of people to be

evacuated is extremely interesting for the deliv-

ery of distinct and possibly different instructions

supplied for a safe evacuation of large numbers

of people, each being considered according to his

or her particular circumstances.

Taking the real-time mapping of urban dynam-

ics to a finer granularity brings us to the consid-

eration of not only means of transport and people

but also the mapping of objects in general. So far

we have been considering mainly one typology

of objects for this purpose: cell phones. However

considering in the context of WikiCity the pos-

sibility of real-time mapping of various types of

objects opens up interesting possibilities. When

considering the sharing or rental of products, for

example (car sharing is a prominent and by now

increasingly well established example, but con-

sider also do-it-yourself tools, sports equipment,

etc.), knowing the location and state of a product

potentially increases the efficiency with which

such a product can be put to use by a large user

group and at the same time addresses issues of

maintenance that may arise from such an intense

usage. Products and services can be supplied to

whoever needs them in that place and in that mo-

ment if their location, availability, and condition

is known in real-time, enabling the creation of a

system of dynamic resource allocation for end

users within the urban context.

In the field of logistics, this approach has been

around for a long time. An object’s position can be

identified throughout entire supply chains, often

across large parts of the globe. This capability has

led to dramatic changes in the way that technologi-

cal resources are used by companies throughout

the production and distribution processes. How

might these systems be useful models for real-time

demand-responsive product and service supply

schemes in an urban context?

Especially this last consideration of directions

toward which to take WikiCity brings up the criti-

cal issues involved in this type of project: privacy

and control. Mapping the status and location of

people and objects in real-time has implications

for an individual who is concerned about reserv-

ing his privacy. Using a non-connected bus with

a generic paper ticket is something quite different

from taking a bus whose position is tracked and

using an electronic ticket that feeds into a system

412

WikiCity

the user’s identity. It alters the visibility of that

specific person to a system that can technically

be read by other systems and individuals, and at

the same time it alters the potential of service

improvements for the specific user and for the

overall transport system.

A critical consideration comes from looking

at the example of the supply-chain management

mentioned above. Thomas Friedman illustrates in

“The World Is Flat” (p. 584) how all the thousands

of parts of his Dell Laptop have come together

during production on the basis of a sophisticated

globalized supply-chain management and points

out how a temporary shortage in the supply of

one component such as a 40-gigabyte hard drive

leads to an immediate relay to the marketing de-

partment which offers a 60-gigabyte hard drive

for the same price over the next 2 hours. Active

demand shaping is the term used for such a pro-

cess enabled by the tight tracking of status and

location (availability for production in this case)

in the production realm. How would this dynamic

translate into the urban context and citizens mov-

ing within and making use of their city? A crucial

aspect of further development in this area will

have to be focused on how to ensure that the

technology of real-time location-based mapping

remains focused on providing better information

for people to base their decisions on instead of

formulating decisions for the people.

Any decision is based on knowledge and

insight in the context in question. The better a

situation and the actual dynamics in place are

known, the better one is able to interact in an

effective way with that situation and open up at

best the implicit potential of that circumstance.

Understanding urban dynamics with the help of

digital technologies that enable real-time and

location-based information is a powerful instru-

ment to support just that, and it will be exciting

to see how this tool can be used in constructive

and inclusive ways for the benefit of a city.

ACKNOWLEDGMENT

We would like to thank Marcus Foth and three

anonymous referees for their helpful sugges-

tions.

REFERENCES

Bassoli A., Brewer J., Martin K., Dourish P.,

Mainwaring S. (2007). Underground Aesthetics:

Rethinking Urban Computing, IEEE Pervasive

Computing, 6(3), 39-–45.

Beer, D., & Burrows, R. (2007). Sociology and,

of and in Web 2.0: Some Initial Considerations.

Sociological Research Online, 12(5).

Berners-Lee T., Hendler J., Lassila O., (2001). The

Semantic Web, Scientific American, May.

BPEL4WS, (2007). Business Process Execution

Language for Web Services version 1.1, http://

www-128.ibm.com/developerworks/library/

specification/ws-bpel/

Calabrese F., Ratti C., (2006). Real-time Rome,

Networks and Communication studies, vol. 20,

n. 3/4.

Calabrese, F., Kloeckl, K., & Ratti, C. (2007).

WikiCity: Real-Time Location-Sensitive tools

for the city. IEEE Pervasive Computing, 6(3),

52-–53.

Deleuze G., Guattari F., (1977). Rizoma. Pratiche

Editrice, Parma-Luca.

Foth, M., Odendaal, N., & Hearn, G. (2007, Oct

15-–16). The View from Everywhere: Towards

an Epistemology for Urbanites. Paper presented

at the 4th International Conference on Intel-

lectual Capital, Knowledge Management and

Organisational Learning (ICICKM), Cape Town,

South Africa.

413

WikiCity

Friedman, T. (2007). The world is flat, release 3.0.

New York : Picador.

Kolbitsch, J., & Maurer, H. (2006). The Transfor-

mation of the Web: How Emerging Communities

Shape the Information we Consume. Journal of

Universal Computer Science, 12(2), 187–-213.

OWL, (2004). Web Ontology Language, http://

www.w3.org/TR/owl-features/.

OWL-S, (2004). Semantic Markup for Web Ser-

vices, http://www.w3.org/Submission/OWL-S/

Oxford (2007). Definition of Real-time, Oxford

English Dictionary, Oxford University press.

Sterling, B. (2005). Shaping Things (Mediaworks

Pamphlets). The MIT Press.

Thom-Santelli J. (2007). Mobile Social Soft-

ware: Facilitating Serendipity or Encouraging

Homogeneity?, IEEE Pervasive Computing,

6(3), 46-–51.

Trevor J., Hilbert D. M. (2007). AnySpot: Per-

vasive Document Access and Sharing, IEEE

Pervasive Computing, 6(3), 76-–84.

W3C, (2007). Semantic Web, http://www.

w3.org/2001/sw/

Wray, S. (1998). On Electronic Civil Disobedi-

ence”. Presented at the Socialist Scholars Confer-

ence March 20, 21, and 22 New York, NY

KEY TERMS

Multimodal Interfaces: Interfaces that allow

user interaction in more than one way such as

visual display, sound, touch, and others.

Real-Time System / Real-Time Control

System: System for the control of a real entity by

means of sensors, intelligence, and actuators

Rhizome: A philosophical network structure,

put forward by Gilles Deleuze and Félix Guat-

tari, in which every part is necessarily connected

with every other part of the system. There are no

preferential connections because every connection

alters the overall network structure. The rhizome

as a flat network is in contrast to arboreal structures

connoted by a hierarchical structure.

Sensor Network: Network of spatially dis-

tributed devices using sensors to cooperatively

monitor physical or environmental conditions

Semantic Web: Extension of the World Wide

Web in which the content is expressed in a way

that is readable by software agents.

Tangible User Interfaces: Interface type that

allows the user to interact with digital information

by acting upon physical elements in the users’

environment.

Wiki: A Wiki is a software that allows users

to collaboratively compose Web pages whose

content is cross-referenced. One of the principles

of the Wiki is that all users can actively create and

edit the content in a continuous and open process

which creates an ever-evolving whole.

ENDNOTES

1 “A SYNCHRONIC SOCIETY synchronizes

multiple histories. In a SYNCHRONIC

SOCIETY, every object worthy of human

or machine consideration generates a small

history. These histories are not dusty ar-

chives locked away on ink and paper. They

are informational resources, manipulable in

real-time.” (Sterling, 2005)2 A CAPTCHA is a program that can tell

whether its user is a human or a computer.

CAPTCHAs are used by many Web sites

to prevent abuse from “bots,” or automated

programs usually written to generate spam

(source http://recaptcha.net).