ontour gooddesignpartdoc

8/3/2019 OnTour goodDesignpartdoc

1/38

1

OnTour

The Ontology

Kathrin Prantner

[email protected]

DERI Innsbruck

www.deri.org


2/38

2

Abstract

The eTourism working group wants to specify a use case to demonstrate the potential use of Semantic

Web technology in eTourism. We set up a small prototype called OnTour, which was realized by the

end of the year 2004. OnTour is a Semantic Web search assistant which makes it possible to the user

to search for vacation packages including accommodations and activities. This is possible with usingthe user interface, where the user can tick on several features he likes. We decided not to annotate

web pages on the fly and set up knowledge base like KIM does. We really want to build a small part of

the Semantic Web for eTourism in Innsbruck consisting of selected semantic enhanced pages. On the

amount of data we can then give a demonstration on how Semantic Web works if the pages are

enriched according to the standards so far.

This paper describes the ontology which was designed for this application. The authors of the ontology

took various existing ontologies into consideration but it turned out that there was no ontology which

was suitable for our requirements. Therefore we developped a ontology focusing on Accomodation,

Activities and the Infrastructure for the activities.


3/38

3

1. Introduction ....................................................................................... 4

2. General Structure and Design Principles ................................................. 5

2.1 Language..................................................................................... 5

2.2 Integration of existing ontologies .................................................... 6

2.3 Used Tools ................................................................................... 7

2.4 Process of Creation ....................................................................... 7

2.5 Instances..................................................................................... 8

3. Usage of the ontology.......................................................................... 8

3.1 Actual System Design.................................................................... 8

3.2 Future System Design ................................................................. 10

4. Ontology Description ......................................................................... 11

4.1 Class Accommodation .................................................................. 12

4.2 Class Activity.............................................................................. 15

4.3 Class Contact Data ...................................................................... 15

4.4 Class Date and Time.................................................................... 17

4.4.1 Class Opening Hours ............................................................. 17

4.4.2 Class Period ......................................................................... 18

4.4.2.1 Class Date Period............................................................... 18

4.4.2.2 Time Period....................................................................... 19

4.4.3 Season................................................................................ 20

4.5 Class Event ................................................................................ 20

4.6 Class Infrastructure..................................................................... 21

4.7 Class Language........................................................................... 23

4.8 Class Location ............................................................................ 24

4.8.1 Class GPS Coordinates........................................................... 24

4.8.2 Class Postal Adress ............................................................... 26

4.9 Class Room................................................................................ 27

4.9.1 Class Conference Room.......................................................... 29

4.9.2 Class Guestroom................................................................... 31

4.10 Class Ticket................................................................................ 36

5. Future Work..................................................................................... 37

6. Related Work ................................................................................... 38

7. Conclusion ....................................................................................... 38

8. References....................................................................................... 38


4/38

4

1. Introduction

Today ontologies have become common on the World Wide Web and they range from large

taxonomies categorizing Web sites to categorizations of different products for sale and their

features. In general an ontologie defines a common vocabulary, i.e. for researchers who

need to share information in a domain. An ontology describes machine interpretable

definitions of basic concepts and the relations among them. For the purpose of this project

the term ontology is defined as follows: An ontology is a formal expicit description of

concepts in a domain of discourse (called classes or concepts), properties of each concept

describing various features and attributes of the concepts are called slots and a knowledge

base consists of the ontology combined with a set of instances. In reality the difference

between the line where the ontology ends and the knowledge base begins is very thin.

Advantages and reasons why an ontology is used are:

o Sharing common understanding of the structure of information among people or

software agents

o Enabling reuse of domain knowledge

o Making domain assumptions explicit

o Seperating domain knowledge from the operational knowledge

o Analyzing domain knowledge

If there are used and published the same underlying ontologies on the Web, the computer

agents are able to find and to extract information more easily. Another aspect is the reusage

of existing ontologies. There are already a lot available, i.e. time and date ontologies. It is not

necessary to create a new ontology, if others have designed it and it is also possible to

extend these existing ones. Also important is that if the knowledge of the domain changes,

also the assumptions made in the ontology can be changed easily, so it is really easy to

adapt it. The analyzation of domain knowledge becomes possible, once a specification of a

term is available. Also the development of standardized ontologies for different disciplines is

increasing what helps the experts of a domain to share and to annotate information.

Normally the creation and designment of an ontolgy is not the main goal in itself. An ontologyor a knowledge base built from an ontology as data is developed to be used by other

programs and applications. This is also the case in this project, where it was used Protg

3.0 for creating the ontolgy.

In section 2 there will be discussed the the structure of the ontology and ist design principles,

like language, integration of existing ontologies, instances, and used tools. Section 3

describes the usage of this ontology, and section 4 includes the documentation. Related

work and future work is discussed in section 5 and section 6.


5/38

5

2. General Structure and Design Principles

In this section there are discussed general tasks of the created ontology. More precisley

there will be described the used language, the integration of existing ontologies, used tools,

the process of creation of the ontology, and the creation of instances.

