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

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}