Review of Primer

Hello,
  Please find below my review of the OWL2 Primer.
  Comments preceded by '*' indicate some question or comment, otherwise
I suggest replacement text.

Cheers,

-=Michel=-


Review of the OWL 2 Primer (WD 21/04/09)
---------------------------------------
1.
* "the buttons below can be used to show or hide all four syntaxes" ->
five syntaxes
* the syntax buttons aren't immediately linked to syntax examples, so a
user wouldn't understand the differences between them and wouldn't
choose between any of them at this point. On first exposure (4 -
classes, instances), unclear which syntax each box refers to, but the
user would have to scroll up to hide the syntax, go check which was
changed, etc.

2. closed-world vs open-world assumptions -> pointers?

"elements used to refer to the real-world objects that are modelled"
-> "elements used to refer to the real-world objects"

"The modelling artefacts created in OWL are called ontologies - a
terminology that also helps to avoid confusion since the term "model" is
often used in a rather different sense in knowledge representation." 
- new jargon "modelling artefacts", "model" are not sufficiently
described, and the purpose of the sentence is therefore unclear.  It
might be useful to briefly digress and describe what modeling is and the
challenges that one faces while attempting to accurately represent
knowledge

* "every OWL 2 ontology is - from an abstract viewpoint - essentially
just a collection of axioms."
- remove the unnecessary "from an abstract viewpoint"

* I agree that the algebraic description could be provided as
"mathematical description", for those so inclined.

* Use either "modeling" or "modelling" throughout the text.

* i prefer that syntax examples are preceded by text descriptions. 

4.2(.1) Subclass
* "class Woman, that it is an instance " -> "class Woman, it is an
instance"


4.2(.2) Class hierarchies
Subclass statements may also be used to construct class hierarchies that
build on previous knowledge. For example, we want to say that all
mothers are women while retaining the fact that mothers are also
persons. This inference becomes possible when we assert that the class
Mother is a subclass of Woman: 


Technically, this means that the subclass relationship between classes
is transitive - that the relations follows along a chain of subclass
assertions. In addition, the subclass is also reflexive, meaning that
every class is its own subclass.

4.2(.3) Class Equivalence
Many terms in our vocabulary effectively refer to the same thing, and
OWL provides a mechanism by which to they are considered to be
semantically equivalent. For example, we use the term Person and Human
interchangeably, meaning that every instance of the class Person is also
an instance of class Human, and vice versa.  Stating that Person and
Human are equivalent amounts exactly to the same as stating that both
Person is a subclass of Human and Human is a subclass of Person.


4.3 class disjointness 
In Section 4.3, we stated that an individual can be an instance of
several classes. However, in some cases membership in one class
specifically excludes membership in another. For example, a person can
either be male or female (disregarding biological borderline cases), and
class membership can be restricted to one or the other, and is referred
to as (class) disjointness. This is represented in OWL as follows:


Asserting class disjointness is useful because it can be used to check
if something was incorrectly said. For example, imagine that somebody
said that mary is a Man, and somebody else said that Mary is a Mother.
Since we know that every Mother is a Woman, and Man and Woman are
disjoint, then a reasoner can automatically infer that this information
is incompatible. Thus, the use of class disjointness is useful to check
whether our modeled knowledge is consistent with our expectations.
However, if no disjointness exists between concepts, then membership to
any and all classes may be possible.

4.4 Object Properties
* (nothing is obvious to somebody reading a primer) - remove all
instances of "obvious", "Obviously", etc


* "Indeed, this is a common source of modeling errors. Likewise, it is
important to use" -> "Indeed, this is a common source of modeling errors
that can be avoided by using"


4.4(.1) Negative Object Properties
"We can also state that two individuals are not connected by a property.
The following, for example, states that Mary is not Jack's wife."

<example>