2.1 Language

The current standards of Semantic Web Ontology Languages at the moment are RDF

Schema Language and OWL [1]. After some recherche we decided to use OWL DL, because

the expressivity of RDFS is not as high as the expressivity of OWL. OWL-DL is a subversion

of OWL, and it is based on the SHI2 Description Logic.

Figure 1: Relationship of OWL-Full, OWL-DL, and OWL-Lite

Differences between OWL (OWL Full, OWL-DL, and OWL-Lite) are that RDF and RDFS

doesnt support cardinality, what we wanted to use developing our ontology. There is also no

possiblity to model disjointness of classes and it is more difficult to perform reasoning.

Another advantage of OWL-DL is that is supports OWA (Open World Assumption), which

was an important issue for our project. Open World Assumption means that the absence of

information is not interpreted as a negative information. For example if an owner of an

accommodation, listed in our search index, doesnt give information about a swimming pool,

it doesnt mean that he has no one. OWL-DL also supports the Unique Name Assumption, so

that the difference of two instances has to be pointed up explicitely. OWL-DL is based on

formal defined semantics and it supports decidability, where all calculations are done in finite

time-limits. Also completeness and soundness are important, what means that all

conclusions are drawn and valid. Here some possible constructs of OWL-DL with an

example each:


6/38

6

Figure 2: Possible constructors of OWL-DL

Figure 3: Possible axioms of OWL-DL

2.2 Integration of existing ontologies

At the beginning of the project several ontologies were considered for reuse but no one was

exactly that one we wanted to have for our small region. So the team decided to create one

themselves. As artwork we used the actual thesaurus which was created by the World

Tourism Organization (WTO) specially for the sector of etourism and which is an international

standard. This thesaurus defines all important terms which stand in relation with the toursimindustry. To get a first structure of our ontology we looked for the chapters activities and

infrastructures and marked all terms we also wanted to include.

In generally we are not aversed to include also existing ontologies in the next step of

development, for instance the Harmonise Ontolgoy [2]. Harmonise is an EU-project and was

created by many different institutions from europe. It is an overall solution for information

exchange in travel and tourism. This ontology allows different message standards or data

formats to exchange data in a cost effective way. It offers fully supported open software andit allows the inclusion of advanced features. In the currently version of the Harmonise


7/38

7

Ontology are included the following data items: accommodation (including hotels, bed and

breakfast, rural tourism and camping), attraction and sights, events, and restaurants.

Other useful ontologies would be some which define date and time. There are different

available ontologies concerning the date and the time all over the web and from other

research groups, but at the moment we didnt had a look at them.

2.3 Used Tools

The ontology was created with Protg 3.0 beta version [3], and open-source development

evironment for ontologies and knowledge-based systems. Protg is a tool which provides

the following features to the user:

o construction of a domain ontology

o customization of data

o entry of data

Furthermore Protg can be used as a platform, where the user has the possiblity to create

graphical applications, like widgets for tables, diagrams, animation components, etc. It also

offers a library which makes it possible to other applications to access and to display

knowledge bases. In our case of developing a semantic ontology we could also use the

OWL-Plugin, another special feature and extension of Protg. This OWL-Plugin provides

the following features:

o Load and save OWL ontologies

o Edit and visualize OWL classes and their properties

o Define logical class characteristics as OWL expressions

o Execure reasoners such as description logic classifiers

o Edit OWL individuals for Semantic Web markup

2.4 Process of Creation

The first step after consulting the Thesaurus was now to create the classes and conceptswhich were needed for giving a general structure for accommodations and accommodations

facilities. At the beginning this task was very hard, specially to name the terms that they

became clear and unique. Also the decision of which classes and subclasses should be

created was hard. So it was forcasted that the structure of the ontology would change more

often until the protype was running. The look on existing Web sites of hotels was inescapable.

With help of several Web sites it became clear what kind of information the providers and

owner give, and the classes and concepts were aimed to them. The next step was now to

create and document the slots. The slots are then shown on the input formular where theuser of OnTour can tick on the favourites.


8/38

8

2.5 Instances

For our prototype OnTour it was decided that we create instances on our own for testing the

system. That means that we included some accommodations and accommodation facilities

manually into the ontology, so the information at the moment is centralized. In advanced

progress the information will be distributed, so the ontology will be seperated from the

knowledge base. This will be explained more in detail in section 3.

The instances now are necessary to get some search results with OnTour. The complexity

of the available information is not very high at the moment. In the actual version of the

ontology there are 20 accommodations, and 22 accommodation facilities, which are all

located near Innsbruck. All of them were choosen by chance, we only took care of having

different qualities and offers. Additionally there are included the contact data, the postal

address, and the GPS-coordinates of each accommodation and each infrastructure. For

differntiating the accommodations, the qualities of the guest- and conferencerooms were

evaluated, so altogether there are 56 guestrooms and 12 different conference rooms. Each

accommodation faciliety offers different tickets, i.e. a skiing resort, so it was decided to

