Webinfo For All Topics

KBM Colors

Posted on 25 Jul 2020; 07:00 PM IST. Last Updated 27 Jul 2020; 01:00 AM IST.

Summary: A fundamental problem of computing is to identify entity instances from their respective instance pools. After identification, the entity instances could typically participate in some action. KBM attempts to solve the problem by providing a generic mechanism for representing requirement specifications as concepts. These concepts, which are regarded as colors, can be attached to entity types, to define intended behavior of an object, and yield one or more instances of the entity type. There can be several different types of colors, some of these color types are already predefined, but the end user is free to create new color types of their choice, based on user defined requirements. The predefined colors of KBM are described below with the aid of examples.


Background

Conceptualization has a chequered history, which dates all the way back to Aristotle in 323 BC. The categories of Aristotle are regarded as the first attempt to conceptualize objects. Philosophy viewed conceptualization as a science called Ontology. Broadly, philosophical studies attempted to describe the static world.

Linguistics also dealt with concepts and their representation. The works of Panini Ashtadhyayi in Sanskrit, stand as an exemplary work of art and science. Linguistics viewed conceptualization as auxiliaries (or thematic roles), and their interrelationships. Broadly, linguistic studies attempted to describe the dynamic world.

Linguistics employ a nameless function called lambda, to describe actions and processes. The lambda function takes the verb of the action, and Panini auxiliaries as parameters. The most commonly used Panini auxiliaries in linguistics are -
a) agent    b) object       c) instrument
d) source   e) recipient   f) location

Thus, it is customary to represent an action in linguistics as a function shown below.
lambda(verb, agent, object, instrument, source, recipient, location);

KBM Color Framework
In KBM, an entity (or class) implies an abstraction of a real life object or process, and the term object implies an instance of an entity. An entity type may be regarded as a container for a large set of entity instances (theoretically infinite).

The following figure depicts several entity types, with a few predefined instances, for each entity type.

Figure: Illustration of Entity Types & Instances

A fundamental problem of computing is to identify entity instances from their respective instance pools. After identification, the entity instances could typically participate in some action. KBM attempts to solve the problem by providing a generic mechanism for representing requirement specifications as concepts. These concepts, which are regarded as colors, can be attached to entity types, to define intended behavior of an object, and yield one or more instances of the entity type. Thus, EntityType+color could serve as a mechanism for identifying the required object instance, from a pool of object instances.

A color is depicted in accordance to the following formats.
i) %colorType-colorValue
ii) %colorType-domain:colorValue

There can be several different types of colors, and some of these color types are already predefined, but the end user is free to create new color types of their choice, based on user defined requirements. The predefined color types were derived from several disparate knowledge sources such as linguistics, ontology, computation, referential, processes, and conceptual realms.

The value portion of a color could simply remain as a string (or tag), or could be mapped to a method, rule, or any concept. The mapping process varies based on the realm to which the color belongs.

The predefined color types of KBM are described below.


KBM Colors derived from Linguistic Notions
The following KBM colors were derived from linguistic notions, and broadly represent the state and operation of the entity.

