1. designing scenarios for social agents - ishida …. designing scenarios for social agents toru...

1. Designing Scenarios for Social Agents

Toru Ishida1 and Hideyuki Nakanishi1

1 Department of Social Informatics, Kyoto University JST CREST Digital City Project

Abstract

One of the most important attributes of autonomous agents for Web applications is the ability to fluently interact with human users. Unfortunately, interaction characteristics are seldom generated by computer professionals, and instead are most often created by application designers such as sales managers, travel agencies, and school teachers. Our challenge is to extend agent technologies to ensure the social acceptance of social agents in Web applications. To this end, we have been developing Q, a language for developing interaction scenarios between agents and users. Q can also act as an interface between computer professionals and scenario writers. This chapter details the specifications of Q, how to design and execute scenarios, and its implementation for Microsoft agents and FreeWalk agents; applications considered include crisis management simulation and social psychological experiments.

Keywords: Interactive agent, multi-agent system, scenario, interaction pattern, Web application, crisis management simulation.

1.1 Introduction

The research community tackling agents and multiagent systems has studied and developed various agents. Typically, personal agents belong to humans and help their users to operate complex computer/communication systems. In the area of multiagent systems, computational agents are designed to interact (both collaborate and compete) with each other. However, interaction among humans and computational agents has not been studied intensively. In this paper, however, we focus on social agents, which can be members of a human community: social agents support human-human interactions, while personal agents support human-computer interactions.

1. Designing Scenarios for Social Agents 2

An interesting example is so called the virtual talent. A Japanese company has created a human-like female agent. The company promotes her to work in TV shows, movies, and in the Internet. She has published books, CDs and so on. Unlike other software, she is valuable not because of her functions, efficiency and correctness, but because she reflects human expectations, and interests. Therefore, it is not meaningful for the company to reproduce her, even though the cost of copying is almost zero. We can also find such agents in online communities and digital cities. Though social agents are software, because people accept their social roles, agents can behave as social beings in cyberspace. A dramatic change will occur in the user's attitude as personal agents are replaced by social ones. Your software assistant is no longer exclusively yours. If your assistant (social agent) is well recognized by others, you are subconsciously forced to interact with your assistant using social protocols. Since social agents are embedded in human societies, the effect of their actions/speech cannot be ignored. Social agents can provide security or can guide humans to safety after a disaster. At the same time, social agents can negatively impact humans, especially children, by violating social rules: spying, cheating, lying, and so on. To understand the nature of social agents, we need a research platform to promote a series of experiments with them. This chapter proposes a scenario description language called Q for designing interactions among a large number of agents, and its application to crisis management simulations and social psychological studies. 1.2 Describing Scenarios 1.2.1 Overview Many of the languages proposed for describing agent behavior and inter-agent protocols are based on agent internal mechanisms. Examples include SOAR [1] and KQML [2]. For Web applications, however, we should also consider the application designers’ view. Q is a language for describing interaction between agents and users based on agent external roles. Q does not depend on agent internal mechanisms; its goal is to describe how scenario writers should be able to request agents to behave. The change of focus from agent internal mechanisms to interaction scenarios significantly impacts the language syntax and semantics. For example, if an agent accepts only two requests, “on” and “off,” Q allows scenario writers to use just two commands, “on” and “off.” This does not mean that the agent is not intelligent, only that the agent is not controllable. Furthermore, the semantics of commands cannot be known unless they are actually tried. For


example, the semantics of the command “move” depend on whether the agent can run rapidly with a light step or move slowly in a thoughtful manner. Since Q cannot control the internal mechanism of the agent, Q does not have functions, such as JAVA function calls, that are often used to implement detailed agent behavior. The scenarios also contribute to establish a bridge between agent designers (computer professionals) and application designers (scenario writers). To maximize this benefit, we introduced IPC (Interaction Pattern Card) with Excel interface. We expect that effective dialog emerges from the interplay between the two different perspectives during the process of formalizing interaction patterns. To realize Q, we extend Scheme1 by introducing sensing/acting functions and guarded commands. Since Scheme is the mother language of Q, all Scheme functions and forms can be used in any scenario. The new language facilities are explained below. 1.2.2 Cue and Action An event that triggers interaction is called a cue. Cues are used to request agents to observe their environment. No cue is permitted to have any side effect. Cues keep on waiting for the event specified until the observation is completed successfully. Comparable to cues, actions are used to request agents to change their environment. Once cues and actions have been successfully performed, they return #t. Cues and actions are defined by defcue and defaction.

