GrOWL-A Framework for Visualization and Editing of OWL Ontologies

economickiteInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

100 εμφανίσεις

GrOWL
-
A Framework for Visualization and Editing of
OWL Ontologies


Serguei Krivov, UVM

Richard Williams, NCEAS and RMBL

Ferdinando Villa, UVM


Abstract:


Formal ontologies have manifold applications. The language OWL (Ontology Web
Language) has recently
emerged as a prime candidate for the standard Semantic Web
ontology language. A number of editing tools have been made available to define,
integrate, and maintain OWL ontologies. Recognizing a necessity to provide intuitive
and unambiguous graphical meta
phors to simplify the approach to the somewhat
intimidating OWL formalism, we have developed GrOWL, a graphic framework for
visualization, browsing and editing of OWL ontologies. GrOWL was born as an
attempt to reconcile long
-
standing semantic network appr
oaches with modern
ontology languages. It exploits the synergies between these formalisms to serve the
expanding needs of knowledge engineering in intuitive yet rigorous ways.


Keywords: ontology editing, ontology visualization, semantic networks


1. Intr
oduction

1.1 Semantic Web, Ontologies and OWL



Research and development on the Semantic Web [41,42] focuses on finding an
efficient knowledge representation mechanism for the World Wide Web that would
facilitate machine understanding and enable sharing
of information between various
agents. This formalism should support an efficient reasoning system capable of
performing the integration of distributed data. The sharing of information between
different agents could be facilitated by semantic mark
-
up, i.
e., an annotation of the
Web page with information on its content that is understood by the agents searching
the Web. To make sure that different agents have a common understanding of this
semantic mark
-
up, one needs ontologies that establish a joint termi
nology between
the agents. [19, 12, 35]
.

Basically, ontology is a collection of definitions of concepts;
the shared understanding comes from the fact that all the agents interpret the concepts
w.r.t. the same ontology. Examples of the use of ontologies i
nclude: semantic based
search; facilitation of agent
-
agent communication in e
-
commerce; providing richer
service descriptions that can be more flexibly interpreted by intelligent
agents
;
enabling integration of data fr
om heterogeneous data bases [4].
In mo
st of the cases,
ontologies provide a bridge between semi
-
structured data and a reasoning system that
can understand the content of these data. To enable reasoning services ontologies
should be clearly expressible in a language of a formal deductive system
. The
efficiency of reasoning completely depends on the property of that deductive system
and thus the choice of the underlying logical formalism is crucial. Currently,
description logics (DL) [8] is the most popular choice for the logical system behind
on
tology languages. Most of the alternative trends include the usage of various logic
programming systems [18]
.


The use of ontologies in this context requires a Web
-
enabled ontology language.
Ideally such language should have a well
-
defined syntax, well
-
de
fined semantics,
efficient reasoning support, sufficient expressive power, and convenience of
expression [10]
.

These requirements directed the evolution of a sequence of W3C
recommendations and standards f
or ontology languages: RDF [28],

then DAML+OIL
[11
]
,

and now OWL [24]
.



OWL [17] is a new ontology language for the Semantic Web, developed by the
World Wide Web Consortium (W3C) Web Ontology Working Group. OWL was
primarily designed to represent information about categories of objects and how
objects
are interrelated. This is the sort of information that ontologies store. OWL can
also represent information about the objects themselves

this sort of information is
often thought of as data.


There are three versions, or species, of OWL. In the order of

increasing expressivity,
OWL Lite was designed to support classification hierarchies and simple constraints.
OWL DL is backed by a description logic formalism and so maximizes
expressiveness while maintaining computational completeness and decidability o
f
reasoning systems. Finally, OWL Full offers much greater expressive freedom at the
expense of giving up the computational guarantees of OWL DL
.

Since OWL DL is
the most expressive species of OWL that is supported by reasoners, GrOWL, like
most semanti
c web tool development efforts, focuses on this species of OWL. Like
all OWL DL compliant tools, GrOWL also fully supports OWL Lite.


1.2 OWL Editors and Browser


Text renderings of anything more than small OWL ontologies, whether using the
highly verbos
e RDF
-
XML format or the more compact abstract syntax (RDF/XML
syntax specification URL) are primarily suitable for machine processing. Various
software tools exist to assist end
-
users in editing and browsing OWL ontologies. The
most well developed tool i
s Protégé [45], a highly flexible and extensible knowledge
-
modeling environment that has support for OWL ontology development through
various software plugins. The basic approach to ontology navigation and editing in
Protégé is through a tree
-
structured l
ist of classes and a list of properties. When a
class is selected, details about that class, such as properties, restrictions and axioms
associated with the class, are shown in forms. Similarly, selecting a property shows
details of its definition. Edit
ing takes place in the forms or in form
-
based dialog
boxes.


Various efforts have been made to enhance this form
-
based user interface by
visualizing the ontology as a graph, a collection of interconnected nodes and links.
The primary goal of this approach

is to make clear the relationships between concepts
that are at the heart of an ontology. Protégé includes two ontology visualization
plugins, OWLViz [23] and ezOWL [7] . OWLViz is designed for viewing and
navigating an ontology’s class hierarchy. The
ezOWL tool is visualization and
editing tool. Like OWLViz, it visualizes ontology as a graph where the nodes are the
ontology’s classes. Properties can be listed below the class name as part of the, and
can also be displayed as links between nodes in the

graph. The OntoTrack tool [43]
also bases its visualization around the class hierarchy tree and uses sophisticated
layout and navigation techniques to optimize browsing and editing large ontologies.


Ontology editing tools are still in their infancy, a
nd the relative merits of form
-
based
and graphical approaches are still an open issue. The authors of OntoTrack [43]
argue that graphical techniques are superior to the indented class hierarchies and
auxiliary information panes used in form
-
based ontology

editors. These advantages
become particularly strong when ontologies are large, class hierarchy trees have many
levels, and multiple inheritance is used.


The visualization in all the tools discussed above is centered on the visual display of
the class h
ierarchy. The approach taken by GrOWL is very different, as both the
classes and the properties are rendered as nodes in a graph. This has advantages
while browsing ontologies, as it facilitates tracing relationships between concepts.
For example, it is

common to look an object property of a class, which is connected to
another class (its range). That class often has one or more object properties, which in
turn are linked to other classes. The explicit representation of properties as nodes in
the graph

makes the tracing of these relationships straightforward.



1.3 Rationale of
GrOWL



Graphical metaphors have been successfully used to hide complexities and facilitate
the approach in many fields of human
-
computer interaction. A very structured and
so
metimes intimidating activity such as the definition of ontologies could benefit
greatly from a rigorous, yet intuitive, graphical language. The rationale of the
GrOWL project has been to provide such metaphors without giving up rigor and
formal correctne
ss. While other graphical approaches to the editing of ontologies
exist, the aims of GrOWL are more extensive. The main objective of GrOWL is to
provide a user
-
friendly framework for navigating, editing and querying knowledge
bases comprised of OWL ontolog
ies. The representation of knowledge in the form of
semantic networks offers a user friendly, intuitive picture of the knowledge bases.
GrOWL aims at reconciling the modern ontology language OWL with the semantic
network philosophy by providing a set
of graphic idioms that cover every OWL
-
DL construct.



In essence, OWL documents are collections of logical assertions, yet in their structure
OWL documents resemble object
-
oriented and frame
-
based languages. Discerning
the subtle interplay between the a
pparent frame
-
based syntax and the description
logic
-
based semantic is one of the major difficulties for many novice users of OWL.
Some visualization tools like ezOWL outline the frame
-
based structure of OWL
documents. Unlike other visualization tools, GrO
WL aims to underline the DL
-
based
semantics of OWL, but at the same time it also shows the frame
-
based structure
inherent in OWL documents.


The core of GrOWL is a recursive structural mapping of DL constructs into a graph.
This mapping was inspired by th
e idea of domain maps introduced in [4]. The
structural mapping provides graphic representation for all common DL expressions
and OWL constructs.



In addition to the many basic objectives that are met in the current implementation,
GrOWL also provides

advanced methods of navigation within large ontologies. The
current and the planned features of GrOWL will help to ease the processing of OWL
ontologies and are a step towards making semantic characterization and annotation
affordable for domain experts w
ith a limited background in computer technology.


