Task-Structure Based Mediation: The Travel-Planning ... - CiteSeerX

Task-Structure Based Mediation: The Travel-Planning Assistant Example Qihua Situ and Eleni Stroulia Department of Computing Science University of Alberta 615 General Services Building Edmonton, AB T6G 2H1, Canada qihua,stroulia @cs.ualberta.ca




Abstract. As the number of applications available on the World Wide Web (WEB) increases at a rapid speed, an enormous number of resources become available to the general public. These resources offer information and services in a variety of domains but are often difficult to use due to their idiosyncratic domain and interaction models. In this paper, we discuss a multi-agent architecture for integration of WEB applications within a domain, based on a task-structure approach. The architecture consists of a set of wrapper agents, driving and extracting information from a set of corresponding WEB applications, and a mediator agent, whose task structure drives both its interaction with the users and its communication with the wrappers. We illustrate this architecture with the description of a travel-planning assistant that supports the users in an exploratory, least-commitment search behavior.

1

Introduction

As the number of applications available on the World Wide Web (WEB) increases at a rapid speed, an enormous number of resources become available to the general public. These resources offer information and services in a variety of domains, such as stockmarket, insurance purchasing, medical prescription ordering and travel planning, just to name a few. However, these applications are often difficult to use. There are several reasons that contribute to this difficulty. Some WEB applications expose a cumbersome and unintuitive interaction model to their potential users because of their underlying implementations. For example, some WEB applications run on legacy systems whose interfaces are ASCII screens and require, in general, fairly long navigations in order to accomplish any particular task. In addition, the majority of WEB applications, whether they are re-engineered on top of legacy applications or they were developed specifically for the WEB, offer a deterministic interaction model: they always require a set of specific inputs from their users and force them to go through a single standard sequence of steps. Such interaction models are not applicable in cases where the user’s 

In the Proceedings of the Thirteenth Canadian Conference on artificial Intelligence. Published by Springer Verlag URL: http://www.springer.de/comp/lncs/index.html

problem is not well defined, but is of the type “I don’t know what I want, but I will recognize it when I see it”. In such cases, the user has to commit early to specific inputs without actually intending to, and if this early selection does not lead to a satisfactory solution, the user has to repeat the process with alternative input selections. To make matters worse, there is little commonality across WEB applications offering services in a domain. Any two applications in a given domain may use different terminology and interaction models for similar services. Mediation [9, 10, 14] is the integration of diverse and heterogeneous information sources by abstracting away the representation differences among them, and by integrating their individual views of the application domain into a common model. A mediator interacts with the users, translates the users’ requests into interaction protocols with the wrappers of its underlying information sources, collects and processes (i.e., sorts, summarizes, or abstracts) the wrappers’ responses, and, finally, presents the overall result to the user. To date, there are two veins of artificial intelligence research focusing on the two aspects of this overall problem. On one hand, there is work on automating the wrapper construction, such that the mediator can communicate in a canonical way with all its underlying sources. The wrapper construction process may be based either on user examples identifying the interesting elements on the presentation space that the source exposes [3, 11], or, on an underlying domain model [12]. In the same area, some work has focused on the use of eXtensible Markup Language (XML) [15] as the representation language for exchanging information on and about WEB sources, enabling the storage of data together with its semantics [1, 4]. Focusing more on the interaction of the mediator with the user, work on agents’ interaction languages has emphasized the need for well-defined semantics for high-level discourse. Elio and Haddadi [13] suggested that, in addition to performatives [16], high-level goal-specific structures are necessary to express the semantics of the discourse between a human and an artificial agent who cooperate to accomplish a common goal, such as a successive refinement search task, for example. In our work on agent-based WEB-application integration, we adopt and integrate several of the above lines of work: we have developed an architecture for task-specific mediation, in which, information sources within an application domain are encapsulated within wrapper agents which interact with an intelligent intermediary agent, the mediator. The mediator is designed to support users performing a particular task in the given application domain, such as least-commitment, exploratory search. The wrappers are designed to expose aspects of the underlying sources’ functionality useful for the mediator’s task. The mediator agent provides (a) a domain model to integrate the terminology of the integrated applications, and (b) a task model that drives its interaction with its users and its communication with the wrappers of the integrated applications. To date, we have developed a prototype of this architecture in the travel planning domain. The rest of this paper is organized as follows: section 2 discusses the overall mediation architecture, section 3 describes a prototype for a travel-planning mediator developed in this architecture and illustrates the mediator’s process with a specific example, and finally section 4 outlines some early conclusions that can be drawn from this work

and outlines our plans for future work.

2

