Post on 03-Oct-2020
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).