Colors derived from Linguistics Notions
SNo Color Name Prefix Color Description Mapping Scheme
1 Verb %v- Function, operation, or role User defined token
2 Auxiliary Verb %a- Existence or location Navigation path
3 Noun %n- State, event, place, notion etc. User defined token
  
  1. The Verb Color: The verb color identifies the function, operation or role in which an entity is participating.
    The verb color is depicted by the prefix “%v-”.

    For example, WareHouse.%v-primary could identify a primary warehouse, and WareHouse.%v-secondary could identify a secondary warehouse.

    The verb color is the most important color of KBM, and can be applied to both entity types, and fields (attributes) of an entity.
    Incidentally, the verb color need not always imply an English language verb, and could also imply an English language adjective, like “%v-current” or “%v-default”, which are typically abbreviated as "%v-cur" or "%v-def".

    An EntityType+verbColor is specified at deployment time, and is regarded as a subset of EntityType, and represents a (sub) pool of instances of the Entity type.

    If the verb color is specified along with other colors, then the EntityType+verbColor identifies a pool of instances, and the other colours are used to subselect an instance from this pool.

    In the absence of other colors, the verb color defaults to the last instance that was created or referred in the pool. This concept is known as “currency” in the DBTG model.

  2. The Auxiliary Verb: The KBM auxiliary verb color identifies a navigation path from a root object to the object of concern.
    The auxiliary verb color (abbreviated as aux verb) is depicted by the prefix “%a-”.

    For example, consider a “SalesOrder” object, having “billto” and “shipto” addresses as contained objects. These objects may be accessed as:
    SalesOrder.%v-cur.Address.%v-billto;
    SalesOrder.%v-cur.Address.%v-shipto;

    Now, if a mapping is defined as:
    %a- sales -> {navigation-path: SalesOrder.%v-cur, target-type: Address }
    then we could rewrite,
    SalesOrder.%v-cur.Address.%v-billto as
    Address.%v-billto.%a-sales;

    SalesOrder.%v-cur.Address.%v-shipto as
    Address.%v-shipto.%a-sales;

    We could define another mapping such as:
    %a-invoice -> {navigation-path: Invoice.%v-cur, target-type: Address }

    This mapping would allow us to rewrite,
    Invoice.%v-cur.Address.%v-def as
    Address.%v-def.%a-invoice

    Auxiliary verbs described above are in their simplest form, and merely constitute syntactic sugar. When the nodes in a path, contain arrays or vectors, resolving the path becomes more complicated. KBM provides special storage access mechanisms, to cater to this situation. This topic is omitted in this article.

  3. The Noun Color: The noun color depicts the state of an entity, and may be broadly classified as:
    a) user based b) state based

    User based noun colors are assigned by developer and are referred by the prefix “%u-" State based noun colors, are assigned automatically, based on the state of the object, and are referred by the prefix “%n-”.

    Typically, fields which are shared by multiple objects, may opt for state based nouns. For state based noun colors, the developer is required to provide a mapping of state/sub-state of entity and the noun color, which is stored in a table called the “State Noun Mapping Table”.

    As an example, consider the discount field, which may be shared amongst Part, Customer, and Sales Order objects. The Part object holds a field which depicts “Normal” discount or “Promotional” discount. The Customer object holds a field called “Customer” discount, which may be created based on Customer longevity, previous orders etc. The Sales Order object holds “Sales” discount like 5%, on all items purchased between two predefined dates.

    It may be noted that the discount being offered depends on the state of the object. The discounts may have a predefined order (in symbolic form), such as:
    Part_Normal < Sales_Regular < Customer_Normal < Customer_Preferred < Sales_Discounted < Customer_Special < Part_Promotion;

    The problem is to find the lowest/highest applicable discount, among the participating objects. Two important factors of the problem are:
    a) The participation of the objects in an activity of the application is optional. In other words, an application may be unaware of their existence or absence.
    b) The comparison of the discounts is not based on the values contained in the fields, but is based on the predefined order of their symbolic forms.

    The KBM solution to the above problem, is as follows:
    1) Include a field called discount.%v-applied in each of the Part, Customer, and Sales objects.

    2) Provide mappings for state/sub-state of objects to their noun colors.
    Class Name Field Name State Sub State Noun Color Abs.
    Level Num
    Part discount.
    %v-applied    		 Normal Normal Normal 1
    Part discount.
    %v-applied    		 Normal Promotion Promotion 7
    Sales discount.
    %v-applied    		 Normal Discounted Sales 5
    Sales discount.
    %v-applied    		 Normal Regular Sales 2
    Customer discount.
    %v-applied    		 Normal Special Customer 6
    Customer discount.
    %v-applied    		 Normal Preferred Customer 4
    Customer discount.
    %v-applied    		 Normal Normal Customer 3


    A scenario such as “Part not on Promotion (normal), Sales provided a discount, for a Preferred Customer”, would yield a discount based on Sales_Discounted rate. The evaluation of the applicable noun color is as follows.
    Part not on Promotion (normal) => Level 1
    Sales Provided a Discount => Level 5
    Preferred Customer => Level 4

    3) KBM automatically computes the noun colors for the discount.%v-applied field in each of the objects, from the object states, and sorts them on the absolute level num. In the absence of a parametric noun color, the highest absolute level number of the noun is selected as the applicable noun. In the above example, the Sales_Discounted rate, which has a level of 5 would be chosen, as the applicable discount.

    The parametric noun, which may be specified as “%p-nnn”, where “nnn” is the relative index number, provides a relative access to the nouns. Thus, the field with lowest/highest noun may be accessed as:
    discount.%v-applied.%p-0;
    discount.%v-applied.%p-255;

    4) It is possible to override the symbolic ordering, and resort to value based ordering, by specifying a value of zero or -1, for absolute level num for the nouns. The zero implies that a max value is sought, while -1 selects the min value. 

    5) Finally, it may be noted that it is possible to have a hybrid version of symbolic and value based orderings.
     