A Task-Structure Based Mediation Architecture

In our work, we have focused on the problem of how a set of heterogeneous applications on the WEB can be integrated to deliver novel services within an application domain. The integration architecture discussed in this paper proposes a multi-agent approach to this problem. For our multi-agent integration architecture, we have adopted task structures as the mechanism underlying the agents’ behavior. Task structures [2] analyze problemsolving behavior in terms of elementary building blocks. Several formalisms have been developed for representing task structures for a variety of purposes, ranging from simulating expert behavior in knowledge-based systems to modeling software systems. In particular, the SBF-TMK language was used to model the design of a software system so that an intelligent agent could monitor the system’s actual run-time behavior, recognize failures, and reconfigure it at run-time or possibly redesign its design elements [5, 6]. In the SBF-TMK language, a task is characterized by the type(s) of information it consumes as input and produces as output, and the nature of the transformation it performs between the two. A complex task may be accomplished by one (or possibly more) method(s), which decomposes it into a non-deterministic network of simpler subtasks. A simple, non-decomposable task, i.e., a leaf task, corresponds to an elementary, executable operator. In addition to the system’s task structure, the SBF-TMK language also specifies the system domain, in terms of the types of objects that it contains, their relations and constraints on these relations. The information elements that flow through the task structure (produced and consumed by its tasks) are instances of the domain object types. This view of problem-solving behavior can be naturally transferred to our multiagent integration architecture of mediator and wrappers. The behavior of the overall multi-agent system can be modeled in terms of a non-deterministic task structure. The wrappers of the individual sources implement elementary leaf tasks using the services of their underlying sources. The mediator implements a set of high-level complex tasks, with non-deterministic decompositions. The user’s interaction with the mediator decides which task is active at each point in time and which decomposition is employed. When a particular task is sufficiently decomposed into elementary tasks, the mediator requests the relevant wrappers to accomplish them and to return their results. In addition to decomposing high-level tasks into elementary ones, the mediator task structure also provides the road map for composing the individual wrappers’ results in a coherent solution to the overall task at hand. For these reasons, we have adopted the SBF-TMK language to describe the internal processes of the mediator and the wrapper agents. To that end, we have developed an XML representation for the SBF-TMK language. XML is a subset of SGML, that allows user-defined tags in order to best describe the semantics of the data content. The 



Structure-Behavior-Function models of Tasks, Methods and Knowledge

Fig. 1. The Overall Mediator-Wrappers Architecture.

set of tags relevant to annotating entities, their attributes and their relationships in a particular domain is described in a DTD (Data Type Definition) document or an XML Schema. XML is fast becoming the de-facto standard for communicating on the WEB, and as more sources are specified in XML information extraction from these resources will become easier. Furthermore, different views of XML data can be specified in terms of a XSL (eXtensible Style Language) stylesheets, thus enabling customization of the data content and its presentation style for different purposes and different user preferences. Figure 1 shows the architecture diagram of the integration architecture. It consists of three layers, the user interface layer (left area of the Figure), the mediator layer (middle area of the Figure) and the wrappers’ layer (right area of the Figure). There are three different types of tasks in a mediator’s task structure: (a) user-interaction tasks, (b) internal tasks, and (c) information-collection tasks. User-interaction tasks are denoted with “post-it” rectangular shapes in Figure 1 and implement the mediator’s interaction with the user, i.e., requesting (or displaying) information from (to) the user. Internal tasks are denoted with rounded edge rectangles in the Figure, and accomplish information processing internal to the mediator. Finally, information-collection tasks are denoted with ovals in the Figure, and correspond to the leaf tasks implemented by the wrappers collaborating with the mediator. The interaction between the user and mediator is supported by a XML browser, such as Internet Explorer. The mediator presents to the interface layer, i.e., the user browser the alternative high-level tasks that it can support as a menu of possible selections. Note that, although in Figure 1 the mediator’s task structure is shown as a tree, it is in general a forest, i.e., it consists of a set of high-level tasks. This menu is automatically generated by an XSL stylesheet developed to translate task-structures to menu-driven interfaces. To initiate an interaction session with the mediator, the user has to specify the high-level task of this interaction session. In response, the mediator retrieves the task structure corresponding to the selected task and recursively descends from the root task to its subtasks. When, during this descent, a user-interaction task is reached, the mediator presents to the interface layer a form appropriate for the type of information that the user has to provide or receive. The generation of the form is based on the mediator’s domain model. The domain model is specified by an XML document, describing the domain objects and their relationships. For each element type in this document, an XSL stylesheet is defined for displaying elements of this type and for receiving values of such elements from the user in a form-based interface.

