DEVELOPING OPEN TRAVEL

ALLIANCE-BASED ONTOLOGY OF GOLF

Agnieszka Cieslik

Dep. of Mathematics and Information Technology, Warsaw University of Technology, Warsaw, Poland

Maria Ganzha, Marcin Paprzycki

Systems Research Institute Polish Academy of Science, Warsaw, Poland

Keywords:

OTA, ontology, golf, agent-based system, travel support system.

Abstract:

For usage of ontologies to become more prevalent, not only new ontologies have to be created to represent

the world, but also ontological support for existing domain-speciﬁc real-world standards has to be provided.

One of such standards that gains popularity is the Open Travel Alliance (OTA) messaging system that deﬁnes,

among others, the way that entities should communicate about golf as a travel-related entity. The aim of this

paper is to outline our efforts leading toward creating an ontology of golf that would match the OTA messaging

speciﬁcation.

1 INTRODUCTION

Our current work is focused on developing an agent-

based system that provides comprehensivesupport for

needs of a traveler. To this effect we have been in-

volved in two related projects. First project is the de-

sign and implementation of a model agent-based e-

commerce system (see (B˘adic˘a et al., 2007b; B˘adic˘a

et al., 2007a), and references to our earlier work con-

tained there). This project is focused on utilization

of price negotiations in a comprehensive e-commerce

scenario, and was extended to facilitate possibility of

airline ticket auctioning (Vukmirovic et al., 2006c;

Vukmirovic et al., 2006a; Vukmirovic et al., 2006b;

Szymczak et al., ; Vukmirovic et al., 2007). Second,

we work on creation of an agent based Travel Support

System (TSS) (Salam and Stevens, 2006; Gawinecki

et al., 2005b; Gordon and Paprzycki, 2005). In the

TSS, travelers are going to ﬁnd, among others, per-

sonalized information about restaurants, hotels, his-

torical points of interest, local weather etc. The main

idea of the TSS is to utilize a central repository of se-

mantically demarcated travel data, and use it to fa-

cilitate personalized information provisioning (Gawi-

necki et al., 2005b; Gawinecki et al., 2005c).

These two projects (airline ticket auctioning sys-

tem and Travel Support System) were developed sep-

arately. It was only in (Vukmirovic et al., 2006c)

where we have looked into issues involved in their

possible merger. The key consideration was related

to the fact that ontologically demarcated data is the

central component of the TSS (Salam and Stevens,

2006; Gawinecki et al., 2005b; Gordon and Paprzy-

cki, 2005). Therefore, the two projects were con-

ceptually merged through development of a common

travel ontology. First, still within the TSS, we have

developed and then merged ontologies of hotels and

restaurants. These two ontologies were developeduti-

lizing a very pragmatic approach to ontology building

and were based on the concept of a hotel as repre-

sented in travel-related WWW sites and concept of a

restaurant as proposed in the ChefMoz project, re-

spectively (Gawinecki et al., 2005a; Gordon et al.,

2005).

In the airline ticket auctioning system we have

pursued an even more reality-grounded approach.

Here, of particular importance is the fact that all air-

travel related activities are regulated by IATA, the

global air-travel governing organization. This fact is

not often recognized by non-practitioners and as a

result, as shown in (Vukmirovic et al., 2006c; Vuk-

mirovic et al., 2006a), most of existing air travel on-

tologies, being typically developed as an academic

exercise, lack speciﬁc features that are required by

IATA as well as a number of additional features that

are needed in day-to-day operation of existing air-

Cieslik A., Ganzha M. and Paprzycki M. (2008).

DEVELOPING OPEN TRAVEL ALLIANCE-BASED ONTOLOGY OF GOLF.

In Proceedings of the Fourth International Conference on Web Information Systems and Technologies, pages 62-69

DOI: 10.5220/0001530700620069

 SciTePress

Table 1: Summary of OTA golf messages.

Message type List of ﬁelds

OTA GolfCourseSearchRQ—request for course information;

used to ﬁnd golf courses that satisfy a given set of criteria

Architect, ADAChallenged, Slope, Metal Spikes, Caddies available, Yardage,

Personal Carts Permitted, Grass Type, Singles Conﬁrmed

OTA GolfCourseSearchRS—list of courses that meet the re-

quested criteria; if attribute is speciﬁed as Required (set to Yes)

then only courses that meet criteria will be returned; if Required

attribute is No a course that does not meet a given criteria may

be included in the list