KBM Colors derived from Ontological Notions
The following KBM colors were derived from ontological notions, and represent existential qualities such as form, category, etc.

Colors derived from Ontological Notions
Color Name Prefix Color Description Mapping Scheme
1 Form %form- Innate form, which is structural or logical or a phase  User defined token, method, or Rule
2  Category %ctg- Acquired quality, relation, or rank User defined token, method, or Rule
3 Model %mod- Structure or relation of constituents with respect to parent User defined token, method, or Rule
4 Capabilities %cap- Applicable interfaces or methods Interfaces
5 Binding %bind- Association to other Entities User defined token, method, or Rule
6 Characteristics %ch- Qualities acquired User defined token, method, or Rule
  
  1. Form Color: An entity could possess several attributes and properties, and some of these could be innate i.e identify self, or acquired at birth. Form color identifies features, relations with other objects, which are innate.

    The form color is depicted by the prefix “%form-”.

    For example, a Car could have features such as compact, sedan, hatchback, which could be represented by the form color as: Car.%form-compact, Car.%form-sedan, Car.%form-hatchback.

    Form color can also be used to describe structural variants of biological substances such as proteins, and multiple views of an information structure.
     
  2. Category Color: The category color is employed to classify an object based on its features, relations with other objects, and ranking against a norm.

    The category color is depicted by the prefix “%ctg-”.

    As an illustration, consider the following two KBM rules:
    SalesOrder.delivery.%v-express =
    SalesOrder.%v-cur.type.%v-delivery ==“Express”;

    SalesOrder.delivery.%v-regular =
    SalesOrder.%v-cur.type.%v-delivery == “Regular”;

    We could map the above KBM rules to colors as described below.
    %ctg-Expdelivery ->
       SalesOrder.delivery.%v-express;

    %ctg-Regdelivery ->
       SalesOrder.delivery.%v-regular ;

    The above mapping would allow us to depict Sales orders with express delivery as:
    SalesOrder.%v-cur.%ctg-Expdelivery

  3. Model Color: The model color is employed to depict the features and structure of the internal components of the object, and relationships of contained entities with respect to the parent.

    The model color is depicted by the prefix “%mod-”.

    The utility of model color can be easily explained by the following simple example from English language processing (NLP).

    “A thirsty crow flew all around the forest [searching for water]”.

    The underlined portion of the sentence can be resolved into KBM colors as shown below.
     
    Sentence Fragment Concept

    KBM Color                  
    Crow primary agent
    thirsty state of the agent noun color    
    flew action performed by the agent verb color
    all around the forest         What part of the forest was covered i.e relationship of parts
    to the whole, or how the action was performed     		 model color  

    The entity Crow may be depicted as:
    Crow.%v-flew.%n-thirsty.%mod-allAroundTheForest;

    As a second example, let us consider the problem of choosing a truck from several trucks, for the delivery of goods (boxes). The capacity of truck is given in terms of max volume and max weight parameters. The boxes too have unit volume and unit weight parameters.

    The max number of boxes that can be loaded in a truck can be calculated as:
    Truck.%v-cur.boxes.%v-max = 
    min(Truck.%v-cur.volume.%v-maxLoad /
           Box.%v-cur.volume.%v-unitLoad, 
           Truck.%v-cur.weight.%v-maxLoad /
           Box.%v-cur.weight.%v-unitLoad);

    If the max number of boxes that can be loaded in the truck is greater than the boxes to be shipped, then we can choose the truck. This can be expressed as a simple KBM rule given below.
    Truck.loading.%v-checkgoodfit = 
       Truck.%v-cur.boxes.%v-max > 
       ShippingBill.%v-cur.boxes.%v-shipped;

    The above rule can be mapped as a model color, as shown below.
    %mod-goodfit -> Truck.loading.%v- checkgoodfit;

    The model color can be applied to the entity as shown below.
    Truck.%v-cur.%mod-goodfit;

  4. Capability Color: The capability color is a complex color, which is employed to depict the tasks, which an entity could perform or participate.

    The capability color is depicted by the prefix “%cap-”.

    For example, a Truck may have a GPS Navigation facility, which may be encoded as: Truck.%v-cur.%cap-gps

    Capabilities of an object may be inferred from its current state or colors, or taxonomy of the object or the interfaces it supports. KBM objects could switch on/off interface methods dynamically, and capability color is the main vehicle for analyzing the current state of the interfaces.

  5. Binding Color: Objects may be bound to other objects, and later an object may be selected based on its relationships to the bound objects, by a rule called binding rule. To facilitate this process, KBM provides a color called “binding color”.

    The binding color is depicted by the prefix “%bind-”.

    Binding comprises of -
    a) operators to bind/unbind a target object, to a source object.
    b) a kbm rule, which evaluates, if any of the targets already bound to the source, could fulfil a specified requirement.
    c) a color called binding color, which is mapped to the kbm rule specified in step (b).

    As an example of binding process of KBM, let us consider the following example.

    In this example, the primary and secondary warehouses of a Sales Order are retrieved and bound to the Sales Order Object, using the KBM bind operator.

    It is assumed that an object called WHLocater is provided, which could retrieve the primary and secondary warehouses, applicable to the Sales Order Object. In the later phase of the example, the Sales Order Details are retrieved in succession, and after the retrieval, a predefined bind color “chkQtyAvbl” of the Sales Order Object is invoked.

    The bind color is mapped to a KBM rule, which checks if the part specified in the sales order detail can be supplied by any of the warehouses bound to the Sales Order object.

    The details of the KBM statements are presented below.
    1) Read a Sales Order object:
    SalesOrder.%v-cur.%proc-read_default;
    KBM stores a reference of this object, in a temporary data set.

    2) Retrieve the primary warehouse, and bind to SalesOrder. It is assumed that WHLocater reference is given, and it has methods to retrieve the primary and secondary WareHouse object references.

    < WHId.%v-sel.@eval_avar >  WHLocater.%v-cur.$$retrievePWH;
    In the above rule, WHLocater retrieves the primary WH, which is then stored in the A-context, by the typecast operator
    < WHId.%v-sel.@eval_avar >.

    SalesOrder.%v-cur  $kb.$op.bind("linkWH", "primary")  WHId.%v-sel;
    The WHId object read is bound to the SalesOrder object using the bind linkage parameters and target reference in an internal cache of SalesOrder object called “binding” cache.

    The secondary warehouse, is retrieved and bound to SalesOrder, in a likewise manner.
    < WHId.%v-sel.@eval_avar >  WHLocater.%v-cur.$$retrieveSWH;

    SalesOrder.%v-cur  $kb.$op.bind("linkWH", "secondary")  WHId.%v-sel;

    3) The Sales order detail objects are read, as shown below.
    SalesOrderDetail.%v-cur.%proc-read_default; 

    Each of these object instances are processed by making use of the warehouse objects bound to the SalesOrder, as shown below.
    SalesOrder.%v-cur.%bind-chkQtyAvbl; 

    4) When the bind color is encountered (during rule translation), KBM would retrieve the associated color map entry.
    A sample configuration of the binding color in the Entity Map file, is shown below.


    It may be noted that the color map entry specifies color prefix and color name and the associated KBM rule to be invoked. In addition, it also specifies the bind linkage name (“linkWH”), parameters (“ ”) and target type (“WHId.%v-sel”).

    KBM then generates code to retrieve and compare the bindings in the “binding” cache of the Sales Order Object (due to the bind operator; please refer to step 2 of this subsection), with the linkage parameters specified for the color.
    For each of the target references, which match the link entry, the reference of the target is stored in a special temporary variable given as:
    $kb.$tgtref.$classname.$colorprefix-colorname
    and the colored rule (shown below in step-5) is invoked.

    5) The colored rule associated with the binding color is as shown below.   

    SalesOrder.%v-chkQtyAvbl =
        WareHouse.%v-cur.%proc-read_bywhid  *
        Part.%v-cur.%proc-read_default             *
        <$Part.qty.%v-avbl.@eval_Avar> $Part.qty.%v-computeAvbl *
        $Part.%a-Order.qty.%v-ordered             *
        $kb.$cmd.$$evalBoolean($3 >= $5)       *
        $kb.$cmd.$$return($6);

    This rule is invoked for each of the warehouses bound to the SalesOrder, and which satisfy the linkage parameters specified for the binding color.

    The first term of the rule on RHS, reads the WareHouse Object using the target reference established by the binding color. (Please refer to step-4).
    The second term reads the Part record, which has a composite key on (partid, whid).
    The third line has two statements (which are numbered as term-4, term-3), and computes the available quantity as:
    $Part.qty.%v-computeAvbl =
        $Part.%a-Master.qty.%v-stock  -
        $Part.%a-Master.qty.%v-hold;
    The fifth term retrieves the quantity ordered from the SalesOrder Detail Object.
    The sixth term evaluates if the output of term-3 ($Part.qty.%v-computeAvbl), is greater than or equal to term-5
    ($Part.%a-Order.qty.%v-ordered).
    The seventh term returns the output of term-6.

    6) After executing the bind color successfully, the code loops back to step-3 to fetch the next Sales Order Detail. If the bind color is unsuccessful it implies that the Sales Order Detail can not be fulfilled by any of the Warehouses. This code related to error processing is omitted.

  6. Characteristics Colors: An object may acquire or lose properties or characteristics dynamically. Typically, these properties are varied and numerous, and are not suitable for inclusion in the object definition. To facilitate this process, KBM provides a color called “characteristics color”.

    The characteristics color is depicted by the prefix “%ch-”.

    Characteristics (in KBM), comprises of -
    a) operators to add/chg/del a characteristic object called target to another object called source. The target is stored in an internal cache table named “characteristics”.
    b) a kbm rule, which evaluates, if any of the targets already bound to the source, could fulfil a specified requirement.
    c) a color called characteristic color, which is mapped to the kbm rule specified in step (b).

    The implementation of characteristics color is very similar to binding color, although the semantics of the two colors differ appreciably.
     

