ISO/IEC 15944-4 – The declarative component of an OeBTO- 20071101

An ontology has a declarative component – which specifies the categories into which collaboration data exchanged among Persons in a business transaction may be slotted; a procedural component – which specifies how that data is to be used in deriving conclusions; and a constraint component – which specifies the business rules for both data and procedures.

Primitive and Derived Data Classes

Persons and Economic Resources

One of the most fundamental ideas in Open-edi is the category of Person as an entity recognized as having legal rights and duties, able to make commitments, and fulfill resulting obligations. Based on applicable external constraints, a Person can be decomposed into three separate subtypes, namely, “individual”, “organization”, and “public administration” 1. These subtypes are illustrated in the UML class diagram of Figure 1.

In this part of ISO/IEC 15944, the focus is on the OeBTO from an internal constraints perspective only 2. However, users of this part of ISO/IEC 15944 should note that where and whenever Person is utilized, it covers the three sub-types of individual, organization, and public administration.

Subtypes of Person based on External Constraints

Figure 1. Subtypes of Person based on External Constraints.

Rule 1:

Irrespective of the use of any particular information technology and related devices, Persons are the only entities which are legally recognized as able to make commitments, agree to the rights and obligations entered into, can be held accountable for their actions, etc., i.e. Persons are the only entities able to participate in a business transaction and able to make commitments for exchanges of value 3.

Persons are the entities who drive the economic exchanges forward in Open-edi collaborations. Ontologically and normatively, they are considered as homo economicus in the classical microeconomic sense; that is, they are parties interested in commercial activity as a means of maximizing utility.

Besides Person, a second very important notion in the OeBTO is the concept of an Economic Resource which is something of value under the control of a Person. These two fundamental categories appear on the left of Figure 2, connected by an economic control relationship which indicates that the Person either owns the resource or is otherwise able to derive economic value (utility) from it.

Person and Economic Resource as the Basis for Exchange

Figure 2. Person and Economic Resource as the Basis for Exchange.

Onto the right side of Figure 2 (inside the dotted lines) is now added an additional Person and economic resource association, thus setting the stage for a possible exchange where both parties might view control of the other Person’s resource as a means of deriving higher utility than present circumstances render. This “value exchange” as it is titled in the collaboration space (Figure 3 of previous post) is the basis for what Open-edi calls a business transaction between the two Persons.

Rule 2:

An Open-edi Business Transaction is an economic exchange occasioned by the presence of two

Persons as trading partners, each possessing a resource of value desirable to the other party. These Persons shall be autonomous parties with competing economic interests, able to commit to a requited exchange with the other Person.

The Open-edi Business Transaction Ontology does not construct exhaustive classification hierarchies for the primitive classes of Person and economic resource, but it does provide a limited taxonomy for both. The hierarchical decomposition of both of these ontology items beyond 2-3 levels becomes very dependent upon the context of industry structure. Particular de-compositions beyond the second or third level may be joined to the minimum classification structures illustrated here to give more detailed taxonomies for a particular industry domain.

In addition to being classified on identity, Persons may also be classified on the basis of their roles, which are the abstract specification of the functions they perform in business transactions. This functional decomposition through three levels is illustrated in the UML class diagram of Figure 3 and explained below.

  • Partner which itself further specializes to Buyer (has money, desires goods) and Seller (has goods, desires money).
  • Regulator which represents Persons who impose external constraints on Business Transactions.
  • Third Party which specializes to a number of other classes such as Escrow, Guarantor, Mediator, and
  • Agent which is a special sub-type in Open-edi that can act for any other Person in a clearly specified capacity, most commonly for a buyer or a seller.

Subtypes of Person based on Roles in a Business Transaction

Figure 3. Subtypes of Person based on Roles in a Business Transaction.

When fully-specified business transactions occur, Persons are able to play roles as indicated by the different sub-typing shown in Figure 3. Again, this taxonomy could be extended with industry-specific specializations of these role levels 4.

