CRAFT – EPFL
Project CityNotes

A Collaboration between EPFL, CH and Proboscis, UK

Description of Tasks of CRAFT

The following text contains the description of the phases of development connected to the project of collaboration between EPFL and Proboscis. It has to be highlited that proceeding to the phases described here is complementary to the completion of the previous phase, and given the availability of resources on both sides.

Phase 1_ Estimate completion time: 2 months_
Goal of this phase is to adapt the current Urban Tapestries interface to the needs and requirements of the project. Practically an internal module will be implemented (B), which will serve in the client side to access the Global Positioning System (GPS: B) functionality of the phone for a precise positioning. At this stage the client in use is provided by Proboscis, and is implemented in Symbian S.D.K.. In addition to this point we will start building a very specific module, called Smart Layering of Information (SLI: A), which will organise the system messages providing the necessary description for the filetering/retrieval. At this stage this module will be partially working because it will need the elaboration of the algorithm which will follow the analisys of the data provided by experiments. Proboscis will operate on the server side to adapt the log capabilities of the system to take track of all the interactions aspect needed by the SLI module.

Phase 2_ Estimate completion time: 8 months_
The aim of this phase is to port the existing Symbian interface of the client to Java 2 Micro Edition. In this way the client will be able to operate on more phones and more testers will be able to join the experiments running in London. The GPS Module B will be rewritten to fit into the new architecture of the client. New functionalities of the interface may be added to correspond to the implemented filtering capabilities of the SLI module A. This last module will be completed given the results of the pre-experiment done with the system running at phase 1.

Phase 3_ Estimate completion time: 6 months_
The target of this phase will be to complete the client interface with the implementation of a GIS module, hereafter module D, which will consent the network streaming of the maps from the server to the client. An appropriate module for the treatement of the vector data will be implemented both on the client side and on the server side, module D and E.

[Traum1999] Traum, D. R. (1999). Computational models of grounding in collaborative systems. In working notes of AAAI Fall Symposium on Psychological Models of Communication, pages 124–131.
——————–

This paper contains a description of Traum’s Grounding Acts model. He developed this model to address some of the specific deficienses of Clark and Schaefer’s Contribution Model. Particularly, he critics their model because: a) it is not clear that contributions are ever really complete; b) there is no graded evidence of understanding; c) it is difficult to define the initiation of the next relevant contribution; d) it is hard to tell whether a particular utterance is part of the presentation phase or the acceptance phase; e) there is no easy way to tell the “state”of the current contribution while engaged in a conversation. He states that this model is of no use for collaborative systems, and therefore he develops the Grounding Acts model, which collapses the different types of acceptance and extends the building blocks of the units of common ground to those that could be realised with a single utterance thus allowing an agent to track progress of each communication without lookahead.

He defines Discourse Units (DU), rather than Contributions; and Grounding Acts, as the basic building blocks. Each of these is identified with a particular utterance unit and performs a specific function toward the achievement of the common ground.

In the same paper he defines the deficiencies of his own model as: a) the oversimplification of the “grounded or not grounded” distinction; b) the dependancy of the model on the size of the utterance units; c) the difficulty in recognising which act was performed; d) the in-sensitivities to modalities other than spoken language.

After the paper I read by David Traum, I decided to explore more the direction of the inference school, namely Grice and Sperber, because I want to have a taste on the other direction. The code approach seems to be interesting but I have the feeling that is reductive to the extent that cannot be really of use. On the other side I have to explore more in general what the big circle of my framework means. Will see.

Do You Remember? from the album “…But Seriously” by Phil Collins

Giles Lane pointed me on another possible phone for developing the project: the Motorola A1000, available on the market during this quarter. Lots of interesting features, among which the A-GPS support, MIDP 2.0, 24 MBytes of internal memory, plus CARD support.

[link to Motorola]

I tried to sketch out my current understanding of the research framework, based on the discussion we had with Stefano Mastrogiacomo last week. It was impressive to see how few information I have and how empty my mental space is …. 🙁

However, this can give me an insight on what are the main areas to explore. More areas needs to be added to this picture: Ontology theory, Inference Theory, Social Meaning, CSCL theory. This will finally constitute my reasoning protocol.

The map is available in SVG format. A plugin is required.

After a quick look on the internet, I found this cool mobile phone, that may be suitable to develop the test concept of my PhD project. The good features are that:

– is a 3G phone, UMTS and fast data transfer

– it has GPS on board for self positioning

– it is Symbian based, 7.0, J2ME, MIDP 1.0.3

– it has SD card expansion

– It costs 99 euro on the italian market

– …etc

[link at symbian] [link at motorola]

Nico pointed me to the recently upgraded flash interface of UrbanTapestries.

At the moment is still a demo but it ids clean and it works quite reliably. Seems to be a perfect testbed for my project.

My position paper is finally online at this address. This workshop in cognitive semantics and ontology has to del with meaning construction and ontologies. Some of the core questions are:

– What do ontologies, as used in the semantic web and elsewhere, have to do with meaning?

– In particular, where do their predicates get their meanings?

– How do the ontologies become meaningful?

Therefore I will add here these extra bits of details in order to ground this discussion in a common knowledge of my targets and metodologies. I will move from the theoretical level of the driving “research questions” to the ground level of the “architecture description”.

1. Research questions_

Q_ What are the cognitive processes by which people infer elements of the communication, subsequently economizing the process, only considering the history of the receiver/emitter position and the connected communication content?

Sub1_ Can we build an Agent that will build a semantic description of the communication content based on an algorithm constructed on these cognitive processes?

Sub2_Is this autonomous agent able to maximize contextual spatial cues through providing this semantic description of the spatialized communication between peers?

