geosocial model: a conceptual framework for realtime

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


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



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.



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



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-



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



• 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



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



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



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



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



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



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-



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



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



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



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



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



Figure 8 A snapshot of the assistant agent interface

Figure 9 A snapshot of a shared view



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



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}



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



geosocial model: a conceptual framework for realtime

Documents