wafflebazaarInternet and Web Development

Oct 21, 2013 (4 years and 8 months ago)




Sucharee Sanghan



A Thesis Presented


Sucharee Sanghan

Master of Science in Information Technology
School of Technology
Shinawatra University

June 2007

Copyright of Shinawatra University


I am indebted to my advisor, Assistant Professor Dr. Chutiporn Anutariya, for
giving me the knowledge to encourage me to pursue my own interests and for her
suggestion which inspired my thoughts to complete this thesis. Moreover, I am
grateful for encouragement, help and friendship. I also thank Associate Professor Dr.
Ekawit Nantajeewarawat and Dr. Maruf Hasan for their valuable comments,
suggestions and time.
I would like to express my sincerest thanks to all my friends for their
continuing support throughout the year. Special thanks go to MSIT staffs for
supporting and arranging very good facilities for our weekly meeting during the thesis
Finally, I would like to thank my family for the motivation and inspiration when
I feel disappointed.


Due to the dramatic growth and popularity as well as the advancement in the
development of content delivery technologies of the Internet, e-learning has also
gained its momentum by providing a richer and more engaging educational
experience to learners. Moreover, it additionally reduces the need for spatial or
temporal proximity in the education process. Therefore, many academic institutes
including higher education, corporate training, and continuing and professional
education have enhanced their services by offering e-learning courses, certificates or
diplomas. However, the structural model of these e-learning services can be
significantly complicated, and thus demanding a learner to carefully make his/her
dynamic and adaptive course plan according to his/her background, preferences and
constraints, in order to fulfill a particular e-learning program/certificate’s
By means of ontology and Semantic Web service technologies, this thesis
proposes an approach to model the e-learning service planning problem by taking into
account these significant matters. In particular, it models an e-learning certificate
offered by a certain institute as a Semantic Web service with the certificate’s structure
and requirements modeled as a service composition problem. Similarly, an e-learning
course is also modeled as a Semantic Web service. Moreover, the approach develops
an ontology describing various important characteristics of a course (e.g.,
prerequisites, equivalent courses), a certificate as well as a learner’s profile (e.g.,
preferences, constraints, passed courses). Based on this modeling methodology, the
proposed approach can therefore suggest appropriate course plans dynamically and
adaptively based on a learner’s profile, available e-learning services offered at that
moment, and course conditions. In addition, since more than one plan can be
generated, they will be ranked according to the learner’s predefined criteria.

Keywords: E-learning, Ontology, OWL
OWL-S, Semantic Web Service, Service composition
Service planning

Table of Contents

Title Page

Acknowledgments i
Abstract ii
Table of Contents iii
List of Figures vi
List of Tables viii

Chapter 1 Introduction 1
1.1 Research Background 1
1.2 Statement of Problems 1
1.3 Research Objective 2
1.4 Scope of Research 2
1.5 Thesis Organization 2

Chapter 2 Literature Review 3
2.1 Semantic Web: Technologies and Standards 3
2.1.1 What is Semantic Web? 3
2.1.2 RDF 4
2.1.3 OWL: Web Ontology Language 5
2.1.4 Semantic Web inference engines 8
2.2 Semantic Web Services (SWS): Technologies and Standards 14
2.2.1 Why SWS? 14
2.2.2 OWL-S 15
2.2.3 WSMO 22
2.2.4 Semantic Web services discovery and composition 25
2.3 Adaptive and Personalized E-learning 26

Chapter 3 E-Learning Service Planning Framework 28
3.1 Ontology Model Overview 28
3.2 Modeling E-learning Certificate 29
3.3 Modeling Course Service and Service Category 31

3.3.1 Course service 32
3.3.2 Service: ServiceCategory 38
3.4 Modeling Student Profile 38
3.5 Ontology Model: Detail View 41
3.6 Matchmaking 41
3.7 Planning Algorithm 42

Chapter 4 System Implementation 45
4.1 Hardware Components 45
4.2 System Components and Their Technology 46
4.2.1 GUI component (Graphic User Interface) 46
4.2.2 Course planner component 46
4.2.3 OWL/ OWL-S data component 46
4.3 System Workflow 47
4.4 Test Scenario 49
4.4.1 Transferable course 49
4.4.2 Equivalent course 50
4.4.3 Pre-requisite course 51
4.4.4 User constraint 53
4.4.5 User preference 55

Chapter 5 Applications of the Proposed Approach 58
5.1 Possible Application 58
5.2 Case Study: Modeling CS Curriculum of Shinawatra University 58
5.2.1 System administration 59
5.2.2 Recommended course plan for students 61
5.2.3 Discussion 65

Chapter 6 Conclusions and Future Work 66
6.1 Conclusions 66
6.2 Future Work 66

References 68

Biography 71

List of Figures

Title Page

Figure 2.1 Structure of the Inference Machinery of Jena2 12
Figure 2.2 OWL-S Upper Ontology 15
Figure 2.3 Selected Classes and Properties of the Profile 16
Figure 2.4 Top Level of Process Ontology 20
Figure 3.1 Proposed Ontology Model 28
Figure 3.2 Hierarchy Level of OWL-S Based E-Learning Service Composition 30
Figure 3.3 An Example of Software Engineer Certificate Modeled by OWL-S 31
Figure 3.4 OWL-S Based to Represent Course Service 33
Figure 3.5 OWL-S Schema to Model Precondition and Effect 35
Figure 3.6 Knowledge Class and Its Instances 36
Figure 3.7 An Example of Course 37
Figure 3.8 Course Category Based on ACM Computing Classification 38
Figure 3.9 The Class Representation of E-Learning Service in OWL 41
Figure 3.10 Overview Diagram for Matchmaking of Course Service 42
Figure 4.1 System Architecture 45
Figure 4.2 System Components of E-Learning Service Planning 47
Figure 4.3 Test Scenarios for Transferable Course 50
Figure 4.4 Test Scenarios for Equivalent Course Property 51
Figure 4.5 Test Scenarios for Pre-Requisite Course 52
Figure 4.6 The Result from the System of First User 52
Figure 4.7 The Result from the System of Second User 53
Figure 4.8 The Result of Learner Having Constraint=4 before Checking
Number of Required Course in Each Category 54
Figure 4.9 The Final Suggested Courses List of Learner Having Constraint = 4 54
Figure 4.10 The Final Suggested Courses List of Learner Having Constraint = 3 55
Figure 4.11 The Suggested Course Plan of The First Learner Having
Information System as Preference 56
Figure 4.12 The Suggested Course Plan of The Second Learner Having
Software as Preference 56

Figure 4.13 The Learner’s Preference and Its Subcategories Using for Reasoning 57
Figure 5.1 The Interface for Adding the New Curriculum 59
Figure 5.2 The Interface for Adding the New Course 60
Figure 5.3 The Interface for Adding the New Student 60
Figure 5.4 The Interface for Adding the Course to Available Service 61
Figure 5.5 Student Menu 62
Figure 5.6 Student Profile Screen 62
Figure 5.7 Certificate Structure Screen 63
Figure 5.8 Available Courses Screen 64
Figure 5.9 Offered Certificate Screen 64
Figure 5.10 Course Plan Result 65

List of Tables

Title Page

Table 2 The Constructs Supports in Jena2 11
Table 3.1 The OWL and OWL-S Properties of Course Service 32
Table 3.2 The OWL Properties of Relationship of Course Service 34
Table 3.3 The OWL Properties of Relationship of Knowledge Class 36
Table 3.4 The OWL Property of Student Profile 39

Chapter 1

