ontour gooddesignpartdoc
TRANSCRIPT
-
8/3/2019 OnTour goodDesignpartdoc
1/38
1
OnTour
The Ontology
Kathrin Prantner
DERI Innsbruck
www.deri.org
-
8/3/2019 OnTour goodDesignpartdoc
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.
-
8/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
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.
-
8/3/2019 OnTour goodDesignpartdoc
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:
-
8/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
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/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
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:*
-
8/3/2019 OnTour goodDesignpartdoc
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:*
-
8/3/2019 OnTour goodDesignpartdoc
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
This propertyindicates whether
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
This propertyindicates whether
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
-
8/3/2019 OnTour goodDesignpartdoc
15/38
15
offers a shuttle
service or not.
4.2 Class Activity
Concrete Class Extends
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
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
hasName
This property indicates
the name of an
individual.
String 0:1
hasType
This property indicates
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
-
8/3/2019 OnTour goodDesignpartdoc
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
Class Documentation:
This class represents an individual's contact data.
-
8/3/2019 OnTour goodDesignpartdoc
17/38
17
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
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
-
8/3/2019 OnTour goodDesignpartdoc
18/38
18
Concrete Class Extends
DateTime
Direct Instances:
1. Skiingresort1OH2. HollywoodbowlingOH
Direct Subclasses:None
Class Documentation:This class is a concrete representation of the concept of an individual's opening hours.
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
hasSeason
This property links an
individual representing
a season.
Instance DatePeriod 0:*
hasWeekdayThis property indicates a
weekday. Symbol
Monday,
Tuesday,
Wednesday,
Thrusday,Friday,
Saturday,
Sunday
0:*
hasTimePeriod
This property links an
individual representing
a date period.
Instance TimePeriod 0:*
4.4.2 Class Period
1. Class Date Period
Concrete Class Extends
Period
Direct Instances:
1. SkiingResortDP2. PatscherkofelDP
Direct Subclasses:
None
Class Documentation:
-
8/3/2019 OnTour goodDesignpartdoc
19/38
19
This class represents the concept of date periods.
Template Slots
Slot name Documentation TypeAllowed
Values/Classes Cardinality Default
hasEndDate
This property indicates
the date when a date
period ends (2004-11-
19).
String 0:1
hasStartDate
This property indicates
the date when a date
period starts (2004-11-
19).
String 0:1
2. Time Period
Concrete Class Extends
Period
Direct Instances:
BowlinghallTP
Direct Subclasses:
None
Class Documentation:This class represents the concept of time periods.
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
hasStartTime
This property indicates
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
-
8/3/2019 OnTour goodDesignpartdoc
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
Concrete Class Extends
DateTime
Direct Instances:PatscherkofelSeason
Direct Subclasses:
None
Class Documentation:
This class is a concrete representation of the concept of seasons.
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
hasName
This property indicates
the name of an
individual.
String 0:1
hasDatePeriod
This property links an
individual representing
a time period.
Instance DatePeriod 0:*
4.5 Class Event
Concrete Class Extends
owl:Thing
Direct Instances:
None
Direct Subclasses:None
Class Documentation:This class is a concrete representation of the concept of events.
-
8/3/2019 OnTour goodDesignpartdoc
21/38
21
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
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.
Instance PostalAddress 0:1
hasGPSCoordinates
This property links
an individual
representing another
individual's GPScoordinates.
Instance GPSCoordinates 0:1
hasContactData
This property links
an individual
representing another
individual's contact
data.
Instance ContactData 0:1
hasTimePeriond
This property links
an individual
representing a date
period.
Instance TimePeriod 0:*
4.6 Class Infrastructure
Concrete Class Extends
owl:Thing
Direct Instances:
1. IceRinkInnsbruck2. IceRinkSeefeld
3. IceRinkHall4. SkiingresortNordpark5. SkiingresortAxamerLizum
-
8/3/2019 OnTour goodDesignpartdoc
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
Class Documentation:
This class is a concrete representation of the concept of infrastructure.
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
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
Instance PostalAddress 0:1
-
8/3/2019 OnTour goodDesignpartdoc
23/38
23
individual's
postal address.
hasGPSCoordinates
This property
links an
individualrepresenting
another
individual's
GPS
coordinates.
Instance GPSCoordinates 0:1
hasContactData
This property
links an
individual
representing
another
individual'scontact data.
Instance ContactData 0:1
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
Concrete Class Extends
owl:Thing
Direct Instances:
1. Italian2. Arabian3. English4. German5. French6. Spanish7. Maltese
Direct Subclasses:
None
-
8/3/2019 OnTour goodDesignpartdoc
24/38
24
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
hasName
This property indicates
the name of an
individual.
String 0:1
4.8 Class Location
Concrete Class Extends
owl:Thing
Direct Instances:
None
Direct Subclasses:
1. GPSCoordinates2. PostalAddress
Class Documentation:
This class represents different ways for describing the geographical location of an
entity.
4.8.1 Class GPS Coordinates
Concrete Class Extends
Location
Direct Instances:
1. HotelKlosterbraeuGPS2. IceRinkSeefeldGPS3. ZurLindeGPS
4. PensionPaulaGPS5. RosshuetteGPS6. NordparkGPS7. IceRinkInnsbruckGPS8. IceRinkHallGPS9. Schlick2000GPS10.StubaierGletscherGPS11.SattelbergbahnGPS12.ElferLifteGPS13.PatscherkofelGPS14.HochserlesGPS
15.GlungezerBahnGPS16.AxamerLizumGPS17.AlpenhotelLammGPS
-
8/3/2019 OnTour goodDesignpartdoc
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
Class Documentation:
This class represents the GPS coordinates of an entity using the WGS 84 (World
Geodetic System 1984) as global reference frame.
Template Slots
Slot name Documentation TypeAllowed
Values/Classes
Cardinality Default
hasLatitude
This property indicates
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
This property indicates
the longitude of anindividual in degrees
and is part of its GPS
String 0:1
-
8/3/2019 OnTour goodDesignpartdoc
26/38
26
coordinates. The WGS
84 (World Geodetic
System 1984) is used as
global reference frame.
4.8.2 Class Postal Adress
Concrete Class Extends
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
-
8/3/2019 OnTour goodDesignpartdoc
27/38
27
39.HotelDollingerPA40.HotelKoegelePA41.ZurLindePA42.AxamerLizumPA
Direct Subclasses:None
Class Documentation:
This class represents the postal address of an entity.
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
hasHouseNumber
This property indicates
the house number of the
building where an
individual is located and
is part of its postal
address.
String 0:1
hasCountry
This property indicates
the country where an
individual is located and
is part of its postal
address.
String 0:1
hasCity
This property indicates
the city where an
individual is located and
is part of its postal
address.
String 0:1
hasPostalCode
This property indicates
the postal code of the
area where an individual
is located and is part ofits postal address.
String 0:1
hasStreet
This property indicates
the street where an
individual is located and
is part of its postal
address.
String 0:1
4.9 Class Room
Concrete Class Extends
owl:Thing
Direct Instances:
-
8/3/2019 OnTour goodDesignpartdoc
28/38
28
None
Direct Subclasses:
1. ConferenceRoom
2. Guestroom
Class Documentation:
This class is a concrete representation of the concept of rooms.
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality Default
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
-
8/3/2019 OnTour goodDesignpartdoc
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
Concrete Class Extends
Room
Direct Instances:
1. HiltonInnsbruckConferenceroom2. LizumerhofConferenceRoom3. PenzConferenceRoom4. HotelKlosterbraeuConferenceRoom5
5. HotelKlosterbraeuConferenceRoom26. HotelKlosterbraeuConferenceRoom67. HotelKlosterbraeuConferenceRoom38. HotelKlosterbraeuConferenceRoom49. HotelKlosterbraeuConferenceRoom110.ParkhotelHallConferenceRoom11.JugendherbergeConferenceRoom12.AlpenhotelLammConferenceRoom
Direct Subclasses:
None
Class Documentation:
-
8/3/2019 OnTour goodDesignpartdoc
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
hasWiredInternetAccess
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
-
8/3/2019 OnTour goodDesignpartdoc
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
hasWirelessInternetAccess
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
Concrete Class Extends
Room
Direct Instances:
1. HotelMartheGuestroom32. HotelMartheGuestroom23. ZurLindeGuestroom14. HotelStubaierhofGuestroom35. HotelStubaierhofGuestroom46. AlpenhotelGuestroom17. AlpenhotelGuestroom28. PensionPaulaGuestroom49. LizumerhofGuestroom1
10.PensionPaulaGuestroom311.PensionPaulaGuestroom112.PensionPaulaGuestroom2
-
8/3/2019 OnTour goodDesignpartdoc
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
Class Documentation:
This class represents the concept of guestrooms.
-
8/3/2019 OnTour goodDesignpartdoc
33/38
33
Template Slots
Slot name Documentation TypeAllowed
Values/ClassesCardinality 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
hasWiredInternetAccess
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
-
8/3/2019 OnTour goodDesignpartdoc
34/38
34
allowed or not.
hasVCR
This property
indicates
whether an
individual has aVCR (Video
Cassette
Recorder) or
not.
Boolean 0:1
hasWirelessInternetAccess
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
-
8/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
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
-
8/3/2019 OnTour goodDesignpartdoc
37/38
37
30.AxamerLizumTicket331.AxamerLizumTicket232.AxamerLizumTicket133.IndoorSwimmingPoolAxamsTicket234.HochserlesTicket2
35.HochserlesTicket336.HochserlesTicket137.TennisSeefeldTicket38.IndoorSwimmingPoolAxamsTicket139.IndoorSwimmingPoolSeefeldTicket140.IndoorSwimmingPoolSeefeldTicket241.SeegrubeTicket142.RidingStableSeefeldTicket2
Direct Subclasses:
None
Class Documentation:
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
Slot name Documentation TypeAllowed
Values/Classes
Cardinality Default
hasName
This property indicates
the name of an
individual.
String 0:1
hasPrice
This property indicates
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.
-
8/3/2019 OnTour goodDesignpartdoc
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;