Thomas A. Alspaugh
Glossaries and Ontologies
glossary

Fig. 1. Glosses written in margin and between lines
of a page of Gregory IX's Decretals
(used by permission of the Bodleian Library)

Glossaries

A glossary is a partial dictionary, a list with explanations of technical or abstruse terms, a collection of glosses. A gloss is a synonym or explanation inserted between the lines or in the margin to explain difficult words in a text — see the beautiful example to the right (Fig. 1) dating from 1241, in which you can clearly see glosses in the left margin, and also in the right margin, the center gutter, and in many of the spaces between lines. A glossary collects such glosses in a single place, rather than dispersed through a document.

A glossary for a particular problem or domain is a list of the special terms that are used there. A glossary is a partial dictionary in that it does not include words that are used in their ordinary senses, only those that are either special words not used in ordinary life or that are used with a special meaning in this context.

See the voting glossary for an example of a glossary in requirements engineering. This glossary defines the words and phrases that are used with special meaning in the domain of elections and voting. Hyperlinks are used to take a reader from each use of a glossary term to the definition of that term, and the distinctive format of hyperlink text identifies each such use.

A good glossary defines every word and phrase that is used with special meaning, and gives these definitions in terms of ordinary words and in terms of other glossary terms.

Ontologies

Glossaries are great as far as they go, but in software requirements we are also very interested in the relationships among concepts, which are made explicit in an ontology.

An ontology consists (for our purposes) of several components:

  1. a glossary of concepts (as in the voting example)
  2. a subsumption hierarchy of those concepts (relating concepts to sub-concepts), in which if A subsumes B then every instance of B is also an instance of A
  3. an whole-part hierarchy of those concepts (relating concepts of individuals to concepts of component parts of those individuals)
  4. properties associated with each concept (relating concepts of individuals to concepts of properties, not parts, of those individuals).
  5. other relationships between concepts.
  6. cardinality constraints on relationships.
  7. the distinguished individuals of each concept, individuals that are always present and that are significant enough to be named. For example, in the concept Number the individuals zero and one are often distinguished, due to their unique properties in addition and multiplication.
Vehicles.
  1. concepts vehicle, car, bicycle, wheel, engine, model year, license number, license plate defined in glossary.
  2. Subsumption hierarchy includes: vehicle subsumes car, or car is a sub-concept of vehicle (so, every car is also by definition a vehicle).
  3. Whole-part hierarchy includes: cars consist of wheels, an engine, and some other things (so, every car has wheels and an engine).
  4. Properties include: a car has a model year.
  5. Other relationships include: each license plate corresponds to a separate license number.
  6. Cardinalities include: every bicycle has exactly two wheels, cars have at most one license number; given a license number, it is possible to determine what car (if any) corresponds to it.
  7. There are no distinguished individuals that are always present and are significant enough to be named.

An ontology adds more information that is not present in a glossary. This additional information provides for more informative problem descriptions. It also makes it easier to check that the glossary is correct, by giving paths by which we can try out what we have so far. For example,

Some of this additional information can be effectively presented in a diagram. Figure 2 illustrates one form of diagram for ontologies (there are many); this form uses a notation similar to UML class diagrams. A key for this kind of ontology diagram is given in Figure 3.

ontology key

Fig. 3. Key to ontology diagrams

Number ontology diagram

Fig. 4. Ontology diagram — numbers

For some reason it is rare to see an ontology diagram with individuals as well as concepts. Figure 4 shows an ontology of several types of number, with several individuals shown as well. The individual-of relationship is propagated transitively by subsumption, so that for example because Algebraic subsumes Rational, ½ is an algebraic number (a root of some polynomial with integer coefficients) as well as a rational number.

There are several terms that seem just about interchangeable with ontology in requirements engineering, such as conceptual map and conceptual graph. Ontology-like things have been studied and used for decades, for example entity-relationship diagrams which date back to the 1970s. Description logic provides a formal underpinning for ontologies, and is the basis for the OWL Web Ontology Language, supported by the Protégé ontology editor and several semantic reasoners. Alloy provides a relational logic notation with which ontologies can be expressed formally, and then checked using a software tool.

Deciding what kind of relationship it is

Once you have decided that two concepts T and t are related, you need to decide what kind of relationship they have. One way to decide is to consider the following questions, in sequence:

  1. Is every t a T? Then T subsumes t (t is a sub-concept of T).

    (It must not be possible for any t not to also be a T.)

  2. Does every T contain a t as a component part of it? Then T and t have a whole-part relationship.

    (T and t must be the same sort of concept: both are physical objects, or both are mathematical concepts, or ….)

    (It must not be possible for a particular t to be part of more than one T at the same time; if it is possible, then probably a t is a property of a T rather than a component part.)

  3. Is every T described by a t ? Then t is a property of T.

    (It must not be possible for any T to not have a t that describes it.)

  4. Are T and t related, but not in any of the ways listed above? Then t is just related to T.

Because the hierarchical subsumption and whole-part relationships are transitive, you do not need to specify them across more than one level of hierarchy. For example, if Toyota Prius is a sub-concept of Toyota, and Toyota is a sub-concept of car, you need not also say that Toyota Prius is a sub-concept of car, because it is already implied. Similarly, if tire is a part of wheel, and wheel is a part of car, you need not say that tire is a part of car because this is also already implied.

