SEMANTIC WEB AND ONTOLOGY BASED TOOLS FOR

walkingceilInternet and Web Development

Oct 22, 2013 (3 years and 11 months ago)

422 views

SEMANTIC WEB AND ONTOLOGY BASED TOOLS FOR
FINDING PROJECTS IN COMPUTER SCIENCE









A THESIS SUBMITTED TO THE UNIVERSITY OF MANCHESTER

FOR THE DEGREE OF MASTER OF SCIENCE

IN THE FACULTY OF SCIENCE AND ENGINEERING






September, 2004




By

Yean Mei Yeo

Department of Computer Science


2

Contents


Abstract

................................
................................
................................
..........

8

Declaration

................................
................................
................................
.....

9

Copyrigh
t

................................
................................
................................
.....

10

Acknowledgement

................................
................................
.......................

11

1

Introduction

................................
................................
..........................

12

1.1

Motivation for Semantic
Web Enabled Search

................................
.................

12

1.2

Project Objective

................................
................................
...............................

15

1.3

Project Definition and Scope

................................
................................
............

15

1.4

Division of Work

................................
................................
..............................

16

1.5

Thesis Outline

................................
................................
................................
...

17

2

Literature Survey

................................
................................
.................

19

2.1

Ontology Languages and Ontology Tools

................................
........................

19

2.1.1

Species of Ontology Languages
................................
................................
....

19

2.1.1.1

Frame
-
based Languages
................................
................................
........

19

2.1.1.2

Description Logics

................................
................................
................

19

2.1.2

RDF/RDF(S)
-

Resource Description Framework (Schema)

.......................

20

2.1.3

DAML+OIL
-

Darpa Agent Markup Language + Ontology Inference Layer

………………………………………………………………………………
23

2.1.4

OWL
-

Web Ontology Language

................................
................................
..

25

2.1.5

Comparison of RDF(S), DAML+OIL and OWL

................................
.........

30

2.1.6

Ontology Tools

................................
................................
.............................

31

2.1.6.1

WebODE

................................
................................
...............................

31

2.1.6.2

Protégé
-
2000

................................
................................
.........................

31

2.1.6.3

OntoEdit

................................
................................
................................

32

2.1.6.4

OilEd

................................
................................
................................
.....

33


3

2.1.6.5

Comparison of WebODE, Protégé
-
2000, OntoEdit and OilEd

............

33

2.2

Ontology Query Languages

................................
................................
..............

34

2.2.1

RQL
-

The RDF Query Language

................................
................................

34

2.2.2

RDQL


RDF Data Query Language

................................
............................

37

2.2.3

OWL
-
QL


OWL Query Language

................................
..............................

39

2.2.4

Comparison of RQL, RDQL and OWL
-
QL

................................
.................

44

3

Proposed Architecture/Design

................................
............................

46

3.1

Architecture
................................
................................
................................
.......

46

3.2

Summary of Tools and APIs Used
................................
................................
....

48

4

Development of CS Project Ontology

................................
................

49

4.1

What is in an Ontology?

................................
................................
...................

49

4.2

Domain and Scope of Ontology

................................
................................
........

49

4.3

Possibility of Reusing Existing Onto
logy

................................
.........................

51

4.4

Enumeration of Important Terms and Grouping of Terms

...............................

52

4.5

Decision between Classes and Individuals

................................
.......................

56

4.6

Define the Properties of Classes

................................
................................
.......

58

4.7

Review and Refinement of CS Project Ontology

................................
.............

59

4.7.1

Classification of CSField Class

................................
................................
....

59

4.7.2

Classification of Programming Language Class

................................
...........

65

4.8

Ontology Normalisation
................................
................................
....................

69

5

Implementation

................................
................................
....................

70

5.1

Search Function

................................
................................
................................

70

5.1.1

User Interface Design

................................
................................
...................

70

5.1.2

Free
-
form Text Search vs. Search from a Predefined List
............................

73

5.1.3

Formation of Search Query

................................
................................
...........

74

5.2

Admin Function

................................
................................
................................

76

5.2.1

User Interface Design

................................
................................
...................

76

5.2.2

Instance Maintenance
................................
................................
....................

78


4

6

Testing and Evaluation

................................
................................
........

80

6.1

Testing
................................
................................
................................
...............

80

6.2

Evaluation

................................
................................
................................
.........

80

6.2.1

Usability and Utility Evaluation

................................
................................
...

80

6.2.2

Ontology Tool Evaluation
................................
................................
.............

82

7

Conclusion and Fu
ture Work

................................
.............................

84

7.1

Conclusion

................................
................................
................................
........

84

7.2

Future Work

................................
................................
................................
......

85

Bibliography

................................
................................
................................

87

Appendix A: Language Features for OWL Full, OWL DL and OWL
Lite

................................
................................
................................
................

92

Appendix B: BNF Grammar of RQL

................................
.......................

94

Appendix C: BNF Grammar of RDQL

................................
....................

96

Appendix D: XML Schema Definition of OWL
-
QL Syntax

..................

98

Appendix E: Scre
en Shots of Semantic Web and Ontology Based Tools
for Finding Projects in Computer Science

................................
.............

103

Appendix F: Test Script

................................
................................
...........

112



5

List of Tables


Table

1.1: Division of Work

................................
................................
.............................

17

Table

2.1: RDF and RDF(S) properties

................................
................................
............

23

Table

2.2: Some features from DAML+OIL

................................
................................
....

25

Table

2.3: Some features in OWL

................................
................................
....................

29

Table

2.4: Comparison of Ontology Languages [7]

................................
.........................

30

Tabl
e

2.5: Comparison of ontology tools

................................
................................
.........

33

Table

2.6: Description of RDQL query syntax

................................
................................
.

38

Table

2.7: Comparison of ontology query lan
guages.

................................
......................

44

Table

3.1: Summary of tools and APIs

................................
................................
.............

48

Table

4.1: Existing ontologies available online

................................
................................

51

Table

4.2: Properties in CS Project Ontology

................................
................................
...

59

Table

4.3: Definition of different programming language categories

..............................

67

Table

4.4: Definition of programming language “Perl” and “C”

................................
.....

67

Table

5.1: Free
-
form text search vs. Search from a predefined
-
list

................................
..

73

Table

6.1: Usability evaluation

................................
................................
.........................

82

Table

6.2: Utility evaluation

................................
................................
.............................

82



6

List of Figures



Figure

2.1: Example of node
-
arc diagram representing RDF statements

.........................

21

Figure

2.2: RDF syntax

................................
................................
................................
.....

21

Figure

2.3: RDF(S) mod
elling primitives [39]

................................
................................
.

22

Figure

2.4: Ontology Languages and OWL

................................
................................
......

26

Figure

2.5: Three sublanguages of OWL

................................
................................
..........

26

Figure

2.6: Subclass relationships between OWL and RDF(S)

................................
........

27

Figure

2.7: OWL
-
QL Query
-
Answering Dialogues (adapted from [12])

.........................

41

Figure

2.8: QWL
-
QL Query message placed inside a SOAP envelope.

..........................

43

Figure

2.9: OWL
-
QL answer message returned by the answering agent (server)
............

44

Figure

3.1: The architecture for CS Project Search

................................
..........................

46

Figure

4.1: Important terms in CS Project Ontology

................................
........................