Negative property assertions provide a unique opportunity to make
statements where we know something that is not true. This kind of
information is particularly important in OWL where the default stance is
that anything is possible until you say otherwise. Being able to make
these kinds of negated statements opens new avenues for knowledge
representation, and should be considered especially important in the
sciences where experiments are done to either provide evidence for or
against certain claims. 



4.7
* for the sameAs example, I think a good example is to use a nickname -
like "Richard" and "Dick", or "Anthony" and "Tony".

* "This would enable a reasoner to infer any information about the
individual Jack which is written down for the individual John." ->
"This would enable a reasoner to infer any information about Jack should
be combined with any information provided for John."

5.1
* pointer to RDFS?



5.2 Property Restrictions
By property restrictions we understand another type of logic-based
constructors for complex classes. As the name suggests, property
restrictions are constructors involving properties.

5.2(.1) Existential Quantification
The first property restriction called existential quantification defines
a class as the set of all individuals that are connected via a
particular property to another individual which is an instance of a
certain class. This is best explained by an example, like the following
which defines the class of parents as the class of individuals that are
linked to a person by the hasChild property.

<example>

This means that there is an expectation that for every instance of
Parent, there exists at least one child, and that child is a member of
the class Person. This is useful to capture <italics>incomplete
knowledge</italics>. For example, Sally tells us that Bob is a parent,
and therefore infer that he has at least one child even if we don't know
their name(s).


Building on the previous example, we can accurately describe a
grandparent as a person that has at least one child that is also a
parent

Class: Grandparent
  Equivalento: Person and hasChild some Parent




5.2(.2) Universal Quantification
Another property restriction, called universal quantification is used to
describe a class of individuals for which all related individuals *must
be* instances of a given class. Natural language indicators for the
usage of universal quantification are words like "only," "exclusively,"
or "nothing but". We can use the following statement to indicate that a
happy grandparent is exactly when all their children are parents.

*** the Happy example is really obfuscated -> we should stay with named
classes and build on previous defs

Class: HappyGrandparent
  EquivalentTo: Person and hasChild all Parent

Universal quantification is particularly valuable in asserting
<italics>absolute knowledge</italics> where the set of possible values
is clearly restricted and no other *disjoint* classes may be considered
for that property (although any subclass of Parent will be acceptable!).

* delete "The usage of proper... nothing but"

Unfortunately, a statement consisting of the universal restriction
without the existential restriction leads to unintuitive consequences:
happy grandparents are not necessarily grandparents. In order to
formalize the aforementioned intended reading, the statement would have
to read as follows:

Class: HappyGrandparent
  EquivalentTo: Grandparent and hasChild all Parent
  
which is itself equivalent to:
 
Class: HappyGrandparent
  EquivalentTo: Person and hasChild some Parent and hasChild all Parent

5.2(.3) Restrictions involving individuals
Complex class expressions can also indicate that a relationship exists
with a particular individual.  For instance, we could define the class
of John's children:
 
 <example>
  
5.2(.4) Local Reflexive Restriction
It is sometimes useful to indicate that in a property always links an
individual to itself. The following example shows how to represent the
idea that all narcissists love themselves

<example>

5.3 Cardinality Restrictions
Using existential and universal quantification, we can say something
about all or at least one of somebody's children, respectively. However,
we might want to specify the number of individuals involved in the
restriction. This can be done by either specifiying a minimum, a maximum
or the exact number of individuals. Imagine that you last saw John 4
years ago, and at the time he had 2 children but was planning to have
more:

Individual: John
	Types: hasChild min 2 Person
	
You later remember that John said that he would never have more than 6
children:

Individual: John
	Types: hasChild max 6 Person


You decide to give him a call, and he tells you that he has 4 children
and definitely won't have anymore:

Individual: John
	Types: hasChild exactly 4 Person

The exact cardinality restriction implies that John has a minimum of 4
children and a maximum of 4 children