1.1 Research Background
Due to the dramatic growth and popularity as well as the advancement in the
development of content delivery technologies of the Internet, e-learning has also
gained momentum by providing a richer and more engaging educational experience
to learners. Moreover, it additionally reduces the need for spatial or temporal
proximity in the education process. Therefore, many academic institutes including
higher education, corporate training, and continuing and professional education have
enhanced their services by offering e-learning courses, certificates or diplomas.
However, the structural model of these e-learning services can be significantly
complicated due to the constraint of the course such as pre-requisite knowledge,
available course and learner’s background.
As a result, we believe that if there is a system that is able to construct the
structure model of e-learning services and provide course planning for the learner
based on important criteria, this will help to increase the popularity and usage of e-
learning and help the learner to achieve their goal more easily.

1.2 Statement of Problems
With current e-learning services available on the Web, the learners can benefit
from this content to learn new knowledge and courses. However, when they register
on a specific course, they might not know whether their knowledge is enough to learn
that course. They might need to register for another course before taking this course.
Some learners might get lost with a lot of e-learning services on the Web. Moreover,
to satisfy one certificate or degree, there are course paths to be learnt in order to
achieve one certificate. Mostly, to have the learners make the course plan themselves,
it will be very complicated for them to choose the correct course based on the number
of constraints involved in fulfilling a particular e-learning certificate’s requirements.
As a result, e-learning services provided on the Web will be very useful to the
learner, if it can provide the user with a course structure and learning path to achieve
a certificate and provide advice about the courses to learners so that they can register
based on their profiles/ preferences/ constraints and the available services at that time
as well as the course requirements (pre-requisite course or equivalent course).

1.3 Research Objective
The objective of this research is to propose an approach to the e-learning
service planning problem by taking into account the significant matters. In particular,
it models an e-learning certificate offered by a certain institute as a Semantic Web
services with the certificate’s structure and requirements modeled as a Semantic Web
service. Moreover, the approach develops an ontology describing various important
characteristics of the course (e.g., prerequisites, equivalent courses), a certificate as
well as a learner’s profile (e.g., preferences, constraints, passed courses). Based on
this modeling methodology, the proposed approach can therefore suggest appropriate
course plans dynamically and adaptively based on a learner’s profile, available e-
learning services offered at that moment, and course conditions.

1.4 Scope of Research
Our research will develop the system to meet all requirements described in
section 1.3. The framework of the system will be developed by using OWL and
OWL-S. However, our system will not cover the e-learning course content
management. Our scope of implementation will only suggest the course plan for each
learner based on his/her profile and other constraints.

1.5 Thesis Organization
This research paper is organized as follows. Chapter 2 includes the literature
review and some of background knowledge and technologies used in this research as
well as related work. In Chapter 3, we will show the model of our ontology and how
to apply a standard semantic Web Services specification, OWL-S, to model the
course organization as well as the planning algorithm for course registration planning
for each learner. In the following Chapter, the implementation and system
architecture will be discussed and test scenarios will also be shown. Finally, the last
Chapter will conclude this research and recommend future work.

Chapter 2
Literature Review

2.1 Semantic Web: Technologies and Standards
2.1.1 What is Semantic Web?
The Semantic Web (Hendler, Berners-Lee, & Miller, 2002) is current Web
adding with the extension in which information is given well-defined meaning. This
defined meaning will help computer not just people to understand and be able to
process the information on the Web. Thus, it enables computers and people to better
work in cooperation. The idea is to link and define data on the Web so that it can be
used for more effective discovery, automation, integration, and reuse across various
applications. In order to reach its full potential for the Web, it must adapt into this
Semantic Web, providing a universally accessible platform. This will allow data to be
shared and processed by automated tools in the same way as by people.
Not only Web pages, The Semantic Web will also provide an infrastructure
that enables databases, services, programs, sensors, personal devices, and even
household appliances to both consume and produce data on the web. This information
can be used to search, filter and prepare information in new and useful ways to assist
the web user by software agents. These new languages make significantly more of the
information on the web machine-readable and understandable and will enable the
development and emergence of a new generation of technologies and toolkits.
Nowadays, there are many researches focusing on applying the Semantic Web
technology into practical applications. Fensel et al. (2002) reviewed and collected the
information in Semantic Web applications areas. Knowledge Management is also one
of the area in which Semantic Web is applied. The existing problems with traditional
knowledge management are information overload, inefficient keyword searching,
heterogeneous information integration and geographically-distributed intranet
problems (Fensel et al., 2002). The Ontoknowledge (OTK) project (Fensel et al.,
2000) is an important project devoting itself to finding content-driven knowledge
management solutions through evolving ontologies. It employs the power of the
Semantic Web technology to facilitate knowledge management and provide a tool
environment powered by Semantic Web technology which focuses on acquiring,
maintaining and accessing weakly structured information sources. Moreover,
Ontology Mappings: Integrating Business Documents (Fensel, 2002) is also another

interesting application using Semantic Web technology. Omelayenko and Fensel
(2001) assumes that XML documents might first be ‘lifted up’ to their RDF data
models (the process known in the Semantic Web area as document annotation). Then
different private RDF data models are mapped to the shared mediating data model
enriched with different constraints and formal specification of shared semantics of the
concepts. An RDF mapping technology RDFT is now being developed to represent,
reuse and execute these mappings (Omelayenko, Fensel, & Bussler, 2002).
Specifically, RDFT provides integration architecture, a mapping meta-ontology that
specifies the mapping constructs called bridges, and the technology for map
interpretation and translation to XSLT. There are still so many applications using the
powerful benefits of Semantic Web such as e-commerce, content standard, Web
service and so on. Next section will show the language and specification used for
Semantic Web implementation.

2.1.2 RDF.
The Resource Description Framework (RDF) (Brickley & Guha, 1999) is a
W3C standard. It is used to describe the resources on the Web, such as the title,
author, modification date, content, and copyright information of a Web page.
RDF is a framework used to describe the resources on the Web, and it has
standard syntax and data model. Thus, independent parties can exchange and use it.
Moreover, RDF is designed to be read and understood by computers, not designed for
being displayed to people. Thus, it is machine readable. XML syntax is used to write
RDF and now RDF is also a part of the W3C's Semantic Web Activity
Web identifiers (URIs) are used to identify things in RDF, and to describe
resources with properties and property values.

Explanation of Resource, Property, and Property value:
• A Resource is anything that has a URI to represent it, such as
• A Property is a Definition that is used to describe Resource, such as
"title", ”ISBN” or "author"
• A Property value is the value of a Property, such as "Sucharee".

Below is the example of code of the explanation above.

<?xml version="1.0"?>
<Title>The beauty of Thai’s culture</Title>

2.1.3 OWL: Web Ontology Language.
The OWL Web Ontology Language (Web Ontology Working Group, 2003;
2004) is a language used to define and build Web ontologies. Ontology is philosophy
term which is the science of describing the kinds of entities or things in the world and
how they are related to each other. Thus, an OWL ontology is the language that used
to represent an ontology and it may include descriptions of classes, properties and
their instances. By using ontology, the OWL formal semantics specifies how to derive
to find the knowledge or result from the ontology logically. To perform logical
reasoning, we may need single document or multiple distributed documents that have
been combined using defined OWL mechanisms.
An ontology is different from an XML schema because ontology is
knowledge representation using XML, not a message format. Many enterprises use
XML message formats and protocol specifications to exchange electronic data. These
formats have been given an operational semantics, such as, "Upon receipt of this
message, transfer
dollars from
." Nevertheless, the specification is not intended to be used to support
reasoning outside the transaction context.
The advantage of OWL ontologies is that we can use the tools to reason about
them. Tools will provide general functionalities that are not specific to the particular
subject domain, which would be the case if one were to build a system to reason
about a specific industry-standard XML schema.
The OWL language provides three increasingly expressive sublanguages:
• OWL Lite supports those users who need to classify or build the hierarchy
of entities or things with simple constraint feature.

