• Home
• Foundations
• ⁘
• Mathematical
  • Sets
  • Relations
  • Correspondences
  • Ordered Sets
  • Lattices
  • Graphs
  • Powersets
  • Cartesian Products
  • Binary Strings
  • aia
  • Greek &c.
• Logic
  • Logic
  • Math. Induction
  • Strong Induction
  • Recurs. Defs., Derivs.
  • Structural Induction
  • Regular Expressions
  • Protégé 4
  • Macro Processing
• Writing/Thinking
  • External Glossary
  • Abstracts
  • Argument
  • Formality
  • Inquiry Cycle
  • Legal Relations
  • LATEX
  • Negotiation
  • Presentations
  • Quotations
  • Teamwork
• SWD
  • Quotations
  • Kinds
  • Architecture
  • Data Flow
  • Evolution
  • IP
  • Object Orientation
  • Process
  • Reviewing
  • Testing
• Requirements
  • Kinds
  • Quick Start
  • Glossaries
  • Goals
  • i*
  • Ilities
  • Narratives
  • SCR
  • Tracing
• Specifications
  • Alloy
  • E-R
  • MSCs
  • Statecharts
  • UML
• Java
  • Coding Standards
  • Design Patterns
  • Javadoc
  • JUnit
  • Nested Classes
  • Packages
  • Types
• Web
  • (X)HTML
  • XML Schemas
  • XSLT
  • MathML

Thomas A. Alspaugh

Glossaries and Ontologies

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.

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,

• since vehicle subsumes car (car is a sub-concept of vehicle), every car must be a vehicle, and some vehicles are not cars.
• since wheels are component parts of cars, every car has wheels, and some wheels are parts of cars.
• since cars have license numbers, some license numbers belong to cars, and some vehicles have license numbers
  

  Fig. 2. Ontology diagram — vehicles

• since cars have at most one license number, there is no car that has two license numbers (this seems close but questionable), and there could be a car that has no license number

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.

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?

• Every Toyota Prius is a car; there are no Toyota Priuses that are not cars. Therefore Toyota Prius is a sub-concept of car.
• It is not true that every wheel is a car, or vice-versa, so wheel and car do not have a subsumption relationship. However, every car has wheels as some of its component parts, and both cars and wheels are physical objects, and it is not possible for a wheel to be part of more than one car at the same time. Therefore car and wheel have a whole-part relationship, with wheel being a part of car.
• It is not true that every model year is a car, or vice-versa, so model-year and car do not have a subsumption relationship. Nor does every car have a model year as one of its component parts, because car and model year are very different kinds of concepts. But every car is described by a model year, so model year is a property of car.
• It is not true that every driver is a car, or vice-versa, so driver and car do not have a subsumption relationship. Nor does every car have a driver as one of its component parts, or vice-versa, so driver and car do not have a whole-part relationship. Nor is every car is described by specifying its driver, or vice versa, at least not in general (a particular driver may drive many cars, although not at the same time), so neither driver nor car is a property of the other. However, there is a relationship between a driver and a car, although it is none of the above kinds.
• Car and goal do not appear to have any relationship. It's not necessary to state this specifically (unless a reader might be confused and assume some relationship exists), as most concepts are assumed to be unrelated unless some relationship is stated.

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?

• Toyota Prius is a sub-concept of car. Subsumption relationships do not have cardinalities.
• Car and wheel have a whole-part relationship, with wheel being a part of car. In a whole-part relationship, the cardinality of the whole individual is never stated (it is implied to be 1). It is possible to give a cardinality for the number of parts, however. In this case, we would say that each car has 4 wheels. We might also give separate whole-part relations to determine the four wheels for a particular car, calling them right-front, left-front, etc.
• Model year is a property of car, and car and model-year have an individual-property relationship (an instance of a car has a model year as a property). The cardinality of the individual is never or rarely stated (it is implied to be *). Each car has exactly one model year, however, and this should be stated.
• Driver and car have a relationship that is none of the above kinds. It would be possible to specify cardinalities if these could be determined. A driver drives a car, so it would probably make sense to specify this as a cardinality (each driver can drive at most one car at a time) by labelling the line between the concepts; the cardinalities might be 0..1 drivers drive 0..1 cars (each driver drives either 0 or 1 car at a time, and each car is driven by either 0 or 1 driver at a time). An alternative relationship might be can drive; for this relationship, the cardinalities might be * drivers can drive * cars (a driver can drive any of some unknown but potentially large number of cars, and vice versa).
• Car and goal have no relationship, so it makes no sense to talk about cardinalities for these.

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

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

• thomas · alspaugh @ acm · org
• 
• 2022Mar02We19:29
• Attribution