52

Figure

4.2: Grouping of terms in CS Project Ontology

................................
....................

53

Figure

4.3: A fraction from the taxonomies of the CS Project Ontology

.........................

55

Figure

4.4: Hierarchical structure of classes in CS Project Ontology schema

.................

57

Figure

4.5: A fraction of the taxonomy for AI field

................................
.........................

60

Figure

4.6: Repository of CS Field keywords

................................
................................
..

61

Figure

4.7: Definition of CS Field “AI”

................................
................................
...........

62

Figu
re

4.8: Definition of CS Field “DataMining”

................................
............................

62

Figure

4.9: Definition of CS Field “AI” and “InformationSystems”
................................

63

Figure

4.10: D
efinition of CS Field “KnowledgeRepresentation” and “SemanticWeb”

.

64

Figure

4.11: Inferred CSField hierarchies

................................
................................
........

65

Figure

4.12: Rep
resentation of PLValueType with a covering axiom.

............................

66

Figure

4.13: A schematic view of the relationship between programming languages and
PLValueType

................................
................................
................................
............

68

Figure

5.1: Page transitions for search procedure

................................
.............................

70

Figure

5.2: User Interface (I) for
Search.jsp

................................
................................
.....

71

Figure

5.3: User Interface (II) for
Search.jsp

................................
................................
...

72

Figure

5.4: Data flow in a search procedure.

................................
................................
....

74

Figure

5.5: Example of RDQL query for
searching projects

................................
............

75


7

Figure

5.6: Page transition for admin function

................................
................................
.

76

Figure

5.7: Instance maintenance page used as pop
-
up windo
w to supplement the creation
of new project.

................................
................................
................................
..........

77

Figure

5.8: Creation of new instance

................................
................................
................

78


8

Abstract


The Internet has become an important source of information with

the advent of the
Information Age.
Nevertheless, searching

for

the correct piece of information from the
World Web Web (WWW)
can
cause numerous difficulties.
This is because online
information is designed for humans to read, not for machines to manipula
te meaningfully.
Manual intervention from humans is still required to sieve through documents found by
search engines in order to locate the desired information.


This project addresses the problems
with the current information retrieval
method
used
by se
arch engines on the Internet
. The
solution

to the problems

is

to adopt

Semantic Web
technology in implementing a smart and versatile

ontology
-
based

search tool that
can

comprehend the underlying meaning of lexical resources posted to it
.


The main aim of

this project is to build such a tool to locate projects offered in the Department of
Computer Science. There are

abundant

of

ontology languages and tools, knowledge base
management tools, ontology query languages and APIs

due to the proliferation of
Sema
ntic Web technology. This project investigates the different options available and
also the via
bility of linking ontology into
an information retrieval system
.

The search
tool produced utilises Protégé
-
OWL to build OWL ontology and makes use of Jena
RDQL

framework for ontology query.





9

Declaration


No portion of the work referred to in this thesis has been submitted in support of an
application for another degree or qualification at this or any other university or other
institute of learning.



10

Copyrigh
t


Copyright in text of this thesis rests with the Author. Copies (by any process) either in
full, or of extracts, may be made in accordance with instructions given by the Author and
lodged in the John Rylands University Library of Manchester. Details may
be obtained
from the Librarian. This page must form part of any such copies made. Further copies (by
any process) of copies made in accordance with such instructions may not be made
without the permission (in writing) of the Author.


The ownership of any i
ntellectual property rights which may be described in this thesis is
vested in the University of Manchester, subject to any prior agreement to the contrary,
and may not be made available for use by third parties without the written permission of
the Univer
sity, which will prescribe the terms and conditions of any such agreement.


Further information on the conditions under which disclosures and exploitation may take
place is available from the head of Department of Computer Science.



11

Acknowledgement


I wou
ld like to acknowledge the help and support given by my supervisor Prof. Alan
Rector, and thank him for his enthusiasm and guidance throughout the project. I would
like to thank my partner of this project,
Miss
Sher Min Yoong for her continuous support
an
d help. Besides that I would also like to express my gratitude towards Sean Bechhofer,
Matthew Horridge and the CO
-
ODE research group members for answering my
questions about Protégé
-
OWL, COHSE and RDQL. Finally, I would like to thank the
Commonwealth Sc
holarship Commission for sponsoring my MSc studies and my family
for their moral support.



12

1

Introduction

1.1

Motivation for
Semantic Web Enabled Search


With the advent of the Information Age, the World Wide Web

(WWW)

has acted as
the
source of
boundless
infor
mation.
Nevertheless, searching

for

the right piece of
infor
mation on the Web often
turns

out to be a

dreadful

experience

due to information
overloading
. One will get lost with the huge amounts of irrelevant results returned by
search engine
s

and miss th
e relevant piece of information [11].
Efficient and accurate
information retrieval across the
WWW
is still a main challenge today. This is because
online information

is designed for humans

to read
, not for machines to manipulate
meaningfully. Manual int
ervention from human
s

is still required to sieve through
documents found by search engines in order to
locate

the
desired

information.

[1,

11
,

29
]



The most common method adopted by search engines is keyword search. Unless the
creator of the Web page spe
cifies the set of keywords probably through the use of Meta
tags, it is totally up to the search engine to determine what content in a Web page should
be classified as keywords.

Essentially, the search engines
must

extract and index words
that seem to be
significant.

For instance, more weight will be given to words included in
the title of a page; words appear at the beginning of a document or words that frequently
repeated.


There are a numerou
s problems with keyword search. Search engine cannot retur
n hits
on keywords that have the same meaning but are not actually entered in the
original
query. For example

a query on the word
“O
range”

will not return any document that
contains the word
“Jaffa”

(
large orange, especially one that comes from Israel
)
.

This
problem can be solved by incorporating synonyms from WordNet into the o
riginal query
[29
].
However
,
this query mechanism still suffers from the ambiguities and inability to
fully comprehend the underlying
semantics

of the lexical resources. Assuming

that a
query “
Orange mobile phone”

is posted to
a

search engine, the search engine doesn’t

13

know
either

the query means
“Find me websites that sell mobile phones that utilise the
network provided by Orange


a mobile telecommunication provider”

or
“Find me

websites that sell mobile phones
that are

orange in colour”
.

As a result, many irrelevant
hits will be returned. Hence,
the precision of keyword
-
based search is relatively low.

Furthermore,
keyword search also couldn’t solve complex queries that acqui
re
background knowledge, for instance

list all the animals that use sonar but are
neither
bats nor

dolphins


[
20
].


In view of the problems mentioned above, smarter and more versatile search capabilities
can be
accomplished

through Semant
ic Web
-
enabled se
arch engines [29
].


The Semantic
Web
is
a term coined

by Berners
-
Lee as an extension of the current Web, in which
information is given well
-
defined meaning, better enabling computers and people to work
in cooperation [1].
The Semantic Web will provide an
infrastructure that enables not
only web pages, but as well as databases, services, programmes, sensors, personal
devices, and even household appliances to both consume and produce data on the Web.

Software agents in return can utilise this i
nformation to

perform search function and
produce new information to assist the Web users
[16
].


The fundamental goal of the Semantic Web

is to convert the current structure of the Web
as a data storage (interpretable by only humans that are able to put the data into

appropriate context) into a structu
re of information storage
, i.e. information that can be
interpreted by machines