Since the relation between frame
-
based structure and DL semantic is likely to be a
subtle problem in interpreting OWL document, the present paper discusses it in some
detail. To facilitate this discussion t
he next section provides a brief review of frames
and description logics. It also explains advantages of semantic networks as a
paradigm of human
-
computer interaction. Section 3 introduces the set of GrOWL
idioms. It could be also used as an introductio
n to OWL language for beginners.

Section 4 provides a formal description of GrOWL and contains a proof of the
unambiguity of the mapping from OWL specifications to GrOWL graph. Section 5
describes the navigation and graphic editing paradigms adopted. Se
ction 6 describes
the current and planned applications of GrOWL.




2. A brief history of Knowledge Representation


Knowledge Representation (KR) is a field of Artificial Intelligence (AI) dealing with
the storage and manipulation of knowledge so that i
t can be accessible by both human
and machines. KR

is also central to cognitive science because knowledge is involved
in all cognitive processes, if the term is taken to include perceptual processes as
knowledge.
The purpose of this section is to introduc
e a set of interrelated concepts
from KR domain that will play an important role in the presentation and discussion of
GrOWL. In the subsection on semantic mapping we bring arguments from cognitive
psychology suggesting that the use of a semantic network b
ased presentation of OWL
may have significant advantages over other forms of presentation.


2.1 Semantic Networks

A semantic network (or net), as defined by M.R. Quillian [22], is a graph structure in
which nodes (or vertices) represent concepts, while t
he arcs between these nodes
represent relations among concepts. From this perspective, concepts have no meaning
in isolation, and only exhibit meaning when viewed relative to the other concepts to
which they are connected by relational arcs. In semantic ne
tworks then, structure is
everything.

Semantic nets were widely accepted both in Cognitive Science and AI as an
appropriate representation of knowledge in humans .

The first implementations of
semantic networks were used to define concept types and patter
ns of relations for
machine translation systems. Silvio Ceccato [36] developed
correlational nets
, which
were based on 56 different relations, including subtype, instance, part
-
whole, case
relations, kinship relations, and various kinds of attributes. He u
sed the correlations as
patterns for guiding a parser and resolving syntactic ambiguities. Margaret
Masterman's system [20] at Cambridge University was the first to be called a
semantic network. They were introduced as "semantic networks" for knowledge
rep
resentation and reasoning by M. Ross Quillian [22]
.

In the seventies, semantic
nets gained popularity, and a wide variety of different nets were designed. Some of
the networks have been explicitly designed to study hypotheses about human
cognitive mechan
isms, while others have been designed primarily for computer
applications. They were often used as the basis for many efforts to produce artificial
intelligence. Earlier versions were highly informal, but subsequently other versions
were designed with for
mally defined systems of logic. The papers by R. J. Brachman
[31] and J. F. Sowa [14] contain reviews of semantic networks from different
historic perspectives.

The epistemological utility of semantic networks has been well recognized, and they
have been

widely used for the study of knowledge representation in humans [13, 31]
.

Researchers in cognitive science bring empirical evidence that validates semantic nets
as a practical model of associative memory. A. M. Collins and Quillian [2 and 3], P.
R. Cohen

[26]


and others [5]


offer empirical data that suggests this model mimics
the reaction time for human verification of relations. It was demonstrated that more
able individuals in a domain have richer, more interconnected knowledge structures
(semantic
networks) than do less able individuals [37]
.

Experts’ structures are more
internally coherent and also more associated with information external to (or distant
from) t
he topic than are novices’ [30]
. S. E. Gordon and R. T. Gill [38]


provided an
espec
ially convincing demonstration of the utility of semantic networks in predicting
problem solving skill. They were able to predict student performance in two domains
with 85% and 93% accuracy on the basis of a semantic network representing each
student's k
nowledge about the domain being tested.

Earlier studies [46, 31]


revived various epistemological ambiguities of
semantic
networks and frames and consequently various efforts were made to clear those
ambiguities.
A precise characterization of the meaning

of a network could be given
by decomposing the net into a set of general knowledge
-
structuring primitives that
have precise meaning. Structural Inheritance Networks (SI
-
Nets) emerged as one
result of those efforts to build semantic nets with a set of cle
ar semantic primitives.
One particular incarnation of SI
-
Nets, the KL
-
ONE system [31, 33]
,

is often quoted
as the forerunner of all modern D
escription Logics.




2.2 Frames

Frames

[21]


organize knowledge around concepts considered to be of interest, a
nd
store stereotypical representations of different situations, objects and events
associated with the concept. There is a strong affinity between the frame paradigm
and the object
-
oriented paradigm. Each individual frame stores information about a
parti
cular object or a class of objects. Frame can be thought of as a record data
structure consisting of a number of
slots
, and associated with each slot there is a
value
. Each slot
-
value pair corresponds to a common attribute of the class or object,
and the
(constant) value or allowable range of values of this attribute for this class or
object. The slot also allows procedural attachment in the form of daemons, so that the
mere fact of creating a frame or accessing a slot can cause significant computation to
be performed. Frames are arranged into hierarchies of classes via defined
relationships. Type hierarchies constructed using "IS
-
A" or "A
-
KIND
-
OF"
relationships provide the mechanism for inheritance. One of the characteristics of
frame systems is that inf
ormation at the top of a class hierarchy is fixed, and as such
can provide expectations about specific occurrences of values at individual frames.

Just as it was with semantic networks, earlier applications of frames suffered from
semantic ambiguities [46]

.

At present, there exists a clean formal theory of Frames.
Frame Logics

[18]


captures the object
-
oriented and frame
-
based paradigms within
one formal system with formal semantics and inference theory. The frames
paradigm has been used in a number of
well known knowledge representation
projects including the Open Knowledge Base Connectivity protocol [44]


and the
Protégé ontology design tool [45] .

Semantic networks have commonly been used for graphical representation of the
information contained i
n frames. The correspondence between frames and semantic
nets is simple
-

individual frames correspond to the nodes in the network, and the
relationships between the frames are the arcs in the network.


2.3 Description Logics

Description logics

[8],
are also called
concept languages

or
KL
-
ONE family
[33]
,
has
been developed as a means of expressing taxonomical knowledge by describing
hierarchies of concepts along with their relations. In contrast to earlier knowledge
representation formalisms like fra
mes and semantic networks, description logics have
the advantage of a Tarski style declarative semantics which allows them to be seen
as sub
-
languages of predicate logic [32]. Unlike predicate logics, DL is characterized
by emphasis on the decidabilit
y of key reasoning problems, and by the provision of
sound, complete and empirically tractable reasoning services. Because such services
are crucially important in ontology management, description logics gained popularity
as the underlying formalism for on
tology languages; the later Semantic Web
standards DAML+OIL and OWL were built upon expressive description logics [12]
.


Description logics languages are built up of two kinds of primitive symbols,
concepts
interpreted as unary predicate symbols and
role
s
, interpreted as binary predicate
symbols; the latter are used to express relationships between concepts. Terms are then
built from the basic symbols using several kinds of constructors such as intersection,
union, complement, value restriction etc. A fund
amental construct is a value
restriction that also forms a concept. For example, a concept written

hasChild.Male

denotes all individuals that have at least one male child. The concept written

hasChild.Male

denotes the set of individual whose children are

all male. The
concept
Male


hasChild.Parent

may serve as definition of concept “grandfather”
because it denotes the set of all male individuals who have at least one child who is
also a parent. The concept

6
hasChild.Person
denotes a set of individual

who
have at least 6 children and may serve as a definition of concept “prodigious parent”.
Different languages provide different sets of constructs but the ones mentioned above
are the most common. These examples also illustrate the key characteristic f
eatures
of description logics that reside in the variable free expressions for establishing
relationships between concepts.


Model theoretic

semantic or Tarski style semantic explicates the meaning of
expressions by mapping the concepts and individual na
mes into sets and their
elements.
A model consists of a

domain
(often
written

Δ
I
) and an
interpretation
function
(often
written

I
). One can think of a domain
as a set of all possible
individuals ever described by the language or by the set of expressions

considered. T
he
interpretation function is a mapping

from
individual, class and property

names to
elements of the
domain,
subsets of the domain and binary relations on the
domain, respectively. With every concept
C
,
the interpretation function
associate
s a set
C
I