5.3.1 Answering Questions Involving Cardinality
OWL is a monotonic language which means that it accommodates new
information provided that it is consistent with previous knowledge. Each
of the cardinality statements about John and the number of children adds
increasingly accurate information into our OWL knowledge base. This is
important for correctly answering questions about the number of children
that John has. For instance, if we know he has at least 2 children, then
we do not know exactly how many he has nor how many he has at most. If
we want to specify a range, whether John has between 3 and 5 children,
this can only be answered when we know that he has at least 2 and at
most 6 children, or when we know he has exactly 4 children. If we know
he has between 2 and 6 children, then we cannot know that he has exactly
5 children. 


6.1


..  Instead of using the new hasParent property for the definition of
the class Child, we can directly refer to it as the hasChild-inverse:

 Class: Child
   EquivalentTo: Person and ( inv (hasChild) some Person)

...

On the other hand, a property can also be asymmetric such that if it
connects A with B it never connects B with A. This relation further
infers that A is a different individual than B. Clearly (excluding
paradoxical scenarios resulting from time travels), this is the case for
the property hasChild and is expressed like this:


....

Note that this statement does not require every individual to have a
husband, it just states that there can be no more than one. Furthermore,
if more than one individual is linked to by hasHusband, then the two
individuals must be the *same*. It is also possible to indicate that the
inverse of a given property is functional:

<example>

This indicates that an individual can be husband of at most one other
individual. It also uniquely identifies them as the husband of an
individual. Moreover, if more than one individual holds the relation,
then all the husbands of must be the same. 


6.2
While the last example from the previous section allowed *us* to infer
an hasAncestor property by following a chain of hasParent properties, we
might want to be a bit more specific and define, say, a hasGrandparent
property instead. Technically, this means that we want hasGrandparent to
connect all individuals that are linked by a chain of exactly two
hasParent properties. In contrast to the previous hasAncestor example,
we do not want hasParent to be a special case of hasGrandparent nor do
we want hasGrandparent to refer to great-grandparents etc. We can
express that every such chain has to be spanned by a hasGrandparent
property as follows:

<example>

6.3 Keys
* If keys operate on data or object properties, then do they represent a
superset of an inverse functional object property?  It should be pointed
out that only object properties have inverse functional characteristics,
so keys are good when it operates over a datatype.



8.1
In many cases, we would like to provide comments about the classes,
properties and individuals in the OWL ontology or even describe the
axioms themselves. OWL provides non-logical annotations for this
purpose. An OWL annotation simply associates property-value pairs with
parts of an ontology, or the entire ontology itself. Even annotations
themselves can be annotated. 

8.2 Ontology Management
* explain why we need equivalence to be stated at each level (instance,
property, class)
 - only one illustrative example for each required

* no description of the priorVersion, IncompatibleVersion


8.3 Entity Declarations
* What exactly does the following mean? "Moreover, "built-in" names
(such as those used by RDF and RDFS and various syntaxes of OWL) cannot
be freely used in OWL." 


9 OWL2 DL and OWL2 FULL
10 OWL2 Profiles
* So the question is - are we going to suggest to modellers to restrict
the modeling to a particular profile?  Or rather, should they model as
accurately as they can, but make performance choices knowing how a
particular profile will affect their ontology?
 - I personally think this section is less relevant, but if it is
necessary, then i suggest the following:
* Remove most of the current text - it's really not accessible because
it introduces huge amounts of new and unexplained terminology that is
unrelated to what precedes it
* I think there would be more value in treating OWL 2 DL, Full, EL, RL
and QL all as profiles of the OWL language. 
* A table that compares the profile features, and the additional
interpretation for FULL
* Use one example to illustrate the support for/differences between the
profiles with an axiom annotation - and make the idea of profiles more
accessible. Either start with a weaker profile and successively add more
constructs, or summarizes the support in one example.
* comparisons with RDFS precedes its  description 

13.1 How OWL 2 relates
* I might suggest that a _motivation_ for OWL 2 should identify the
limitations of other technologies in section 2 




That's it for now!

-=Michel=-

Received on Wednesday, 13 May 2009 00:37:50 UTC