KBM Colors derived from Computational Notions
The following KBM colors are derived from computational notions.

KBM Colors derived from Computational Notions
SNo Color Name Prefix Color Description Mapping Scheme
1 Procedure %proc- Mechanism for persisting entity references  Procedure 
2 DataSet %ds- Storage where references of the entity are stored  Partition of storage
  
  1. Procedure Color: An application performs several backend database operations to retrieve and/or persist objects. Typically these operations are stored as methods of a procedure object.

    The procedure color identifies how objects are read from and written to data bases or in other words, provides a mapping to a method of the procedure object.

    The procedure color, is depicted by the prefix “%proc-”.

    As an example, let us consider the problem of retrieving the ZipCode record from database, based on the zipcode of the current customer.

    Let us assume a term of rule given as:
    ZipCode.%v-cur.%proc-read_custzip;
    where, the procedure color is mapped to a procedure object and method as shown below.
    %proc-read_custzip -> ZipCodeProc.$$init.%v-read_custzip;

    As per the mapping the “init” method of the ZipCodeProc object is invoked using the method color “%v-read_custzip”, which further identifies the formal parameter of the init method as “Customer.%v-cur.curzip”.

    KBM generates code, to create an instance of the procedure object and invokes the “init” method of ZipCodeProc, with the formal parameter “Customer.%v-cur.curzip”.

    When the generated code is invoked, an instance of the ZipCode entity is retrieved, based on the zip code value stored in the Customer record.

  2. Data Set Color: In KBM, a description such as “WareHouse.%v-cur” implies a set of object instances. This set can be further divided into smaller chunks, called “data sets”. The data set color identifies an individual “dataset”, and is specified by the prefix “%ds-”.

    For example, we could split the set of instances identified by “WareHouse.%v-cur”, as “primary” and “secondary” warehouses.

    This would allow us to access object instances as -
    WareHouse.%v-cur.%ds-primary or as
    WareHouse.%v-cur.%ds-secondary

    A data set is created automatically, when an object instance is stored in it.
    To store an object instance in a data set, we could specify the dataset name in “<>” as in:
    WareHouse.%v-cur.%ds-< primary >

    It may be noted that two special datasets called “temp” and “save” are reserved by KBM, for special processing.
     

