Overview

This KBlog describes disjointness in ontologies. The KBlog says what it is; says why you want it and describes how you get it.

In brief, a disjointness axiom about two classes states that an element cannot be an instance of both classes, i.e., that the extensions of both classes are always necessarily disjoint. Stating explicitly that an individual is an instance of two disjoint classes thus makes the ontology inconsistent. Disjointness has both a role in representing the knowledge of a domain and in enabling a lot of inference on an ontology.

We describe different ways of making classes disjoint, illustrated with examples, and explain the consequences of doing so.

The Authors

Robert Stevens and Uli Sattler
BioHealth Informatics and Information Management Groups
School of Computer Science
University of Manchester
Oxford Road
Manchester
United Kingdom
M13 9PL
robert.stevens@Manchester.ac.uk and Ulrike.Sattler@Manchester.ac.uk

What is Disjointness?

Two classes in an ontology are disjoint if they cannot share an instance, regardless of how the classes are interpreted.

For example:

1. There can be no animal (or anything else) that can be both an Elephant and a Newt.
2. If we said that the individual tiny is both a type of Elephant and a type of Newt and that Elephant and Newt are disjoint, then we would have an inconsistent ontology, i.e., one that can never be realised in a model.
3. Also, if we made a class ElephantNewt to be both a subclass of Elephant and a subclass of Newt (with the parents being disjoint), then we would have an unsatisfiable class ElephantNewt, i.e., in each of the ontology’s models, there is never an instance of ElephantNewt (as it would have to be an instance of both Elephant and Newt, which isn’t possible).
4. Similarly, if we say Elephant SubClassOf: Animal and then Elephant DisjointWith: Animal, then Elephant is unsatisfiable: all elephants are animals and no elephants are animals, a straight-forward contradiction, and thus there cannot be any Elephant.

Now, in OWL, classes are not disjoint unless we somehow say that they are. That is, classes potentially overlap in their extents – unless stated otherwise, and there are many ways in which we can make a disjointness statement.

Why do we care about Disjointness?

1. Because it is “true” (or it is what we want to say about entities in our field of interest); there is a simple knowledge representation requirement to be able to say that an individual cannot be instances of two classes. One important role of an ontology is to make domain knowledge explicit and disjointness makes this explicit for humans and computers.
2. Also, disjointness has far-reaching effects on entailments. Ontologies are used as part of applications in which queries are made, or where inferred class hierarchies are considered and individuals realised into classes. Disjointness has an important role in causing entailments. In other words, not making classes disjoint that we consider as being disjoint will then lead us to find that we don’t get the entailments we were expecting.

Let’s discuss this second point with the help of some examples. Before we do so, let us point out that, in OWL, if we have an ontology where we declare two classes A and B, and say nothing more about them, then any model of our ontology can interpret these classes in any way it likes: as empty sets, one contained in the other, intersecting, or as disjoint sets. Adding axioms about A and B restricts possibilities that models of our ontology have to interpret them. In particular, a disjointness axiom between A and B restricts models to those that interpret A and B and disjoint sets.

For example, assume that all we know about Elephant and Newt is that they are subclasses of Animal, and consider the following statements:

Individual: Finknotle
        Types:
                Person,
                owns some Newt,
                owns some Elephant

If we now ask for people that own at least two animals, we won’t get Finknotle, as we don’t know that the owned instance of a newt isn’t also an elephant: as it is possible that Finknotle only owns a single animal that happens to be both a newt and an elephant, Finknotle isn’t necessarily an instance of Person and atleast 2 owns Animal. If, on the other hand, if the classes Elephant and Newt are disjoint, then it is no longer possible that Finknotle only owns a single animal that happens to be both a newt and an elephant. And thus we know that Finknotle has at least two animals and therefor would be an instance of Person and at least 2 owns Animal. As he may have even more pets, he would not be an instance of Person and exactly 2 owns Animal…but this is part of another discussion.

Similarly, but slightly more involved, assume that we say the following:

Class: PProtein

        SubClassOf:  Protein ,
                hasPart some Alpha-helix,
                hasPart only Alpha-helix