(defcue name {(parameter in|out|inout)}*) (defaction name {(parameter in|out|inout)}*)

In/out controls the flow of data. When Q variables are specified, they are treated as either in or out. In means the data is transferred from Q variables to the agent, and out indicates the opposite direction. Inout specifies both directions. When constants (for example, names of agents) are specified, they are always handled as in. Unlike functions in programming languages, the semantics of cues and actions are not defined in Q scenarios. Since cues and actions are executed differently by different agents, their semantics fully depend on the agent. Examples of 1 Scheme is a dialect of the Lisp programming language invented by Guy Lewis Steele Jr.

and Gerald Jay Sussman.


cues (starting with ?) and actions (starting with !) are as follows:

(?hear “Hello” :from Jerry) (!walk :from bus_terminal :to railway_station) (!speak “Hello” :to Jerry) (?see railway_station :direction “south”)

In the above example, the agent waits for Jerry to say “Hello,” walks from a bus terminal to a railway station, says “Hello” to Jerry, and observes whether the railway station can be seen to the south. The above actions are called synchronous actions, which return after completion. Asynchronous actions, however, allow other actions to be executed in parallel. For example, walk can be an asynchronous action, since we can speak in parallel. To represent asynchronous actions, we use the notation !!walk. If we use !!walk in the above example, the agent says “Hello” to Jerry, just after he starts walking. Asynchronous actions significantly extend the flexibility (and complexity at the same time) available for describing agent scenarios. 1.2.3 Guarded Command All Scheme control structures such as conditional branches and recursive calls can be used in Q. In addition, guarded commands are introduced for the situation wherein we need to observe multiple cues simultaneously.

(guard {(cue {form}*)}*[(otherwise {form}*)])

A guarded command combines cues and forms. After either cue becomes true, the corresponding form is evaluated. If no cue is satisfied, the otherwise clause is evaluated if present. When multiple cues are satisfied, one of the satisfied cues is selected by the Q interpreter. The return value of a guarded command is the value of the last evaluated form.

(guard ((?hear “Hello” :from Jerry) (!speak “Hello” :to Jerry) …. ) ((?see railway_station :direction “south”) (!walk :from bus_terminal :to railway_station) …. ) (otherwise (!send “I am still waiting” :to Tom) …. )

In the above example, if one of the cues is observed (i.e. the agent hears Jerry say “Hello”), the corresponding forms are performed afterward (the agent says “Hello” to Jerry). If no cue is observed, the guarded command performs the otherwise clause (the agent sends a message “I am still waiting” to Tom).


1.2.4 Scenario A scenario is used for describing state transitions. Scenarios can be called from other scenarios or functions. Each state is defined as a guarded command, but can include conditions in addition to cues. (defscenario name ({var}*) (state1 {(testform {form}*)}* {(cue {form}*)}* [(otherwise {form}*)]) (state2 {(testform {form}*)}* {(cue {form}*)}* [(otherwise {form}*)]) …)) Each state is defined as a guarded command, but can include test forms (conditions) in addition to cues (events). Test forms can be any Scheme form. For a state transition, (go state) is used. State1, state2…are symbols showing states. The scenario’s return value is the value of the last evaluated form. Local variables can be declared in defscenario just as in Scheme functions. Although a scenario is written in the form of simple state transitions, since any form can be evaluated in the body of states, it is easy to describe fairly complex tasks. Scenarios can be called recursively, Scheme functions can be called in scenarios, and any scenario can be called in Scheme functions. (defscenario reception (message) (scene1 ((?hear “Hello” :from $x) (!speak “Hello” :to $x) (go scene2)) ((?hear “Bye”) (go scene3))) (scene2 ((?hear “Hello” :from $x) (!speak “Yes, may I help you?” :to $x)) (otherwise (go scene3))) (scene3 …)) In the above example, each scenario defines several states (scene1, scene2, …). The same observation yields different actions in different states. In scene1, the agent says “Hello” when it hears someone say “Hello.” In scene2, however, the agent says “Yes, may I help you?” when it hears “Hello” again. 1.2.5 Agent