KBM Colors derived from Referential Notions
The following KBM colours were derived from referential notions.

KBM Colors derived from Referential Notions
SNo Color Name Prefix Color Description Mapping Scheme
1 Local Reference %lref- Storage where attributes are stored  cache 
2 Instance %id- Instance identifier  User defined token
3 Symbolic ID %sym- Symbolic Id of a term of a Rule User defined token
  
  1. Local Reference Color: KBM uses internal caches to store temporal information. To inform KBM, that an attribute of an entity is contained in an internal cache, a special color called local reference color was provided. The local reference color is specified by the prefix “%lref-”.

    As an example, consider the following KBM code fragment.
    SalesOrder.%v-cur.WH.%v-cur.%lref-binding

    As per the normal semantics of KBM, the object WH.%v-cur must exist as a field in SalesOrder.%v-cur. When the object WH.%v-cur is specified with a local reference color, it implies that WH.%v-cur is not a regular field of SalesOrder, but is located in a cache of SalesOrder.%v-cur, which is identified by the “%lref-” color value “binding” .
     
  2. Instance Color: An instance color identifies a specific instance of an object using an id. In KBM, every object instance can be assigned a unique identification or id, and can be retrieved by specifying the id.

    The instance color is depicted by the prefix “%inst-”.

    As an example, let us consider a warehousing application, where a region is catered by a primary warehouse, and two secondary warehouses.

    We could depict the primary and secondary warehouses as :
    Warehouse.%v-primary and Warehouse.%v-secondary.

    The two secondary warehouses can be identified by the instance color as:
    Warehouse.%v-secondary.%inst-sec1,
    Warehouse.%v-secondary.%inst-sec2
    where, the instance colours %inst-sec1, and %inst-sec2 identify the two secondary warehouses.
     
  3. Symbolic Id Color: A complex application may have several rules, and the terms across different rules, may possess the same entity type and verb color. The same entity type and verb color, in different rules, could imply different sources. KBM provides a color called symbolic identification to identify each usage separately.

    The symbolic identification color is depicted by the prefix “%symid-”.
     

