De
eliver
rable
le # 2
K
Knowle
edge-E
Engineeering Metho
M odologyy to
“S
Semanticc Web Baased Traiin Tickett Reservaation System”
Subm
mitted To::
Madam
m Amna B
Basharat Haider
(Instruuctor SWT)
Subm
mitted By::
Ghazanffar Latif
R
Roll No: 0
06‐0384
Section A
Blogg Address::
http:///semain
no.blogspot.com
m/
Natio
onal Univers
U sity off Comp
puter &
Em
merginng Scie
ences Islama
I abad
Semantic Web Based Train Ticket Reservation System
Knowledge-Engineering Methodology:
Step1. Domain and scope of the ontology:
We suggest starting the development of ontology by defining its domain and scope
which is, answer several basic related questions.
For what we are going to use the ontology?
What is the domain that the ontology will cover?
Who will use and maintain the ontology?
The answers to these questions may change during the ontology-design process, but
at any given time they help limit the scope of the model.
Let consider the ontology of traveling and train. Representation of traveling and train
is the domain of the ontology. We plan to use this ontology for the applications that
suggest good combinations of train and traveling.
In the traveling and train domain, the following are the possible competency
questions:
What are the routes of the train that choose?
How much time it take from source to destination?
If complete one train route not found from source to destination then how to
use two trains to reach exact destination?
What type of compartment classes this train has?
What is the best choice class for ticket reservation?
If the ontology we are designing will be used to assist in natural language processing
of articles in travelling related magazines, it may be important to include synonyms
and part-of-speech information for concepts in the ontology. If the ontology will be
used to help permanent travelers decide which type of seat class or train compartment
will better for him, we need to include its pricing information along with tax. If the
people who will maintain the ontology describe the domain in a language that is
different from the language of the ontology users, we may need to provide the
mapping between the languages.
Step2. Reusing existing ontologies:
It is almost always worth considering what someone else has done and checking, if
we can refine and extend existing sources for our particular domain and task. Reusing
existing ontologies may be a requirement if our system needs to interact with other
applications that have already committed to particular ontologies or controlled
vocabularies. Many of the ontologies are already available in electronic form and can
be imported into an ontology-development environment that we are using. There are
libraries of reusable ontologies on the Web and in the literature. There are libraries of
reusable ontologies on the Web and in the literature.
For example, the train ticket reservation process ontologies are exists and
now we want to make airline ticket reservation system. Then we can refine
and perform slight changes on to the existing ontologies and make new
system which internally works nearly the same way as the train ticket
reservation system.
Similarly, a knowledge base of electric city train may already exist. If we can
import this knowledge base and the ontology on which it is based, we will
have not only the classification of electric city train but also the first pass at
the classification of trains characteristics used t o distinguish and describe the
trains.
Step3. Enumerating important terms in the ontology:
It is useful to write down a list of all terms we would like either to make statements
about or to explain to a user.
What are the terms we would like to talk about?
What properties do those terms have?
What would we like to say about those terms?
For example, important train-related terms will includes:
Trains
Train type
Train apartments
Roots
Fare
Tax
Classes’ condition and so on
Step4. Definition of classes and the class hierarchy:
Developing the class hierarchy and defining properties of concepts are closely
intertwined. Typically, we create a few definitions of the concepts in the hierarchy
and then continue by describing properties of these concepts and so on. These two
steps are also the most important steps in the ontology-design process.
When we define the class hierarchy of Train ticket reservation there are several possible
approaches of development process for example:
A top-down development process starts with the definition of the most
general concepts in the domain and subsequent specialization of the concepts.
For example, we can start with creating classes for the general concepts of
trains and traveling. Then we specialize the train class by creating some of its
subclasses: electric city trains, coil engine trains, oil engine trains. We can
further categorize them in to subclasses.
A bottom-up development process starts with the definition of the most
specific classes, the leaves of the hierarchy, with subsequent grouping of these
classes into more general concepts. For example, we start by defining classes
for new modeled high speed electric city trains and old electric city based
trains. We then create a common super class for these two classes’ electric
city trains which in turn is a subclass of trains.
A combination development process is a combination of the top-down and
bottom up approaches: We define the more salient concepts first and then
generalize and specialize them appropriately. We might start with a few top-
level concepts such as trains, and a few specific concepts, such as new high
speed E.C Trains. We can then relate them to a middle-level concept, such as
electric city trains.
Step5. Defining of properties of classes—slots:
The classes alone will not provide enough information to answer the competency
questions from Step 1. Once we have defined some of the classes, we must describe
the internal structure of concepts. We have already selected classes from the list of
terms we created in Step 3. Most of the remaining terms are likely to be properties of
these classes. These terms include, for example:
Train apartments
Train classes
Speed
Fare details etc.
All subclasses of a class inherit the slot of that class and a slot should be
attached at the most general class that can have that property.
Step6. Defining the facets of the slots:
Slots can have different facets describing the value type, allowed values, the number
of the values (cardinality), and other features of the values the slot can take.
For example, the value of a name slot (as in “the name of a train”) is one string. That
is, name is a slot with value type String. A slot produces, can have multiple values
and the values are instances of the class train. That is, produces is a slot with value
type Instance with train as allowed class. Allowed classes for slots of type Instance
are often called a range of a slot and the classes to which a slot is attached or classes
which property a slot describes are called the domain of the slot. Common value
types contain String, Number, Boolean, Enumerated, Instance.
Step7. Creating Instances:
The last step is creating individual instances of classes in the hierarchy. Defining an
individual instance of a class requires (1) choosing a class, (2) creating an individual
instance of that class, and (3) filling in the slot values.
Conceptual Model:
Traveler Visits
POTRS Site
To Register
Booking Signup
Traveler Agent communicate Fill Out
Website Agent
Registration Form
Perform (Actually to make
Personal Software Agent)
Check
Seat Cancelation
Check Reserved
Trains
Ticket Info
Check Available
Fares
Check Out
Payment by Seats
Class
Credit Card
Validity
Process Complete
Cut Off
Payment Ticket Reserved
Process Complete Congratulation
Ready to
Print
Domain Model:
RDF Graph:
cd RDF Graph
Trav eller
can view TrainNames
LoginName Admin
make can view moves to
goes to
reruire TravellerName
TrainTiming
check
Address TrainDetails moves to
Register add
initiate
add
reruires
CreditCard_ID
add
reruires moves to
moves to
Password
Trav elerDetails add moves to
Gender TrainSpeed
UserName
add
get info from TrainRoot
add
Date SeatPrefreance
enter
Reserv ation SeatClassPrefrance
Source
enter
enter
moves to
Destination
pay ticket fare P_Details get nfo from
Payment
done by
check
CreditCard Balance
validity check
through
TicketAmount
Payment_A_S
deduce
perform
FareDeduction
genreate
deduce
Tax
Reser_Slip