Golf Course ID, Golf Course address, Contact information—telephone number,

List of requested criteria

OTA GolfCourseAvailRQ—requests information about avail-

ability of a speciﬁc golf course

Golf Course ID, Tee Time—start and end date, Number of golfers, Number of

holes, Maximum price for one person

OTA GolfCourseAvailRS—provides information about ﬁeld

availability

Golf Course ID, Tee Time, Number of golfers, Number of holes, Maximum price

for one person, List of fees. Fee has name, information about amount, currency

and taxes

OTA GolfCourseResRQ—requests a reservation of a given golf

course

Information about person who makes reservation (ﬁrst and last name, address,

date of birth, telephone number), Mean of payment, Date of game, Number of

golfers, Number of carts, List of fees

OTA GolfCourseResRS—conﬁrms (or denies) reservation of a

given golf course

Reservation ID, Information about person who makes reservation (ﬁrst and last

name, address, date of birth, telephone number), Mean of payment (credit cart

information), Date of game, Number of golfers, Number of carts, List of fees,

Information concerning cancellation penalties and date and time by which a can-

cellation must be made

lines. Separately, the Open Travel Alliance (OTA)

(OTA, a) has proposed a set of messages that organi-

zations involved in travel-related activities can use to

meaningfully communicate about travel entities such

as ﬂights or golf course reservations. Interestingly,

one can infer that OTA messages may be currently on

the way to become an industry-wide standard. For

instance, a number of travel-related businesses (e.g.

some of US-based airlines) have accepted OTA mes-

sages in their business practices. Let us also note

that, from the technical perspective, OTA messaging

is an open standard that consists of a set of XML-

demarcated messages. Obviously, by the very nature

of their design and function, these messages represent

a certain conceptualization of the “world of travel.”

However, they do not explicitly deﬁne an ontology.

In (Vukmirovic et al., 2007) we have proposed how

OTA air-travel-relatedmessages can be used as a basis

for development of an ontology of air-travel. Further-

more, we have utilized IATA manuals, and practical

knowledge of a member of our team, in an attempt to

assure compliance of the proposed ontology with air-

travel regulations and practices. Finally, the proposed

air-travel ontology was successfully merged with the

ontology of restaurant and hotel. The results (com-

plete ontology of restaurants, hotels and air travel)

can be found at (tss, ). The aim of this paper is to

describe how, in an attempt at extending the TSS on-

tology and functionality, the OTA golf messaging has

been turned into an OTA ontology of golf.

To this effect we proceed as follows. In the next

section we describe the OTA golf messages. We fol-

low with the speciﬁcation of concepts that have to be

represented in the OTA golf ontology. Next we ana-

lyze which concepts should be re-used from the TSS

ontology (in order to allow later merging of these on-

tologies). Finally we present the most important parts

of the proposed OTA ontology of golf.

2 OTA GOLF MESSAGES

Let us now brieﬂy describe golf-related OTA mes-

sages (description is based on (OTA, b)). As in the

case of all OTA messages, they come in pairs. There

is alway a request (RQ) message (a query) and, cor-

responding to it, a response (RS) message. For the

golf-course-related communications the OTA stan-

dard identiﬁes three pairs of messages summarized in

Table 1. In short, these messages provide the follow-

ing functionalities: (1) ability to ﬁnd a golf course

with speciﬁc characteristics, (2) check if a course of

interest is available at a speciﬁc time and under a spe-

ciﬁc set of conditions (e.g. below a certain maximum

price), and (3) make an actual reservation.

To illustrate the speciﬁc form that OTA messages

take, in Figure 1 we present an example on an

OTA GolfCourseAvailRQ message (based on (OTA,

b)). In this message two friends specify that they

would like to play golf on October 31st, and the re-

DEVELOPING OPEN TRAVEL ALLIANCE-BASED ONTOLOGY OF GOLF

quested tee-off time is to be between 1:00 and 2:30.

They are interested in playing at a speciﬁc golf course

with the identiﬁer FL3421. The maximum price that

they are willing to pay for 18 holes is $80.00 per per-

son. The aim of this message is to ﬁnd if the FL3421

course is available at a given time and if the price con-

dition is satisﬁed.

<?xml version=” 1.0 ” encoding =”UTF−8” ?>

<OTA\ GolfCourseAvailRQ xmlns=

‘ ‘ h t t p : / /www. op e n travel . org /OTA/2003/05 ’ ’

xmlns : x s i=