KBM Colors derived from Process based Notions
The following KBM colors were derived from process based notions.

KBM Colors derived from Process based Notions
Color Name Prefix Color Description Mapping Scheme
1 Functional %fct- Change in state due to an action  Transformation of functional state 
2  Transformation %tran- Change in colors  Transformation of colors
3 Mode of Processing %mp- set of parameters used for invoking a process User defined token
4 Process Execution %pe- Path of execution Path of execution
5 Disposition %disp- State or end-point reached in an activity  State reached
  
  1. Functional Color: The functional color describes how an entity has transformed due to the actions of a process.

    The functional color is depicted by the prefix "%fct-".

    As an example let us consider the clinical evaluation of flu and cold.



    Path-1: Root; Node 1; Node 2; Exit-1 => flu
    Path-2: Root; Node 1; Node 3; Exit-2 => common cold
    Path-3: Root; Node 4; Node 5; Exit-1 => whooping cough
    Path-4: Root; Node 4; Node 6; Exit-2 => allergy

    If the initial functional color is null, then we could ascribe new functional color based on path traversed as %fct-flu; %fct-cold; %fct-wcough; %fct-allergy.

    In general, the function color is map, which may be given as:
    old functional color * path of activity -> new functional color;

  2. Transformation color: Transformation color identifies how the colours of an entity have transformed, from one pre-defined point to another.

    The transformation color is depicted by the prefix “%tran-”.

    The implementation uses successive transformations in functional color to identify transformations.
     
  3. Mode of Processing Color: The mode of processing color identifies a set of parameters and initial values, which are employed to initiate an activity.

    The mode of processing color is depicted by the prefix “%mp-”.

  4. Process Execution Color: In KBM, high level processes are depicted as graphs. The path of execution of a process identifies a particular usage of the process, and can be mapped to a color called the process execution color.

    The process execution color is depicted by the prefix “%pe-”.

  5. Disposition Color: In KBM, high level processes are depicted as graphs, and typically these graphs have a start node and several end nodes. A process could reach any of the end nodes which are also known as process states.

    Disposition identifies the fate of the process, i.e the end node or state the process reaches, when it is invoked.

    The disposition color is depicted by the prefix “%disp-”.
     

