Informatica 31 (2007) 93-104 93 Designing New Ways for Selling Airline Tickets Mladenka Vukmirovic Industry Development Department, Montenegro Airlines Beogradska 10, 81000 Podgorica, Montenegro Michal Szymczak Department of Mathematics and Computer Science Adam Mickiewicz University Umultowska 87, 61-614 Poznan, Poland Maciej Gawinecki Systems Research Institute, Polish Academy of Science Newelska 6, 01-447 Warsaw, Poland Maria Ganzha, Elblag University of Humanities and Economics, Elbl^g, Poland ul. Lotnicza 2, 82-300 Elblqg, Poland and Systems Research Institute, Polish Academy of Science Newelska 6, 01-447 Warsaw, Poland Marcin Paprzycki Computer Science Institute, SWPS Chodakowska 19/31, 03-815 Warsaw, Poland and Systems Research Institute, Polish Academy of Science Newelska 6, 01-447 Warsaw, Poland Keywords: software agents, air-travel ontology, travel support system, e-commerce, e-auctions, OTA, IATA Received: October 12, 2006 Large body of recent work has been devoted to multi-agent systems utilized in e-commerce; in particular, autonomous software agents participating in auctions. In this context we modify a model agent-based e-commerce system so that it can serve as an airline ticket auctioning system. Such a system can be then combined with a Travel Support System that utilizes ontologically demarcated travelcontent. To achieve this goal, air travel data has to be demarcated utilizing an air travel ontology that has to support existing domain-specific real-world standards. One of such standards that steadily gains popularity in the air travel industry (and other travel areas) is the Open Travel Alliance (OTA) messaging system that defines, among others, the way that entities should communicate about air travel related issues. The aim of this paper is to outline our efforts leading toward creating an agent-based system for selling airline tickets that utilizes an air-travel ontology that matches the OTA messaging specification as well as satisfies procedures described in IATA manuals. Povzetek: Opisan je vecagentni system za prodajo letalskih kart. 1 Introduction Broadly understood e-commerce is often closely associated with software agents, which are to facilitate higher quality information, personalized recommendations, decision support, knowledge discovery etc. [27]. When developed and implemented, agent systems are to be, among others, adaptive, proactive and accessible from a broad variety of devices [42]; and as such are to deal autonomously with information overload (e.g. large number of e-shops offering the same product under slightly different conditions—price, delivery conditions, warranty etc.). Moreover, recent advances in auction theory have produced a general methodology for describing price negotiations [8, 9]. Combination of these factors gave new impetus to research on automating e-commerce [24]. In this context, we have started working on two independent research projects. The first one is devoted to the development of a model agent-based e-commerce system [2-5, 12 and references to our work cited in these papers]. In this system, we model a distributed marketplace where buyer agents approach e-stores and engage in price negotiations with seller agents. What makes our work unique is, among others, an attempt at conceptualizing not only price negotiations, but also a complete process from the moment when User-Cuyer 94 Informatica 31 (2007) 93-104 M. Vukmirovič et al. "decides" to make a purchase of product P to the successful purchase (or to a decision that such a purchase is impossible - e.g. due to the market conditions). The second project is an agent-based Travel Support System (TSS) [13, 39, 40]. In the TSS, travelers are to find complete support of their needs including, among others, items like restaurant information, historical points of interest, local weather etc. The central part of the TSS is a Jena-based repository [20, 21] that contains travel-related data is represented as RDF demarcated instances of a travel ontology [13]. Specifically, we have developed a complete ontology of a hotel (understood as a travel-related entity) and a restaurant; and then merged them [35]. The overarching goal of the design of the TSS was delivery of personalized information to users [13]. More recently we have asked, what would happen if our model e-commerce system had to be used in a more realistic scenario, where instead of an unspecified product P, airline tickets were to be sold and the system would have to interact with an actual airline reservation system. As a result we have proposed an augmented system in which two additional agents: a FlightOffer Agent (FOA) and a Reservation Agent were created to interact with Global Distribution Systems (GDS), e.g. AMADEUS or SABRE [1, 33] and facilitate delivery of all necessary air-travel related information. In the next step we have considered how this augmented system could be integrated with the TSS. Since in the TSS travel data is stored as instances of travel ontologies (currently hotel and restaurant data), air travel related data should be also stored in the same way. Furthermore, air travel ontology that is to be used within the system should be tightly integrated with ontologies already existing in the system. After a thorough analysis of existing air-travel ontologies we have decided to develop our own [40]. The aim of this paper is to summarize our research results up to date. In the next section we present the augmented ticket auctioning system. We follow (in Sections 3 and 4) with a list of existing travel-related ontologies and a summary of the Open Travel Alliance (OTA) messaging system. OTA messages are then used as a starting point to design an air travel ontology, which is outlined in the next section. Figure 1: Airline ticket auctioning system - use case diagram. 2 Airline ticket auction system Before proceeding with the description of the system, let us point some of the assumptions made in our work. (1) In our original agent-based e-commerce system e-stores were "drivers" within the marketplace. In other words, buyers could purchase only products that were available for sale through existing e-stores. We have decided, in the initial phase of our work on airline ticket selling system, to accept this approach (while planning to remove this limitation in the future). Therefore, in the augmented system, multiple "travel agencies" sell tickets to a variety of "popular destinations." They obey basic rules of airline ticket trading, but it is only "them" who decides which tickets to sell. Specifically, if the user of the system would like to fly from Tulsa, OK to San Diego, CA, she may not find such a connection. At the same time, connections between Amsterdam and Detroit, MI may be sold by every e-store. While this assumption may seem limiting, we would like to point out that success of priceline.com (and other auction places that sell airline tickets) makes our model scenario "realistic enough." (2) While we are utilizing the CIC Agent that stores "yellow-pages" (what?) and "white-pages" (who?) information as the approach to matchmaking [38], we see possible interesting extensions of its role in the system. It DESIGNING NEW WAYS FOR SELLING. Informatica 31 (2007) 93-104 95 could be possible to allow the CIC Agent to study market trends and sell this information to interested travel agencies. (3) In all situations where it was possible we utilize existing structures that have been described in [25, 10] and interested readers should consult these sources for further details. Let us represent design of the system through its UML use case diagram in Figure 1 (detailed descriptions of the system can be found in [39]). We can distinguish three major parts of the system. (1) The Information center area where white-page and yellow-page information is stored and serviced by the CIC Agent. As specified above, currently, User-Merchants request that their e-stores sell tickets only for specific routes that they believe to be profitable. Each such route is advertised through the CIC. Every time the Client Agent is searching for an airline ticket for its User-Client it communicates with the CIC to find out which e-travel agencies sell it. (2) The Purchasing side where agents and activities representing the User-Client are represented. Here the User-Client informs its Client Agent which tickets she would like to purchase. While the Client Agent should be viewed as an incarnation of a Personal Agent [24] that knows preferences of its UserClient and autonomously acts on her behalf, their exact interrelations will be established in the future. Client Agent obtains from the CIC information which e-travel agencies sell requested tickets and sends a Buyer Agent to each one of them. Buyer Agents engage in price negotiations with Seller Agents. Successful price negotiations results in a reservation. Client Agent decides which agency to make a purchase from and, if the reservation did not expire and the tickets are still available in the GDS, they are purchased. (3) The Seller side involves Shop Agent acting on behalf of its User-Merchant and attempting at selling air tickets for routes defined by her. It interacts with the FlightOffer Agent in creating a list of specific offers that are registered with the CIC. Upon successful price negotiation the Reservation Agent creates and manages a reservation and, if this is to be the case, is responsible for completing the purchase. Observe that both the FlightOffer Agent and the Reservation Agent interact directly with the GDS. In this way they act as "wrapper agents" translating data between the outside world (the GDS) and the system. Let us now describe in more details the roles of these agents that have been added, or that act differently than in the original e-commerce system. 2.1 Shop Agent Shop Agent (SA) acts as the representative of the User-Merchant and, at the same, time participates in the Selling function of the system. As specified above, in our current system design, it is the User-Merchant who specifies the input provided to the system. Specifically, for each route that is to be offered, she specifies: departure airport code, destination airport code, booking class, fare basis code, and the initial rule by which seats are to be offered for sale. For example, if User-Merchant wants to sell out seats that would have been offered for Advanced Purchase Excursion Fare—APEX [18, 19] but time limit for this fare has expired, User-Merchant would specify the number and the period for which she wants to offer seats on specific flights. This info would be used in availability check and price retrieval. The time-period would be needed to set bounds within which flights should be offered. Optionally User-Merchant can specify flight number as well. This narrows down the availability list and may be necessary in the case when there is more then one flight per day between two given destinations. Furthermore this can be used also in the case when, for instance, user-merchant wants to offer seats on morning flights, but not on evening flights. In this case she can specify which flight number(s) can be chosen from. In this way, all other possible flight numbers are excluded. Obviously, it is possible to extend functionality of our system. For instance, while at present our system acts only as a "distributor" of a predefined set of tickets, it is possible to modify it in such a way that the SA could start distributing (acquire and put for auction) also tickets for routes that User-Clients are looking for. Since the CIC agent stores information about all unfulfilled User-Client queries, an SA could be enabled to obtain an access to this data (e.g. purchase it), analyze it and decide that, for instance, there is a growing need for tickets between Podgorica and Beijing and offer these for sale. Statechart diagram of the Shop agent is depicted in Figure 2. At first the SA creates the Gatekeeper Agent (which plays here exactly the same role as described in [6]) and waits for a User-Merchant order. After receiving such an order the SA creates FlightOffer Agent, which communicates with the GDS and gathers needed information to create list of offers for the Shop Agent (one FlightOffer Agent is created for each route to be serviced and exists for as long as tickets for a given route are sold by the SA). List of offers includes information about every itinerary: data about both (inbound and outbound) flight numbers, number of seats and class of service for both flights etc. Shop Agent creates also Seller Agent(s), "introduces" them to the Gatekeeper, and enters a complex state called Selling. Note here that Seller Agents play exactly the same role as that described in [6]; they are to interact with incoming Buyer Agents and through some form of price negotiation mechanism (e.g. an auction) select the Buyer that may purchase the ticket. In the Selling state the SA is listening to its Seller Agent(s). After receiving a message from one of the Seller Agents - informing about the result of price negotiations - the Shop Agent acts depending on content of that message. 96 Informatica 31 (2007) 93-104 M. Vukmirovič et al. Figure 2: Shop Agent statechart diagram. 1. If the Seller informs the SA about a winner of price negotiations the Shop Agent waits for the corresponding Buyer Agent to confirm that it plans to actually buy the ticket (see also [10] for more details). Here, we have to stress, that in our general e-commerce model it is natural that multiple Buyer Agents visit multiple e-stores [10]. Specifically, separate Buyer visits each e-travel agency that offers ticket(s) satisfying needed itinerary. The end of price negotiation means that the Buyer should consult with the Client Agent. Therefore, the SA does not know if the winner of price negotiations will actually attempt at making a purchase. 2. If the Buyer Agent confirms it wants to buy a ticket, the Shop Agent creates a Reservation Agent (RA), which communicates with the GDS to make a reservation. There are then the following possibilities: - If the RA was able to reserve tickets (it is possible that while the negotiations were taking place all tickets available in a given class of service etc. are already gone), it sends the reservation data to the Shop Agent. Upon reception of the data (all communication in the system is carried using ACL messages) the Shop Agent transfers it further to the Buyer Agent and carries out standard procedures involved in completing the sale (Figure 1, state "Sale finalization"). - In the opposite case (the RA was not able to secure the reservation) the Shop Agent notifies the Buyer Agent that reservation is impossible and kills the Reservation Agent. 3. If the Buyer Agent sends message that it does not want to make a purchase, this fact is registered in a local Knowledge Database. More precisely, all information about processes that take place within the shop when it is attempting to sell tickets is recorded in the Knowledge Database. In the future, this information will be used by the SA to adapt its behavior. Currently we denote this fact by introducing the Decision Making box, which denotes multi-criterial decision making. For instance, one of important factors that influences the way that the SA interacts with incoming BAs is trust (see for instance [7, 28]). It should also be mentioned that in our system we utilize a modified negotiation framework [3, 4, 6] introduced originally by Bartollini, Jennings and Preist [8, 9]. In this framework, the negotiation process was divided into a generic negotiation protocol and a negotiation template that contains parameters of a given negotiation. These parameters specify, among others, the price negotiation mechanism itself. Observe, in Figure 2, that one of possible results of Decision Making is change of the negotiation template. In other words, the SA may decide that since only very few tickets are left but there is also only very short time to sell them, it will deeply discount them and sell them with a fixed price, or through a very short time lasting English auction with a low threshold value and a relatively large increment. 4. If there is no winner, the Shop Agent writes information into the Knowledge Database and starts to analyze the current situation (the Decision Making box in Figure 2). As a result it may change the negotiation template, or request another itinerary from the FlightOffer Agent. Finally, it may establish that for that given route (User-Merchant order) either there is nothing more to do (all tickets have been sold) or that nothing can be done (the remaining tickets cannot be sold in the current condition of the market). Then it will remove all DESIGNING NEW WAYS FOR SELLING. Informatica 31 (2007) 93-104 97 "servant" agents servicing that route and inform its User-Merchant about the situation. It is important to note that we assume that in all price negotiation mechanisms the Seller institutes a time limit for negotiations. This moment is presented within the Shop Agent diagram as a sub-state "Counting time" (within the Selling state). If the Seller does not sell any tickets within that time the Shop Agent, again, registers this information in the Knowledge Database, kills this Seller and notifies its user-merchant accordingly. Following, the SA enters the Multi-criterial Decision Making state. As described above, here it can decide, among others, to sell more seats on some specific itinerary or to change the template of negotiations or to conclude that nothing more can be sold and its existence should be completed. Waiting for an order i Connecting to host do } send identification wait for response response received 3 response not receive i login on GDS do / sign-in with credentials Count re-tries do /1+ + Waiting for response [t ~ - '/' I ■ y i' \\ numStay stayUnit Figure 5: Protégé display of Tariff class. Let us stress that since the OTA was defined as a messaging system used for information exchange, while the proposed ontology was created with intention to describe persistent data in our system, therefore quite often more then one class from our ontology has to be used in association with a single OTA message. As request (RQ) messages contains only data used to make a query, let us illustrate how the RS message matches with the proposed ontology in the case of the OTAFareDisplaylRS. In our ontology an equivalent class is Tariff. In Table 1 we depict how elements of the message match elements of our ontology. Furthermore, Figure 5 shows relations of the Tariff class with other classes (Airline, Airport, IATAFareBasis, StayLength, BookingClass) from our ontology. Finally, one of the major advantages of utilizing the ontology technologies to demarcate electronic data is that it provides us with a highly readable, customizable and scalable knowledge (data) model. This allows us, among others, to swiftly browse the travel related content, based on the ontology concept references. Figure 6 presents such references between Hotel, Airport, Restaurant, OutdoorLocation, Currency and Person concepts. Obviously, the TSS ontology and its air-ticketing-dedicated extension contain far larger number of interconcept references; however, presenting them within a single figure would greatly limit its readability. 6 Concluding remarks In this paper we have summarized results obtained thus far in our attempt in developing an agent-based airline ticket selling system. We have started from presenting an augmented version of a model agent-based e-commerce system and followed with a suggestion that such a system should be merged with an agent-based Travel Support System that we are also developing. To achieve this goal it was necessary to develop ontology of air travel. Based on our analysis of existing travel ontologies we have decided to develop our own ontology that is based on IATA manuals and OTA messaging system. As a result, in this paper we have illustrated how an ontology can be extracted from OTA messages. Overall, when completed (currently, the proposed merged travel ontology it is available for comments at: http://agentlab.swps.edu.pl) our (air) travel ontology should be capable of being used to interface our Travel Support System with an actual GDS (which is one of important goals of our project). Let us note that there exist already GDS's that allow communication using OTA messaging. Leading this development, AMADEUS in its newly created platform called 'Results CMS' aimed at lowering cost of operations and offered OTA messaging as a way to distribute airline inventory to external travel sites and dynamic package providers. Therefore, as the next step of our research, we plan to develop two parsers. Let us assume that a query that is related to air-travel has been formulated in our system. Obviously, this will be a SPARQL query (as SPARQL is our language of choice to query ontologically demarcated content stored in Jena repository). This query will then be translated into an OTA message and submitted to the GDS. Such a translation will be based on our air-travel ontology. As a response, the GDS will send an OTA response message, containing requested information. This message will be then parsed and information translated into instances of our air-travel ontology. We will then use our display system [25] to present them to the user. We will report on our progress in subsequent publications. DESIGNING NEW WAYS FOR SELLING. Informatica 31 (2007) 93-104 103 Figure 6: Ontology concept references Acknowledgement We want to thank Mr Zoran Djurisic, the President of Board of Directors of Montenegro Airlines for his support of this research. Work of Maria Ganzha, Maciej Gawinecki and Marcin Paprzycki was partially sponsored by the EU IRG grant - project E-CAP. References [1] AMADEUS, http://www.amadeus.com/ [2] Bädicä, C., Badita, A., Ganzha, M., Iordache, A., Paprzycki M.: Implementing Rule-based Mechanisms for Agent-based Price Negotiations. In: Proceedings of the SAC'2005 Conference (in press) [3] Bädicä, C., Ganzha, M., Paprzycki, M., Pirv"anescu, A.: Combining Rule-Based and Plug-in Components in Agents for Flexible Dynamic Negotiations. In: M. P"echou"cek, P. Petta, and L.Z. Varga (Eds.): Proceedings of CEEMAS'05, Budapest, Hungary. LNAI 3690, Springer-Verlag, pp.555-558, 2005. [4] Bädicä, C., Ganzha, M., Paprzycki, M., Pirvänescu, A.: Experimenting With a Multi-Agent E-Commerce Environment. In: V. Malyshkin (Ed.): Proceedings of PaCT'2005, Krasnoyarsk, Russia. LNCS 3606, Springer-Verlag, pp.393-402, 2005. [5] Bädicä, C., Bäditä, A., Ganzha, M., Paprzycki, M., Developing a Model Agent-based E-commerce System, in: Jie Lu et. al. (eds.) E-Service Intelligence - Methodologies, Technologies and Applications (to appear) [6] Bädicä C., Ganzha M., Paprzycki M., UML Models of Agents in a Multi-Agent Ecommerce System. In: Proceedings of the ICEBE 2005 Conference, IEEE Press, Los Alamitos, CA, 56-61 [7] Costin Bädicä, Maria Ganzha, Maciej Gawinecki, Pawel Kobzdej, Marcin Paprzycki (2006) Towards Trust Management in an Agent-based E-commerce System - Initial Considerations. In: A. Zgrzywa (ed.) Proceedings of the MISSI 2006 Conference, Wroclaw University of Technlogy Press, Wroclaw, Poland, 225-236 [8] Bartolini, C., Preist, C., Jennings, N.R.: Architecting for Reuse: A Software Framework forAutomated Negotiation. In: Proceedings of A0SE'2002: Int. Workshop on Agent-Oriented Software Engineering, Bologna, Italy, LNCS 2585, Springer Verlag, pp.88100, 2002. [9] Bartolini, C., Preist, C., Jennings, N.R.: A Software Framework for Automated Negotiation. In: Proceedings of SELMAS'2004. LNCS 3390, Springer-Verlag, pp.213-235, 2005. [10] Cambia Service, http://zurich.agentcities.whitestein. ch/Services/Cambia.html [11] DAML Ontologies, http://www.daml.org [12] Ganzha, M., Paprzycki, M., Pirvänescu, A., Bädicä, C, Abraham, A.: JADE-based Multi-Agent Ecommerce Environment: Initial Implementation, In: Analele Universitä.tii dinTimi,soara, Seria Matematicä-Informaticä, 2005 (to appear). [13] Gordon M., Paprzycki M., Designing Agent Based Travel Support System. In: Proceedings of the ISPDC 2005 conference, IEEE Computer Society Press, Los Alamitos, CA, 2005, 207-214 [14] http://www.opentravel.org/about.cfm [15] Harmonize, http://deri.at/research/projects/e-tourism 104 Informatica 31 (2007) 93-104 M. Vukmirovič et al. [16] I AT A Airline Coding Directory - Airline Designators, 70th Edition [17] IATA City Code Directory, 43rd Edition, Effective 9 December 2005 - 31 December 2006 [18] IATA Passenger Services Conference Resolutions Manual, 24th Edition, Effective 1 June 2005 - 31 May 2006 [19] IATA Passenger Tariff Coordination Conferences Manual, Composite, Dec 9, 2005 until Dec 31, 2006 [20] IATA Reservation Service Manual, 23rd Edition [21] IATA Standard Schedules Information Manual, Mar 1, 2006 until Sep 30, 2006 [22] Jena 2 Ontology API - General concepts, http://jena.sourceforge.net/ontology/index.html#gen eralConcepts [23] Jena Documentation, http://jena.sourceforge.net/ documentation.html [24] Kowalczyk, R., Ulieru, M., Unland, R.: Integrating Mobile and Intelligent Agents in Advanced Ecommerce: A Survey. In: Agent Technologies, Infrastructures, Tools, and Applications for E-Services, Proceedings N0De'2002 Agent-Related Workshops, Erfurt, Germany. LNAI 2592, SpringerVerlag, pp.295-313, 2002. [25] Maciej Gawinecki, Minor Gordon, Pawel Kaczmarek, Marcin Paprzycki (2003) The Problem of Agent-Client Communication on the Internet. Scalable Computing: Practice and Experience, 6(1), 2005, 111-123 [26] Maes P., Agents that Reduce Work and Information Overload. Communications of the ACM, 37, 7, 1994, 31-40 [27] Maes, P., Guttman, R.H.,Moukas, A.G.: Agents that Buy and Sell: Transforming Commerce as we Know It. In Communications of the ACM, Vol.42, No.3, pp.81-91, 1999. [28] Maria Ganzha, Maciej Gawinecki, Pawel Kobzdej, Marcin Paprzycki, Costin Bädicä (2006) Functionalizing trust in a model agent based ecommerce system. In: M. Bohanec et. al. (eds.), Proceedings of the 2006 Information Society Multiconference, Josef Stefan Institute Press, 22-26] [29] Mladenka Vukmirovic, Marcin Paprzycki, Michal Szymczak (2006) Designing ontology for the Open Travel Alliance Airline Messaging Specification, In: M. Bohanec et. al. (eds.), Proceedings of the 2006 Information Society Multiconference, Josef Stefan Institute Press, 101-105] [30] Mondeca, http://www.mondeca.com [31] OpenCyc, http://www.opencyc.org [32] OpenTravelTM Alliance, Message Users Guide. 2005B Version 1.0, 2 December 2005 [33] SABRE, http://www.sabre.com/ [34] SENSUS, http://www.isi.edu/natural-language/projects/ONTOLOGIES. html [35] Szymczak M., Gawinecki M., Vukmirovic M., Paprzycki M., Ontological reusability in state-of-the-art semantic languages, Proceedings of the XVIII Summer School of PIPS (to appear) [36] SUMO, http://www.ontologyportal.org [37] TAGA, http://www.agentcities.org [38] Trastour, D., Bartolini, C., Preist, C.: Semantic Web Support for the Business-to-Business E-Commerce Lifecycle. In: Proceedings of the WWW'02: International World Wide Web Conference, Hawaii, USA. ACM Press, New York, USA, pp.89-98, 2002. [39] Vukmirovic M., Ganzha M., Paprzycki M.: Developing a Model Agent-based Airline Ticket Auctioning System. In: Proceedings for the IIPWM Conference, LNAI [40] Vukmirovic M., Szymczak M., Ganzha M., Paprzycki M.: Utilizing Ontologies in an Agent-based Airline Ticket Auctioning System. In: Proceedings of the 28th ITI Conference, IEEE Computer Society Press, Cavtat, Dubrovnik, Croatia, 385-390 [41] WordNet, http://www.daml.org/ontologies/196 [42] Wooldridge, M.: An Introduction to MultiAgent Systems, John Wiley & Sons, 2002.