• OWL DL is more expressive than OWL Lite without losing computational
completeness (all entailments are guaranteed to be computed) and
decidability (all computations will finish in finite time) of reasoning
systems. All OWL language constructs with restrictions will be included
in OWL DL such as type separation (a class cannot also be an individual
or property, a property cannot also be an individual or class). DL stands
for description logics, a decidable fragment of first order logic and
amenable to automated reasoning. Thus, OWL DL supports the existing
Description Logic business segment and has computational properties for
reasoning systems.
• OWL Full is the most expressive OWL sub language and it allows user to
have the syntactic freedom of RDF with no computational guarantees. As
a result, it is pretty difficult to perform the reasoning using OWL Full.

When the developers want to build OWL ontology, they should consider
which one is the best suite for their need by determining from the required level of
expressiveness or computational capability. Reasoners for OWL Lite will provide
computational properties, while Reasoners for OWL DL will deal with a decidable
sublanguage, and will be subject to higher worst-case complexity. The requirement of
the user about meta-modeling facilities of RDF Schema (i.e. defining classes of
classes) will determine the choice between OWL DL and OWL Full. When using
OWL Full compared to OWL DL, reasoning capability is less predictable.
Now, we will discuss the basic component of ontology. Most of the elements
of an OWL ontology concern classes, properties, instances of classes, and
relationships between these instances. This section presents the language components
essential to introducing these elements.
• Classes: Classes are the most basic concept of OWL. It will contain the
individual. Class owl:Thing is the biggest class in OWL world as every
individual must be the member of this class. Thus, when user define a
class, it will definitely be the subclass of owl:Thing. You can define
Domain specific root classes by declaring a named class. For example, we
create class Country
<owl:Class rdf:ID="Country"/>

• Individuals: Individuals are the member of the class. From the previous
example, we create class country, so it might have the members which are
US, England, Thailand, and so on belong to this class.

<owl:Class rdf:ID="Country"/>
<Country rdf:ID="US " />
<Country rdf:ID="England " />
<Country rdf:ID="Thailand " />

• Properties: A property is a two-way relation. Two types of properties are
- datatype properties, relations between instances of classes and
RDF literals and XML Schema datatypes
- object properties, relations between instances of two classes. Note
that the name object property is not intended to reflect a
connection with the RDF term rdf:object
The example of object properties

<owl:ObjectProperty rdf:ID="hasName">
<rdfs:domain rdf:resource="#persons" />
<rdfs:range rdf:resource="#name" />

• Property Characteristic: In OWL, we can specify the characteristic for
each property we created. This will make our ontology more powerful
when reasoning.
- Transitive Property: We create one property called Equal having
Transitive property and we have individuals which are A, B and C.
If we set up Equal(A,B) and Equal(B,C), Reasoner will
automatically know that Equal(A,C) holds without building this
relation. This is called Transitive property.
- Symmetric Property: We create property called NearTo having
Symmetric Property. If we set up the relation NearTo(Thailand,
Singapore), Reasoner will automatically know that
NearTo(Singapore, Thailand) holds because of Symmetric

- InverseOf Property: We create property called isChildOf being an
InverseOf property called isParentOf. If we set up isChildOf(A,B),
Reasoner will know that isParentOf(B,A) holds.

2.1.4 Semantic Web inference engines.
1) Pellet OWL reasoner
Pellet (Parsia & Sirin, 2004) is an OWL DL reasoner which is open-source
pure Java implementation. It can be used with both Jena (McBride, 2000) and OWL
API libraries to provide reasoning capability because Jena does not provide reasoning
capability of OWL. Functionalities to see the species validation, check consistency of
ontologies, classify the taxonomy, check entailments and answer a subset of RDQL
queries will be provided by Pellet API. Pellet is an OWL DL reasoner using the
tableaux algorithms developed for expressive Description Logics. It supports the full
expressivity OWL DL including reasoning about nominal classes (enumerated
classes). Currently, Pellet is the first and only complete DL reasoner that can handle
this expressivity.

Some of Pellet Features
• Ontology analysis and repair: OWL has two major types, OWL DL and
OWL Full, with OWL DL being a subset of OWL Full. All OWL
knowledge bases are encoded as RDF/XML graphs. OWL DL imposes a
number of restrictions on RDF graphs, some of which are substantial (e.g.,
that the set of class names and individual names be disjoint) and some less
so (that every item have a rdf:type triple). Ensuring that an RDF/XML
document meets all the restrictions is a relatively difficult task for authors,
and many existing OWL documents are nominally OWL Full, even
though their authors intend for them to be OWL DL. Pellet incorporates a
number of heuristics to detect "DLizable" OWL Full documents "repair"
• Species Validation: It can check the species of OWL whether they are
• Conjunctive ABox query: Query answering is yet another important
feature for Semantic Web. Pellet is Support ABox query answering

module by using "rolling-up'' technique. Pellet has devised algorithms to
optimize the query answering by changing how likely candidates for
variables are found and tried. Exploiting the dependencies between
different variable bindings helps us to reduce the total number of
satisfiability tests thus speeding up the answer significantly.
• Datatype Reasoning: XML Schema has a rich set of basic data types
including various numeric types (integers and floats), strings, and
date/time types. It also has several mechanisms, both standard and unusual
for creating new types out of the base types. For example, it is possible to
define a data type by restricting the integers to the set of integers whose
canonical representation has only 10 digits, or whose string representation
matches a certain regular expression. Currently, XML Schema systems
tend toward validation of documents and generation of PSVI instead of
type checking (though, with the advent of XQuery, this might change).
Pellet can test the satisfiability of conjunctions of thus constructed data
• User-defined Simple Datatypes: The main problem of having user-
defined data types is how to define URI's for XML Schema definitions.
This document from SWBPD working group at W3C discusses the
problem and several different solutions in detail. In Pellet, we adopt the
DAML+OIL solution in which a data type URI is constructed from the
URI of the XML schema document and the local name of the simple type.
We parse the XML schema document from the given URI and locate the
type using name attribute of the definitions.
• Multi-Ontology Reasoning using E-Connections: An E-Connection is a
knowledge representation language defined as a combination of other
logical formalisms. We use E-Connections as a language for defining and
instantiating combinations of OWL-DL ontologies, i.e. as a way of
combining KBs, rather than logics. This approach providing an alternative
to owl:imports will always bring all the axioms from the imported
Ontology and lets us identify sub-parts of an Ontology and gives a well-
founded logical framework for reasoning with multiple ontologies. Pellet

provides support for reasoning with E-connected ontologies through both
Jena and OWL-API interfaces.
• Ontology Debugging: Detection of unsatisfiable concepts in an Ontology
is a straightforward task. However, the diagnosis and resolution of the bug
is generally not supported at all. For example, no explanation is given as
to why the error occurs (e.g., by pinpointing the root clash, or axioms in
the Ontology responsible for the clash) or how dependencies between
classes cause the error to propagate (i.e., by distinguishing root from
derived unsatisfiable classes). Pellet provides support for both kinds of
tasks by pinpointing axioms that cause an inconsistency and the relation
between unsatisfiable concepts.
• Web Service Composition: Pellet is also used for Web Service discovery
and composition. Pellet has been used as the knowledge base for a version
of the SHOP2 HTN planning system and Fujitsu Lab of America's Task
Computing Environment (TCE).

2) Jena2
Jena (McBride, 2000) is a Java framework used to construct Semantic Web
applications. The current version of Jena is 2.4 which supports most of the main
ontology languages such as RDF/RDFS, DAML+OIL, and OWL. However, Jena2
does not fully support OWL in term of OWL reasoning, but it can work with all the
syntax of OWL. With this version of Jena2, it supports OWL Lite, some constructs of
OWL DL and OWL Full. Some of the significant constructs that are not supported in
Jena2 are complementOf and oneof. Because RDFS is not a subset of the OWL Lite or
OWL DL languages the Jena2 is an incomplete implementation of OWL Full. The
constructs Jena2 supports are listed in Table 2.