When the mediator reaches an information-collection task, it looks up the wrapper registry, denoted as the drum in the top-right corner of the mediator component in the Figure, to identify the wrappers that can fulfill the information transformation of the task at hand. The wrapper registry is essentially an association table mapping wrappers to the set of information-collection tasks that they can accomplish. Based on the wrapper registry, the mediator identifies which wrappers can produce the output information given the available input and sends them a request. For each elementary task that it can perform, a wrapper has a corresponding plan for driving its underlying application. For WEB applications the plan consists of a sequences of HTTP “post” messages followed by parsing of the source response. Parsing is also based on the domain model. Each wrapper contains a generic parser and a copy of the XML document describing the domain, annotated with extraction rules for recognizing elements of each type in the source’s responses. This annotated XML document defines a grammar for appropriately interpreting the application response in terms of the common domain model. Thus, for every request it receives from the mediator, a wrapper executes a three-step process, involving (a) mapping the input provided by the mediator to the input parameters of the plan, (b) executing the plan and (c) extracting the output desired by the mediator from the source’s response. The mediator then collects the data and continues its execution of the task structure. When an internal task is reached, if it is complex (denoted as bigger rounded rectangles in the Figure) it simply sets up a set of simpler tasks. If it is elementary (denoted as smaller rounded rectangles in the Figure) an internal mediator functionality is invoked to process the currently available information, i.e., to derive further information from the user’s input or to further process the information collected by the wrappers before presenting it to he user. These tasks enable the integration of further intelligent processing of the data available in the domain.

3

The Travel Agent Prototype

Let us now discuss an instantiation of this architecture, consisting of a travel agent mediator and a set of related brokers, to illustrate our ideas discussed above. Personal travel assistants are one of the seven areas specified by FIPA [7]. In this specification, ...the PTA interacts with the user and with other agents, representing the available travel services. The agent system is responsible for the configuration and delivery - at the right time, cost, Quality of Service, and appropriate security and privacy measures - of trip planning and guidance services. It provides examples of agent technologies for both the hard requirements of travel such as airline, hotel, and car arrangements as well as the soft added-value services according to personal profiles, e.g. interests in sports, theater, or other attractions and events.

Our travel mediator currently interacts with the following information sources: – An XML table, describing airports, their codes and their location in terms of country, state and city. This table was produced by wrapping the HTML source at http://www.cowtown.net/users/rcr/aaa/ccmain.htm.

– ITN, an on-line travel reservation system, exposing a form interface to the users: http://www.itn.com/. A wrapper was hand-crafted for ITN.

Fig. 2. A diagrammatic depiction of the mediator’s domain model (top) and task structure (bottom).

Figure 2 depicts the travel mediator’s domain model (top of the Figure) and task structure (bottom of the Figure). The domain objects include air ticket, date, location, flight and fare. A date is specified in terms of a year, month, day and time. A location is specified in terms of a country, state, city and airport. A flight is specified in terms of an airline and flight code. A fare is specified in terms of currency and amount. An air ticket is specified in terms of origin and destination, both of which are locations, departure and return dates, both of which are dates, departure and return flight which

are flights, and air fare which is fare. An interesting aspect of the model is that the attributes of location and time have domain-level relationships. For example, country, state and city are all attributes of location, but at different levels of specificity. state is at a lower (more specific) level than country, and at a higher (more general) level than city. The underlying intuition is that values at one level are collapsed and summarized at the next higher level, and a value at one level corresponds to a collection of values at the next lower level. The concept of domain level is very important for supporting flexible, exploratory search behaviors. It enables the interpretation of vague problem statements, i.e., statements expressed in terms of attribute values at a high level, into a collection of specific ones, i.e., expressed in terms of their corresponding values at lower levels. So for example, when the user does not want to commit to a specific destination airport but only to a city, the mediator is able to translate this vague problem statement in a collection of problems each of which has as the destination airport one of the airports close to the given city. Alternatively, when the user has made strong and mutually exclusive commitments, the mediator may explore possible relaxations by substituting the specific elements of the problem statement with more general ones at a higher level of abstraction. The mediator’s overall task (shown at the bottom of Figure 2) is travel planning, which is decomposed in (any of) the following tasks: finding airfare, renting a car and making a hotel reservation. All these three tasks are instances of a single generic task, i.e., exploratory search - indicated by the dashed line arrows in the Figure. The outputs of these tasks are correspondingly an air ticket, a car rental and a hotel reservation. Because these tasks are all instances of the exploratory search task, their inputs can be any combination of values for the attributes of the desired output. So for example, the input of the fare-finding task can be any combination of values for the air-ticket attributes, that is origin and destination locations, and departure and return dates. The user may specify these inputs at any level of specificity, i.e., at any level in the location and date domains. The search task structure of the travel-assistant mediator is designed for ill-structured problems, where a precise specification of the desired output is not available and instead, the user explores the solution space following a least commitment strategy [13]. The overall search task is decomposed into six subtasks. First, the problem inputs are specified by the user. The problem inputs are attributes of the solution, so essentially in this task the user specifies the problem as a set of constraints on the range of values that different attributes of the solution may take. The mediator then generates a set of detailed problem specifications, by refining all the abstract elements of the input problem specification to their most specific domain levels. Then the mediator identifies the relevant wrappers that are able to solve the problem, communicates the problem to them and collects their solutions. If no solution is found, the mediator requires the user to relax some of the original constraints, i.e., to specify some input at a higher domain level, and it tries again. If some solutions are found, the mediator can further process the solution set by deriving additional attributes for the solutions, such as total length of travel for example. Finally, the mediator evaluates the size of the result set. If it is small, the mediator presents all the solutions to the user, and allows the user to decide on one