[
1,
9
].
In order to achieve this goal,
metadata, data that contains
the semantics and the context must be added into the raw data.

This
re
qu
ires the
extensive use of Knowledge Representation

(KR)
.

The fund
amental concept from
KR

that acts as the heart

of Semantic Web is ontologies.

One of the aim
s

of Semantic Web is
to link the current web pages to ontologies.


An ontology is

a
collection

of terms and relationship between the terms that describe a
particular application domain [9
].
A typical

Web ontology consists of
a

taxonomy and a
set of inference rules [1].
Taxonomy defines the important classes (concepts) and
relationships between cla
sses in a particular domain.
The inference rules are established

14

using mathematical logic or description logic to combine known knowledge to deduce
new knowledge. For example, if A is a parent of B and A is a female, then A is the
mother of B.

The capab
ility to infer such knowledge is the gist of Semantic Web.


Ontologies can be used to enhance Web searches by looking for documents that refer to a
precise concept rather than pages that r
efer to ambiguous keywords [1, 38
].
This can be
performed through c
oncept
-
based search.
In this scenario, the ontology is used as
metadata for indexing into a repository of information. Web users select terms they
are
interested from the ontology and a specialized search engine will locate the relevant
pages in a
reposi
tory based on the terms [38
].

Furthermore, ontologies can greatly
improve recall and preci
sion of a search application. [23
]



Many research projects

have been carried out to build ontology
-
enhanced search tools.
One of the commercial products that make
use of Semantic Web is Semagix Freedom. It
is an application development platform that utilises the Semantic Web technology to
build
smart enterprise applications and ontolo
gy
-
driven information system
s

[33, 34
].
Apart from this, another project carried
out by the Standard University with collaboration
from AT&T Solutions and Allegheny Hospital also made use of ontology to improve the
search experience for primary care physicians who intend to find relevant online
literature

to support patient treatment [
23
].


The real challenge of Semantic Web is to standardise a language that can represent
reasoning for both data and rules and at the same time allows rule from any existing KR
system to be exported onto the Web [1].
Some of the ontology languages devel
oped
includes SHOE, RDF, DAML, DAML+OIL and most recently OWL.
OWL is a
recommendati
on by W3C as of 10 February 2004
.

The comparisons among the features
of different ontology languages will be discussed in more details in Chapter 2.


15

1.2

Project Objective


T
he main objective of this project is to investigate with the abundant ontology languages
and tools, knowledge base management tools, ontology query languages and APIs
through small experiments.
A set of suitable ontology language, tools and APIs will be
s
elected based on the result of the experiments in order to build a tool

to

ease the search
of MSc
. projects offered by the D
epartment of Computer Science.


The second objective is to evaluate the latest ontology language, namely Web Ontology
Language (OWL)

and Protégé
-
OWL plugin, the tool used to build OWL ontology.
Protégé
-
OWL plugin is still being actively developed by the Standard University. This
project can be used as the “guinea pig” to test the capability of this tool.


Finally,
it is essential to
determine the viability of Semantic Web technology.
It is
important to know how ontology differ
s

from a database approach in terms of searching
and

how practical is it to build ontology

from scratch.




1.3

Project Definition and Scope


The current MSc. proje
cts offered by the Department of Computer Science

are static
HTML pages.
Students are unable to search the projects based on their preferred
criterion.
Hence, there is a need to build a search

tool to achieve a smart search; a search
that matches the stu
dents’ interests and capable to show projects that are related to their
interests.


At first glance, database

driven search

seems to be able to solve this problem

by attaching
keywords to each project pages
. Nonetheless,
database is not smart enough to de
duce the
rel
ationship between two projects. For example, project
ALR5 is related to Semantic
Web,
projec
t MR1 is related to Data Mining and project IPG4 is related to Process
Modelling; Semantic Web and Data Mining are both subjects from Artificial Intell
igence;

16

Process Modelling is a subject of Information Systems; Semantic Web at the same time is
also a subject of Information Systems.

A SQL query
cannot
find

whether project ALR5 is
related to
MR1
because both of them are projects

that are indirectly

rela
ted to
Artificial
Intelligence
.

Similarly,
a SQL query also cannot discover that ALR5 is also related to
IPG4

because both of them have indirect
relation

to Information Systems.


In view of th
is,
an ontology
-
driven search would be able to solve the proble
m
.

An ontology that is
capable to describe the projects needs to be built
to accomplish the task.


The functionalities in this ontology
-
driven search tool cater for both users and
administrator. The features
covered

in the user side including the followi
ng:

i.

Browsing: A form of conceptual retrieval. Users are able to browse projects
based on concepts from the ontology, for instance browse by Computer Science
subjects, supervisor, research group, degree category, and etc.

ii.

Searching:
Users are able to searc
h for projects based on a combination of
criterion like supervisor name, related subject, pre
-
requisite, research group,
degree category,

industrial collaboration,

and etc.

iii.

O
ntology visualisation: Users are able to view all the projects related to each
pr
oject through
ontology visualisation.
The related projects will be depicted in a
graph

(arc
-
node diagram)

applet.

The functionality

for the administrator is the
instance

maintenance

in the knowledge base
.
The administrator is able to edit, delete or crea
te new individuals in the knowledge base.


1.4

Division of Work


Since this is a joint project, the division of work between two members is rather flexible.
This is because many of the experiments are carried out parallel by two members to boost
the progress
of the project as well as to enhance peer learning.
If one member encounters
problem, another member will be able to immediately give help so that the overall
progress will not be delayed too much.


Basically, the division of work is according to the laye
r of the proposed architecture.


17

Task

Assigned To

Ontology Building

Author

Knowledge base management structure
building and inferencing

Sher Min

Yoong

Ontology browsing

Sher Min

Yoong

Querying code for search

Author

User interface coding for search

(
JSP
pages)

Both

Administration of knowledge base,
including adding, deleting and updating of
instances in the knowledge base.

Both

Table
1
.
1
: Division of Work


The tasks assigned to the author are more focused on ontology building. Hence, this
thesis

places more emphasis on ontology related issues, for example survey of different
ontology languages, ontology
tools, ontology development and querying from ontology.


1.5

Thesis Outline


Literature Survey
,
Chapter 2 cover
s

the
literature survey

on
the variety of
ontology
languages and the corresponding tools as well as the different options for ontology query
language
s
.

This chapter compares among all the choices for ontology languages and
tools. The most suitable option will be picked based on the comparison.


Proposed Architecture/Design, Chapter 3 includes a
n

architecture diagram for the
proposed solution, the des
ign issues and a list of specification for all the tools and APIs
used.

Ontology Development, Chapter 4 illustrates the major steps and different
approaches taken to develop the ontology for this project.


Implementation, Chapter 5 covers search function
and
admin function for project
management
. These include

brief discussion about

UI

design and coding in RDQL
, JSP
and Java classes. Testing and Evaluation, Chapter 6 presents an experiment and
evaluation
that has been done to the system. Finally, Concl
usion and Future Work,

18

Chapter 7 summarises the outcome of this project
, challenges encountered

and presents
the future work that can be done to enhance the system.


19

2

Literature Survey


This chapter begins by discuss
ing different species of on
tology languag
es
. It t
hen covers
the different varieties

