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 see http://www.msu.edu/user/mccarth4/ 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.