Agents, avatars and a crowd of agents are defined as follows.

(defagent name scenario :location :shape :arguments) (defavatar name scenario :location :shape :control :arguments) (defcrowd name scenario

:population :location_range :shape_choice :arguments) Examples are as follows:

(defagent guide :scenario 'guide_for_sightseeing) (defavatar Jerry) (defcrowd pedestrian :scenario 'sightseeing :population 30)

In Q, an agent is defined by a scenario in that the scenario specifies what the agent is to do. Avatars controlled by humans do not require any scenario. However, avatars can have scenarios, if it is necessary to constrain avatar behaviors (see section 1.5.2 for social psychological experiments). Even if a crowd of agents executes the same scenario, the agents exhibit different actions as they interact with their environment (including other agents and humans). 1.3 Q for Legacy Agents 1.3.1 Microsoft Agents For illustrating Q scenarios, let us start with Microsoft agents. Table 1.1 summarizes cues and actions for Microsoft agents. The action !gesture can perform any of the 60 different gestures known to Microsoft agents.

Table 1.1 Sample Cues and Actions for Microsoft Agents

Cue Action Movement

!fly (fly on the screen)

Gesture !gesture (perform some gesture)

Motion

?watch (eatch WEB pages)

Appearance !appear (show up) !disappear (erase itself)


Conversation

?receive-text (receive text messages) ?receive-selection (receive selected items)

!speak (speak by voice) !display (display WEB pages) !request-text (ask users text input) !request-selection (ask users item selection)

Others

!change (change parameters)

Let's assume that we would like to control Microsoft agent Marlin as follows: if you find the user is looking at http://www.news.com/, then say hello to him/her with a gesture and show some of today's topics, and ask him/her to select one of them. The corresponding scenario in Q is given below.