Moreover, assume that we hadn’t made Alpha-helix and Beta-sheet disjoint. Then asking for a protein without beta-sheet (i.e., instances of Protein and hasPart only not beta-sheet) would not return PProtein. Our domain knowledge tells us that nothing can be both a beta-sheet and an alpha-helix, but the automated reasoner can’t know this: we need to say explicitly that alpha-helix and beta-sheet are disjoint. If we do this, then PProtein is returned as expected.

Next, consider the following example:

Class: NewtOwner

        EquivalentTo: owns only Newt

Class: ElephantOwner

        EquivalentTo: owns only elephant

One might assume that NewtOwner and ElephantOwner are disjoint if Newt and Elephant are disjoint. This is, however, not the case since someone who owns nothing is an instance of both: if somebody is not owns-related to anything, then it is vacuously the case that all its owns-successors are instances of every class, in particular instances of Newt and of Elephant. Hence such a have-not would be both a NewtOwner and an ElephantOwner.

If we make, additionally, NewtOwner and ElephantOwner own something, then indeed NewtOwner and ElephantOwner are disjoint if Newt and Elephant are:

Owner

  EquivalentTo: Person and owns some OwlThing

NewtOwner

  EquivalentTo: Owner and owns only Newt

ElephantOwner

  EquivalentTo: Owner and owns only elephant

How to Make Classes Disjoint

The most common way of expressing disjointness is with a disjointness axiom:

Elephant

DisjointWith: Newt

This just says directly that nothing can be both a type of Elephant and a type of Newt, and it applies to both named classes and unnamed ones.

Now disjointness statements aren’t restricted to named classes: we can also state that class expressions have to be interpreted as disjoint sets, e.g., as follows:

(isPartOf some Nucleus)

DisjointWith: (isPartOf some Mitochondrion)

As a consequence of the above axiom, elements cannot be both part of the nucleus and part of the mitochondrion; a rather strong statement (though now it’s explicit, it can be examined – the KR argument given above).

Additionally, there are several other ways to explicitly state disjointness, and it is also possible to imply disjointness – or both at the same time. We will now discuss some of these.

First, as an alternative to the above disjointness axiom on elephants and newts, we can say the following:

Elephant

SubClassOf: not Newt

This has exactly the same meaning and thus the same consequences as the first disjointness statement.

Next, we observe that, if we have two subclassses of our disjoint classes, then they are also disjoint: for example, Indian Elephant and Great Crested Newt will be disjoint when added to our animal ontology.

However, when we state that African Elephant and Indian Elephant are subclasses of Elephant, then they are not automatically disjoint; this has to be asserted or implied in some way.

As mentioned above, disjointness can be stated explicitly or implicitly, and we next discuss some simple ways of implicitly making classes disjoint. Take the classes

Class: Helium

SubClassOf: hasPart exactly 2 Proton

Class: Lithium

SubClassOf: hasPart exactly 3 Proton

As each and every Helium must have exactly two protons (no more and no less) and each and every Lithium must have exactly 3 protons, an atom cannot be both helium and lithium at the same time. Hence any explicit disjointness axiom on atoms is redundant if we model them in this way – and this safes us roughly 10K disjointness axioms in the 100 or so types of atom!

Similarly, if we have classes with the axioms

Class: A

hasPart at most 3  C

Class: B

SubClassOf: hasPart at least 4 C

then A and B are disjoint as there is no way an individual can fulfill both these criteria without contradiction. The next example is a non-obvious case of this situation:

Class: G

        SubClassOf: hasPart some  C

Class: H

        SubClassOf: hasPart only not C

Observe that hasPart some C means has at least one part that is a C and hasPart only not C means has only parts that are not Cs, which in turns means has none/zero parts that are a C. Hence the above two axioms also imply disjointness between G and H.

Finally, we want to mention that OWL 2 provides us with short-cuts in the forms of the AllDisjoint axiom and the DisjointUnion axiom. The latter makes a list of classes subclasses of the class on its left-hand-side, makes all classes in the list pairwise disjoint, and adds in a covering axiom for the left-hand-side being covered by the right-hand-side. For example,

Class: AminoAcid

        DisjointUnion (Alanine, Cysteine, Aspartate, Glutamate,
        Phenylalanine, Glycine, Histidine, Isoleucine, Lysine,
        Leucine, Methionine, Asparagine, Proline, Glutamine, Arginine,
        Serine, Threonine, Valine, Tryptophan, Tyrosine)

