Missing:
Providing Opportunistic Access to Information Sources and Services for Mobile Users Marcela Rodríguez1,2 ,Jesus Favela1 and Miguel A. Muñoz1 1
Departamento de Ciencias de la Computación, CICESE, Ensenada, México 2 Facultad de Ingeniería, UABC, Mexicali, México {marcerod, favela}@cicese.mx
Abstract Ubiquitous computing is the method of augmenting and improving work practices and knowledge sharing, by making computers of all scales, available but invisible throughout the physical environment, while amplifying human-to-human communication. Personal systems, such as PDAs and cell phones, give users access to computing resources regardless of their location. Handheld computers are being transformed from personal electronic agendas into mobile communication devices with intermittent network connectivity. Thus, they are becoming a natural medium to tap into an ubiquitous computing infrastructure. However, handhelds most often operate disconnected from the network thus reducing the opportunities for spontaneous interoperation with other peers or web services, which is a desirable feature of ubicomp environments. Autonomous agents can enable spontaneous collaboration by representing users, as well as devices or services available through the Web, which has become an ubiquitous medium for information sharing. An agent acts on behalf of the user while he is disconnected, and represents services added to the environment, thus allowing the physical integration and interoperability of these entities. We present the SALSA framework, which allows developers to implement simple agents for ubicomp systems. These agents use an expressive communication language based on XML, which provides protocols for locating and interacting with Web services even when the user is disconnected.
Introduction Ubiquitous computing (ubicomp) is the attempt to modify the traditional desktop interaction paradigm by distributing computers, of all scales, into the environment surrounding the user to augment and improve work practices and knowledge sharing while amplifying human-to-human communication. Thus, the notion of ubiquitous computing allows greater user mobility. Mobile computing devices, such as Personal Digital Assistants (PDAs) and smart cell phones, are becoming extremely popular. As new services and more powerful devices reach the market this tendency will certainly continue in the near future. Thus, these Copyright © 2002, American Association for Artificial Intelligence (www.aaai.org). All rights reserved.
devices are becoming a natural medium to tap into an ubiquitous computing infrastructure. Handheld computers are being transformed from personal electronic agendas into mobile communication devices with intermittent network connectivity. Ubicomp environments allow mobile users to interact with other users and with devices that provide almost constant access to information and different kinds of services (printers, whiteboards, cameras, etc.). However, handhelds most often operate disconnected from the network thus reducing the opportunities for spontaneous interoperation with other peers or services, which is a desirable feature of these environments. Handhelds provide alternatives for network connectivity, yet they are often inactive and even when in use they are most of the time disconnected from the network, which severely limits their use for ubiquitous interaction with the environment’s entities. Autonomous agents can be integrated to ubicomp environments in order to enhance the collaborative activities of mobile users and allow their interoperation with other devices. Thus, we can envision a multi-agent system where autonomous agents act on behalf of the users while disconnected. In this case, an autonomous agent might be able to maintain a limited user presence and execute actions on his behalf while he is disconnected or inactive by performing actions, such as making decisions. Other agents can represent services added to the environment to allow their opportunistic utilization by users. These agents allow users to access computing resources available through the Web which has become an ubiquitous medium for information sharing. We present the SALSA framework, which allows developers to implement simple agents for ubicomp systems. These agents use an expressive communication language based on XML, which provides protocols for locating and interacting with services, users and other agents using Web technology and standards protocols. Our framework is developed from the premise that the Web provides a strong basis for pervasive mobile computing (Kindberg and Barton 2000). This premise is based on the web' s potential to realize ubiquitous access and its lightweight software requirements. Before we present the SALSA framework, we first discuss a couple of use scenarios to motivate the need for
autonomous agents, and the requirements of the software infrastructure that we have identified from these scenarios. Then, we introduce the architecture of SALSA and describe the behavior, structure, and communication means of the agents. Finally, we present a particular scenario of an ubiquitous collaborative application implemented with SALSA and our conclusions.
Autonomous Agents in Ubiquitous Collaborative Applications In order to lay the foundation of the proposed framework, we first present a couple of scenarios that describe the use of autonomous agents in ubiquitous collaborative applications. This analysis helped us determine key issues to be addressed in the development of the framework we are presenting. The applications analyzed and their associated use scenarios are described next.
Conference Scheduling Agent A user attends a conference with multiple simultaneous tracks. On her handheld device she fills a form in which she specifies her main interest within the scope of the conference. While she registers at the conference she connects her handheld to a point of presence provided by the conference to send her profile. This will launch an agent that communicates with another agent in the conference server to build for her a recommended personalized schedule given the user preferences. Once the schedule is generated it will be stored in the server to be downloaded to the handheld the next time the user is connected to the network. The data will be integrated in the calendar application in the handheld. As the conference progresses users could add notes or grade the talks they attend. If these notes are marked as being public they will be downloaded to the server when the user connects to a point of presence in the conference. Public notes from other users will be transmitted to the connected user, as will updates to the schedule based on recommendations by other users with similar profiles (Sarwar 1998). Users could also exchange notes and recommendations using their handheld computers without requiring a connection to the network.
An Agent that deals with Shared Resources A user is co-authoring a research paper with a couple of colleagues and he needs to incorporate his final contributions and send the paper today. However, the latest version of the paper is currently locked in a shared repository by one of his co-authors who has left town to attend a conference for the week. The user sends a message to his co-author’s agent who will decide, based on the context and the trust he has on the author making the request, whether or not to liberate the resource. Moran et al. describe a tool named Doc2U that could be the basis for supporting this scenario. With Doc2U shared
resources are added to the roster of an instant messaging and presence awareness application (Moral et al 2001). A user then can be aware of the state of resources, such as a document being locked. An instant message can be sent directly to a co-author or to a resource in the form of a command. In this case the decision to unlock a resource is left to the user, but he could have configured an agent to act on his behalf when he is disconnected or inactive. An agent can be seen in the roster of a handheld-based instant messaging application, such as Doc2U, as another user to which one can send messages or commands such as "launch". When the device has no access to network resources, all events generated are stored by the handheld application and later sent, when access to the network is provided or a synchronization process is performed. A similar approach is used for information flowing from the application server to the mobile device, if the device is not accessible, all messages and other events are blocked until the exchange of data is possible.
SALSA Development Framework’s Requirements The SALSA (Simple Agent Library for Sope Applications) development framework must enable developers to build autonomous agents that act on behalf of a user. An agent might be able to maintain a limited user presence and execute actions on the user’s behalf while he is disconnected or inactive. These two main characteristics, “acting for another” and “autonomy”, and the proposed use scenarios were used as the basis to discover and define all the characteristics that an agent living in an ubiquitous environment must have. These attributes are described next. Proactivity: Bradshaw uses the word proactivity as synonymous of autonomy, which means goal-directedness and self-starting behavior (Bradshaw 1997). Temporal continuity: An agent will live in its environment until it has reached its goals, by maintaining its persistence and state over long periods of time. SALSA provides an agent life cycle and considers that the agents reside in a trusted server or a desktop computer. Reactivity: an agent perceives its environment and responds in a timely fashion to changes that occur in it (Wooldridge and Jennings 1995). Ubiquitous computing environments contain components, which are fixed or mobile, such as PDAs, that enter and leave routinely. Thus, an agent allows users to become aware of the available services or users with whom to interact. Collaborative behavior: An agent can work in concert with other agents to achieve a common goal (Bradshaw 1997). Thus, an agent is part of a multi-agent system. Communication ability: The agent must be able to communicate with the user or the device that it represents, and with other agents in order to collectively tackle problems that no single agent can handle, individually.
Access Point
Printer
Agent HTTP Server
Initialize and Register
Agent Directory
Perception Reasoning
Agent
Device Jabber interface Client
Action
Initialize and Register User
Perception Reasoning
User interface
Jabber Client
Jabber Server
Action
Figure 1. Architecture of an ubiquitous computing environment created with SALSA
Then, for agents to communicate with each other they need a common language. We identified the following functional requirements for the SALSA architecture in order to support users in ubiquitous computing applications: Provide an infrastructure of services that enable the naming, registration, authentication, and localization of agents, and a simple API to develop autonomous agents with the above characteristics. Support for disconnected mode of operation. An agent acts on behalf of the user when he is disconnected or inactive. Allow the interoperation between users and devices by notifying the presence and status of new devices offering services and allowing the interaction with them. Authentication. By the authentication of the user’s handheld, the agent recognizes the user that it represents when he gets connected to the network or any user with whom it should interact according to its action plan. Users should be able to launch agents explicitly or they could be launched automatically when certain conditions are met. Agents might be able to communicate with its user and with other agents in other desktops or a server. Additionally, agents can read and write to the repository where the user' s personal information is stored (agenda, todo list, preferences, etc.).
SALSA’s Architecture The architecture and functionality of SALSA to support agents living in a pervasive computing environment is illustrated in Figure 1, in which the main components of a SALSA application are the following: A terminal or desktop computer that acts as an access point. This computer is used to access both networked information and the handheld device. Wireless connectivity to the access point is increasingly a viable option with the proliferation of devices that support the Bluetooth and IEEE 802.11b standards. The access point runs an HTTP server to handle XML/HTML communication with the
handheld. In addition, it stores the Agent Directory to which agents representing services and users will register. Jabber server. Jabber is an open instant messaging and presence awareness system. This server (http://www.jabber.org) is used to notify the state of people and agents, and to handle the interaction between people, agents and devices through XML messages. All communication between the handheld and the agent will go through this server. The information in the user’s handheld is synchronized with the server every time the device is connected to a point of access. Agents. There are two kinds of agents that can be implemented with SALSA: agents that represent users and agents that represent devices. These agents might run in the access point or any other computer with connectivity to the access point. They can be launched explicitly by the user or automatically when certain conditions are met. An agent contains several components: a protocol to register into the Agent Directory; an interface to the device that acts as a wrapper to query its status and interact with it or an interface that allows the user to introduce information by which the agent learns his interests; a Jabber client to notify the device' s status to all interested users and receive XML messages through which remote users, user’s agents and device’s agents interact; and finally, the subsystem that implements the agent’s intelligence that contains components for perception, reasoning and action. The perception module obtains knowledge (from interfaces to environment’s sensors or getting information of users, other agents or devices through the Jabber server, such as their state), and feeds the reasoning subsystem, which governs the actions, including deciding what to perceive next. Among the actions that can be triggered by an agent are included sending a message to the user or creating a new agent with a predefined subgoal. The reasoning component can be implemented as a simple action/perception rule or with a more sophisticated algorithm, which is left to the user based on his application' s logic. Devices. These are appliances that offer services and are connected to the local network. Communication with the device is made through its agent. Devices define possible
states, the services it offers, and the protocol used to interact with them.
Deactivated. If the agent has fulfilled its obligation, then it is deactivated and consequently killed. activated
Agent Development Framework
communicating suspended
Agent’s Behavior Agents are computer programs that have goals and methods to achieve these goals. They are implemented to assist a user in accomplishing a task. An agent can be used to search for information, schedule a meeting or perform actions on behalf of the user. Agents exhibit autonomous behavior in the sense that they use internal mechanisms to make decisions as to how to reach their goals. Pattie Maes identified two issues to be dealt with in designing and implementing autonomous agents: competence and trust (Maes 1994). Competence related to the mechanisms used by the agent to acquire knowledge and make decisions. Agents normally acquire competence by observing and imitating the user and receiving feedback from it, thus adapting their behavior to conform to the user’s expectations. The issue of trust relates to the confidence that the user has on the agent to delegate work on him. Trust is build over time based on the agent’s response to the tasks assigned to it.
Agent’s Life Cycle A SALSA agent has a life cycle, which, as shown in figure 2, includes these states: Activated. This is the original state of an agent when it is created. This is a super-state that contains different substates that an activated agent can present. Learning. It is the initial sub-state. An agent acquires knowledge of its environment in different ways. For example, by explicitly receiving information from the user, a service or another agent, from a sensor’ s interface that detects a new device/service added to the environment, or thru learning. An agent gets into this state if its action plan requires it. That is, it moves from the executing state to the learning state. Thinking. The agent analyzes the obtained knowledge in the learning state in order to establish its goals and an action plan to reach these goals. Executing. In this state the agent performs the action plan proposed previously. Communicating. The agent interacts with one or more agents in order to get information necessary to fulfill its goals. An agent can get into this state if it is dictated by his action plan or because the agent needs to request specific knowledge. Suspended. An agent in this state is alive but it is not performing any activity. It is waiting to be activated again. For example, if an agent is waiting from information that it has requested to another agent, then it changes from the communicating state to the suspended state, and when contacted by the other agent, its state returns to communicating.
learning created thinking generating its goals
evaluating
executing selecting actions
desactivated
killed
Figure 2. The life-cycle of an agent
Agent Communication An ACL (Agent Communication Language) provides agents with the means to exchange information and knowledge through a set of communicative acts. The purpose of these acts is to convey information about the agent’ s own mental state with the objective to affect the mental state of the communication partner (Labrou 2001). We usually hear agents mentioned within the context of the Web, and the Internet is the arena in which we generally expect them to compete. But ACL’ s. such as, KQML and FIPA ACL have followed a path away from the mainstream Internet technologies and standards (Labrou and Finin, 1999). They also do not cover the entire spectrum of what agents may want to exchange. The content of the message (beliefs, desires, intentions) is expressed in other languages, such as, KIF, Prolog, etc. (Finin et al 1994). The SALSA development framework must provide an expressive language that enables the exchange of different kinds of objects between agents (such as actions, beliefs, goals, or simple messages), between agents and users (such as the user’ s profile), and between agents and services (such as the service’ s state). This information must be exchanged through the Web, which permits ubiquitous access to resources and information. The Web is an appropriate platform for the support of pervasive computing because it is accessible from a large and rapidly growing number of places (Kindberg and Barton 2000). The Web relies on the HTTP protocol, which can be implemented on a vast variety of devices, such as devices that the user carries, e.g. personal digital assistants (PDAs) and laptops, and devices that provide specific services, such as digital cameras and printers. Furthermore, the Web supports mobile users through its flexible global addressing scheme, allowing them transparent access to resources outside their current environment. Finally, the form of interaction with particular devices and other entities, such as autonomous agents, can be encoded using XML (eXtensible Markup Language) (Kindberg, and Barton 2000). A number of researchers have suggested that ACL messages and its content ought to be encoded in XML
because it offers several advantages over traditional ACLs, e.g. KQML and FIPA ACL, which are based on Lisp-like encoding (Labrou 2001): 1. XML describes data in a human-readable format 2. It is a database-neutral and device neutral format. Data marked up in XML can be targeted to different devices using the eXtensible Style Language (XSL). 3. XML-encoding is easier to develop parsers. One can use off-the-shelf tools for parsing XML, instead of writing customized parsers to parse the ACL messages. 4. Makes the ACL more WWW-friendly, which facilitates the development of software agents. 5. Using XML will facilitate the practical integration with a variety of Web technologies. 6. XML incorporates links, which allow to interface the ACL message to the knowledge repository that is the WWW. Our proposal for the SALSA development framework is to use a more Internet friendly agent language taking advantage of XML to encode any kind of message. Thus, SALSA provides developers an API that facilitates the composition, sending, and receiving of messages between agents, agents-services, and agents-users. However, the code for every content message type of the communicative act is left to the programmer, because it depends on the application logic and the details of the agent system of the ubiquitous collaborative environment.
SALSA’s Library The SALSA library consists of a set of abstract classes such as, Agent, Goal, Knowledge and Action. The Agent class provides the methods to create and control the life cycle on an agent. Thus, an agent can be created with a specific goal, which is specified in an object Goal. The agent first invokes the learn method which the developer needs to specialize to implement a simple or complex learning mechanism, such as, a decision tree or a neuronal network that will create a Knowledge object. Then, the think method is invoked to create an Action object that contains the action plan, which the agent will execute. The Agent class contains others methods, such as authenticate that is used to recognize the represented user each time he connects to the network, or any other user that should be contacted by the agent, and the send and receive methods to exchange XML messages with other agents or users. Agents also include attributes, for instance, the agentKind attribute specifies if the agent represents a user or a device, the Identification object contains information about the user or device that the agent represents (its localization and id), the AgentDirectories object contains information of all the agent directories where the agent is registered. The contents of the Goal, Knowledge and Action objects can be specified using first order logic statements or simple statements and conditions. It depends of the application’ s complexity and logic. Next we describe how an agent can be implemented to enhance an ubiquitous application.
A Couple of Sample Applications To illustrate how the components of a SALSA’ s application interact, we show in Figure 3, a sequence diagram based on the scenario “ An Agent that Deals with Shared Resources” , and we present in Figure 4 the sample application, which is describe next.
:Handheld application
:Jabber server
:Agent
:HTTP Server + Webdav
Message(unlock index2.html, userId) authenticate(userId) think(userId)
receive(unlock index2.html, userId)
execute(unlock index2.html) Message(“unlocked index2.html”) Message(“unlocked index2.html”)
Figure 3. Sequence diagram of a sample ubiquitous computing application
One of the authors sends to his co-author a message requesting to liberate the document index2.html. Due the co-author is not available, the message is intercepted by his agent, which analyzes the request and authenticates the user by checking a predefined list of co-authors and accessing WebDAV to obtain information of the user’ s rights on the document. Than, the agent executes the method think, which will analyze the context of the situation in order to generate an action plan. The agent, by a mechanism of action/perception rule, decides to liberate the document considering that the requester is the main author, the dateline is very close, and that it doesn’ t know when the coauthor will be available to attend this request. Finally, the agent sends a message to the authors notifying that the document has been unlocked.
Figure 4. Handheld’ s client of the ubiquitous computing application
Context-aware computing has been closely associated to ubiquitous computing. Context-aware computing refers to an application’ s ability to adapt to changing circumstances and respond based on the context of use. Mobile users are constantly changing their context, most notably their location. Additionally, context-awareness often requires the use of sensors and computing devices set in the environment in order to establish the context of use. Consider for instance, the following scenario: Theresa is a doctor in a local hospital. As she makes her final round, she notices that a patient is not responding well to her medication. She wishes to leave a note to the doctor who will be in reviewing the patient in the afternoon shift. She doesn’t know who that will be, so she writes a message to the first doctor to check the patient after her. As noted in this scenario, there are circumstances that require the sending of messages to a person or device, that might depend on the context (location, time, availability, etc.). For instance, the doctor in the scenario described might wish to send the message to the first doctor to be at a particular location (around a patient’ s bed) during the afternoon shift and once the results of his medical analyses have been reported. Another scenario might involve a user wishing to send a document to the first printer to become available when he is moving around a previously unknown location. Based on these requirements we decided to extend the instant messaging paradigm to support what we refer to as context-aware communication, by allowing users to specify a set of circumstances that need to apply for a message to be delivered; we refer to this as context. For instance, the sender can indicate that the message will be delivered to the specified recipient when she enters the emergency room; or for the message to be sent to the last person to leave the laboratory when the air conditioning is on. For the purposes of the scenarios we have envisioned we
a)
b)
consider the following elements of context to be relevant: The identity of the person to whom the message will be sent. The identity could be stated in terms of a role (i.e. doctor, nurse, etc.) or to any or all users that meet the criteria specified by other elements of context (location, time, state, etc.). A period of time during which the message can be sent. A place or geographic location. The state of a device and represented by a SALSA agent. To implement context-aware messaging we are using an instant messaging platform of SALSA. We have already implemented a prototype of a client’ s user interface on WindowsCE (see Figure 5). This prototype is being developed specifically to operate in a local medium-size hospital. To support the delivery of messages that are dependent on context we introduce the concept of “ context agent” . This is an entity to which all context-aware messages will be sent. The context agent will monitor the environment to determine whether conditions are met for the delivery of the messages it retains before they expire. This agent is a first class entity registered in the instant messaging server and with an IM roster that includes all people and devices of whose state it needs to be aware to deliver a message. We divide the discussion of the design of the interface of the client in two. On the one hand we need a lightweight interface for the user that composes the message to be able to easily specify the context of delivery. On the other hand, slight changes are required when the message is finally presented, for the reader to have enough context to understand the message received. In contrast with traditional instant messages, when a context-aware message is created the sender needs to specify the circumstances that need to be met for the message to be delivered. In the spirit of the simplicity and ease of use of instant messaging applications the additional information that the sender needs to specify should not add
c)
Figure 5. Prototype of the context aware messaging system. a) Roster of the people and devices registered with the user; b) Sending a context-aware message that specifies location date and time of delivery; c) Map displayed for the user to specify the location where the recipient (person or device) needs to be for the message to be delivered.
significant cognitive overhead to the user. In Figure 5.b we present the interface that is presented to the user for him to specify the context for message delivery and write the message itself. A user can specify the following information to provide adequate context for message delivery: Recipient. The user can send a message to a specific user; to all users that meet the additional criteria; or only to the first user that satisfies the criteria. In our current prototype the sender could also specify the recipient’ s identity by role, for instance, to any doctor, to all nurses. Location. The sender specifies an area where the user needs to be for the message to be delivered. For this purpose a sensitive map is displayed for the user (Figure 5.c), where he selects the designated area. The estimation of user location hay not yet been implemented in the prototype, we plan to do it by triangulation of at least three 802.11 access points (Bahl and Padmanabhan 2000). The module that we are currently implementing for these purposes, will be itself a SALSA agent that wraps a backpropagation neural network, previously trained to map the signal strength to each access point to the user’ s location. Time and date. The sender can specify a lower and upper bound of time and date for message delivery. He could specify either one or both. The message won’ t be sent before the minimum date indicated and will expire without delivery after the maximum time. State of a device. Devices define in the SALSA platform the set of states at which they can be at a given time. This list of states for all registered devices is presented to the user if he wants to specify that the device needs to be at a given state as a constraint for message delivery. For instance, send the message if the lights are on; the printer is jammed; the camera has detected movement; etc. From the perspective of the user that receives a contextaware message, it might be important to be aware of the context specified for message delivery, since this information could be useful for him to make sense of the message. For instance a message that states “ medicate this patient when his analyses are completed” might not be fully understood if the user is not aware that the message was meant for delivery at a specific location, the patient in certain room in this case. Given that the messages are not necessarily sent immediately after they are composed, the system should allow users to go back, consult the messages they have sent, and modify or delete them.
Conclusions In this paper we describe the SALSA architecture, which uses a combination of the instant messaging paradigm and agent technology to support the disconnected mode of operation of users and the opportunistic interoperation with services. Instant messaging has proven to be an efficient interface to support casual interaction; the applications implemented with SALSA, provide an adequate balance
between awareness, privacy and disturbance. By incorporating awareness of resources and devices, new opportunities for spontaneous collaboration arise. Autonomous agents that act on behalf of the user and reside on a desktop computer or trusted server, can maintain a limited user presence and execute commands or make decisions on his behalf while he is disconnected or inactive. Developers that wish to add a new agent to represent a user or a device in a pervasive computing environment need only to program an interface to the device or user by defining an XML document to specify the interaction with them, and overwrite some methods of the abstract Agent class according to the application’ s logic. References Bahl, P. and Padmanabhan V.N. 2000. RADAR: An InBuilding RF-Based Location and Tracking System. In Proceedings of IEEE INFOCOM, Mar. 2000, (2):775-784. Bradshaw, J. Eds. 1997. Software Agents. AAAI/MIT Press. Finin, T., Fritzson, R., McKay, D., McEntire, R. 1994. KQML as an Agent Communication Language. In Proceedings of the Third International Conference on Information and Knowledge Management, 456-463, ACM Press. Glushko, R., Tenenbaum, J., Meltzed, B. 1999. An XML Framework for Agent-based Ecommerce. Communications of the ACM, March 1999, (42)3: 107-114. Kindberg, T., Barton, J. 2000. A Web-based Nomadic Computing System. Computer Networks, Special Edition on Pervasive Computing, Elsevier. HP Labs Technical Report #2000-110. Labrou, Y., Finin, T., Peng, Y. 1999. Agent Communication Languages: The Current Landscape. IEEE Intelligent Systems, March/April 1999, (14) 2: 45-52 Labrou, Y. 2001. Standardizing Agent Communication. In Proceedings of Advanced Course on Artificial Intelligence (ACAI-01), 74-97, Springer-Verlag Press. Maes, P. 1994. Agents that Reduce Work and Information Overload. Communications of the ACM, July 1994, (37)7: 30-40 Moran, L., Favela, J., Martinez, A., Decouchant, D. 2001. Document Presence Notification Services for Collaborative Writing. In Proceedings of the Seventh International Workshop on Groupware , 125-133. Sarwar, B. 1998. Using Filtering Agents to Improve Prediction and Quality in the GroupLens Research Collaborative Filtering System. In Proceedings of CSCW, 345-354, ACM Press. van Ejic, R. 2002. Semantics of Agent Communication: An Introduction. In Proceedings of UKMAS 1996-2002, LNAI 2403, 152-168, Springer-Verlag Press Wooldridge, M., and Jennings, N. 1995. Intelligent Agents: Theory and Practice. Knowledge Engineering Review, (10)2:115-152, Cambridge University Press.