provide also information about the tickets and their price to the user. At the moment there are

42 tickets.

3. Usage of the ontology

In this section there will be given a short overview of the whole system and architecture of

the search assistent OnTour, so that it becomes clear for what the ontology is used for.

There will be described the actual architecture, but also the one of the future. Again it has to

be pointed out that the current version of the OnTour search assistant is a beta version, and

that it is going to be advanced.

3.1 Actual System Design


9/38

9

Figure 4: The architecture of OnTour

At the moment OnTour works as follows: At the back there is an ongology which defines

accommodations and activities with different activity facilities. It were created instances

manually, so the knowledge base is included in the ontology at the moment. This also means

that the information now is centralized. The inference engine which was used is racer, which

is responsible for querying the request which the user does when searching with the formular.

The formular gives the user the possiblity to cross certain features of accommodations and

activities. Additionally the user is able to specify a distance between the wanted activity and

the accommodation. The Core is responsible for querying, for the suggest value, and for

packaging. The suggest value is given in case a user wants to refine his search. For every

attribute which is available on the online search form and which was crossed by the user

there is a value in brackets. This value shows the user how many results the OnTour would

give, if he searches again without this value, for example has parking. The results of the

OnTour are packages called vacation packages.

User inte rfa c e

Ontology

&

Know led ge BaseInference

engine

Computation

engine

Computation

engine

Computation

engine


10/38

10

Figure 5: Vacation package of OnTour

Each package includes the available accommodations which accomplish the criteria, and the

activitiy facilities in the wished distance. Every package includes the links to the resulted

infrastructures. In future such a vacation package will also include information about prices,

availablility of the accommodations or of certain tickets, a date and time aspect (for example

opening hours or season), but also information about events and transportation possiblities.

In future the system will be enhanced to the following model:

3.2 Future System Design

Figure 6: The future architecture of OnTour

Accommodation

Activity

Vacation

package

Infrastructure

Distance

Crawler

Index

Concep t editor

Annotation editor

User interfac e

Ontology

Knowled ge ba se

Computation

engine

Computation

engine

Computation

engine

Inference

engine


11/38

11

Now it becomes clear what will happen. The Semantic Websites contain the information

offered by the owners of the infrastructure (accommodation and activity facilities). The

ontology now is seperated from the information which is now distributed. Here is the big

advantage of the Semantic Web. Each provider of information has to annotate his existing

website wich help of an Annotation Editor. The provider of information is able to change the

information easily on his own and he can give only informtion he wants. The annotated data

will then be located on the providers server. To get the information from the different

Semantic Web sites there will be a crawler which goes through the offered information and

prepares an index for the search. The index then is updated regularly and stored on a local

server.

4. Ontology Description

This section contains a detailed definition of the concepts and classes in the etourism

prototype ontology. For each class, we define its superclass and subclasses, give a human-

readable, non-normative description and list the properties which have this class within their

domain. The documentation of the OnTour ontology was generated directly out of Protg

and it includes also the instances, which were included manually to test the OnTour system.

First there is shown an overview of the structure, before each class is listed with its slots. The

actual version of the ongology can also be seen on http://ontologies.deri.org.

Accommodation

Activity

Contact Data

Date Time

o Openinghours

o Period

DatePeriod TimePeriod

o Season

Event

Infrastructure

Language

Location

o GPS Coordinates

o Postal Adress

Room


12/38

12

o Conferenceroom

o Guestroom

Ticket

4.1 Class Accommodation

Concrete Class Extends

owl:Thing, hasRoom Guestroom, hasRoom (Guestroom ConferenceRoom)

Direct Instances:

1. PensionPaula2. HotelAngelika3. HotelKlosterbraeu4. HotelWeissesKreuz

5. HotelCentral6. PenzInnsbruck7. ParkhotelHall8. SporthotelIgls9. PensionGlungezer10.HiltonInnsbruck11.AlpenhotelLamm12.HotelStubaierhof13.Lizumerhof14.JugendherbergeInnsbruck15.ZurLinde16.PensionTulferhof17.HotelKoegele18.PensionBoeckenhof19.HotelMarthe20.HotelDollinger

Direct Subclasses:None

Class Documentation:This class is a concrete representation of the concept of accomodations.

Template Slots

Slot name Documentation TypeAllowed

Values/Classes

Cardi

nality

Def

ault

hasRoom

This property links

one or more

individuals

representingrooms.

InstanceGuestroom,

ConferenceRoom0:*


13/38

13

hasName

This property

indicates the name

of an individual.

String 0:1

hasType

This property

indicates the typeof an individual. String 0:1

hasPostalAddress

This property links

an individual

representing

another individuals

postal address.

Instance PostalAddress 0:1

hasGPSCoordinates

This property links

an individual

representing

another individualsGPS coordinates.

Instance GPSCoordinates 0:1

hasContactData

This property links

an individual

representing

another individuals

contact data.

Instance ContactData 0:1

hasDryingRoom

This property

indicates whether

an individual has a

drying room ornot.

Boolean 0:1

