Professional Documents
Culture Documents
Designing New Ways For Selling Airline Tickets.: March 2007
Designing New Ways For Selling Airline Tickets.: March 2007
net/publication/220166598
CITATIONS READS
6 277
5 authors, including:
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Maria Ganzha on 22 May 2014.
Michał Szymczak
Department of Mathematics and Computer Science
Adam Mickiewicz University
Umultowska 87, 61-614 Poznań, 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 Elbląg, 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
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 travel-
content. 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 večagentni system za prodajo letalskih kart.
“decides” to make a purchase of product P to the Agent (FOA) and a Reservation Agent were created to
successful purchase (or to a decision that such a purchase interact with Global Distribution Systems (GDS), e.g.
is impossible – e.g. due to the market conditions). The AMADEUS or SABRE [1, 33] and facilitate delivery of
second project is an agent-based Travel Support System all necessary air-travel related information.
(TSS) [13, 39, 40]. In the TSS, travelers are to find In the next step we have considered how this augmented
complete support of their needs including, among others, system could be integrated with the TSS. Since in the
items like restaurant information, historical points of TSS travel data is stored as instances of travel ontologies
interest, local weather etc. The central part of the TSS is (currently hotel and restaurant data), air travel related
a Jena-based repository [20, 21] that contains travel- data should be also stored in the same way. Furthermore,
related data is represented as RDF demarcated instances air travel ontology that is to be used within the system
of a travel ontology [13]. Specifically, we have should be tightly integrated with ontologies already
developed a complete ontology of a hotel (understood as existing in the system. After a thorough analysis of
a travel-related entity) and a restaurant; and then merged existing air-travel ontologies we have decided to develop
them [35]. The overarching goal of the design of the TSS our own [40].
was delivery of personalized information to users [13]. The aim of this paper is to summarize our research
More recently we have asked, what would happen if our results up to date. In the next section we present the
model e-commerce system had to be used in a more augmented ticket auctioning system. We follow (in
realistic scenario, where instead of an unspecified Sections 3 and 4) with a list of existing travel-related
product P, airline tickets were to be sold and the system ontologies and a summary of the Open Travel Alliance
would have to interact with an actual airline reservation (OTA) messaging system. OTA messages are then used
system. As a result we have proposed an augmented as a starting point to design an air travel ontology, which
system in which two additional agents: a FlightOffer is outlined in the next section.
could be possible to allow the CIC Agent to study market for each route that is to be offered, she specifies:
trends and sell this information to interested travel departure airport code, destination airport code, booking
agencies. (3) In all situations where it was possible we class, fare basis code, and the initial rule by which seats
utilize existing structures that have been described in [2– are to be offered for sale. For example, if User-Merchant
5, 10] and interested readers should consult these sources wants to sell out seats that would have been offered for
for further details. Advanced Purchase Excursion Fare—APEX [18, 19] but
Let us represent design of the system through its UML time limit for this fare has expired, User-Merchant would
use case diagram in Figure 1 (detailed descriptions of the specify the number and the period for which she wants to
system can be found in [39]). We can distinguish three offer seats on specific flights. This info would be used in
major parts of the system. (1) The Information center availability check and price retrieval. The time-period
area where white-page and yellow-page information is would be needed to set bounds within which flights
stored and serviced by the CIC Agent. As specified should be offered. Optionally User-Merchant can specify
above, currently, User-Merchants request that their e- flight number as well. This narrows down the availability
stores sell tickets only for specific routes that they list and may be necessary in the case when there is more
believe to be profitable. Each such route is advertised then one flight per day between two given destinations.
through the CIC. Every time the Client Agent is Furthermore this can be used also in the case when, for
searching for an airline ticket for its User-Client it instance, user-merchant wants to offer seats on morning
communicates with the CIC to find out which e-travel flights, but not on evening flights. In this case she can
agencies sell it. (2) The Purchasing side where agents specify which flight number(s) can be chosen from. In
and activities representing the User-Client are this way, all other possible flight numbers are excluded.
represented. Here the User-Client informs its Client Obviously, it is possible to extend functionality of our
Agent which tickets she would like to purchase. While system. For instance, while at present our system acts
the Client Agent should be viewed as an incarnation of a only as a “distributor” of a predefined set of tickets, it is
Personal Agent [24] that knows preferences of its User- possible to modify it in such a way that the SA could start
Client and autonomously acts on her behalf, their exact distributing (acquire and put for auction) also tickets for
interrelations will be established in the future. Client routes that User-Clients are looking for. Since the CIC
Agent obtains from the CIC information which e-travel agent stores information about all unfulfilled User-Client
agencies sell requested tickets and sends a Buyer Agent queries, an SA could be enabled to obtain an access to
to each one of them. Buyer Agents engage in price this data (e.g. purchase it), analyze it and decide that, for
negotiations with Seller Agents. Successful price instance, there is a growing need for tickets between
negotiations results in a reservation. Client Agent decides Podgorica and Beijing and offer these for sale.
which agency to make a purchase from and, if the Statechart diagram of the Shop agent is depicted in
reservation did not expire and the tickets are still Figure 2. At first the SA creates the Gatekeeper Agent
available in the GDS, they are purchased. (3) The Seller (which plays here exactly the same role as described in
side involves Shop Agent acting on behalf of its User- [6]) and waits for a User-Merchant order. After receiving
Merchant and attempting at selling air tickets for routes such an order the SA creates FlightOffer Agent, which
defined by her. It interacts with the FlightOffer Agent in communicates with the GDS and gathers needed
creating a list of specific offers that are registered with information to create list of offers for the Shop Agent
the CIC. Upon successful price negotiation the (one FlightOffer Agent is created for each route to be
Reservation Agent creates and manages a reservation serviced and exists for as long as tickets for a given route
and, if this is to be the case, is responsible for completing are sold by the SA). List of offers includes information
the purchase. Observe that both the FlightOffer Agent about every itinerary: data about both (inbound and
and the Reservation Agent interact directly with the GDS. outbound) flight numbers, number of seats and class of
In this way they act as “wrapper agents” translating data service for both flights etc. Shop Agent creates also Seller
between the outside world (the GDS) and the system. Let Agent(s), “introduces” them to the Gatekeeper, and
us now describe in more details the roles of these agents enters a complex state called Selling. Note here that
that have been added, or that act differently than in the Seller Agents play exactly the same role as that described
original e-commerce system. in [6]; they are to interact with incoming Buyer Agents
and through some form of price negotiation mechanism
2.1 Shop Agent (e.g. an auction) select the Buyer that may purchase the
ticket. In the Selling state the SA is listening to its Seller
Shop Agent (SA) acts as the representative of the User-
Agent(s). After receiving a message from one of the
Merchant and, at the same, time participates in the
Seller Agents – informing about the result of price
Selling function of the system. As specified above, in our
negotiations – the Shop Agent acts depending on content
current system design, it is the User-Merchant who
of that message.
specifies the input provided to the system. Specifically,
96 Informatica 31 (2007) 93–104 M. Vukmirovič et al.
1. If the Seller informs the SA about a winner of price about processes that take place within the shop when it is
negotiations the Shop Agent waits for the corresponding attempting to sell tickets is recorded in the Knowledge
Buyer Agent to confirm that it plans to actually buy the Database. In the future, this information will be used by
ticket (see also [10] for more details). Here, we have to the SA to adapt its behavior. Currently we denote this fact
stress, that in our general e-commerce model it is natural by introducing the Decision Making box, which denotes
that multiple Buyer Agents visit multiple e-stores [10]. multi-criterial decision making. For instance, one of
Specifically, separate Buyer visits each e-travel agency important factors that influences the way that the SA
that offers ticket(s) satisfying needed itinerary. The end interacts with incoming BAs is trust (see for instance [7,
of price negotiation means that the Buyer should consult 28]). It should also be mentioned that in our system we
with the Client Agent. Therefore, the SA does not know if utilize a modified negotiation framework [3, 4, 6]
the winner of price negotiations will actually attempt at introduced originally by Bartollini, Jennings and Preist
making a purchase. [8, 9]. In this framework, the negotiation process was
2. If the Buyer Agent confirms it wants to buy a ticket, divided into a generic negotiation protocol and a
the Shop Agent creates a Reservation Agent (RA), which negotiation template that contains parameters of a given
communicates with the GDS to make a reservation. negotiation. These parameters specify, among others, the
There are then the following possibilities: price negotiation mechanism itself. Observe, in Figure 2,
– If the RA was able to reserve tickets (it is that one of possible results of Decision Making is change
possible that while the negotiations were taking of the negotiation template. In other words, the SA may
place all tickets available in a given class of service decide that since only very few tickets are left but there is
etc. are already gone), it sends the reservation data to also only very short time to sell them, it will deeply
the Shop Agent. Upon reception of the data (all discount them and sell them with a fixed price, or
communication in the system is carried using ACL through a very short time lasting English auction with a
messages) the Shop Agent transfers it further to the low threshold value and a relatively large increment.
Buyer Agent and carries out standard procedures 4. If there is no winner, the Shop Agent writes
involved in completing the sale (Figure 1, state “Sale information into the Knowledge Database and starts to
finalization”). analyze the current situation (the Decision Making box in
– In the opposite case (the RA was not able to Figure 2). As a result it may change the negotiation
secure the reservation) the Shop Agent notifies the template, or request another itinerary from the
Buyer Agent that reservation is impossible and kills FlightOffer Agent. Finally, it may establish that for that
the Reservation Agent. given route (User-Merchant order) either there is nothing
3. If the Buyer Agent sends message that it does not want more to do (all tickets have been sold) or that nothing can
to make a purchase, this fact is registered in a local be done (the remaining tickets cannot be sold in the
Knowledge Database. More precisely, all information 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- Knowledge Database, kills this Seller and notifies its
Merchant about the situation. It is important to note that user-merchant accordingly. Following, the SA enters the
we assume that in all price negotiation mechanisms the Multi-criterial Decision Making state. As described
Seller institutes a time limit for negotiations. This above, here it can decide, among others, to sell more
moment is presented within the Shop Agent diagram as a seats on some specific itinerary or to change the template
sub-state “Counting time” (within the Selling state). If of negotiations or to conclude that nothing more can be
the Seller does not sell any tickets within that time the sold and its existence should be completed.
Shop Agent, again, registers this information in the
fashion. Furthermore, we envision the augmented portal [11]. For instance, the Itinerary-ont is an
e-commerce system as comprising a number of e- ontology for representing travel itineraries. It reuses
travel agencies that utilize methods developed there to the airport codes ontology and involves definitions of
sell airline tickets for selected routes. In this case we terms like Aircraft, Class, Flight etc. Another example
have to deal with the following situation. Data stored is the Trip Report Ontology that defines Airfare,
in and provided by the GDS is not ontologically Amount, Date, etc., and models on-line sale.
demarcated. Hotel and restaurant information stored in The complete list of pros and cons for ontologies
the travel agency is ontologically demarcated. listed above may be found in [40]. There, we report
Therefore, to be able to combine these two systems results of our in-depth analysis of the possibility to
one has to provide travel agencies in the e-commerce utilize any of them in airline ticket sales. Overall, none
system with: (1) air-travel ontology, that should be of them had a fully developed air travel part and that
integrated with the two already developed ontologies, could also interface with an actual GDS, and therefore
and (2) way of translating data provided by the GDS we had to develop our own, based on the Open Travel
into an appropriate form for the travel agency and the Alliance messaging system.
GDS to “understand” each-other. In the remaining
parts of this paper we address the first issue, while in 4 OTA and OTA Air Messages
the concluding remarks we sketch our proposed
solution of the second one. The Open Travel Alliance (OTA) is a non-profit
organization working to establish a common
3 General and travel ontologies electronic vocabulary for exchange of travel
information. Such an exchange is to take form of
As the first step in the direction of being able to utilize standardized eXtensible Markup Language (XML)
an air travel ontology, we have researched the existing messages. OTA specifications have been designed to
available ontologies. serve: (a) as a common language for travel-related
While the largest general ontology building terminology, and (b) as a mechanism for exchange of
projects, such as (1) the Cyc project [31], (2) WordNet information between travel industry members [14].
[41], (3) Suggested Upper Merged Ontology (SUMO) The OTA Air Messages standard, which is of
[36], and (4) SENSUS [34] do not provide us with an particular interest in our work, specifies structure and
“ontology of travel,” there exist a number of smaller elements of different scenarios involved in selling air
scale attempts at defining such an ontology. (1) travel tickets. Let us note that since this is a
Mondeca´s [30] tourism ontology defines tourism specification of messaging, it does not cover any
concepts based on the WTO thesaurus. (2) The Travel other operations involved in selling air-tickets (e.g.
Agent Game in Agentcities (TAGA) is an agent airfare calculations). These operations have to be
framework for simulating the global travel market on treated separately. OTA messages have been
the Web. Its purpose is to demonstrate Agentcities and proposed as pairs of request and response messages
Semantic Web technologies [37]. In addition to the (RQ / RS below). Let us summarize their main
FIPA content language ontology, TAGA defines (a) features (their complete description can be found in
basic travel concepts such as itineraries, customers, [32]).
travel services, and service reservations, and (b) OTA_AirAvailRQ/RS – establishes airline flight
different types of auctions, roles participants play in availability for a city pair, specific date, specific
them, and protocols used. (3) Harmonize is an attempt number and type of passengers. The request can also
at ontology-mediated integration of tourism systems be narrowed to a specific airline, flight or booking
following different standards [15]. Its goal is to allow class. Optional requested information can include:
organizations to exchange information without time / time window, connecting cities, client
changing data structures. The Harmonize project also preferences (airlines, cabin, flight types etc.). The
involves sub-domains that are only partially related to response message (RS) contains flight availability.
the world of travel: geographical and geo-spatial Furthermore, a set of origin and destination options is
concepts, means of transportation, political, temporal, returned, each of which contains one or more
activity/interest, gastronomy etc. These sub-domain (connecting) flights that serve that city pair. For each
concepts can be used within the travel system flight information about: origin and destination
(directly, as needed) or incorporated into the ontology airports, departure and arrival date/times, booking
constructed for the system. It is claimed that the next class availability, equipment, meal information and
generation of “eTourism” will be powered by the code-share information is returned.
Semantic Web technology (resulting in an eTourism OTA_AirBookRQ/RS – requests to book a specific
Semantic Web portal which will connect the itinerary for one or more identified passengers. The
customers and virtual travel agents from anywhere at message contains optional pricing information,
anytime). Goes with out saying that this is a very allowing the booking class availability and pricing to
interesting project, however, airline ticket sales are not be rechecked as part of the booking process. Optional
included in the current version of Harmonize requested information can include: seat and meal
ontology. (4) Finally, a number of “minimalist” travel requests, Special Service Requests (SSR), Other
ontologies can be found within the DAML language Service Information (OSI), remarks, fulfillment
DESIGNING NEW WAYS FOR SELLING... Informatica 31 (2007) 93–104 99
information – payment, delivery details, type of ticket availability / price series of entries for an airline CRS
desired. If booking is successful, the RS message or GDS. The RS contains a Priced Itinerary that
contains the itinerary (including the directional includes: set of flights, pricing information including
indicator, status of booking, and number of taxes and full fare breakdown for each passenger
passengers), passenger and pricing information sent type, ticketing information, fare basis codes and the
in the request, along with a booking reference number information necessary to make a fare rules entry.
(PNR Locator) and the ticketing information. The RS OTA_AirRulesRQ/RS – requests text rules for a
echoes back received information with additional specific fare basis code for an airline and a city pair
information – booking reference from the GDS for a specific date. Negotiated fare contract codes can
through which reservation was created. be included in the request. The RS contains a set of,
OTA_AirFareDisplayRQ/RS – allows a client to human readable, rules, identified by their codes.
request information on fares, which exist between a OTA_AirSchedulesRQ/RS – provides customer, or a
city pair for a particular date or date range. No third party, with ability to view flight schedules. It
inventory check for available seats on flights is requires specification of the departure and arrival
performed by the server before the RS is send back. cities and a specific date. It offers flight information
The request can optionally contain information on airlines that provide service between requested
indicating that a more specific response cities and could be used when customer: (1) wants to
(e.g. passenger information, specific flight determine what airlines offer service to/from specific
information and information on the types of fares that destinations, (2) is looking for a specific flight
the client is interested in) is required. The RS number – by entering the arrival and departure cities,
message repeats FareDisplayInfo elements, each of and the approximate arrival or departure time,
which contains information on a specific fare contract specific flight number can be found, (3) needs to
including airline, travel dates, restrictions and pricing. determine the days of the week that service is
It can also return information on other types of fares scheduled to and from requested destinations, (4)
that exist, but have not been included in the response. wants to determine aircraft type used to fly that route.
OTA_AirFlifoRQ/RS – requests updated information Message may request other information that
on the operation of a specific flight (it requires the customers are interested in: meal service, duration of
airline, flight number and departure date; the flight, on-time statistics and if smoking is allowed. In
departure and arrival airport locations can be also be addition, these messages provide foundation for
included). The RS includes real-time flight departure electronic timetables.
and arrival information. It also includes: departure OTA_AirSeatMapRQ/RS – displays seats available
airport, arrival airport, marketing and operating on a given flight, as well as their location within the
airline names; when applicable, flight number, type aircraft. It is used o make seat assignments as it
of equipment, status of current operation, reason for identifies all information necessary to request and
delay or cancellation, airport location for diversion of return an available seat map for a particular flight.
flight, current departure and arrival date and time, Types of information for the seat map request
scheduled departure and arrival date and time, include: airline, flight number, date of travel, class of
duration of flight, flight mileage, baggage claim service and frequent flier status. The RS includes:
location. flight, aircraft and seat description information.
OTA_AirLowFareSearchRQ/RS – requests priced OTA_AirBookModifyRQ/OTA_AirBookRS –
itinerary options for flights between specific city requests to modify an existing booking file. It
pairs on certain dates for a specific number and types contains all elements of the OTA_AirBookRQ plus a
of passengers. Optional requested information can general type of modification, i.e. name change, split,
include: time / time window, connection points, client cancel or other; as indicated with the attribute
preferences (airlines, cabin, flight types etc.), flight ModificationType. The modification operation on
type (nonstop or direct), number of itinerary options different elements is either indicated with the existing
desired. The RS contains a number of Priced attribute Status (for air segments, SSR’s and seat
Itinerary options. Each includes: a set of available requests) or with attribute Operation of type
flights matching the client’s request, pricing ActionType for other elements (i.e. other service
information including taxes and full fare breakdown information, remarks or AirTraveler elements). In the
for each passenger type, ticketing information – ticket AirBookModifyRQ, all data to be changed is
advisory information and ticketing time limits, fare submitted and in the AirReservation element all
basis codes and the information necessary to make a existing data may be submitted. This allows the
rules entry. receiving system to perform a consistency check
OTA_AirPriceRQ/RS – requests pricing information before updating the booking file (but to keep the
for specific flights on certain dates for a specific message small, this part can be omitted). Changes to
number and type of passengers. The message allows a booking (1) may result in required updates of the
for optional information such as fare restriction ticket (e.g. revalidation), (2) may imply charges for
preferences and negotiated fare contract codes to be the change, (3) the pricing may change, and/or (4)
included. The pricing request contains information some fees may need to be collected. Pricing and
necessary to perform an availability / sell from fulfillment details required to achieve results of
100 Informatica 31 (2007) 93–104 M. Vukmirovič et al.
Let us stress that since the OTA was defined as a should be merged with an agent-based Travel Support
messaging system used for information exchange, while System that we are also developing. To achieve this goal
the proposed ontology was created with intention to it was necessary to develop ontology of air travel. Based
describe persistent data in our system, therefore quite on our analysis of existing travel ontologies we have
often more then one class from our ontology has to be decided to develop our own ontology that is based on
used in association with a single OTA message. As IATA manuals and OTA messaging system. As a result,
request (RQ) messages contains only data used to make a in this paper we have illustrated how an ontology can be
query, let us illustrate how the RS message matches with extracted from OTA messages. Overall, when completed
the proposed ontology in the case of the (currently, the proposed merged travel ontology it is
OTA_FareDisplaylRS. In our ontology an equivalent available for comments at: http://agentlab.swps.edu.pl)
class is Tariff. In Table 1 we depict how elements of the our (air) travel ontology should be capable of being used
message match elements of our ontology. Furthermore, to interface our Travel Support System with an actual
Figure 5 shows relations of the Tariff class with other GDS (which is one of important goals of our project).
classes (Airline, Airport, IATAFareBasis, StayLength, Let us note that there exist already GDS’s that allow
BookingClass) from our ontology. communication using OTA messaging. Leading this
Finally, one of the major advantages of utilizing the development, AMADEUS in its newly created platform
ontology technologies to demarcate electronic data is that called ‘Results CMS’ aimed at lowering cost of
it provides us with a highly readable, customizable and operations and offered OTA messaging as a way to
scalable knowledge (data) model. This allows us, among distribute airline inventory to external travel sites and
others, to swiftly browse the travel related content, based dynamic package providers. Therefore, as the next step
on the ontology concept references. Figure 6 presents of our research, we plan to develop two parsers. Let us
such references between Hotel, Airport, Restaurant, assume that a query that is related to air-travel has been
OutdoorLocation, Currency and Person concepts. formulated in our system. Obviously, this will be a
Obviously, the TSS ontology and its air-ticketing- SPARQL query (as SPARQL is our language of choice
dedicated extension contain far larger number of inter- to query ontologically demarcated content stored in Jena
concept references; however, presenting them within a repository). This query will then be translated into an
single figure would greatly limit its readability. OTA message and submitted to the GDS. Such a
translation will be based on our air-travel ontology. As a
6 Concluding remarks response, the GDS will send an OTA response message,
containing requested information. This message will be
In this paper we have summarized results obtained thus then parsed and information translated into instances of
far in our attempt in developing an agent-based airline our air-travel ontology. We will then use our display
ticket selling system. We have started from presenting an system [25] to present them to the user. We will report
augmented version of a model agent-based e-commerce on our progress in subsequent publications.
system and followed with a suggestion that such a system
DESIGNING NEW WAYS FOR SELLING... Informatica 31 (2007) 93–104 103
[16] IATA Airline Coding Directory – Airline [38] Trastour, D., Bartolini, C., Preist, C.: Semantic Web
Designators, 70th Edition Support for the Business-to-Business E-Commerce
[17] IATA City Code Directory, 43rd Edition, Effective 9 Lifecycle. In: Proceedings of the WWW’02:
December 2005 – 31 December 2006 International World Wide Web Conference, Hawaii,
[18] IATA Passenger Services Conference Resolutions USA. ACM Press, New York, USA, pp.89-98, 2002.
Manual, 24th Edition, Effective 1 June 2005 – 31 [39] Vukmirović M., Ganzha M., Paprzycki M.:
May 2006 Developing a Model Agent-based Airline Ticket
[19] IATA Passenger Tariff Coordination Conferences Auctioning System. In: Proceedings for the IIPWM
Manual, Composite, Dec 9, 2005 until Dec 31, 2006 Conference, LNAI
[20] IATA Reservation Service Manual, 23rd Edition [40] Vukmirović M., Szymczak M., Ganzha M.,
[21] IATA Standard Schedules Information Manual, Mar Paprzycki M.: Utilizing Ontologies in an Agent-
1, 2006 until Sep 30, 2006 based Airline Ticket Auctioning System. In:
[22] Jena 2 Ontology API – General concepts, Proceedings of the 28th ITI Conference, IEEE
http://jena.sourceforge.net/ontology/index.html#gen Computer Society Press, Cavtat, Dubrovnik, Croatia,
eralConcepts 385-390
[23] Jena Documentation, http://jena.sourceforge.net/ [41] WordNet, http://www.daml.org/ontologies/196
documentation.html [42] Wooldridge, M.: An Introduction to MultiAgent
[24] Kowalczyk, R., Ulieru, M., Unland, R.: Integrating Systems, John Wiley & Sons, 2002.
Mobile and Intelligent Agents in Advanced E-
commerce: A Survey. In: Agent Technologies,
Infrastructures, Tools, and Applications for E-
Services, Proceedings NODe’2002 Agent-Related
Workshops, Erfurt, Germany. LNAI 2592, Springer-
Verlag, pp.295-313, 2002.
[25] Maciej Gawinecki, Minor Gordon, Paweł
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 e-
commerce system. In: M. Bohanec et. al. (eds.),
Proceedings of the 2006 Information Society
Multiconference, Josef Stefan Institute Press, 22-26]
[29] Mladenka Vukmirović, Marcin Paprzycki, Michał
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., Vukmirović 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