Table 1 The Constructs Supports in Jena2
rdfs:subClassOf, rdfs:subPropertyOf, rdf:type
rdfs:domain, rdfs:range
owl:sameAs, owl:differentFrom, owl:distinctMembers
owl:equivalentProperty, owl:inverseOf
owl:FunctionalProperty, owl:InverseFunctionalProperty
owl:SymmeticProperty, owl:TransitiveProperty
owl:minCardinality, owl:maxCardinality, owl:cardinality

Jena OWL reasoner does not support constructs that go beyond OWL Lite.
Thus, we use an external reasoner such as Pellet OWL Reasoner to do reasoning in

Figure 2.1 illustrates the overall structure of the inference machinery.

Figure 2.1 Structure of the Inference Machinery of Jena2

The Jena2 inference subsystem will open the connection to plug with a range
of inference engines or reasoners. These engines are used to derive additional RDF
assertions, which are entailed from some base RDF together with any optional
Ontology information and the axioms and rules associated with the reasoner. The
objective of this mechanism is to support the use of languages such as RDFS and
OWL which allow additional facts to be inferred from instance data and class
descriptions. Nevertheless, the machinery is designed to be general and, especially, it
includes a generic rule engine that can be used for many RDF processing or
transformation tasks.
Applications use the ModelFactory to associate a data set with some reasoner
to create a new Model in order to access the inference machinery. Queries to the
created model will return not only those statements that were present in the original
data but also additional statements than can be derived from the data using the rules
or other inference mechanisms implemented by the reasoner.
As shown the inference machinery is actually implemented at the level of the
Graph SPI. Thus, any of the different Model interfaces can be constructed around an
inference Graph. Especially, the Ontology API provides easy ways to link suitable
reasoners into the OntModels which it constructs. We also provide an InfModel as

part of the general RDF API. This is an extension of normal Model interface that
provides additional control and access to an underlying inference graph.
RDQL is a query language for RDF in the Jena framework. RDQL aims at
extracting information from RDF graphs. Thus, RDQL only retrieves information
stored in the model containing a set of N-Triples statements. However, RDQL does
not provide reasoning mechanisms, but reasoners will provide the reasoning after
binding to the model containing the original Ontology information. RDQL can
process Ontology in different languages including OWL with the help of an
appropriate reasoner.

An RDQL queries have the following form:

WHERE (?x shortPrefix:localName "value")
USING shortPrefix FOR <URIprefix>

?x is a variable. In the WHERE clause, a set of N-Triples define the query
pattern of a query. The USING clause defines an alias for the prefix of a URIs to
simplify the URI. RDQL can also query about predicates or objects too. The
limitation of RDQL is that there is no disjunction in the query. Though RDQL is
relatively simple in syntax, it is efficient for most of the Ontology queries. The simple
syntax also makes RDQL very flexible.

3) RacerPro
RacerPro (Racer Systems GmbH, 2005) stands for Renamed ABox and
Concept Expression Reasoner Professional. From its name, the origins of RacerPro
are in description logics area. Since description logics provide the foundation of
international approaches to standardize Ontology languages in the context of the so-
called Semantic Web, RacerPro can also be used as a system for managing Semantic
Web ontologies based on OWL (e.g., it can be used as a reasoning engine for
Ontology editors such as Prote´ge´). However, RacerPro can also be used as a
Semantic Web information repository with optimized retrieval engine because it can
manage large sets of data descriptions (e.g., defined using RDF). Furthermore, the

system can also be used for modal logics such as Km. However, RacerPro is the
commercial product, so it is quite inconvenient to use for research.

4) Protégé
Protégé (Stanford Medical Informatics, 2006) is a free, open-source platform
that provides user with a set of tools to construct domain models and knowledge-
based applications with ontologies. Protégé can implement a rich set of knowledge-
modeling structures and actions that support the creation, visualization, and
manipulation of ontologies in various representation formats. Protégé can be
customized to provide domain-friendly support for creating knowledge models and
entering data. Furthermore, Protégé can be extended by a Java-based Application
Programming Interface (API) for building knowledge-based tools and applications.

2.2 Semantic Web Services (SWS): Technologies and Standards
2.2.1 Why SWS?
The objective of the Semantic Web Architecture (Alesso, 2004) is to provide a
knowledge representation of linked data in order to allow machine processing on a
global scale. The W3C has developed a new generation of open standard markup
languages that are now poised to unleash the power, flexibility and, above all, logic of
the next generation of the Web, and open the door to the next generation of Web
Semantic markup (Roman et al., 2005) will be used to automate the tasks of
Web services discovery, composition and invocation. In addition, ontologies (Li &
Horrocks, 2003) can be used to describe services so that agents (both human and
automated tool) can advertise and discover services according to a semantic
specification of functionality.
There are many ways in which the two areas of Web Services and the
Semantic Web could interact to lead to the further development of Semantic Web
Services. Berners-Lee (Alesso, 2004) has suggested that both of these technologies
would benefit from integration that would combine the Semantic Web's meaningful
content with Web Services' business logic.
There are some technologies intending to combine Web Services (Alesso,
2004) and the Semantic Web in order to leverage the highest benefits such as OWL-
S, WSMO, METEOR-S and DAML. However, the technology issues of the Next

Generation Web create many problematic questions that must be solved before the
full power and capability of the Semantic Web Services are available. Concerns about
logic loops, syntax errors and trust-worthy published information remain formidable
problems. Despite this, several credible examples of Semantic Web Services are well
under way.

2.2.2 OWL-S.
OWL-S (Martin et al., 2004; Polleres, 2005) is OWL Ontology for describing
Web Services, enhancing some capabilities, such as capability based discovery of
Web Services, automatic composition of Web Services, and automatic invocation of
Web Services, that OWL does not have. OWL-S built the Semantic layer on top of
existing Web Service standard, e.g. OWL-S relies on WSDL for Web Service
invocation and expands UDDI for Web Service discovery, but not replacing Web

Figure 2.2 OWL-S Upper Ontology

The Figure 2.2 illustrates the Ontology of OWL-S in upper level:
• Service profile may correspond to capability specification, general service
features, service quality and classification in service taxonomies.
• Service model will describe how a service work, specify service
interaction protocol, and also facilitate Web Service invocation, Web
Service composition and interaction monitoring.

• Service grounding provides a specification of service access information.
Service Model + Grounding provide everything necessary for using the
service, and build upon WSDL in order to define message structure and
physical binding layer.

1) Service Profile
The class ServiceProfile provides a superclass of every type of high-level
service description. Figure 2.3 illustrates selected classes and properties of the Profile.

Figure 2.3 Selected Classes and Properties of the Profile

• Service Profile
The class
provides a superclass of every type of high-level
description of the service. While mandating the basic information to link any instance
of profile with an instance of service,
does not mandate any
representation of services.
A service can be related to a profile and a profile to a service according to a
two-way relationship between a service and a profile, expressed by the properties