spokenLanguage

This property

indicates which

languages are

spoken.

Instance Language 0:*

petsAllowed

This property

indicates whether

pets are allowed or

not.

Boolean 0:1

hasParking

This property

indicates whether

an individual has

parking or not.

Boolean 0:1

hasStarRating

This property

indicates the

number of stars of

an accommodation

(1 to 5 stars).

Integer 0:1

hasBoard

This property

indicates shich

board is offered by

Instance Board 0:*


14/38

14

an individual.

Allowed values

are: full board, half

board, breakfast,

and all inclusive.

hasElevator

This property

indicates whether

an individual has

an elevator or not.

Boolean 0:1

hasWellnessFacility

This property

indicates whether

an individual has

wellness facilieties

or not.

Instance WellnessFacilities 0:*

offersChildCare

This propertyindicates whether

an individual

offers child care or

not.

Boolean 0:1

hasHandicapAccessibility

This property

indicates whether

an individual has

handicap

accessiblity or not.

Boolean 0:1

offersLaudryCleaning


an individual

offers laundry

service or not.

Boolean 0:1

hasBaggageRoom

This property

indicates whether

an individual has

an baggage room

or not.

Boolean 0:1

offersCrib


an individual

provides a crib on

request or not.

Boolean 0:1

offersCot

This property

indicates whether

an individual

provides a cot on

request or not.

Boolean 0:1

offersShuttleServiceThis propertyindicates whether

an individual

Boolean 0:1


15/38

15

offers a shuttle

service or not.

4.2 Class Activity


owl:Thing

Direct Instances:

1. Ice-skating2. Skiing3. Snowboarding4. Bowling

5. CrossCountry-skiing6. Tennis7. Swimming8. Riding

Direct Subclasses:

None

Class Documentation:

This class is a concrete representation of the concept of activities.

Template Slots


Values/ClassesCardinality Default

hasName

This property indicates

the name of an

individual.

String 0:1

hasType


the type of anindividual.

String 0:1

canBeDoneAt

This property links an

individual representing

the infrastructure where

an activity can be done.

Instance Infrastructure 0:*

4.3 Class Contact Data

Concrete Class Extendsowl:Thing


16/38

16

Direct Instances:

1. HotelDollingerCD2. AlpenhotelLammCD3. SattelbergCD

4. IceRinkInnsbruckCD5. IceRinkSeefeldCD6. IceRinkHallCD7. RosshuetteCD8. Schlick2000CD9. StubaierGletscherCD10.ElferLifteCD11.PatscherkofelCD12.HochserlesCD13.GlungezerBahnCD14.AxamerLizumCD

15.NordparkCD16.CrossCountry-SkirunSeefeldCD17.IndoorSwimmingPoolAxamsCD18.PensionPaulaCD19.HotelAngelikaCD20.BowlinghallCD21.HotelKlosterbraeuCD22.HotelKoegeleCD23.HotelCentralCD24.HotelWeissesKreuzCD25.PensionBoeckenhofCD26.RidingStableSeefeldCD27.CrossCountry-SkirunAxamsCD28.HotelMartheCD29.PenzCD30.ParkhotelHallCD31.TennisCourtIglsCD32.TennisCourtSeefeldCD33.IndoorSwimmingPoolSeefeldCD34.PensionGlungezerCD35.RidingStableGnadenwaldCD

36.SporthotelIglsCD37.JugendherbergeInnsbruckCD38.HiltonCD39.LizumerhofCD40.HotelStubaierhofCD41.ZurLindeCD42.PensionTulferhofCD

Direct Subclasses:

None


This class represents an individual's contact data.


17/38

17

Template Slots



hasWebsite

This property

indicates one or

more of an

individuals website

addresses and is part

of its contact data.

The protocol part of

the URI must not be

part of the value (i.e.

www.uibk.ac.at).

String 0:*

hasFaxNumber

This property

indicates an

individuals fax

number and is part

of its contact data. It

includes country and

area codes seperated

by hyphens as well

as possibly

necessary extensions

(i.e. +43-512-507-0).

String 0:1

hasTelephoneNumber

This property

indicates an

individuals

telephone number

and is part of its

contact data. It

includes country and

area codes seperated

by hyphens as well

as possibly

necessary extensions

(i.e. +43-512-507-0).

String 0:1

hasEMail

This property

indicates an

individuals email

address and is part of

its contact data.

String 0:1

4.4 Class Date and Time

4.4.1 Class Opening Hours


18/38

18


DateTime

Direct Instances:

1. Skiingresort1OH2. HollywoodbowlingOH


Class Documentation:This class is a concrete representation of the concept of an individual's opening hours.

Template Slots



hasSeason



a season.

Instance DatePeriod 0:*

hasWeekdayThis property indicates a

weekday. Symbol

Monday,

Tuesday,

Wednesday,

Thrusday,Friday,

Saturday,

Sunday

0:*

hasTimePeriod



a date period.

Instance TimePeriod 0:*

4.4.2 Class Period

1. Class Date Period


