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

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

  1. a glossary of concepts (as in the voting example)
  2. a sub-concept hierarchy of those concepts
  3. an instance-part hierarchy of those concepts
  4. properties associated with each concept (an instance-property relationship). 
  5. other relationships between concepts
  6. cardinality constraints on relationships, and functions from one concept to another. 

Vehicles. 

  1. concepts vehicle, car, bicycle, wheel, engine, model year, license number, license plate defined in glossary. 
  2. Sub-concept hierarchy includes:  car is a sub-concept of vehicle (so, every car is also by definition a vehicle). 
  3. Instance-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. Cardinality and functions 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. 
Vehicle ontology diagram

Fig. 2.  Ontology diagram — vehicles

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 (see Fig. 2).  A key for ontology diagrams (as we will draw them in this class) is given in Fig. 3. 

ontology key

Fig. 3.  Key to ontology diagrams

There are several terms that seem just about interchangeable with "ontology" in requirements engineering:  "conceptual map", "conceptual graph".  Ontologies show up in studies of databases and have recently become common as a coming underpinning of Web pages. 

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 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 an instance-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 sub-concept and instance-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 sub-concept 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 or function is appropriate, if any, for a relationship

Sub-concept relationships never have cardinalities or functions; they make no sense for this kind of relationship. 

An instance-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 instances for a particular property is important, the relationship should probably not be expressed as a property. 

An instance-part relationship has an implicit function (in one direction).  It is always possible to figure out which T goes with a specific t that is part of it (it's the one that the t is part of) and this should not be also specified as a function. 

Although it makes no sense to specify a function that restricts an instance-part or property relationship, it is possible to have one cardinality at the part end of an instance-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, and can be restricted by functions in either direction. 

Example:  car, Toyota Prius, wheel, model year, driver, goal.  What kinds of cardinalities and functions 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. Sub-concept 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, functions, ...) 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. Instance-part hierarchy.  For every concept T whose instances 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 instances of concept T and U
    1. Are there some instances of T and U that are R?  (should be "yes")
  6. Cardinality and functions
    1. (Ask questions that test the specific cardinalities and functions.)

Ontology diagrams are not class diagrams

The concepts, properties, organization, relationships, and functions of an ontology can be partially expressed in a diagram.  This diagram is somewhat similar to a UML class diagram, but also 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 instances of concepts between objects of classes
Both have ways to restrict relationships functions 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. 4.  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. 4). 

  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 sub-concept 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 and functions ("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

Valid XHTML 1.0 Strict
Valid CSS!
2009Nov04We09:53
Thomas A. Alspaugh