‘ ‘ h tt p : / /www.w3. org /200 1 /XMLSchema−i n s t an c e ’ ’

xsi:sch e m a L ocat i on=

‘ ‘ h tt p : / /www. ope n t ravel . org /OTA/200 3 /

05 OTA GolfCourseAvailRQ . xsd ’ ’

EchoToken=”12345”

TimeStamp=”1003−05−31 T13:20:00 −05:0 0 ”

Target =” Pro d u ction” Versio n=” 1.001 ”

SequenceNmbr=” 123456 ”>

<GolfCourseTeeTime S t a r t =”2003−10−31 T13:00:00 ”

End=”2003−10−31 T14:30:00 ”

NumberOfGolfers=”2”

NumberOfHoles=”18”

NumberOfTimes=”1”

MaxPrice=” 80.00 ”

CurrencyCode=”USD”>

</ GolfCourseTeeTime>

</ GolfCourseTeeTimes>

</OTA\ GolfCourseAvailRQ>

Figure 1: Example of an OTA golf course availability query

message.

In response to the OTA GolfCourseAvailRQ message

depicted in Figure 1, the OTA GolfCourseAvailRS

message presented in Figure 2 could have been re-

ceived. This response indicates that the requested

FL3421 course is available on October 31st, with the

tee-time between 1:00 and 2:30. Furthermore, the

green fee is $70.00 per person, while the cart fee is

$10.00 per person.

As a result, a GolfCourseResRQ message could be

send, requesting a reservation at a speciﬁc time. This

message would then have to be followed by a Golf-

CourseResRS message that would conﬁrm the reser-

vation.

3 DESIGNING THE

ONTOLOGY—PRELIMINARY

CONSIDERATIONS

Now, we can discuss how OTA golf-course-related

messages can be used as a basis for the development

of an OTA golf course ontology. Analysis of OTA

<?xml version=” 1.0 ” encoding=”UTF−8” ?>

<OTA\ GolfCourseAvailRS

xmlns =‘ ‘ h t tp : / /www. ope n t ravel . org /OTA/2003/0 5 ’ ’

xmlns : x s i = ‘ ‘ h t t p: / /www.w3. org / 2 001/

XMLSchema−insta n c e ’ ’

xsi:sch e m a L ocati on=

‘ ‘ h t t p : / /www. o pentra v e l . org /OTA/2003/05

OTA GolfCourseAvailRS . xsd ’ ’

EchoToken=” 12345 ”

TimeStamp=”2003−05−31 T13:20:00 −05:00 ”

Target =” Pro d u ction”

Version=” 1.001 ”

SequenceNmbr=” 123456 ”>

</ UniqueID>

<GolfCourseTeeTime

S t a r t =”2003−10−31T13:00:00 ”

End=”2003−10−31 T14:30:00 ”

NumberOfGolfers=”2”

NumberOfHoles=”18”

NumberOfTimes=”1 ”

MaxPrice=” 80.00 ”

CurrencyCode=”USD”>

<Fees>

<Fee T axInc l u s ive=” t r ue ”

Amount=” 70.00 ” CurrencyCode =”USD”>

</ Descrip t i on>

</ Fee>

<Fee T a x Inclus i v e=” true ”

Amount=” 10.00 ” CurrencyCode =”USD”>

</ Descrip t i on>

</ Fee>

</ Fees>

</ GolfCourseTeeTime>

</ GolfCourseTeeTimes>

</OTA\ GolfCourseAvailRS>

Figure 2: Example of an OTA golf course availability re-

sponse message.

golf related messages showed us a need for deﬁning

of two core concepts: Golf Course and Golf Course

Tee Time. The ﬁrst one is going to uniquely iden-

tity a given golf course and its features. This concept

is related directly to the ﬁrst of OTA message pairs,

where a golf course with a speciﬁc set of features is

sought. This concept is similar to the restaurant and

hotel concepts from the TSS ontology of travel. All

three concepts deﬁne a static object and a set of its

features. The second concept will deﬁne all informa-

tion that is necessary for completing a reservation of

a golf course. Thus, the Golf Course Tee Time con-

cept deﬁnes dynamic characteristics of a static object

speciﬁed in the Golf Course object. The Golf Course

WEBIST 2008 - International Conference on Web Information Systems and Technologies

concept and its features are represented in Table 2.

Table 2: Golf Course concept and its features.

Class GolfCourse

Course ID ID originates from theOTA GolfCourseSearchRS

message; can be used for getting information

about golf course availability and for making