of ontology languages and tools that can be considered for real
implementation. Finally, the different varieties of ontology query language
s

are
discussed in details and comparisons
of ontology query languages
a
re made

to decide the
best option
.


2.1

Ontology Language
s

and
Ontology Tools

2.1.1

Species

of Ontology Language
s


In the past few years, many ontology languages have been invented, with varying
characteristics in terms of expressiveness, ease of use and computation
al complexities.

2.1.1.1

Frame
-
based Languages


Frame
-
based languages make use of frames (classes) as structures for representing
concepts or objects.
There are a collection of properties known as attributes attached to
the frames.
The scopes of these attributes

are local instead of global. These attributes are
only applicable to the
classes they are defined for [2
].
Frame based ontology
representation is analogous to object
-
oriented systems
and

are easy to comprehend.
This
is the reason explaining the popular
ity of frame
-
based languages amongst users.
Nevertheless
, frame
-
based languages do suffer from a lack of well
-
defined semantics.
Due to this, automatic classification and reasoning is very troublesome in frame
-
based
systems.

2.1.1.2

Description Logics


Descripti
on Logics

(DLs)

describe knowledge through the use of concepts and role
restrictions as their modelling primitives.

They are a subset of first order logic that

20

facilitates reasoning and automatic classification of class hierarchies.

DLs are in fact
fragm
ents of decidable first order logic with more limited expressiveness.
DLs allow the
definition of classes in terms of descriptions that specify the properties fulfilled by
obje
cts belonging to the concept [2
]. Unlike frame
-
based representation, p
ropertie
s are
defined on
global scope.
Default
, DLs provide various form
s

of concept forming
operators such as conjunction, disjunction, negation and other forms of role
quantification.
The main

advantage
s

of DLs
are

their formal semantics and the ability to
sup
port reasoning.


2.1.2

RDF/
RDF(S)

-

Resource Description Framework (Schema)


RDF is a specification providing infrastructure to support metadata on the World Wide
Web. It

is developed by W3C

for encoding, exchange and reuse of structured metadata.
RDF provid
es a standard form for representing metadata

(data about resources on the
web, for example the author, date of creation and so on)

in XML.


The RDF data model consists of three object types:
resources
(subjects)

are described by
RDF expressions and are
u
sually

named by URIs plus optional anchor IDs;
properties

(predicates) define specific aspects, characteristics attributes, or relations used to describe
a resource; and
statements

(objects) assign a value for a property in a specific resource
(this value
mig
ht be another RDF statement) [14
].

RDF statements are called triples

<subject, predicate, object>
.


The subject of one statement can be the object of another. Such collections of RDF
statements can be illustrated as nodes and arcs diagram (a form of d
irected, labelled
graph). The nodes (ovals) represent resources. The arcs represent named properties.
String literals are represented by rectangles.
The following
example:
“The person
referred to by
staff

id 98101552 is named Brian Vokes and has the em
ail address
brian@man.ac.uk. The resource http://www.man.ac.uk/~brian was created by this
person.”

can be represented as
graph in figure 2.1
.


21










Figure
2
.
1
: Example of node
-
arc diagram representing
RDF statements


In RDF
syntax
, Figure 2.1

is represented as follow:

<
?xml version=”1.0”?>

<rdf:RDF “xmlns:rdf=”http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#”


xmlns:p=”http://somewhere.com/schema/”>




<rdf:Description about=”http://www.man.ac.uk/~
brian”>


<p:createdBy rdf:resource=http://www.man.ac.uk/staffId/98101552/>


</rdf:Description>




<rdf:Description about=”http://www.man.ac.uk/staffId/98101552”>


<p:Name>Brian Vokes</p:Name>


<p:Email>brian@man.ac.uk</p:Email>


</rdf:Descript
ion>


</rdf:RDF>

Figure
2
.
2
: RDF syntax


RDF gives a formalism for metadata annotation written in XML format.
However
, it
does not define the semantics of any application domain. RDF does not provide a
me
chanism to define the relationship between properties and resources. In order to do
this, RDF Schema

Specification Language

(
RDF(S)
) plays the role.
RDF(S)

is the type
system for RDF.

RDF(S)

offers primitives for defining knowledge models that are clos
e
r
to frame
-
based approaches [14
].


RDF(S)

can be used directly to describe ontologies, although its main intention is no
t for
ontology specification
but for representing the relations between properties and resources
http://www.man.ac.uk/~brian

Brian Vokes

brian@man.ac.uk

Name

Email

http://www.man.ac.uk/staffid/98101552

createdBy


22

on the Web
[35
].


RDF(S)

provides the b
asic
modelling

primitives such as class, property
and constraint property

(they are all resources)

for defining ontology.
For example, terms
such as ‘Class’, ‘Property’, ‘subClassOf’ and ‘subPropertyOf’ are used to organized
properties and classes into hi
erarchies. Vocabularies such as ‘domain’ and ‘range’
are
used to specify constraints on properties. Therefore, it is evident that the using
RDF(S)

vocabularies can produce a simple ontology language.











Figure
2
.
3
:
RDF(S)

modelling primitives [39]


Property name

Description

Domain

Range

rdfs:isDefinedBy

Indicates the namespace of a resource

Resource

Resource

rdf:subject

The subject of a

RDF statement.

Statement

Resource

rdf
:predicate

The predicate of a

RDF statement.

Statement

Property

rdf:object

The object of a

RDF statement.

Statement

Not specified

rdf:type

Indicates membership of a class

Resource

Class

rdfs:member

A member of a container

Container

Not specified

rdfs:subClassOf

Indicates membership of a class

Class

Class

rdf:value

Identifies the principal value (usually a
string) of a property when the property
value is a structured resource

Resource

Not specified

rdfs:subPropertyOf

Indicates specialis
atio
n of properties

Property

Property

rdfs:comment

Use this for descriptions
/annotations

of
resources

Resource

Literal

rdfs:label

Provides a human
-
readable resource
name.

Resource

Literal

rdfs:domain

A domain class for a property type

Property

Class

rdfs:range

A range class for a property type

Property

Class

Class

rdfs:Resource

r
dfs:Class

rdsf:Property

rdfs:ConstraintProperty

rdfs:Literal

ConstraintProperty

rdfs:range

rdsf:domain

Property

rdf:type

rdfs:subClassOf

rdfs:subPropertyOf

rdfs:comment

rdfs:l
abel

rdfs:seeAlso

rdfs:isDefinedBy


Resource


23

rdfs:seeAlso

A resource that provides information
about the subject resource

Resource

Resource

Table
2
.
1
:
RDF and
RDF(S)

properties


Nonetheless

RDF(S)

has a relatively limited expressive power
.

Some of the limitations
are:



No local scope of properties:
rdfs:range

could not declare range restrictions that
apply to some clas
ses only. For example, it is not possible to say that cows eat
only plants, while other animals may eat meat because
rdfs:range

defines the
range for all classes.



No axiom definitions: Axioms cannot be defined directly. For example, the
disjointness of f
emale and male cannot be expressed in
RDF(S)
.



No cardinality restrictions:
It is not possible

to specify the restrictions on how
many distinct values a property may or must take in
RDF(S)
. We cannot say a
person has exactly two parents in
RDF(S)
.



Special
characteristics of properties: No transitive, inverse or symmetrical
properties can be expressed in
RDF(S)