of the returned solutions or to further modify (relax or strengthen) the constraints. If the solution set is too large, the mediator proposes to the user dimensions of the input specification that could be further constrained, and gives appropriate suggestions to the user. The process continues until either a satisfying result is found or the user quits. When this search task structure is invoked in service of the air ticket finding task, it is instantiated in the context of this task’s input-output transformation. Thus, first the ticket finding inputs are collected, and subsequently refined, then the appropriate wrappers of ticket reservation sources are invoked to identify possible tickets that would correspond to the problem in question and then the resulting tickets are collected. The tickets are presented to the user in a tabular format that can be sorted according to all its attributes, such as price or length of travel or length of stopovers for example. By reviewing the ticket collection according to different attributes, the user may select a specific ticket or decide on how to further refine the problem specification. 3.1

An Example Scenario

In this section, we discuss a specific scenario to illustrate how the exploratory search behavior is supported in the context of finding air tickets. A user plans a vacation “to California in July”. “July” and “California” are too vague for querying any of the current travel-agent WEB applications. The specific destination and date may eventually depend on the availability of flight seats and the price of the airfare, but in order to make more precise decisions the user may want to evaluate the possible options. For such problems, the specification of the problem may shift around within the domain. The above specification implies a range of destinations and a range of departure and arrival dates. The mediator queries the city database to find all the cities in California, and then the airport database to find the airports in those cities and the airport in Edmonton. In this manner, the origin and destination are defined at the lowest, most precise domain level for locations. These queries are executed through an XQL engine [8], because the airport database is in XML. It then identifies, by executing an internal task, specific departure and arrival dates - two weeks apart from each other. All data related to specific user-mediator sessions are contained within the mediator’s session DOMs. The Document Object Model (DOM) is a programming API for HTML and XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the Document Object Model, documents have a logical structure which is very much like a tree. The mediator’s session DOM is used to store the data for every task execution. The session DOM has one child node for each user; each user node has one child node for each task; and finally each task node has two child nodes, one for input data and the other for output data. The mediator uses the resulting combinations as problem specifications with which to query ITN. It sends the task DOM to the ITN wrapper. The task DOM contains the user input data and leaves the output elements to be filled. The ITN wrapper maps the task DOM in the parameters of the ITN method, and when it receives the method’s response, it extracts from it the data of interest and to translate it in XML. The wrapper finally returns the task DOM to the mediator. After the entire task is accomplished, i.e. the DOM has been updated by all the relevant wrappers, the mediation layer sends the result DOM back to the interface layer.

For exploratory search tasks, the result DOM is essentially a table of possible solutions to the user’s input problem. To enable the user to better inspect the result, we have developed an XSL stylesheet that enables the user to sort and view the result in different ways. Thus, in our particular scenario, a table of the found tickets is presented to the user, who can sort it according to different ticket attributes. For example, the user may decide to see tickets in increasing price order and to select the first one, i.e., the cheapest. Or alternatively, the user may order the tickets according to departure dates and select some ticket toward the middle of July. Finally, the user might choose to completely abandon “California” as a destination and go to “Vancouver Island” instead, in which case the mediator will repeat the search process from the start.

4

Reflections and Conclusions