means that AminoAcid has all the subclasses listed, and that those subclasses are all disjoint. Also, and importantly, the listed amino acids are covering for AminoAcid (that is, any given amino acid must be an instance of one of the classes in the list).

Making Individuals Different

We can have a similar discussion about equality of individuals. Individuals may be the same unless we say or imply that they are different. We can do this, for example, with a DifferentIndividuals axiom and, as with disjointness, this will lead to expected but also possibly unexpected answers. Take the following example:

Individual: Harry

        Facts:

    hasFather Charles,

    hasFather James

If hasFather is stated to be functional, any individual may only hold one of this property to a distinct individual. However, without a different individuals axiom on James and Charles (or something implying it), they may or may not be identical, and thus the axioms above won’t lead to an inconsistency. Adding a different individuals axiom on James and Charles (or something implying it) leads to an inconsistency.

Warm Words

So, disjointness is important both as a means to describe the world as we see it, and also to get the inferences we expect. We have just seen a number of ways to make classes disjoint, and some of the consequences of doing so. This is well exemplified in ontology design patterns like normalisation: this pattern uses a tree of asserted primitive classes with all sibling classes being pair-wise disjoint. Defined classes then use this foundation upon which to build the polyhierarchy desired for knowledge representation etc. This use touches both the KR and inference point outlined above.

So, disjointness is a basic part of ontology building and inference. We hope you enjoyed the trip and will fly with us again.

Overview

This article describes approaches to dealing with synonomy in ontologies written in the Web Ontology Language (OWL). synonomy is an important issue in ontologies as one of the roles of an ontology is to help manage the vocabulary used for entities in a field of interest. As synonomy is rife, understanding how to deal with the phenomenon in ontologies written in OWL is important. There is a choice between managing synonomy through the use of labels on classes or via equivalence, to state that two extents are the same. The article indicates where the choice should be made and illustrates with examples.

Authors

Robert Stevens
bioHealth Informatics Group
School of Computer Science
University of Manchester
United Kingdom
M13 9PL

Phillip Lord
School of Computing Science
Newcastle University+ Newcastle
United Kingdom
NE3 7RU

Wikipedia describes synonyms as words that have the same meaning or more or less the same meaning as another word. A typical biological example would be Erythrocyte and red blood cell; these two labels are inter-changeable and completely preserve meaning. The two labels have extents that are the same set of cells with the same definitions. Scientific English is rife with this sort of nomenclature difference; from the pseudo-Greek of erythrocyte to the more straight-forward red blood cell, and the spellings of sulphur and sulfur, haemoglobin and hemoglobin. There are also all the results of autonomous namings of proteins and genes such as seen in almost any Uniprot record for a protein sequence such as “LARD”.

These are different symbols used by scientists for the same concept (set of instances). In OWL there is a choice of how this is managed:

1. Through use of the equivalence axiom that says that two classes have the same instances.
2. Simply through labelling of the concept or class using anotation properties such as the skos:prefLabel and skos:altLabel of SKOS. Such annotations are part of editorial metadata that can occur in ontologies.

The choice between these two options is normally made on the basis of modelling intention. If the ontologist wishes to highlight that there are two names, or two labels for the same concept, then in general they will use the synonomy mechanisms supported via annotation properties in OWL. However, if the ontologist wishes to highlight that there appear to be two different definitions for the same concept, then they would use equivalence. This is a decision related to the distinction between a class and its extent.

We explain this further with a set of examples. In OWL the axiom A equivalentTo B states that the extents of the two classes are the same — they are equivalent. The statement

(Polygon and hasPart exactly 3 sides)
       EquivalentTo:
(Polygon and hasPart exactly 3 angles)

is an equivalence axiom; both classes represent all instances of triangles. However, they have different definitions: one using the concept of a side and one the concept of an angle. One definition, however, implies the other; for a polygon to have three angles, it must have three sides, and vice versa. Here we have different intentional definitions for the same extent of instances; we are capturing this in our ontology by having two definitions and marking them as equivalent.

We could also have:

Class: 000001
Annotations:
label "Triangle",
synonym "Polygon with three sides",
synonym "Polygon with three angles"
SubClassOf: Polygon
and hasPart exactly 3 Sides

