/[protege]/frames-vs-owl/FrameOWLSidebySide03.tex
ViewVC logotype

Contents of /frames-vs-owl/FrameOWLSidebySide03.tex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 2461 - (show annotations) (download) (as text)
Sat Jun 24 00:02:40 2006 UTC (12 years, 5 months ago) by vendetti
File MIME type: text/x-latex
File size: 74456 byte(s)
adding directory to house material for the frames vs. owl tutorial at the 2006 protege conference
1 \documentclass{llncs}
2 %\documentstyle[twoside,wicsbook,pt,units,coz,epsf]{article}
3 %\usepackage{pt}\\\\
4 \usepackage{graphicx}
5 \usepackage{subfigure}
6 \usepackage{epsfig}
7 \usepackage{lscape}
8 \usepackage{amssymb}
9 \usepackage{amsmath}
10 %\usepackage{lncsexample}
11 \usepackage{times}
12 \usepackage{url}
13 \usepackage{wrapfig}
14 \newcommand{\dzcmp}{\mbox{{\large $\zcmp~$}}}
15 %\newcommand{\pound}{\rlap{\hspace*{0.5pt}\raise 0.5mm\hbox{--}}{\cal L}}
16 \def\opref{\mathrel{\mathop{\kern0pt \sqsubseteq}\limits_{op}}}
17 \def\obref{\mathrel{\mathop{\kern0pt \sqsubseteq}\limits_{ob}}}
18 \newcommand{\po}{\sqsubseteq}
19 \newcommand{\zif}{{\bf if~}}
20 \def \postwr {~^\sim\mbox{\hspace{-0.75mm}}wr\_wr}
21 \newcommand{\dlocal}{{\bf dlocal}}
22 \newcommand{\local}{{\bf local}}
23 \newcommand{\dcontain}{{ dcontain}}
24 \newcommand{\contain}{{ contain}}
25 \newcommand{\dshare}{{ sdcontain}}
26 \newcommand{\share}{{ scontain}}
27 \newcommand{\llid}{{\bigcirc\scriptsize{\hspace{-0.78 em}\mbox{\tiny{L}}}}}
28 \newcommand{\onlyone}{{\bigcirc\scriptsize{\hspace{-0.76 em}\mbox{\tiny{1}}}}}
29 \newcommand{\uid}{{\bigcirc\scriptsize{\hspace{-0.79 em}\mbox{\tiny{U}}}}}
30 \newcommand{\localid}{{\bigcirc\scriptsize{\hspace{-0.78 em}\mbox{\tiny{L}}}}}
31 \newcommand{\val}{{\cal V}}
32
33
34 \newcommand{\means}{{\cal M}}
35 %\newtheorem{algorithm}[theorem]{Algorithm}
36 %reduce figure space
37 %\renewcommand\floatpagefraction{.5}
38 %\renewcommand\topfraction{.5}
39 %\renewcommand\bottomfraction{.5}
40 %\renewcommand\textfraction{.1}
41 %\setcounter{totalnumber}{50}
42 %\setcounter{topnumber}{50}
43 %\setcounter{bottomnumber}{50}
44
45
46 \newcommand{\cn}[1]{{\sf{#1}}} %Class name command
47 \newcommand{\protege}{Prot\'eg\'e } %Protege with accents
48 \newcommand{\protegeowl}{Prot\'eg\'e-OWL } %Protege-OWL with accents
49 \newcommand{\protegeframesfull}{Prot\'eg\'e-Frames } %Protege-OWL with accents
50 \newcommand{\protegeframes}{Frames } %Protege-OWL with accents
51 \newcommand{\owl}{OWL} %OWL as we intend to use it - and for consistency so I don't have to remember which are macros.
52
53 \newcommand{\opengalen}{\textit{Open}GALEN}
54 \newcommand{\poc}{\protege-OWL-CO-ODE }
55 \newcommand{\framesName}{$^F$} %Protege with accents
56 \newcommand{\ie}{\emph{i.e.} }
57 \newcommand{\eg}{\emph{e.g.} }
58
59 \newcommand{\tx}{ }
60
61 %\newcommand{\sid}{{\bigcirc\scriptsize{\hspace{-0.75 em}\mbox{\tiny{S}}}}}
62 %\pagestyle{empty}
63
64 %\input{psfig}
65
66
67 \title{\protege Frames and OWL Side by Side}
68
69 %
70 %\author{ Hai Wang ~~ Matthew Horridge~~ Alan Rector \\ Nick Drummond
71 % ~~ Julian Seidenberg
72 %\institute{
73 % Department of Computer Science,\\ The University of Manchester,\\
74 % Manchester M13 9PL, UK \\
75 % \email\{hwang,mhorridge,rector,ndrummond,jms\}@cs.man.ac.uk }}
76 \begin{document}
77
78 \maketitle
79 %\thispagestyle{empty}
80
81 \section{Introduction}
82
83 %Ontology is widely considered to be the current heir to artificial intelligence as the hype of past decades fades. Evolving from semantic network notations, modern ontology has become more and more important and has proved to be useful in many different application domains~\cite{ss, ss}. Currently there exists two different dominating ontology paradigms - frames-based and logic-based - the former being well represented by the OKBC inspired Prot\'eg\'e-Frames , the latter by the current standard Web Ontology Language, OWL. Almost every publicly available ontologies are in one of these formats or the other.
84
85 With the arrival of the Semantic Web, the widespread focus on information sharing in the sciences, ``ontologies'' have become a hot topic. ``Semantics and Metadata with everything'' - E-Research, Web Services \cite{} , Workflows \cite{}, Digital Libraries \cite{}, and resources such as the Gene Ontology and other Open Biomedical Ontologies (OBO)\cite{}, the National Cancer Institute Ontology \cite{} and the SNOMED terminology for medical applications. With the introduction of the new W3C standard Web Ontology Language OWL the use of the description logic (DL) -- or more broadly ``relational''-- paradigm has come to the fore. On the other hand, the ``object oriented'' paradigm -- represented by frame systems -- remains the dominant approach and is most familiar to most potential users. Frames based ontology languages were first introduced nearly two decades ago and used to be the most widely accepted ontology modeling languages. Most legacy knowledge models are in frames format. The relation therefore of OWL and other DL paradigms to frame paradigms is therefore a key issue. Because \protege supports both paradigms within a single overall framework, it provides an opportunity to compare them both in theory and practice. In this paper we focus on the relationship between the Frame paradigm, as represented by \protegeframes \cite{} and the OKBC standard \cite{}, and its relation to OWL and its implementation in \protegeowl. Although we focus specifically on the Frame paradigm, it has much in common with other object oriented formalisms such as RDF(S) and UML.
86
87 Frames and OWL are both knowledge-modeling languages and use similar but not identical. Both are often diagrammed using nodes and arcs; both conceptualise the domain in terms of classes, subclasses, instances (``individuals'') and properties (``slots''). Users, especially newcomers, often have difficulty recognising the differences and in choosing the appropriate paradigm for their application. Furthermore, it is often difficult for an ontologiest with significant experience in one paradigm to understand the other, even compared with new users who start from scratch. Furthermore, it is often useful to move between the two paradigms, either to access tools available only in one or because experience shows that the intiial choice was less than optimal. Transformation, in either direction, between frames and OWL is not straightforward.
88
89 In this paper, we will compare a frames-based language with OWL, specifically looking at several important differences and illustrate the differences with parallel versions of the well known Pizza and Wine examples. {{Or is this in a separate paper}}
90
91 %{{Need to describe some conventions - eg which syntax we use for the examples (abstract syntax with refs - is there one for Frames??). Also, for brevity, should we use the term "Frames" to denote Protege-Frames throughout??? - we could state this early on}}
92 %{{Could we have the example OWL and Frames ontologies available on the CO-ODE site? And reference them}}
93 %{{It feels like section 3 jumps in a bit quickly. Is it worth hinting in this introduction what the major areas of difference are in bullet form? Like Set theory semantics, Open World, Overloading/defaults, restrictions vs template slots}}
94
95
96 \section{Background}
97 \label{background}
98
99 \subsection{High level comparison}
100
101 The vocabulary used in OWL and Frames is compared in Table~\ref{vocabulary}. Although the two languages are designed to achieve many of the same outcomes, the approach is very different, and the similarities hide significant differences
102
103 % Just marked for the moment.
104
105 \begin{table} \centering
106 \bigskip
107 \renewcommand{\baselinestretch}{1}\small\normalsize
108 \begin{tabular}{|l|l|l|}
109 \hline
110 \bf{}&\bf{FRAMES}
111 & \bf{OWL} \\
112 \hline
113 Concepts in application domains & Class & Class\\
114 \hline
115 Relations among entities & Slot & Property \\
116 \hline
117 Constrians on values &Retriction & Facet\\
118 \hline
119 \end{tabular}
120 \renewcommand{\baselinestretch}{2}\small\normalsize
121 \vspace{0.1ex}
122 \caption{Vocabulary used in Frames and OWL} \label{vocabulary}
123 \end{table}
124
125
126 \emph{VOCABULARY COMPARISON TABLE TO GO ABOUT HERE}
127
128 % This list is too long and not well enough focused, but I can't fix it until the rest of the paper comes together.
129 \textbf{THIS LIST IS TOO LONG AND NOT WELL ENOUGH ORGANISED, BUT IS A BRAINSTORM TO BE ORGANISED AS THE PAEPR EVOLVES}
130 \begin{description}
131
132
133 \item[Semantics: operations vs meaning] A \protegeframes knowledge base defines a set of operations - literally a set of functions or logic programmes - and their outcomes when performed on entities in the knowledge base. An \owl knowledge base defines the meaning of a set of entities in the knowledge base in terms of the logical relations between them. In effect, \protegeframes leaves open the detailed interpretation of the ``meaning'' but defines well the operations to be performed. The \protegeframesfull tool closely reflects these operations. By contrast, \owl captures the meaning but leaves open the operations, which have to be decided by each implementer. One particular set of operations is provided by the \protegeowl toolset.
134
135 \item[Semantics: templates vs sets] A \protegeframes knowledge base consists of a set of templates for objects or ``frames''. The semantics is defined by a set of functions on those objects. A \owl knowledge base consists of a set of logical axioms constraining the relationship between individuals or sets of individuals. A class in \protegeframes is fundamentally a template for its instances, and every frame must be an instance of some class. Hence \protegeframes must contain a number of built in classes as a starting point. A class in \owl is fundamentally a set. \owl provides ``constructors'' such as union and intersection to build new sets from old and to restrict the contents of that set and the relations between individuals.
136
137
138
139 \item[Open vs closed world semantics] \protegeframes is normally treated as having closed world semantics -- things not present are considered false. OWL uses open world semantics -- things not present are unknown unless provably absent. This means that OWL requires closure axioms for explicitly closed world situations, whereas \protegeframes does not.
140
141 \item[Underspecification and existential quantifiers] In \owl it is possible to say that an individual of some class exists without creating and naming it -- \eg to say that ``John has a sister (who is a Person)'' without having to create an individual of type Person. Similarly, \owl leaves open, unless explicitly declared, whether two classes are the same, overlapping, or disjoint and whether two individuals are the same or different. By contrast, \protegeframes adheres to the ``unique name assumption'', and classes are usually treated as being disjoint unless they have a common subclass.
142
143 \end{description}
144
145 There are a range of other differences and comparisons to be entered later.
146
147 \subsection{Saying something simple: Pizzas have toppings that must be of class PizzaTopping}
148
149
150 \begin{figure*}[t]
151 \begin{center}
152 %\includegraphics[width=14cm]{SimpleNodeArc}
153 \mbox{\epsfxsize=130mm \epsfbox{SimpleNodeArc}}
154 \caption{Propagation of template and own slots through the subclass-of and instance-of relations. ??PLACEHOLDER??}
155 \label{basicNodeArc}
156 \end{center}
157 \end{figure*}
158
159
160 \begin{figure*}[h]
161 \begin{center}
162 %\includegraphics[width=14cm]{uml}
163 \mbox{\epsfxsize=130mm \epsfbox{uml}}
164 \caption{Propagation of template and own slots through the subclass-of and instance-of relations. ??PLACEHOLDER??}
165 \label{uml}
166 \end{center}
167 \end{figure*}
168
169 The basic intuition in both \protegeframes and \protegeowl is that we want to describe relations between entities. In \protegeframes the original purpose was to constrain data entry in intelligent forms; in \owl, it is to describe entities logically.
170 We often picture the entities as nodes -- classes and individuals -- and the relations as arcs, as shown in Figure~\ref{basicNodeArc}.
171 The same picture is often expressed in UML diagram by an association between two classes~\ref{uml}.
172 The question - originally raised in a slightly different context by Wood in \cite{WhatsInALink} -- is what does such a diagram mean.
173
174 The OKBC/\protegeframes interpretation is that there is a function that given the class Pizza and the slot hasTopping returns a value. There is an ambiguity about how the diagram should be interpreted. One representation is that the value is itself the class PizzaTopping; the other is that there is a ``allowed classes'' facet on the has$\_$property that indicates that, for any instance of the class Pizza, the only values allowed must be of class PizzaTopping, or at least that PizzaTopping is in the list of allowed classes. In either case, whether or not Pizza Toppings is required for Pizzas is likewise ambiguous in the diagram and would be specified by another facet on the property hasTopping indicating whether the slot was ``optional'' or ``mandatory''.
175
176 The same ambiguities are present in representing the intended meaning of the diagram in \owl. The \owl interpretation would usually be an axiom equivalent to ``All pizzas have toppings that are PizzaToppings'', leaving it open as to whether they had any other kind of toppings. Alternatively, one might interpret diagram as meaning ``All pizzas have only PizzaToppings as toppings'', leaving it open as to whether there were any toppings at all - just specifying that if there were any they were PizzaToppings.
177
178 There are three obvious differences in these two interpretations.
179 \begin{description}
180
181 \item[Values vs Restrictions ] The simplest interpretation of the diagram is to make \textit{PizzaTopping} the value of the slot \textit{hasTopping} for textit{Pizza}. This is allowed in \protegeframes but not in \owl,. More properly, it is only allowed in OWL-Full, and if one does so the semantics is clearly that the thing linked to the class textit{Pizza} is the class textit{PizzaToppings} - that is that an individual pizza would have classes of toppings rather than individual toppings. Clearly not what is meant. Arguably, the same problem applies in \protegeframes, but because it is defined procedurally, a programme can choose its interpretation. in \owl, the interpretation is fixed by the semantics of the language. \textbf{??THE DISCUSSION OF FLAVOURS OF OWL NEEDS TO GO IN EARLIER OR SOME OTHER RE-ORGANISATION??~~~~} However expessed, in \protege frames, we specify a value or values for a series of functions -- the slot and facet values. In OWL we assert that the class is ``restricted'' to those satisfying the axioms -- in this case that all of their members have a topping. Both represent the arc between Pizza and PizzaTopping, but despite superficial similarities, the underlying meaning is quite different.
182
183 \item[mandatory/ optional vs underspecification] In \protegeframes, the meaning of ``mandatory'' is that a value must be entered for an individual. Since \protegeframes uses closes world semantics, the only way we can know that a value exists is if it is actually present. in \owl, the statement ``All pizzas have some pizza topping" means precisely that. Even if we don't know what it is, there is one -- \ie. the description of the Pizza can ``underspecified''; we can know that something of a given Class is there, even if we cannot specify its identity, indeed even if there is no such individual explicitly in the KB.
184
185 Whether or not we are required to enter the individual's identifier when entering data on an individual of this class is not an issue about which OWL semantics has anything to say. Tools can impose various conventions for providing this information, but it is 'meta information' separate from the \owl knowledge base itself. Put another way, it may be a fact about our conceptualisation of the world that all pizzas have toppings; however, when constructing pizza menus we might choose always to list the toppings, never to list the toppings, or optionally to list the toppings. The pizzas would be the same; the menus would be different. In a strong sense, \owl is designed for representing Pizzas; \protegeframes is designed for representing ``menus'', or more generally forms.
186
187
188
189 \end{description}
190
191 Figure ???? gives~the OKBC and \owl representation of the various interpretations of Figure~\ref{basicNodeArc}.
192
193 In fact, the simple node-and-arc diagram as in Figure~\ref{basicNodeArc} really only applies to \owl individuals. The \owl ``restrictions'' on classes are defined in terms of logical statements about the arcs between individuals, though we often choose to draw them otherwise. A more appropriate representation for the \owl interpretation would be as given in Figure ????A variation on Matt's drawing in the Pizza Tutorial??.
194
195
196 \subsection{Classification}
197
198 A second major important set of differences between \protegeframes and \owl is the difference between checking constraints and inferring consistency and classification.
199
200 \begin{description}
201
202 \item[Classification and sufficient conditions] In \protegeframes, filling a slot makes a statement about all instances of that slot (except for possible exceptions provided by default values). In \owl, there are effectively two kinds of statements -- a) those that, as in \protegeframes are true of all individuals in a class, and b) those that are collectively sufficient to \emph{define} the class. A reasoner, sometimes called a ``classifier'' can use the sufficient conditions to infer which classes are subclasses (``subsumed by'') the defined class. The \owl classifier can infer additional links in the subclass hierarchy; there is no equivalent feature in \protegeframes.
203
204 \item[Input constraints and checking vs Inference and consistency testing] The same reasoner that checks the classification also checks that an OWL KB is consistent, (or in OWL parlance ``satisfiable''). By contrast in Protege, a program such as PAL can check constraints. However, the inferences are almost always local. It cannot make inferences that change the hierarchy asseerted by the user and take that into account in determining whether a knowledge base is consistent.
205
206
207 \item[Permissions vs constraints] In \protegeframes, everything is prohibited until it is permitted; in \owl, everything is permitted until it is prohibited. Neither statement is explicit from the specifications, but follows from the structure. Nothing can be entered into a \protege KB until there is a place for it in the corresponding template. Anything can be entered into an OWL KB unless it violates one of the constraints.
208
209
210 \end{description}
211
212
213 ???Bring vegetarian pizzas in here??
214
215
216
217 \textbf{??A LIST OF SOME THINGS TO GO IN SOMEPLACE , PERHAPS JUST A TABLE - IN TERMS OF EXPRESSIONS THAT EXIST IN ONE LANGUAGE OR THE OTHER, WITH OR WITHOUT VARIOUS EXTENSION??}
218
219
220 Other things ??? links not in yet.
221
222 \begin{description}
223
224 \item[Object orientation vs relation orientation] In \protegeframes, all information must belong to a given frame. In OWL, in principle, information can be entered in any order, and it requires considerable effort in the tools to provide a view corresponding to a \protegeframes of all of the information pertinent to a given individual or class. The difference is related to the difference between object-oriented and relational databases. The most important consequence is that all statements in Protege are local to the frame, whereas all statements in OWL are, in principle, global.
225 \item[variable facets vs constructors and characteristics of properties] \protege instances]
226
227
228
229
230 \item[Transitive and related attributes of properties]
231 \item[Boolean connectives - and, or, and not]
232
233
234
235 \item[defaults and exceptions]
236
237 \item[etc. ]
238
239
240
241
242
243
244 \end{description}
245
246
247
248
249
250
251 \subsection{\protegeframesfull overview}
252
253 The \protegeframes model is compatible with OKBC (Open Knowledge-Base Connectivity protocol), which is a common query and construction interface for frame-based systems to facilitate interoperability. \protegeframes further restricts the OKBC knowledge model to specify all the behaviors of a knowledge-model component explicitly. At base, OKBC
254
255 As a frame-based knowledge model, a frame is the principal building
256 block of a knowledge base in \protegeframes. A \protegeframes ontology consists of classes, slots and facets, which are all types of frame.
257
258 \subsubsection{Class}
259 Classes are concepts in the domain of discourse and constitute a taxonomic hierarchy. For example, we can define the classes \textit{Pizza, VegetarianPizza, LowFatPizza} to represent the different concepts in a Pizza restaurant domain. \textit{VegetarianPizza, LowFatPizza} classes are the subclasses of the \textit{Pizza} class. \protegeframes allows one class to have more than one superclass. For example, the \textit{FruitPizza}
260 class could be the subclass of both \textit{VegetarianPizza}, and \textit{LowFatPizza} classes. Both individuals and classes themselves can be instances of classes as well.
261
262 \subsubsection{Slot}
263 Slots describe properties or attributes of classes and instances, such as the toppings a pizza can have. In \protegeframes slots are first-class objects: Slots are defined independently of any class. To describe properties of a particular frame, a slot has to be attached to that frame. For example, we can define a slot \textit{hasTopping} and attach it to the class \textit{PIzza} to represent the toppings pizzas can have. When a slot is attached to a frame it can have a value. For example, the \textit{hasTopping} slot for a instance of \textit{Pizza} may have an instance of \textit{Vegetable} class as the value.
264
265 A slot can be attached to a frame in one of two ways: as a \textbf{template slot }or as an \textbf{own slot}. An own slot attached to a frame describes properties of an object represented by that frame (an individual or a class). Own slots attached to a class do not get inherited by its subclasses or propagated to its instances. Template slots can be attached only to class frames. A template slot attached to a class is inherited by its subclasses. In addition, a template slot on a class becomes an own slot on the instances of that class (Figure~\ref{debugging} ). Template slots describe properties that an instance of a class shall have.
266
267 \begin{figure*}[t]
268 \begin{center}
269 %\includegraphics[width=14cm]{frames}
270 \mbox{\epsfxsize=130mm \epsfbox{frames}}
271 \caption{Propagation of template and own slots through the subclass-of and instance-of relations.}
272 \label{debugging}
273 \end{center}
274 \end{figure*}
275
276 \subsubsection{Facet}
277 We can add facets to template slots \textbf{Facets} describe properties of slots and they are used to specify constraints on allowed slot values. The constraints specified using facets include cardinality of a slot (how many values the slot can have), restrictions on the value type of the slot (for example, integer, string, instance of a class), minimum and maximum value for a numeric slot, and so on. Facets define restrictions on an attachment of a slot to a class frame. For example, for the instances of the class \textit{VegetarianPizza}, the slot \textit{hasTopping} can only have instances of \textit{Vegetable} as its values.
278
279
280 \subsection{OWL overview}
281
282 An OWL ontology consists of classes, properties and individuals.
283 Classes are interpreted as sets of objects that represent the
284 individuals in the domain of discourse. Properties are binary
285 relations that link individuals and are represented as sets of
286 ordered pairs that are subsets the cross product of the set of objects.
287
288 \subsubsection{Class }
289 OWL classes fall into two main categories -- named classes and
290 anonymous (unnamed) classes. Anonymous (unnamed) classes are formed
291 from logical descriptions. They contain the individuals that
292 satisfy the logical description. Anonymous classes may be
293 sub-divided into restrictions and `logical class expressions'.
294 Restrictions act along properties, describing sets of individuals
295 in terms of the types of relationships that the individuals
296 participate in.
297
298 Logical classes are constructed from other classes using the
299 boolean operators AND ($\sqcap$), OR ($\sqcup$) and NOT ($\lnot$).
300
301 \subsubsection{Property}
302 Properties in OWL are similar to slots in \protegeframes. In OWL properties are first-class objects as well. OWL also allows `global' axioms to be put on properties. We can define a property to be `functional' or `transitive' etc. The \textit{domain} and \textit{range} can also be specified for properties. In many other languages including \protegeframes, domain and range are commonly used as constraints that are checked and generate warnings or errors if violated. Hence domain and range constraints can be used in inference. More details about this difference will be discussed in later sectionm.
303
304
305
306 %
307 %\subsubsection{Disjoint Axioms}
308
309 %All OWL classes are assumed to overlap unless it is otherwise
310 %stated that they do not. To specify that two classes do not
311 %overlap they must be stated to be \emph{disjoint} with each other
312 %using a \emph{disjoint axiom}. The use (and misuse) of disjoint
313 %axioms is one of the primary causes of unexpected classification
314 %results and inconsistencies~\cite{errorsInOWL}. Disjoint axioms
315 %are `inherited' by their subclasses. For example if \cn{Pizza} is
316 %disjoint from \cn{PizzaTopping} then all subclasses of \cn{Pizza}
317 %will be disjoint from all subclasses of \cn{PizzaTopping}. This
318 %can make debugging difficult for ontologies that have deep
319 %taxonomical hierarchies.
320
321 %\subsubsection{Describing Classes}
322
323 %Named OWL classes are described in terms of their named and anonymous
324 % super classes, equivalent classes and disjoint classes. When a restriction is added to a
325 %named class, it manifests itself as an anonymous superclass of the named class.
326
327 % For example the named class
328 %\cn{VegetarianPizza} might have a named superclass called
329 %\cn{Pizza} and also the anonymous super class
330 %\cn{$\forall$~hasTopping~Vegetable}. That is,
331 %things that are \cn{VegetarianPizza}s are also
332 %\cn{Pizza}s and things that have only
333 %\cn{vegetable}s as toppings. We refer to these super classes as
334 %\textit{conditions}, as they specify the conditions for membership
335 %of a given class.
336
337
338
339 %\subsubsection{Model-theoretic semantics}
340
341
342
343
344 \section{Comparison of Semantics}
345
346 \protegeframes and OWL define their semantics in different ways. Compatibility with and extension of OKBC give \protegeframes system a well defined operational semantics which strongly match the process of knowledge acquisition. It is clearly defined how forms will be generated from class and slot definitions and how instances will be input into the knowledge base using those forms.
347 OWL does not have any operational semantics in this context. Instead, it defines how statements should be interpreted to fully understand the meaning captured in a knowledge base. As an ontology language based on Description Logics, it has rigorous formal denotational semantics (based on model theory). Every construct and statement in OWL has a precisely defined meaning and there is no ambiguity. The model-theoretic semantics of OWL has been formally proved to be sound and complete. The denotational semantics for \protegeframes is less rigorous. Although the \protegeframes knowledge model is compatible with OKBC, the semantics of OKBC itself is less formal and the meaning of some frames statements like the slot-facet is often unclear and could be interpreted differently by various applications.
348
349 OWLÕs formal denotation semantics is very suited to machine understanding of the meaning captured in a knowledge model. Therefore it is easier to build tools to assist users to build and use the knowledge models. On the other hand, \protegeframes operational semantics is closer to the philosophersÕ understanding of ontology building and is more intuitive for users to understand the process of knowledge acquiring. These significant differences create enormous difficulties for people trying to understand and use those two languages. In this section we present the major semantic differences between \protegeframes and OWL-DL, giving examples of specific modelling issues, and describe some of the different assumptions being adopted by frames systems and OWL.
350
351 {{We are very biased towards OWL - there is little comparison taking place - is it possible to do some of these OWL things in PAL for example? We need to check with Stanford}}
352 {{Quite a lot of this section feels like it just reiterates the common errors paper - prob best to shorten}}
353
354 \subsection{Property Association}
355 \subsubsection{Association of Slots/Properties to Classes}
356 \protegeframes and OWL describe a concept in different ways. To illustrate the difference, the class \textit{VegetarianPizza} has been defined in both \protegeframes and OWL (Figure~\ref{modelconcept})\footnote{In this paper, The word ``\framesName'' is appended to all the entities defined in \protegeframes system to distinguish those corresponding elements defined in OWL {{I think we scrub this - it doesn't help and the text doesn't match this anyway}}. }. The two definitions try to express the same fact, that is \textit{VegetarianPizza} is a pizza which can only have vegetable toppings, using the different languages. They maybe look similar from the abstract syntax representation however, underneath, the modelling process is quite different. In \protegeframes, it requires two modeling steps for this task. The slot \textit{hasTopping} has to be explicitly associated to the class first, then we can add the constraint facet to the associated slot. Contrastingly, in OWL, the restriction can be added to the class directly. This is because in \protegeframes, a class is assumed to have no slots associated with it unless they have been explicitly added to it or its parents. In OWL, we can add restrictions to a class on any property\footnote{Adding restrictions to an OWL class can cause bring unexpected effects - this will be discussed in section~\ref{domainRange}. } directly because of the Open World Assumption (Section~\ref{openclose}).
357
358 \begin{figure}[!ht]
359 \center \fbox{ \small{ \parbox{4.0in}
360 {\begin{flushleft}\vspace{-0.3cm}
361 \textbf{\protegeframes :} \\
362 (defclass \cn{VegetarianPizza\framesName} \\
363 ~~~(IS-A \cn{Pizza\framesName}\\
364 ~~~(multislot hasTopping\framesName ~~~~ \textbf{//step one: attach the slot to the class} \\
365 ~~~(allowed-class Vegetable\framesName)) \textbf{ //step two: add the constraint} \\~~
366 \\
367 \textbf{OWL:} \\
368 Class (\cn{VegetarianPizza} complete \\
369 ~~~\tx \cn{Pizza} \\
370 ~~~\tx restriction (\cn{hasTopping} allValuesFrom \cn{Vegetable}))\\
371 %\textbf{Paraphrase:} \\
372 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
373 %things}, both does \emph{not} have \emph{some} meat topping and
374 %also does \emph{not} have \emph{some} fish topping.
375 %\vspace{-0.15cm}
376 \end{flushleft}}}}
377 \caption{Model a concept in \protegeframes and OWL {{Would Pizza -> hasBase only PizzaBase be a better example?}} }
378 \label{modelconcept}
379 \end{figure}
380
381
382 \subsubsection{Relating individuals by slot/property }
383 \protegeframes does not allow direct attachment of own slots to frames, therefore instances (both normal instances and class instances) can only have values for those slots defined as template slots on their type classes. For example, we can not add any values to a direct instance of \textit{:Thing}. Normally the deeper a class is located in the class hierarchy, the more we could say about its instances.
384 OWL behaves in the opposite way. An OWL individual can have a relationship along any property unless it has been asserted that it canÕt. We could say anything about an instance of \textit{OWL:Thing}. The deeper a class is located in the class hierarchy, the less we can say about its instances.
385 For instance, continuing with the example we defined in Figure~\ref{modelconcept}, we define an instance of the class \textit{VegetarianPizza} in both \protegeframes and OWL and use a slot/property, \textit{hasFatness}. In \protegeframes, we are prevented from adding values for the slot \textit{hasFatness} to \textit{aVegetarianPizza}, as the slot \textit{hasFatness} is not associated with the class \textit{VegetarianPizza}. However, in OWL this is perfectly legal (~Figure~\ref{relatedindividuals}). It will be an error (inconsistent) only if it is asserted or inferred that the class \textit{VegetarianPizza} cannot have any values for the property \textit{hasFatness}, e.g. it is disjoint with the domain of the property \textit{hasFatness}.
386
387 \begin{figure}[!ht]
388 \center \fbox{ \small{ \parbox{4.0in}
389 {\begin{flushleft}\vspace{-0.3cm}
390 \textbf{\protegeframes:} \\
391 ([\cn{aVegetarianPizza\framesName} of \cn{VegetarianPizza\framesName} \\
392 ~~~(\cn{hasFatness\framesName} ...) ~~~~ \textbf{// It is an error in \protegeframes.} \\
393 )\\~~
394 \\
395 \textbf{OWL:} \\
396 Individual(\cn{aVegetarianPizza}\\
397 ~~~~~\tx type(\cn{VegetarianPizza})\\
398 ~~~~~\tx value (\cn{hasFatness} ....))
399 %\textbf{Paraphrase:} \\
400 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
401 %things}, both does \emph{not} have \emph{some} meat topping and
402 %also does \emph{not} have \emph{some} fish topping.
403 %\vspace{-0.15cm}
404 \end{flushleft}}}}
405 \caption{Relate individuals in \protegeframes and OWL }
406 \label{relatedindividuals}
407 \end{figure}
408
409
410 \subsection{Classification vs. Assertion}
411 \label{definedClass}
412 In \protegeframes, all subclass relations and instantiation relations must be asserted, but in OWL this information can be either asserted directly or inferred.
413 Although, in theory, the OKBC specification provides an interface for frames-based systems to support ``defined'' classes~\footnote{reference from OKBC spec??}, i.e. to specify a set of necessary and sufficient conditions for being an instance of a class, in \protegeframes (and to the best of our knowledge, all other Frames systems, object oriented programming and analysis and UML as well), classes can only be described but not defined.
414 One of the major advantages of OWL is that it supports both ``primitive'' and ``defined'' classes, which can be used for reasoning in OWL-DL ontologies. New concepts can be built up from existing concepts by fitting them together in definitions like blocks of Lego. More formally, OWL allows concepts to be defined by sets of necessary and sufficient conditions. We refer to classes for which there are only necessary conditions -- marked by the keyword ``partial\footnote{OWL descriptions are sometimes known as Òpartial definitionsÓ and the keyword ``partial'', appears in OWL syntax and in OilEd. This usage is seriously misleading and the term Òpartial definitionÓ a misnomer. Many of the restrictions on primitive, or indeed defined, classes are necessary implications and take no part in any set of necessary and sufficient conditions - i.e. in definitions Ð ``partial'' or otherwise.}'' in the abstract syntax -- as ``primitive'' classes{{, harking back to an older terminology - delete?}}. Classes for which there is at least one set of necessary and sufficient conditions -- marked in the abstract syntax by the keyword ``complete'' -- are referred to as ``defined''.
415
416 \begin{figure}[!ht]
417 \center \fbox{ \small{ \parbox{4.0in}
418 {\begin{flushleft}\vspace{-0.3cm}
419 \textbf{\protegeframes:} \\
420 (defclass \cn{VegetarianPizza\framesName} \\
421 ~~~(multislot hasTopping\framesName \\
422 ~~~(allowed-class Vegetable\framesName)) \\
423 (defclass \cn{MushroomPizza\framesName} \\
424 ~~~\textbf{(IS-A \cn{VegetarianPizza\framesName}) ~~~~~ // It has to be explicitly asserted!}
425 ~~~(multislot hasTopping\framesName \\
426 ~~~(allowed-class Mushroom\framesName)) \\
427 \textbf{OWL:} \\
428 Class (\cn{VegetarianPizza} \textbf{COMPLETE \\
429 ~~~~ // the keyword changes to ''COMPLETE''}\\
430 ~~~\cn{Pizza} \\
431 ~~~~~~ (restriction \cn{hasTopping} allValuesFrom \cn{Vegetable}))\\
432 Class (\cn{MushroomPizza} partial\\
433 ~~~ \cn{Pizza} \\
434 ~~~~~~ restriction (\cn{hasTopping} allValuesFrom \cn{Mushroom}))\\
435 %\textbf{Paraphrase:} \\
436 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
437 %things}, both does \emph{not} have \emph{some} meat topping and
438 %also does \emph{not} have \emph{some} fish topping.
439 %\vspace{-0.15cm}
440 \end{flushleft}}}}
441 \caption{Asserted and inferred IS-A relations }
442 \label{is-a}
443 \end{figure}
444
445 Previously we stated that a \textit{VegetarianPizza} must only have toppings that are \textit{Vegetables} (Figure~\ref{modelconcept}). Coming from the other direction, suppose that we want to model the fact that any pizza that only has vegetables as its topping must be a \textit{VegetarianPizza}. Furthermore, we also define a special kind of \textit{VegetarianPizza} -- \textit{MushroomPizza}, which can only have \textit{Mushrooms} as its toppings. The frames definition of \textit{VegetarianPizza} is unchanged as \protegeframes does not allow us to defined a class. In fact, we have to explicitly assert that \textit{MushroomsPizza} is a subclass of \textit{VegetarianPizza}. In OWL we can create the \textit{MushroomsPizza} with this more constrained restriction and change the \textit{VegetarianPizza} class from ÒprimitiveÓ to ÒdefinedÓ -- note the keyword has been changed to ÒcompleteÓ (Figure~\ref{is-a}). The IS-A relationship will be inferred automatically by reasoners.
446 The ability to define classes in OWL brings a number of important advantages. For example, it can be used as a mechanism for ÔnormalisingÕ ontologies \ref{alanNormal}. More detail about normalizing ontologies will be discussed when we compare the different supporting tools for \protegeframes and OWL in section~\ref{reasoner}.
447 Although ``defined'' classes bring many advantages, understanding the difference between ``primitive'' and ``defined'' classes in OWL is one of the major stumbling blocks experienced by frames ontologists. In our experience, the most common accidental error made by frames ontologists in implementing OWL ontologies is to fail to make a set of restrictions a definition. In our \protegeowl interface, sets of Ònecessary and sufficientÓ conditions appear in the same widget as the set of necessary conditions, so that both sets are simultaneously visible.
448 It is critical to understand that, in general, the reasoner will not classify anything underneath a primitive concept. In the OWL example in (Figure~\ref{is-a}), if ``partial'' isn't replaced by ``complete'', no IS-A relation will be inferred between \textit{MushroomsPizza} and \textit{VegetarianPizza}. The first thing, therefore, to look for when things fail to be classified under a concept, is whether it has been defined.
449
450
451 \subsection{Knowledge checking vs. Knowledge reasoning (Constraints vs Reasoning)}
452 \label{domainRange}
453 The facts asserted in \protegeframes can be divided into knowledge reasoning facts and knowledge checking facts. They both play different roles in a knowledge model. The knowledge reasoning facts, e.g. the subclass relationship, can be used to conclude new knowledge from the asserted knowledge. For example, if we know that ``A'' is a subclass ``B'' and ``a'' is an instance of ``A'', then we can infer the new knowledge that ``a'' is an instance of class ``B'' as well {{Can we??}}. The knowledge checking facts, e.g. domain definition for frames slots, are used as operational constraints to check if the knowledge being acquired is valid or not. Normally they are used to restrict the interface to prevent invalid input or trigger an error message to prompt the user to correct the violation.
454 In OWL, all the assertions made are knowledge reasoning facts and they are all treated as axioms used for inference. The reasoner assumes that all the asserted facts are correct and tries to build a model that satisfies all these facts. If no such model can be built, the knowledge model is inconsistent.
455 Users often have difficulty using constructors that appear in both languages but play different roles in each. For example, we want to model a concept \textit{MeatyVegetarianPizza}, which is a subclass of \textit{VegetarianPizza} and can only have \textit{Beef} topping (Figure~\ref{meatyVeg}). In \protegeframes, the user interface prevents this from being modelled as it is considered an error. This is because the superclass of \textit{MeatyVegetarianPizza} -- \textit{VegetarianPizza} -- requires all the toppings to be \textit{Vegetables} and \textit{Beef} is not a kind of \textit{Vegetable}. This behaviour prevents the wrong knowledge being asserted. Making the same statement in OWL means that \textit{MeatyVegetarianPizza} can only have those toppings which are both \textit{Vegetable} and \textit{Beef}. If there is nothing in our model to state otherwise (e.g. disjoints), by default it is possible for something to be both vegetable and beef -- more details about this issue will be discussed later (Secton~\ref{}). In fact, even we asserted these classes disjoint, we could have a consistent \textit{MeatyVegetarianPizza} with no any toppings at all. This is commonly known as ``trivial satisfaction''~\cite{common errors paper} -- ``only'' does not state ``at least one''. Regardless of the consistency of our statements, the act of using a reasoner as a ``compiler'' means we generally do not catch these ``errors'' until the ontology is classified -- the issue of how many errors can be prevented at editing time is an ongoing one and requires consideration of both computational efficiency and user interference. Several interfaces that enforce some of the Frames-style constraints on input have proved very useful in reducing error rates \cite{designing UIs prevent errors paper}.
456
457 \begin{figure}[!ht]
458 \center \fbox{ \small{ \parbox{4.0in}
459 {\begin{flushleft}\vspace{-0.3cm}
460 \textbf{\protegeframes:} \\
461 (defclass \cn{MeatyVegetarianPizza\framesName} \\
462 ~~~(IS-A \cn{VegetarianPizza\framesName})
463 ~~~(multislot hasTopping\framesName \\
464 ~~~(allowed-class Beef\framesName)) ~~~~~ \textbf{// This is an error!} \\
465 \textbf{OWL:} \\
466 Class (\cn{MeatyVegetarianPizza} partial \\
467 ~~~\cn{VegetarianPizza} \\
468 ~~~~~~ restriction( \cn{hasTopping} allValuesFrom \cn{Beef})\\
469 %\textbf{Paraphrase:} \\
470 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
471 %things}, both does \emph{not} have \emph{some} meat topping and
472 %also does \emph{not} have \emph{some} fish topping.
473 %\vspace{-0.15cm}
474 \end{flushleft}}}}
475 \caption{Knowledge checking vs. Knowledge reasoning}
476 \label{meatyVeg}
477 \end{figure}
478
479
480 Another example for this difference between \protegeframes and OWL is the use of property domain and range (Figure~\ref{domain}). Domain and range are axioms in OWL but constraints that can be simply checked in Frames systems. Tool support in OWL is more complicated than in other languages, because a class that may not satisfy a constraint prior to classification may be inferred by the classifier to do so (and vice-versa). Usually, but not always, such behavior is unintended and indicates an error.
481
482
483 \begin{figure}[!ht]
484 \center \fbox{ \small{ \parbox{4.0in}
485 {\begin{flushleft}\vspace{-0.3cm}
486 \textbf{\protegeframes:} \\
487 (multislot \cn{hasTopping\framesName} \\
488 ~~~(Type instance) \\
489 ~~~(domain \cn{Pizza\framesName}))\\
490 (defclass \cn{ChocIcecream\framesName} \\
491 ~~~(multislot hasTopping\framesName ....) ~~~~~ \textbf{// This is an error!} \\
492 \textbf{OWL:} \\
493 ObjectProperty (\cn{hasTopping} domain \cn{Pizza}) \\
494 Class (\cn{ChocIcecream } partial \\
495 ~~~~~~\tx restriction (\cn{hasTopping} someValuesFrom \cn{Chocolate}))\\
496 %\textbf{Paraphrase:} \\
497 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
498 %things}, both does \emph{not} have \emph{some} meat topping and
499 %also does \emph{not} have \emph{some} fish topping.
500 %\vspace{-0.15cm}
501 \end{flushleft}}}}
502 \caption{Domain example}
503 \label{domain}
504 \end{figure}
505
506 \subsection{Things are different? Or not?}
507 In \protegeframes, things are assumed to be different by default, while OWL behaves in exactly the opposite way. This difference affects both class level and instance level statements.
508
509 \subsubsection{Disjoint vs. overlapping between classes}
510
511 In frames systems, two classes are assumed to be ``disjoint'' unless they have some common subclass. In contrast, OWL classes are assumed to ``overlap'' by default. An OWL individual cannot be assumed not to be a member of a particular class simply because it has not been asserted to be a member of that class, or it has been asserted to be a member of a different class. OWL provides three constructs for stating facts about the inclusive relationships among classes. They are \textit{owl:disjointWith}, which is used to state that two classes have no common instances, \textit{rdfs:subClassOf}, which states the instances of a class description is a subset of the instances of another class description, and \textit{owl:equivalentClass}~\footnote{In OWL, each class has been associate with both an intensional meaning (the underlying concept) and a class extension (a set of individual instances). The use of owl:equivalentClass does not imply two classes are same. It means that they are two different classes, which have same extention (instances). Two classes are the same only if they have the same intensional meaning (denoting the same concept), which can only be asserted by using owl:sameAs construct within OWL FULL.}, which means that a class has exactly the same instances as another class. In the absence of one of these statements, OWL tools should make no assumptions.
512 To demonstrate the difference, Figure~\ref{classDisjoint} shows a small fragment of ontology in both formats. Three classes -- \textit{PizzaTopping}, \textit{PizzaBase}, \textit{Pizza} and one slot /property \textit{hasTopping} have been created. The value of \textit{hasTopping} must come from the class \textit{PizzaTopping}. An instance of the class \textit{Pizza}, \textit{aPizza}, is related to another instance \textit{aPizzaBase}, which is an instance of the class \textit{PizzaBase}, by the property \textit{hasTopping}. In frames systems, this would be treated as an error, as \textit{PizzaBase} and \textit{PizzaTopping} are disjoint. In OWL, we have to explicitly assert that \textit{PizzaTopping} and \textit{PizzaBase} are disjoint. Without this disjoint axiom, \textit{aPizza} would be a consistent individual, as it is possible for \textit{PizzaTopping} and \textit{PizzaBase} class to have some shared instances, like \textit{aPizza}.
513
514 \begin{figure}[!ht]
515 \center \fbox{ \small{ \parbox{4.0in}
516 {\begin{flushleft}\vspace{-0.3cm}
517 \textbf{\protegeframes:} \\
518 (defclass \cn{PizzaTopping\framesName}) \\
519 (defclass \cn{PizzaBase\framesName}) \\
520 (defclass \cn{Pizza\framesName} \\
521 ~~~(multislot hasTopping\framesName \\
522 ~~~~~~~~~~ ....\\
523 ~~~~~~~~~~(allowed-class \cn{PizzaTopping\framesName}
524 ) \\
525 ([\cn{aPizzaBase\framesName}] of \cn{PizzaBase\framesName}) \\
526 ([\cn{aPizza\framesName}] of \cn{Pizza\framesName}\\
527 ~~~~~(\cn{hasTopping} \cn{aPizzaBase\framesName}) \\~\\
528 \textbf{OWL:} \\
529 Class(\cn{PizzaTopping })
530 Class(\cn{PizzaBase} )\\
531 \textbf{disjointWith(\cn{PizzaTopping }, \cn{PizzaBase })}\\
532 \textbf{// This disjoint information need to be explicitly asserted. }\\
533 Class (\cn{Pizza } partial \\
534 ~~~~~~ restriction \cn{hasTopping} allValuesFrom \cn{PizzaTopping})\\
535 Individual(\cn{aPizzaBase} Type(\cn{PizzaBase}))\\
536 Individual(\cn{aPizza} \\
537 ~~~Type(\cn{Pizza})\\
538 ~~~value(\cn{hasTopping} \cn{aPizzaBase}))
539
540 %\textbf{Paraphrase:} \\
541 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
542 %things}, both does \emph{not} have \emph{some} meat topping and
543 %also does \emph{not} have \emph{some} fish topping.
544 %\vspace{-0.15cm}
545 \end{flushleft}}}}
546 \caption{Class disjointness example}
547 \label{classDisjoint}
548 \end{figure}
549
550 \subsubsection{Distinct vs. Same Instances --- Unique Name Assumption (UNA) }
551 \protegeframes, like many other languages, has a so-called ``unique names'' assumption, i.e. different names refer to different things {{I'm surprised frames cannot assert two classes/individuals as being equivalent - can this be done in PAL}}. However, in OWL such an assumption is invalid, i.e. different names (URI references) could refer to the same thing. This is because OWL has been designed with distribution and reusability in mind - features critical in realising the next generation of Web Ð the Semantic Web~\cite{semanticweb}. On the web, which is a highly open and distributed environment, the unique name assumption is very restrictive. The semantic web should allow definitions to be extended/specialised by any number of users. For example, the same person can be referred to in many different ways (i.e. with different URI references) depending on the referrer's focus or application (work-related, personal, image-related etc). OWL provides three constructs for stating facts about the identity of individuals. They are \textit{owl:sameAs}, which is used to state that two URI references refer to the same individual, \textit{owl:differentFrom} which is used to state that two URI references refer to different individuals, and \textit{owl:AllDifferent} which provides an idiom for stating that a list of individuals are all different. Unless an explicit statement is made that two URI references refer to the same or different individuals, OWL tools should assume either situation is possible.
552
553 For example, the fragment of ontology in Figure~\ref{UNA} tries to model that two individuals, \textit{Tom} and \textit{Jerry}, are the chefs for the \textit{aPizzaRestaurant}, which is an instance of the class \textit{PizzaRestaurant}. In a frames system, from the asserted facts, we knew that \textit{Tom} and \textit{Jerry} are two different \textit{chefs}. Therefore, we can conclude that \textit{aPizzaRestaurant} has exactly two different chefs. However in OWL we have to explicitly assert that \textit{Tom} and \textit{Jerry} are names for different instances. Without this \textit{allDifferentFrom} statement, we can only conclude that \textit{aPizzaRestaurant} has at least one chef and we cannot say \textit{aPizzaRestaurant} has at least two chefs, because \textit{Tom} and \textit{Jerry} could be two different names referring to the same person. Note that the ``at least'' is used here because that \textit{aPizzaRestaurant} could have some other unmentioned chefs. This is because of the Òopen world assumptionÓ which we will discuss in the next section.
554
555 \begin{figure}[!ht]
556 \center \fbox{ \small{ \parbox{4.0in}
557 {\begin{flushleft}\vspace{-0.3cm}
558 \textbf{\protegeframes:} \\
559 ...\\
560 ([\cn{aPizzaRestaurant\framesName}] of \cn{PizzaRestaurant\framesName} \\
561 ~~~~~(\cn{hasChef\framesName} \cn{[Tom\framesName]}\\
562 ~~~~~~~~~~~~~~~~~~~~~~~[\cn{Jerry\framesName}]) \\~\\
563 \textbf{OWL:} \\
564 ....\\
565 Individual(\cn{Tom}) \\
566 Individual(\cn{Jerry}) \\
567 AllDifferentFrom(Tom, Jerry)\\
568 Individual(\cn{aPizzaRestaurant} \\
569 ~~~type(\cn{PizzaRestaurant})\\
570 ~~~value(\cn{hasChef} \cn{Tom})\\
571 ~~~value(\cn{hasChef} \cn{Jerry}))
572
573 %\textbf{Paraphrase:} \\
574 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
575 %things}, both does \emph{not} have \emph{some} meat topping and
576 %also does \emph{not} have \emph{some} fish topping.
577 %\vspace{-0.15cm}
578 \end{flushleft}}}}
579 \caption{Unique Name Assumption example}
580 \label{UNA}
581 \end{figure}
582
583 \subsection{Open World vs. Closed World Assumption}
584 \label{openclose}
585 One of the biggest single difference between OWL and \protegeframes is frames systems use closed world reasoning with ``negation as failure'' -- i.e. if a fact is absent, it is assumed to be untrue. For example, as mentioned in the previous section, from the ontology defined in Figure~\ref{UNA}, we can conclude that \textit{aPizzaRestaurant} has \textbf{exactly} two different chefs. This is because there are no facts in our model that relate further chefs to our restaurant.
586
587 By contrast, OWL uses open world reasoning with ``negation as unsatisfiability'' Ð i.e. something is false only if it can be proved to contradict other information in the ontology.
588 In our OWL model, we can only conclude that \textit{aPizzaRestaurant} has \textbf{at least} two different chefs. This is because, according to the open world assumption, \textit{aPizzaRestaurant} could have some other chefs which have just not been asserted in the model. To draw the same conclusion as in \protegeframes, we have to ``close'' our description of \textit{aPizzaRestaurant} indicating that there are no other chefs working there -- this is commonly done by adding a ``close axiom'' (Figure~\ref{open1}).
589
590
591 \begin{figure}[!ht]
592 \center \fbox{ \small{ \parbox{4.0in}
593 {\begin{flushleft}\vspace{-0.3cm}
594 \textbf{OWL:} \\
595 ....\\
596 Individual(\cn{aPizzaRestaurant} \\
597 ~~~Type(\cn(PizzaRestaurant))\\
598 \textbf{~~~Type(restriction (hasChef allValuesFrom(oneof(\cn{Tom, Jerry}))))}\\
599 \textbf{~~~//A close axiom need to be explicitly asserted.}\\
600 ~~~value(\cn{hasChef} \cn{Tom})\\
601 ~~~value(\cn{hasChef} \cn{Jerry}))
602
603 %\textbf{Paraphrase:} \\
604 %
605 %\vspace{-0.15cm}
606 \end{flushleft}}}}
607 \caption{Closure of chefs on PizzaRestaurant}
608 \label{open1}
609 \end{figure}
610
611 {{I've cut most of this - its all in the common errors paper - I think we need to be comparing, not explaining}}
612
613 The open world assumption forms a big hurdle for \protegeframes ontologists' understanding at the class-level in OWL. The closed world is often implicit in our own understanding of a domain and this must be reflected in the models and applications built to support that domain. For example, most restaurant customers would understand from a menu that a \textit{FruitPizza} is a pizza that has apple and banana toppings (but nothing else -- at least without paying extra). This is simple to handle in frames {{can we have an example??}}, but much as our last example, modelling this in OWL requires additional axioms to ``close'' the descriptions of primitive pizzas, otherwise it's always possible to extend our pizzas by adding more toppings.
614 The final restriction shown in Figure~\ref{correctFruit}, and described fully in~\cite{commonError} is known as a ``closure restriction'' or ``closure axiom'' because it closes off the possibility of further additions for a given property.
615
616
617 \vspace{-0.6cm}\begin{figure}[!h] \center \fbox{
618 \small{ \parbox{4.0in}{\begin{flushleft} \vspace{-0.3cm}
619 \textbf{OWL:} \\
620 Class( \cn{FruitPizza} complete \\
621 ~~~\tx \cn{Pizza} \\
622 ~~~~~~\tx restriction (\cn{hasTopping} someValuesFrom \cn{Apple}) \\
623 ~~~~~~\tx restriction (\cn{hasTopping} someValuesFrom \cn{Banana})) \\
624 ~~~~~~\tx restriction (\cn{hasTopping} allValuesFrom (\cn{Apple} or \cn{Banana})))\\
625 \end{flushleft}}}}
626 \caption{Definition of Fruit pizza with closure restriction.}
627 \label{correctFruit}
628 \end{figure}
629
630 \subsection{Single Model vs. Multiple Models}
631
632
633 %{{I won't pretend to understand extension vs intension, but this terminology needs to be introduced}}
634 From a theoretical point of view, another big semantic difference between the \protegeframes and OWL is that how the model is defined for a knowledge base. \protegeframes makes the assumption that for one knowledge base there exists only one single model. When a new piece of knowledge is added to the knowledge base, the extension (the possible instantiations {{???}}) of the model are as small as possible. The empty knowledge base (no constraints) has a single empty model. An OWL knowledge base does not define a single model -- for a consistent OWL knowledge base, there is a set of possible models that could satisfy all constraints. The empty OWL knowledge base means any model is valid. The more constraints we add to the knowledge base, the fewer models are possible until too many constraints are added, the knowledge base becomes inconsistent and there is no possible model for it. Table~\ref{sumPara} summarizes the different characteristics of single model and multiple model knowledge bases.
635 % {{I don't understand the 2nd and 3rd rows in the table - are they the right way round?}}
636
637
638 \begin{table} \centering
639 \bigskip
640 \renewcommand{\baselinestretch}{1}\small\normalsize
641 \begin{tabular}{|l|l|p{3.7cm}| }
642 \hline
643 \bf{Multiple Model}
644 & \bf{Single Model} \\
645 \hline
646 Monotonic: & Non-Monotonic: \\
647 When new sentences are added to & The inference rules are non-sound; \\
648 the database, no existing inferences & when new sentences are added to the \\
649 need to be retracted. & database, earlier inferences may \\
650 & need to be retracted.\\
651 \hline
652 Can capture incomplete information. & Can't capture incomplete information.\\
653 \hline
654 More expressive and can support & Less expressive and cannot support \\
655 negation and disjunction. & negation and disjunction.\\
656 \hline
657 \end{tabular}
658 \renewcommand{\baselinestretch}{2}\small\normalsize
659 \vspace{0.1ex}
660 \caption{Comparison between single model and multiple model } \label{sumPara}
661 \end{table}
662
663
664
665 \section{Expressiveness Difference}
666
667
668 \subsection{\protegeframes Expressiveness - Advantages}
669
670
671 \subsubsection{Meta-modelling}\
672 Meta-level modelling is important for making statements about the ontology constructs themselves . Some existing frames ontologies (cite FMA paper) heavily rely on metaclasses which are not supported by OWL-DL.
673 %{{what is allowed? - Classes as instances, slots as instances etc}}.
674 The primary advantage of metamodelling in \protegeframes, and one of the fundamental design decisions behind the tool, is its ability to map alternative languages onto a frames-based system by subclassing the metaclasses (e.g. Class, Slot, Instance etc). This is the mechanism originally exploited by the ProtegeOWL support to build OWL on top of frames.
675 Because of the strengths of the form-building mechanisms in \protegeframes, frequently metaclasses are used to customise sets of forms for entry of groups of classes -- this is an important authoring feature as it simplifies model building. Arguably, this is a convenient side-effect of a much more powerful feature.
676
677 OWL FULL has complete meta-modeling features. However, use of the OWL FULL features means that one may lose the tractability OWL DL and OWL LITE guarantee and there are currently no reasoning systems for OWL FULL %{{can FoL provers be used for some of this??}}.
678 As having fully automatic-reasoning tools is the major advantage of logic-based formalisms, like OWL, over the frames language and OWL DL is the most widely used OWL flavor, the missed meta level modeling ability in OWL DL is still considered as a big expressive limitation~\footnote{OWL 1.1 will walk around the meta-modeling problem by allowing a name to be used for an individual, class and property. The computational problems are avoided by ensuring that no aspect of the use of the name as an individual has any effect on the meaning of the name as a class (This treatment is often called punning).} of OWL comparing with \protegeframes.
679
680
681 \subsubsection{Default Information and Exceptions}
682 Default reasoning has always been one of the great strengths of frames systems. Frames is designed around the notion of ``prototypes'' in which defaults are used to fill partial knowledge in our perceptions. For example, if we want to model that ``Most pizzas have a cheese topping'' in frames, we can add a default on the \textit{hasTopping} slot. So, unless we override this value specifically, our pizzas will have cheese on them. Any overrides are clearly exceptions to the rule -- this is a very useful notion when modelling safety critical facts, since the defaults can be used to provide a fail-safe value and only overridden when the safety of the exception is established. Many domains, such as Biology and Medicine, strongly rely on exceptions.
683
684 OWL, being a logic formalism, can only make statements of the form ``All pizzas have at least one cheese topping'' leaving no room for exceptions. Currently, there are some attempts to use design patterns to represent default information in OWL [cite alan default paper]. However, the proposed approaches are far from perfect and impractical in all but the simplest cases. Default reasoning remains one of the key strengths of \protegeframes over OWL.
685
686
687 \subsubsection{Concrete Domains and User Defined Datatypes}
688 {{Below needs more talk about frames}}
689 \protegeframes supports several primitive data types Ð numbers, strings, symbols and so on Ð and user defined constraints on them. {{Can they be used in queries etc??}}
690
691 One of the omissions in the current OWL language that prevents many potential users from adopting OWL is poor representation of numeric expressions in order to be able to express quantitative information. Examples in our domain could include the lengths between 9in and 12in or mass in the range of 100-500g. Such range declarations are needed to classify individuals and to build class definitions such as ``LargePizza'', and should therefore be supported by reasoners. Issues preventing this support from being in the current version of OWL include how to refer to an XML schema user defined datatype with a URI and the denotational semantics of the XML data type etc (\cite{ jeffÕs thesis}). However, these are being resolved and OWL 1.1 will support user-defined datatypes.
692
693
694 \subsection{OWL Expressiveness - Advantages}
695
696
697 \subsubsection{Defined Classes}
698 As discussed in section~\ref{definedClass}, OWL allows us to `define' classes, allowing inferred subclass and type information to be calculated.
699 {{How would we think of doing this in Frames?}}
700
701
702 \subsubsection{Embedding Class Definition}
703 OWL allows complex expressions to be built up without having to name each intermediate concept before use. This embedding of `anonymous concepts' allows more expressive representations to be built easily and naturally. To some extents, the embedding of concepts in expressions can be considered as a special case of definition. This can result in a dramatic reduction in the number of facts that have to be maintained explicitly. For example, we can define a \textit{FattyPizza} as \textit{(Pizza and (hasIngredient (FoodStuff and (hasFatContent some HighFat))))} without having to create a notion of \textit{HighFatIngredients}.
704 %{{The below example needs to be in the Pizza domain - what are we trying to say? That we don't wish to enumerate every combination I guess, but we don't say that. Also, its not clear how this relates to the above}}
705 For example, in defining an ontology of burns, we might consider the notion that burns can have any surface anatomic location (of which there might be, say, 300), three degrees of penetration, three categories of size, and two causations (heat and chemical). That is a total of at most a dozen new facts to maintain about burns. However, the total number of types of burns that can be defined from those dozen facts is 300*4*4*3 = 14,400. How many of those types are relevant to any application? How much effort is required to keep such a large number of types correctly classified by hand?
706
707 \protegeframes does not have a notion of anonymous classes.
708 %{{Again, what needs to be done in frames to roughly simulate this??}}
709
710
711 \subsubsection{Power Qualification on the Fillers}
712 OWL allows several kinds of quantification of properties and the meaning of each of these quantifications is precisely defined. The filler of most restrictions can be any OWL class expression and the OWL restriction itself is a kind of class expression as well. Currently OWL supports the following kinds of restrictions.
713 \begin{itemize}
714 \item Existential restriction (\textit{owl:SomeValuesFrom}), which specifies the existence of a (i.e. at least one) relationship along a given property to an individual that is a member of a specific class.
715 \item Universal restriction (\textit{owl:AllValuesFrom}), which constrains the relationship along a given property to individuals that are members of a specific class.
716 \item HasValue restriction (\textit{owl:hasValue}), which specifies the existence of a relationship along a given property to a specific individual.
717 \item Cardinality restrictions (\textit{owl:maxCardinality, owl:minCardinality, owl:cardinality}), which are used to talk about the number of relationships that an individual may participate in for a given property.
718 \end{itemize}
719
720 In addition, OWL 1.1 will support \textit{qualified cardinality restrictions (QCRs)} which allow us to restrict the number of values of a particular type, e.g. a \textit{Pizza} must have at least two \textit{MeatToppings}, and local reflexivity restrictions (i.e. everything in the domain bears the relation to itself) which allows constructs like restriction (like self).
721 In \protegeframes, the effect of universal, hasValue and cardinality restrictions can be approximately modeled using frames facets. However the semantics of slot-facets are often unclean. ProtŽgŽ-frames cannot model existential restrictions (which is probably the most common) or QCRs. This is a significant gap in expressive power, which leads to many modelling difficulties (cite, NatashaÕs envelop paper).
722
723
724 \subsubsection{Set Combination on Classes }
725 OWL allows users to apply the standard set operators (Intersection, Union and Complement) on class descriptions. With the combination of the OWL class axioms, like equivalent class, we can model statements like covering, disjointness etc. For example, we can represent the fact that there are no other \textit{PizzaBases} other than \textit{ThinAndCrispy} or \textit{DeepPan} as: $PizzaBase \equiv ThinAndCrispy \bigcup DeepPan$. %{{Frames???}}
726
727
728 \subsubsection{Equivalence and Disjointness}
729 In \protegeframes, by default, two classes are considered to be disjoint if they do not have any common sub class {{I assume Top is OK??}} but there is no way to explicitly assert two classes are indeed disjoint. For example, in \protegeframes, there is no way to prevent \textit{PizzaTopping} and \textit{PizzaBase} overlapping {{Hang on, we said the opposite before!!}}. In OWL, such information can be asserted by using the \textit{owl:disjointWith} construct. Asserting these classes disjoint in OWL means it will be inconsistent to have a subclass of both. Similarly, OWL can explicitly assert that two class descriptions have the same class extension (instances) with the constructor owl:equivalentClass. OWL 1.1 will allow us to say two properties are disjoint as well.
730
731
732 \subsubsection{Characters of Properties }
733 \protegeframes allows uses to say that a slot is \textit{functional} (by setting the maximum cardinality to be one) or \textit{symmetric} (by setting the invert slot to be itself). In OWL, apart from \textit{functional} and \textit{symmetric}, the properties can be set as \textit{transitive} as well. OWL 1.1 will include \textit{reflexive}, \textit{irreflexive}, and \textit{anti-symmetric} properties.
734 So the statement like ``A is part of B, B is part of C, then A is part of C as well'' which could not be modeled in \protegeframes could be model in OWL. The transitive property is important for some application domain like anatomy and geography.
735
736
737 \section{Tools support}
738
739
740 For both \protegeframes and OWL, there are many different tools to assist with various users' tasks, like ontology visualizing, comparing, documenting, publishing etc. However due to the different nature of two languages, each of them has their own distinct supporting tools. In this section, we introduce the most important and unique tools for the two languages.
741
742
743 \subsection{OWL reasoner}
744 \label{reasoner}
745 As we have discussed, one of the most important distinguishing features of logic based ontology languages like OWL from other ontology formalisms is that it has formal semantics. Staying within OWL-DL, allows us to build reasoners which can make automatic inferences over our knowledge base. Reasoners can be used at development time to help users to build and manage their ontologies more easily.
746 We believe that building large, reusable ontologies with rich multiple inheritance by manual effort unaided by formal checks is virtually impossible. This is doubly so in any collaborative environment where work from several authors must be reconciled and integrated. However, many of our users develop draft versions of ontologies without benefit of classifiers to which we propose ``enrichments'' with the help of classifiers and then return to the original authors for checking. At the end of the development process, we deliver most of the ontologies we build to applications in forms that do not require the applications to have classifiers or even know that classifiers have been used. In general, the use of OWL reasoners includes but is not limited to the following:
747
748
749 \subsubsection{Diagnosis}
750 An OWL ontology is an engineered artifact which may inevitably contain flaws which may include:
751 \begin{itemize}
752 \item Logical inconsistency. We have seen examples of classes that have been found inconsistent {{REF}}. Normally, this is because that the knowledge model has been over constrained and contains contradicting facts. If we're lucky, these contradictions might be locally defined for that class, but often they are propagated over other inconsistent classes. Manually discovering the logic inconsistence is an impossible mission for a large and complex ontology.
753 \item Unexpected inference. Since the inference in OWL is based on the assumption that the knowledge base in incomplete, there can often be unexpected inferences caused by missing information.
754 \item Unexpected type coercion for individuals. Apart from its asserted type, we can infer if individuals have any additional inferred types.
755 \end{itemize}
756
757 Using OWL reasoners directly the first kind of flaws can be automatically and efficiently identified. With tool support and additional interaction from users, the causes of the last two flaws can normally be discovered as well.
758
759
760 \subsubsection{Composition}
761 OWL allows us to build more complex concepts out of simpler concepts -- it is sometimes referred to as ``Conceptual Lego''. The fundamental advantage of using classifiers is that they allow composition Ð i.e. they allow new concepts to be defined systematically from existing concepts. This can result in a dramatic reduction in the number of facts that have to be maintained explicitly.
762
763
764 \subsubsection{Normalisation and Managing Polyhierarchies}
765 Managing and maintaining a complex polyhierarchy of concepts is hard. Changes often need to be made in several different places, and keeping everything in step is error prone and laborious. Using a classifier, we have developed a mechanism for `normalisation' of ontologies {{REF normalisation paper}}. In normalised ontologies, even the most complex polyhierarchies are built out of simple non-overlapping trees. In the pizza domain {{...}}. Concepts bridging the trees are created by definitions. The relationships amongst defined concepts are maintained by the classifier. Changes are always made in exactly one place. If we need to change the anatomy, or add the possibility of ultra$\-$violet light as a cause, we do it just once, not for some large and difficult to identify fraction of 14,400 potential concepts~\cite{??}.
766 {{Need to completely change the example above to pizzas}}
767
768
769 \subsubsection{Pre- and Post- Coordination and the Ontology Life Cycle}
770 Querying a knowledge base is one of the fundamental tasks needed in an ontology-driven application. Depending on the type of ontology and the type of queries that need to be asked, we can determine whether the reasoner is needed at run-time, or if it can be simply used at ``publish'' time.
771 Many applications need an ontology primarily as a fixed vocabulary with fixed relations. They do not expect to define new concepts in terms of existing concepts ``on the fly'' at run time. What is required at run time is a ``pre-coordinated'' ontology in which all concepts needed and the relations between them are explicitly pre-defined. That the pre-coordinated ontology was, or was not, derived through normalisation and classification is irrelevant at run time. What is required is a hierarchy (or polyhierarchy) of concepts to ``fill the boxes'' in the information or decision support model. In this case the life cycle of the ontology is that it is authored, maintained and demonstrated correct in OWL with the help of the classifier, but then ``published'' as a pre-coordinated form Ð in RDF(S), OWL-Lite, CLIPS, or some proprietary form.
772 On the other hand, some applications require more concepts than can be conveniently enumerated. Indeed the number of concepts that can be defined from the elements of an ontology may be indefinitely large or even demonstrably infinite. If it cannot be predicted in advance which concepts are needed, then the classifier is needed at run time to create and classify the concepts found. In the example of burns above, it might well be worth the trouble to have a classifier if it meant that the user could see on the order of 15000 potential concepts but the system to be maintained needed to deal with only a dozen or so facts. The PEN$\&$PAD clinical data entry system developed in Manchester used post-coordination to allow very large potential terminology to be maintained simply and tailored quickly to special needs. Discussion of how to use SNOMED-CT in similar ways is currently under way. {{Again, we need to avoid talking about medicine}}
773
774 \subsection{\protegeframes tools .Form tab? others?}
775 To be discussed.
776
777 \section{Modelling practice}
778 To be discussed.
779 \subsection{\protegeframes}
780 \subsection{OWL}
781
782 Conceptual lego. limited primitives, but allow arbitrary boolean combination and defining.
783 ÒAll OWL ontologies I know of are built a combination of top down, middle out, and occasionally bottom upÓ from alanÕs slide
784
785
786 \section{\protegeframes or OWL? Guidelines}
787 {{State something about the purpose of each}} OWL is a Semantic Web language and is designed with open world semantics that easily allow under-specification for extensibility by multiple domains. \protegeframes is designed as a constraint language and is heavily focused on helping generate strictly controlled data sets. Although both can be thought of as ``Schema languages'', OWL's strengths are at the class-level description of a domain, whereas frames, being closed world is more suited to instance-level. It seems reasonable that a combination of both paradigms may be useful for different aspects of a given application. This leads to questions about the development and use of an ontology and which paradigm might be suited to which parts of its lifecycle. {{This is probably not worded very well}}
788
789 \section{Conclusion}
790
791 \subsection*{Acknowledgements.}
792
793
794
795 \bibliographystyle{plain} % for [n] style bibliography
796 \bibliography{muall}
797
798
799 %\input{ozintr}
800
801
802
803
804
805 \end{document}

protege-admin@lists.stanford.edu
ViewVC Help
Powered by ViewVC 1.1.26