Period

Direct Instances:

1. SkiingResortDP2. PatscherkofelDP

Direct Subclasses:

None



19/38

19

This class represents the concept of date periods.

Template Slots


Values/Classes Cardinality Default

hasEndDate


the date when a date

period ends (2004-11-

19).

String 0:1

hasStartDate


the date when a date

period starts (2004-11-

19).

String 0:1

2. Time Period


Period

Direct Instances:

BowlinghallTP

Direct Subclasses:

None

Class Documentation:This class represents the concept of time periods.

Template Slots



hasStartTime


the time when a time

period starts. Hours,

minutes, and seconds

are sepersated by

colons. The postfix

stands for the hour

difference compared to

the coordinated

universal time (i.e.

13:20:00+05:00).

String 0:1

hasEndTimeThis property indicatesthe time when a time

period ends. Hours,

String 0:1


20/38

20

minutes, and seconds

are seperated by colons.

The postfix stands for

the hour difference

compared to the

coordinated universaltime (i.e.

13:20:00+05:00).

4.4.3 Season


DateTime

Direct Instances:PatscherkofelSeason

Direct Subclasses:

None


This class is a concrete representation of the concept of seasons.

Template Slots



hasName


the name of an

individual.

String 0:1

hasDatePeriod



a time period.

Instance DatePeriod 0:*

4.5 Class Event


owl:Thing

Direct Instances:

None


Class Documentation:This class is a concrete representation of the concept of events.


21/38

21

Template Slots



hasName

This property

indicates the name

of an individual.

String 0:1

hasType

This property

indicates the type of

an individual.

String 0:1

hasTicket

This property links

one or more

individuals

representing

different kinds oftickets.

Instance Ticket 0:*

hasPostalAddress

This property links

an individual

representing another

individual's postal

address.


hasGPSCoordinates

This property links

an individual


individual's GPScoordinates.


hasContactData

This property links

an individual


individual's contact

data.


hasTimePeriond

This property links

an individual

representing a date

period.

Instance TimePeriod 0:*

4.6 Class Infrastructure


owl:Thing

Direct Instances:

1. IceRinkInnsbruck2. IceRinkSeefeld

3. IceRinkHall4. SkiingresortNordpark5. SkiingresortAxamerLizum


22/38

22

6. SkiingresortRosshuette7. SkiingresortSchlick20008. SkiingresortStubaierGletscher9. SkiingresortSattelbergbahn10.Skiingresort11erLifte

11.SkiingresortPatscherkofel12.SkiingresortHochserles13.SkiingresortGlungezerBahn14.Bowlinghall15.CrossCountry-SkirunAxams16.CrossCountry-SkirunSeefeld17.TennisCourtSeefeld18.TennisCourtIgls19.IndoorSwimmingPoolAxams20.IndoorSwimmingPoolSeefeld21.RidingStableSeefeld

22.RidingStableGnadenwald

Direct Subclasses:

None


This class is a concrete representation of the concept of infrastructure.

Template Slots



hasName

This property

indicates the

name of an

individual.

String 0:1

hasType

This property

indicates the

type of an

individual.

String 0:1

hasTicket

This property

links one or

more

individuals

representing

different kinds

of tickets.

Instance Ticket 0:*

hasPostalAddress

This property

links an

individualrepresenting

another



23/38

23

individual's

postal address.

hasGPSCoordinates

This property

links an

individualrepresenting

another

individual's

GPS

coordinates.


hasContactData

This property

links an

individual

representing

another

individual'scontact data.


providesInfrastructureFor

This property

describes what

activity can be

done at an

infrastructure.

Instance Activity 0:*

hasOpeningHours

This property

indicates what

opening hours

an individuum

has.

Instance OpeningHours 0:*

4.7 Class Language


owl:Thing

Direct Instances:

1. Italian2. Arabian3. English4. German5. French6. Spanish7. Maltese

Direct Subclasses:

None


24/38

24

Template Slots



hasName


the name of an

individual.

String 0:1

4.8 Class Location


owl:Thing

Direct Instances:

None

Direct Subclasses:

1. GPSCoordinates2. PostalAddress


This class represents different ways for describing the geographical location of an

entity.

4.8.1 Class GPS Coordinates


Location

Direct Instances:

1. HotelKlosterbraeuGPS2. IceRinkSeefeldGPS3. ZurLindeGPS

4. PensionPaulaGPS5. RosshuetteGPS6. NordparkGPS7. IceRinkInnsbruckGPS8. IceRinkHallGPS9. Schlick2000GPS10.StubaierGletscherGPS11.SattelbergbahnGPS12.ElferLifteGPS13.PatscherkofelGPS14.HochserlesGPS

15.GlungezerBahnGPS16.AxamerLizumGPS17.AlpenhotelLammGPS


25/38

25

18.TennisCourtIglsGPS19.HotelDollingerGPS20.HotelWeissesKreuzGPS21.PensionBoeckenhofGPS22.SporthotelIglsGPS