(scene1 ((?see :address "http://www.news.com/")

(!behave :animation “Greet”) (!speak "Hello, I am Marlin.") (!fly :x 50 :y 300) (!display :url “http://www.news.com/topics.html”) (!speak "What are you interested in?") (!ask :selection

'("World Series" "World Cup" “Olympics” "Other Topics")) (!receive $x) (go scene2))) ….

Assume that we place the following task on Merlin: if the user wants to learn more about Kimono2, then visit the Kimono Web site and let the user freely click Web pages. Each time the user visits a new page, summarize its content. If the user does not react for a while, move to the next subject. Figure 1 shows this scenario written in Q and its outcome. Q will be easy for computer professionals to work with, but Scheme syntax may not be familiar to scenario writers. Furthermore, since Q is a general purpose scenario description language, there is too much freedom in describing scenarios for specific domains. We thus introduced IPC (Interaction Pattern Card), which captures the patterns of interaction in each domain. Figure 2 shows a card equivalent to the Q scenario in Figure 1.2. Scenario writers can use Excel for filling in the card. The IPC translator then generates

2 Kimono is Japanese traditional clothes.


a Q scenario according to the card’s contents and predefined semantics. Note that IPC is not merely an Excel interface to Q, rather it provides a pattern language, and so should be carefully designed by analyzing the interactions in each domain.

Designed by Tomasan Kimono School

Figure 1.1 Example Q Scenario (by M. Fukumoto and A. Yamamoto)

(defscenario card14 () (scene1 (otherwise (!speak "Hm-hum, you are so enthusiastic.") (!speak "Then, how about this page?") (!display :url "http://kimono.com/index.htm") (go scene2))) (scene2 ((?watch_web :url "http://kimono.com/type.htm") (!speak "There are many types of obi.") (!speak "Can you tell the difference?") (go scene2)) ((?watch_web :url "http://kimono.com/fukuro.htm") (!gesture :animation "GestureLeft") (!speak "Fukuro obi is for a ceremonial dress.") (!speak "Use it at a dress-up party!") (go scene2)) ((?watch_web :url "http://kimono.com/maru.htm") (card42 self) (go scene2)) ((?timeout :time 20) (go scene3))) (scene3 (otherwise (!speak "Did you enjoy Japanese Kimono?") (!speak "OK, let’s go to the next subject."))))


Card ID 14 Card Name Visiting Kimono Web site Card Type User Initiative

Action Hm-hum, you are so enthusiastic. Then, how about this page?

Opening

http://www.kimono.com/index.htm Cue Action

There are many types of obi. http://kimono.com/ type.htm Can you tell the difference?

(GestureLeft) Fukuro obi is for a ceremonial dress. http://kimono.com/

fukuro.htm Use it at a dress-up party!

Mouse Click

http://kimono.com/ maru.htm (Evaluate Card42)

Seconds Action

Reactions to Users’ Mouse Click

（Repeat）

No Reaction 20 (End of Repeat)

Action Did you enjoy Japanese Kimono? ClosingOK, let’s move on to the next subject.

Figure 1.2 Interaction Pattern Card (by Y. Murakami, S. Takata and A. Yamamoto)

Figure 1.3 Multi-Agent Information Retrieval with Q (By Y. Kitamura) Using Q and Microsoft agents, we have developed a multi-character interface for information retrieval, where domain specific search agents cooperate to satisfy users’ queries [7]. Previous research often used blackboard systems to integrate the results from multiple agents. However, since search agents are developed independently, integration quality is often unsatisfactory. We thus


took a totally different approach. Instead of integrating the results at the back end, we display the integration process to users as a dialogue involving multiple characters, each of which represents a different search agent. Users can observe the collaboration process among the agents and join the conversation if necessary. The multi-character interface increases users’ satisfaction by integrating the results socially at the front end. As shown in Figure 1.3, agents are implemented on the Microsoft agent platform and controlled through Java Applets and Java Scripts running within Internet Explorer. Since the whole system is very flexible, we can easily add or remove agents on the client machine. This allows a group of agents to support a wide variety of collaborative tasks for information retrieval. Moreover, the whole system is robust against failure, since no agent can seriously affect another agent. 1.3.2 FreeWalk Agents One interesting challenge is to use Q to create interdisciplinary 3D Web applications. FreeWalk [9] allows us to create virtual cities that exactly mirror the corresponding physical cities. Table 1.2 summarizes the cues and actions for FreeWalk agents, and Figure 4 displays a view of such agents controlled by Q scenarios. Actions with an asterisk can be used as asynchronous actions. A typical example is as follows:

(!!walk :to bus_terminal) (!speak “Follow me.” :to Jerry)

In this case, the agent speaks while walking. Since scenario writer combines inter-agent and intra-agent parallelism, it can create fairly complex multiagent behavior in short scenarios.

Table 1.2 Sample Cues and Actions for FreeWalk Agents

Cue Action Movement

!walk* (walk along a route) !approach* (approach to other agents) !block* (block other agents)

Motion

?position (get location and orientation) ?observe (observe gestures and actions) ?see (see objects)

Rotation !turn* (turn a body) !face* (turn a head)


Gesture !point* (point objects) !behave* (perform some gesture)

Appearance !appear (show up) !disappear (erase itself)

Conversation

?hear (hear voice) ?receive (receive text messages) ?answer (receive an answer to questions)

!speak* (speak by voice) !send* (send text messages) !ask* (ask questions)

Others

?finish (finish asynchronous actions) ?input (key input by users)

!change (mode change) !finish (stop asynchronous actions) !output (output logs)

Current technology allows a large number of agents to walk around each virtual city in real-time [6]. As walking motion can be generated by the user's machine via a Web browser plug-in, only the walking position/velocity and direction need be downloaded. Thus, a large number of agents and avatars can be created rapidly in real-time. As described in Section 1.5, we are trying to create a group of socially engaged agents that support the various activities of participants in digital cities [5]. We believe that agents offer excellent abilities as coordinators for building and maintaining online communities.

Figure 1.4 Virtual Kyoto with Agents


1.4 Designing Scenarios 1.4.1 Q Architecture Figure 1.5 shows the Q architecture for handling scenarios. When a scenario is given to a particular agent, a Q processor is created and coupled to the corresponding agent system. The agent system is capable of hosting multiple agents. For example, in the 3D virtual space called FreeWalk [9], hundreds of agents can coexist. The Q interpreter is designed to execute hundreds of scenarios simultaneously. The problem associated with the concurrent execution of scenarios is that execution results can differ with each run. To avoid this, we selected Scheme as the mother language of Q, because process switching can be completely controlled under the Q interpreter by using Scheme’s continuation. Though Q processors are implemented at the top of the Scheme, the program interface is provided for C++ and JAVA software, so we can easily combine Q and legacy agent systems.

Figure 1.5 Q Architecture The Q Architecture is divided into two layers: the execution layer and meta-layer. In the execution layer, the Q interpreter asks agents to execute cues and actions. If the agents find any problem in a given scenario, control is transferred to the meta-layer. In the meta-layer, agents can request the Q analyzer to investigate the scenario. Based on the report from the Q analyzer, the agents may enter into negotiations with the scenario writers. Readers may find similarity between Q architecture and three layer architectures for robot planning, which consist of control layer, sequencing layer and deliberative


layer [3]. The first and the third layer correspond to the execution layer and meta-layer, respectively. The Q scenario can be seen as a sequencing layer, but prepared outside of the agent by scenario writers. Agents can be autonomous or dependent. If autonomous, scenarios can be simple; if not, scenario writers should specify all details. Note that the granularity of cues and actions depends on two independent factors: the level of agent autonomy, and the degree of preciseness required by scenario writers. 1.4.2 Design Process There will be a diverse variety of applications that use Web agents [12]. To allow application designers to use fairly complex agents, we established a process for designing scenarios. The biggest effect of introducing Q is that it provides a clear interface between scenario writers (application designers) and computer professionals (agent designers), who are expected to have totally different perspectives. The process of creating a scenario is thus focused on a dialog that bridges two perspectives: STEP1: A scenario writer and a computer professional agree upon the cues and actions as the interface between them. Note that cues and actions are not provided a priori but are defined for each application domain through negotiation. This step defines cues and actions, the vocabulary of scenario writers. STEP2: The scenario writer describes a scenario using Q language, while the computer professional implements cues and actions. STEP3: We can introduce a third actor in this design process, the interaction designer, who observes the patterns of interaction in each domain and proposes interaction pattern cards (IPC). The cards trigger dialog between scenario writers and interaction designers and lead to a better understanding of the interaction patterns in each domain. IPC also improves the productivity of scenario writers. 1.4 Applying Scenarios The challenge of Q is to create a new application field for social agents. This section provides two different interdisciplinary applications, where agent designers (computer professionals) and application designers (scenario writers) meet. Readers can easily imagine Q as applied to various socially oriented tasks including e-commerce, e-government, digital cities and so on.


1.5.1 Crisis Management Simulation We have started using virtual cities to conduct crisis management simulations involving humans and agents. This pilot application links computer scientists, architects and social psychologists. The roles of agents in this simulation include pedestrians, security guards and so on. Realistic evacuation simulations can be created by having pedestrian agents act as humans running around trying to escape. Such simulations will contribute to discover typical human mistakes and to make correct decisions in real crises. Figure 1.6 shows 2D and 3D simulations of how humans behave when a crisis occurs in a small room. We compared the results obtained from the ongoing simulation to previous findings [11], and confirmed that multi-agent simulation guided by Q scenarios are sufficiently realistic. Based on this experiment, we are planning to conduct crisis management simulations in subway and railway stations in virtual Kyoto. The simulation will take place with 20 or more people (avatars) connected via the Internet, and hundreds of agents controlled by Q scenarios. The cover story is as follows:

(a) 2D Simulation


(b) 3D Simulation Figure 1.6 Evacuation Simulation (by T. Kawasoe and K. Minami)

In 200X, an evacuation simulation involving Kyoto subway and railway stations 3 is conducted in 3D virtual Kyoto with hundreds of socially engaged agents. Twenty or more citizens participate via the Internet. The data is collected and analyzed for planning real evacuations. In 200Y, a disaster occurs and a fire starts in the stations. The situation in the physical space is captured by omni-directional cameras and sent to the control center through wireless networks. The movement of people as a group is grasped and displayed on a central screen. Based on the results of previous evacuation simulations, appropriate directions are sent to the peoples’ mobile terminals, and agents start to guide them.

The evacuation simulation brings up the following issues. What can we learn from the simulation results in virtual spaces? Even if the simulation indicates heavy casualties, it is not clear what this means. People may think the virtual space simulation is just like a video game. We thus started scientific research from two different aspects. The first aspect is to understand how humans behave differently in the physical space from the virtual space. People are given the same task in both spaces (for instance, leave via a given exit) and all

3 Kyoto's resident populations about one million, with approximately forty million people

visiting each year. Since there is no airport, all visitors come through Kyoto railway station.


fixations recorded by eye cameras are analyzed. We are interested in how difficult it is to move in virtual space without peripheral vision, which is inherent in physical space. The second aspect is to understand the difference between human-human and human-agent interaction. We trust software when it is efficient, while we trust humans not because they are efficient. Therefore, human reactions may differ according to whether the directions were given by humans or by software officers, but different in what way? These issues must be analyzed carefully in controlled experiments before conducting large-scale simulations. 1.5.2 Social Psychological Study of Agents To understand the nature of agents, several social psychological experiments have been performed [10]. However, the effects of introducing agents in human communities have not been investigated. We are currently conducting experiments to see how agents can support human communication and influence human relations. Agents can act as go-betweens among people who have different social roles such as inhabitants and visitors, the young and the aged, and so on. In our experiment on cross-cultural communication between Japanese and American students, the agents influenced not only the impressions of agents but also the impressions of conversation partners and the stereotypes of nationalities. For example, if the agent encouraged students to discuss political problems, the Japanese students became as talkative as the Americans [4]. Figure 1.7 shows a screen of FreeWalk in these experiments. The dog-shaped agent is supporting human-human conversation. An application designer (social psychologist) needs to repeatedly carry out experiments in various settings in order to study the nature of the socially engaged agent. In these experiments, the user interface for communicating with the agent is very simple. The agent does not use voice—it presents questions to the users in a text-balloon above its head. (We thought text was far less intrusive than audio.) The users indicate ‘yes’ or ‘no’ using the mouse to click on their answer. The scenario in this case is fairly complex as follows: At first, the agent selects one topic from its repertoire of safe (or unsafe) topics, out of those that have not yet been used. It then randomly chooses one of the two participants as the target for the first question (Figure 1.7 (1)). Let’s call this person A. When A answers (Figure 1.7 (2)), the agent replies to A’s answer (Figure 1.7 (3)). Based on A’s answer, the agent then chooses a follow-up question and turns to B to pose the question (Figure 1.7 (4)). When B answers, the agent makes a general comment to guide the participants into addressing this topic. This general comment is selected based upon the previous answers from the


participants, so that it makes sense given their replies. After making this comment, the agent departs. If at any time a user does not respond to the agent’s question, the agent will wait for a while, and then return to idling mode, without trying to continue its line of questioning.

Person A is asked the first question (1), and responds (2), then the agent comments (3). Next person B is asked a question. Note that the agent faces the person it is addressing (4).

Figure 1.7 Example Scenario in Social Psychological Experiments In February 2002, we ran a joint class for social psychological experiments between Kyoto University4 and Stanford University5 using FreeWalk via the Internet. In this class, several groups of Japanese and American students planned and carried out experiments to understand the nature of human behavior in a virtual space. Figure 1.8 displays how American and Japanese students used FreeWalk for cooperatively designing social psychological experiments. Students decided to work on topics including “the difference between American and Japanese work styles in virtual spaces” and “the difference between American and Japanese impressions of computer characters that look American or Japanese.” Q was used to describe the scenarios of students’ experiments.

4 Department of Social Informatics, Kyoto University 5 Department of Communication, Stanford University


Figure 1.8 Discussions between Stanford and Kyoto Students (by H. Ito) 1.6 Conclusion Agent description languages have been intensively studied, but are not yet widely used for various applications. To include views from application designers, we developed Q, a scenario description language, to capture interaction patterns among agents and humans. Scenarios also foster the emergence of dialogs between agent designers and application designers. Q has been designed to support two different legacy systems: Microsoft agents and FreeWalk agents. This makes the development of Q is highly practical and realistic. The reason that totally different agent systems can be supported is because Q is a language for describing human requests to autonomous agents.

Table 1.3 Comparison of Computational and Social Agents

Computational Agent Social Agent

Model Internal Mechanism Interaction Patterns Description Program Scenario

Creator Computer Professionals Scenario Writers Goal Correctness Robustness Test Debugging Codes Rehearsal

Outcome Computational Society Agent Mediated Community Table 1.3 summarizes the difference between computational and social agents. Compared to previous languages for computational agents, Q does not assume


the correctness of multi-agent scenarios. Rather it combines execution layer and meta-layer to create robust agent behavior. In Q, errors in scenarios are corrected not by debugging codes but by rehearsals. Metaphors of human communities are introduced in Q for support agent-mediated communities. As more humans and agents coexist in the Internet, the need for describing multi-agent scenarios will become essential to realize a wider variety of Web applications. If we allow agents to be completely autonomous, the whole system becomes hard to control. It is necessary to give social constraints as scenarios so that agents use them to guide their behavior. Remaining research issues include how agents should behave under given social constraints. Acknowledgements This work would not have been possible without the contributions of R. Hishiyama, K. Isbister, H. Ito, T. Kawasoe, Y. Kitamura, K. Minami, Y. Murakami, C. Nass, S. Takata, K. Tsutsuguchi, and A. Yamamoto. FreeWalk and Q have been developed by Department of Social Informatics, Kyoto University and JST CREST Digital City Project. The source codes can be obtained from http://www.digitalcity.jst.go.jp/Q/.

References

1. John E. Laird and Paul Rosenbloom. The Evolution of the Soar Cognitive Architecture. David M. Steier and Tom M. Mitchell Eds. Mind Matters: A Tribute to Allen Newell, Lawrence Erlbaum Associates Inc., pp. 1-50, 1996.

2. T. Finin, R. Fritzson, D. McKay, and R. McEntire. KQML as an Agent Communication Language. International Conference on Information and Knowledge Management (CIKM-94), 1994.

3. E. Gat. Three-Layer Architectures. D. Kortenkamp, R. P. Bonasso and R. Murphy Eds. Artificial Intelligence and Mobile Robots: Case Studies of Successful Robot Systems, MIT Press, pp. 195-210, 1998.

4. K. Isbister, H. Nakanishi, T. Ishida, and C. Nass. Helper Agent: Designing an Assistant for Human-Human Interaction in a Virtual Meeting Space. CHI-00, pp. 57-64, 2000.

5. T. Ishida and K. Isbister Eds. Digital Cities: Experiences, Technologies and Future Perspectives. Lecture Notes in Computer Science, 1765, Springer-Verlag, 2000.

6. T. Ishida. Digital City Kyoto: Social Information Infrastructure for Everyday Life. Communications of the ACM, Vol. 45, No. 7, 2002.

7. Y. Kitamura, T. Yamada, T. Kokubo, Y. Mawarimichi, T. Yamamoto, T. Ishida. Interactive Integration of Information Agents on the Web. M.


Klusch, F. Zambonelli Eds. Cooperative Information Agents V, Springer-Verlag, pp. 1-13, 2001

8. K. Kuwabara, T. Ishida and N. Osato. AgenTalk: Describing Multiagent Coordination Protocols with Inheritance. IEEE Conference on Tools with Artificial Intelligence (TAI-95), pp.460-465, 1995.

9. H. Nakanishi, C. Yoshida, T. Nishimura and T. Ishida. FreeWalk: A 3D Virtual Space for Casual Meetings. IEEE Multimedia, Vol.6, No.2, pp.20-28, 1999.

10. B. Reeves, and C. Nass. The Media Equation: How People Treat Computers, Television, and New Media Like Real People and Places. Cambridge University Press, 1996.

11. T. Sugiman and J. Misumi. Development of a New Evacuation Method for Emergencies: Control of Collective Behavior by Emergent Small Groups. Journal of Applied Psychology, Vol. 73, No. 1, pp. 3-10, 1988.

12. Y. Y. Yao, N. Zhong, J. Liu, and S. Ohsuga. Web Intelligence. N. Zhong, Y. Y. Yao, J. Liu and S. Ohsuga Eds. Web Intelligence: Research and Development, Springer-Verlag, pp. 1-17, 2001.

1. designing scenarios for social agents - ishida …. designing scenarios for social agents toru...

Documents