Last revised 05/20/2010 by A. W. Crapo

Modeling as a science has greatly benefited from the computational capabilities of the Information Age and has steadily evolved over the past several decades. The development of the Object Modeling Technique (OMT) at GE Research (1,2) and its evolution into the Unified Modeling Language (UML) was a significant milestone. No less significant was the work in description logics (DL) and artificial intelligence, which produced the Knowledge Interchange Format (KIF), the Resource Description Framework (RDF), the Web Ontology Language (OWL), conceptual graphs (CG), and Common Logic (CL). More recent work by the Object Management Group (OMG) has produced the Meta-Object Facility (MOF) and its variants, which promise to unify UML, OWL, and any other modeling language or paradigm (OMG’s MOF). This is an exciting time to be involved in modeling!

Common Building Blocks

 UML was born in the software engineering domain. OWL and CL were born in the domain of formal models and logical inference and classification. It is instructive to compare their meta-models. MOF, first and foremost the meta-model of UML, captures four main concepts: 1) classes, 2) associations, 3) datatypes, and 4) packages. OWL models are composed of 1) classes, 2) properties, and 3) instances. The alignment is, however, much closer than it may appear. The MOF architecture has the meta-meta-model or MOF model at layer M3 with UML (for example) at layer M2, an actual UML model at layer M1, and the real-world data at layer M0 (see Figure 1). This M0 real-world data is a software engineer’s version of what an ontologist would call instances.

Figure 1: MOF Layers with Example (after illustration on UML at http://en.wikipedia.org/wiki/Unified_Modeling_Language)

Datatypes exist in OWL as well as in MOF and represent those primitive data constructs that are not unique “instances” of a class. To illustrate, if John has brother Jim and Susan has husband Jim, then (assuming the same Jim) we would have only one instance of Jim in our model and both statements would reference it. However, if John has age 12 years and Susan owns 12 apples, we would not normally say that there is only one number 12 in our model. A datatype allows us to use things like numbers, strings, dates, etc. (XML Schema datatypes) without giving them a unique identifier.

In OWL, concepts (classes, properties, and instances) are identified by a Uniform Resource Identifier (URI) (except for “blank class nodes” which are identified by a system-generated unique identifier for proper local handling). A URI consists of two parts: a namespace and a local name, separated by a “#” symbol. In this way local names are only required to be unique within the namespace. MOF 2 moves in the direction of making identifiers more compatible with OWL by requiring package names to be legal URIs. This makes sense since the concept of a namespace is in many ways similar to the package in MOF. Class names are only required to be unique within the package. Closely related classes will normally be found in the same package just as closely related concepts in OWL will normally be defined in the same namespace. In summary, the basic building blocks of MOF and of OWL are very similar. MOF metamodels of OWL have been constructed under work on the Ontology Definition Metamodel (ODM) (ref OMG ODM). Automatic translation of at least most of UML and OWL models from one to the other is a work in-progress.

Differences between UML and OWL

There are some fundamental differences between UML and OWL (3). They include:

  1. While both UML and OWL are based on sets, the set semantics of UML are not as complete as are those of OWL
  2. In OWL an individual can exist and may have properties independent from membership in any classes. This is particularly an issue when starting from individuals with properties and doing classification to determine to which classes they belong
  3. In UML there is not as much care taken to ensure that the semantics are sufficiently followed to support automatic inference
    1. UML disjointedness requires that disjoint classes have a common super-class, which is not the case in OWL (other than every class is a subclass of owl:Thing)
    2. Modeling set intersection in UML allows an instance of all the super-classes to be omitted from the subclass
    3. There is no UML construct for set complement
  4. UML lacks a formal model theoretic semantics; OCL has neither a formal model theory nor a formal proof theory. This prevents the use of automated reasoners on UML models


  1. Rumbaugh, James , Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen (1991). Object-Oriented Modeling and Design. Prentice Hall. ISBN 0-13-629841-9.
  2. Lorensen, William. Object Oriented Modeling, available on-line at http://marchingcubes.org/index.php/Object_Oriented_Modeling
  3. Ontology Definition Metamodel Version 1.0, available on-line at http://www.omg.org/spec/ODM/1.0/PDF/