23.IndoorSwimmingPoolSeefeldGPS24.HotelAngelikaGPS25.RidingStableSeefeldGPS26.BowlinghallGPS27.CrossCountry-SkirunSeefeldGPS28.HotelCentralGPS29.ParkhotelHallGPS30.CrossCountry-SkirunAxamsGPS31.PenzInnsbruckGPS32.TennisCourtSeefeldGPS33.IndoorSwimmingPoolAxamsGPS

34.HiltonInnsbruckGPS35.HotelKoegeleGPS36.PensionGlungezerGPS37.LizumerhofGPS38.HotelStubaierhofGPS39.ReitstallGnadenwaldGPS40.JugendherbergeInnsbruckGPS41.HotelMartheGPS42.PensionTulferhofGPS

Direct Subclasses:

None


This class represents the GPS coordinates of an entity using the WGS 84 (World

Geodetic System 1984) as global reference frame.

Template Slots


Values/Classes

Cardinality Default

hasLatitude


the latitude of an

individual in degrees

and is part of its GPS

coordinates. The WGS

84 (World Geodetic

System 1984) is used as

global reference frame.

String 0:1

hasLongitude


the longitude of anindividual in degrees

and is part of its GPS

String 0:1


26/38

26

coordinates. The WGS

84 (World Geodetic

System 1984) is used as

global reference frame.

4.8.2 Class Postal Adress


Location

Direct Instances:

1. PensionBoeckenhofPA2. SattelbergPA3. IceRinkInnsbruckPA

4. IceRinkSeefeldPA5. IceRinkHallPA6. NordparkPA7. RosshuettePA8. Schlick2000PA9. StubaierGletscherPA10.ElferLiftePA11.PatscherkofelbahnPA12.HochserlesPA13.GlungezerBahnPA14.HotelAngelikaPA

15.HotelStubaierhofPA16.AlpenhotelLammPA17.PensionPaulaPA18.IndoorSwimmingPoolAxamsPA19.BowlinghallPA20.HotelKlosterbraeuPA21.RidingStablePA22.HotelCentralPA23.CrossCountry-SkirunAxamsPA24.HotelWeissesKreuzPA25.CrossCountry-SkirunSeefeldPA26.PensionTulferhofPA27.SporthotelIglsPA28.PenzPA29.ParkhotelHallPA30.TennisIglsPA31.TennisCourtSeefeldPA32.LizumerhofPA33.IndoorSwimmingPoolSeefeldPA34.RidingStableSeefeldPA35.JugendherbergeInnsbruckPA

36.HotelMarthePA37.PensionGlungezerPA38.HiltonInnsbruckPA


27/38

27

39.HotelDollingerPA40.HotelKoegelePA41.ZurLindePA42.AxamerLizumPA



This class represents the postal address of an entity.

Template Slots



hasHouseNumber


the house number of the

building where an

individual is located and

is part of its postal

address.

String 0:1

hasCountry


the country where an



address.

String 0:1

hasCity


the city where an



address.

String 0:1

hasPostalCode


the postal code of the

area where an individual

is located and is part ofits postal address.

String 0:1

hasStreet


the street where an



address.

String 0:1

4.9 Class Room


owl:Thing

Direct Instances:


28/38

28

None

Direct Subclasses:

1. ConferenceRoom

2. Guestroom


This class is a concrete representation of the concept of rooms.

Template Slots



hasNameThis propertyindicates the

name of an

individual.

String 0:1

hasTelephone

This property

indicates

whether an

individual has a

telephone or

not.

Boolean 0:1

hasTVSet

This propertyindicates

whether an

individual has a

TV set or not.

Boolean 0:1

hasArea

This property

indicates an

individual's area

in square

metres.

Float 0:1

hasWiredInternetAccess

This propertyindicates

whether an

individual has

wired internet

access or not.

Boolean 0:1

hasAirCondition

This property

indicates

whether an

individual has

air condition ornot.

Boolean 0:1

hasFaxMachine This property Boolean 0:1


29/38

29

indicates

whether an

individual has a

fax machine or

not.

smokingAllowed

This property

indicates

whether

smoking is

allowed or not.

Boolean 0:1

hasVCR

This property

indicates

whether an

individual has a

VCR (Video

CassetteRecorder) or

not.

Boolean 0:1

hasWirelessInternetAccess

This property

indicates

whether an

individual has

wireless internet

access or not.

Boolean 0:1

4.9.1 Class Conference Room


Room

Direct Instances:

1. HiltonInnsbruckConferenceroom2. LizumerhofConferenceRoom3. PenzConferenceRoom4. HotelKlosterbraeuConferenceRoom5

5. HotelKlosterbraeuConferenceRoom26. HotelKlosterbraeuConferenceRoom67. HotelKlosterbraeuConferenceRoom38. HotelKlosterbraeuConferenceRoom49. HotelKlosterbraeuConferenceRoom110.ParkhotelHallConferenceRoom11.JugendherbergeConferenceRoom12.AlpenhotelLammConferenceRoom

Direct Subclasses:

None



30/38

30

This class represents the concept of conference rooms.

Template Slots

Slot name Documentation Type

Allowed

Values/Classes Cardinality Default

hasName

This property

indicates the

name of an

individual.

String 0:1

hasTelephone

This property

indicates

whether an

individual has a

telephone or

not.

Boolean 0:1

hasTVSet

This property

indicates

whether an

individual has a

TV set or not.

Boolean 0:1

hasArea

This property

indicates an

individual's area

in square

metres.

Float 0:1


This property

indicates

whether an

individual has

wired internet

access or not.

Boolean 0:1

hasAirCondition

This property

indicates

whether an

individual has

air condition or

not.

Boolean 0:1

hasFaxMachine

This property

indicates

whether an

individual has a

fax machine or

not.

Boolean 0:1

smokingAllowed

This property

indicates

whether

Boolean 0:1


31/38

31

smoking is

allowed or not.

hasVCR

This property

indicates

whether anindividual has a

VCR (Video

Cassette

Recorder) or

not.

Boolean 0:1


This property

indicates

whether an

individual has

wireless

internet accessor not.

Boolean 0:1

hasVideoConferenceSystem Boolean 0:1

hasScreen Boolean 0:1

hasSlideProjector Boolean 0:1

hasStage Boolean 0:1

litByNaturalDaylight Boolean 0:1

hasFlipChart Boolean 0:1

hasLectern Boolean 0:1

hasAudioEquipment Boolean 0:1

hasVideoProjector Boolean 0:1

4.9.2 Class Guestroom


Room

Direct Instances:

1. HotelMartheGuestroom32. HotelMartheGuestroom23. ZurLindeGuestroom14. HotelStubaierhofGuestroom35. HotelStubaierhofGuestroom46. AlpenhotelGuestroom17. AlpenhotelGuestroom28. PensionPaulaGuestroom49. LizumerhofGuestroom1

10.PensionPaulaGuestroom311.PensionPaulaGuestroom112.PensionPaulaGuestroom2


32/38

32

13.HotelAngelikaGuestroom14.PenzGuestroom15.HotelKlosterbraeuGuestroom316.HotelKlosterbraeuGuestroom217.HotelKlosterbraeuGuestroom1

18.SporthotelIglsGuestroom19.HotelCentralGuestroom120.HotelWeissesKreuzGuestroom421.HotelWeissesKreuzGuestroom322.HotelDollilngerGuestroom323.JugendherbergeGuestroom224.JugendherbergeGuestroom325.HotelKoegeleGuestroom226.HotelKoegeleGuestroom127.HotelWeissesKreuzGuestroom128.HotelWeissesKreuzGuestroom2

29.HiltonInnsbruckGuestroom130.HotelCentralGuestroom231.PensionGlungezerGuestroom132.ParkhotelHallGuestroom33.PensionTulferhofGuestroom134.HotelStubaierhofGuestroom735.HotelStubaierhofGuestroom836.ZurLindeGuestroom337.ZurLindeGuestroom238.LizumerhofGuestroom339.LizumerhofGuestroom240.HotelMartheGuestroom141.PensionGlungezerGuestroom342.PensionGlungezerGuestroom243.HiltonInnsbruckGuestroom344.HiltonInnsbruckGuestroom245.AlpenhotelGuestroom346.HotelStubaierhofGuestroom547.HotelStubaierhofGuestroom648.HotelStubaierhofGuestroom149.HotelStubaierhofGuestroom2

50.JugendherbergeGuestroom151.JugendherbergeGuestroom452.ZurLindeGuestroom453.PensionBoeckenhofGuestroom154.PensionBoeckenhofGuestroom255.HotelDollingerGuestroom156.HotelDollingerGuestroom2

Direct Subclasses:

None


This class represents the concept of guestrooms.


33/38

33

Template Slots



hasName

This property

indicates the

name of an

individual.

String 0:1

hasTelephone

This property

indicates

whether an

individual has a

telephone or

not.

Boolean 0:1

hasTVSet

This property

indicates

whether an

individual has a

TV set or not.

Boolean 0:1

hasArea

This property

indicates an

individual's area

in square

metres.

Float 0:1


This property

indicates

whether an

individual has

wired internet

access or not.

Boolean 0:1

hasAirCondition

This property

indicates

whether an

individual has

air condition or

not.

Boolean 0:1

hasFaxMachine

This property

indicates

whether an

individual has a

fax machine or

not.

Boolean 0:1

smokingAllowed

This property

indicates

whether

smoking is

Boolean 0:1


34/38

34

allowed or not.

hasVCR

This property

indicates

whether an

individual has aVCR (Video

Cassette

Recorder) or

not.

Boolean 0:1


This property

indicates

whether an

individual has

wireless internet

access or not.

Boolean 0:1

hasDoubleSizeBed

This property

indicates

whether an

individual

offers a room

with a double-

size bed.

Boolean 0:1

hasShower

This property

indicates

whether an

individual has a

shower or not.

Boolean 0:1

hasType