Figure 4 illustrates some of the possible sub-typing for the other OeBTO primitive – economic resource – illustrated in Figure 2. This taxonomy has a second level derived directly from the text of 15944-1 which categorizes resources as:

  • Goods which are tangible resources to include: o Materials including capital assets (like trucks), basic raw materials and natural resources (like steel or petroleum) plus sub-components of a larger assembled product (like seats for an automobile).
    • Real Estate like office buildings or warehouses.
    • Funds like money or marketable securities.
  • Services which are the provision of value-adding activities by a provider to a consumer to include:
    • Human Services like temporary workers or consultants. o Transportation Services like packing/picking or actual shipments.
    • Regulatory Services such as the right to import/export or the right to do business in a certain segment or area.
    • Warranty Services such as the automatic provision of replacement goods under faulty judgments.
    • Insurance Services such as guaranteed payment under exigent circumstances.
    • Rights which are intangible resources to include examples like Intellectual Products (IPR) and Rightsof-way 5.

ISO 15944-4 Figure 7 Subtypes -possible- for Economic Resource

Figure 4. Subtypes (possible) for Economic Resource.

Rule 3:

Economic Resources may be classified as goods, rights, or services. Particular industry level classifications can further specialize this first level of decomposition.

Figure 4 also shows a recursive association that is especially important in ontological terms because it reflects an important aspect of economic reality – that economic resources often have component structures. This means that their value is often derived from an assemblage of other resources.  For a product example, those components could be the physical material, its advertised cache, its delivered-to-the-door-status, and its warranty.

Rule 4:

Economic Resources in the vast majority of trading cases will have component structures that can be identified and treated differentially in economic exchanges.

As an example of the logic of Rule 4, example goods that are termed free-on-board at source (FOB source) would be missing a delivery component that free-on-board destination (FOB destination) would have included.

In Open-edi, a business transaction involves an economic exchange of resources between Persons with competing economic interests, each attempting to maximize his or her own economic utility. As portrayed in 15944-1 and shown in Figure 5, there are two additional fundamental elements of a Business Transaction Model besides PERSON (discussed amply above). The first of these is the DATA involved in the transaction, and the ontological categories for capturing that data will be the topic for the rest of this Clause 5. The other fundamental element is the PROCESS involved in a business transaction and that will be the main topic for the following Clause 6. Clause 7 illustrates the constraint component where the business rules concerning both data and processes are enumerated.

Fundamental parts of a business transaction

Figure 5. Fundamental parts of a business transaction.

Normative Data Categories for a Business Transaction involving an Economic Exchange: Resources, Events, and Persons plus their fundamental Relationships

The UML class diagram of Figure 6 illustrates the high level semantic view of the essentials of an economic exchange. In Open-edi, the full details of this exchange are realized within the scope of a single business transaction as trading partners identify each other, negotiate commitments, and engage in the actual exchange of resources with value.

As a starting point for ontological definition, this collaboration space diagram concentrates on the object answers to four fundamental questions:

  • Who is involved in the collaboration (Persons)?
  • What is being exchanged in the collaboration (Economic Resources)?
  • When (and under what trading conditions) do the components of the exchange occur (Economic Events)?
  • Why are the trading partners engaged in the collaboration (duality relationships between resource flows)?

The normative infrastructure of the Open-edi Business Transaction Ontology (OeBTO) encompasses these essential question components, as explained in Addition of Business Event to Basic Exchange Pattern below. Extension of the OeBTO into Types below illustrates the ontological components that result from typifying the OeBTO normative infrastructure, while Locations and Claims below deals with the non-normative extensions of claims and business locations. Adding Commitments to Economic Exchanges below discusses the elaborate commitment structures of the OeBTO, and Business Transactions with Contracts below accounts for the extended ontology objects of scenarios and markets.

Figure 6 illustrates the basic economic primitives of OeBTO in a UML class diagram. An actual value exchange in the collaboration space of Open-edi between a buyer and a seller would involve two instances of this object pattern. That is, there would a resource-event-person pattern instance for an initial resource transfer from one partner to the other; this would then be followed by a connected (with duality associations) resource-event-person pattern instance for a requiting resource transfer. A full example of this is shown in Figure 7 with a delivery of product followed by a payment of cash. In very general terms, a full economic exchange of value in collaboration space is defined as a Business Transaction in the Open-edi ontology. It is important to remember that Bilateral Transactions between a buyer and a seller constitute the basic collaborative unit in Open-edi. These bilateral transactions may be aggregated to Mediated Transactions involving more than two Persons.

