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.
(0)
Recent Comments