Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
Geo-Social Model: A Conceptual Framework forReal-time Geocollaboration
Zheng (Eric) Chang and Songnian Li
Department of Civil Engineering, Ryerson University
AbstractSynchronous geocollaboration helps geographically dispersed people to work together in a shared geospa-tial environment. Its real-time nature, multiple users’ interaction and diversity of work context imposesome special social, organizational and technological requirements, making the development of such real-time geocollaboration systems a challenging task. A conceptual framework is therefore needed to specifyand describe what synchronous geocollaboration is, considering its social, spatial and technical aspects.The geo-social model presented in this article describes a conceptual framework for synchronous geocol-laboration systems addressing the above aspects, identifies the core elements of the system and describeshow these elements collaborate with each other. This model is presented using application-level ontologyand is then applied to a multi-agent system based prototype in which multiple users can interact andnegotiate in a shared 3D geospatial environment.
1 Introduction
The American Heritage Dictionary of the English Language defines collaboration thus: “Towork jointly with others or together especially in an intellectual effort.” In the geographicalinformation science (GIS) community, several terms have been used to describe group intellec-tual works. These include geocollaboration (MacEachren and Brewer 2004, Cai 2005), col-laborative geographical information systems (CGIS) (Churcher and Churcher 1996, Joneset al. 1997, Li and Coleman 2003, Balram and Dragicevic 2006), and group spatial decisionsupport systems (GSDSS) (Armstrong and Densham 1995, Nyerges 1999, MacEachren 2001,Jankowski and Nyerges 2001, Rinner 2001). MacEachren and Brewer (2004) considercomputer-supported geocollaboration to involve a committed effort on the part of two ormore people to use geospatial information technologies to collectively frame and address atask involving geospatial information. In order to maintain consistency, the term, geocollabo-ration, is used in this article.
Geocollaboration closely relates to the concept of computer-supported cooperative work(CSCW). CSCW, through its technological implementation, groupware, supports a group ofpeople engaged in a common task (or goal) and provides an interface to a shared environment(Ellis et al. 1991). Groupware may be defined as “technology that communicates and organ-izes unpredictable information allowing dynamic groups to interact across time and space”(Cameron et al. 1995). In both academia and industry, various groupware prototypes andproducts have emerged, each providing a set of functions designed to support a particular
Address for correspondence: Zheng (Eric) Chang, Department of Civil Engineering, Ryerson University, 350 Victoria St., Toronto,Ontario, Canada M5B 2K3. E-mail: [email protected]: This work was supported by the National Science and Engineering Research Council (NSERC) of Canada (grantnumber 250346-05); and the GEOIDE Network of Excellence (project SLM-DFM# 15).
bs_bs_banner
Research Article Transactions in GIS, 2013, 17(2): 182–205
© 2012 Blackwell Publishing Ltd doi: 10.1111/j.1467-9671.2012.01352.x
cooperative work situation or a particular range of cooperative work situations. Cooperativework settings are often diverse in terms of tasks, duration, group, organizational context andculture (Hinssen 1998). However, they are usually classified as one of four situations accordingto the temporal and spatial dimensions (Johansen 1998, Dix 1996): (1) same time (synchro-nous or real-time) and same place (co-located); (2) different time (asynchronous) and sameplace; (3) different time and different place (distributed); or (4) same time and different place.For example, the social network services (SNS) such as Facebook and instant messagingsystems such as Windows Live Messenger are usually considered as a tool for Situations 3 and4, respectively. While real-time synchronous geocollaboration includes both Scenario 1 and 4,this article focuses on supporting same time collaboration in different places.
The real-time, different places type of geocollaboration, however, is more complex thanSNS systems and has its unique features and/or challenges related to geographical references,involvement of social factors and technical implementation issues. For example, in a typicalreal-time, synchronous geocollaboration application such as virtual emergency managementand real-time vehicle tracking systems, the geographically distributed people can work in ashared 2D or 3D virtual geospatial workspace and are capable of knowing other remotepeers’ operations to the environment and sharing information in real time. Sharing operationsand information requires real-time, multi-cast data transmissions to keep consistent graphicaluser interfaces (GUI) and geographical representations, and to synchronize spatial data. Mul-tiple users’ operations to the system also require a mechanism to manage the conflicts so thatthe complicated interactions among users can work smoothly together. The mechanismusually relates to the roles of the users, the rules and even the workflows in the context to besupported, which collectively form the social aspects of the system. The real-time multicastdata transmission distinguishes this system from traditional client- or browser-server systems.Special architectures such as centralized architecture and replicated architecture might beapplied to this system (Dewan 1999, Suthers 2001). All these features separate our develop-ment from that of most PPGIS and other types of geocollaboration systems and make thesystem design and development complicated and unique.
A conceptual framework is therefore needed for the proposed real-time 3D geocollabora-tion environment to answer the following questions:
1. What are the special functions and usability for this type of system compared to tradi-tional and mainstream 3D GIS systems, PPGIS and other collaborative systems?
2. What are the special elements that need to be identified to help the design and develop-ment of this type of system when considering it as a specific type of real-time collaborativesystem?
3. How can the system be designed and developed to realize the capability of real-time col-laboration on geospatial data?
Geocollaboration often faces diverse application contexts. Real-time, synchronous geocol-laboration, as part of normally complex geocollaboration workflows, is no exception.However, with a focus of “real-time” it is possible to abstract and define requirements ofapplications that require real-time, synchronous geocollaboration. For example, group meet-ings have a similar workflow and features in both urban planning and geology and miningcontexts. A conceptual framework can then be developed to support the design and develop-ment of geocollaboration applications because they all share some common characteristics.
This article presents such a conceptual framework to identify these special features andprovides a roadmap or guidelines for the design and development of a real-time geocollabora-tion system. The remainder of this article includes the following sections: the next section
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 183
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
presents a review of the work related to geocollaboration systems and conceptual frameworks;a case study in urban planning is analyzed and the simulation of a virtual group meeting isthen derived; the geo-social model is obtained through generalizing the above analysis; thismodel is presented as an application-level ontology and implemented in a multi-agent method;and finally, user testing and evaluation are discussed to refine the geo-social model, followedby some conclusions.
2 Related Work
This section includes two parts: a related systems review and a related conceptual frameworksreview. The aim of the former is to obtain the capabilities and requirements of basic real-timegeocollaboration, while the aim of the latter is to understand the artifacts of existing geocol-laboration frameworks and decide whether they provide sufficient support to real-time, syn-chronous collaboration.
2.1 Review of Related Systems
There are many collaborative systems, explicitly or implicitly, labeled under groupware orCSCW (computer-supported cooperative work). Depending on their purposes, the level of col-laboration functionality varies. Example systems include computer conferencing systems,instant messaging systems, co-authoring systems, and social network sites (SNS) (Table 1; for amore detailed review see Li 2006). For example, social network sites such as Facebook,Twitter and Flickr are examples of collaborative systems. They provide a virtual communitywith collaboration functions such as networks of friends listings (showing a person’s “innercircle”), person surfing, private messaging, discussion forums or communities, events manage-ment, blogging, commenting (sometimes as endorsements on people’s profiles), and mediauploading (Breslin et al. 2007). However, not many systems are explicitly “geospatial”, i.e.handling geospatial data, tasks and workflows.
Geocollaboration systems or collaborative GISs not only have similar functions to SNSbut also provide a geo-referenced spatial platform/workplace for sharing. The related systemshave two main types, Public Participation GIS (PPGIS) and Real-time (or Synchronous) Col-laborative GIS. While PPGIS may possess real-time, synchronous GIS functions, in most exist-ing PPGIS and related research these functions rarely exist. For example, Tang et al. (2005)and Li et al. (2007) developed similar PPGIS prototypes, GeoDF and GeoVPMS, with opensources. In these applications, some typical features include email/feedback forms, sketchingand annotation, map attachments, geo-referenced comments and an online discussion forum.Rinner (2001) also proposed and developed a GIS-based argumentation map, Argoomap,which supports online discussion and planning based on Google Map. ArgooMap was cus-tomized as ParticipatoryGIS.com to address simultaneously deliberative and analytic dimen-sions of spatial decision-making and planning in an integrated and cohesive fashion(Boroushaki and Malczewski 2009). Although users in these systems can concentrate on thesame topic and area of interest (AOI), the users’ GIS environments, such as map extent andscale, are different.
On the other hand, the studies on Real-time Collaborative GIS focus on real-time sharingand/or synchronization of geospatial data, graphical views and some basic spatial operationson the view such as zoom, pan and textual/graphical annotation. The early efforts, e.g.GroupArc (Churcher and Churcher 1996), Habanero (Chabert et al. 1998) and Toucan Navi-
184 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
gate (InfoPatterns 2007), share not only the geographical data but also the users’ viewpointsand even the behaviors such as operations to the data and views. These systems focused prima-rily on combining GIS with groupware software. They implemented the typical methods forreal-time collaborative GIS, a commercial GIS system with a groupware extension (e.g.GroupArc: Arcinfo + GroupKit) or a groupware environment embedding a GIS component(e.g. Groove Framework and Toucan, Habanero and GIS viewer). However, Cai (2005) arguesthat these two approaches are equally bad strategies for geo-collaborative applications becauseof their heavy dependency on one or more particular CSCW, GIS, or other involved softwaresystems, which causes difficulties in terms of deployment, maintenance and adaptation.
There are also some more recent efforts related to the design and implementation of real-time collaborative mapping/GIS technologies. For example, based on a technology developedby Consultants TGIS (Consultants TGIS Project: http://www.geoconnections.org/projects/geoinnovations/2002/TGIS/index.htm), PCI Geomatics developed and released a GeoConfer-ence product (http://old.pcigeomatics.com/products/tgis.html), which allows users to share(viewing and annotating) 2D maps and images with distant colleagues and clients in real timeduring teleconferencing. Butt and Li (2012) used open source solutions to develop a real-time2D collaborative mapping component that can be accessed online within an e-meeting system.
Table 1 Summary of groupware systems
Category System Cases Collaborative Function Descriptions
Computerconferencingand instantmessagingsystems
WebEx, ETeam, • Setting up sessions, audio, video, sharedapplication connections
• Integration of other media (phone, videoand text chat)
• Providing text-based computer-mediatedchats between users
• Each letter or sentence that is typed isimmediately observable on the screens ofother users after clicking Return key
MSN, Yahoomessage,QQ message
SocialNetworkingSites
MySpace,Facebook
• Network of friends listing and searching• Private messaging• Discussion forums or communities• Events management• Blogging• Commenting
Co-authoringsystems
MicrosoftGROVE,CoWord
• Different phases of authoring, e.g.brainstorming, doing research, planning,writing, and reviewing
• Simultaneous document editing and/orsequential document editing
• Annotations, versions and revisions• Communication between authors about
the document or the authoring process• Coordination of the authoring process
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 185
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
However, they are limited to 2D, with inadequate empirical studies addressing the synchro-nous collaboration and real-time map sharing mechanism.
In summary, the core feature of the real-time geocollaboration system is a shared geo-graphical workspace, in which users can communicate and collaborate with each other usingInternet access, sharing the geographical data, the visualization, the Graphic User Interface(GUI), and even the application.
2.2 Review of Conceptual Frameworks
A number of conceptual frameworks have been developed, providing a guide to describe howthe different people work together mainly within asynchronous collaborative environments.Dragicevic and Balram (2004) made a more specific effort in structuring and managing distrib-uted planning processes with a Web-based collaborative spatial Delphi framework, in whichremote users can share maps, annotation and text comments at the same or different times.Cognitive mapping, the Delphi procedure, and consensus approaches are the main componentsintegrated to structure a shared virtual space for problem solving and planning. They also pre-sented a collaborative modeling framework with agent UML (AUML) to solve the problemswith more complex interaction between natural and human systems (Balram and Dragicevic2006).
Nyerges and Jankowski (Nyerges 1999, Jankowski and Nyerges 2001) were concernedabout the development and/or integration of group-based GIS technology with other computertechnologies to facilitate group problem-solving, scientific visualization and decision-making;all of them have an inherently geographical character. They used the enhanced adaptive struc-turation theory (EAST) and its enhanced successor, the EAST-2 framework, to describe signifi-cant issues for characterizing group decision-making (Jankowski and Nyerges 2001, 2003).
Antunes and Andre (2006) developed a conceptual framework for people in different loca-tions, gathering geographically related data in the field and sharing knowledge in geology andmining process. Their conceptual framework has five elements: places, teams, tasks, artifactsand geo-referenced knowledge. The related prototype was also developed, aiming at increasingthe productivity of the geological mapping process followed by a national agency with compe-tence in this area.
Although the above studies developed different conceptual frameworks in different workcontexts, they are not involved in real-time geocollaboration situations, such as a distributedgroup-meeting situation, which supports geographically dispersed people simultaneouslyworking together. Our review of the literature found that no conceptual framework providesclear descriptions of real-time, synchronous geocollaboration. However, their researchmethods were useful for developing our synchronous collaboration framework. The concep-tual frameworks for geocollaboration are mainly drawn from two aspects: the social/institutional aspect and the technological aspect. The former relates to social structures such asrules, policy, social norms and domain characteristics. The latter relates to technologicalsupport such as current IT technologies, GIS software and decision-making tools for theformer aspect.
3 Methodology
The conceptual framework is developed through an iterative process (see Figure 1) by repeat-ing rounds of requirements analysis, modeling and feedback from examining applications, pro-totype and user testing results.
186 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
An initial framework was developed based on a literature review and case study. It wasthen modeled and abstracted as a Geo-Social Model. The prototype was subsequently devel-oped based on this framework. Through user testing and evaluation, the framework wasrefined and some observations were drawn from the development process. The entire processis further explained as follows:
1. Obtaining the basic requirements from literature review and case study: Both functionaland non-functional requirements were learned and specified through the literature reviewand analysis of an existing urban planning case for airport site selection. This is necessarybecause few real-time geocollaboration systems are available in either research or marketsettings.
2. Simulating a virtual group meeting: Since the urban planning case was processed the tradi-tional way, different people came to a conference room to discuss the issues about theairport selection. We simulated this group meeting by mapping the requirements, tasksand procedures into a virtual group meeting environment. In this virtual environment, weassumed that all the participants had access to the basic real-time geocollaboration func-tions. Also, we assumed that the users were able not only to share the geo-referencedairport site maps but also to perform all the documented activities in the virtualenvironment.
3. Modeling geo-social elements and their relations: The core elements for real-time geocol-laboration were derived from this simulation.
4. Prototyping with the multi-agent method: A prototype with real-time geocollaborationcapability was implemented using a multi-agent system development platform namedJADE (JADE 2011).
5. Testing and evaluating the prototype and refining the framework: The small user groupmethod was adopted to test the prototype against the framework. The feedback of thisstep was used to further refine the geo-social model.
3.1 Case Study: Learning from a Real-world Problem
The purpose of the case study was to supplement our understanding, established with a litera-ture review, on how a small group of people work together during group meetings and to
1 Literature Review and
Case study
2 Simulate virtual
group meeting
3 Modeling Elements:
Geo-social Model
4 Prototype with
multi-agent method
5 User testing and
evaluation
Figure 1 The development process of the conceptual framework
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 187
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
model meeting processes. The study helped develop a mock-up scenario to simulate themeeting processes, create a shared geospatial environment and identify the main elements ofthat environment. The mock-up scenario allowed us to collect some real-time collaborationcases to use for developing the geo-social model. For this purpose, a project for airport siteselection was selected and studied. The main materials of the case study analyzed were thegroup meeting minutes and related documentation. More information on this project may befound in the Wood River Region Airport Site Selection and Feasibility Study Report (FMAA2006). The focus of the study was on group meetings, rather than the overall site selectionprocesses that normally drive planning practices.
Site selection problems have typical scenarios and group meetings, which involve differentpeople working towards a common goal in real time. A typical investigation comprises a thor-ough examination of all pertinent factors, such as existing and foreseen land use planning,characteristics of wind and weather conditions, operational and safety aspects, interferencewith the existing road networks, earthworks, construction and expropriation costs, as well asenvironmental and socio-economic impacts. Group meetings play an important role in theexchange of opinions, in discussing solutions and in making decisions. They occur in nearlyevery step such as establishing site selection criteria, commencing discussions with the cus-tomer agency and community, shortlisting selections and conducting detailed site evaluation(GSA 2011). Usually there are two kinds of group meetings in the planning process: “smallgroup” meetings for internal and invited people, and public hearings.
A small group meeting is a typical use case of real-time collaboration, in which forexample participants will communicate with each other, share common work context towardsthe same understanding on a specific topic, and finally make a decision. Participants mayassume different roles. The chair of a meeting is in charge of the meeting and coordinates thespeakers’ activities. The speakers are in control of the microphone and demo equipment. Theothers just watch the meeting and may provide feedback.
The whole process of a group meeting is usually as follows. First, the chair provides theagenda of the meeting for approval. The agenda could be a proposal of the alternatives andrelated criteria of the site selection. Related materials such as reports, images, and proposalsare sent to all the participants. The previous minutes are approved, if any exist. The issueslisted in the agenda are discussed one by one. During the meeting, the participants can presenttheir opinions and demonstrate their ideas through tools, such as PowerPoint or GIS tools.Some scoring process may be processed to screen the criteria and alternatives. The decisionsare then made after the screening process.
3.2 Virtual Meeting Environment Enabled by Shared GIS
According to the understanding established through the literature review and case study, avirtual group meeting is mocked up, which allows participants from different locations toshare the geo-referenced data, discuss and negotiate a certain topic in real time within the envi-ronment with the real-time geocollaboration capability. Figure 2 shows the process of suchvirtual group meetings.
In the presentation style, the chair gives the participant the right to present, show a GISview and upload data to everyone. For example, upon a participant’s request for presentation,the chair approves the request. The participant obtains the right to control the microphone,shared GIS view and video channel, and starts to present to all other participants within alimited time. In the discussion style, instead of being assigned the right by the chair, every par-
188 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
ticipant has an equal chance to give a presentation if he/she can “catch” the right to controlthe floor. After one presenter finishes his/her presentation, the first one who catches the rightcan present.
The above mock-up group meeting process seems to be very simple and straightforward.However, the system that supports such a process is different from traditional, asynchronoussystems in the following aspects:
• Topic registration: Participants find and register the topic of interest.• Workflow mechanism: Workflow is used to plan, assign and implement the tasks. The
workflow is a sort of asynchronous collaboration.• Negotiation mechanism: Negotiation is needed to handle discussions in the decision-
making process.
Setting up virtual
group meeting
Joining the meeting
Approving Topics
Discussing and
demonstrating Topics
Closing group
meeting
1. Register session
2. Setup sharedGIS view
3. Setup floor controls
4. Set up shared data source
1. Join the session and shared view
2. Accept the floor rules
3. Download shared data
1. Chair summits agenda to all the participants for
approval and gives detailed introduction to the
agenda.
2. Participants may give comments to the agenda.
3. Chair may accept the comments and make a
change to the agenda, and submit the agenda to
everyone for approval again.
4. Repeat Step 2 and 3, until the agenda is
approved.
5. Participants approve the agenda.
1. Two mechanisms are used to manage the
participant’s discussions: presentation style and
discussion style.
2. The participants’ opinions may be adopted and
become part of the decisions.
3. A voting system may be used to screen the
alternatives and criteria (Optional).
Figure 2 Virtual group meeting process enabled by shared GIS
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 189
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
• Multiple users’ awareness in goal, tasks and behaviors: Users can share not only the data,but also the operations on and views of geospatial data. The typical capability is strictlywhat-you-see-is-what-I-see (WYSIWIS) or relaxed WYSIWIS. The relaxed WYSIWISmeans that participants can share the same viewing environment (with the same viewpoint)but also maintain a private view with their personal viewpoint.
• Real-time multicast-based message transmitting: For example, in the agenda approval stepor issue discussion step, the clients need a real-time message exchange process. The agendaand shared view need to be transmitted to all the clients. The routine of multicast transmis-sion distinguishes this kind of system from a typical client-server system.
Further, in this virtual meeting environment, multiple users’ discussion and collaborationare based on a shared GIS environment. A presenter usually presents his/her opinion and argu-ment through demonstrating and operating the GIS model and environment to other partici-pants. In order to understand the presenter’s opinion and context, all other participants shouldhave the same viewpoint of the GIS model and share the same operation of the GIS environ-ment. This shared GIS environment also needs the shared data sources and tools to coordinatethe participants’ behaviors and operations so that the multiple users’ operations to the sharedGIS environment are to be synchronized. Its realization requires solutions of not only sometechnical issues, but also social issues, such as people’s collaboration. The next section willpresent a conceptual framework to guide and scope the related issues.
4 Geo-social Model: a Conceptual Framework for Real-time Geocollaboration
The conceptual framework of the real-time geocollaboration is divided into three aspects:social, geospatial and technological (Figure 3). The social aspect focuses on the collaboration
Implementation
Geospatial Aspects:
GIS data model
Spatial data query and
analysis
Visualization
Social Aspects:
Participants’ profiles
Workplaces’ norm, rules and
workflow
Awareness, communication
and collaboration
Technological Aspects:
Consistency
Message multicast
Shared understanding
Multi-user graphic interface
Combination
Figure 3 A conceptual framework for geocollaboration
190 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
and cooperation among users. The geospatial aspect relates to the special criteria derived fromGIS requirements, which differentiate geocollaboration from other collaborative or groupwaresystems. The technical aspect gives more attention to the main technological challenges toimplementing the framework.
4.1 Social, Geospatial and Technical Aspects
The social aspect relates to how participants work with each other. The core elements mayinclude:
• Participant’s profile, role and relations with others• Workplace’s norm, rules and operation protocols• Participant’s awareness, communication and interaction with each other• Workflow and negotiation processes
A participant’s profile usually presents the user’s name, location, title, origination androle. Different roles have different privileges to access and operate within the workplace. Forexample, in the simulation, the meeting chair has the right to assign other users the privilege tooperate the shared workplace in the virtual group meeting, while the audience role only hasthe right to view in the workplace. All the users will follow the same norm, rules and workprotocols in the same workplace.
Awareness, communication and interaction present three levels of collaboration. Aware-ness involves the understanding of another person’s interaction with the shared workspace.The typical functionalities include shared participants’ profiles and environments, such asshared view, radar view and tele-pointer. Communication involves the information exchangebetween participants. The information may include events, messages, text chat, radio andvideo conferencing. Interaction involves not only information exchange but also decision-making and negotiation processes. This level of collaboration is more complex than awarenessand communication since the interaction process involves multiple information exchange andshared understanding.
The geospatial aspect specifies the special features in real-time geocollaboration. Thesefeatures differentiate the real-time geocollaboration not only from other groupware systemsbut also from the traditional GIS applications. The main features are:
• Spatial data models in the different fields• Spatial data query and analysis• Shared cartographic visualization
The spatial data model is the main difference between GIS and other systems. This kind ofdata model describes both location information and characteristics of spatial attributes such asroads, land parcels, and vegetation stands on the Earth’s surface. In order to specify the specialcharacteristics of GIS, several core elements, such as a geographic coordinate system, geom-etry, attribute, topology relations, and styles, are identified. These elements can be presented inone data model, like the GIS theme model, which is also called the Feature model in GML.
Spatial data query and analysis include some typical GIS algorithms, for example, shortestpath analysis, buffer query and utility network analysis. The queries and analyses are based onthe geometry, topology and attribute information from the spatial data model.
The special characteristics of GIS in visualization have to do with cartographic symboliza-tion, which describes how mapmakers display a spatial feature in a map or digital map with
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 191
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
cartographic issues (map elements) such as symbol, color, text and type of map, title and scale.Rather than integrating these elements into the GIS data mode, current GIS platforms such asArcGIS configure them on the fly when the data is loaded into the system. However, the samecontent could be visualized in different ways according to a user’s habit and the purpose of themap theme. The method separates the visualization from its content and causes potential prob-lems for real-time geocollaboration because all users’ visualizations in terms of symbols,colors, styles and so on need to be consistent in the distributed environment.
The technical aspect provides technological support or tools to implement the socialaspects and GIS requirements. These requirements, such as users’ awareness, communicationand interaction, result in technology differences compared with traditional desktop, client- orbrowse-server systems, such as OpenLayers and Mapserver. The core challenges, which arederived from the real-time features, are:
• Consistency• Message multicasting• Shared understanding• Multi-user graphic interface
The consistency issue is about how to keep the distributed clients in consistency. Usuallythe geographically dispersed users work on their own distributed clients. There are potentialconflicts when the users operate the system with their clients. A mechanism such as floorcontrol is needed to coordinate potential conflicts.
Message multicasting is also required to handle client-to-client message transferring. Thisdirect communication between clients is different from typical client-server architecture. Thedevelopers for geocollaboration platforms have to consider more on the network layer design(Gutwin et al. 2006), which is transparent for traditional client-server system development. This isbecause most of the groupware systems have their own network layer API for multicast protocols,which is the special feature for groupware systems. An issue of shared understanding is how tomake all involved elements such as the messages, different clients and their behaviors, and datasources, understandable to each other. This is the foundation for collaboration in a distributedsystem. A multi-user graphic user interface (GUI) is also a challenge. Development tools such asC++ or Java are not designed with collaboration in mind (Begole et al. 1997). Special technologi-cal efforts have to be made to design multi-user GUIs for GIS purposes.
4.2 Geo-social Model
The geo-social model is an abstracted presentation of the interactions and elements for partici-pants to work together in a shared GIS environment, e.g. mimic a small group meeting. Thediagram shown in Figure 4 describes the main elements and relations of two geographicallydispersed participants who collaborate with each other in a group meeting. The model is scal-able in the sense that more participants can be easily added using the same pattern and organ-ized into separate meeting sessions, if smaller group meetings are preferred (Butt and Li 2012).
As illustrated in Figure 4, participants, systems, and data sources play different roles incarrying out the collaborative tasks. For example, when one participant operates the GISsystem, such as zooming in/out or rotating the geospatial model, his/her operations are sharedwith other participants. These operations are called shared tasks. In order to avoid the con-flicts of multiple participants’ operations to the system, different participants may be granteddifferent privileges or roles, called profiles. Participants may also need to upload the data
192 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
source for sharing, which is called the shared data source. Some complex communications,such as making deals, are also facilitated among participants.
Based on the above description, there are five main elements in the geo-social model:Topic, Participant, Systems Container, Shared Task and Data Source. Each of these elementshas two attributes: Action and Property. Action defines “what they are doing” and propertydefines “who they are”. Table 2 describes the main properties and actions of the five elements.
Topic identifies the topic that is discussed by the participants in a group meeting. Partici-pants can search for a topic and join a group meeting session through the topic identification.All the activities relate to the topic.
Participant represents the people who find the topic interesting and attend the groupmeeting. Participants play different roles and therefore have different privileges to operate ashared system/service container. The participants’ roles and privileges also present the structureof the organization. The collaboration workload can be carried out through this structure.
Topics
Shared
Tasks
Participant 1
System
Container 1
Private
Data 1
Profiles
Data Sources
Participant 2
System
Container 2
Private
Data 2
Register
Share
Discuss
Operate
Load
Location 1 Location 2
Location …N
Apply the same
interactions
Figure 4 Elements and relations of the geo-social model
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 193
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
Tabl
e2
Elem
ents
of
the
geo
-so
cial
mo
del
and
thei
rp
rop
erti
esan
dac
tio
ns
Elem
ents
Pro
per
tyA
ctio
nC
om
men
ts
Top
icTo
pic
Nam
eC
reat
eto
pic
Itco
uld
be
anid
enti
fica
tio
nto
gro
up
mee
tin
gs.
Peo
ple
wh
oar
ein
tere
sted
inth
isto
pic
will
atte
nd
this
mee
tin
gD
elet
eto
pic
Part
icip
ant
Pro
file
sR
egis
ter
top
icTh
ep
rofi
lein
clu
des
par
tici
pan
t’sn
ame,
titl
e,ro
lean
dac
cess
righ
tsD
ereg
iste
rto
pic
Ro
le(C
hai
r,Pr
esen
ter,
Au
die
nce
)D
iscu
ssw
ith
oth
erp
arti
cip
ants
Acc
ess
Rig
hts
(Op
erat
ion
,Med
iate
,Pri
vate
and
Pub
lic)
Syst
emC
on
tain
erSy
stem
Iden
tity
Nav
igat
e3D
view
(Zo
om
in,Z
oo
mo
ut,
Ro
tate
and
Pan
)O
nly
pre
sen
tssh
ared
task
s.
Qu
ery
fun
ctio
ns
An
alys
isfu
nct
ion
sSh
ared
Task
Task
Nam
e,Pa
ram
eter
san
dO
wn
ers
Sim
ilar
toSy
stem
Co
nta
iner
san
dD
ata
Sou
rce
Dat
aSo
urc
eD
ata
Sou
rces
Iden
tity
Load
dat
aIn
clu
des
pri
vate
dat
aan
dsh
ared
dat
aso
urc
es.
Form
ato
rM
etad
ata
Rem
ove
dat
aR
ecei
ved
ata
fro
mre
mo
tep
eers
Sen
dd
ata
tore
mo
tep
eers
194 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
System Container is a place where a system platform or service is contained. In a con-tainer, participants can share the same operation and rendered model, even the whole systemplatform. The system platform, for example, could be a 3D GIS environment, Web-based GISservice or a GIS application.
Shared Task describes the tasks performed and shared by the participants. These taskscould be a simple operation or a set of operations to the system. Although other elements havetheir own tasks (private tasks), shared tasks are specified as the tasks known and shared withall participants. Private tasks can be changed to shared tasks, if necessary. For example, whena task is used by other participants, it becomes a shared task.
Data Source describes the data format, database connection information and the locationsof the data sources when the data need to be loaded in the system. The data source includes aprivate data source and a shared data source. The private data can be uploaded and subse-quently become the shared data, which are accessible to all participants.
The real-time collaboration requires that the shared tasks and data sources be shared, col-laboratively operated and managed in real-time. This requirement needs a mechanism to coor-dinate all of the above elements. A floor control mechanism (Myers et al. 2004) was proposedto handle the task. The design of the mechanism is based on participant’s profile. For example,in the case of group meeting use, people are usually in one of two situations: highly interactivediscussion or monologue presentation. In an interactive discussion situation, any person whowants to talk and demonstrate his or her ideas would like to take the floor immediatelywithout the permission of a moderator, while in a monologue presentation people would liketo present their ideas until they have finished. The participant’s operation privileges, roles andstanding situations are defined in his or her profile.
5 Prototyping Virtual Group Meeting
The main purpose of the geo-social model is to present a shared understanding to the geocol-laboration environment so that the distributed environment, behaviours and activities can bebetter understood by the distributed client. The shared understanding of the knowledge needsto be presented in a common understandable format. In this research, the geo-social model ispresented using an ontology and implemented by a multi-agent method.
5.1 Multi-agent Method
The multi-agent method has a special feature to present a shared knowledge base (e.g. usingontology) and provides tools for communications between distributed machines. It was used toimplement the Geo-social model in the shared 3D system. The traditional client server (orbrowse server) and map service (or Web service) face difficulties in implementing peer-to-peerand peer-to-many data transportation. For example, when performing the shared tasks such aszoom and pan, the task events will be sent to all the users who participate in this session. Thetraditional client-server or Web service architecture just provides the communication betweenthe client and the Web or database server. More complicated peer-to-peer and peer-to-manydata transportation has to be exposed in collaboration components. Considering system con-sistency and the floor control mechanism, the collaboration components will be very compli-cated and error-prone.
The collaboration components cannot easily deal with the more complicated collaborativeprocesses, which may be related to negotiation and multi-round interaction protocols (IEEE
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 195
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
FIPA 2008). For example, in the negotiation process (see Section 3.2), the chair and the par-ticipants would make the issues approved through a negotiation process such as agree/do notunderstand/refuse. This structured interaction is not easily implemented with a hard-codedpattern. Moreover, collaboration among users requires not only A Human-Machine Interface(HMI), but also an interface between machine and machine. This requires a shared under-standing of the interactions among machines and users.
Multi-agent systems, such as those based on the Java Agent Development Framework(JADE), provide solutions to these challenges. A multi-agent system’s capabilities are asfollows:
1. Peer-to-peer and peer-to-many data transportation support: The multi-agent platform pro-vides a method for transmitting all kinds of structured data such as messages, data andoperations from one client to other clients directly.
2. Complicated interaction protocols such as multi-user negotiation support: The multi-agentmethod usually follows the IEEE Foundation for Intelligent Physical Agents (FIPA) inter-action protocol. These interaction protocols, such as FIPA-Request, FIPA-query, FIPA-Request-When, FIPA-recruiting, FIPA-brokering, allow the initiator to verify if theexpected rational effect of a single communicative act has been achieved.
3. Shared understanding: The multi-agent approach usually provides a FIPA-compliant plat-form and ontology towards achieving shared understanding (“agreeing on disagree-ments”) in terms of the working context and environment, topics, tasks and users.
Although there are some studies related to multi-agent systems in urban planning (Saar-loos et al. 2008), the main complicity of the multi-agent system has to do with how it modelsthe system. The implementation of a multi-agent system such as JADE and the ontology pres-entation of the geo-social model could follow the multi-agent development process in Guarino(1997).
5.2 Ontology Presentation
Ontology is a formal explicit description of concepts in a domain of discourse (concepts orclasses), properties (slots or roles) and restrictions on properties. Jasper and Uschold (1999)identified three major areas of uses for ontology: (1) to assist in communication betweenhuman beings; (2) to achieve interoperability (communication) among software systems; and(3) to improve the design and the quality of software systems. Based on different purposes,ontologies are also classified into different levels such as top-level, domain-level, task-level andapplication-level (Guarino 1997). Because the purpose of using an ontology to present the geo-social model is to share the common understanding of the group meeting in the geocollabora-tion environment among distributed people and software agents, the geo-social modeltherefore can be seen as an application-level ontology.
In developing an ontology, the primary task is to define the main elements, such as terms(vocabulary), discourses (classes), properties and constrains of properties. A detailed approachcan be seen in Noy and McGuinness (2001). Figure 5 shows a conceptual diagram of anapplication-specific ontology for geocollaboration in 3D GIS derived from the geo-socialmodel. All the elements discussed in Section 4 are presented in this ontological representationas shared knowledge. For example, the discourse, Task, has its sub-discourse, 3D GIS Task.3D GIS Task has its sub-discourses Pan, Zoom, etc.
These concepts, together with their properties, will be coded and encoded as contents ofAgent Communication Language (ACL) messages. ACL is used for multi-agents to communi-
196 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
cate with each other in a multi-agent system. The geo-social model is used in a multi-agentsystem prototype to solve/reconcile the conflicts in a group meeting.
5.3 Agent Identification
From the case study and mock-up group-meeting scenario, different users work in a virtualmeeting with a shared environment (it is a 3D GIS environment in this prototype). These usersmay play different roles, such as chair, participant (presenter) and audience. They also havedifferent behaviors, such as operation of the environment, communication among users, andmaking deals. These roles and behaviors can be presented as agents.
There are three types of agents in this multi-agent layer: Assistant agent, Registrationagent and Transducer agent (T-agent) (see Figure 6). Each distributed client has an assistantagent and a T-agent. The complete multi-agent layer has only one registration agent.
The assistant agent is launched by its client and is responsible for complex communica-tions with other assistant agents after it registers the interested topic to the registration agent.Complex communications include making deals or proposals. The assistant agents themselvesalso play different roles, such as chairing the meeting, making a deal or approving a proposal,while other agents just have the right to audit and discuss in the meeting. The registrationagent is responsible for setting the meeting and topics and other agents’ registration and dereg-istration. This agent is launched by the client who is the first one to set up and chair thesession. The transducer agent is responsible for communication between the shared 3D GISenvironment and assistant agent.
5.4 Agent Interaction
From the simulation, some typical interactions can be identified. For example, for the Joiningthe meeting use case (see Figure 2), when a user sets up a meeting, this user will wait for other
Figure 5 Conceptual representation of an application-specific ontology for geocollaboration
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 197
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
users to join in the meeting. Suppose that the meeting is set up by the registration agent. Thereare two types of interactions between the registration agent and assistant agent: request inter-action and subscribe interaction.
In the request interaction, the assistant agent sends a request to the registration agent tojoin in a topic and the registration agent approves it. This seems simple, but many situationsmay occur. For instance, the assistant agent has sent the message, but the registration agentmay not receive it, or the registration agent receives the message but may not understand whatit means. Also, the registration agent may refuse the request or agree to the request and sendthe related information to the assistant agent.
The detailed workflow can be described as follows. The assistant agent sends a requestmessage to the registration agent to join in the topic. The registration agent receives therequest and replies with a rejection; the registration agent receives the request and replies withan acceptance and sends related meeting details; or the registration agent does not receive therequest messages.
In the subscribe interaction, the assistant agent subscribes to the topic. When the meetingabout the topic is set up, the assistant agent automatically joins in the meeting. The subscribeinteraction also faces the same situations as with request interaction when the subscription isset up.
IEEE Foundation for Intelligent Physical Agents (FIPA), as a standards organization,developed a specification that describes all the situations for these kinds of interactions (IEEEFIPA 2008). For example, in the request interaction, FIPA defines all possible situations thatmay happen when two agents communicate. Of course, not all the situations are necessary tobe handled in the real work. The agents’ interactions in these multi-agent layers can beabstracted into several types, such as Request, Subscribe and Contract Net according to theFIPA Interaction.
5.5 Multi-agent System Implementation
The overall architecture includes two layers: a shared 3D GIS environment and a multi-agentbased social structure layer. This article focuses on the latter. The shared 3D environment(Chang and Li 2008) is part of the research but it is not discussed in this article. The reasons
User 2User 1
Assistant
Agent
Register
Agent
Assistant
Agent
Register
Make deal or proposal
Register
T-agent
Request Request
System
T-agent
System
Figure 6 Agents and their relations
198 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
for implementing a 3D environment rather than a 2D one for real-time collaboration aretwofold: (1) the authors had started the research with 2D and subsequently moved on to 3D;and (2) even through screen sharing software such as Microsoft NetMeeting or WebEx, the 2DGIS system can be shared by sending images to every participant. However, the 3D system isnot easily shared with good performance because hundreds of frames are drawn every second.That is why a more-complicated architecture is used for video games such as Counter Strikerand Battlefield (series) to handle multiple user collaboration.
The relations between the two layers are loosely coupled. The transducer approach(Nikraz et al. 2006) is adapted to integrate the multi-agent part into the overall system. Thetransducer approach provides the interface agent, called transducer agent (T-agent), betweenthe legacy and the multi-agent systems. The two layers share the same ontology-based socialcollaboration model. According to this method, the whole system is divided into two parts: amulti-agent part and a 3D GIS part (Figure 7). The transducer agent serves as an interfacebetween the 3D GIS and the multi-agents. The distributed 3D GIS is responsible for meetingthe basic 3D GIS requirements, while the multi-agents are responsible for handling morecomplex interactions such as multiple communication and structured interactions.
The multi-agents are divided into several agents to implement specific tasks in a distrib-uted pattern. Using the Agent Communication Language (ACL) in the JADE system, theseagents can communicate and interact with each other through a shared knowledge base, anontology, which shares vocabulary and interaction protocols and achieves common under-standing. The 3D GIS part is an independent (legacy) distributed system. The shared cache is ashared virtual memory which every client can access as well as update the shared system statusand therefore keep the whole system consistent.
In order to share the same understanding, these agents need to share the same language,vocabulary and protocols. In this prototype, JADE is used to develop the multi-agent system
Figure 7 Transducer approach integrates multi-agents to SC3DGIS
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 199
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
part in which the FIPA communicative acts and coder/decoder classes for semantic languages(SL) are followed. Through defining application-specific ontology, the vocabulary and seman-tics for the content of the message are shared among agents and the distributed 3D GIS.
6 Evaluation
A walkthrough method, together with the Mechanics of Collaboration, was adapted in evalu-ating the prototype and the conceptual framework. Three groups were formed, each with threestudents (names are hidden because of a related policy) from different backgrounds (geomat-ics, geography, mechanics and economy), ages and gender.
6.1 Evaluation Methodology
The evaluation of real-time collaborative systems is still considered to be a difficult problem,and many researchers feel that the only way to get a true picture of a groupware system is tostudy it in an actual application context with real users (e.g. Gutwin and Greenberg 2000).Although these kinds of field methods are able to contextualize the evaluation, they can beboth time-consuming and expensive. In addition, they can be difficult or impossible to performif a system is not fully developed.
This research adopted a usability inspection technique (Gutwin and Greenberg 2000) toevaluate the groupware system without utilizing a real work situation. This method wasmainly used to test the usability of shared workspaces with the predefined criteria, Mechanicsof Collaboration (Table 3). The Mechanics of Collaboration, which are low-level actions andinteractions such as communication, coordination, planning, monitoring, assistance and pro-
Table 3 Content of evaluation
Mechanic DescriptionAverageRating
ExplicitCommunication
Intentional provision of information, either throughspeech, text, or gesture
1.8
Coordinationof Action
Synchronizing actions and managing access toshared resources
2
Planning Division of labor, reserving areas of the workspacefor future use, or plotting courses of action
N/A
Monitoring Gathering information given by others throughconsequential communication or feed-through
2
Assistance Provision of help to one another, either uponrequest or opportunistically
1
Protection Actions taken to prevent change to or deletion of aperson’s existing artifacts and work
0
Internet Access Web based system and Internet data source 13D GIS Data Sources GIS data source support 1Structured Society Support roles and complex interaction 1
200 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
tection, must be carried out to complete a task in a shared manner. The framework alsoincludes gross measures of these mechanics: effectiveness, efficiency, and satisfaction. Steveset al. (2001) gave a rating for each mechanism of collaboration (see Table 4).
In order to add context to a groupware usability evaluation, Pinelle and Gutwin (2002)designed a groupware walkthrough method that adds contextual information about the workdomain, enabling evaluators to test the interface in relation to real tasks and users.
6.2 Walkthrough Testing
There are two ways of resolving conflicts in collaboration: negotiation and avoidance. Theformer reconciles through discussions and negotiations and the latter by sequencing conflictingactions. In this walkthrough testing, the conflicting actions can be solved through negotiationinstead of avoidance. For example, one user can perform a conflicted action through a negotia-tion process (Chang and Li 2009):
1. The agent system is launched from every client. The client with the Chair role may launchits registered agent and assistant agent, while other clients just launch their assistantagents.
2. The assistant agents register to the register agent. The registration is an automatic pro-ceeding if an assistant agent is subscribed to the service.
3. One of the assistant agents, assumes the Chair role, tries to navigate its point of the viewto a specific location in the shared 3D view. The transformation parameters are sent to allof the other assistant agents.
4. Other assistant agents receive the parameters, make changes, and send these back to theChair agent.
5. The Chair agent makes a change according to the feedback and resends the parameters toevery agent again.
6. After several iterative revision procedures, the Chair agent accepts the changes and sendsthem to every assistant agent, or the Chair agent rejects the changes and terminates thisaction.
Figure 8 shows the interface of two assistant agents. Each of them has a private 3D viewin which the individual points of view can be checked. After one assistant agent (e.g. AssistantAgent 1) makes a decision regarding the 3D point of view, it sends the view parameters toother agents (Assistant Agent 2) for negotiation until an agreement is achieved or terminated.If an agreement is reached, the action to make a point of view for the shared view is sent to theshared 3D environment (see Figure 9). The agent management GUI monitors all the agents’ lifecycles.
Table 4 Rating and associated descriptions (Steves et al. 2001)
Rating Description
+2 Very successful, few reports of problems+1 Often successful, but some awkwardness0 Adequate: no major problems or major benefits-1 Useful in some situations but many drawbacks-2 Rarely successful with many failuresN/A Not enough information to rate
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 201
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
Figure 8 A snapshot of the assistant agent interface
Figure 9 A snapshot of a shared view
202 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
The three groups mentioned above took part in this evaluation. Each group has a groupleader who plays the Chair role for the evaluation. The leader can assign different roles forother users through floor control functions. During the test period, the users rate the mechan-ics of collaboration in Table 3 according to the rating system in Table 4.
According to the observations and results (see Table 3), most of the synchronous collabo-ration functions are satisfied and successful. Even though two of the testers did not have therelated background, they could work on the walkthrough smoothly with the guidance of thegroup leader. The synchronous collaborative functions, such as the What-You-See-Is-What-I-See feature, text messages and floor control mechanism, play important roles to assist partici-pants in understanding the context and working environment. The lack of a protectionmechanism may cause problems because the shared file can be deleted by any participant (referto Table 3). This is an issue related to the balance between write/delete and read permissionsbecause participants should be allowed to upload and view data. The prototype was onlytested with a simple 3D GIS model without involving any actual planning tasks, so that thefocus could be maintained on “collaboration”. The 3D GIS data model is supported throughextending X3D and using FME Services, but the attributes cannot be visualized in the shared3D view because of the X3D driver’s limitations. However, this can be easily realized when anew driver is found to handle all X3D attributes. This prototype is also well-structuredthrough supporting roles and negotiations.
7 Conclusions
A requirement analysis method together with a case study was used to develop a conceptualframework for real-time geocollaboration. A comprehensive understanding of the specialrequirements in terms of architecture, technology and data model to be deployed was obtainedand presented. The geo-social model and its ontological representation have been developedand presented. This effort not only provides guidelines for the real-time geocollaborationdevelopment in this research, but also serves as an abstract model for any collaborative anddistributed graphics system, such as a collaborative 3D GIS or vehicle tracking system, toshare the system status. The ontology was first presented as an XML presentation. It was thentransferred via Java classes to the shared 3D view system and the multi-agent support systemso that each client can understand the others. A multi-agent system was prototyped to simulatethe real-time and multi-user collaboration in a shared 3D environment.
The research results indicate that the real-time, synchronous geocollaboration has specialfeatures related to social, geospatial and technological aspects. These aspects define the overallscope of the research not only as a technical issue but also as a social one. The reason that thegeo-social model and the multi-agent method were involved in this research is to handle com-plicated social issues as well as the real-time highly interactive communication. The main ele-ments and the relations presented in the geo-social model are capable of describing thebehaviors and interactions of the users in a distributed group meeting.
Nevertheless, it is well known that human-human collaboration is highly case and contextspecific. Further detailed investigations into specific use cases are needed as well as a refinedunderstanding and representation of the context. For example, modeling the behaviors ofusers, sub-systems and data in a 3D GIS context is different from simulating the urban plan-ning process. Sharing the understanding of this behavior model is related to the domain ontol-ogy, reasoning and rule-based technology. Furthermore, the well-defined description ofbehaviors among human-human, human to machine (system), and machine to machine will
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 203
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
benefit broader research in areas such as the spatial Web Sensor Network and Public Participa-tion GIS (PPGIS).
The agent methods have advantages in solving problems related to complex communica-tion and shared understanding between distributed clients. The agent method provides notonly shared presentation such as ontological presentation but also tools such as agent commu-nication language and FIPA standards at an implementation level, which provides the bridgebetween the modeling and implementation. However, these methods are not yet mature ineither agent system design or agent developing kits. In addition, some of the performanceproblems are still not resolved in the multi-agent system area and these multi-agent methodsare an important topic in semantic services and intelligent systems research situated in boarderareas such as computer science and Artificial Intelligence.
References
Armstrong M P and Densham P J 1995 Cartographic support for collaborative spatial decision-making. In Pro-ceedngs of Auto Carto 12, Charlotte, North Carolina: 49–58
Antunes P and Andre P 2006 A conceptual framework for the design of geo-collaborative systems. Group Deci-sion and Negotiation 15: 273–95
Balram S and Dragicevic S 2006 Extending objects to model agents: A collaborative design framework usingAgent UML extension. In Balram S and Dragicevic S (eds) Collaborative Geographic Information Systems.Hershey, PA, Idea Group: 121–33
Begole J, Struble C A, and Shaffer C A 1997 Leveraging Java applets: Toward collaboration transparency inJava. IEEE Internet Computing 2: 57–64
Boroushaki S and Malczewski J 2009 ParcitipatoryGIS: A WebGIS-based Collaborative Multicriteria DecisionAnalysis. WWW document, http://www.urisa.org/files/Boroushaki%20%20ParcitipatoryGIS%20com%20(2).pdf
Breslin J G and Decker S 2007 The future of social networks on the Internet: The need for semantics. IEEEInternet Computing 11: 86–90
Butt M and Li S 2012 Developing a web-based, collaborative prototype to support public participation. AppliedGeomatics 4: 197–215
Butt M and Li S 2012 Open source based online map sharing to support real-time collaboration. OSGeoJournal (10): 5–14
Cai G 2005 Extending distributed GIS to support geocollaborative crisis management. International Journal ofGeographical Information Science 11: 4–14
Cameron B, DePalma D A, O’Herron R, and Smith N 1995 Where does groupware fit? Cambridge, MA, For-rester Research, Software Strategies Report
Chabert A, Grossman E, Jackson L, Pietrowicz S, and Seguin C 1998 Java object-sharing in Habanero. Commu-nications of the ACM 41(6): 69–76
Chang Z and Li S 2008 Architectural design and prototyping of a Web-based synchronous collaborative 3DGIS. Cartography and Geographic Information Science 35: 117–32
Chang Z and Li S 2009 Reconciling inconsistent perspectives in collaborative GIS using multi-agent method. InProceedings of the Seventeenth International Conference on Geoinformatics, Fairfax, Virginia
Churcher N and Churcher C 1996 GroupARC: A collaborative approach to GIS. In Proceedings of the EighthColloquium of the Spatial Information Research Center, Dunedin, New Zealand
Dewan P 1999 Architectures for collaborative applications. In Beaudonin-Lafon M (ed) Computer SupportedCooperative Work. Chichester, John Wiley and Sons: 169–94
Dix A 1996 Challenges and perspectives for cooperative work on the Web. In Proceedings of the ERCIM Work-shop on CSCW and the Web, Sankt Augustin, Germany
Dragicevic S and Balram S 2004 A Web GIS collaborative framework to structure and manage distributed plan-ning processes. Journal of Geographical Systems 6: 133–53
Ellis C, Gibbs S, and Rein G 1991 Groupware: Some issues and experiences. Communications of ACM 34(1):38–58
FMAA 2006 Wood River Region Airport Site Selection and Feasibility Study website, WWW document, http://www.flyfma.com/index.asp?Type=B_BASIC&SEC={2BDCB453-0891-4A8F-96D7-503AF71D1BE8}&DE={A4F6DE87-077C-4944-9E26-DF20E56D3B2F}
204 Z Chang and S Li
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)
GSA 2011 Site Selection Guide. WWW document, http://www.gsa.gov/portal/category/21137Guarino N 1997 Semantic matching: Formal ontological distinctions for information organization, extraction
and integration. In Pazienza M T (ed) Information Extraction: A Multidisciplinary Approach to an Emerg-ing Information Technology. Berlin, Springer-Verlag Lecture Notes in Computer Science Vol. 1299: 139–70
Gutwin C and Greenberg S 2000 The mechanics of collaboration: Developing low cost usability evaluationmethods for shared workspaces. In Proceedings of the Ninth You +1’d this publicly. Undo
Gutwin C, Fedak C, Watson M, Bell T, and Dyck J 2006 Improving network efficiency in real-time groupwarewith general message compression. In Proceedings of the Twentieth Anniversary Conference on ComputerSupported Cooperative Work (CSCW 2006), Banff, Alberta: 119–28
Hinssen P J H 1998 What Difference Does It Make? The Use of Groupware in Small Groups. Enschede, TheNetherlands, Telematica Instituut, Elematica Instituut Fundamental Research Series Vol. 002 (available athttp://www.telin.nl/publicaties/1998/scout/scout.htm)
IEEE FIPA 2008 IEEE Foundation for Intelligent Physical Agents, Interaction Protocol Specifications WWWdocument, http://www.fipa.org/repository/ips.php3
InfoPatterns 2007 Toucan Navigate. WWW document http://www.infopatterns.com/JADE 2011 Java Agent Development Framework. WWW document, http://jade.tilab.com/Jankowski P and Nyerges T 2001 Geographic Information Systems for Group Decision Making: Towards a Par-
ticipatory, Geographic Information Science. London, Taylor and FrancisJankowski P and Nyerges T 2003 Towards a framework for research on geographic information-supported par-
ticipatory decision making. URISA Journal 15: 9–17Jasper R and Uschold M 1999 A framework for understanding and classifying ontology applications. In Pro-
ceedings of the IJCAI99 Workshop on Ontologies and Problem-Solving Methods (KRR5), Stockholm,Sweden
Jones R M, Copas C, and Edmonds E A 1997 GIS support for distributed group-work in regional planning.International Journal of Geographical Information Systems 11: 53–71
Johansen R 1998 Groupware: Computer Support for Business Teams. New York, Free PressLi S 2006 Web-based collaborative spatial decision support systems: A technological perspective. In Dragicevic S
and Balram S (eds) Collaborative Geographic Information Systems, Hershey, PA, IGI Publishing: 285–315Li S and Coleman D 2003 A Web-based collaboration system for managing distributed GIS data production.
Geomatica 57: 351–61Li S, Guo X, Ma X, and Chang Z 2007 Towards GIS-enabled virtual public meeting space for public participa-
tion. Photogrammetric Engineering and Remote Sensing 73: 641–50Myers B A, Shan Y, Chuang A, T M, Chen M, and Lee C 2004 Floor Control in a Highly Collaborative
Co-located Task. WWW document, http://www.cs.cmu.edu/~pebbles/papers/pebblesfloorcontrol.pdfMacEachren A M 2001 Extending collaborative tools to support virtual teams. Cartography and GIS Progress
in Human Geography 25: 431–44MacEachren A M and Brewer I 2004 Developing a conceptual framework for visually-enabled geocollaboration.
International Journal of Geographical Information Science 18: 1–34Nikraz M, Caireb G, and Bahria P 2006 A methodology for the development of multi-agent systems using the
JADE platform. International Journal of Computer Systems Science and Engineering 21(2): 1–6Noy N F and McGuinness D L 2001 Ontology Development 101: A Guide to Creating Your First Ontology.
WWW document, http://www.ksl.stanford.edu/KSL_Abstracts/KSL-01–05.htmlNyerges T 1999 Progress in spatial decision making using geographic information systems. In Craglia M and
Onsrud H (eds) Geographic Information Research: Trans-Atlantic Perspectives. London, Taylor andFrancis: 129–42
Pinelle D and Gutwin C 2002 Groupware walkthrough: Adding context to groupware usability evaluation. InProceedings of the 2002 Conference on Human Factors in Computing Systems (CHI 2002), Minneapolis,Minnesota: 455–62
Rinner C 2001 Argumentation maps: GIS-based discussion support for online planning. Environment and Plan-ning B 28: 847–63
Saarloos D J M, Arentze T A, Borgers A W J, and Timmermans H J P 2008 A multi-agent paradigm as structur-ing principle for planning support systems. Computers, Environment and Urban Systems 32: 29–40
Steves M, Morse E, Gutwin C, and Greenberg S 2001 A comparison of usage evaluation and inspection methodsfor assessing groupware usability. In Proceedings of the ACM Conference on Supporting Group Work,Boulder, Colorado: 125–34
Suthers D 2001 Architectures for computer supported collaborative learning. In Proceedings of IEEE Interna-tional Conference on Advanced Learning Technologies (ICALT 2001), Madison, Wisconsin
Tang T, Zhao J, and Coleman D J 2005 Design of a GIS-enabled online discussion forum for participatory plan-ning. In Proceedings of the Fourth Annual Public Participation GIS Conference, Cleveland, Ohio
Geo-Social Model: a Conceptual Framework for Real-time Geocollaboration 205
© 2012 Blackwell Publishing Ltd Transactions in GIS, 2013, 17(2)