reservations

Address Address of golf course

Contact Contact information (e.g. telephone number)

Features List of golf course features

In Table 3 we list features that constitute the nec-

essary information to deﬁne the Golf Course Tee

Time concept. Since the “names of features” are

self-explanatory, we do not deﬁne them further. It

is of value to compare the list of features deﬁn-

ing the Golf Course Tee Time concept with the con-

tent of the golf course availability querying (Golf-

CourseAvailRQ) message presented above.

Table 3: Golf Course Tee Time concept and its features.

Class GolfCourseTeeTime

Course ID

Start date and time

End date and time

Price

Max price for one person

Number of holes

Number of golfers

Number of games

List if fees

After identifying two concepts that are going to con-

stitute the core of the OTA golf ontology, we have

to address the following question: how does this on-

tology relate to the existing TSS ontology. In other

words, we have to establish which already existing /

deﬁned concepts can (and should) be immediately re-

used in the new ontology.

3.1 Common Concepts with the TSS

Ontology

Ontology re-use is one of important concepts in on-

tological engineering (Fensel, 2003). Therefore we

should re-use as much as possible of the existing on-

tologies (and we have done so within the TSS ontol-

ogy). Furthermore, the OTA golf course ontology,

should be integrable with the TSS ontology and thus

utilize immediately as many of its concepts as pos-

sible. Thus we have identiﬁed existing concepts that

could be re-used; let us list them here.

Outdoor Location—geographical location is one of

common features of objects populating the TSS

(restaurant, hotel, airport). Obviously, it is also a con-

cept that is directly related to the golf course. The

OutdoorLocation concept (class) describes geograph-

ical location through a set of geographical properties,

such as: street address, country, city/town, region, zip

code, reference points or location description (see the

TSS ontology available at (tss, ) for a complete list-

ing). In the TSS ontology, the Hotel, the Restaurant

and the Airport classes are sub-classes of the Out-

doorLocation class. Therefore, the proposed class

GolfCourse should also become a subclass of Out-

doorLocation. This is a natural decision as the Golf

Course should be an object of the same “stature” as

the other objects mentioned here.

Discounts—in general, is the class that contains the

following information:

• code of the particular discount,

• amount of reduction of the base-price,

• short description of the discount policy.

However, when dealing with air travel support we

have realized that IATA deﬁned speciﬁc air travel

discount codes. Therefore, the question has arisen:

how to integrate these with hotel and restaurant dis-

count codes (including both OTA-speciﬁc and gen-

eral discounts—these omitted in the OTA speciﬁ-

cation). For the purpose of integration of ontolo-

gies, speciﬁc discounts codes were distinguished and

deﬁned as subclasses of the general DiscountTypes

class. Speciﬁcally, in the TSS there exist three classes

deﬁning possible discounts:

• OTADiscountTypes—discount types originating

from the OTA speciﬁcation

• IATADiscountTypes—discount types originating

from the IATA speciﬁcation

• DiscountTypes—general class; all discount types

Obviously, classes OTADiscountTypes and IATADis-

countTypes are subclasses of DiscountTypes. Note

that since the proposed ontology of golf is based on

OTA messages, the discount concepts used here be-

long to the OTADiscountTypes class.

The remaining common parts between the TSS and

the OTA golf course ontologies are:

• MeanOfPayment—concept deﬁning possible

mean of payment (e.g cash, credit card, check,

etc.)

• AdressRecord—class that in the TSS ontology de-

scribes the address

• Currency—deﬁnes what is the currency that the

fees are in

• FareTax—information about taxes

DEVELOPING OPEN TRAVEL ALLIANCE-BASED ONTOLOGY OF GOLF

• Contacts—possible ways of contacting an entity

(e.g. telephone number)

4 THE OTA GOLF ONTOLOGY

Figure 3: Golf Course concept; graphical representation.

Based on the above considerations we can now brieﬂy

discuss the most important aspects of the proposed

OTA golf ontology. Let us start from deﬁnitions of

the two basic classes, the main class deﬁning the con-

cept of the Golf Course is presented in Figure 4 (in

the form of the standard RDF notation) and in Figure

3 (in the visual representation).

As can be easily seen in the graphical representa-

tion, the GolfCourse class is a subclass of Outdoor-

Location and utilizes the Contacts concept (from the

TSS ontology). In its deﬁnition we use strings for: id,

courseName, architect; and an integer for the slope.

The second concept that belongs to the core of the