This property

indicates the

type of an

individual.

String 0:1

hasView

This property

indicates which

view somebody

has from an

individual.

String 0:1

hasBalcony

This property

indicates

whether an

individual has a

balcony or not.

Boolean 0:1

hasHairDryer

This property

indicates

whether an

individual has ahair-dryer or

not.

Boolean 0:1


35/38

35

hasAlarmClock

This property

indicates

whether an

individual has

an alarm clock

or not.

Boolean 0:1

hasSafe

This property

indicates

whether an

individual has a

safe or not.

Boolean 0:1

hasOneSizeBed

This property

indicates

whether an

individual

offers a roomwith a one-size

bed.

Boolean 0:1

hasMinibar

This property

indicates

whether an

individual has a

minibar or not.

Boolean 0:1

hasTeaCoffeeEquipment

This property

indicates

whether an

individual has a

tea and coffee

equipment or

not.

Boolean 0:1

hasQueenSizeBed

This property

indicates

whether an

individual

offers a room

with a queen-size bed.

Boolean 0:1

hasKingSizeBed

This property

indicates

whether an

individual

offers a room

with a king-size

bed.

Boolean 0:1

hasBathTub

This property

indicateswhether an

individual has a

Boolean 0:1


36/38

36

bath tub or not.

hasTwinSizeBed

This property

indicates

whether an

individualoffers a room

with a twin-size

bed.

Boolean 0:1

hasTerrace

This property

indicates

whether an

individual has a

terrace or not.

Boolean 0:1

4.10 Class TicketConcrete Class Extends

owl:Thing

Direct Instances:

1. RidingStableSeefeldTicket12. SeegrubeTicket23. PatscherkofelTicket24. PatscherkofelTicket1

5. IceRinkInnsbruckTicket26. IceRinkSeefeldTicket17. IceRinkSeefeldTicket28. IceRinkHallTicket29. IceRinkHallTicket110.IceRinkInnsbruckTicket111.RosshuetteTicket312.RosshuetteTicket213.RosshuetteTicket114.Schlick2000TIcket115.Schlick2000Ticket2

16.Schlick2000Ticket317.StubaierGletscherTicket118.StubaierGletscherTicket219.StubaierGletscherTicket320.SattelbergTicket121.SattelbergTicket322.SattelbergTicket223.ElferLifteTicket224.ElferLifteTicket325.ElferLifteTicket126.PatscherkofelTicket3

27.GlungezerBahnTicket328.GlungezerBahnTicket129.GlungezerBahnTicket2


37/38

37

30.AxamerLizumTicket331.AxamerLizumTicket232.AxamerLizumTicket133.IndoorSwimmingPoolAxamsTicket234.HochserlesTicket2

35.HochserlesTicket336.HochserlesTicket137.TennisSeefeldTicket38.IndoorSwimmingPoolAxamsTicket139.IndoorSwimmingPoolSeefeldTicket140.IndoorSwimmingPoolSeefeldTicket241.SeegrubeTicket142.RidingStableSeefeldTicket2

Direct Subclasses:

None


This class represents the ticket that has to be bought to consume a product or service

with costs. It enables the distinction between various price categories, such as kids,

adults and seniors.

Template Slots


Values/Classes

Cardinality Default

hasName


the name of an

individual.

String 0:1

hasPrice


the price of an

individual in Euros.

Float 0:1

5. Future WorkAs mentioned above we first want to consider other existing etourism ontologies, for instance

the Harmonise Ontology. We think that this ontology would cover our needs most. Further we

want to redesign the ontology, i.e. splitting up some concepts or creating more subslots. We

also want to include more logics, for what we have choosen OWL-DL, because at the

moment we only use the inverseOf function. The biggest step of our future work is the

distribution of the information in our architecture, as discussed in section 3. Every provider of

information (owner of an accommodation, etc.) has to annotate the information he wants to

give on his own. For this there will be needed an Annotation Editor.


38/38

6. Related Work

There are already other ontologies concerning the etourism sector. For example the

Harmonise Ontology [2] and the Thesaurus of WTO, which were already discussed in section

2.2. Another tourism ontology is that one from Mondeca1 [4] or the Itinerary-Ontology2 [4]

which is specialized on travelling.

7. Conclusion

With the project OnTour we showed that it makes sense to use an ontology and other new

technologies in the area of etourism. With an ontology it becomes easier to structure

information and provide it for search. In the end the user will profit, because he gets concrete

and best results when searching. We also saw that for the realization we need the semantic

web and that OnTour has still many weaknesses. Another aspect which became clear is that

it is benefiting reusing existing ontologies.

8. References

[1] Fensel, D; Ontologies: A Silver Bullet for Knowledge Management and Electronic

Commerce; Second Edition; 2004;

[2] Harmonise Ontology http://www.harmo-ten.info

[3] Prog 3.0 http://protege.stanford.edu

[4] Daniel Bachlechner; Ontology Collection in view of an Etourism Portal; October 2004;

ontour gooddesignpartdoc

Documents