Basic exchange primitives of the Open-edi Ontology

Figure 6. Basic exchange primitives of the Open-edi Ontology.

Exchange of value in collaboration space involves two symmetrical Resource-Event-Agent clusters

Figure 7. Exchange of value in collaboration space involves two symmetrical Resource-Event-Agent clusters.

Entity Definitions:

  1. A Person is a natural or legal person unit empowered to control the flow of economic resources (including his or her own labor) by engaging in economic events. Persons are also empowered to make commitments or promises to execute resource flows in the future. The Person class may also include persons who are responsible for subordinates’ participation in economic events. A subset of Person is Partner; partners are Persons who play the leading roles in business transactions as sellers and buyers (or alternatively, as producers and consumers of services).
  2. An Economic Resource is a scarce good, right, or service that possesses utility (economic value) and that is presently under the identifiable control of a particular Person.
  3. An Economic Event most simply is an inflow or outflow of an economic resource. Economic events reflect changes in economic resources resulting from exchanges, conversions, or transportation.

Relationship Definitions:

  1. A resource-flow relationship is an association between an economic resource and an economic event. From the independent perspective, resource-flow instances are matched in bi-directional fashion with each party both giving and taking in the same exchange.
  2. A participates relationship is an association between a Person and an economic event. Economic events normally have two participates relationships with independent parties who have competing economic interests (that is, they are said to have an arm’s length relationship with each other). One of these is specialized on the class diagram of Figure 6 as “from” and the other as “to”, indicating again the independent perspective of collaboration.
  3. A duality relationship is an association between two (or more) economic events where one is the economic or legal consideration for the other in an economic exchange. Dualities are needed for every binary component of mediated transactions.
  4. A custody relationship is an association between a Person and an economic resource where physical control or access to physical control possession is indicated.
  5. Responsibility is a relationship between (among) two or more Persons. These responsibility associations indicate hierarchical orderings within an enterprise that are necessarily revealed to trading partners in a collaboration model.

Rule 5:

The minimum normative constellation of business transaction entities needed for a valid business transaction includes Economic Resources, Economic Events, and Persons plus their exchange relationships (resource-flow, duality, and participates).

Rule 6:

Custody and responsibility relationships are not required for a valid economic exchange, but they provide critical additional data to the basic exchange template.

Addition of Business Event to Basic Exchange Pattern:

In Figure 8, the primitive Business Event has been added to the basic OeBT ontology pattern in a UML class diagram. A business event is an occurrence in time in collaboration space that Persons wish to plan, control, monitor, or evaluate. To bring about the occurrence of an economic event, it is often necessary to perform multiple business events. Additionally, business events may also be aggregates of other, finer-grained business events, so the UML component structure for a business workflow is shown as recursive business events. In a state machine sense where many elements of the OeBTO become business transaction entities (representing business transaction entity types as explained in Clause 6) with defined object states and defined object lifecycles, a business event can be defined more precisely as an occurrence that causes a state change in one or more business transaction entities.

Rule 7:

Business Events can either occur instantaneously or have duration. For a business event that has duration, it will be possible to specify as its components, both starting and finishing events of instantaneous nature.

Addition of Business Event to Basic Business Transaction Pattern

Figure 8. Addition of Business Event to Basic Business Transaction Pattern.

Extension of the OeBTO into Types

Abstract concepts are information structures used to describe the intangible components of actual phenomena. For ontologists, this is an important distinction. In the OeBT ontology, “type images” are used to represent the abstract structure of economic phenomena. For the construction of abstract concepts, the common abstraction mechanism of typification is used.6  This abstraction method is portrayed in Figure 9.

The bottom of Figure 9 represents things that really exist or have actually happened, like a digital product or some real material or an event that has transferred ownership of such resources. In concrete economic terms, this is where accountability for past and near future activities lies. At the top of the figure is where policies are specified in terms of the abstract economic future: things that could be or should happen. Typification works by abstractly specifying the grouped properties of real things, and policies can then be derived by associating those abstract entities.

