ISO/IEC 15994-4 – The procedural 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.

In an operational use of the Open-edi Business Transaction Ontology, the various declarative components specified in Clause 5 – for example all of the classes illustrated in Figure 15 – become defined as Business Transaction Entity Types (BTET). BTETs represent the abstract specification of Business Transaction Entities (BTE), detailing their recommended attributes, their recommended methods, and their recommended life-cycle states. Additionally, a business transaction entity type will usually specify the types of business events that cause a BTE of this type to proceed through its different states as the business transaction itself progresses through its own phases of planning, identification, negotiation, actualization, and post-actualization. A BTE thus is a particular real instance of a business transaction entity type.

Rule 13:

A Business Transaction Entity (BTE) is the computable representation of any real world entity that participates, occurs, or is materialized during a particular business transaction. For procedural materialization of conclusions during the business transaction, the combined use of the BTE attributes, methods, and states may be used to determine its status as a component in an economic exchange.

Relating Ontological Components to the Open-edi Business Transaction Phases

From ISO/IEC 15944-1, the paragraphs below enumerate the five identified phases of an Open-edi Business Transaction. This phase specification is one of the major building blocks of ISO/IEC 15944-1.

  1. Planning: In the Planning Phase, both the buyer and seller are engaged in activities to decide what action to take for acquiring or selling a good, service, and/or right.
  2. Identification: The Identification Phase pertains to all those actions or events whereby data is interchanged among potential buyers and sellers in order to establish a one-to-one linkage.
  3. Negotiation: The Negotiation Phase pertains to all those actions and events involving the exchange of information following the Identification Phase where a potential buyer and seller have:
    1. identified the nature of good(s) and/or service(s) to be provided; and,
    2. identified each other at a level of certainty. The process of negotiation is directed at achieving an explicit, mutually understood, and agreed upon goal of a business collaboration and associated terms and conditions. This may include such things as the detailed specification of the good, service, and/or right, quantity, pricing, after sales servicing, delivery requirements, financing, use of agents and/or third parties, etc.
  4. Actualization: The Actualization Phase pertains to all activities or events necessary for the execution of the results of the negotiation for an actual business transaction. Normally the seller produces or assembles the goods, starts providing the services, prepares and completes the delivery of good, service, and/or right, etc., to the buyer as agreed according to the terms and conditions agreed upon at the termination of the Negotiation Phase. Likewise, the buyer begins the transfer of acceptable equivalent value, usually in money, to the seller providing the good, service, and/or right.
  5. Post-Actualization: The Post-Actualization Phase includes all of the activities or events and associated exchanges of information that occur between the buyer and the seller after the agreed upon good, service, and/or right is deemed to have been delivered. These can be activities pertaining to warranty coverage, service after sales, post-sales financing such as monthly payments or other financial arrangements, consumer complaint handling and redress or some general post-actualization relationships between buyer and seller.

Rule 14:

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.

Figure 18 adds the definition of these Business Transaction Phases to the OeBTO declarative primitives for a bilateral collaboration.

Open-edi Ontology with Business Transaction Phases and Business Events

Figure 18. Open-edi Ontology with Business Transaction Phases and Business Events.

Figure 18 also specifies that these Open-edi business process phases have Business Events as components, illustrating the behavioral progress through each phase as marked by collaborative activities. A Business Event is defined as an occurrence in time that partners to a business transaction wish to monitor or control.  Business events are the fuel that drives a business transaction state machine, as they progress that dynamic representation through its five phases by changing the states of the ontological components illustrated in Figure 18. Additionally, Business Events have component structures as illustrated by the recursive relationships in Figure 18, and this facilitates the modeling of activities in business collaboration space at whatever level of granularity is needed. Business Event components of instant duration can drive the state of a higher-level Business Event with extended duration from start to completion, and that higher level component may then effect a state change in one of the other Business Transaction Entities for a particular transaction.

Figure 19 illustrates the approximate correspondence of the Open-edi Business Transaction phases with the categories of ontological components defined in Clause 5.

ISO Open-edi Phases with Components

Figure 19. ISO Open-edi Phases with Components.

  • Planning and Identification involve business events wherein potential buyers and sellers identify each other by matching on proposed types of resources to be exchanged and their actual trading partners.
  • Negotiation involves business events wherein linked business partners cooperate on the abstract specification of their proposed exchange (its type of resources, events, and roles as stipulated in a contract).
  • Actualization and Post-Actualization involve business events that aggregate to the performance of resource transfers (the actual economic events) between the buyer and seller.