OTA golf course ontology is Golf Course Tee Time is

presented in Figure 5 (in the RDF notation) and in

Figure 6 in its graphical representation.

Observe that while the GolfCourseTeeTime class

is relatively simple itself (it consists of strings for:

startDate, endDate and golfCourseID; ﬂoat for max-

Price; and an integer for numberOfTimes), it utilizes

also a fairly extensive concept of a Fee. This points

out to the fact that in addition to the two basic con-

cepts (classes GolfCourse and GolfCourseTeeTime)

we had to deﬁne the following additional concepts /

classes:

• Price—concept of price (includes: amount, taxes,

currency, etc.)

• Fee—concept of fee (e.g. green fee, cart fee)

• Description—additional descriptions that are

needed for the traveler to be able to effectively uti-

lize the information provided by the system

@prefix r d f:

< h t t p : / /www.w3. org /1999/02/22 − rdf −syntax −ns \#> .

@prefix r df s :

< h t t p : / /www.w3. org / 2 000/01/ rdf −schema\#> .

@prefix x s d:

< h t t p : / /www.w3. org / 2 001/XMLSchema\#> .

@prefix b a s e : <Golf / GolfCourse \#> .

@prefix l o c : <Location / Outd oorLocation\#>.

@prefix pmt: <Payment / MeanOfPayment\#>.

@prefix phc : <C ontacts / Contacts \#> .

@prefix r s v :

<H o t e lI n f r a st r u c t u r e Cod e s / Reserv ationCod es\#> .

base:Gol fCourse a r d f s : C l a s s ;

rdfs : s u bClassOf loc:O u t doorLoc a t i on ;

rdfs:comment ‘ ‘ Used fo r c i ty and

geogra p hical l o c a t i o n d e s c r i p t ion ’ ’ .

b as e :i d a r d f : P r o per t y ;

rdfs : d omain base :GolfCourse ;

r d f s:r a n g e x s d : s t r i n g .

base:name a r d f: P r o p e r t y ;

rdfs : d omain base :GolfCourse ;

r d f s:r a n g e x s d : s t r i n g .

b a s e : c o n t act I n fo a r d f : Pro p e r t y ;

rdfs:comment ‘ ‘ Con tact i n format i o n . ’ ’ ;

rdfs : d omain base :GolfCourse ;

r d f s:r a n g e phc:Cont a c t s .

b a se : a r c h i t ec t a r d f : P r o p e r t y ;

rdfs:comment ‘ ‘ I n forma t ion a bout a r c h i t e c t ,

who design t h is g olf cou rse ’ ’ ;

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e x s d: s t r i n g .

base : s l ope a r d f :Pr o p e rt y ;

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e x s d : i n t e g e r .

base:ava i l Caddy a r df:P r o per t y ;

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e xsd:bo o l ean .

base:permCart a rd f : P r o p e rty ;

rdfs:comment ‘ ‘ I n forma t i on i f persona l

c a r t s are p e rmitt e d ’ ’

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e xsd:bo o l ean .

base:ya r d age a r d f : P r o p e rty ;

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e x s d : f l oa t .

base:sin g l esConfir med a r d f : P rop e rt y ;

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e xsd:bo o l ean .

base:me t a lSpike s a r d f: P ro per t y ;

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e xsd:bo o l ean .

b a s e :g r as s a r d f :Pr o p e rt y ;

rdfs : d omain base:GolfCourse ;

r d f s:r a n g e x s d: s t r i n g ;

Figure 4: Golf Course concept; proposed GolfCourse class.

Note that the concept of the Price is similar to that

used in the TSS ontology, however in the case of a golf

course it is much less complicated than in the case of

air travel. Therefore we have decided, for the time

WEBIST 2008 - International Conference on Web Information Systems and Technologies

@prefix r d f : < h t t p : / /www. w3 . org /1999/02/22− rdf−syntax −ns \#> .

@prefix r d f s : < h t t p : / /www. w3 . org /2000/ 0 1/ rdf −schema \#> .

@prefix x s d: < h t t p: / /www.w3. org / 2 0 01/XMLSchema\#> .

@prefix f e e : < f i l e : / / / D: / ont o l o g i e s / domain / Golf / Fee\#>.

@prefix b ase: < f i l e : / / / D: / onto l o g i e s / domain / Golf / GolfCourseTeeTime \#> .

base:GolfCourseTeeTime a r d f s: C l a s s ;

base:go l fCourse ID a r df:P r o per t y ;