In this case, however, we have only formally captured the definition using three sides. The use of synonym labels here is, therefore, wrong. It is, essentially, mistaking the notion of a polygon with three angles as a label.

As well as being able to explicitly state equivalence, it is also possible to computationally reason that two definitions, in fact, are the same class. For example, in the Family History Knowledge Base (FHKB), a woman is defined as any person that has sex female; while a daughter is defined as being any woman that is the child of some person. The reasoner infers these to be equivalent; despite the different definitions, it is the case that all woman are indeeed daughters (of somebody!). The Amino Acids Ontology has some infered equivalence due to the closing of the world of amino acids to those found in biology.

We can contrast this with examples of clear synonomy — where one definition for a concept simply has multiple labels. A simple example is “acetic acid” and “ethanoic acid”; “femur” and “thigh bone”; and the Gene Ontology ID GO:0016049 has the label “cell growth ” and exact synonyms “cellular growth” and “growth of cell”.

One specialised use of synonomy is for internationalisation. The distinction between sulphur and sulfur is an example of dialectic variation between British and American English, while sulfur and zolfo is a language difference. While OWL uses the same mechanism to represent these, again, there is a distinction of intentionality. The labels are considered to be equivalent, without a prefered label, while synonomy often implies a preferred and non preferred term. We could, for example, write:

Class: 000666

Annotations:
SKOS:prefLabel "Common cold"@en,
SKOS:prefLabel "Un raffreddore"@it,
SKOS:altLabel "Bit of a sniffle"@en,
SKOS:altLabel "essere costipato"@it

where we see differences in internationalisation and synonomy. Here we clearly have a simple case of multiple labels for the same concept, some down to different languages and some down to preferences within languages. OWL uses the language tags from the IETF to designate language for a label (it is possible to say which language to use in display in many tools). Unfortunately, it is not possible to define one’s own community tags that would enable community variants of labelling to be taken into account for presentation.

As always, there are some edge cases where it is less clear whether we see an example of synonomy. For example, compare the labels “Sulphur” and “Brimstone”. While, “brimstone” could be considered to be a synonymous term as “sulphur”, in modern parlance as it has become archaic, so it has gained religious connotations. Therefore, a priori it is unclear whether “brimstone” should be considered a synonym of sulphur, or a mythical substance of historical, rather than scientific interest.

From a functional point of view, the most important distinction between equivalence and synonymy is that it is possible to automatically reason the former and not the latter, which must always be asserted. It is possible, therefore, for two concepts to lose their equivalence. For example, if woman and the daughter are equivalent, this implies inductively that humans must have existed forever, which is not true. If we extended the Family History Knowledge Base to deal with evolutionary as well as historical time, then the equivalence of these concept would have to change also.

In summary, there is a relatively straight-forward choice to be made between wehther one has a case of labelling synonomy, with one label being preferred, and a case of differing intentional descriptions with the same extent. The former is managed, in OWL, with annotations (with a range of implementations possible) and the latter with equivalence axioms and, possibly, inference.

As an ontologist, I probably should have known better and got this right in the first place. I have changed Ontogenesis to use semantic-free identifiers. From initial testing, it appears that WordPress is doing-the-right-thing. The old permalinks redirect to the right place, and internal links have been automatically updated. So, it should work from inside and outside, but please let me know if it is broken anywhere.

The motivation for this came from two sources. First, some one suggested that I change the name of my article; the suggestion was a good suggestion, but I started to worry that it would make my permalink out-of-date. Second, Duncan Hull decided to shorten the permalink for his article. Perfectly sensible but, again, this caused some consternation as it broke the implied semantics.

Bottom line, here, is that semantics free identifiers seemed like a sensible way to go. The flip side is, of course, that they are a little harder to remember, and there is more chance of error when inserting them in text, because you can’t tell whether it’s the right link or not. However, this is also true if articles change during review so that the implicit semantics in the link are wrong.

There isn’t really a way to square this circle. Comments welcome.

The Ontogenesis kblog is an open environment; this includes the reviews too. So, the author will know who reviewed the article; indeed, it is most likely that the authors selected the reviewers. It is our hope and experience that the open nature of the review process contributes positively to the process; reviewers gain credit for their contribution, while at the same time, ensuring that the process is self-policing.