KBM Colors derived from Conceptual Notions
The following KBM colors were derived from conceptual notions.

KBM Colors derived from Conceptual Notions
SNo Color Name Prefix Color Description Mapping Scheme
1 Auxiliary %aux- Thematic role of the entity Panini Auxiliary 
2 Taxonomy %tax- Taxonomy Taxonomy String
  
  1. Auxiliary Color: Linguistics define action in terms of a generic function called the lambda function, which takes several entities as its parameters. The parameters of the lambda function are said to play or possess predefined roles called thematic roles or auxiliaries.

    The most common examples are the subject or agent and object, in English language sentences.

    Thematic roles were formalized in many languages. The oldest of these formalizations is by Panini, in the description of the Sanskrit grammar.

    Panini prescribed 6 auxiliaries for depicting any action, which are shown below.
    a) agent      b) object         c) instrument
    d) source     e) recipient     f) location

    In KBM, an entity instance may be assigned a thematic role, by specifying a color called auxiliary color.

    The auxiliary color is depicted by the prefix “%aux-”.

    The following example demonstrates the auxiliary colors.
    Consider the following natural language statement is chosen.
    “A thirsty crow flew all over the forest, searching for water”.

    In this example, two entities namely Crow, and Water, are connected by the main verb “searching”. The colors of the entities may be identified as shown below.
    i) For the entity Crow, we have,
    thirsty : state, which makes it a noun color
    flew : verb color
    all over the forest : model color

    ii) For the entity Water, we have no colors.

    We could represent the sentence as a lambda function, shown below.
    lambda(verb:searching, Crow.%v-flew.%n-thirsty.%mod-allOverTheForest.%aux-agent, Water.%aux-object);

    We could create a new color type called lambda, and map the color to the above lambda function, as shown below.
    %lambda-searchingForWater =
    lambda(verb:searching, Crow.%aux-agent, Water.%aux-object);

    The lambda color type allows us to rewrite the above sentence as -
    Crow.%v-flew.%n-thirsty.%mod-allOverTheForest.%aux-agent.%lambda-searchingForWater;
    It may be noted that the lambda color identifies the process in which the entity "Crow" participated as an agent.
     
  2. Taxonomy Color: An entity may optionally hold, a token called taxonomy id, which identifies a sub classification of the entity in some standard classification scheme. The entity may be identified later on the basis of taxonomy id, by specifying it as a color called taxonomy color.

    The taxonomy color is depicted by the prefix “%tax-”.
     

