Result of Adaptation

[EGAlberts]

When we adapt, let's say, select_variant(MED_SPEED), the model needs to reflect that the new feature is selected and, in the case of an alternative, its sibling is deselected.

The simplest solution is waiting until we set a parameter and then updating the feature associated with that tactic which we can know from the original query to get the tactic.

however, I think it is more in line with runtime models to process any parameter changes both into the architecture model and then its ramifications into the feature model.

@Rezenders is this something we can do/you think we should do within TypeDB? My current thoughts are to just update the java objects and then make queries afterwards. I will probably proceed with the java way to get evaluation 1 working ASAP for now.

[EGAlberts]

One thing we can do is add rules for 'selected' which are based on architectural information. It should be feasible to say something like, if the parameter value mentioned in the feature_adaptation that a feature is a part of is equal to the current value of that parameter then that feature is selected.

[EGAlberts]

Then the problem becomes, keeping architectural information up to date in typeDB. Which can be done with a ParameterEventListener, either in java or the TypeDBInterface

[EGAlberts]

I managed to do it with this rule:

rule feature_selected_by_parameter_match:
when {
$fa ($f) isa feature_adaptation;
$f isa Feature;
# find a variant_resolution that targets this feature and has a set_nodes_parameters action
$vr (variant: $f, resolution_action: $ra) isa variant_resolution;
$ra (parameter: $p, parameter_value: $pv) isa set_nodes_parameters;
# find a node with the same current parameter value
$hpv (node: $n, parameter: $p, parameter_value: $pv) isa has_parameter_value;
} then {
$f has selected true;
};

rule feature_not_selected_by_parameter_match:
when {
$f isa Feature;
# no matching parameter-value path that would select this feature
not {
$fa ($f) isa feature_adaptation;
$vr (variant: $f, resolution_action: $ra) isa variant_resolution;
$ra (parameter: $p, parameter_value: $pv) isa set_nodes_parameters;
$hpv (node: $n, parameter: $p, parameter_value: $pv) isa has_parameter_value;
};
not { $f has selected true; }; # don't overwrite an explicit/derived true
} then {
$f has selected false;
};

I still need to update the generation to make sure that when a set_parameter matches the default value that they are actually pointing to the same 'Thing' in TypeDB, but with a fake query designed like that it worked

[EGAlberts]

I update the generation as described, when generating a SetParameter it now checks if the value to be set matches the default value of the node in question. If it does it will point to that instead. All that remains now is ensuring that when parameter are set the has_parameter_value of each node is set to point at the new Values creates from the SetParameter instances which were not the default value.

[EGAlberts]

I made an update query and associated test to show how one can use change the has_parameter_value and that this leads correctly to the selected feature changing accordingly. That concludes the typedb_tactics side of things mostly, so I made a PR https://github.com/kas-lab/typedb_tactics/pull/65, this is yet to be implemented in the java side of things to complete the adaptation loop and solve this issue.

[Rezenders]

One thing we can do is add rules for 'selected' which are based on architectural information. It should be feasible to say something like, if the parameter value mentioned in the feature_adaptation that a feature is a part of is equal to the current value of that parameter then that feature is selected.
Then the problem becomes, keeping architectural information up to date in typeDB. Which can be done with a ParameterEventListener, either in java or the TypeDBInterface

I like this idea!
This is exactly what KRR is supposed to be good for, modeling the knowledge and inferring whatever you need to infer from it. Nice design :)