In the UML class diagram of Figure 10, three of the economic primitives defined previously (Economic Resource, Economic Event, and Person), are typified to produce their abstract specification classes shown at the top of the figure (Economic Resource Type, Economic Event Type, and Economic Role).

Abstract specification with typification

Figure 9. Abstract specification with typification.

When type images are connected with each other as illustrated in the top constellation of Figure 10, policy artifacts often emerge, such as the association between an Economic Event Type (for example, large amount sales) and an Economic Role (such as the managerial position needed to authorize such a class of transactions). This kind of abstract specification is especially important to the pre-actualization components (planning, identification, and negotiation) of an Open-edi business transaction. For example, parties often specify in advance the types of goods they desire to be shipped under different delivery categories by different types of shipping agencies. Typification is strongly linked to the concept of Open-edi Scenarios which are formal specifications of particular classes of business transactions designed for reusability. As discussed in Clause 6, connected type images also result many times in control artifacts such as the rules embodied in internal and external Open-edi constraints. Such constraints supply pre- and post-conditions on state machine transitions.

Type connections for policy and planning

Figure 10. Type connections for policy and planning.

Typification is a non-normative extension of the components of a basic economic exchange. Connecting typified entities specifies the abstract rules or business policies under which business transactions occur.

Locations and Claims

The UML class diagram of Figure 11 illustrates two non-normative additions to the basic Open-edi ontological framework.

  1. A Business Location designates the site where an economic event occurs if such information is needed. Locations also indicate the targeted delivery points for Economic Commitments. Location Types indicate grouped instances like an approved kind of delivery warehouse or an acceptable medical facility.
  2. An Economic Claim is an optional materialization of a temporal imbalance in a duality relationship where an economic event has occurred without its requited correspondence to another economic event. An initial economic event materializes the claim, while the requiting economic event settles it.

Addition of Business Location and Economic Claim

Figure 11. Addition of Business Location and Economic Claim.

Adding Commitments to Economic Exchanges

In the Open-edi ontology, a business transaction pertains to the exchange of something of value as illustrated in the delivery-payment example of Figure 10. An additional key property of an Open-edi business transaction is that it involves commitment exchange as illustrated in Figure 12. In economic terms however, commitments do not occur in isolation because partners simply do not agree to value exchanges without reciprocation. Commitments are bundled in Economic Contracts between trading partners where, for example, a commitment to deliver some product is reciprocated by a commitment to pay cash.

Contract as a Bundle of Commitments

Figure 12. Contract as a Bundle of Commitments.

Rule 9:

Economic commitments are fulfilled by economic events; these commitments are the promised analog of economic events which are connected by duality relationships. Thus, commitments also occur in reciprocal pairs where the promise of one party is requited by the promise of the other.

In Figure 13, the ex ante nature of commitments is illustrated further. At a minimum, an Open-edi economic commitment should specify the type of economic resource expected in the fulfilling economic event. For example, a catalogue order chooses from a product list for delivery. Additionally, the economic commitment often will specify:

  1. the type of event to fulfill it (such as an expedited delivery or a purchase under wholesale pricing), and
  2. the business roles needed in the eventual exchange (such as a buyer, a seller, a seller agent, and a third-party escrow).

Economic commitments may less commonly specify types of locations, like an approved class of warehouse.

 Abstract specification of Commitments

Figure 13.  Abstract specification of Commitments.

Business Transactions with Contracts

The UML class diagram of Figure 14 formally adds Economic Commitment structures to the basic notion of an economic exchange. As mentioned previously, commitment is one of the defining features of Open-edi, so these structures are extremely important ontological components.

  1. An Economic Commitment is a promise to execute an Economic Event at some point in the future. The specification of an Economic Commitment may involve relationships with four type-level classes: Economic Resource Type, Location Type, Economic Event Type, and Economic Role. Economic Commitments may also have relationships with Economic Resource (reserves), Person (participate), and Business Location (target).
  2. A fulfillment relationship is an association between an Economic Commitment and the Economic Event that executes that commitment.
  3. A reciprocal relationship is an association between Economic Commitments that each in turn individually fulfills compensating economic events.
  4. An Economic Contract is a bundle of reciprocating commitments wherein two Parties agree to a future schedule of exchanges with compensating economic events. An Agreement is similar to an economic contract, but it is not legally enforceable.
  5. An economic bundle relationship is an association between an Economic Contract and its pair of reciprocal Economic Commitments.