describes a relation between an instance of service and an instance of
profile, meaning that the service is described by the profile.
specifies that a given profile describes a service.
• Service name, contacts and description
ServiceName, textDescription
, properties of the profile
provide human-readable information that is unlikely to be automatically processed.
Although having at most one service name and text description, a profile has many
items of contact information that the provider wants to offer.
, used as an identifier of the service, represents the name of the
service that is being offered.
provides a brief description of the service, what the service
offers, what the service requires to work, and any additional information that the
compiler of the profile wants to share with the receivers.
provides a mechanism of referring to humans or individuals
responsible for the service (or some aspect of the service). However, the range of this
property is unspecified within OWL-S.
• Functionality description
The profile specifies the functionality the service provides and the conditions
that must be satisfied for a successful result. In addition, it specifies what conditions
result from the service, including the expected and unexpected results of the service
activity. Two aspects of the functionality of the service are represented by the OWL-S
Profile: the information transformation (represented by inputs and outputs) and the
state change produced by service execution (represented by preconditions and
effects). For example, in order to complete the sale, a CD-selling service requires the
inputs which are not only a credit card number and expiration date, but also the
precondition that the credit card actually exists and is not overdrawn. The sales’ result
is the output of a receipt confirming the proper execution of the transaction, and the
effect is the transfer of ownership and the physical transfer of the CD from the
seller’s warehouse to the buyer’ address.
The Profile ontology does not provide a schema to describe IOPE instances. It
instead exists in the Process ontology, discussed in the next section. Ideally, we
conceive that the IOPE's published by the Profile are a subset of those published by
the Process. Therefore, the Process part of a description will create all the IOPE

instances and the Profile instance can simply point to these instances. In this case a
single instance is created for any IOPE, unlike in previous versions of OWL-S which
an instance was created both in the Profile and Process part of the OWL-S description
for a certain IOPE. Nevertheless, the Profile is able to create its own IOPE instances,
if the Profile IOPE's are different from the Process IOPE's. These IOPE instances
creations use the schema offered by the Process ontology.
The Profile ontology identifies the following properties of the Profile class for
referring to IOPE's:
covers a Parameter instance of the Process ontology. Parameter
class models our intuition that Inputs and Outputs (which are kinds of Parameters) are
both involved in information transformation and are different from Preconditions and
Effects. Its role is solely to make domain knowledge explicit. Thus, this class is not
expected to be instantiated.

covers instances of Inputs as defined in the Process Ontology.

covers instances of type Output, as defined in the Process ontology.

specifies one of the service preconditions and covers a
Precondition instance defined with regard to the schema in the Process ontology.

specifies one of the service results, as defined by the Result class in
the Process ontology, under what conditions the outputs are generated. Moreover, the
Result specifies what domain changes are produced during the execution of the

• Profile attributes
Profile attributes include the quality guarantees provided by the service,
possible classification of the service, and additional parameters the service may want
to specify.
is an expandable list of properties that may accompany a
profile description. The property’s value is an instance of the class
refers to an entry in some services ontology or taxonomy. The
property value is an instance of the class
• ServiceParameter
is the actual parameter’s name, which could be just a
literal, or perhaps the URI of the process parameter (a property).
refers to the parameter’s value within some OWL ontology.

• ServiceCategory
describes services’ categories based on some classification that
may be outside OWL-S and possibly outside OWL. In the latter case, some
specialized reasoner is required, if it has to do any inferences.
is the actual category’s name, which could be just a literal, or
perhaps the URI of the process parameter (a property).
stores a reference to the taxonomy scheme. A reference can be either
taxonomy’s URI, or its URL, or its name, or anything else.
refers to the value in a specific taxonomy whose value may be more than
one value for each taxonomy, as a result, there are no restriction added here.
to each type of service stores the code relevant to a taxonomy.

2) Service model
• Atomic and simple processes
Atomic processes correspond to the actions that require single interaction
whereas simple processes provide an abstraction mechanism to provide multiple
views of the same process.
Atomic processes are directly invocable (by passing them the appropriate
messages). Atomic processes have no subprocesses and execute in a single step, as far
as the service requester is concerned, taking an input message, doing something, and
then returning their output message. Therefore, a grounding that enables a service
requester to construct messages to the process from its inputs and deconstruct replies
must be provided for each atomic process.

Figure 2.4 illustrates selected classes and properties of the process model.

Figure 2.4 Top level of Process Ontology

• Composite Process
Composite processes are decomposable into other (non-composite or
composite) processes; these activities can be specified by using control constructs
such as
. Note that a composite process is not a behavior a
service will do; however, it is a behavior (or set of behaviors) the client can perform
by sending and receiving a series of messages. For example, if the composite process
has an overall effect, the client must perform the entire process in order to achieve
that effect.
This section is concluded with an overview of the OWL-S control constructs:
Sequence, Split, Split + Join, Choice, Any-Order, Condition, If-Then-Else, Repeat-While, and

: A list of control constructs to be done in order.

: The components of a
process are a bag of process components to be
executed concurrently. As soon as all of its component processes have been
scheduled for execution,

: The
process consists of concurrent execution of a bunch
of process components with barrier synchronization. It completes when all of its
components processes have completed.
allow us to define
processes that have partial synchronization.

allows the process components (specified as a bag) to be
able to be executed in some unspecified order except concurrently. Moreover,
execution and completion of all components is required. An
requires that the execution of processes not overlap, i.e. atomic processes and
composite processes cannot be executed concurrently and interleaved, respectively. In
addition all components must be executed and completion of all components is

calls for the execution of a single control construct from a bag
of control constructs given by the components property. Any of the given control
constructs may be chosen for execution.

: The
class is a control construct having properties
, then and else. Those properties hold different aspects of the
. Its
semantics indicate ``Test If-condition; if True do Then, if False do Else.''.

Repeat-While and Repeat-Until

Both of these iterate until a condition becomes
false or true.
tests for the condition, exits if it is false and does the
operation if the condition is true, then loops.
does the operation, tests for
the condition, exits if it is true, and otherwise loops. Therefore,
never act, whereas
always acts at least once.

3) Service grounding
The service grounding specifies the details, mainly related with protocol and
message formats, serialization, transport, and addressing, of how to access the
service. A grounding can be considered as a mapping from an abstract to a concrete
specification of those service description elements required for interacting with the
service. For our purposes, those service description elements are the inputs and
outputs of atomic processes. In OWL-S, both the ServiceProfile and the

ServiceModel are considered as abstract representations while only the
ServiceGrounding concerns the concrete level of specification.
OWL-S does not include an abstract construct for explicitly describing
messages, but the abstract content of a message is implicitly specified by the input or
output properties of some atomic process. Thus, atomic processes, in this case can
also be considered as the communication primitives of an (abstract) process
specification. Concrete messages, however, are specified explicitly in a grounding.
An OWL-S grounding function is centrally to show how the (abstract) inputs and
outputs of an atomic process are to be realized concretely as messages, carrying those
inputs and outputs in some specific transmittable format. Since there are a significant
body of work in the area of concrete message specification, which is already well
adopted, Web Services Description Language (WSDL) is chosen to be used in
crafting an initial grounding mechanism for OWL-S.

2.2.3 WSMO.
As mentioned in Section 2.2.1, many existing research aimed at making web
content more machine-processable. Semantic Web (Berners-Lee, Hendler, & Lassila,
2001), particularly in Web services’ context usage, are gaining momentum also. In
this case , semantic markup shall handle tasks’ automation of Web service discovery,
composition and invocation (The OWL Services Coalition, 2004) while minimizing
human intervention.
The description of Web services in the context of machine-understandable or
machine-processable is predicted to have a great impact in areas of e-Commerce, e-
learning and Enterprise Application Integration, since it is expected to enable
dynamic and scalable cooperation between different systems and organizations:
Based on the needs of another business or application, Web services provided by
cooperating businesses or applications can be automatically located, composed to
achieve more complex, added-value functionalities. Moreover, they allow
cooperating businesses or applications to interoperate without prior agreements
custom codes, enabling much more flexible and cost-effective integration.
The Web Service Modeling Ontology (WSMO) (Dumitru et al., 2005) aims to
describe all general service aspects accessible through a Web service interface with
the ultimate goal of enabling tasks’ automation (total or partial) concerning both
intra- and inter-enterprise integration of Web services. WSMO is conceptually based