2.1.3

DAML+OIL
-

Darpa Agent Markup Language + Ontology
Infer
ence Layer


DAML+OIL [7
] has been developed by a joint committee from the United States and
the
European Union (IST) in the context of DAML, a DARPA project for allowing sem
antic
interoperability in XML. The name DAML+OIL
implies

that there is a close relationship
with OIL.
It is a new language evolved from the initial specification called DAML
-
ONT
with inclusion of features from OIL.


DAML+OIL is built based on RDF and RDF Schema, but provides richer mode
l
ling
primitives, commonly found in description logics.

Since DAML+OIL kept the OIL’s
mapping to description log
ics, this has made DAML+OIL

beco
me
s

a very expressive
language with well
-
defined semantics and
the ability to support reasoning
.

Most of the

24

frame
-
based approaches
available in OIL were removed and assertions are made in term
s
of a limited set of axioms [35
].


DAML+OIL built on RDF
(S) by extending the expressivity power. The following list
shows some of the extended features:



Constraints (restrictions) on properties of classes, for instance introduce the use of
quantifier (existential and universal) and cardinality



Boolean combinat
ions of classes and restrictions, for example

union, intersection
and complement
.



Class axioms
such as

equivalence, disjointness and coverings.



Complete classes (necessary and sufficient conditions) and partial classes
(necessary conditions)



Constraints on

properties

The most important feature added is the support for automated reasoning. The reasoner
can be used to automatically classify asserted classes and able to detect inconsistencies in
the ontology when wrong definition of classes occur.


The follow
ing table summarises some important features used in DAML+OIL ontology
construction.

Element

Description/Example

Namespace

rdf:RDF

element is used to specify the namespaces. Similar to the one
used in RDF.

Class

d
aml:Class

is used for class definition.

Example:

<daml:Class rdf:ID="Animal"/>

<daml:Class rdf:ID="Male">


<rdfs:subClassOf rdf:resource="#Animal"/>

</daml:Class>

Property

daml:ObjectProperty

relates objects to other objects. Example:

<daml:ObjectProperty rdf:ID=“activity”>


<rdfs:domain
rdf:resource=“Person”>


<rdfs:range rdf:resource=“ActivityArea”>

</daml:ObjectProperty>

daml:DatatypeProperty

relates objects to datatype values. Example:

<daml:DatatypeProperty rdf:ID=“emailAddress”>


<rdfs:domain rdf:resource=“Person”>


<rdfs:ra
nge
rdf:resource=“http://www.w3.org/2001/XMLSchema/String”/>

</daml:DatatypeProperty>

Property
daml:Restriction

is used to specify restriction on properties. It always

25

restrictions

contain the element
daml
:onProperty

to specify which property to
define t
he restriction and follow by either of the following operator:



dam
l:hasValue



states the specific value of the property



dam
l:
toClass



universal quantifier



daml
:
hasClass



existential quantifier



daml
l:minCardinality



daml
:maxCardinality



dam
l:Cardinality

E
xample:

<daml
:Class rdf:about=“#firstYearCourse”>


<rdfs:subClassOf>


<daml
:Restriction>


<daml
:onProperty rdf:resource=“#isTaughtBy”/>


<daml
:
toClass

rdf:resource=“#Professor”/>


</daml
:Restriction>


</rdfs:subClassOf>

</dam
l:Class>

Spe
cial
properties

Some special properties can be defined directly by:



daml
:TransitiveProperty



defines a transitive property like “is
ancestor of”.



daml
:SymmetricProperty



defines a symmetric property like “is
sibling of”.



damll:Unique
Property



defines a
property that has at most one
unique value for each object such as “age”.



daml
:inverseOf



one property is inverse of another, for example
“producedBy” and “manufactory”



daml
:
Unambiguous
Property



defines a property for which two
different objects cannot
have the same value, for example student
ID.

Boolean
combinations

Boolean combinations (union, intersection, complement) of classes can
be expressed by using the following operators:



daml:unionOf



daml:disjointUnionOf



daml:complementOf



daml:intersectionOf

Table
2
.
2
:

Some features from DAML+OIL


2.1.4

OWL
-

Web Ontology Language


O
WL [22
] is the successor of DAML+OIL. It has been developed by the Web Ontology
Working Group as part of W3C Semantic Web Activity.

OW
L

is also an extension of
RDF(S). The following figure shows the evolution of ontology languages to form this
new language.


26













Figure
2
.
4
:

Ontology Languages and OWL


OWL

has a layered architectur
e with successive layers providing more expressivity. The
layers form
three sublanguages

of

OWL
.









Figure
2
.
5
:
Three sublanguages of OWL


The three sublanguages are:



OWL Full:

The entire language is

called OWL Full, and make use of all the
language primitives in OWL.
OWL Full also corresponds to RDF(S).

OWL Full
allows an ontology to alter the meaning of the pre
-
defined (RDF or OWL)
primitives.

The advantage of OWL

Full is that it is fully compatib
le with RDF;
any legal RDF document is also a legal OWL Full document. The disadvantage
of OWL Full is
that there
are

no computational guarantees. Hence, it is not
possible to support complete reasoning for
all the

feature
s

available in

OWL Full.

Full

DL

Lite

DAML

OIL

DAML+OIL

RDF(S)

OWL

(standardized
by W3C)


27



OWL DL:

In order to improve computational efficiency, OWL DL (DL stands for
Description Logic) is a subset of OWL Full which restricts the way the
construct
or
s from OWL and RDF can be used. The advantage of OWL DL is

that

it makes use of the maximum expressivity

while retaining computational
completeness (all conclusions are guaranteed to be computable) and decidability
(all computations will finish in finite time). The disadvantage of OWL DL is that
it is not fully compatible with RDF.



OWL Lite:

OWL Lite has fu
rther restrictions limits in terms of language
constructors’

usage.
For instance, in terms of cardinality constraints, it only
allows cardinality values of 0 or 1.
The advantage of OWL Lite is that it is easier
to understand and to implement. The disadv
antage is
the

restricted expressivity.


The three sublanguages are upward compatible, which means:



Every legal OWL Lite ontology is a legal OWL DL ontology.



Every legal OWL DL ontology is a legal OWL Full ontology.



Every valid OWL Lite conclusion is a vali
d OWL DL conclusion.



Every valid OWL DL conclusion is a valid OWL Full conclusion.

The language features for OWL Full, OWL DL and OWL Lite are included as reference
in Appendix

A
.

OWL still utilizes RDF(S) extensively:



all varieties of OWL use RDF as thei
r syntax



instances are declared as in RDF, using RDF descriptions and typing information



OWL constructors like owl:Class, owl:DatatypeProperty and owl:ObjectProperty
are subclasses of their counterparts in RDF.

This is shown in figure 2.6
.







Figure
2
.
6
:

Subclass relationships between OWL and RDF(S)


rdfs:Resource

rdfs:Class

rdfs:Property

owl:Class

owl:ObjectProperty

owl:DatatypeProperty


28

Since OWL is built on RDF(S), it follows RDF’s XML syntax.
The following table
summarises some important language primitives used in OWL ontology construct
ion.

Element

Description/Example

Header


rdf:RDF

is used to specify namespaces used in the ontology


owl:Ontology

contains version information and inclusion of other
ontologies. Example:

<owl:Ontology rdf:about=“”>

<owl:priorVersion rdf:resource=“http:/
/somewhere.com/old
-
schema”/>

<owl:imports rdf:resource=“http://somewhere.com/person
-
schema”/>

</owl:Ontology>

Class

owl:Class

is used for class definition. Example:

<owl:Class rdf:ID=“Wine”/>

There are many operators available to express a class in mor
e details.



owl:disjointWith



owl:equivalentClass



owl:unionOf



owl:intersectionOf



owl:complementOf

Example:

<owl:Class rdf:ID= “Female”>


<owl:disjointWith rdf:resource= “Male”>

</owl:Class>

Property

owl:ObjectProperty

relates objects to other objects. Ex
ample:

<owl:ObjectProperty rdf:ID=“activity”>


<rdfs:domain rdf:resource=“Person”>


<rdfs:range rdf:resource=“ActivityArea”>

</owl:ObjectProperty>

owl:DatatypeProperty

relates objects to datatype values. Example:

<owl:DatatypeProperty rdf:ID=“emailA
ddress”>


<rdfs:domain rdf:resource=“Person”>


<rdfs:range
rdf:resource=“http://www.w3.org/2001/XMLSchema/String”/>

</owl:DatatypeProperty>

Property
restrictions

owl:Restriction

is used to specify restriction on properties. It always
contain the elem
ent
owl:onProperty

to specify which property to define
the restriction and follow by either of the following operator:



owl:hasValue



獴慴s猠瑨e⁳灥c楦楣⁶a汵攠潦⁴桥⁰r潰o牴y



owl:allValuesFrom



畮楶敲獡氠煵慮瑩晩lr



owl:someValuesFrom



ex楳ie湴na氠煵慮瑩
晩fr



owl:minCardinality



owl:maxCardinality



owl:Cardinality

Example:

<owl:Class rdf:about=
“#firstYearCourse”>


<rdfs:subClassOf>


<owl:Restriction>


29


<owl:onProperty rdf:resource=
“#isTaughtBy”/>


<owl:allValuesFrom rdf:resource
=
“#Professor”/>


</owl:Restriction>


</rdfs:subClassOf>

</owl:Class>

Some special properties can be defined directly by:



owl:TransitiveProperty



defines a transitive property like “is
ancestor of”.



owl:SymmetricProperty



defines a symmetric property like “is
sibli
ng of”.



owl:FunctionalProperty



defines a property that has at most one
unique value for each object such as “age”.



owl:inverseOf



one property is inverse of another, for example
“producedBy” and “manufactory”



owl:InverseFucntionalProperty



defines a p
roperty for which two
different objects cannot have the same value, for example student
ID.

Enumerations

An enumeration is a
owl:oneOf

element used to define a class by
listing all its elements. Example:

<owl:oneOf
rdf:parseType=
“Collection”>


<owl:Thin
g rdf:about=
“#Sunday”>


<owl:Thing rdf:about=“#Monday”>


<owl:Thing rdf:about=“#Tuesday”>


<owl:Thing rdf:about=“#Wednesday”>


<owl:Thing rdf:about=“#Thursday”>


<owl:Thing rdf:about=“#Friday”>


<owl:Thing rdf:about=“#Saturday”>

</owl:oneOf>

I
nstances

Instances of classes are declared as in RDF. Example:

<Person rdf:ID=

“John”>


<name>Johnny English</name>


<age><xsd:integer rdf:value= “30”/></age>

</Person>

Table
2
.
3
:
Some features in OWL


30

2.1.5

Comparison of
RDF(S)
, DAML+OIL and OWL



Language

Feature

RDF(S)

DAML+OIL

OWL

Bounded lists


X

X

Cardinality constraints


X

X

Class expressions


X

X

Data types


X

X

Defined classes


X

X

Enum
erations


X

X

Equivalence


X

X

Extensibility

X

X

X

Formal semantics


X

X

Inheritance

X

X

X

Inference


X

X

Local restriction


X

X

Qualified constraints


X


Reification

X

X

X

Table
2
.
4
:

Comparison of O
ntology Languages

[7
]


OWL is chosen as the ontology language for this project due to several reasons.
Firstly,
OWL is part of the growing stack of W3C recommendations related to the Semantic Web.
It has been recently standardised by W3C on 10 February 2
004.

Secondly, it is a
successor of DAML+OIL which means it has improved features from DAML+OIL.
Thirdly, OWL provides three increasingly expressive sublanguages i.e. OWL Lite, OWL
DL and OWL Full designed for use by specific communities of implementers

and users.
Ontology developers are able to choose the
preferred

sublanguage that best suits their
needs.




31

2.1.6

Ontology
Tools


2.1.6.1

WebODE


WebODE [40
] is web
-
base Ontology Development Environment (ODE) developed by the
Knowledge Reuse Group, at the Technica
l University of Madrid.
WebODE is built on
three
-
tier
architecture
: the
client

(user interface)
, the application server

(business logic)
,
and the database management system

(data)
.


The main constructs of the WebODE
knowledge model are: concepts, groups

of concepts, relations, constant and instances.


Some of the unique features provided by WebODE including

[40]
:



Support for multiple
-
users.



Guided conceptualisation through the use of a very intuitive and simple user
interface.



Customisation capabilitie
s by means of templates.



Complete consistency checks to assure the ontology contains valid knowledge.



Easy taxonomy edition either by using a form based user interface or a more
complex and powerful graphical editor (OntoDesigner)



Instance handling inde
pendent from the ontology conceptualisation.



API available for accessing ontologies from any application using RMI or
CORBA.



Maximum interoperability through use of XML.


2.1.6.2

Protégé
-
2000


Protégé
-
2000 [36
] is an integrated and platform
-
independent system f
or development and
maintenance of knowledge
-
base systems.

It is developed by Stanford Medical
Informatics at the Stanford University.
It is a tool used to create concept hierarchies and
instances that are viewable from several formats.

It is built using

open
-
source
technologies
and has a
plugin
-
based

architecture.
There are many plugins being

32

developed for Protégé
-
2000 to extend its functionality and to support more formats. For
instance, there are plugins for OWL, RDF(S), DAML+OIL, Topic Map, UML, XML

and
XMI.
The most important plugin developed is Protégé
-
OWL plugin that
support editing
Semantic Web ontologies in OWL format.

The Protégé OWL Plugin enables the
following functions:



Load and save OWL and RDF ontologies



Edit and visualise OWL classes a
nd their properties



Define logical class characteristics as OWL expressions



Execute reasoners such as description logic classifiers



Edit OWL individuals for Semantic Web markup


2.1.6.3

OntoEdit


OntoEdit

[27
]

is an Ontology Engineering Environment supporting
the development and
maintenance of ontologies by using graphical means. OntoEdit is built on top of a
powerful internal ontology model.

OntoEdit is developed by Ontoprise and available free
in a standard and a professional version.

OntoEdit

allows the us
er to edit a hierarchy of
concepts or classes. Thes
e
concepts may be abstract or concrete, which indicates whether
or not it is

allowed to make direct instances of the concept. A concept may have several

names

(aliases)
, which essentially is a way to defin
e synonyms for that concept.


The tool is based on a flexible plug
-
in framework. Firstly
,

this allows

the functionality to
be extended easily

in a modularis
ed way. The plug
-
in interface is open
ed