Let us now reflect upon the generality/extensibility of this approach and the cost involved in its adoption in novel application domains. Our travel-planning assistant currently “talks” with only two wrappers and offers limited solution post-processing , i.e., inference of some derived flight attributes and flexible result sorting. Its extension with further capabilities would simply involve the editing of its task-structure XML document to include new tasks and the implementation of java methods for these tasks. The task-structure interpretation mechanism would not need to be modified. Similarly, additional wrappers could simply be integrated by additional entries in the registry table. What is involved, however, in developing a similar exploratory search mediator in another application domain? First the domain has to be modeled and the stylesheets of the new domain elements have to be developed. This is currently a manual process, but various business and technology sectors have embarked on the specification of standard XML schemas for exchanging information in their domains of interest. These efforts would potentially eliminate this task in the future, for domains that have been thus standardized. The search task structure would be mostly transferable with the exception of many of the domain-dependent post-processing subtasks. Some of the post-processing subtasks, such as sorting for example, are domain-independent and transferable. Finally, the sources would have to be wrapped. This is currently a manual process in our environment, but we are in the process of investigating related work [3, 11] on automating it. Finally, we want to close with a few concluding remarks. In this paper, we discussed an architecture for integration of WEB applications, based on a multi-agent system consisting of a mediator and a set of wrappers. The wrapper agents act as “representatives” of the functionalities that their underlying applications can deliver. The mediator’s internal process is defined in terms of a task structure. The mediator’s task structure drives the interaction with its users and its communication with its associated wrappers. In particular, we have developed a generic exploratory-search task structure that allows the user to specify the problem at an abstract level and does not force early commitments on the desired attributes of the output. Such search mediators can support the users in exploring large areas of the problem space, and enable them to make decisions based on the results collected from the exploration. This search task structure can be instantiated in different domains, as long as objects in these domains can take values in spaces

organized in an abstraction hierarchy. Both the mediator’s task structure and domain model are specified in XML. Thus task structures as well as domain models can be shared among mediators. In addition to their XML specification, the domain and task structure have also associated XSL stylesheets which specify the interaction (elements, presentation, layout and navigation) between the mediator and its users. The resulting interface is consistent and intuitive, since it directly corresponds to the task structure and the domain model.

Acknowledgments This work was supported by NSERC research grant NSERC-RGPIN 203221-98.

References 1. A. Sahuguet and F. Azavant: Looking at the Web through XML glasses by CoopIs’99, 1999. 2. B. Chandrasekaran: Task Structures, Knowledge Acquisition and Machine Learning. Machine Learning 4:341-347, 1989. 3. C.A. Knoblock et al.: Modeling Web Sources for Information Integration. In the Proceedings of the Fifteenth National Conference on Artificial Intelligence, Madison, WI, 1998. 4. C. Baru et al.: XML-Based Information Mediation with MIX. In the exhibition program, ACM Conf. on Management of Data (SIGMOD’99), Philadelphia, USA, 1999. 5. E. Stroulia and A.K. Goel: A Model-Based Approach to Blame Assignment: Revising the Reasoning Steps of Problem Solvers. In the Proceedings of the Thirteenth Annual Conference on Artificial Intelligence, pp. 959-965, AAAI Press. 6. E. Stroulia and A.K. Goel: Redesigning a Problem Solver’s Operators to Improve Solution Quality. In the Proceedings of the Fifteenth International Joint Conference on Artificial Intelligence, 1997. pp 562-567. 7. FIPA 97 Draft Specification Part 4 Personal Travel Assistance by Foundation for Intelligent Physical Agents. 8. GMD-IPSI XQL Engine http://xml.darmstadt.gmd.de/xql/index.html 9. G. Wiederhold. Mediation in Information Systems. ACM Computing Surveys. 27(2):265-267, June 1995. 10. G. Wiederhold and Michael Genesereth: The Conceptual Basis for Mediation Services; IEEE Expert, 1997. 11. I. Muslea, S. Minton and C. Knoblock: A Hierarchical Approach to Wrapper Induction. In the Proceedings of the Third Conference on Autonomous Agents, Seattle, WA, 1999. 12. N. Kushmerick: Wrapper Induction for Information Extraction. PhD Dissertation, University of Washington, 1997. 13. R. Elio and A. Haddadi: Abstract Task Models and Conversation Policies. In the Proceedings of the Autonomous Agents ’99 Workshop, 1999. 14. S. Heiler: Semantic Interoperability. ACM Computing Surveys. 27(2):271-273, June 1995. 15. W3 Consortium, XML http://www.w3c.org/xml 16. Y. Labrou and T. Finin: A Proposal for a new KQML Specification TR CS-97-03, February 1997, Computer Science and Electrical Engineering Department, University of Maryland Baltimore County, Baltimore, MD 21250. This article was processed using the LATEX macro package with LLNCS style