on Web Service Modeling Framework (WSMF) (Fensel & Bussler, 2002), refining
and extending this framework and developing a formal ontology and set of languages.
WSMO provides ontological specifications for the core elements of Semantic
Web Services. In fact, the purpose of Semantic Web Services is to combine Semantic
Web technologies and Web services to offer an integrated technology for the next
generation of the Web, as a result they turn the Internet from information repository
for human consumption into a world-wide system for distributed Web computing.
Thus, Semantic Web Services need appropriate frameworks for integrating the basic
Web design principles, those defined for the Semantic Web, and for distributed,
service-oriented computing of the Web. Therefore, WSMO is based on the following
design principles:
• Web compliance: WSMO inherits the concept of URI (Universal Resource
Identifier) for unique identification of resources as the essential design
principle of the Word Wide Web, adopts the concept of Namespaces for
denoting consistent information spaces, supports XML and other W3C
Web technology recommendations, and the decentralization of resources.
• Ontology-based: WSMO uses ontologies as the data model, meaning that
all resource descriptions as well as all data interchanged during service
usage are based on ontologies. Since ontologies have been identified as the
central enabling technology for the SemanticWeb, the extensive usage of
ontologies allows semantically enhanced information processing as well as
support for interoperability; WSMO also supports the ontology languages
defined for the SemanticWeb.
• Strict decoupling: Decoupling indicate that each WSMO resources is
specified independently without concerning possible usage or interactions
with other resources, complying with the open and distributed nature of
the Web.
• Centrality of Mediation: Mediation addresses the handling of
heterogeneities that naturally arise in open environments, and able to
occur in terms of data, underlying ontology, protocol or process. For
WSMO, mediation is recognized as the important aspect for the successful
deployment of Web services by making it a first class component of the

• Ontological role separation: Users, or more generally clients, exist in
specific contexts other than available Web services. For example, a user
may wish to book a holiday according to preferences for weather, culture
and childcare, whereas Web services will typically cover airline travel and
hotel availability. The underlying epistemology of WSMO differentiates
between the desires of users or clients and available services.
• Description versus Implementation: For WSMO, there are differences
between the descriptions of Semantic Web Services elements (description)
and executable technologies (implementation). While the former requires
a concise and sound description framework based on appropriate
formalisms in order to provide concise semantic descriptions, the latter
involves the support of existing and emerging execution technologies for
the Semantic Web and Web services. The objective of WSMO is to
provide an appropriate ontological description model, and to be compliant
with existing and emerging technologies.
• Execution semantics: For verifying the WSMO specification, the formal
execution semantics of reference implementations such as WSMX and
other WSMO-enabled systems provide the technical realization of
• Service versus Web service: While a Web service is a computational entity
able to achieve a user goal by invocation, a service is the actual value
provided by this invocation. WSMO provides means to describe Web
services that provide access (searching, buying, etc.) to services. As a
result, it is designed as a means to describe the former and not to replace
the functionality of the latter.

Top-level elements of WSMO
WSMO identifies four top-level elements as the main concepts, following the
key aspects identified in the Web Service Modeling Framework, which have to be
described to define Semantic Web Services:
• Ontologies provide the terminology used by other WSMO elements to
describe the relevant aspects of the domains of discourse. When compared
to mere terminologies that focus exclusively on syntactic aspects,

ontologies can additionally provide formal definitions that are machine-
processable, allowing other components and applications to take actual
meaning into account.
• Web services represent computational entities that can provide access to
services that, in turn, provide some value in a domain; Web service
describes the capabilities, interfaces and internal working of the service
using the terminology defined by the ontologies.
• Goals describe aspects related to user desires according to the requested
functionality; again, Ontologies are able to be used to define the used
domain terminology, useful in describing the relevant aspects of goals.
Goals model the user view in the Web service usage process, and therefore
are a separate top-level entity in WSMO.
• Mediators decribe elements that handle interoperability problems between
different WSMO elements. They are envision as the core concept to
resolve incompatibilities on the data, process and protocol level, e.g. in
order to resolve mismatches between different used terminologies (data
level), in how to communicate between Web services (protocol level) and
on the level of combining Web services (process level).

2.2.4 Semantic Web services discovery and composition.
Semantic Web Services facilitate activities including automatic discovery and
composition of Web Services (Hakimpour, Sell, Cabral, Domingue, & Motta,

Research on Web Services composition is gaining a considerable attention
motivated by the need to support business interoperation and re-use or extension of
available services. Semantic Web technology can support this complex task, whereby
semantic descriptions associated with each Web Service can be used to filter and
match the services according to the users needs.
Matchmaking is one important task need to be done when we try to search and
match for the suitable service to be composed (Service Discovery). The Matchmaker
is also a web service that helps to connect between service requesters and service
providers. The Matchmaker serves as a "Telephone or Service directory book" of
service capabilities or functionalities. The Matchmaker allows users and/or software
agents to find each other by providing a mechanism for registering service

capabilities. Registration information is stored as advertisements. When a user or
another software agent sends the query to Matchmaker agent, it looks into its dynamic
database of advertisements to find agents that can fulfill the incoming request(s).
Therefore, the Matchmaker also serves as a connection between a service requester
and a service provider.
There are many methods to perform this task. Many research focus on
computing syntactical and semantic similarity among service capability description
using inputs, outputs, pre-conditions and post-conditions (IOPEs) to match for the
service (Liu ,Guo, & Huang, 2006; Majithia, Walker, & Gray, 2004). Moreover, there
is another way using ontology similarity matching the service name in case that
service does not have service description (IOPEs), so they will use ontology to
describe itself and using ontology to find the services which are able to match with
them (Jian Wu, Zhaohui Wu, 2005).
Finally, OWL-S and WSMO are two prominent initiatives that address the
service composition in the domain of Semantic Web Services.

2.3 Adaptive and Personalized E-learning
Several works related to adaptive e-learning have been proposed in e-learning
research area. They more focus on how to propose the e-learning course that suit with
each personal profile of the learner. Dolog, Henze, Nejdl, and Sintek (2004) used
personalized service architecture to address the gap between an adaptive educational
system and a personalized functionality. It brings personalization to the Semantic
Web to help the user find learning materials, courses or learning paths that are
suitable for that user. However, they do not use the personal data of the learner to do
the course planning. Thus, the learner might get lost what should be the learning path
for them after finishing a particular course. In the same research area, Li & Huang
(2006) proposes an approach to dynamically compose an adaptive curriculum for e-
learning based on a topic-centered resource space. By exploiting the semantic
relationships that characterize learning objects (LOs) and learner profile, the approach
dynamically selects, sequences, and links learning resources into a coherent,
individualized curriculum to address learners’ focused learning needs. This is another
example of the paper which also mainly focuses on learning object on individual

Stojanovic, Staab, and Studer (2001) examined the comprehensive benefits of
E-Learning by using Semantic Web technology which provides an e-learning portal
architecture that uses Ontology to address the description of learning material
(content). The form of presentation (context) and the dimension of learning materials
(structure) provide flexible and personalized learning materials.
Some area of interest of research in e-learning topic focuses on the content
aggregation and management. LMS (Learning Management System in SCORM)
(Advanced Distributed Learning, 2004) focuses on delivering e-learning content to
the learner in the right sequence and also keep track of each e-learning. eduSource
(Canadian Network of Learning Object Repositories) is also another example in the
same area as SCORM. eduSource tries to develop and break through the limitation of

Chapter 3
E-Learning Service Planning Framework

This Chapter discusses about applying OWL-S to model course composition
for each certificate and also model course service and course category. Moreover, the
Ontology model of student profile and course type will also be discussed in detail.
Finally, planning algorithm, which will plan the course based on provided OWL-S
and Ontology information, will also be explained step by step.
For the design of Semantic Web Services (OWL-S) and Ontology (OWL),
they need to be designed based on the following requirements:
1) Suggest course plan to be registered based on Student profile/ Student
Preference / constraint and available services at that time.
2) More than one plan will be generated and these plans can be ranked based
on Student Preferences and Constraints
3) System should advise the course by taking into account course pre-
requisites and transferable/ equivalent courses as a factor.
4) The system can get the input such as certificate structure, course details,
and Student Profile.