We ask that reviewers apply the same reviewing standards that we would all like to have for our own articles; they should provide significant, positive and constructive feedback about the article. Articles for ontogenesis kblogs are aimed at an audience that is attempting to learn about ontology modelling, authoring and using ontologies. They are supposed to be short, accessible articles; while they should be correct, they do not need to be fully detailed. If more needs to be written, this may indicate another article is needed — we welcome contributions the ideas for which have come from the reviewing process.

Reviewing an article follows a similar process to writing an article in the first place, and should present no technical challenges for those who have already written a kblog article. A more complete description of the technical process is available on Process.

Authors

Phillip Lord
School of Computing Science
Newcastle University
United Kingdom
NE3 4PH

phillip.lord@newcastle.ac.uk

Robert Stevens
School of Computer Science
University of Manchester
United Kingdom

mailto:robert.stevens@manchester.ac.uk

This is a review for Uli Sattler’s article on OWL the Web Ontology language. The title “OWL” looks a little strange in the table of contents, so I’d be inclined to change it to “The Web Ontology Language (OWL)”. Most of my comments are at this level, so indicates that the article is fine. I have only a few other comments.

As a background to how OWL works this K-Blog works for me. This article takes the reader on an introductory tour of OWL. It gives a genral background on OWL. It concentrates on the reasoning side of OWL – what a reasoner does. A few lines of introduction to say what the purpose the article is and what it wil not do would be useful. for instance, a guide to OWL exspressivity and modelling tips for OWL is not the purpose of this article. A link to Phil Lord’s KBlog on components and Matt Horridge’s on OWL syntax would be good.

Whilst OWL is probably the most prominent ontology language of the moment, within the biology context that is the topic of the Ontogenesis Kblog, the OBOF format should be mentioned (along with a link to the OBOF K-Blog). In this community, OBOF is very widely used and this should be acknowledged.

It would be useful to give a simple statement of what an axiom is. The word “model” and its meaning within the DL world may need more attention as well (or a warning to just overlook it). Model is used in this community in its much more general sense.

“where OWL and reasoning is used purely to make sure that the things said about classes and the resulting entailed class hierarchy are correct” – Is OWL natively used in SnoMED? I thought it used a DL, but not OWL as such. Also, “correct” needs care as it is checked for logical correctnesss rather than domain of interest correctnerss.

Minor:

• “are important: OWL comes in” → sentence change instead of colon.
• “, properties, and inviduals” → individuals
• “chose whatever relation you like” → choose
• “help us unterstand ” → understand
• “Coming back to Protege” → new paragraph at onset of this sentence.
• “currently recides in” → resides
• “Both have clearly advantages ” clearly have

reviewed by robert Stevens

School of Computer Science, University of Manchester.

This is a review for Uli Sattler’s article on OWL the Web Ontology language. The title “OWL” looks a little strange in the table of contents, so I’d be inclined to change it to “The Web Ontology Language (OWL)”. Most of my comments are at this level, so indicates that the article is fine. I have only a few other comments.

As a background to how OWL works this K-Blog works for me. This article takes the reader on an introductory tour of OWL. It gives a genral background on OWL. It concentrates on the reasoning side of OWL – what a reasoner does. A few lines of introduction to say what the purpose the article is and what it wil not do would be useful. for instance, a guide to OWL exspressivity and modelling tips for OWL is not the purpose of this article. A link to Phil Lord’s KBlog on components and Matt Horridge’s on OWL syntax would be good.

Whilst OWL is probably the most prominent ontology language of the moment, within the biology context that is the topic of the Ontogenesis Kblog, the OBOF format should be mentioned (along with a link to the OBOF K-Blog). In this community, OBOF is very widely used and this should be acknowledged.

It would be useful to give a simple statement of what an axiom is. The word “model” and its meaning within the DL world may need more attention as well (or a warning to just overlook it). Model is used in this community in its much more general sense.

“where OWL and reasoning is used purely to make sure that the things said about classes and the resulting entailed class hierarchy are correct” – Is OWL natively used in SnoMED? I thought it used a DL, but not OWL as such. Also, “correct” needs care as it is checked for logical correctnesss rather than domain of interest correctnerss.

Minor:

• “are important: OWL comes in” → sentence change instead of colon.
• “, properties, and inviduals” → individuals
• “chose whatever relation you like” → choose
• “help us unterstand ” → understand
• “Coming back to Protege” → new paragraph at onset of this sentence.
• “currently recides in” → resides
• “Both have clearly advantages ” clearly have

reviewed by robert Stevens

School of Computer Science, University of Manchester.

This is a review for Uli Sattler’s article on OWL the Web Ontology language. The title “OWL” looks a little strange in the table of contents, so I’d be inclined to change it to “The Web Ontology Language (OWL)”. Most of my comments are at this level, so indicates that the article is fine. I have only a few other comments.

As a background to how OWL works this K-Blog works for me. This article takes the reader on an introductory tour of OWL. It gives a genral background on OWL. It concentrates on the reasoning side of OWL – what a reasoner does. A few lines of introduction to say what the purpose the article is and what it wil not do would be useful. for instance, a guide to OWL exspressivity and modelling tips for OWL is not the purpose of this article. A link to Phil Lord’s KBlog on components and Matt Horridge’s on OWL syntax would be good.

Whilst OWL is probably the most prominent ontology language of the moment, within the biology context that is the topic of the Ontogenesis Kblog, the OBOF format should be mentioned (along with a link to the OBOF K-Blog). In this community, OBOF is very widely used and this should be acknowledged.

It would be useful to give a simple statement of what an axiom is. The word “model” and its meaning within the DL world may need more attention as well (or a warning to just overlook it). Model is used in this community in its much more general sense.

“where OWL and reasoning is used purely to make sure that the things said about classes and the resulting entailed class hierarchy are correct” – Is OWL natively used in SnoMED? I thought it used a DL, but not OWL as such. Also, “correct” needs care as it is checked for logical correctnesss rather than domain of interest correctnerss.

Minor:

• “are important: OWL comes in” → sentence change instead of colon.
• “, properties, and inviduals” → individuals
• “chose whatever relation you like” → choose
• “help us unterstand ” → understand
• “Coming back to Protege” → new paragraph at onset of this sentence.
• “currently recides in” → resides
• “Both have clearly advantages ” clearly have

reviewed by robert Stevens

School of Computer Science, University of Manchester.

This is a review on community driven ontology development, by frank gibson and James Malone. this is a good article topic for the Ontogenesis Kblog — ontologies need to be used, and this usually means a community; though an ontology can be built by one person to be used in an application (so the users of the application ar the community and therefore somewhat indirect to the ontology). I think that starting the article with the (perhaps obvious) statement that if an ontology is to be used by a wider community then it meeds to engage that community would be good. There are few, if any, ontologies that are actually used widely that have small community engagement and/or are not collaboratively built in some way. It may be useful to distinguish between community involvement and collaboration. It is possible to have community engagement without collaborative authoring and it is possible to have collaborative authoring without community engagement (here I would say that feedback via issue trackers as OBO often do it is not collaborative authoring, but is a collaboration by commmunity engagement – and a useful one).

It might also be good to draw out the way many of the successful OBO ontologies do this sort of comunity driven aspect, especially where the dynamic nature of the authoring is an issue and what its consequences are. This might help talk about different types of engagement: Actual authoring; reporting of issues; etc. As the OBO process is pre-dominant in this field, it might be useful to describe their process more fully and this would link back to the drawing out of types of community engagement.

Finally, the article could do with some kind of conclusion, summary or wrapping up. Also, a further “how to” article on doing community driven development would be good.

Minor Comments

• with slightly different defintions. = definitions.
• - the The Open Biomedical Ontology = double word
• - Foundry acts as a registry = a repository actual holds the artefact a registary simply catalogues the thing; I suspect the OBO Foundary would be a repository, though I’m not the person to say.

by Robert Stevens

Overview

In this k-blog we look at another kind of statement found in an ontology, higher order knowledge. In this case it is orientated about statements about the class, rather than the instances of the class, which is the norm in an ontology.

Authors

Robert Stevens and Alan Rector
bioHealth Informatics Group
School of Computer Science
University of Manchester
United Kingdom
M13 9PL

Higher Order Knowledge