Examples of KBM Colors

Example-1:
Let us consider a typical business scenario, like “the recent order received from ABC Corp, was kept on hold”.

In this example, the primary entity is Order, and the secondary entity is ABC Corp. The colors of the entities may be identified as shown below.
i) For the entity Order, we have,
recent : category of time received : category color
hold : state : which makes it a noun color

ii) For the entity ABC Corp, we have,
ABC Corp : source, which is an auxiliary of Panini Linguistics

We could represent the sentence as a lambda function, shown below.
lambda(verb:received, Order.%ctg-time:recent.%aux-object, ABC_Corp.%aux-source);

We could create a new color type called lambda, and map the color to the above lambda function, as shown below.
%lambda-receivedFromSource =
lambda(verb:received, Order.%aux-object, ABC_Corp.%aux-source);


The lambda color type allows us to rewrite the above sentence as -
Order.%v-received.%ctg-time:recent.%aux-object.%lambda-receivedFromSource;

Next, we note that the Order was ultimately kept on hold, which identifies state of the Order object. Thus we have the following final form.
Order.%v-received.%n-hold.%ctg-time:recent.%aux-object. %lambda-receivedFromSource;
 

Example-2:
A more detailed example of KBM colors is presented below, with the aid of an example in nano switches.

Diarylethene is a nano material, which exists in two forms, which are regarded as form-a and form-b.

In form-a, the nano material is white in color, and allows light to pass through it unobstructed. In form-b, the nano material is purple in color, and blocks the propagation of light.

The visible light spectrum extends from 380nm-740nm, and the wavelength 313nm is regarded as UV signal.

The nano material, utilizes visible light below 500nm as data, and the visible light above 500nm and UV light at 313nm as control signals.

The nano material functions as a switch, as depicted below.

1) Visible light spectrum from 380-500nm : data.
2) UV light signal at 313nm : control signal-1, which transforms nano material from form-a to form-b.
3) Visible light spectrum above 500nm : control signal-2, which transforms nano material from form-b to form-a.

The behaviour of the nano switch could be described by KBM rules, as shown below.

1) NanoMaterial.%form-a *
    Light.%ctg-data.%form-visible.%ch-lt500nm  ->
    Light.%ctg-data.%form-visible.%ch-lt500nm;

2) NanoMaterial.%form-b *
    Light.%ctg-data.%form-visible.%ch-lt500nm ->
    Light.%ctg-data.%form-darkness;

3) NanoMaterial.%form-a *
    Light.%ctg-control.%form-uv.%ch-eq313nm  ->
    NanoMaterial.%form-b;

4) NanoMaterial.%form-b *
    Light.%ctg-control.%form-visible.%ch-gt500nm ->
    NanoMaterial.%form-a;
 

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.
 

This topic was brought forward by WebInfoForAll.com as part of our effort to provide latest news, latest info for all topics and trends, highlighting the latest trending topics, and top web trends for all products and services.