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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 2503 - (show annotations) (download) (as text)
Tue Jul 4 13:04:38 2006 UTC (12 years, 5 months ago) by tredmond
File MIME type: text/x-latex
File size: 20590 byte(s)
Some cleanup.

1
2
3 The following represents some of the major differences between
4 \protegeframes\ and \owl:
5 \begin{description}
6 \item[Unique name assumption]
7 In \protegeframes, if two objects have different names, they are
8 assumed to be different, unless stated otherwise. In OWL, objects
9 are assumed to be the same, unless explicitly stated otherwise.
10 \item[Open World Assumption vs Closed World Assumption]
11 In \protegeframes, everything is prohibited until it is permitted;
12 in \owl, everything is permitted until it is prohibited. Nothing
13 can be entered into a \protege\ KB until there is
14 a place for it in the corresponding template. Anything can be
15 entered into an OWL KB unless it violates one of the constraints.
16 \item[Classification vs. Assertion]
17 One of the major advantages of \owl\ over \protegeframes\ is that
18 the \owl\ language allows for the definition of in terms of
19 properties and other classes. This is a very powerful capability.
20 Among the benefits is the possibility that a user can be relieved of
21 the burden of determining the class hierarchy as the \owl\ reasoner
22 can do this work.
23 \end{description}
24
25 \subsubsection{Unique Name Assumption (UNA) }
26
27 \protegeframes, like many other languages, has a so-called ``unique
28 names'' assumption, i.e. different names refer to different things
29 However, in OWL such an
30 assumption is invalid, i.e. different names (URI references) could
31 refer to the same thing. This is because OWL has been designed with
32 distribution and reusability in mind - features critical in realising
33 the next generation of Web, the Semantic
34 Web~\cite{semanticweb}. On the web, which is a highly open and
35 distributed environment, the unique name assumption is very
36 restrictive. The semantic web should allow definitions to be
37 extended/specialised by any number of users. For example, the same
38 person can be referred to in many different ways (i.e. with different
39 URI references) depending on the referrer's focus or application
40 (work-related, personal, image-related etc). Unless an
41 explicit statement is made that two URI references refer to the same
42 or different individuals, OWL tools should assume either situation is
43 possible.
44
45 For example, the fragment of ontology in Figure~\ref{UNA} tries to
46 model that two individuals, \textit{Tom} and \textit{Jerry}, are the
47 chefs for the \textit{aPizzaRestaurant}, which is an instance of the
48 class \textit{PizzaRestaurant}. In a frames system, from the asserted
49 facts, we knew that \textit{Tom} and \textit{Jerry} are two different
50 \textit{chefs}. Therefore, we can conclude that
51 \textit{aPizzaRestaurant} has exactly two different chefs. However in
52 OWL we have to explicitly assert that \textit{Tom} and \textit{Jerry}
53 are names for different instances. Without this
54 \textit{allDifferentFrom} statement, we can only conclude that
55 \textit{aPizzaRestaurant} has at least one chef and we cannot say
56 \textit{aPizzaRestaurant} has at least two chefs, because \textit{Tom}
57 and \textit{Jerry} could be two different names referring to the same
58 person. Note that the ``at least'' is used here because that
59 \textit{aPizzaRestaurant} could have some other unmentioned
60 chefs. This is because of the open world
61 assumption which we discussed above.
62
63 \begin{figure}[!ht]
64 \center \fbox{ \small{ \parbox{4.0in}
65 {\begin{flushleft}\vspace{-0.3cm}
66 \textbf{\protegeframes:} \\
67 ...\\
68 ([\cn{aPizzaRestaurant\framesName}] of \cn{PizzaRestaurant\framesName} \\
69 ~~~~~(\cn{hasChef\framesName} \cn{[Tom\framesName]}\\
70 ~~~~~~~~~~~~~~~~~~~~~~~[\cn{Jerry\framesName}]) \\~\\
71 \textbf{OWL:} \\
72 ....\\
73 Individual(\cn{Tom}) \\
74 Individual(\cn{Jerry}) \\
75 AllDifferentFrom(Tom, Jerry)\\
76 Individual(\cn{aPizzaRestaurant} \\
77 ~~~type(\cn{PizzaRestaurant})\\
78 ~~~value(\cn{hasChef} \cn{Tom})\\
79 ~~~value(\cn{hasChef} \cn{Jerry}))
80
81 %\textbf{Paraphrase:} \\
82 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
83 %things}, both does \emph{not} have \emph{some} meat topping and
84 %also does \emph{not} have \emph{some} fish topping.
85 %\vspace{-0.15cm}
86 \end{flushleft}}}}
87 \caption{Unique Name Assumption example}
88 \label{UNA}
89 \end{figure}
90
91
92 \subsubsection{Open World vs. Closed World Assumption}
93 \label{openclose}
94
95 One of the biggest single difference between OWL and \protegeframes\
96 is frames systems use closed world reasoning with ``negation as
97 failure'' -- i.e. if a fact is absent, it is assumed to be untrue. For
98 example, as mentioned in the previous section, from the ontology
99 defined in Figure~\ref{UNA}, we can conclude that
100 \textit{aPizzaRestaurant} has \textbf{exactly} two different
101 chefs. This is because there are no facts in our model that relate
102 further chefs to our restaurant.
103
104 By contrast, OWL uses open world reasoning with ``negation as
105 unsatisfiability'' i.e. something is false only if it can
106 be proved to contradict other information in the ontology. In our OWL
107 model, we can only conclude that \textit{aPizzaRestaurant} has
108 \textbf{at least} two different chefs. This is because, according to
109 the open world assumption, \textit{aPizzaRestaurant} could have some
110 other chefs which have just not been asserted in the model. To draw
111 the same conclusion as in \protegeframes, we have to ``close'' our
112 description of \textit{aPizzaRestaurant} indicating that there are no
113 other chefs working there -- this is commonly done by adding a ``close
114 axiom'' (Figure~\ref{open1}).
115
116
117 \begin{figure}[!ht]
118 \center \fbox{ \small{ \parbox{4.0in}
119 {\begin{flushleft}\vspace{-0.3cm}
120 \textbf{OWL:} \\
121 ....\\
122 Individual(\cn{aPizzaRestaurant} \\
123 ~~~Type(\cn(PizzaRestaurant))\\
124 \textbf{~~~Type(restriction (hasChef allValuesFrom(oneof(\cn{Tom, Jerry}))))}\\
125 \textbf{~~~//A close axiom need to be explicitly asserted.}\\
126 ~~~value(\cn{hasChef} \cn{Tom})\\
127 ~~~value(\cn{hasChef} \cn{Jerry}))
128
129 %\textbf{Paraphrase:} \\
130 %
131 %\vspace{-0.15cm}
132 \end{flushleft}}}}
133 \caption{Closure of chefs on PizzaRestaurant}
134 \label{open1}
135 \end{figure}
136
137 The open world assumption forms a big hurdle for many users
138 understanding at the class-level in OWL. The closed world
139 is often implicit in our own understanding of a domain and this must
140 be reflected in the models and applications built to support that
141 domain. For example, most restaurant customers would understand from a
142 menu that a \textit{FruitPizza} is a pizza that has apple and banana
143 toppings (but nothing else -- at least without paying extra). This is
144 simple to handle in frames, but much as
145 our last example, modelling this in OWL requires additional axioms to
146 ``close'' the descriptions of primitive pizzas, otherwise it's always
147 possible to extend our pizzas by adding more toppings. The final
148 restriction shown in Figure~\ref{correctFruit}, and described fully
149 in~\cite{commonError} is known as a ``closure restriction'' or
150 ``closure axiom'' because it closes off the possibility of further
151 additions for a given property.
152
153
154 \vspace{-0.6cm}\begin{figure}[!h] \center \fbox{
155 \small{ \parbox{4.0in}{\begin{flushleft} \vspace{-0.3cm}
156 \textbf{\protegeframes:} \\
157 (defclass \cn{FruitPizza} \\
158 ~~~(is-a \cn{Pizza}) \\
159 ~~~(multislot hasTopping \\
160 ~~~~~~(type INSTANCE) \\
161 ~~~~~~(allowed-classes \cn{Apple} \cn{Banana})) \\
162 \textbf{OWL:} \\
163 Class( \cn{FruitPizza} complete \\
164 ~~~\tx \cn{Pizza} \\
165 ~~~~~~\tx restriction (\cn{hasTopping} someValuesFrom \cn{Apple}) \\
166 ~~~~~~\tx restriction (\cn{hasTopping} someValuesFrom \cn{Banana})) \\
167 ~~~~~~\tx restriction (\cn{hasTopping} allValuesFrom (\cn{Apple} or \cn{Banana})))\\
168 \end{flushleft}}}}
169 \caption{Definition of Fruit pizza with closure restriction.}
170 \label{correctFruit}
171 \end{figure}
172
173 As a result of the open and closed world assumption, \protegeframes\
174 and \owl\ have different handling for
175 \begin{itemize}
176 \item disjoint vs. overlapping classes,
177 \item association of slots/properties to classes and
178 \item association of slots/properties to individuals.
179 \end{itemize}
180
181 \paragraph{Disjoint vs. Overlapping Classes}
182
183 In frames systems, two classes are assumed to be ``disjoint'' unless
184 there is an assertion that there is a common individual or a common
185 subclass. This is an example of ``negation by failure'' because
186 until the common element of two classes is asserted, they are disjoint.
187 In contrast, OWL allows for the possibility that classes overlap
188 unless there is some assertion to the contrary.
189
190 To demonstrate the difference,
191 Figure~\ref{classDisjoint} shows a small fragment of ontology in both
192 formats. Three classes -- \textit{PizzaTopping}, \textit{PizzaBase},
193 \textit{Pizza} and one slot /property \textit{hasTopping} have been
194 created. The value of \textit{hasTopping} must come from the class
195 \textit{PizzaTopping}. An instance of the class \textit{Pizza},
196 \textit{aPizza}, is related to another instance \textit{aPizzaBase},
197 which is an instance of the class \textit{PizzaBase}, by the property
198 \textit{hasTopping}. In frames systems, this would be treated as an
199 error, as \textit{PizzaBase} and \textit{PizzaTopping} are
200 disjoint. In OWL, we have to explicitly assert that
201 \textit{PizzaTopping} and \textit{PizzaBase} are disjoint. Without
202 this disjoint axiom, \textit{aPizza} would be a consistent individual,
203 as it is possible for \textit{PizzaTopping} and \textit{PizzaBase}
204 class to have some shared instances, like \textit{aPizza}.
205
206 \begin{figure}[!ht]
207 \center \fbox{ \small{ \parbox{4.0in}
208 {\begin{flushleft}\vspace{-0.3cm}
209 \textbf{\protegeframes:} \\
210 (defclass \cn{PizzaTopping\framesName}) \\
211 (defclass \cn{PizzaBase\framesName}) \\
212 (defclass \cn{Pizza\framesName} \\
213 ~~~(multislot hasTopping\framesName \\
214 ~~~~~~~~~~ ....\\
215 ~~~~~~~~~~(allowed-class \cn{PizzaTopping\framesName}
216 ) \\
217 ([\cn{aPizzaBase\framesName}] of \cn{PizzaBase\framesName}) \\
218 ([\cn{aPizza\framesName}] of \cn{Pizza\framesName}\\
219 ~~~~~(\cn{hasTopping} \cn{aPizzaBase\framesName}) \\~\\
220 \textbf{OWL:} \\
221 Class(\cn{PizzaTopping })
222 Class(\cn{PizzaBase} )\\
223 \textbf{disjointWith(\cn{PizzaTopping }, \cn{PizzaBase })}\\
224 \textbf{// This disjointness statement needs to be explicitly asserted. }\\
225 Class (\cn{Pizza } partial \\
226 ~~~~~~ restriction \cn{hasTopping} allValuesFrom \cn{PizzaTopping})\\
227 Individual(\cn{aPizzaBase} Type(\cn{PizzaBase}))\\
228 Individual(\cn{aPizza} \\
229 ~~~Type(\cn{Pizza})\\
230 ~~~value(\cn{hasTopping} \cn{aPizzaBase}))
231
232 %\textbf{Paraphrase:} \\
233 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
234 %things}, both does \emph{not} have \emph{some} meat topping and
235 %also does \emph{not} have \emph{some} fish topping.
236 %\vspace{-0.15cm}
237 \end{flushleft}}}}
238 \caption{Class disjointness example}
239 \label{classDisjoint}
240 \end{figure}
241
242
243 \paragraph{Association of Slots/Properties to Classes}
244
245 In \protegeframes, a (template) slot is only associated with a class
246 if the slot has been explicitly added to the class or one of its
247 parents. Otherwise the domain of the slot is assumed to be disjoint
248 from the class. In \owl\ a property can be associated with a class unless
249 there is an explicit assertion to the contrary.
250
251 To illustrate the difference, the class \textit{VegetarianPizza} has
252 been defined in both \protegeframes and OWL
253 (Figure~\ref{modelconcept})\footnote{In this paper, The word
254 ``\framesName'' is appended to all the entities defined in
255 \protegeframes system to distinguish those corresponding elements
256 defined in OWL {{I think we scrub this - it doesn't help and the text
257 doesn't match this anyway}}. }. The two definitions try to express
258 the same fact, that is \textit{VegetarianPizza} is a pizza which can
259 only have vegetable toppings, using the different languages. They
260 maybe look similar from the abstract syntax representation however,
261 underneath, the modelling process is quite different. In
262 \protegeframes, it requires two modeling steps for this task. The slot
263 \textit{hasTopping} has to be explicitly associated to the class
264 first, then we can add the constraint facet to the associated
265 slot. Contrastingly, in OWL, the restriction can be added to the class
266 directly.
267
268 This is because in \protegeframes, a class is assumed to
269 have no slots associated with it unless they have been explicitly
270 added to it or its parents. In OWL, we can add restrictions to a class
271 on any property\footnote{Adding restrictions to an OWL class can cause
272 bring unexpected effects - this will be discussed in
273 section~\ref{domainRange}. } directly because of the Open World
274 Assumption (Section~\ref{openclose}).
275
276 \begin{figure}[!ht]
277 \center \fbox{ \small{ \parbox{4.0in}
278 {\begin{flushleft}\vspace{-0.3cm}
279 \textbf{\protegeframes :} \\
280 (defclass \cn{VegetarianPizza\framesName} \\
281 ~~~(IS-A \cn{Pizza\framesName}\\
282 ~~~(multislot hasTopping\framesName ~~~~ \textbf{//step one: attach the slot to the class} \\
283 ~~~(allowed-class Vegetable\framesName)) \textbf{ //step two: add the constraint} \\~~
284 \\
285 \textbf{OWL:} \\
286 Class (\cn{VegetarianPizza} complete \\
287 ~~~\tx \cn{Pizza} \\
288 ~~~\tx restriction (\cn{hasTopping} allValuesFrom \cn{Vegetable}))\\
289 %\textbf{Paraphrase:} \\
290 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
291 %things}, both does \emph{not} have \emph{some} meat topping and
292 %also does \emph{not} have \emph{some} fish topping.
293 %\vspace{-0.15cm}
294 \end{flushleft}}}}
295 \caption{Model a concept in \protegeframes and OWL {{Would Pizza -> hasBase only PizzaBase be a better example?}} }
296 \label{modelconcept}
297 \end{figure}
298
299
300 \paragraph{Association Slot/Property Semantics to Individuals}
301
302
303 In \protegeframes, a slot is only associated with an instance if the
304 slot has been explicitly added a class containing the instance or one
305 of its parents. Otherwise the domain of the slot is assumed to not
306 include the instance. In \owl\ a property can be associated with a
307 class unless there is an explicit assertion to the contrary.
308
309 For example, in \protegeframes, we can not add any values to
310 a direct instance of \textit{:Thing}. Normally the deeper a class is
311 located in the class hierarchy, the more we could say about its
312 instances. OWL behaves in the opposite way. An OWL individual can have a
313 relationship along any property unless it has been asserted that it
314 can't. We could say anything about an instance of
315 \textit{OWL:Thing}. The deeper a class is located in the class
316 hierarchy, the less we can say about its instances.
317
318 Continuing with the example we defined in
319 Figure~\ref{modelconcept}, we define an instance of the class
320 \textit{VegetarianPizza} in both \protegeframes and OWL and use a
321 slot/property, \textit{hasFatness}. In \protegeframes, we are
322 prevented from adding values for the slot \textit{hasFatness} to
323 \textit{aVegetarianPizza}, as the slot \textit{hasFatness} is not
324 associated with the class \textit{VegetarianPizza}. However, in OWL
325 this is perfectly legal (~Figure~\ref{relatedindividuals}). It will be
326 an error (inconsistent) only if it is asserted or inferred that the
327 class \textit{VegetarianPizza} cannot have any values for the property
328 \textit{hasFatness}, e.g. it is disjoint with the domain of the
329 property \textit{hasFatness}.
330
331 \begin{figure}[!ht]
332 \center \fbox{ \small{ \parbox{4.0in}
333 {\begin{flushleft}\vspace{-0.3cm}
334 \textbf{\protegeframes:} \\
335 ([\cn{aVegetarianPizza\framesName} of \cn{VegetarianPizza\framesName} \\
336 ~~~(\cn{hasFatness\framesName} ...) ~~~~ \textbf{// It is an error in \protegeframes.} \\
337 )\\~~
338 \\
339 \textbf{OWL:} \\
340 Individual(\cn{aVegetarianPizza}\\
341 ~~~~~\tx type(\cn{VegetarianPizza})\\
342 ~~~~~\tx value (\cn{hasFatness} ....))
343 %\textbf{Paraphrase:} \\
344 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
345 %things}, both does \emph{not} have \emph{some} meat topping and
346 %also does \emph{not} have \emph{some} fish topping.
347 %\vspace{-0.15cm}
348 \end{flushleft}}}}
349 \caption{Relate individuals in \protegeframes and OWL }
350 \label{relatedindividuals}
351 \end{figure}
352
353
354 \subsection{Classification vs. Assertion}
355 \label{definedClass}
356
357 One of the major advantages of OWL is that it supports both
358 ``primitive'' and ``defined'' classes, which can be used for reasoning
359 in OWL-DL ontologies. New concepts can be built up from existing
360 concepts by fitting them together in definitions like blocks of
361 Lego. More formally, OWL allows concepts to be defined by sets of
362 necessary and sufficient conditions. We refer to classes for which
363 there are only necessary conditions -- marked by the keyword
364 ``partial
365 \footnote{
366 OWL descriptions are sometimes known as partial definitions and the
367 keyword ``partial'', appears in OWL syntax and in OilEd. This usage
368 is seriously misleading and the term `partial definition' a
369 misnomer. Many of the restrictions on primitive, or indeed defined,
370 classes are necessary implications and take no part in any set of
371 necessary and sufficient conditions - i.e. in definitions
372 ``partial'' or otherwise.}''
373 in the abstract syntax -- as ``primitive'' classes{{, harking back to
374 an older terminology - delete?}}. Classes for which there is at
375 least one set of necessary and sufficient conditions -- marked in the
376 abstract syntax by the keyword ``complete'' -- are referred to as
377 ``defined''.
378 In contrast, in \protegeframes, all subclass relations and
379 instantiation relations must be asserted, but in OWL this information
380 can be either asserted directly or inferred.
381
382 \begin{figure}[!ht]
383 \center \fbox{ \small{ \parbox{4.0in}
384 {\begin{flushleft}\vspace{-0.3cm}
385 \textbf{\protegeframes:} \\
386 (defclass \cn{VegetarianPizza\framesName} \\
387 ~~~(multislot hasTopping\framesName \\
388 ~~~(allowed-class Vegetable\framesName)) \\
389 (defclass \cn{MushroomPizza\framesName} \\
390 ~~~\textbf{(IS-A \cn{VegetarianPizza\framesName}) ~~~~~ // It has to be explicitly asserted!}
391 ~~~(multislot hasTopping\framesName \\
392 ~~~(allowed-class Mushroom\framesName)) \\
393 \textbf{OWL:} \\
394 Class (\cn{VegetarianPizza} \textbf{COMPLETE \\
395 ~~~~ // the keyword changes to ''COMPLETE''}\\
396 ~~~\cn{Pizza} \\
397 ~~~~~~ (restriction \cn{hasTopping} allValuesFrom \cn{Vegetable}))\\
398 Class (\cn{MushroomPizza} partial\\
399 ~~~ \cn{Pizza} \\
400 ~~~~~~ restriction (\cn{hasTopping} allValuesFrom \cn{Mushroom}))\\
401 %\textbf{Paraphrase:} \\
402 %A vegetarian pizza is \emph{any} pizza that, \emph{amongst other
403 %things}, both does \emph{not} have \emph{some} meat topping and
404 %also does \emph{not} have \emph{some} fish topping.
405 %\vspace{-0.15cm}
406 \end{flushleft}}}}
407 \caption{Asserted and inferred IS-A relations }
408 \label{is-a}
409 \end{figure}
410
411 For example, previously we stated that a \textit{VegetarianPizza} must only have
412 toppings that are \textit{Vegetables}
413 (Figure~\ref{modelconcept}). Coming from the other direction, suppose
414 that we want to model the fact that any pizza that only has vegetables
415 as its topping must be a \textit{VegetarianPizza}. Furthermore, we
416 also define a special kind of \textit{VegetarianPizza} --
417 \textit{MushroomPizza}, which can only have \textit{Mushrooms} as its
418 toppings. The frames definition of \textit{VegetarianPizza} is
419 unchanged as \protegeframes does not allow us to defined a class. In
420 fact, we have to explicitly assert that \textit{MushroomsPizza} is a
421 subclass of \textit{VegetarianPizza}. In OWL we can create the
422 \textit{MushroomsPizza} with this more constrained restriction and
423 change the \textit{VegetarianPizza} class from primitive to
424 defined -- note the keyword has been changed to complete
425 (Figure~\ref{is-a}). The IS-A relationship will be inferred
426 automatically by reasoners.
427
428 The ability to define classes in OWL brings a number of important
429 advantages. For example, it can be used as a mechanism for
430 normalising ontologies \ref{alanNormal}. More detail about
431 normalizing ontologies will be discussed when we compare the different
432 supporting tools for \protegeframes\ and \owl\ in section~\ref{reasoner}.
433
434 Although ``defined'' classes bring many advantages, understanding the
435 difference between ``primitive'' and ``defined'' classes in OWL is one
436 of the major stumbling blocks experienced by frames ontologists. In
437 our experience, the most common accidental error made by frames
438 ontologists in implementing OWL ontologies is to fail to make a set of
439 restrictions a definition. In our \protegeowl interface, sets of
440 necessary and sufficientÓ conditions appear in the same widget as
441 the set of necessary conditions, so that both sets are simultaneously
442 visible.
443
444 It is critical to understand that, in general, the reasoner will not
445 classify anything underneath a primitive concept. In the OWL example
446 in (Figure~\ref{is-a}), if ``partial'' isn't replaced by ``complete'',
447 no IS-A relation will be inferred between \textit{MushroomsPizza} and
448 \textit{VegetarianPizza}. The first thing, therefore, to look for when
449 things fail to be classified under a concept, is whether it has been
450 defined.
451
452
453
454 %===========================================================
455 \nocite{flogic}

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