3.1 Ontology Model Overview

= Class
= Property

Figure 3.1 Proposed Ontology Model

Before we start implementation, the design of the high-level framework needs
to be completed in order to confirm that all requirements are addressed when
performing actual implementation. From Figure 3.1, we propose four main classes
which are
Course Category
will represent the learner who might have some passed course and
certificate that he/she already passed.
should be able to represent the
structure of each certificate which inside contains courses. We use OWL-S
ServiceModel to represent
will represent each course.
However, there will be the relationship between each
) that will be described in detail in Section 3.3.
Course Category
will be used to
describe the category of each course and will represent the preference of the learner.
This information is very important when raking the course plan.
The next section will describe each component of the framework in detail.

3.2 Modeling E-Learning Certificate
In the proposed framework, the service composition concept will be used in
this design phase. Each individual course contained in a degree or certificate is
modeled as a service and individually modeled based on the W3C OWL-S 1.1. We
will only focus on the OWL-S ProcessModel to model our degree or certificate.
Composite process, Atomic Process
and Control Construct Class ("
") are used in this modeling.
In our model, each course is modeled as
Atomic Process
, and the composition in
a higher level will be represented as
Composite Process
. In course structure of each
certificate in our research, it is composed of 3 main categories of courses. First is
Core Courses
, Second is Category:
Specialized Courses
and Third is Category:
Language Courses
. Thus, these categories are represented as Composite Process.
However, in each category, it is composed of many courses, but in reality we
will limit the number of registered courses required in each category, so the learner
can only choose a certain number of courses from the whole list of courses in each
category. Thus, we create the subcategory (
SubCore courses, SubSpecialized courses,
SubLanguage courses
) of each category to specify the number of courses required for
each category, and the subcategory is represented as Composite Process as well.
Finally, the list of the courses in each category will be represented as
under subcategory,
Composite Process
. In this level, we will use “
” of

Control Construct Class to cover the list in order to show that subcategory can choose
only one course in the list.
Figure 3.2 shows the model of OWL-S e-learning service composition. We
will classify the service into three levels which is shown in hierarchy level

Figure 3.2 Hierarchy Level of OWL-S Based E-Learning Service Composition

Figure 3.3 shows the example of Software Engineering certificate which is
composed of three main categories,
Core Courses
Specialized Courses
Language Courses
Control Construct used to cover these three categories is “
”. Under
, there are 3
, and under
, there are the lists of
. This means that this certificate requires 3 core courses chosen from the lists of
courses represented by
#Atomic Process


Figure 3.3 An Example of Software Engineer Certificate Modeled by OWL-S

However, in this model, it still cannot elaborate the sequence or pre-requisite
of each course in order to benefit for the sequencing and composition planning, but
because of limitation of OWL-S service model syntax itself, we then design new
properties of Ontology in course service to represent this requirement which will be
discussed in next section.

3.3 Modeling Course Service and Service Category
In the previous section, we discuss about the OWL-S ProcessModel to model
course composition for each certificate. In this section, we then will move into more
detail about
service and its category. In
service, we will discuss about its
description and properties of the service (
Course Equivalent
, etc..) as well as
the category of the service which will be represented by
of OWL-
S model.

3.3.1 Course service.
In our implementation, we represent each course as one service annotated by
OWL-S. We then use the Service:Profile to explain the description of the course. The
Table 3.1 shows the description of the course service using ServiceProfile.

Table 3.1 The OWL and OWL-S Properties of Course Service
OWL-S ServiceProfile
ServiceName CourseService Text
This will contain the
Course Name
Text Description CourseService Text
This will contain the
Course Description
CourseCredit CourseService Integer
This integer will specify
the credit of this course.
CourseCode CourseService Text
This text will specify the
code of this course e.g.
Contact Information CourseService Text
This will contain the
information of instructor
Service Category CourseService Service
This will contain the
Course Type of the
course which will be
described in section
3.3.2. In our
implementation, we
allow one course to have
more than one category
because it can be
interdisciplinary course

Figure 3.4 shows an example of a course service, namely Java course. It
shows the details of how to employ OWL-S to represent course service. In this model,
we will mainly use the
of OWL-S because it can explain the description

of the course and also can classify the category of the course by using
Note that
is used to model how to execute a particular course service.

Text Description
profile =
service =
process =
grounding =
Java course service
Course name
Course description
Instructor Contact
Course Category
Figure 3.4 OWL-S Based to Represent Course Service

We already discussed about the description of the service. However, the
important things to help the system perform the service planning are the relationship
properties of services, such as
and etc.
Table 3.2 shows the details of each ontology property used by a course service
to link to related course services. This will help the system to be able to reason when

Table 3.2 The OWL Properties of Relationship of Course Service
CourseService CourseService
This property has inverse property
which is
. This
property is used to define the
prerequisite of each course service
in order to let the system know that
the student cannot register for the
course unless he/she passes the
prerequisite courses.
CourseService CourseService
This property has symmetric and
transitive property. This property
will be used when the student has
passed one course and can have the
credit transferred to another
course, so he/she does not need to
register again for that course. In
another case, the system can
suggest the equivalent course when
some courses are not available at
that time, but one of their
equivalence is.

In terms of Pre-requisite, some institutes might apply only at course level. For
example, to be able to register for Data Structure course, you need to pass Discrete
Mathematics course. This is the normal practice in many institutes or universities
using courses to determine knowledge of students. However, to model a course, there
might be many types and levels of knowledge. Thus, to allow a student to register a
certain course, one might want to describe the pre-requisite conditions by means of
types and levels of knowledge. For example, Network programming might contain
the lessons related to Network, Programming and Algorithm but in different level;
hence, the Network Programming Course requires Network Knowledge level 1,

according to Figure 3.7. Thus, this student might not need to take the full Network
course, but only take some course containing the basic knowledge of Network. As a
result, the knowledge of a student can be determined by the detail knowledge of each
course which he/she has already passed. Then, the knowledge of a student can be
shown in more detail with more accuracy.
To be able to provide this capability, we use
properties to model this Pre-requisite
knowledge of each course and also model the post-knowledge. Figure 3.5 shows
OWL-S schema to model Precondition and Effect of course.

profile =
service =
process =
grounding =
Java course service
Knowledge Type
Knowledge Level

Figure 3.5 OWL-S Schema to Model Precondition and Effect

class contains each type of knowledge and its level shown in Table
3.3. The level will determine the capability of the student required to be able to study
that course and also the knowledge that they will get after finishing that course, and
the knowledge type will specify the area of that knowledge such as Network,
Programming Language and so on. Normally, each type of knowledge will have 5
levels from lowest to highest level.


Table 3.3 The OWL Properties of Relationship of Knowledge Class
OWL properties
Knowledge KnowledgeType
The Knowledge type is
an area of knowledge
such as Computer
Network, Programming
Language, Software
Engineering and so on.
Knowledge KnowledgeLevel
(Integer ranging
from 1 to 5)
The knowledge level will
determine the capability
of the learner in that area
of knowledge.

Figure 3.6 will show knowledge class and its instances. Thus, each course can
select more than one prior knowledge instances (
) from this class and can
select more than one post knowledge instances (
) from this class as well.

Figure 3.6 Knowledge Class and Its Instances

Now that the schema and the structure of knowledge class are shown already,
Figure 3.7 will show the example of the course with its
This is
the Network Programming course which the student need to have the knowledge in
Computer Network (level 1), Programming Techniques(level 1), Algorithm(level 2) ,
Programming Language (level 2) and Operating System(level 1) before registering
for this course. The knowledge of a student then can get from many courses which
he/she has ever studied. It is not required to get this knowledge from only one course
or two courses. In addition, after the student passes this course, he/she will have the
knowledge in Computer Network (level 3) and Programming Techniques (level 2).
Thus, it is very obvious that with this kind of design the knowledge of each
students can be determined more accurately, and students are recommended with the
most suitable course to register.

Figure 3.7 An Example of Course


3.3.2 Service: ServiceCategory.
In our system, we also want to categorize each course. Thus, we implement
Course Category
by using
of OWL-S. Moreover, this will be
used to suggest the course to the students based on their preference. In their
preference, they can specify the course category which they prefer.
Course Category
will use ACM Computing classification (1998 version) (The
Association for Computing Machinery, Inc. 1998) structure as a model for
implementation as shown in Figure 3.8.


Figure 3.8 Course Category Based on ACM Computing Classification

3.4 Modeling Student Profile
In previous section, we discuss about using OWL-S to model some
components of e-learning service composition framework. In this section, we will

then discuss about using OWL Ontology to model the rest of the framework. Thus,
this section will mainly discuss about OWL for Student Profile.
Student Profile
is one of important component Ontology in the system because it
will be used to determine which course the student already passed and which
certificate student already got. Then, the system will use this information to plan the
course service to suggest to the student.
The properties of
Student Profile
will be shown in Table 3.4.

Table 3.4 The OWL Property of Student Profile
StudentProfile String
This String will specify the
Student’s first name.
StudentProfile String
This String will specify the
Student’s last name.
StudentProfile Integer
This Integer will specify the
Student’s age.
StudentProfile Date
This Date will specify when
this student first attends to
register for certificate. This
will help university or
institute to keep tracks of the
period of studying of this
StudentProfile String
This String will specify the
Student’s sex (male/ female).
StudentProfile CourseService
This property will link
between the student and the
list of courses that this
student has already passed.
This information will be used
by the system to determine
which course this student

should register. Some passed
course may already be in the
list of registered certificate,
so the system can reduce the
number of the courses yet to
be registered by this student
in that certificate.
StudentProfile Certificate
This property will link the
student and the list of
certificates which this student
has already passed, so the
system will then be able to
offer the certificate which
this student has never
registered before.
StudentProfile Integer
This number will specify
how many courses/credits
(can be customized for both
requirements) this learner is
able to register per one
semester. The system will
use this information to
calculate when suggesting
the course plan.
StudentProfile CourseCategory
One student can have more
than one preference. This
information will be used to
rank the course plan before
suggesting to the learner. It
will suggest the plan that
mostly matches with user
preference first.

3.5 Ontology Model: Detail View
The previous sections discuss the important classes and properties proposed
by the framework in detail. This section presents the overall ontological classes and
properties described in the previous section. Figure 3.9 illustrates the ontology which
will be used to perform actual implementation. There will be the relation between the
ontology and also within the same ontology as well.

Atomic Process
Atomic Process
Course (OWL-S)
Course Category (OWL-S
Certificate (OWL-S ProcessModel)
Text Description
Instructor Contact
Course Type
Java Service

Figure 3.9 The Class Representation of E-Learning Service in OWL

3.6 Matchmaking
Our OWL-S Matchmaker uses ontology similarity matching to search for the
service. Service matching will be performed when the student registers for one
specific certificate which contains many courses, then the system will find the course
services of that specific certificate (requester) in the current available course database

(register database/database of advertisement) in which the provider registers for its
course service.
In the implementation, we will use the course name to match or search for the
service. However, if the system cannot find an exact match for the course name, Twe
will use ontology to compute semantic similarity to find another course service.
Figure 3.10 shows the Overview Diagram for Matchmaking of Course Service. In this
figure, the requester tries to ask for “Computer Network Management” course.
However, when the Matchmaker searches this course in the Database of
Advertisement, this course cannot be found. Then, the Matchmaker uses course
ontology to find out a similar/ equivalent course. It finds that “Communication
Network” is equivalent to “Computer Network Management”, and “Communication
Network” is also currently available in Database, so it returns this service to the

Figure 3.10 Overview Diagram for Matchmaking of Course Service

3.7 Planning Algorithm
For the planning algorithm, we need to carefully plan each step because the
algorithm of reasoning to get the end result is very complicated. We need to compare
and retrieve the data from many classes in our Ontology. This algorithm runs every
time when it suggests the plan for the learner. Normally, it will be run once per

Code Listing 3.1 are the steps of planning algorithm

Code Listing 3.1 Planning Algorithm
input username, certificate;
output courseplan[ Combination];

planning algorithm
{ request_certificate <- retrieve the requested certificate from the certificate.owls ontology
number_of_required_corecourse <- get the number of required core courses from
corecourses[ ] <- get the lists of core courses of request_certificate
number_of_required_specializedcourse <- get the number of required specialized courses from
specializedcourses[ ] <- get the lists of core courses of request_certificate
number_of_required_Languagecourse <- get the number of required Language courses from
Languagecourses[ ] <- get the lists of Language courses of request_certificate

learnerPassedCourse[ ] <- query learner’s PassedCourse and reasoning for equivalent Course
of the learner’s passed course as well

for each course of corecourse[ ], specializedcourse[ ], languagecourse[ ]
{ if (course is in learnerPassedCourse[ ] && course is corecourse)
{ Reduce number_of_required_corecourse by 1 ;
Delete this course from corecourses[ ];
if (course is in learnerPassedCourse[ ] && course is specializedcourse)
{ Reduce number_of_required_specializedcourse by 1 ;
Delete this course from specializedcourses[ ];
if (course is in learnerPassedCourse[ ] && course is languagecourse)
{ Reduce number_of_required_languagecourse by 1 ;
Delete this course from languagecourses[ ];
// Check the each course in certificate whether it is available
available_course [ ] <- query available course from available_service.owl ontology
for each course of corecourse[ ], specializedcourse[ ], languagecourse[ ]
{ if(course is in available_course[ ]) // If course is available
{ prerequisite_course[ ] <- query the prerequisite of course
for each prerequisite_course[ ]
if (prerequisite_course is not in learnerPassedCourse && course is corecourse)
{ Delete the course from corecourses[ ]); }
if (prerequisite_course is not in learnerPassedCourse && course is
{ Delete the course from specializedcourses[ ]; }
if (prerequisite_course is not in learnerPassedCourse && course is
{ Delete the course from languagecourses[ ]; }
// We will check the equivalent of the course instead, if the course is not available
else if (course is not in available_course[ ])
{ equivalent_course[ ] = query equivalent courses of the course from course ontology;
for each equivalent_course[ ]
{ if (equivalent_course is in available_course[ ] && equivalent_course is in
{ Replace the course with this equivalent_course;
// suggest its equivalent course instead

if (all equivalent_course[ ] is not available)
{ Delete this course from suggest course list;
final_courselist [ ] <- corecourse[ ]+specializedcourse[ ]+languagecourse[ ];
// Final list will collect all possible courses that can be register of this learner
num_learner_constraint <- get learner’s constraint from student ontology
ArrayOfCombination[ Combination];
ArrayOfCombination[ ] <- Generate the combination of the course based on
num_learner_constraint and select the course from final_courselist[ ];
// ArrayOfCombination[] will collect every possible combinations