Business Events are the specific activities that mark the explicit states that trading partners expose to each other as they complete an exchange. For example, supplying a quote on a listed product during negotiation may progress an Economic Commitment from status (or state) “unspecified” to “proposed” while simultaneously marking a Resource Type and an Event Type as “specified”. If this Business Event of supplying a quote was followed by a quote acceptance and then a payment terms acceptance, an Economic Contract might move into status “in-force” and then the entire Negotiation Phase might move into state “completed”. This completed negotiation would keep the entire Business Transaction in state “in progress”, whereas an unsuccessful negotiation might have moved the overall Business Transaction into state “aborted” or state “suspended”.

Rule 15:

Business Events are the activities or messages that collaborative business partners use to communicate their progress through a Business Transaction.

Figure 20 portrays the individual phases of a Business Transaction and the targeted object states that would signal to each business partner that a particular phase was now complete.

  1. Planning is complete when both trading partners have formulated an abstract vision of an exchange. This involves moving the entities representing the potential partner and the potential type of resource into “candidate” states.
  2. Identification is complete when the corresponding partners have been identified along with their identified resource types. This establishes a 1-to-1 linkage between the partners concerning a common trading interest.
  3. Negotiation is complete when the abstract specification of economic commitments is done and when all the commitments and a contract move to an “in-force” condition. Generally, this would mean that the entities for the types of resources to be exchanged are in state “specified”. It could also mean that economic specifications are complete for the type of event, the economic roles, and the types of location.
  4. Actualization is complete when the requiting Economic Event entities are both in state “complete”, thus marking the completion of the full exchange.
  5. Post-Actualization is complete when the possible warranty (or similar post-exchange exception condition) component of an Economic Resource is invoked, and the conditions of the exchange reach their final values.

Phases of a Business Transaction and Object States for Completion

Figure 20. Phases of a Business Transaction and Object States for Completion.

Figure 21 illustrates how the declarative ontological components of Open-edi (referred to here as Business Transaction Entity Types) can be augmented to account for state machine mechanics. Each ontological component is envisioned as a possible Business Transaction Entity with a defined Business Transaction Entity Lifecycle consisting of multiple Business Transaction Entity States. The transition to these states is effected by the occurrence of a Business Event.

Business Transaction Entities, Lifecycles, States, and Events

Figure 21. Business Transaction Entities, Lifecycles, States, and Events.

Figure 22 illustrates some example states that could be identified for some of the Open-edi Ontology components defined thus far. In a full ontological specification, all of the business transaction entity types defined in this document would be given fully-enumerated lifecycles of object states (as specified in Figure 21). However, these would change from one business context to another, so the exposition here is limited to these four samples.

Rule 16:

In the OeBTO, all declarative components become candidates for Business Transaction Entities, and each of these in turn will have a defined life cycle of states that will mark its progressive use in the representation of a real economic exchange.

Sample States for Business Transaction Entities

Figure 22. Sample States for Business Transaction Entities.

Figure 23 lists an example set of Business Events involved in a typical instance of a Business Transaction. These 14 Business Events represent a full collaboration between an example buyer and seller, as it proceeds through the Open-edi phases. Again, each Business Event might cause multiple state changes. For example:

  1. The fourth activity – Buyer sends Availability and Price Request to Seller – would cause:
    1. the Economic Resource Type to move into its Specified state, and
    2. the Identification Phase to move into its In-Force state.
  2. The ninth activity – Buyer sends an Order Acceptance to Seller for parts – would cause:
    1. the Economic Resource Types, the Economic Event Types, and the Economic Roles to move into their Specified states, and
    2. the Economic Contract and the Economic Commitment entities to move into their In-Force
  3. The eleventh activity – Buyer sends Receiving Report to Seller when inspected goods are accepted – would cause:
    1. the Economic Event to move into its Completed state, and
    2. the Economic Resource to move into its Transferred

An Example Business Transaction with Business Events Grouped in Phases

Figure 23. An Example Business Transaction with Business Events Grouped in Phases.