First order knowledge describes individuals. In OWL we describe the individuals themselves or classes where we describe things that are true of all individuals in a class. We often, however, wish to describe other knowledge about the class, not only the individuals in that class. These are not metadata about the class, but extra knowledge about the class, rather than knowledge about the individuals of that class. For example, the class Electron is the anti-particle of the class Positron. We do not wish to say that each instance of the class Electron has an anti-particle of a Positron; that is simply wrong at many levels.

Instead, we need to say things about the class, not its individuals. This is second order knowledge; a kind of higher order knowledge. Higher order statements are always, in some sense, about classes – that’s what makes them higher order, although they may, of course, also contain statements about individuals related to those classes.

We can see examples of this kind of second order knowledge in basic chemistry:

• The discovery year for an element; we do not wish to say that all individual francium atoms were discovered in 1939. However, we may wish to say that the category Francium was discovered in 1939.
• The positron and electron example given above.
• Constraining a class MoleOfPureAtom to have only one type of atom. This can be done for specific atoms — a mole of sodium is made of some and only hydrogen atoms. Doing this for the general MoleOfAtom is more difficult: MoleOfAtom is made of some and only Atom cannot constrain the class to be made of only one type of atom. Using exactly 1 simply says there is at least one atom in the mole, not that it has only one type of atom. We need to make a statement about the class, not its individuals.
• Diamond is an allotroph of graphite. We don’t need to say that each instance of diamond is an allotroph of some instance of graphite. It is something we want to say about the classes themselves.

Making Higher Order Statements

We need a mechanism to describe the hier order knowledge. OWL is poor at modelling and reasoning about such higher-order knowledge. As stated, it really only does first order statements, though OWL 2’s punning comes closer and OWL’s annotation properties allow statements to be made about statements, but without exposing such statements to reasoning etc.

OWL2’s puns are a mechanism for making higher order statements. In OWL2, an individual can be created that has the same URI as the class. As well as holding metadata about the class, this “punned’ individual can be used to make higher-order statements about a class. Taking our Electron example; A pun also called Electron can be created. If there is another class and pun called Positron a relationship can be made between the two puns of isAntiparticleOf (with the characteristic of being symmetric). This is a statement about the class Electron and not the instances of Electron. Higher-order reasoning is, however, outside the world of OWL and puns can be queried, but not submitted to OWL’s usual automated reasoners.

Summary

An ontology contains (or at least should contain) so much more than the axioms describing the instances of a domain. It should contain metadata that describes the ontology as an artefact. Elsewhere, we have described 3 kinds of metadata in ontologies. We have also described higher-order knowledge, statements about the classes in an ontology where the usual axioms are just about the individuals of a domain. Each of these types of metadata and higher-order knowledge are an important part of modelling a domain. In addition, we should note that higher order domain knowledge should not be confused with metadata. Higher order domain knowledge is about the categories themselves e.g. Who first described a disease, whether a species is endangered, etc. whereas the first order knowledge that makes up the main body of Domain Knowledge is about the members of the categories e.g. patients with diabetes, etc. Higher order domain knowledge is about the domain rather than the information artefact. In OWL all of these statements can be syntactically represented as annotations and call them “metadata”, but there is a distinction that should be made between them.

Overview

Inn this kblog we talk about statements that are generalisations about a domain, but are not universally true. Much of domain knowledge can fall into this category of statement and it is important to understand that it exists and the issues involved in its representation.

Authors

Robert Stevens and Alan Rector
bioHealth Informatics Group
School of Computer Science
University of Manchester
United Kingdom
M13 9PL

Introduction

As already said, if ontologies are about anything at all, then they are concerned with universal statements about individuals or objects of a field or domain. However, if we are to capture a broad set of useful knowledge about a domain, then we have to capture knowledge about that domain that doesn’t conform to this strrict criterion. In contrast to the universal statements, where the thing said is true of “all” individuals of a class, we are also concerned with statements that are “mostly” true or “usually” true of those objects. Strictly speaking such knowledge is not ontological, but it is useful, so we do talk about it here. Such statements are another form of statements in an ontology.

We might want some of these “non-universal” statements to capture domain knowledge in our ontology (sic)- information is sometimes or typically but not universally true. For example, “The first line treatment for pneumococcal pneumonia is amoxicillin” or “Rales are evidence for pneumonia”. biology is rife with such examples.