to

third parties
where

users
are able to

extend OntoEdit eas
ily by
adding

needed functionalities.
Secondly, having a set of plug
-
ins available
such as,

a

domain lexicon, an inferencing
plug
-
in and several export and import plugins,

allows for user
-
frie
ndly customis
ation to
adapt the
tool to different

usage scenario
s.



33

2.1.6.4

OilEd


OilEd [26
] is a development tool for OIL and DAML+OIL ontologies developed by the
University of Manchester.
It is initially designed to be a demonstration tool for OIL
language.
The current version

of
OilEd

does not provide a full ontology de
velopment
environment. It does not actively support the development of large
-
scale ontologies, the
migration and integration of ontologies, versioning, argumentation and many other
activities that are involved in ontology construction. It
only offers

enoug
h functionality to
allow users to
build ontologies. It incorporates

with

a reasoner (FaCT) for onotologies
consistency checking.


2.1.6.5

Comparison of
WebODE, Protégé
-
2000, OntoEdit and OilEd


Ontology Tool

Feature

WebODE

Protégé

OntoEdit

OilEd

Capabilities

Cr
eate concept
hierarchies and
instances.

Create concept
hierarchies and
instances in
several

formats.
Integrate with
common
database.


Create concept
hierarchies and
instances.
Integrate with
common
databases.


Create concept
hierarchies and
instances;
an
alyze

Semantic
consistency
(according

to
DL).

Persistency

Server storage

Local storage

Local storage

Local storage

Web
-
based

Yes

No

No

No

Import

XML, OWL,
DAML+OIL,
UML, RDF(S)

CLIPS, RDF(S),
OWL (other
formats depend
on the installed
plugins)

F
-
logic,

DAML+OIL,
RDF(S), OXML

DAML+OIL
,
OWL, GO, OIL,
SHIQ

Export

XML, RDF(S),
OIL, OWL,
DAML+OIL,
UML, Prolog

RDF(S), OWL,
CLIPS
, (other
formats depend
on the installed
plugins)

F
-
logic,
DAML+OIL,
RDF(S)
, OXML

RDF
(S)
,
DAML+OIL,
OWL
, FaCT
Lisp, HTML,
SHIQ

Synt
atic quality

Error prevention

Error Detection

Error prevention

Weak

Consistency
checking

Good

Weak

Good

Good

Tutorial

Yes

Yes

Yes

Yes

Visualisation

Good

Good

Good

Good

Table
2
.
5
:

Comparison of ontology tools


34


Protégé
-
2000 is chosen as the ontology tool for this project because of its good support
for OWL through Protégé
-
OWL plugin. The plugin is updated from time to time to
ensure a better suppo
rt and correction of detected bugs.

Protégé is being actively
developed and
provides strong support for users through forum discussion. I
t is a good
tool to use for building Semantic Web ontologies.

Furthermore, the Department of
Computer Science has ac
tively participated in the development of
Protégé
-
OWL plugin
,
so that

is worth to investigate the capabilities of Protégé
-
OWL plugin.


2.2

Ontology Query Language
s


Ontology language
s

are

used to represent the ontology schema and the knowledge base.
Similar t
o database
s
, there is a need to access and
manipulate

the ontology schema and
knowledge base programmatically.
O
ntology query language
s

are

invented for such
purpose. Ontology query language
s

are

analogous to SQL where
it is used to retrieve
information fr
om ontologies (ontology schema and knowledge base)
.


T
he survey of ontology query language covers the query languages designed for RDF, i.e.
RQL and RDQL; and OWL
-
based query language, i.e. OWL
-
QL.
The main features of
each language are discussed in dep
th. A comparison among these languages will be
illustrated in a table at the end of this subtopic.

The best option will be chose

based on
the compared criterion.


2.2.1

RQL
-

The RDF Query Language


RQL [15
,

37
] is a RDF query language developed by ICS
-
FORT
H (Institute of Computer
Science
-

Foundation of Research Technology Hellas


Greece). It

is a typed language
following a functional ap
proach, which supports generalis
ed
path expressions featuring
variables on both nodes and edges of the RDF graph.
RQL r
elies on a formal graph
model that captures the RDF mode
l
ling primitives and permits the interpretation of

35

superimposed resource descriptions by means of one or more schemas

[37]
. The novelty
of RQL lies in its ability to smoothly combine schema and data
querying while exploiting
the taxonomies of labels and multiple classification of resources

[15]
.


The RQL Interpreter is implemented in C++ on top of an ORDBMS using standard
client
-
server architecture for Solaris and Linux platforms. It consists of four
modules

[37]
:

i.

Parser
: analyses the syntax of queries

ii.

Graph Constructor:

captures the semantics of queries in terms of typing and
interdependencies of involved expressions

iii.

SQL Translator
: rewrites RQL to efficient SQL queries

iv.

Evaluation Engine:

accesses t
he underlying database via SQL queries.


RQL APIs are available in two implementations, i.e. C API and Java API. C API can be
used by linking with the rqlc library whilst Java API can be used by linking with the
rqljni library.


RQL queries are construct
ed based on three clauses:
select
,
from

and
where
. RQL is
based on OQL
-
like syntax.

The BNF g
rammar of RQL is included in Appendix

B
.

The
following query retrieves
the names of the authors of publication X

is adapted from [15
]:

select PersonName

from
{X} s:author {y}. rdfs:member {z}. s:name {PersonName}

using namespace


s = http://www.aifb.uni
-
karlsruhe.de/WBS/pha/rdf
-
query/sample.rdf ,


rdfs = http://www.w3.org/2000/01/rdf
-
schema#


RQL

queries

support many features including:

(the exa
mples sho
wn are adapted from
[15
,

37
])



Duplicate elimination:

Duplicate results are eliminated through the use of “
select
distinct”
.



Namespace facilities:

For handling different schemas. The query namespaces
can be specified through the “
using
” construct.



Metasche
mas querying:

F
or schemas

browsing.

The following query finds all
properties defined on class Painter and its superclasses.


36

select p, range(p)

from DProperty{p}

where domain(p) >= Painter




XML Schema data types:

F
or filtering literal values
. The following

query returns
resources that are last modified after year 2000 and their modification dates.

select

x
,
y

from {x
}
last_modified{y
}

where y
>= 2000
-
01
-
01




N
ested
queries:

The sample query
searches for the most recent modified
resources using a nested querie
s.

select x, y

from {x}last_modified{y}

where y= max( select z from {w}last_modified{z})




A
ggregate functions
: RQL is equipped with the complete set of aggregate
functions (count, avg, min, max) for extracting statistics. The following query
counts the nu
mber of authors of a publication.

select count(author)

from s:Publication {pub}. s:author {z}. rdfs:member {author}

using namespace


s = http://www.aifb.uni
-
karlsruhe.de/WBS/pha/rdfquery/sample.rdf,


rdfs = http://www.w3.org/2000/01/rdf
-
schema#




Set ope
rations:

RQL supports basic set operations including union, difference and
intersection. The following RQL query returns the labels of all topics that are not
title of publications.

( select TopicLabel


from s:Topic{X}. rdfs:label {TopicLabel}

) minus (


select PubTitle


from s:Publication{X}. s:title {PubTitle}

)

using namespace


