REA Enterprise Ontology has been initially created by William E.
McCarthy, mainly for modeling of accounting systems. However, it proved so
useful and intuitive for better understanding of business processes that
it became one of the major modeling frameworks for both traditional
enterprises and e-commerce systems. It has been extended to provide
concepts useful for understanding the processing aspects (processes,
recipes) in addition to the economic aspects (economic exchanges). Please
for more information. Some of the REA concepts have been used to model the
Business Requirements in UN/CEFACT Modeling Methodology ("UMM",
formally known as TMWG N090), and the Business Process Analysis Worksheets
in ebXML, and it's use is currently a subject of further study in the
Business Collaboration Patterns and Monitored Commitments team of the
E-Business Transitionary Working Group (eBTWG) - the successor to ebXML.
As far as I know, this is the first attempt to formally define this
ontology, other than in written textual form. This work is a part of the
E-Commerce Integration Meta-Framework project (see
http://www.ecimf.org for more
information). There surely are errors and dubious choices I've made, and
I'd appreciate any comments or corrections to that model.
Some of the disputable issues I encountered, and how I solved them:
- the type images are put as separate concepts, not as abstract
superclasses of the concrete concepts. This allows for greater
flexibility and capturing of more complex phenomena than a simple
specialization would allow. E.g. in this case the instances of
AgreementTypes can be viewed as mutually independent classification
schemas, and a given instance of Agreement may be classified by multiple
AgreementTypes. If the super/subclass relationship were used, it would
be more difficult, and it would require careful definitions of the
mutiple inheritance semantics.
- the EnterpriseScripts consist of recipes, which I represented as a
subset of Activity diagrams.
- one, perhaps strange, aspect of my choice to make the Exchange a
central element of the meta-model, is that Process is related to
Agreement, which in turn consists of Events, and Agents collaborate with
each other as specified by the Recipes, which further can be described
by Tasks. This allows to model multiple collaborations in parallel,
between multiple Agents, but still in support of the same Exchange. The
counterintuitive effect of this choice is that Process is not directly
related to the Tasks.
- stock-flow slot: has been reified, because it needs to have
properties of its own. Stock-flows occur on the level of Events (where
they simply denote the type and amount of resources exchanged), and on
the level of Processes, where they describe a more broader view of the
resource flow between related business processes. Although I didn't
define any explicit relationship between them, the ProcessStockflows are
really aggregates of individual Stockflows in the Exchanges that are
parts of these Processes.
- in this version, Process may consist of many events, as defined by
multiple Agreements. The ProcessStockflows represent the flow of
resources, which cannot be balanced by the inflows and outflows from all
the individual events within that Process.
- in many cases the relationship between concepts is bidirectional,
e.g. Events fullfil Commitments, and Commitments execute Events. In such
cases I added slots only to one of the classes - the one, which
instances are more likely to be created first... Also, the "reciprocal"
and "duality" are symmetric, but since they occur in both
instances, they need to be (somewhat stupidly) defined in both...
- the meaning of "executes" relationship is opposite to what
is found in the original REA papers - however, this is what UN/CEFACT
decided to follow, and IMHO it's more natural.
- I decided to reify the Association relationship between agents, to
allow for its classification (AssociationTypes), and specifically, to
express an important subclass Collaboration - relationship between
Agents participating in the same event. This is needed to relate it to
the dynamic aspects (processes, tasks, etc).
- REA defines several additional constraints (axioms), which I didn't
define in this version. I'd appreciate help with that.
Here's the REA Ontology zip file,
containing the Protege project with ontology and the Car Rental example
from one of the reference documents. Here's the OntoViz
diagram of the main concepts. Here is also
the REA ontology saved as an RDF schema , and
the associated project zipfile.
In parallel, I created a UML model of the central REA concepts. Here's
the main class diagram. For now, these two
models - UML and Protege - are synchronized manually. I'd appreciate
suggestions on how to automate that process.
For comments and further info please contact the author:
Andrzej Bialecki .
Last updated: November 12, 2001.