Sub3_How is this description/knowledge reflecting in the way people use the space in their daily life?

2. Experiment_

The hyphothesis of the study will be tested on a number of experimental groups of peers, ideally from 5 to 8 people, using a mobile technology which enables them to attach shared virtual notes to space.

The idea is to give them this technology for a relatively long period of time, namely 6 months, during which some interventions are operated: different algorithms will be subsequently enabled in the systems, allowing the user to interact with an extended set of functionalities.

These functionalities will enable an intelligent retrieval of the messages into the system, based on the users’ actions in the city and based on their communication intents as detected by the system.

The user behavior and communication will be logged at all time. A comparison between the logs of the group without the extended functionalities and the the same group with these functionalities activated will constitute a proof technique towards the raised hypothesis.

3. Functionalities_

In order to have the minimal interaction necessary to provide useful information for the experiment purpose, the system should acknowledge the users’ position in the phisical space. Subsequently, this position should be encoded in a visual representation, namely a 2D map, where the users can make sense of the group movements and messaging in relation to the actual space where they happen to be.

A second core function of the system is the ability of authoring this representation of the shared space, this commonly viewed 2D map, adding SMS-style messages. All the messages in the system, plus the position of the authors, are available to the users.

The subsequent functionality that is needed in the system, is the ability to filter/sort the messages in order to find/track the relevant or nedeed information. This ability will be limited at first and then implemented as the extended functionalities dscribed in the section 2 above.

4. Architecture_

As the main concept of this project is to enquiry for spatialised communication, it is important for the system to be mobile. Therefore, it needs to be embedded in portable computational devices. In addition, the system cannot rely on an ah-hoc network, because it needs constant logs of each participant to enables the extended functionalities described above. Therefore, a central server is needed to aggregate all the messages and interaction of the users.

The system should be able to locate each user, using common technologies available tody, like the GPS (Global Positioning Systems) and /or the Radio localisation (aka CellID) and/or radio triangulation. The sensibility of this positioning is also an issue in regard of the user’s ability to attach a message to a single building. Therefore I estemate this parameter to be circa 10-20 meters in the urban area.

Another feature of this centralised architecture is that enables for a common managment of the shared representation of the space, which may requires lots of computational power and therefore it may not be suitable for the contraints of a mobile devices.

As last point, the portable device has to be non-intrusive: as the user is going to bring this device at all time, for a long period of observation (six months). The goal, in this case, is to use a device which is already present in everyone’s life: a mobile phone. The extra value of running the system on mobile phones is that of haveing a readily available connection to the internet and to the server. The network for Mobile phones is way more extended than any other network freely available.

4.1 Hacking an existing LBS: the MogiMogi game_

Instead of reinventing the wheel an existing Location Based Service has been selected, which incorporates most of the features described above: MogiMogi, the hunting game. The idea is to hack its software platform (with a formal agreement with their developers) and implement the original modules to complete the set of functionalities described above.

Aim of the game of MogiMogi is to walk around, finding virtual objects attached to actual locations, collect these objects subsequently raising the connected user score.

The system, built and implemented for the Japanese market (http://au.mogimogi.com), runs on J2ME mobile phones, which in Japan are GPS enabled, and is able to localise the users by the means discussed above. Also, the system provides a rough interferface with the virtual space of the game board by the mean of a “radar” representation. Finally the system implements a communication API, a GIS (Geographical Information System) engine and an “Object” engine (Players or Modules), all of which are recorded in an SQL database.

4.2 Steps towards an adaptation_

In order to bend MogiMogi platform to the architecture discussed above the following adaptation is needed: a) adapt the localisation engine to the specific architecture of the choosen mobile network and geographical space; b) build a 2D representation of the city space to be used in the client; c) add authoring functionalities to the client side; d) logging all the interactions of the system into an appropriate database with the appropriate structure; e) customising appropriate interaction in the system to match with the extended functionalities discussed above.

a) The GIS database has to be adapted to match the geographical space where the experiment will be held. In addition, there should be an adaptation of the positioning engine which should be triggered on the GSM network offerend in the same area.

b) In the GIS engine an extra module is needed that may output a light graphical representation of the space (i.e., Scalable Vector Graphics – SVG), which can be offered to a specific Java servlet to serve the J2ME interface of the clients. This module should also be able to select the appropriate level of definition of the space offered by the data set.

c) The J2ME interface of the client should be completely rewritten to be able to display the 2D representation of the city space plus to be able to offer the communication functionality discussed above. The interface should allow the user to attach the message to his/her specific position at the place of origin and/or to a chosen point of interest. This may also mean to build a brand new SQL database for archiving the messages and organising them with the appropriate categorisation.

d) In addition to the communication content of the messages, other information need to be stored for offering the extended functionalities discussed above. This information may include the history of the position of the emitter and the receiver of the message, the related messaging happening at the same time, the threads or answers generated in the same context, etc. This information may also be organised in “layers”, to be displayed with the graphical visualization sent to the client (see attached picture). These logs may be contained in the same SQL structure that hosts the messages as per point c.

e) Two main kind of Python scripts should be realised. The first group of scripts should add extra descriptors to each message according to a theory defined by the hypothesis raised at point 1 and using the logs contained in the SQL database of point c and d. The second group of scripts should implement the extended functionalities discussed at point 2. Essentially they should be activated by the users interactions or by the users search in the messages contained in the system.

I am really interested in this conference about Formal Ontology and Cognitive Semantics. particularly i am interested in attending the workshop that is orgenised by Werner Kuhn, who wrote interesting articles about using ontologies in geographical contexts.