that is subset of the domain.

We could think of
C
I

as a denotation
of concept
C.

With every role
R

the interpretation function associate set
R
I

that
is a subset of
Δ
I

× Δ
I
.

We could think of
R
I

as denotation of role
R.
W
hat
are
important here are the relationships between elements, subsets, and binary
relations generated by the expressions of the language. Many important
features of the expressions could be derive
d by the analysis of their
corresponding set theoretical structures. Specifically, models are used to
analyze the meaning of the concepts and expressions. A concept
C

has two
types of meaning
-

one (extensional meaning) is its
denotatum

or
reference
, a
set

of all individuals
C
I

of the domain

Δ
I

ever described by concept

C
. This
type of meaning depends on the underlying model. Another type of meaning
(intentional meaning) that is called the
sense

of a concept is derived from
features and relationships of
C
I

that are common to
all possible mod
els.

The
symbol

of the concept, its
reference

and its
sense

constitute the so
-
called
semiotic triangle

or
Frege triangle
.


The concept
C

is said to be

inconsistent

if

C
I

must always be the empty set in
all possible models. The inconsistency of a concept i
s a consequence of the
axioms that the concept has to satisfy.
For example if concept
C

has to satisfy
axiom
C



D





D
then
C

is inconsistent. This follows from the fact that
C
I



D
I



(

D
)

I

must hold for
C
I

.
T
he intersection of a set
D
I

with its complement
Δ
I

\
D
I

=
(

D
)

I

is the empty set, and as a subset of the empty set,
C
I

must be
empty. To arrive at th
e conclusion about inconsistency of
C
, we had to analyze
only the relationships between sets. This trivial yet useful example illustrates
how model theoretic semantic works in the general case. In the context of
formal semantics, o
bjects in the domain
Δ
I

do not in themselves have
any
meaning,
nor does the choice of any particular set of objects that make up the
domain. What
is important are the set theoretic relationships between objects
and sets of objects that constitute the range of the interpretation
functions.


Although the inconsistency of a concept always emerges as a result of some
logical contradiction such as
C



D





D
, finding the contradictions in complex
theories is not always straightforward.

Description logics have powerful decision
procedures that allow checking of the consistency of the concepts. Such
algorithms start from the definition of the concep
t and then expand it in different
ways trying to ensure that every conjunctive element of the concept is
consistent. The availability of such decision procedures for checking concept
consistency makes description logics useful as a formal basis of ontolog
y
languages.


The semantic of OWL is based on an expressive DL. Tables 3 and 4 in Appendix 1
(copied from [12]) describe the main semantic constructs used in the OWL DL
language. The first column represents the expression in Abstract OWL syntax; the
second

column represent the equivalent expression in DL syntax; the last column
represent the semantic of these expressions. Full details on the formal semantics of
OWL can be found in the OWL Semantics and Abstract Syntax (RDF/XML syntax
specification framework
, URL).


In description logic systems, a knowledge base (KB) comprises two components, the
TBox and the ABox. The TBox introduces the terminology, i.e., the vocabulary of an
application domain, while the ABox contains assertions about named individuals in
terms of this vocabulary. Knowledge bases of expressive description logics may also
have an RBox that contain descriptions of relations between roles such as relations of
sub
-
role, inverse role, and equivalent role.


2.5 Semantic Mapping

If semantic networ
ks can serve as models of how the human brain captures, stores,
and transfers information, then they also have the potential of helping human
learning. M. Buckley
-
Hanf [16] was the first to develop the semantic mapping
procedure originally designed to imp
rove the teaching of study skills. During the
1980s there was an explosion in research related to semantic mapping that greatly
increased our knowledge of the broad applications of mapping strategies. Semantic
networks were used as a technique for increasi
ng vocabulary and improving reading
comprehension, as a means of improving the teaching of study skills, and as a way of
facilitating below
-
level college readers’ comprehension of complex conceptual
relationships.


The nature of semantic networks makes t
hem appropriate as a method of ontology
visualization. However, in the current generation of semantic web tools, the use of
semantic networks has been surprisingly sparse. The GrOWL browser and editor
intends to fill this gap by providing a semantic netwo
rk based presentation of OWL
DL.


3.

OWL constructs and GrOWL Idioms

In this section, we introduce the GrOWL idioms along with the semantics of the
OWL DL language. GrOWL follows a very simple general mapping principle
-

named classes and instances are depict
ed as boxes and various relationships between
classes or between instances are depicted as ellipses with a labels or icons. There are
four types of nodes in GrOWL:

1.

Classes, instances, data types and data values are represented by rectangular
nodes with lab
els.

2.

The classes defined as intersections or unions of classes or a complement of a
class are represented by round nodes with icons.

3.

Properties and property restrictions are represented by oval nodes with labels.

4.

Special round nodes with labels represent O
WL axioms for classes,
individuals and properties


The underlying parallel with the frame paradigm emerges if we consider nodes of
types 1 and 2 as frames that represent classes and objects and then consider nodes of
type 3 as slots attached to those frame
s. Since nodes of type 4 may describe relations
between more then 2 classes it would be not appropriate to associate them with slots.
In the GrOWL implementation terminology, nodes of types 1 and 2 are called
object
nodes,
while nodes of types 3 and 4 are
called
relation nodes
.


Using a common approach adopted by many introductory OWL articles [17, 24, 10] ,
this section introduces GrOWL by describing simple examples of OWL constructs.
Some of these examples come from the introductory OWL paper by Antoniou

and
Harmelen [10]. This section is intended for readers who are new to OWL and could
be also used as an introduction to OWL DL language. Readers who are familiar with
OWL could briefly review the diagrams with the corresponding OWL declarations,
read sub
section 3.4 and then go directly to section 4, which provides a concise
systematic description of GrOWL constructs.

3.1

Classes and Individuals




Since the standard XML/RDF syntax of OWL is meant for machine processing and is
extremely verbose, in this paper
we will use OWL Abstract Syntax. Most often the
OWL specifications will be provided as legends to the diagrams. Here is a simple
subclass diagram:


The OWL abstract syntax allows specifying the same in a concise way as either

Class(associateProfessor par
tial academicStaffMember)
or

