Decision Data Structural Levels (RGB)

Level 1 No Inherent Structure

The data exists as a number of separate fields that have no inherent relationship to each other except that they are all used within a single decision Example

The input to this decision, in json format, might look like this: {"color": "red", "length": 11}

And the output might look like this: {"price":5, "shipping":5}

The decision is designed to accept a single set of inputs and produce a single set of outputs.

Technical Note
Since this data will eventually be consumed by an Aion app the attributes will need to belong to a class 
even if the user didn't explicitly declare one.
Perhaps in this case we simply assume the class to which the attributes belong is called "INPUT"
{"INPUT":{"color": "red", "length": 11}}
{"OUTPUT":{"price":5, "shipping":5}}

However, if we think about it a bit more we may conclude that the various attributes can be grouped according to the thing they describe. For example the attributes color and length might be characteristics of a toy. In fact the user might create an ontology to define the properties of the entity toy:

So we could make the model a bit more explicit by recognizing that fact:

Level 2 Structured Attributes

The input for this decision would now look like this: {"toy":{"color": "red", "length": 11}}

And the output would be: {"toy":{"price":5, "shipping":5}}

Again the decision is modeled to accept only one toy at a time. If we need to apply the decision to many toys then we have two choices

1. Invoke the decision above multiple times (once for each toy in the collection) - in this case the client application would need a loop to iterate through the toys and pass them one at a time to the decision. Each execution is completely independent of the other executions. In fact they could be done in parallel.
2. Invoke the decision once for the entire collection of toys - In this case the decision would contain the necessary logic for processing every item in the collection. This kind of processing is often needed when we have rules about the collection as a whole such as the number of elements or the total of a particular field

Level 3 Collections of Structured Attributes

By using the statement {toy in TOYS} we are indicating that the rules should be applied to every toy in the collection The logic for iterating over the elements in the collection will be handled automatically by BizVR. There are two different ways this may happen:

Iteration

This simply processes each element in the collection one at a time and then moving on to the next. This method is used when the actions of the rules do not add new elements to the collection and do not modify any attribute that is tested in the conditions. Iteration never revisits any element of the collection once processed (so its fast)

Pattern Matching

This is a more complex process that also iterates over the elements of the collection but may revisit elements previously processed if they were changed by the rules. This can happen if the rules modify an attribute that is tested or they create (or delete) elements of the collection. Pattern matching continues processing until no more changes can be made (so it may be slower that simple iteration)