KBM Abstract Modelling
Posted on 25 Jul 2020; 07:00 PM IST. Last Updated 27 Jul 2020; 01:00 AM IST.Summary: KBM provides a framework called abstract modelling to utilize a standard body of code or instructions. A detailed description of the framework is provided below.
KBM provides a framework called abstract modelling to utilize a standard body of code or instructions.
A description of the framework is given below.
1) Abstraction elevates an ordinary entity to a higher level, called abstract entity, which is devoid of specificities.
In KBM, an entity is associated with a token called abstract id, at deployment, in the deployment descriptor, which identifies the abstract type of the entity.
2) An abstract type can be sub classed, into a more meaningful entity, by attaching a taxonomy color. For example, an abstract type such as AutoMobile, can be sub classed into Cars and Trucks, as shown below.
AutoMobile.%tax-Car;
where, the taxonomy color "%tax-Car", adds an additional concept to the abstract entity AutoMobile.
Similarly, we could have a Truck subclass as:
AutoMobile.%tax-Truck;
AutoMobileDealer could be sub classed as, used car dealers and show room dealers as:
AutoMobileDealer.%tax-UsedCars
AutoMobileDealer.%tax-ShowRoom
3) An action or interaction can be depicted abstractly using auxiliary colors (or thematic roles) of abstract entities as shown below.
AutoMobileDealer.%aux-agent * AutoMobile.%aux-object;
The above interaction is regarded as a high level abstract rule. This rule could have many specific variations, which are regarded as low level abstract rules. A particular low level variation of the above rule could be given as follows.
AutoMobileDealer.%tax-UsedCars.%aux-agent * AutoMobile.%tax-Car.%aux-object;
4) Abstract interactions could lead to abstract actions, where the action is depicted as a token or a method of a semantic role of the abstract entity. Such interactions are generally referred as actions.
For example, in the interaction of an used car dealer and a car the dealer could play the role of a seller, and execute an action called sale.
AutoMobileDealer.%tax-UsedCarDealer.%aux-agent * AutoMobile.%tax-Car.%aux-object ->
AutoMobileDealer.%tax-UsedCarDealer.SalesRole.$$sale;
The above norms depict a simple framework for describing abstract interactions, and their associated actions. This knowledge by itself, which is described as a set of abstract rules, is called “Interaction Maps”.
Often different vendors having specific implementations would attempt to utilize abstract rules or knowledge, in their implementations. A specific implementation of one vendor could define entities slightly differently from another vendor.
In order to overcome the specificities of entities across vendors, the above scheme may be utilized to convert an interaction of specific entities, with taxonomies, into an abstract interaction, as shown below.
Assume an interaction of an UsedCarDealer and a Car, which are specific entities, as shown below.
UsedCarDealer.%v-cur.%tax-UsedCarDealer * Car.%v-cur.%tax-Car;
The specific entities UsedCarDealer, and Car hold abstract ids in their deployment descriptors as shown below.
UsedCarDealer -> AutoMobileDealer;
Car -> AutoMobile;
When we associate the specific interaction, with an abstract action, such as:
AutoMobileDealer.%aux-agent * AutoMobile.%aux-object;
We could unwind the above process and get the semantic role and method, from the “Interaction Maps”, as shown below.
AutoMobileDealer.%tax-UsedCarDealer.%aux-agent *
AutoMobile.%tax-Car.%aux-object ->
AutoMobileDealer.%tax-UsedCarDealer.SalesRole.$$sale;
Thus far, an abstract rule is invoked, with entities which are vendor specific. The applicable variation of the abstract rule is selected, and the corresponding effect is obtained. Nevertheless, the effect obtained is in abstract terms, and needs to be converted to a vendor specific action.
The mapping of the effect of the abstract action to a vendor specific action is called “process semantics”.
The “process semantics” mapping is specific to each vendor, or more specifically the vendor is required to specify this mapping.
Typically, an abstract effect, such as -
AutoMobileDealer.%tax-UsedCarDealer.SalesRole.$$sale,
is mapped to a KBM rule in the operational model of the vendor, as shown below.
AutoMobileDealer.%tax-UsedCarDealer.SalesRole.$$sale ->
UsedCarDealer.%v-cur.$$sale.%v-default;
The above scheme can be described as shown below.
References:
1. Mechanism and System for Representing and Processing Rules; USPTO. Patent Number: 7,890,928. Date: Feb 15, 2011.
2. Mechanism and System for Representing and Processing Activity Models; USPTO. Patent Number: 9,176,951; Nov 03, 2015.