A UML state machine diagram is the best formal specification of dynamic object behavior with state changes. Such a specification is illustrated in Figure 24 for the Business Entity Type “Economic Resource Type” as it moves through the example collaboration.

  1. The Economic Resource Type (for example a type of inventory) would become a Candidate when the Publish-Catalog event occurs, moving from its initial undefined state (black dot).
  2. The Send-Availability-And-Price-Request event would then move the inventory into state This same event would move the Identification Phase of the Business Transaction into state In-Service (not shown in Figure 24).
  3. The Return-Availability-And-Price-Result would cause the inventory to become This same event would move the Identification Phase of the Business Transaction into state Complete (not shown).
  4. The Send-Offer event would shift the example inventory into its Proposed state.
  5. The Accept-Offer would cause the Economic Resource Type to become Specified.
  6. And finally, a Send-Shipping-Notice action would cause the resource type to move to an Actualization state (end of object life cycle). 1

State Machine Diagram for Economic Resource Type

Figure 24. State Machine Diagram for Economic Resource Type.

Figure 24 illustrates the progress of a collaboration between two trading partners from the perspective of one Business Transaction Entity as it progresses through its state changes. Figures 24-27 provide a different, but much more comprehensive view of progress through the first three phases (planning, identification, and negotiation) 2 the same business transaction. 3 Each of these figures illustrates a UML activity graph with various business events (such as “Publish-Catalog” at the top right of Figure 25) being performed by either the buying partner (left column) or the selling partner (right column). The collaboration space between the buyer and seller (first illustrated in Figure 3) is where the shared business entity states reside that allow each partner to determine simultaneously what the exact status of the overall business collaboration is. For example in Figure 25, the Publish-Catalog event at the upper right causes the entity Economic Resource Type to move into state Candidate (as earlier illustrated in Figure 24) and the entity Planning Phase to move into state Waiting Start. For purposes of parsimony, Figures 25-28 do not illustrate all of the state changes that would occur in a collaboration, only an illustrative subset. For example, it would commonly be the case that the Completed state of one transaction phase (such as Identification) would cause the following phase (such as Negotiation) to move into a Waiting Start state. However, this state transition is not shown.

Activity Graph 1 for Collaboration

Figure 25. Activity Graph (1) for Collaboration.

Activity Graph 2 for Collaboration

Figure 26. Activity Graph (2) for Collaboration.

Activity Graph 3 for Collaboration

Figure 27. Activity Graph (3) for Collaboration.

Activity Graph 4 for Collaboration

Figure 28. Activity Graph (4) for Collaboration.

To summarize the state machine presentation, it is necessary to understand how the definitions of Clause 5 and Clause 6 work together.

  1. Clause 5 defined the declarative components of the Open-edi ontology. This is a specification of the primitive classes as they model the components of a business transaction. These primitive classes become candidates for Business Transaction Entity Types, and their realization during an actual business collaboration would become Business Transaction Entities.
  2. Clause 6 defined the procedural components of the Open-edi ontology. This illustrated the dynamic mechanics of tracking business collaboration through each of the five Open-edi phases using state machine mechanics. This progress was illustrated with the UML, first from the perspective of a single business transaction entity (state machine diagram) and second from the perspective of the entire workflow (activity graphs).

With partners communicating with each other through shared states of Business Transaction Entities, the actual status of an Open-edi collaboration is exactly determined for each at any point in time.

Rule 17:

In the OeBTO, the declarative components – the Business Transaction Entities – and the procedural components – the shared collaboration space state machines – work in tandem to fully track the activities and progress in an economic exchange. A realization of the OeBTO requires integrated specification of both of these features in the conduct of an Open-edi business transaction.

Previous:  ISO/IEC 15944-4 The declarative component of an OeBTO – 20071101
Next: ISO/IEC 15944-4 The constraint component of an OeBTO – 20071101

  1. In reality, this state machine example for Economic Inventory is slightly more complicated as the individual state changes would need to be tracked through a UML association class between the Economic Inventory Type and the Business Transaction.
  2. The exposition here is limited to these first three phases for parsimony sake. Including the phases of actualization and post-actualization would make the activity documentation twice as long with little gained in explanatory power.
  3. Figures 25-28 are intended to be read consecutively. For example, the start of Figure 26 (illustrated as a  filled-in circle) connects with the finish of Figure 25 (illustrated as a target circle.