SubClassOf((associateProfessor, academicStaffMember)



It is important to emphasize that a statement in OWL Abstract Syntax normal does
not define a class, but rather describes one aspect of a class. Although the statement
Cla
ss(associateProfessor partial academicStaffMember)
may resemble a class
definition in an Object Oriented language, this parallel may be misleading. The
statement merely asserts that a class
associateProfessor

is a subclass of class
academicStaffMember
, an
d this assertion does not intend to provide complete
information about the class
associateProfessor.
It is safe to think about OWL
statements as logical assertions or axioms that describe logical relations between
classes, properties and individual instan
ces. GrOWL idioms introduce graphic
representations for those logical assertions.




The following is an instance diagram along with the equivalent OWL specification:


Individual(JohnSmith type(associateProfessor)).


The arrow between two nodes represents

in the first case the relation
subclass
-
of

and
in the second case the relation
instance
-
of
. Since instance and class nodes are clearly
distinguished by their background color, it is easy to recognize the meaning of the
arrow connecting the nodes.


The t
wo examples above introduce simple idioms for named classes and instances.
Besides named classes, OWL has a variety of anonymous classes that have more
complex graphic representation. OWL reference guide (ref) distinguishes five types
of anonymous
class
descriptions
:

1.

an exhaustive enumeration of individuals that together form the instances of a
class

2.

a property restriction

3.

the intersection of two or more class descriptions

4.

the union of two or more class descriptions

5.

the complement of a class descript
ion

These various types of class descriptions will be considered in subsections of this
section. In subsection 3.4 we consider idioms for property restrictions. In subsection
3.5 we introduce basic idioms for the other anonymous descriptions. In subse
ction
3.6 we talk about complete (as opposed to partial) class definitions and also discuss
complex nested class descriptions.


3.2 Properties

A property is a binary relation. Two types of properties are distinguished:



datatype properties
, relations bet
ween instances of classes and RDF literals
and XML Schema datatypes



object properties
, relations between instances of two classes.

Here is a simple specification of an
object property
:


ObjectProperty( isTaughtBy


domain(cource)


range(a
cademicStaffMember))

The global restrictions on properties, such as specifications that a property is
symmetric, functional, transitive, or any allowed combinations of these, are provided
on a separate property panes. The relations of properties to other
properties such as
subproperty and inverseOf relation are depicted graphically in a separate RBox view
that displays the property hierarchy. For example consider the following property
specification:

ObjectProperty( teaches super(involvedIn)


domain
(academicStaffMember)


range(cource)


inverseOf(isTaughtBy))

This specification of an object property will generate two separate diagrams:






The second diagram will appear in the RBox view only. Such separation of TBox,
ABox and RBox vi
ews is especially convenient for viewing large ontologies. Note
that the subproperty relation could be specified with a subproperty axiom, separately
from the property declaration. For example the relation between
teaches

and

involvedIn
could be specifie
d with the subproperty axiom
SubProperty(teaches,
involvedIn).
In GrOWL, the two types of declaration of sub or super properties are
indistinguishable.


The idiom for
datatype properties

is analogous to idiom for object properties, except
that it is rende
red in a different color. Here is an example of data property
specification.


DatatypeProperty(age


domain(person)


range(xsd:nonNegativeInteger))





3.3 Facts

Individuals are defined with individual axioms (also called "facts"). There are two
kinds of

facts in the OWL. The first kind of fact states information about a particular
individual, in the form of classes that the individual belongs to and values of the
properties associated with that individual. The second kind of fact is used to make
individu
al identifiers be the same or pairwise distinct. Here is an example of the first
kind of fact:



Individual(JohnSmith


type(academicStaffMember)


value(teaches Java)


value(teaches ArtificialIntelligence)


value(age "32"^^xsd:integer))





T
he current GrOWL implementation supports a color
-
coding scheme that
distinguishes class nodes from instance nodes and property nodes from property value
nodes through their background color. The color
-
coding scheme has been configured
to further distingui
sh data values from class instances, object properties from data
type properties, and object property values from data property values based on the
border color and background color.


Here is a simple example that illustrates the idioms for the facts of th
e second kind:


SameIndividual(AI ArtificialIntelligence)




DifferentIndividuals(JohnWSmith JohnSmith)


To facilitate immediate recognition of axioms, the nodes that represent OWL

axioms
have yellow borders

and yellow arrows that point to the operator
arguments.

3.4 Property Restrictions

Suppose we wish to declare that the class C satisfies certain conditions, that is, all
instances of C satisfy the conditions. Obviously it is equivalent to saying that C is
subclass of a class D, where D collects al
l objects that satisfy these conditions. Such
class D could be effectively created by any DL class constructor, such as

R.C
i

,

R.

C
i
,

n R, etc. In OWL terminology such class constructors are called
property
restrictions
.

This idea is used in OWL as

a way to link frame based specifications of
OWL with DL semantics. One form of the class declaration
is an OIL
-
style class
frame specified in OWL Abstract syntax as
Class(A
par t i al


C
1
.....Cn)
. This

s
yntactically describes A as a collection of slots
C
1
...
..Cn,

while semantically it is
equivalent to a DL axiom assert
ing that class A is a subclass of each of the
classes
C
1
.....Cn
. For example the following GrOWL diagram and equivalent OWL
declaration requires every Math courses to be taught by staff memb
ers of Math
Department only.



Class(MathCourse partial


restriction(isTaughtBy allValuesFrom(MathDeptStaffMember)))


The rendering in GrOWL reflects both DL semantics and the frame
-
based flavor of
OWL Abstract syntax. The
equivalent DL axiom is as
follows:

M
athCourse





isTaughtBy
.

MathDeptStaffMember


This axiom is represented by the subclass
-
of arrow that connects the node
M
athCourse

with the node


isTaughtBy
. In the diagram above, the node with label


isTaughtBy

represents the entire class

isTaughtBy
.
MathDeptS
taffMember.
We
shall say that node labeled


isTaughtBy

is a
base node

for the class

isTaughtBy
.
MathDeptStaffMember
. On the other hand, the graphic format
suggests that oval node


isTaughtBy
is a slot attached to the class node
M
athCourse.

An analog
y between the diagram above and the property declaration
diagram presented in subsection 3.2 suggest this. However, this analogy could only
be drawn by interpreting subclass
-
of arrow as a slot arrow.


OWL distinguishes two kinds of property restrictions:
value constraints and
cardinality constraints. A value constraint puts constraints on the range of the
property when applied to this particular class description. A cardinality constraint
puts constraints on the number of values a property can take, in the

context of this
particular class description.


3.4.1 Value Constraints

There are three types of value constraints: (1) AllValuesFrom , (2) SomeValuesFrom
and (3) hasValue. An example of the value constraint of the first kind has already
been provided ab
ove. The next is example of a SomeValuesFrom type constraint. It
declares that all academic staff members must teach at least one undergraduate
course:



Class(AcademicStaffMember
partial


restriction(teaches someValuesFrom(cource)))


The following is
an example of hasValue constraint. It states that all programming lab
courses are taught at “room
-
22”. Note that the relation node
taughtAt

is represented in
the same way as nodes for property values (see subsection 3.3).


Class(programmingLab
partial



restriction(taughtAt hasValue(room
-
22)))


The examples above illustrate the value constraints on object properties. The same
constructs are also applicable to data properties. The ranges of restrictions on data
properties must be nodes that repres
ent either XMLSchema data types or data ranges.
The GrOWL rendering for restriction on data properties are almost identical to the
rendering of respective restrictions on object properties, but the color of data property
restrictions is the same as the col
or used for data types and data property declarations.
This allows the user to immediately distinguish the two types of values, properties
and restrictions. The rendering of data ranges is similar to rendering of class
enumerations, which will be discusse
d in subsections 3.5 and 3.6.


The following example illustrates data value restrictions that use data ranges. Suppose
scores for some test can take numeric values {2, 3, 4, 5}. (Here 1 is excluded since it
is as bad as 2). Then to restrict the range of v
alues for data property ”score” to the
desired ones the following data property restriction must be used.



Class( Test partial restriction( hasScore allValuesFrom(


oneOf("2"^^<http://www.w3.org/2001/XMLSchema#integer>



"5"^^<http://www.w3.org/2001/XMLSchema#integer>


"4"^^<http://www.w3.org/2001/XMLSchema#integer>


"3"^^<http://www.w3.org/2001/XMLSchema
#integer>))))


3.4.2 Cardinality Constraints


In OWL, it is assumed that any instance of a class may have an arbitrary number of
values for a particular property. Cardinality constraints can be used to limit the
number of values for specific property.
OWL

supports 3 types of cardinality
constraints: minCardinality, maxCardinality, and cardinality.
The following
minCardinality

constraint assert that a course must be taught by at least one academic
staff member:





Class(cource
partial


restriction(i
sTaughtBy minCardinality(1)))


The declaration of a cardinality restriction does not include specification of the range
of the property. GrOWL connects the cardinality restriction node to a property range
node making the best possible guess, based on th
e specifications avalible.


The rendering of maxCardinality constraints is similar to rendering of minCardinality
constrait. When both the minCardinality and maxCardinality are specified for the
same property in one class, GrOWL provides combined renderi
ng of these constraints
in one property restriction node. The following example, asserting that a Ph.D.
student should take 7 to 10 courses, illustrates this:



Class(phdStudent
partial


restriction(takesCource minCardinality(7))


restriction
(takesCource maxCardinality(10)))


The following is an example of a cardinality constraint that asserts that every Ph.D.
student should have exactly 2 advisors:




Class(phdStudent partial


restriction(hasAdvisor cardinality(2)))


For all 3 types

of restrictions, OWL Abstract Syntax allows two alternative
specifications for restrictions. Besides the declaration inside the class which was
used in all the examples of restrictions shown here, it is possible to specify the
restriction using the
SubCl
assOf
axiom. The following equivalent reformulation of
the last example illustrates this point:


Class(phdStudent partial)

SubClassOf(phdStudent restriction(has Advisor cardinality(2)))

3.5 Set theoretical Operators

The class descriptions Intersection,
Union and Complement that create anonymous
classes represent the more advanced class constructors that are used in description
logic. They can be viewed as representing the AND, OR and NOT operators on
classes. These language constructs may contain neste
d class descriptions. In this
subsection we will discuss these constructors, while in the
next subsection we will
give examples of how they could be combined within descriptions of named classes.
We also count as set theoretical the operator “one of” that

describes a

class by an
exhaustive enumeration of individuals that together form the instances of a class. The
same operator “one of” is used for description of data ranges.

For reference, we will give the definitions of
Intersection
,
Union

and
Complement
.
The intersection of classes Class1, Class2 and Class3 is a set of all individuals that
belongs to every class Class1, Class2 and Class3. The union of classes Class1,
Class2 and Class3 is a set of all individuals that belongs to at least one class Class
1,
Class2 and Class3. The complement of a class Class1 is a set of all individuals in the
domain that do not belong to Class1. The operator node of complement should have
only one argument arrow pointing to a class node. The “one of” node of the class
e
numeration operator must have several argument nodes pointing to individuals. It
represents a class comprized of those individuals. Each node represented by a set
theoretical operator denotes an
anonymous

class which can be used within class
description
s, for example as a range of a value restriction.

The following nodes represent set theoretical operators of Intersection, Union,
Complement and Class Enumeration:


The operator node for Intersection and Union must have several argument arrows
pointing t
o class or restriction nodes. For example, in the following diagram, the
operator node represents a class which is an intersection of classes Class1, Class2 and
Class3.



Since the arrows subclass
-
of and equivalent
-
class may use the operator nodes as the
ir
domain or range the clear differentiation of argument arrows from other types of
arrows is essential for unambiguous interpretation of GrOWL constructs. This
distinction is facilitated by making the color and thickness of argument arrows
different from

the color and thickness of subclass
-
of and equivalent
-
class.


The following denotes the intersection of the class ‘faculty’ and an anonymous class
formed by a “hasValue” constraint that denotes individuals affiliated with
CSDepartment.


Intersection(fac
ulty


restriction(affiliatedWith hasValue(CSDepartment))


3.6

Class Descriptions



Anonymous classes such as those produced by set theoretical class constructors do
not apear independently in an ontology. They can appear in various parts
of
descriptions of named classes and in class axioms. In this section we shall elaborate
on how descriptions of various anonymous classes can be used in descriptions of
named classes.


OWL Abstract Syntax distinguishes two types of named class descriptio
ns. The
description
Class(A
par t i al


C
1
.....Cn)

states that class A is a subclass of the
intersection of the classes
C
1
.....Cn.
This also implies

that A
is a subclass of each class
C
1
.....Cn.
The description
Class(A
complete

C
1
...Cn ) states

that class
A is a exactly
equal to the intersection of the classes
C
1
.....Cn.
These two class descriptions have
different renderings in GrOWL.


The following diagrams illustrate that difference. The first two diagrams present
different rendering of the OWL descrip
tion

Class(CSProfessor partial


faculty


restriction(affiliatedWith hasValue(CSDepartment))



The following is a “literal” rendering:



Although this type of diagram is amissible in
GrOWL

during editing , it is not
used
while rendering the OWL files. Instead
GrOWL

uses a simpler rendering such as the
following:



As it was discussed in subsection 3.4
, attaching a restriction node to a class implies
that this class is a subclass of the anonymous class that specifie
s the restriction. We
already mentioned that this type of representation makes class declarations similar to
Frame style declarations. This type of representation cannot be used when the
declaration of a class is complete (i.e. when the class is exactl
y equal to the
intersection of the “slots”) and we have to resort to the literal form of rendering. The
following diagram illustrates complete class declarations:


Class(CSFaculty complete


faculty


restriction(affi
liatedWith hasValue(CSDepartment))


It may be seen as a disadvantage that two types of class descriptions that are very
similar in OWL Abstract Syntax have different rendering in GrOWL. Yet the
specificity of the graphic paradigm imposes its own constrain
ts and requrements such
as an absence of ambiguities, clarity of the correspondence between graphic and
semantic primitives and economy of canvas space. While designing GrOWL, we
considered a number of alternative graphic conventions and the present graph
ic
mapping was selected as optimal given these constraints.


To further explain the use of
nested set theoretic operators

we will provide two
examples. The first one illustrates the use of the complement and union operators.

The following diagram defines
administrative staff as the set of those staff members
that are neither faculty nor technical support staff:





Class(adminStaff complete


complementOf(unionOf(faculty techSupportStaff)))



The second example illustrates the use of enumer
ations and the use of set theoretic
operators as ranges of value restrictions. The diagram states that the value of the
property hasDayOff for class Department must be restricted to the union of classes
NationalHoliday and an anonymous class defined by a c
onstraint on the property
dayOfWeek restricting it to the values Saturday and Sunday.


Class(Department partial


restriction(hasDayOff


allValuesFrom(


unionOf(



restriction(dayOfWeek


allValuesFrom(oneOf(Saturday Sunday)))


NationalHol
iday))))



3.7 Class Axioms and Individual Axioms



In OWL there are 3 class axioms: EquivalentClasses, SubClassOf and
DisjointClasses. The following annotated diagrams present the schemes for rendering
these 3 axioms:


EquivalentClasses(Class3 Class1 Cl
ass2)



SubClassOf(Class1 Class2)




DisjointClasses(Class3 Class1 Class2)


Here the classes
Class3 Class1 Class2
may be either named classes or anonymous
classes defined by set theoretic and restriction class constructors. In practice, named
classes ar
e used more often inside the class axioms.


EquivalentClasses and SubClassOf axioms provide alternative ways of describing
classes. For example, the following two definitions are equivalent:


1. Class(adminStaff complete


complementOf(uni
onOf(faculty techSupportStaff)))


2 .
Class(adminStaff partial )


EquivalentClasses(adminStaff


complementOf(unionOf(faculty techSupportStaff)))


The GrOWL diagram from previous subsection representing the first definition
may
also be taken as representation of the second definition. Similarly the following two
definitions are equivalent:


1.
Class(CSProfessor partial


faculty


restriction(affiliatedWith hasValue(CSDepartment))


2.
Cl
ass(CSProfessor partial )


SubclassOf(CSProfessor


Intersection(

faculty


restriction(affiliatedWith hasValue(CSDepartment)))


In this case the default rendering of the two diagrams will be dif
ferent. The first
definition will be represented as:



The second definition will be represented in “literal” form:



As was already mentioned, these two diagrams have the same meaning.


4. GrOWL Semantics

This section describes the three basic design pr
inciples behind GrOWL and also
provides systematic descriptions of the GrOWL elementary idioms. The main graphic
idioms of GrOWL could be obtained by recursively mapping a DL KB into a graph.
To illustrate the interactions of this idioms we provide a scree
nshot of the Camera
ontology (fig. 1). The abstract syntax of the Camera ontology is given in appendix.
The original rds/xml presentation syntax can be found in an online library of OWL
ontologies [24]
.

4.1 Graphical Coding

The first principle behind GrOW
L is the use of the color, shading and shape of nodes
to encode properties of the basic language constructs. We use the same color,
shading or shape for rendering grammatical constructs that belong to a single broad
category. For example, we use shading
to clearly differentiate TBox and ABox
related nodes. Nodes related to terminology are shaded with a solid color
background, and nodes related to individual instances or data values are rendered
with white backgrounds. The second pair of categories of la
nguage constructs is
entities and relations between them. The category of entities includes classes,
instances, data types, and data values. The category of relations includes properties,
property restrictions and property values for both object properties

and data
properties. All entities are rendered as rectangular nodes and all relations are
rendered as elliptical nodes. The third dimension of our categorization differentiates
between things related to data types and object types and is encoded with th
e help of
two colors. The following table describes the color
-
coding scheme of GrOWL. The
color
-
coding scheme in the table does not include the set theoretic constructs union,
intersection and complement. Since the nodes for those constructs represent b
oth
entity and relations at the same time and do not fit into our broad classification of
grammatical constructs they have special rendering constructs.
















Table
1
. Graphical Coding Scheme




4.2 Structural Mapping of DL expressions


While designing a graphic formalism for some language it is important to consider
several questions. First, it is nece
ssary to ask if every expression of the language has
an adequate graphical representation and so the graphic mapping is complete.
Second, it is necessary to ensure that graph does not allow ambiguous reading. In this
section we shall describe GrOWL as a
structural mapping that goes along with
recursive definitions of underlying DL class constructors. We shall demonstrate that
GrOWL is a complete and unambiguous mapping of OWL. For the sake of
simplicity we will focus on TBox constructs only.


We will use

the expression
base node

of the class for the nodes that represent a
particular class on the graph. From a formal standpoint, we have a couple of related
functions. Structural mapping
G

maps every class definition
C

from a DL knowledge
base to a graph
G(
C)
. Only one node of this graph represents the mapped class. Base
node mapping
BG

draws correspondence between a class definition and the single
node
BG(C)

in graph
G(C)

that represent class
C
. Base nodes represent classes on
the graph in that sense that e
very arrow that represents subclass
-
of and equal
-
to
relations of a class is attached to the base node of this class. Thus for any pair of
either named or anonymous classes
C
1
and
C
2


the following holds:




Color 1 (Blue)


Color 2 (Brown)

Rectangular

with shaded
background

Classes




Data ty
pes




Rectangular

with white
background

Individuals



Data values



Ellipse

with shaded
background


Properties and

Property Restrictions


Data Properties and Data
Property Restrictions

Ellipse

with white
background



Property Value pairs, Value
Restric
tions


Data Property Value

Pairs


G

maps
C
1


C
2

to the diagram




G

maps
C
1
= C
2


to the diagram



In both cases,

is a base node of class
C
1

and

is a base node of class
C
2

and
they do not have to be shaded squares, but may be of any shape indi
cated in the third
column of the table for TBox constructs. The table (table 2) describes the recursive
mapping of DL expression into a graph that constitutes the core of GrOWL. Data
properties and data property restrictions are not shown in the table sin
ce their
mapping is identical to the mapping of respective relations pertaining to individuals,
and the difference is only in color.



Table 2 Structural Mapping for main TBox Constructs




























Mapping of OWL class axioms was already described in section 3.7 and mapping of
ABox expression is obvious from the example in subsection 3.3. Neither of those
introduces new class nodes but create arrows and relations b
etween existing class
nodes or class nodes and instance nodes. Structural Mapping follows the recursive
Class Definition

The diagram G(C)

Base
node
BG(C)

Primitive Class

C



Intersection
C
1


C
2




Union
C
1


C
2




Complement


C




Enumeration
{o
1
,o
2
}



Exist Restriction

R.C




For all Restriction

R.C




Number Restriction


nR


Eg.


Number Restriction

n R


Eg.


Value Restriction

R:o




definitions of the OWL semantic constructs, and therefore every TBox constructs
receives a graphic representation.


Structural Mapping is one
-
to
-
one.
Although the rendering of the arrows that represent
subclass
-
of and instance
-
of axiom is identical, it is not possible to mistake one for
another, since subclass
-
of arrow always connect two classes. The nodes for property
value restrictions are similar to

nodes for property value pairs, but only the nodes for
property value restrictions can be targets for subclass
-
of and instance
-
of arrows. If
the graphical coding scheme described in previous section is used, and furthermore if
there is a clear distinctio
n between the following 3 types of arrows then the mapping
is unambiguous.

1.

Subclass
-
of arrows (currently thick and blue)

2.

Argument arrows (currently thin and orange)

3.

Arrows connecting restrictions to class nodes (currently thin and blue)

On the contrary, a
similarity between any two of these 3 types of arrows would open
the possibility for ambiguous reading of certain graphs.



Most of the GrOWL idioms could be obtained as the result of the structural mapping
of a representation of an OWL file in form of DL.

Property declarations constitute an
exception. The DL semantics of property declarations is complex and therefore we
render them according to the rules described in Table 4. The introduction of special
symbols as a substitute for complex graphs that ex
press the DL semantics of property
declarations does not break the unambiguous character of the GrOWL mapping.

5. Navigation and editing tools in GrOWL


The problem of visualizing large ontologies is not an easy one. The main challenge is
to present a mea
ningful visualization of the underlying knowledge structure while
providing intuitive understanding, eliminating visual clutter and maintaining aesthetic
appeal. Trying to draw even a simple semantic network on a two
-
dimensional surface
would likely end up

with a non
-
planar graph


meaning that the relationships that
link concepts together would be drawn crossing and overlapping each other


a very
messy and potentially unusable view of the underlying structure. In order to minimize
occurrences of such situ
ations, GrOWL provides the following advanced techniques
for navigating through large networks:


1.

Automatic and Manual Layout.
The current GrOWL implementation is
based on a modified and enriched version of the Touchgraph [40]
.

library and
uses the underly
ing Touchgraph layout engine. This layout engine distributes
nodes and edges evenly on the canvas space. Switching to manual layout
mode allows the user to reposition individual nodes to further refine the graph
layout.

2.

Locality Restricted View.

GrOWL als
o inherits from Touchgraph the
mechanism for restricting the set of visible nodes and edges to only those that
lie in a topological neighborhood of a selected node. When the selected node
is changed the set of visible nodes and edges is readjusted accordin
gly. As in
Touchgraph, a node is set as selected by clicking on it.

3.

Search Combo and Navigation Pane

GrOWL maintains a list of classes or
instances in a combo box. Selecting any object from this combo sets the
respective node as selected. This action readj
usts the visible locality of the
network, centering it on the selected node. To facilitate finding classes in
large ontologies, the list matches incrementally on the user’s typed input.
There is a navigation pane that represents the class hierarchy as a
tree that also
allows the user to navigate through the class hierarchy by expanding and
collapsing subtrees. This representation is familiar for users of Protégé and
many other ontology browsing tools. When an entry in the class tree is
selected, the vis
ualization is re
-
centered on the selected class.

4.

Expansion of individual nodes.

Suppose you have selected a class and are
viewing its properties and their ranges. To expand any one range class, you
could either select that class or increase the displayed

neighborhood of the
original selected class. The first option has the problem that when the new
class is selected, all other edges and nodes connected to the original class are
collapsed. The second approach has the disadvantage that the ranges of all
p
roperties of the selected class are expanded and so the complexity of the
graph increases drastically. To address these issues, we have extended the
Touchgraph navigation tools to allow the expansion of any node that is at the
edge of a locally restricted

view and so has undisplayed edges.

5.


TBox, ABox, RBox and Class Hierarchy views

There are several possible
ways to filter out a part of the entire graph, including viewing only the ABox,
TBox or class hierarchy. It is also possible to hide all named class

nodes
except for a selected class and its subclasses. There is also an RBox view,
which is maintained on separate canvas and it is not a part of the entire
network as it is the case with other restricted views




Editing


GrOWL is a convenient tool for
the visualization of OWL ontologies. However it is
even more valuable as a visual ontology editor. In editing mode, GrOWL displays a
toolbox with a set of button. Pressing any of these buttons activates the respective
tool for creating various graphic pr
imitives. After pressing a button on toolbox, the
user can create class, instance, data type, and data value nodes by clicking on canvas.
By selecting property and property restriction related tools, the user can create the
respective relation nodes betwee
n object nodes by selecting a source node and then
dragging the mouse from the source node to the target object node.


Many editing task can be accomplished in one of two ways. When the class creation
tool is selected, clicking on the canvas creates a new

class. The relationship between
that class and a subclass or superclass is then created by clicking and dragging from
the subclass to the superclass. Alternatively, when this tool is selected, clicking on a
class and dragging into open space on the canv
as creates a subclass of the class that
was at the beginning of the dragging gesture. Other entities, such as individuals,
properties and restrictions, can all be created and linked into the ontology using either
idiom. The user is given further guidance

during some operations. For example,
when the user drags from a class to create a restriction, they are presented with a list
of existing properties to restrict.




Figure
1

GrOWL displaying Camera ontology




6. Current applica
tions and future work




GrOWL is implemented as java applet, and as a stand
-
alone java application. The
policy
-
based design [1]


of GrOWL ensures its extensibility and possibility to easily
target the software to the needs of different projects.


At pre
sent, GrOWL is being used for two main purposes. The first is to allow non
-
technical users to browse the structure of the knowledge represented in web
-
accessible databases and perform assisted queries using a graphical interface. The
most important applica
tion at the time of this writing is the Ecosystem Services
Database [6]
,

a data and analysis portal to assist the informed estimation of the
economic values of ecosystem services [27]. The ESD uses the applet version of
GrOWL to present the annotated onto
logies it is based on to the user. Once the user
has located a concept of interest, the right
-
click menu in the applet gives access to a
set of queries that the database supports for the selected concept. The representation
of instances offered by GrOWL is

used in the ESD to document the objects retrieved
by a user query. ESD extensively uses OWL format for the description of dynamic
models as well as data. The annotated graphical description provided by GrOWL has
proved to be a valuable learning device for

students and users when the object being
documented is a complex dynamic model or a composite dataset with extensive
metadata.


The second important application of GrOWL is to enable the development of
ontologies in a workshop context where not all partic
ipants are versed in the concepts
and methods of knowledge representation. Just as tools like Stella [39]


have been
used successfully to enable cooperative development of dynamic models, using a
graphical representation of the model as the “blackboard” f
or a collective thinking
process, we are experimenting with GrOWL in a collaborative context to enable more
intuitive viewing and understanding of a developing knowledge structure than
conventional tree
-
based representations can provide.


In the future we

plan to extend GrOWL by implementing graphic maps
-

a feature
that will provide domain specific rendering for specific DL constructs and for
instances of certain classes. We also plan to connect the GrOWL editor to an OWL
reasoner. In order to support co
llaborative ontology development by distributed
communities, we are planning a collaborative version of the GrOWL editor, where
remote users can view and edit several versions of an ontology and cut
-
and
-
paste
conceptual structures across windows describing

different collaborating sites.



The future implementation will include a graphic framework for complex queries of
OWL and DL knowledge bases, including visual tools for query design, and a
semantic markup editor.




2
-
3 paragraphs perhaps, leaving d
etail analysis of possible applications for another
paper.

Ferdinando? [I’ll write this section in the next couple of days, for the paper and the
web site]


I’d add a few links to ontologies visualized in GrOWL so that users can try them out


as referenc
es, not inline, unless the journal has a policy on that.]




Appendix 1









Abstract OWL Syntax

DL Syntax

bbbb

A

(URI
reference)

owl:Thing

owl:Nothing

A

T



A
I



Δ

I

owl:Thing
I

=
Δ

I

owl:Nothing
I

= {}

intersectionOf(C
1

C
2

...)

unionOf( C
1

C
2

...)

complementOf(C)

oneOf(o
1
...)

C
1


C
2

C
1


C
2



C

{o
1
……}

(
C
1


C
2
)

I
=

C
1
I




C
2
I

(
C
1



C
2
)

I
=

C
1
I



C
2
I



C
)

I

=
Δ

I
\

C

I

{o
1

I

……}={o
1

I

……}



restricti
on(R
someValuesFrom(C))

restriction(R

allValuesFrom(C))

restriction(R

hasValue(o))

restriction(R

minCardinality(n))

restriction(R

minCardinality(n))


R.C


R.C

R:o



n R


n R


R.C

)

I

={x |

y.(x, y)

R
I

and y


C

I

}


R.C

)

I

={x |

y.(x, y)

R
I



y


C

I

}


R.o

)

I

={x |

(x, o
I
)

R
I

}

(

n R
)

I

={x |

(

y.(x, y)

R
I
})


n }

(

n

R
)

I

={x |

(

y.(x, y)

R
I
})

n }





(
`d
R.o)
τ

=
{x
~(
x, o
τ
)
E
R
τ
}

(
~
n R)
τ

={x
~
]({y.(x,
y)
E
R
τ
})
~
n}

(
~
n R)
τ

=
{x
~
]({y.(x,
y)
E
R
τ
})
~
n}

rest ri ct i on(U
someValu
esFrom(D))

rest ri ct i on(U
allValuesFrom(D))

rest ri ct i on(U
hasValue(v))

rest ri ct i on(U
minCardinality(n))

rest ri ct i on(U
maxCardinality(n))


U.C


U.C

U:o



n U


n
U


U.C

)

I

={x |

y.(x, y)

U
I

and y


C

I

}


U.C

)

I

={x |

y.(x, y)

U
I



y


C

I

}


U.o

)

I

={x |

(x, o
I
)

U
I

}

(

n U
)

I

={x |

(

y.(x, y)

U
I
})


n }

(

n

U
)

I

={x |

(

y.(x, y)

U
I
})

n }


Data Ranges (D)



D

( URI
reference)

oneOf(v
1
...)

D

{o
1
……}

D
D


Δ

I
D

{v
1

I

……}={v
1

I

……}

Object Properties (R)



R

(URI
reference)

R

R
-

R

I


Δ

I


Δ

I


(R
-
)

I

=
(R

I
)
-

Datatype
Properties (U)



U

(URI
reference)

U

U

I


Δ

I


Δ

I
D

Individuals
(o)



o

(URI
reference)

o

o
I



Δ

I


Data Values
(v)



v

(RDF
literal)

v

v
I


Δ

I
D


Table 3
OWL DL Descriptions, Data Ranges, Properti
es, Indivdiuals, and Data Values















Class(A
parti al


C
1
.....Cn)

Class(A
complete

C
1
...Cn )

EnumeratedClass(A

o
1
,… , o
n

)

SubClassOf(

C
1

C
2
)

EquivalentClasses(

C
1
.....Cn )

DisjointClasses(

C
1
.....Cn )

Dat at ype(D)

A


C
1





C
n

A =
C
1





C
n

A = {o
1
,… , o
n
}

C
1


C
2

C
1
= . . . =Cn

C
i


C
j

=

, i


j

A
I


C
1
I






C
2
I

A
I

=

C
1
I






C
2
I

A = {o
1

I
,… , o
n

I

}

C
1
I




C
2
I

C
1
I

= . . . =C
n
I


C
i




C
j

=

, i


j


D
D


Δ

I
D


DatatypeProperty(U
super(U
1
)...super(U
n
)

domain(C
ι

) ...domain(C
m
)

range(D
ι

) .
..range(D
l
)

[Functional])

SubPropertyOf( U
1

U
2
)

Equi val entProperti es( U
1
… U
n
)


Obj ectProperty(R
super(R
1
)...super ( R
n
)

domai n(C
1

) ...domai n(C
m

)

range(C
k
)
...r ange( C
l

)

[ i nver seOf ( R
o
]

[ Symmet r i c]

[ Funct i onal ]

[ I n v e r s e Fu n c t i o n a l ]

[ Transi t i ve] )


SubPropert
yOf (R
ι

R
2
)

Equi val ent Propert i es(R
1

...R
n
)



U



U
i



1 U


C
i


T



U.D
i



T




U

U
1




U
2

U
1

=...=


U
n




R




Ri



1 R


C
i



T



R.C
i


R=(


R
o
)

R=(


R)


T




R

T




R



Tr(R)



R
1




R
2

R
1

=...=


R
n






U
I




U
i
I

U

I


C
i

I



Δ

I
D


U

I


Δ

I



D
i
I



U

I

is functional

U
1
I




U
2
I

U
1
I

=...=


U
n
I


R
I




R
i
I

R

I


C
i

I


Δ

I

R

I


Δ

I



C
i
I



R
I
=(

R
o
I
)


R
I
=(

R
I
)


R
I

is functional

(

R
I
)

i s

f unc t i ona l

R
I
=(

R
I
)




R

1
I




R

2
I

R

1
I

=...=



R

n
I




Individual(o type(C
1
)

...t ype(C
n
)

value(R
1

o
1
)...value(R
n

o
n
)

value(U
1

v
1
)...value( U
n

v
n
))

SameIndi vi dual (
o
1
...o
n
)

DifferentIndividuals(
o
1
...o
n

)

o


C
i

(

o
,

o

i
)



R
i

(
o
, v
i
)



U
i

o
1
=...=o
n

o
i


o
j
, i


j

o
I


C
i
I

(o
I
,
o
i
I
)



R
i
I

(o
I
,
v
i
I
)



U
i
I

o
i
I
=
o
j
I

o
i
I

o
j
I

, i


j


Table 4: OWL DL Axioms and Facts


Apendix 2

Camera ontology in Abstract syntax


References


[1] A. Alexandrescu, Modern C++ Design: Generic Programming and Design
Patterns Applied, Addison Wesley Professional, 2001.


[2] A. M. Col
lins and M. R. Quillian, Retrieval Time From Semantic Memory,
Journal of Verbal Learning and Verbal Behaviour, 8 (1969) 240
-
247.


[3] A. M. Collins and M. R. Quillian, How to Make a Language User, in: E. Tulving
and W. Donaldson, eds., Organization and Me
mory, 1972.


[4] B. Ludaescher, A. Gupta, and M. E. Martone, Model
-
based mediation with
Domain Maps, in: Proceedings of 17th Intl. Conference on Data Engineering (ICDE),
Heidelberg, Germany, IEEE Computer Society, 2001.


[5] C. Conrad, Cognitive Economy i
n Semantic Memory, Journal of Experimental
Psychology, 92 (1972)149
-
154.


[6] ESD, Ecosystem Services Database URL, www.esd.uvm.edu


[7] EzOWL URL, http://iweb.etri.re.kr/ezowl/index.html


[8] F. Baader, D. Calvanese, D. McGuinness, D. Nardi, and P. Pate
l
-
Schneider, eds.,
The Description Logic Handbook. Cambridge University Press, 2002.


[
9
] F. Baader, I. Horrocks, and U. Sattler, Description logics for the semantic web. KI
-

Künstliche Intelligenz, 16(4) (2002) 57
-
59.


[10] G. Antoniou and Frank van Harm
elen, Web Ontology Language: OWL, in: S.
Staab and R. Studer, eds., Handbook on Ontologies in Information Systems, Springer
-
Verlag, 2003.


[11] I. Horrocks, DAML+OIL: a description logic for the semantic web. Bull. of the
IEEE Computer Society Technical C
ommittee on Data Engineering, 25(1) (2002) 4
-
9.


[12] I. Horrocks, P.

F. Patel
-
Schneider, and F. van Harmelen, From SHIQ and RDF to
OWL: The making of a web ontology language, Journal of Web Semantics, 1(1)
(2003) 7
-
26.


[13] J. Anderson and G. Bower, Huma
n Associative Memory, Washington, DC:
Winston, 1973.

[14] J. F. Sowa, Semantic Networks, 2002, http://www.jfsowa.com/pubs/semnet.htm

[15] K. M. Fisher, SemNet Semantic Networking, in: Fisher, K. M., Wandersee, J. H.,
& Moody, D, Mapping biology knowledge,
Dordrecht, Netherlands, Kluwer, 2000,
pp. 143
-
165.


[16] M. Buckley
-
Hanf, Mapping: A technique for translating reading into thinking.
Journal of Reading, 14 (1971) 225
-
300.


[17] M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D. L.
McGuin
ness, P. F. Patel
-
Schneider, and L. A. Stein, OWL web ontology language
reference, W3C Working Draft, 31 March 2003. [http://www.w3.org/TR/2003/WD
-
owl
-
ref
-
20030331].


[18] M. Kiffer, G. Lausen, J. Wu, Logical Foundations of Object
-
Oriented and
Frame
-
Based

Languages. Journal of ACM, 1995.


[19] M., Klein, J. Broekstra, D. Fensel, F.

van Harmelen, and I.

Horrocks. Ontologies
and schema languages on the web. In Dieter Fensel, James Hendler, Henry
Lieberman, and Wolfgang Wahlster, editors, Spinning the Semanti
c Web: Bringing
the World Wide Web to its full potential. MIT Press, 2003.


[20] M. Masterman, Semantic message detection for machine translation, using an
interlingua, in: NPL 1961 pp. 438
-
475.


[21] M. Minsky, A framework for representing knowledge, in:
P.H. Winston, editor,
The Psychology of Computer Vision
.
New York, McGraw
-
Hill Book Company,
1975.


[22] M. R. Quillian, Semantic Memory, in: M. Minsky (ed.), Semantic Information
Processing ,1968.


[23] OWLViz, URL, http://www.co
-
ode.org/downloads/owlviz
/


[24]
OWL Web Ontology Language Guide, 2004, URL,
http://www.w3.org/TR/owl
-
guide/


[
25
] P. F. Patel
-
Schneider, P. Hayes, and I. Horrocks, OWL web ontology language
semantics and abstract syntax, W3C Working Draft, 31 March 2003.
[http://www.w3.org/TR/200
3/WD
-
owl
-
semantics
-
20030331/]


[26] P. R. Cohen and E. A. Feigenbaum, Article XI.E.1: Quillian's Semantic Memory
System, The Handbook of Artificial Intelligence 3, 1982, pp. 36
-
41.


[27] R. Costanza, R. d’Arge, R. de Groot, S. Farberk, M. Grasso, B. Hannon
, K.
Limburg, S. Naeem, R. V. O’Neill, J. Paruelo, R. G. Raskin, P. Sutton, & M. van den
Belt, The value of the world’s ecosystem services and natural capital, Nature, 387
(1997) 253
-
260.



[28]
RDF, Resource Description Framework, URL, http://www.w3.org/R
DF/


[29] RDF/XML Syntax Specification, D. Beckett, Ed., W3C Recommendation, 2004,
http://www.w3.org/TR/rdf
-
syntax
-
grammar/


[30] R. D. Tweney, and B. J. Walker, Science education and the cognitive psychology
of science. In Jones, B. F. & Idol, L., eds., D
imensions of thinking and cognitive
instruction, Hillsdale: Lawrence Erlbaum, 1990.


[31] R. J. Brachman, On the Epistemological Status of Semantic Networks, in:
Nicholas V. Findler, ed., Associative Networks: The Representation and Use of
Knowledge by Com
puters, New York, Academic Press, 1979, pp. 3
-
50.


[32]
R. J. Brachman and H. J. Levesque,
The tractability of subsumption in frame
based description languages, in: Proceedings of the 4th National Conference of the
AAAI, Austin, Tex., 1984, pp. 34
-
37.


[33
]
R. J. Brachman

and J. Schmolze,
An overview of the KL
-
ONE knowledge
representation system,
Cognitive Science
, 9(2)
(1985),
171
--
216.


[34] SEEK, URL Science Environment for Ecological Knowledge,
http://seek.ecoinformatics.org


[35] SEMATICWEB, URL, Semant
icWeb.org The Semantic Web Community
Portal, http://www.semanticweb.org
/


[36] S. Ceccato, Linguistic Analysis and Programming for Mechanical Translation,
Gordon and Breach, New York, 1961.


[37] S. D. Derry, Learning strategies for acquiring useful knowl
edge, in: Jones, B. F.
& Idol, L., eds., Dimensions of thinking and cognitive instruction
.

Hillsdale:
Lawrence Erlbaum, 1990.


[38] S. E. Gordon, and R. T. Gill, The formation and use of knowledge structures in
problem solving domains, Project Report, Ps
ychology Department, University of
Idaho, Moscow, Idaho 83843, 1989.


[39] Stella, URL,
http://www.iseesystems.com/(cq5ih555rxi3mqulqf3j4qvl)/index.aspx


[40] Touchgraph, URL, www.touchgraph.com


[
41
] T. Berners
-
Lee, J. Hendler, and O. Lassila, The semanti
c Web, Scientific
American, 284(5) (2001) 34
-
43.


[
42
] T. Berners
-
Lee, A roadmap to the Semantic Web, 1998, URL,
http://www.w3.org/DesignIssues/Semantic.html


[43] T. Liebig, O. Noppens and O.Track, Fast Browsing and Easy Editing of Large
Ontologies, in:

Proceedings of the Second International Workshop on Evaluation of
Ontology
-
based Tools (EON2003) 2nd International Semantic Web Conference,
Sanibel Island, USA, 2003.


[44] V. K. Chaudhri, A. Farquhar, R. Fikes, P. D. Karp, and J. Rice, OKBC: A
programma
tic foundation for knowledge base interoperability, in: Proceedings of the
15th Nat. Conf. on Artificial Intelligence (AAAI’98), 1998 pp. 600

607.


[45] W. E. Grosso, H. Eriksson, R. W. Fergerson, J. H. Gennari, S. W. Tu, and M. A.

Musen, Knowledge modelli
ng at the millenium (The design and evolution of

Prot´eg´e
-
2000), in: Proceedings of Knowledge Acqusition Workshop (KAW’99),
1999.


[46] W. A. Woods, What's in a link: foundations for semantic networks, in: D. G.
Bobrow and A. Collins, eds., Representation

and Understanding, Academic Press,
New York, 1975, pp. 35
-
82.