Relations are inherited down the subsumption hierarchy, and these do not need to be explicitly stated either. For example, car is related to model-year, so you need not say that Toyota Prius is related to model-year because this is already implied.

Example: car, Toyota Prius, wheel, model year, driver, goal. What kinds of relationships do these have?

Deciding what cardinality is appropriate, if any, for a relationship

Subsumption relationships never have cardinalities; they make no sense for this kind of relationship.

A whole-part relationship or a property relationship has an implicit cardinality (at one end). If a t is a part of a T, then there is necessarily at most one T for every t already, and this should not be also specified as a cardinality. If a t is a property of a T, then there are ordinarily many Ts for every t already, and this should not be also specified as a cardinality. If the cardinality of the values for a particular property is important, the relationship should probably not be expressed as a property.

It is possible to have one cardinality at the part end of a whole-part relationship, or at the property end of a property relationship. A T may consist of n ts, for example, or be characterized by n values of property p.

Other relationships can have cardinalities at either or both ends.

Example: car, Toyota Prius, wheel, model year, driver, goal. What kinds of cardinalities do these have?

Testing the correctness of an ontology

In general, one can test the correctness of an ontology by asking these questions:

  1. Glossary. For every term T in the glossary and term U used to talk about the domain:
    1. Is T a special term not in common use, or a common term that has a special meaning in this domain? (must be yes for every T)
    2. Is every word used in the definition of T either a common word used in one of its common meaning, or another term defined in this glossary? (must be yes for every T)
    3. Is T needed to discuss the domain? (must be yes for every T)
    4. Does the glossary contain U? (must be yes for every U)
  2. Subsumption hierarchy. For every concept T that has a sub-concept t:
    1. Are all ts also Ts? (must be yes)
    2. Are there Ts that are not ts? (should be yes)
    3. Is there anything one can do (relationships, properties, …) with a T that one can't do with a ts? (must be no)
    4. Is there anything one can do with a t that one can't do with a Ts? (should be yes)
    5. Is there anything that is true of a T that is not true of a ts? (must be no)
    6. Is there anything that is true of a t that is not true of a Ts? (should be yes)
  3. Whole-part hierarchy. For every concept T whose individuals have ts, us, etc. as their component parts:
    1. Does a T consist of anything other than its ts, us, etc.? (must be no, at least for the purposes of discussing the domain)
  4. Properties. For every concept T and one of its properties P, P', etc.:
    1. Does every T have some value for P? (must be yes)
    2. Does every T have the same value of P? (should be no, unless T is a sub-concept that inherits P from its parent in which case yes is acceptable)
  5. Other relationships. For every relationship R between individuals of concept T and U:
    1. Are there some individuals of T and U that are R? (should be yes)
  6. Cardinality.
    1. (Ask questions that test the specific cardinalities.)

Ontology diagrams are not class diagrams

The concepts, properties, organization, and relationships, of an ontology can be partially expressed in a diagram. This diagram is similar in some ways to a UML class diagram, but in other ways not similar.

Similar (in an ontology) (in a class diagram)
Both have a hierarchical organization of concepts of classes
Both have relationships between things between individuals of concepts between objects of classes
Both have ways to restrict relationships cardinalities cardinalities
Not similar (in an ontology) (in a class diagram)
Different kinds of things are in the diagram Things in the problem space Things in the system implementation
Implementation-specific notation operations (methods)
associations as classes
most of the stereotypes
frooble ontology

Fig. 5. The same approaches apply no matter what the concepts

Questions to ask about parts of an ontology

In general, there are certain questions you can (and should) ask about parts of an ontology, even if you don't know what the concepts mean (as in the Frooble example diagram in Fig. 5).

  1. Questions about concepts (an A)
    1. What can an A do (or have, or be related to) that a non-A can't?
    2. What can't an A do that a non-A can?
    3. What can only some A's do?
    4. Can a non-A later become an A? Can an A later not be an A?
  2. Questions about properties (A is P)
    1. If A is P right now, does that mean A is always P?
    2. What can A do or not do if it is P?
    3. What can A do or not do if it is not P?
    4. What other relationships can A have if it is P, that it can't have if it is not P?
  3. Questions about subsumption hierarchy (An A is a B)
    1. Can an A do everything a B can? (should be yes)
    2. Are there Bs that are not As? (should be yes)
    3. If an A is a B now, can it later still be an A but not be a B? (should be no)
    4. If an A changes later so it is no longer an A, is it still necessarily a B anyway? (could be either yes or no)
    5. Can an A change later so it is not an A? (can be either yes or no) (unlike UML class diagrams)
  4. Questions about relationships (A is R with B)
    1. Is every A R with some B?
    2. How many Bs is A R with?
    3. Is A always R with B?
    4. Is A necessarily R with itself?
    5. If A is R with B, does that mean B is R with A?
    6. If A is R with B, and B is R with C, is A R with C?

You can ask these questions about any ontology, even if you don't know what the concepts in the ontology mean. The answers help test you understanding of the relations among the concepts

flip bgunflip