s = http://www.aifb.uni
-
karlsruhe.de/WBS/pha/rdfquery/sample.rdf,


rdfs = http://www.w3.org/2000/01/rdf
-
schema#




Q
uantification iterators:

RQL supports existential (exists) an
d universal (forall)
quantifiers.

The following example finds the persons who are authors of all
publication using both existential and universal quantifiers.

select person

from s:Person {person}

where forall Z in (select X from s:Publication {X})


such

that exists P in (select Y from {Z} s:author {}.
rdfs:member {Y})


37



such that person = P

using namespace


s =
http://www.aifb.uni
-
karlsruhe.de/WBS/pha/rdfquery/sample.rdf
,


rdfs =
http://www.w3.org/2000/01/rdf
-
schema#




Entailment

(inference):

RDF has a f
ormal semantics which provides a
dependable basis for reasoning about

the meaning of an RDF graph [15
]. This
reasoning is called entailment or inference. This means i
mplicit information
(subsumptions between classes and properties not specified explicitl
y in RDF) can
be inferred from explicit information based on entailment rules.

RQL provides
functions such as

subClassOf (X)
that returns all transitive subclasses of class X
which means it is able to deduce what are the direct and indirect descendents of

class X.


2.2.2

RDQL


RDF Data Query Language


RDQL [15, 32
]
is implemented as a
SQL
-
like query language for RDF.

It treats RDF as
data and provides query with triple patterns and constraints over a single RDF model.

It
is a language derived from SquishQL.

RDQL are implemented in the following
frameworks:



Jena (http://www.hpl.hp.com/semweb/jena.htm)



RDFStore (http://rdfstore.sourceforge.net/)



Sesame (http://sesame.aidministrator.nl/)



PHP XML Classes (http://phpxmlclasses.sourceforge.net/)



3Store (http://sou
rceforge.net/projects/threestore/)



RAP
-

RDF API for PHP (
http://www.wiwiss.fu
-
berlin.de/suhl/bizer/rdfapi/
)


RDQL consists of a graph pattern, expressed as a list of triple patterns.


Each triple
pattern is comprised of named variables and RDF values (URI
s and literals).


A RDQL
query can additionally have a set of constraints on the values of those variables, and a list
of the variables required in the answer set.
The syntax of RDQL
is very similar to SQL
.
The RDQL query is constructed based on the foll
owing clauses:
select, from(optional),

38

where, and(optional), using(optional)
.
The BNF grammar of RDQL is included in
Appendix

C
.

SELECT

Variables

FROM
Documents

WHERE

Expressions

AND

Filters

USING

Namespace declarations


Syntax

Description

SELECT

The sele
ct
clause

indicates the RDQL variables to be returned by the query.
Variables defined must start with a ‘?’, for example
select ?x, ?y?, ?z
.

FROM

The from clause indicates the RDF sources to be queried, each source is
enclosed by angle brackets ‘<source>
’.

WHERE

The where
clause

indicates constraints that RDF triples (subject, predicate,
object) must accomplish in order to be returned. The where part is expressed
by a list of restrictions separated by commas, each restriction takes the form:
(subject, p
redicate, object) where the subject, predicate and object can be a
literal value or a RDQL variable.

AND

The AND clause indicates constraints that RDQL variables must follow
.

USING

The using clause declares all the namespaces in the query, declarations a
re
separated by commas and use the notation:
prefix_name for
.

Table
2
.
6
:

Description of RDQL query syntax


The following example is adapted from Jena Tutorial. The query returns the age and
family name for persons that are above 24 years old from a RDF file called people.rdf.

SELECT ?person,

?
age, ?familyName

FROM <people.rdf>

WHERE (?person
<
info:age
>

?age)


(?person,
<
vCard:N
>

?y) , (?y, <vCard:Family>, ?familyName)

AND ?age >= 24

USING info FOR <http://somewhere/peopleInfo#>


vCard FOR
<
http://www.w3.org/2001/vcard
-
rdf/3.0#
>



Unlike RQL, there is no inference (entailment) being
performed

in RDQL
. RDQL is
"data
-
oriented" in that it only queries the information held in the models.

It is vital for an
ontology query language to support inference because the power of
S
emantic
W
eb lies on
the ability to deduce new knowledge from existing known ground facts.

However, many
RDQL frameworks provide inference API to accomplish this task.

For instance, Jena is
designed to support inference by allowing a range of inference engines or

reasoners to be
plugged into the framework.

The supported reasoners available in Jena are as follow
s

[21
]
:


39



Transitive reasoner:
Provides support for storing and traversing class and
property lattices. This implements just the
transitive

and
symmetric

pro
perties of
rdfs:subPropertyOf

and
rdfs:subClassOf
.



RDF(S)

rule reasoner:
Implements a configurable subset of the RDFS
entailments.



OWL FB Reasoner:
A useful but incomplete implementation of the OWL/Lite
subset of the OWL/Full language.



DAML micro reason
er:
Used internally to enable the legacy DAML API to
provide
RDF(S)

scale
inferencing
.



Generic rule reasoner:
A rule based reasoner that supports user defined rules.
Forward chaining, tabled backward chaining and hybrid execution strategies are
supported.



Many features supported in RQL are not available in RDQL. RDQL supports only
namespaces and XML schema data for literal processing.


2.2.3

OWL
-
QL


OWL Query Language


OWL
-
QL [12
] is a formal language and protocol for a querying agent

(client)

and an
answeri
ng agent

(server)

to use in conducting a query
-
answering dialogue using
knowledge represented in Web

Ontology

Language (OWL).

It is an extended version of
the DAML Query Language (DQL).
OWL
-
QL is developed by the Stan
ford Kno
wledge
Systems Laboratory, St
an
ford University.

Although OWL
-
QL is designed for use with
OWL,
it is designed to be prototypical and easily adaptable to other declarative formal
logic representation language including RDF(S) and DAML+OIL.


There are many features supported by OWL
-
QL,
many of them are very vital for
querying on the Semantic Web

[12
]
.


40



Heterogeneity:
Unlike ordinary Web query languages, OWL
-
QL include
s

the
kind of query
-
answering service that is capable to access many type of
information represented in various formats.



En
tailment (Inference):

The answering agent may use automated reasoning
methods to derive answers to queries.



Flexibility:
OWL
-
QL provides an adaptable query answering protocol which
both allows a server to return partial sets of answers as the answers are

computed
and allows a client to specify the maximum number of answers that it wants the
server to include in the next set of answers it sends to the client.



Autonomy:
A common use of the Semantic Web will be to send a query to a
server and expect the serv
er to select reliable knowledge sources from which to
produce answers. OWL
-
QL supports server selection of the knowledge base(s)
to be used in answering a query, and client requests that a server identify the
knowledge base(s) used in answering a query.



M
eta
-
specification:
OWL
-
QL is designed to be independent of the surface
syntax of the language.
The

OWL
-
QL

specification is stated at an “abstract”

or
structural level, allowing essentially the same language to be implemented in
multiple surface syntactic
forms.



Formal Description:
The OWL
-
QL specification includes a formal description
of the semantic relationships among a query, a query answer, and the knowledge
base(s) used to produce the answer.


An OWL
-
QL query
-
answering dialogue is initiated by a cli
ent sending a query to an
OWL
-
QL server.
An OWL
-
QL query
must comprises the following items:



A
query pattern