ISO/IEC 15944 consists of the following parts under the general title “Information technology – Business Operational View”:
- Part 1: Operational aspects of Open-edi for implementation
- Part 2: Registration of scenarios and their components as business objects
- Part 4: Business transaction scenarios — Accounting and economic ontology
- Part 5: Identification and referencing of requirements of jurisdictional domains as sources of external constraints
- Part 6: Technical introduction to e-Business modelling [Technical Report]
- Part 7: eBusiness vocabulary
- Part 8: Identification of privacy requirements as external constraints on business transactions
- Part 9: Business transaction traceability framework for commitment exchange
- Part 10: IT-enabled coded domains as semantic components in business transactions
- Part 11: Descriptive techniques for foundational modelling in Open-edi
- Part 20: Linking business operational view to functional service view
Purpose and overview
This work is motivated with important ideas from the ISO Open-edi specifications as represented in ISO/IEC 15944-1. In ISO/IEC 15944-1 and in some of its earlier foundational expositions, such as ISO/IEC 14662, there were important concepts defined and interrelated such as business transaction, fundamental activities of a business transaction, commitment, Person, role, scenario, and others. A need for relating all of these concepts in a formal framework for the Open-edi work is apparent.
This is a question of ontology: a formal specification of the concepts that exist in some domain of interest and the relationships that hold them. In this case, the domains of interest are those that encompass Open-edi activities, that is, law, economics, and accounting in an extended sense, not the internal accounting of one particular firm, but the accountabilities of each of the participants in a market-based business transaction.
Ontologies are generally classified as either upper-level ontologies, dealing with generalized phenomena like time, space, and causality, or domain ontologies, dealing with phenomena in a specific field like military operations, manufacturing, medical practice, or business. The economic and accounting ontology being used in electronic business eXtended Markup Language (ebXML), in the UN/CEFACT modelling methodology, and E-Commerce Integration Meta-Framework (ECIMF) work is entitled the Resource-Event-Agent (REA) ontology 1. REA is used here as an ontological framework for specifying the concepts and relationships involved in business transactions and scenarios in the Open-edi sense of those terms. The resulting framework is titled the Open-edi business transaction ontology (OeBTO).
The REA ontology is actually an elementary set of concepts derived from basic definitions in accounting and economics. These concepts are illustrated most simply with a UML class diagram. See Figure 1, which illustrates the simple Resource-Event-Agent structure that gives REA its name. A business transaction or exchange has two REA constellations joined together, noting that the two parties to a simple market transfer expect to receive something of value in return when they trade. For example, a seller, who delivers a product to a buyer, expects a requiting cash payment in return.
Figure 1 Basic economic primitives of the Open-edi ontology.
There are some specific points of synergy between the REA ontology and the ISO Open-edi specifications as represented in ISO/IEC 15944-1.
ISO/IEC 15944-1, 3.9 defines commitment as “the making or accepting of a right, obligation, liability, or responsibility by a Person…”. Commitment is a central concept in REA. Commitments are promises to execute future economic events, for example, to fulfill an order by executing a delivery event.
ISO/IEC 15944-1, 6.1.3, Rule 1 states: “Business transactions require both information exchange and commitment exchange.” REA firmly agrees with and helps give definition to this assertion. Reciprocal commitments are exchanged in REA via economic contracts that govern exchanges, while information exchange is tracked via business events that govern the state transitions of business transaction entities that represent various economic phenomena.
ISO/IEC 15944-1, 6.3.1, Rule 39 states: “Conceptually a business transaction can be considered to be constructed from a set of fundamental activities. They are planning, identification, negotiation, actualization, and post-actualization.” For REA, actualization is the execution of economic events that fulfill commitments. Planning and identification involve business partners with types of economic resources, events, and persons, while negotiation is finalized by an economic contract which is a bundle of commitments. The UN/CEFACT Business Process Group has also defined negotiation protocols that assist in forming commitments. The Open-edi set of activities and the REA economic concepts will help each other tie together all the activities into a cohesive business transaction, and then unite that transaction definition with its related information models.
Finally, with regard to the preliminary agreement between Open-edi and REA, the two major sets of ideas that characterize the Open-edi work, the specification of business transactions and the configuration of scenarios, correspond well at the aggregate level to what the REA ontology calls the accountability infrastructure and the policy infrastructure. A business transaction specifies, in a descriptive sense, actual business events of what has occurred or has been committed to. Conversely, a scenario is more prescriptive: it configures what could be or should be. The realm of both descriptions and prescriptions is important both to Open-edi and REA, and they can work well in developing standards for each.
Definition of Open-edi Business Transaction Ontology (OeBTO)
According to the most widely accepted definition from Tom Gruber, an ontology is a formal, explicit specification of a shared conceptualization. The individual components of this meaning are each worth examining.
- formal = machine-readable
- explicit specification = concepts, properties, relations, constraints, and axioms are explicitly defined
- of a shared = consensus knowledge
- conceptualization = abstract model of some phenomenon in the real world
At present, the REA model is certainly an explicit specification of a shared conceptualization of economic phenomena in the accounting community.
A formal, machine-readable specification is not proposed in this part of ISO/IEC 15944; however, such extensions may follow in other standards work.
This part of ISO/IEC 15944 focuses on integrating the Gruber definition of ontology with a REAbased approach. It does so from an accounting and economic ontology perspective within an Openedi Reference Model context. This is achieved through the introduction of the concept (or construct) of “Open-edi Business Transaction Ontology (OeBTO)”, which is defined as follows:
formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among those concepts.
Use of the “independent” and “trading partner” perspective in the Open-edi ontology work
In normal business use, the naming perspective for the ontological primitives would be that of the entrepreneur or of one of the two trading partners engaged in collaborative commerce. The other trading partner would ordinarily have a mirror-image view. Thus, a sale, a cash receipt, or a resource inflow for a particular entrepreneur would become a purchase, a cash disbursement, or a resource outflow for a corresponding trading partner. From this perspective, business events and their accompanying economic phenomena would be modeled twice, once in the database of each trading partner. However, for Open-edi purposes, or for that matter for any other independent modeling of business collaborations like the Business Requirement View BRV level of the UN/CEFACT modeling methodology, this redundancy is not acceptable because it allows the states of the two representations to become inconsistent. This difference in naming perspective is explained below and illustrated in Figure 2.
Figure 2. Different views of business collaboration.
Figure 2 illustrates three independent value chains for three different enterprises. Each company has a connected network of business processes that takes its initial input of resources (called factor inputs for their production functions) and transforms them via cumulative flows of goods, services, rights, and/or cash into an output for that firm’s downstream customers. For Open-edi collaboration modeling, these internal processes are not relevant until a resource flow crosses enterprise boundaries, as is illustrated for Enterprise #2 which accepts materials from Enterprise #1 and which delivers materials to Enterprise #3 (most probably in both cases for cash payments in return). The two dotted lines with double-headed arrows show these inter-enterprise events.
The independent or collaboration perspective of resource flows is anchored on the view of the eye outside of Enterprise #2. This view sees both exchanges as conceptually similar with flows of materials being requited by flows of funds. Such a perspective is quite different from that of the eye inside of Enterprise #2, which sees the flow between Enterprise #1 and Enterprise #2 as a “purchase” and the flow between Enterprise #2 and Enterprise #3 as a “sale”. Note that an eye inside of Enterprise #1 (not shown on diagram) would have modeled the “purchase” of Enterprise #2 as a “sale” of Enterprise #1, hence the redundancy and the inevitable inconsistency.
Business process modeling can take either of the perspectives shown by the eyes of Figure 2, but the independent perspective is clearly the choice for Open-edi. This leads to the concept of a business collaboration that is illustrated in Figure 3. Most generally, there is a value exchange between two Persons, with one assuming the role of a “buyer” (has money, desires goods, services, and/or rights) and the other assuming the role of a “seller” (has goods, services, and/or rights, desires money). It is also possible to anchor the independent view on time, with one event being the initiating flow and the requiting event being the responding flow. For internal database purposes of corporate accountability, “trading partner perspective” terms are directly derivable from “independent perspective” terms.
Figure 3. Concept of a business collaboration.
The “Open-edi Business Transaction Ontology” (OeBTO)
“Definition of Open-edi Business Transaction Ontology (OeBTO)” and “Use of ‘independent’ and ‘trading partner’ perspective in the Open-edi ontology work” have suggested:
- that the components of the REA domain ontology model are sufficiently well-defined, stable, and well-known that they can clearly serve as the basis for an ontological specification of the concepts involved in collaborative exchanges between trading partners, and
- that the components of that model must be viewed from the outside perspective of a modeler viewing the economic phenomena independently.
Because the primitive economic terms are being adopted here for use with the operational aspects of Open-edi from ISO/IEC 15944-1, the ontology to be defined will be termed the “Open-edi Business Transaction Ontology” (OeBTO). Its definition is
formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among these concepts
From the definitional foundations of both ISO/IEC 15944-1 and the REA model, it follows that the OeBTO will follow these five principles:
- as a business transaction ontology, a distinguishing characteristic of OeBTO is that in addition to information exchange, it incorporates commitment exchange among autonomous Persons
- an OeBTO requires the use of clear and pre-defined rules, principles, and guidelines (see ISO/IEC 15944-1, 5.1)
- an OeBTO is neutral in terms of technology, representation, and application
- the scope of an OeBTO covers all areas of business transactions (public/private, industry sectors, international, regional, etc.)
- the semantics of the concepts represented in an OeBTO are explicitly specified and constrained.
Organization and description of Part 4 of ISO/IEC 15944
Clause 1 and Clause 2 provide scope and normative references for OeBTO. The basic OeBTO definitions are first enumerated in Clause 3, while Clause 4 provides a table of symbols and abbreviations. Clause 5 provides the declarative substance for this part of ISO/IEC 15944, which is a set of UML class diagrams and conceptual explanations that circumscribe the Open-edi Business Transaction Ontology. Clause 6 explains the mechanics of a business transaction state machine, which is the procedural component of an OeBTO, while Clause 7 explains the (internal) constraint component of OeBTO, which is its repository for business rules.
At the end of this part of ISO/IEC 15944 are some helpful Annexes that provide elaboration on the points raised in the main body. Normative Annex A is a consolidated list of all the terms and definitions used in this part of ISO/IEC 15944 in both ISO English and ISO French. The other normative annex is Annex C, which is common to ISO/IEC 15944-2, ISO/IEC 15944-4, ISO/IEC 15944-5, and ISO/IEC 15944-8. Annex B is informative text providing more detailed background information on the REA Model. This part of ISO/IEC 15944 concludes with a bibliography.
Appendix B – REA Ontology
Note: The text of this annex has been adopted from the UN?/CEFACT Simple Guide to the UMM, 2003.
Ontology, according to the most generally accepted e-commerce definition of that word, is a “specification of a conceptualization”. The REA (Resource-Event-Agent) ontology is a specification of the declarative semantics involved in a business process. The theory behind REA came initially from the field of accounting where REA was first introduced, but its components clearly have microeconomic origins with specific ties in many instances to the use of economic definitions in the practice of building enterprise-wide information systems. In UN/CEFACT work, all of the REA ontology definitions are applied to the collaborative space between enterprises where market exchanges occur in closely synchronized fashion among two or more trading partners.
In its most simple form without a high degree of precision, REA can be portrayed as a UML class diagram with associations and generalizations relating the object classes. The intent of this annex is to display REA simply and to explain its basic rationale. To do so, the annex will use a set of three figures (Figures B.1, B.2 and B.3), plus two summary figures. The most advanced of the UML diagrams (Figure B.3) is a good overall guide to the BRV semantics, given both here and in the Unified Modeling Methodology (UMM) of UN/CEFACT.
B.2 The Basic REA Ontology
The Basic REA model was first published in the July 1982 issue of The Accounting Review, the most prominent, most reliable, and most tightly controlled outlet for theoretical-based accounting work in the world. Its basic premises have withstood all theoretical challenges in the 20 years since, and its components are used extensively in a variety of educational, practical, and theoretical contexts. The REA model work was given the first (and thus far only) Seminal Contribution to the Accounting Information Systems Literature Award in 1996 by the American Accounting Association (AAA), and in 2003, its use as a model for teaching enterprise information systems was awarded the Innovation in Accounting Education Award, also from the AAA. There are a number of textbooks in worldwide use that feature REA as a pattern-oriented teaching framework.
Figure B.1 illustrates the basic class structure of REA ontology. The left-to-right configuration of economic Resources, economic Events, and economic Agents (renamed in UMM as “Partner”) in a typical business collaboration pattern is the source of the model’s REA name.
A successful business collaboration involves first and foremost two types of Economic Events, each of which details the Economic Resources involved in an exchange between two Trading Partners. For example, a Supplier (Trading Partner) transfers ownership of an Automobile (Economic Resource) to a Customer (Trading Partner) in return for which (duality association) the Customer will provide Money (Economic Resource) to the Supplier. There are two mirror-image instantiations of the object pattern shown in Figure B.1 where one transfer represents the legal or economic consideration given for the other.
Figure B.1. Basic REA ontology.
The declarative semantics shown here are central to all trading relationships. Economic Resources are objects that have value and are under the control of one of the two collaborative agents. Trading partners always expect requited transfers of resources when they engage in commerce. Hence, Figure B.1 is a pattern for all economic exchanges.
B.3 Adding Commitments to the Basic Exchange Ontology
In electronic commerce, the actual trading phase of an exchange is accommodated well by the object structure shown above in Figure B.1. However, trading partners in long-term relationships need more trusted and predictable structures where both parties contract for their exchange behavior in advance. The REA ontology accommodates this expansion with the addition of the classes shown as Economic Commitments, Economic Contract, and Agreement in Figure B.2.
Figure B.2. REA ontology with Commitments.
A Commitment is a promise by a Trading Partner to initiate an Economic Event in the future. Performing the Economic Events fulfills that Commitment. Commitments should always be reciprocated by the other Trading Partner who commits to initiate another type of Economic Event in return. An Economic Contract is a bundle of reciprocating commitments between Trading Partners who bind themselves to one or more economic exchanges in the future. A Contract is a subtype of the more general object class called Agreement, and Agreements can regulate other Agreements.
In the case of the automobile-for-money exchanges discussed in the prior section, Commitments would involve the Customer agreeing to accept delivery of an Automobile on a certain date in return for which he or she would be contractually obligated to making a series of Cash payments to the Supplier for that purchase.
In the bottom part of Figure B.2, two additional objects of the REA ontology are illustrated: Claims and Locations.
- Materialization of Claims is sometimes needed when Trading Partners insist on documentation of partially completed exchanges (for example, when a Customer takes possession of an Automobile before paying for it in full). If needed, Claims can be instantiated by documents like invoices or by accounting artifacts like accounts-receivable. Their inclusion here is more a matter of business custom than ontological completeness.
- A Location is another object that is sometimes needed to fill out the specification for a full economic transfer. Locations simply identify the place where Economic Events take place.
The economic and ontological foundations of commitments are explained more completely by Geerts and McCarthy.
Adding Types to the Basic REA Exchange Ontology
The object pattern portrayed in Figure B.2 above is primarily descriptive in the sense that it illustrates what actually occurred in an economic exchange or what has been committed to. In the UMM, these descriptive components have been augmented by prescriptive components that allow the specification of control policies or collaboration patterns. These prescriptive components are enabled by the inclusion of type images of the basic descriptive objects. The class diagram of Figure B.3 shows these additions.
The addition of Types to Figure B.3 proceeds in two stages:
- The three base descriptive classes – Economic Resource, Economic Event, and Partner (Economic Agent) – have classes added for their types. These new classes are connected to the descriptive objects by typifies associations. An example of a Resource Type could be different models of automobiles. An example of Economic Event Type could be the classes of retail transaction and wholesale transactions, each with different pricing structures. An example of Partner Type could be different classes of employees, each type with separate training requirements. Additionally, the class Location is also typified. An example of Location Type might be different types of loading docks with different sizes and stress capability levels.
- The full design of the Economic Commitment would necessitate associations between the commitment and each of the new type-level objects. These are illustrated in the figure with specifies associations.
Figure B.3. REA Ontology with Types.
In addition to these two groups of additions, there are other REA associations in the UMM that are not illustrated here in an effort to minimize diagram complexity. These include:
- Contract – responsible – Partner
- Economic Commitment – destination – Location
- Partner – participates – Agreement
- Partner – participates – Economic Commitment
- Economic Commitment – reserves – Economic Resource
And finally with regard to Figure B.3, the partial integration of the elements of the REA ontology with the components of the UMM business collaboration framework is illustrated by showing the class for Business Collaboration (with dotted lines) and some of its associations with REA classes (also illustrated with dotted lines). Outside of its use with the UMM and the attendant specifications, the REA ontology has a three-level architecture that is explained by Geerts and McCarthy. In the UMM, this three-level architecture is effected by the integration of REA components within the business collaboration framework and by the connection of the Business Requirements View (BRV) to the Business Domain View (BDV) above it and the Business Transactions View (BTV) below it.
The Suitability of the REA Ontology within the Open-edi Model
The REA ontology is well known and well used throughout the field of accounting and to a lesser extent throughout the field of enterprise computing in general. It is the best example of a business domain ontology in existence today, and its measures well against the most commonly cited “ontology quality” criteria as proposed by Gomez-Perez. Her functional criteria and the REA explanation of their applicability are portrayed in Figure B.4. REA and Open-edi also fit very well together, as do REA and the Business Requirements View of the UN/CEFACT meta-model. Figure B.5 illustrates how these three systems correspond to each other on some very important points of emphasis. Continuing harmonization work with both the business process group and the core components group of UN/CEFACT is emphasizing these principles of commonality.
|Functional Criteria||REA Explanation|
|Does it express the consensus knowledge of a community of people?||The original paper and all extensions since have been published in high quality refereed journals (The Accounting Review, IEEE Intelligent Systems, etc.) where its components are open to constant review and criticism. In 1996, the original paper was given the first Seminal Contribution to the Accounting Information Systems Literature Award by the American Accounting Association. The Work was most recently awarded the 2003 Innovations in Accounting Education Award by the AAA.|
|Do people use it as a reference of precisely defined terms?||The three leading textbooks on accounting systems analysis and design all use REA extensively to define system primitives and to explain modeling of accounting phenomena.|
|Is the language used expressive enough for people to say what they want to say?||The REA primitives may be used to model any of the economic dealings of an enterprise. The actual chain of entrepreneurial logic might itself be hard to explicate in a minority of cases (why for instance do firms support public charities or why is training important for employees?), but once those links are made at some level of granularity, REA primitives are able to document them.|
|Is it stable?||The original paper was published in the top accounting journal in the world (The Accounting Review) in 1982. No substantive criticisms of its features have been published in the intervening 20 years.|
|Can it be used to solve a variety of different sorts of problems or as a starting point to construct multiple sorts of applications?||REA can be used to model and design the accounting components of software systems. It has also been used to model external business processes or business collaborations for ebXML and TMWG of UN/CEFACT. It has also been used to model inter-firm phenomena such as supply chains and to analyze the efficacy of a variety of enterprise software systems. Moreover, this documentation can be expressed at multiple levels of granularity, ranging from high level value chains and supply chains all the way down to the level of workflow tasks The original model covered both inter- and intraenterprise transactions, but its use can be specialized for either case.|
Figure B.4. Ontology criteria and the REA Ontology.
|Overall Concept||ISO Open-edi||REA Ontology||UN/CEFACT|
|Emphasis on “economic value” as foundation for business process and business collaboration definitions||A business transaction pertains to the exchange of something of value||Involves requited economic events wherein one economic resource –which is something of value under the control of an enterprise – is exchanged for another economic resource||A business collaboration is an activity where one thing of measurable value is created, either as a service performed or as a product created|
|Designated “actors” or agents who participate in the economic activities within or between business enterprises||Person is a legal or human entity having the ability to make commitments and to fulfill resulting obligations, and to be held accountable for those obligations||Economic Agents include persons and agencies who participate in the economic events of the enterprise||Partner is an actor in a business collaboration|
|The ability to make and impart information about “commitments” as a critical component of e-commerce||A key property of a business transaction is that it involves commitment exchange among persons||A commitment is an agreement to execute an economic event in a well-defined future that will result in either an increase of resources or a decrease of resources||A commitment is an obligation to perform an economic event (that is, transfer ownership of a specified quantity of a specified resource type) at some future point in time|
|Preestablished patterns for different classes of e-commerce collaboration||An Open-edi Scenario is a formal specification of a class of business transactions having the same business goal||A scenario is a configuration of event types, resource types, commitment types, and agent types aggregated together||Declarative Collaboration Patterns are being developed based on the BRV components of the UMM metamodel|
Figure B.5. Correspondence of ISO, REA, and UN/CEFACT.
- Elements of the REA ontology as they are used in other standards work are explained in Annex B ↩