Experimental tribe: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 25: | Line 25: | ||
|field_project_news_site=http://doc.xtribe.eu | |field_project_news_site=http://doc.xtribe.eu | ||
|field_socialsoftware_sites=N/A | |field_socialsoftware_sites=N/A | ||
|field_system_overview=The Platform In Depth | |field_system_overview=XTribe has been designed with a modular structure through which most of the complexity associated to running an experiment is hidden into a Main Server, while the experimentalist is left with the only duty of devising a suitable interface for the actual experiment. In this way most of the coding difficulties related to the realization of a dynamic web application are already taken care by the ET Server and the realization of an experiment should be as easy as constructing a webpage with the main utilities for it. | ||
|field_completion_level=Medium | |||
|field_last_edition=2018/03/08 | |||
}} | |||
{{bibliography | |||
|field_author=S. Caminiti, F. Tria, A. Sirbu, V. Servedio, V. Loreto, P. Gravino, C. Cicali | |||
|field_date=2013 | |||
|field_title=XTribe: A web-based social computation platform | |||
|field_reference=S. Caminiti, F. Tria, A. Sirbu, V. Servedio, V. Loreto, P. Gravino, C. Cicali, XTribe: A web- , IEEE Proceedings of the Third International Conference on Social Computing and its Applications (2013) | |||
|field_link=http://people.cs.umass.edu/~wallach/workshops/nips2011css/papers/Cicali.pdf | |||
|field_publication_type=Conference papers | |||
}} | |||
{{Free text}} | |||
Long citation from Caminiti et al. 2013:2). ''Should be documented apart as CS projects'' | |||
As case-study experiments, two games are already implemented in the platform: Nexicon and Blindate. Nexicon is a collaborative word association game: two players, who cannot communicate with each other, have to write a set of words they associate with a given word (the same for both players). They win as soon as both of them write a common word. The scientific outcome of the game is the possibility of constructing a sort of perceptual network of word association, much along the same line of well known word association databases. | |||
Blindate, instead, is a collaborative game, very close to the well known Schelling’s Games first introduced in the early ’60s [17]. In Schelling’s original version (one of many similar problems), two players, unable to communicate with each other, were asked to find a point on a map where to meet, i.e. they had to find a strategically salient “focal point” among a potential infinity of solutions to the coordination problem. Since Schelling’s seminal contribution, many versions of “Schelling games” have been used to investigate strategic salience, i.e. the individual ability to guess recursively what the other guesses that he will guess is salient, an so forth [18, 19]. In our custom version, two players are shown a portion of the map of a real city and are asked to point a location in a given area where they think it is more likely to meet each other. The reward is a score depending inversely on the distance between the guesses. In addition, after playing, participants may optionally explain with suitable tag words the reason of their choice. The purpose of the experiment is to get an annotated map of the focal points of the city. | |||
== The Platform In Depth == | |||
XTribe has been designed with a modular structure through which most of the complexity associated to running an experiment is hidden into a Main Server, while the experimentalist is left with the only duty of devising a suitable interface for the actual experiment. In this way most of the coding difficulties related to the realization of a dynamic web application are already taken care by the ET Server and the realization of an experiment should be as easy as constructing a webpage with the main utilities for it. | XTribe has been designed with a modular structure through which most of the complexity associated to running an experiment is hidden into a Main Server, while the experimentalist is left with the only duty of devising a suitable interface for the actual experiment. In this way most of the coding difficulties related to the realization of a dynamic web application are already taken care by the ET Server and the realization of an experiment should be as easy as constructing a webpage with the main utilities for it. | ||
Interface and Game Manager | Interface and Game Manager | ||
A game, an experiment can be imagined as a combination of two intercommunicating parts: the interface and the Game Manager (GM). The interface is what is visible to players, and will interact with them. The GM is represented by those functional parts that process the action of the players. | A game, an experiment can be imagined as a combination of two intercommunicating parts: the interface and the Game Manager (GM). The interface is what is visible to players, and will interact with them. The GM is represented by those functional parts that process the action of the players. | ||
But even if the researcher writes down the code for both the interface and the GM, he is still far from the creation of a web game. Here, XTribe comes in handy. In the first place, the platform will host the game interface. The platform will offer a page for the description of the game rules, compiled by the researcher, from which players can access and play the game. Instead, the GM part of the game will be hosted by the researcher. In this way he can directly collect the data in real time. | But even if the researcher writes down the code for both the interface and the GM, he is still far from the creation of a web game. Here, XTribe comes in handy. In the first place, the platform will host the game interface. The platform will offer a page for the description of the game rules, compiled by the researcher, from which players can access and play the game. Instead, the GM part of the game will be hosted by the researcher. In this way he can directly collect the data in real time. | ||
Users and Data | Users and Data | ||
Since the game has been created for research purposes, the researcher is interested in all sort of statistics related to players. Beside this, he may also be interested in filtering players for specific purposes, e.g. according to their age, gender, geographical location, nationality, etc. To this end, XTribe handles a user registry in which players will be allowed to register, if required, and play while the system would maintain all the information about them, such as scores, ranks, etc. together with biographical information. If needed, this information should be send to the GM, i.e. to the experimentalist. | Since the game has been created for research purposes, the researcher is interested in all sort of statistics related to players. Beside this, he may also be interested in filtering players for specific purposes, e.g. according to their age, gender, geographical location, nationality, etc. To this end, XTribe handles a user registry in which players will be allowed to register, if required, and play while the system would maintain all the information about them, such as scores, ranks, etc. together with biographical information. If needed, this information should be send to the GM, i.e. to the experimentalist. | ||
Furthermore, based on this information, when properly configured, the system will grant the access to the game only to certain profiles. Being in charge of the handling of the user registry, the system would also spare the researcher from dealing with privacy and security issues since all data will be properly anonymized and, possibly, encrypted. However, by default, it is still possible for unregistered users to access the games. Filters are applied only if set by the researcher. | Furthermore, based on this information, when properly configured, the system will grant the access to the game only to certain profiles. Being in charge of the handling of the user registry, the system would also spare the researcher from dealing with privacy and security issues since all data will be properly anonymized and, possibly, encrypted. However, by default, it is still possible for unregistered users to access the games. Filters are applied only if set by the researcher. | ||
... and this is how it begins! | ... and this is how it begins! | ||
Once the players have accessed the game, the system will create an instance of the game. There may be given rules for the game to start. A basic rule is the number of players: a certain number of players have to be reached to start a game. There may be also different constraints such as locations, age, sex, etc. As soon as there is a sufficient number of players satisfying the grouping constraints, the game starts. | Once the players have accessed the game, the system will create an instance of the game. There may be given rules for the game to start. A basic rule is the number of players: a certain number of players have to be reached to start a game. There may be also different constraints such as locations, age, sex, etc. As soon as there is a sufficient number of players satisfying the grouping constraints, the game starts. | ||
The Game | The Game | ||
The interface will transmit the actions of the players to the GM, but all messages will pass through the system, which will group them by match instance number after having anonymized them. The GM will then receive the data, will elaborate them and will send the results of the elaboration back to the system, which in turn will transmit them to the interfaces. Obviously, it will also save the data of interest locally (the GM runs on the researcher’s machine). The platform will also handle errors and exceptions. For instance, if the match aborts because one of the players disconnected, the system will detect it, will notify the abort to the remaining players and will send a message to the GM. Since there is no direct communication between GM and interface, the GM will experience no trouble at all. All these features, especially the user registry and the instance handling, usually require a lot of coding, quantified in time and money, to be realized. Within XTribe, they can be realized with a straightforward procedure. After the configuration, the system will automatically take care of all. What researchers have to do is writing the code of the interface and of the GM. | The interface will transmit the actions of the players to the GM, but all messages will pass through the system, which will group them by match instance number after having anonymized them. The GM will then receive the data, will elaborate them and will send the results of the elaboration back to the system, which in turn will transmit them to the interfaces. Obviously, it will also save the data of interest locally (the GM runs on the researcher’s machine). The platform will also handle errors and exceptions. For instance, if the match aborts because one of the players disconnected, the system will detect it, will notify the abort to the remaining players and will send a message to the GM. Since there is no direct communication between GM and interface, the GM will experience no trouble at all. All these features, especially the user registry and the instance handling, usually require a lot of coding, quantified in time and money, to be realized. Within XTribe, they can be realized with a straightforward procedure. After the configuration, the system will automatically take care of all. What researchers have to do is writing the code of the interface and of the GM. | ||
Yes, but how? | Yes, but how? | ||
The interface has to be structured as a web page with plenty of freedom in using HTML, CSS, Flash, etc., while the interaction between the interface and the system has to be achieved by means of the ET API, which are internally developed as Javascript functions. With this simple set of functions the interface will interact with the platform and, through it, with the GM. Basically, the GM has to work as a HTTP server hosted on the researcher’s machine. The communication with the system takes place through the HTTP protocol and all messages are coded in JSON format. Besides a restricted set of system messages, the game internal protocol is fully elaborated by the researcher. The following parts contains some tutorials aimed at introducing the various concept related with the XTribe platform. If you haven't done yet, go on XTribe and play some of the game available there. | The interface has to be structured as a web page with plenty of freedom in using HTML, CSS, Flash, etc., while the interaction between the interface and the system has to be achieved by means of the ET API, which are internally developed as Javascript functions. With this simple set of functions the interface will interact with the platform and, through it, with the GM. Basically, the GM has to work as a HTTP server hosted on the researcher’s machine. The communication with the system takes place through the HTTP protocol and all messages are coded in JSON format. Besides a restricted set of system messages, the game internal protocol is fully elaborated by the researcher. The following parts contains some tutorials aimed at introducing the various concept related with the XTribe platform. If you haven't done yet, go on XTribe and play some of the game available there. | ||
Latest revision as of 20:01, 8 March 2018
Cs Portal > List of citizen science infrastructures > Experimental tribe - Xtribe -(2018/03/08)
IDENTIFICATION
- Beta start date : N/A
- End date :
⇳ Description Experimental tribe is a web platform for gaming and social computation. It helps researchers to realize web games/experiments and it let people join, while enjoying, the scientific research. ➠ Purpose Experimental Tribe is a web platform designed for scientific gaming and social computation. In the last few years the Web has been progressively acquiring the status of an infrastructure for “social computing” that allows researchers to coordinate the cognitive abilities of users in online communities, and steer the collective action towards predefined goals. This general trend is also triggering the adoption of web-games as a very interesting laboratory to run experiments in the social-sciences and whenever the peculiar human computation abilities are crucially required for research purposes.
Xtribe is run by a research team focused on the investigation of dynamical processes involving human beings, a series of research topics gathered under the denomination of Social Dynamics. The research team recently got funded by the Templeton Foundation for a project on "Unfolding the dynamics of creativity, novelties and innovation" .
More about the research project:
The project addresses the dynamics of novelties - a fundamental factor in the evolution of human societies, biological systems and technology- with the aim to unfold and quantify the underlying mechanisms through which creativity emerges and innovations diffuse, compete and stabilize. The project is timely due to the availability of extensive longitudinal records of human, social, biological and technological evolution. We shall exploit the unique opportunity offered by the combination of ICT tools for social computation with powerful analytical and modeling tools, by blending, in a unitary interdisciplinary effort, three main activities: web-based experiments, data science and theoretical modeling. Through this experimental, mathematical and computational framework we aim at providing the scientific community with a quantitative understanding of the determinants of creativity and innovation as well as a solid overarching scientific framework describing creativity in a quantitative and operational way. We hope to stimulate a bundle of new research lines in multiple academic and non-academic communities interested in quantifying and controlling the processes underlying creativity and innovation. By unveiling and quantifying the complex ecology of creativity and innovation, we also expect to impact sectors - education, learning, research, social challenges- where creativity and innovation are much needed fuels.
COMMUNITY
- Communication:
- Social Network: N/A
- Main news site: http://doc.xtribe.eu
- Visibility of member profiles:: N/A
- Member profile elements:
⏣ Description
DEVELOPERS
- Uses Citizen science software:Citizen science custom software
- Provides online tool to create applications: yes
- Provides support team for development: N/A
- Provides documentation for development and hosting: yes
Rome, Italy
♜ DEVELOPERS TEAM
Official team page:
Leader: Vittorio Loreto
Contact: Vittorio Loreto http://socialdynamics.it/vittorioloreto/
+ Information about the team
OVERVIEW
▣ SYSTEM OVERVIEW
XTribe has been designed with a modular structure through which most of the complexity associated to running an experiment is hidden into a Main Server, while the experimentalist is left with the only duty of devising a suitable interface for the actual experiment. In this way most of the coding difficulties related to the realization of a dynamic web application are already taken care by the ET Server and the realization of an experiment should be as easy as constructing a webpage with the main utilities for it.
| BIBLIOGRAPHY |
Long citation from Caminiti et al. 2013:2). Should be documented apart as CS projects
As case-study experiments, two games are already implemented in the platform: Nexicon and Blindate. Nexicon is a collaborative word association game: two players, who cannot communicate with each other, have to write a set of words they associate with a given word (the same for both players). They win as soon as both of them write a common word. The scientific outcome of the game is the possibility of constructing a sort of perceptual network of word association, much along the same line of well known word association databases. Blindate, instead, is a collaborative game, very close to the well known Schelling’s Games first introduced in the early ’60s [17]. In Schelling’s original version (one of many similar problems), two players, unable to communicate with each other, were asked to find a point on a map where to meet, i.e. they had to find a strategically salient “focal point” among a potential infinity of solutions to the coordination problem. Since Schelling’s seminal contribution, many versions of “Schelling games” have been used to investigate strategic salience, i.e. the individual ability to guess recursively what the other guesses that he will guess is salient, an so forth [18, 19]. In our custom version, two players are shown a portion of the map of a real city and are asked to point a location in a given area where they think it is more likely to meet each other. The reward is a score depending inversely on the distance between the guesses. In addition, after playing, participants may optionally explain with suitable tag words the reason of their choice. The purpose of the experiment is to get an annotated map of the focal points of the city.
The Platform In Depth
XTribe has been designed with a modular structure through which most of the complexity associated to running an experiment is hidden into a Main Server, while the experimentalist is left with the only duty of devising a suitable interface for the actual experiment. In this way most of the coding difficulties related to the realization of a dynamic web application are already taken care by the ET Server and the realization of an experiment should be as easy as constructing a webpage with the main utilities for it.
Interface and Game Manager
A game, an experiment can be imagined as a combination of two intercommunicating parts: the interface and the Game Manager (GM). The interface is what is visible to players, and will interact with them. The GM is represented by those functional parts that process the action of the players. But even if the researcher writes down the code for both the interface and the GM, he is still far from the creation of a web game. Here, XTribe comes in handy. In the first place, the platform will host the game interface. The platform will offer a page for the description of the game rules, compiled by the researcher, from which players can access and play the game. Instead, the GM part of the game will be hosted by the researcher. In this way he can directly collect the data in real time.
Users and Data
Since the game has been created for research purposes, the researcher is interested in all sort of statistics related to players. Beside this, he may also be interested in filtering players for specific purposes, e.g. according to their age, gender, geographical location, nationality, etc. To this end, XTribe handles a user registry in which players will be allowed to register, if required, and play while the system would maintain all the information about them, such as scores, ranks, etc. together with biographical information. If needed, this information should be send to the GM, i.e. to the experimentalist. Furthermore, based on this information, when properly configured, the system will grant the access to the game only to certain profiles. Being in charge of the handling of the user registry, the system would also spare the researcher from dealing with privacy and security issues since all data will be properly anonymized and, possibly, encrypted. However, by default, it is still possible for unregistered users to access the games. Filters are applied only if set by the researcher.
... and this is how it begins!
Once the players have accessed the game, the system will create an instance of the game. There may be given rules for the game to start. A basic rule is the number of players: a certain number of players have to be reached to start a game. There may be also different constraints such as locations, age, sex, etc. As soon as there is a sufficient number of players satisfying the grouping constraints, the game starts.
The Game
The interface will transmit the actions of the players to the GM, but all messages will pass through the system, which will group them by match instance number after having anonymized them. The GM will then receive the data, will elaborate them and will send the results of the elaboration back to the system, which in turn will transmit them to the interfaces. Obviously, it will also save the data of interest locally (the GM runs on the researcher’s machine). The platform will also handle errors and exceptions. For instance, if the match aborts because one of the players disconnected, the system will detect it, will notify the abort to the remaining players and will send a message to the GM. Since there is no direct communication between GM and interface, the GM will experience no trouble at all. All these features, especially the user registry and the instance handling, usually require a lot of coding, quantified in time and money, to be realized. Within XTribe, they can be realized with a straightforward procedure. After the configuration, the system will automatically take care of all. What researchers have to do is writing the code of the interface and of the GM.
Yes, but how?
The interface has to be structured as a web page with plenty of freedom in using HTML, CSS, Flash, etc., while the interaction between the interface and the system has to be achieved by means of the ET API, which are internally developed as Javascript functions. With this simple set of functions the interface will interact with the platform and, through it, with the GM. Basically, the GM has to work as a HTTP server hosted on the researcher’s machine. The communication with the system takes place through the HTTP protocol and all messages are coded in JSON format. Besides a restricted set of system messages, the game internal protocol is fully elaborated by the researcher. The following parts contains some tutorials aimed at introducing the various concept related with the XTribe platform. If you haven't done yet, go on XTribe and play some of the game available there.