Positioning and Formalizing the REA Enterprise Ontology

Abstract

Recent Resource, Event, Agent (REA) research has focused on defining and theoretically justifying the ontology's contents. Here, we elaborate on more practical issues related to REA. First, we classify REA and its applications using ontology classification schemes and application frameworks. This analysis clarifies REA's application potential but also reveals weaknesses that may impede its operationalization. Next, we propose a new REA ontology specification that uses a Unified Modeling Language (UML) profile for graphically representing ontologies. This new specification is more complete and precise than previously available specifications, without compromising understandability. It can easily be transformed into a machine-readable representation for automatic processing, which is a prerequisite for the successful application of REA in business modeling, software engineering, knowledge representation, and interoperability creation. The paper ends with a proof of concept application in which a formal Ontology Web Language (OWL) specification of REA is fed into the Proté gé knowledge representation tool and subsequently used for the development of an enterprise schema.

REA2: A unified formalisation of the Resource-Event-Agent ontology

“…The best-known originate from the analysis of REA in the light of Sowa's foundational ontology (Sowa, 2000), with one further study that supplements Sowa's ontology with abstraction mechanisms in REA (Geerts and McCarthy, 2000b, 2005, 2006Sowa, 2000). A number of authors have formalised REA to make it computer-readable, whilst numerous others have tried to find the best definitions for REA concepts that most help the human endeavour in applying REA (Gailly and Geerts, 2013;Gailly, Laurier and Poels, 2008;Ito and Vymětal, 2013;Jaquet, 2006;Laurier and Poels, 2014;McCarthy, Geerts and Gal, 2016a,b;Zdravkovic, Zikra and Ilayperuma, 2011).…”

“…To a minor extent, we will also focus on the design cycle by presenting an artefact -namely the exemplar -that will serve as our proof of concept and allow for a scenario-based analysis of our approach presented shortly. This paper addresses research rigour by refactoring the Prolog 1 code found in Geerts and McCarthy (2000a) with notions from the REA formalisation developed by Gailly, Laurier and Poels (2008). That formalism is stereotyped in turn with OntoUML stereotypes (Guizzardi, 2014) instead of OWL stereotypes, and notions from the original ResourceEvent-Agent (REA) data model published by McCarthy (1982) and Hruby et al's (2006) book on REA.…”

“…This person-bound interpretation of the notion economic event is also related to this paper's contribution as the traditional interpretation of economic event is absolute and should be read as "an event that has the potential of having an economic impact on at least one person". Figure 2 reads the "inflow event" and "outflow event" in the stock-flow axiom as an event playing the increment event role in an inflow and an event playing the decrement event role in an outflow respectively, as inflow and outflow are considered subtypes of stockflow by Gailly, Laurier and Poels (2008). As stated by the stock-flow axiom, the economic event rolemixin has two sub-types.…”

Track and Trace Future, Present, and Past Product and Money Flows with a Resource-Event-Agent Model

“…REA has been used for modeling production processes (Hruby, 2006), supply chain management and e-collaboration systems (Haugen & McCarthy, 2000), enterprise information systems (Batra & Sin, 2008;Dunn, Cherrington, & Hollander, 2005), and management information systems (Church & Smith, 2008). Moreover, previous research has shown that REA can support the integration of business processes across enterprise boundaries (Gailly, Laurier, & Poels, 2008). Therefore, REA cannot be considered an accounting-only ontology.…”

A Simulation Model Articulation of the REA Ontology

“…Apart from accounting systems design, the REA ontology is applied in accounting education, model-driven systems design, supply-chain collaboration and knowledge representation [7].…”