Business Transaction Model with Bundled Commitments

Figure 14. Business Transaction Model with Bundled Commitments.

Rule 10:

An Economic Contract is a reification of the reciprocal relationship among groups of Economic Commitments. When the paired commitments have simple structures and there are no legal needs for a formal agreement, the Economic Contract entity becomes optional.

Figure 15 illustrates the full addition of the “commitments to type specification” by combining Figures 13 and 14. Additionally, it extends the concept of a Bilateral Transaction to that of a Mediated Transaction by including the previously-defined Third Party subtype of Person as an essential ingredient of mediated collaborations. Figure 15 also indicates the essential roles of Regulators who are Persons who constrain business transactions.

Collaboration with Commitment structures

Figure 15. Collaboration with Commitment structures.

Rule 11:

A Bilateral Business Transaction includes just the two basic kinds of Partner: the Buyer and the Seller (or an Agent for one or both). Mediated Business Collaborations involve the participation of a Third Party like a Guarantor or a Notary.

Rule 12:

All Open-edi business transactions, which include the modeling of external constraints in addition to internal constraints only, are subject to the participation of a Regulator – a Person with the authority to prescribe external constraints which serve as principles or rules governing the behavior of other types of participants in a business transaction.

Typifying Agreements and Business Transactions

Figure 16 and Figure 17 illustrate typification of Economic Agreements and Business Transactions.

  1. All Business Transactions are set in both Defined Markets and Undefined Markets, both of which are overseen by various Jurisdictional Domains.
  2. Business Transactions may be classified into different kinds of Open-edi Scenarios such as the 2x2x2 (overall giving eight combinations) factoring shown in the cloud at the bottom of Figure 16. 7.

An Agreement can be decomposed into classes like Leases/Rentals, Service Agreements, Consignments, and Purchases. Agreements have Pricing Methods like reverse auctions, open and closed bids, and individual quotes. These methods can in turn be typified into classes (Pricing) like bid, auction, or matching. These are all illustrated in Figure 17.

The modeling specifications illustrated in Figure 1 through Figure 17 give specific conceptual definition to many of the Open-edi Business Transaction terms used in ISO/IEC 15944-1. In the following clause, the behavioral use of these components is explained with explicit reference to the Open-edi notion of business transaction phases. According to ISO/IEC 15944-1, a business transaction proceeds through the stages of planning, identification, negotiation, actualization, and post-actualization, and an ontologically-based state machine model of this progress is explained there.

Addition of markets and scenarios for Business Transactions

Figure 16. Addition of markets and scenarios for Business Transactions.

Agreement Types with Pricing Methods

Figure 17. Agreement Types with Pricing Methods.

Previous: ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Terms and definitions – 20071101
Next: ISO/IEC 15944-4 – The procedural component of an OeBTO – 20071101

  1.   See further in ISO/IEC 15944-1:2002, 6.2 “Rules governing Person” and in particular, 6.2.7 “Person and external contraints: individual, organization and public administration.”
  2.   With respect to incorporating external constraints, see further ISO/IEC 15944-5:2006; in particular, see 5.2.2 “Collaboration space — internal constraints only” and 5.2.3 “Collaboration space — the role of ‘regulator’ representing “external contraints”, and Annex G.
  3.  Rule 1 is based on ISO/IEC 15944-1:2002, 6.2, Rule 11.
  4.  Because of this industry specificity, these hierarchical decompositions should be viewed as informative rather than normative. This is especially true of the decomposition of “third party” where industry specificity gives rise to many different types of role names.
  5.  Again as in Figure 3, these hierarchical de-compositions should be viewed as informative rather than normative. This is especially true of the third level decomposition in Figure 4 which is clearly designed as an example enumeration.
  6. For an explanation of typification, see Geerts, GL and McCarthy, WE – Using object templates from the REA Enterprise Information Systems, Journal of Information Systems, 2006
  7. A more complete explanation of this classification scheme for Open-edi Scenarios is given in ISO/IEC 15944-2