Check whether combi matches are actually possible when looking at concrete values #691
Description
If we look at the GeneralizeIfNecessary Test. One of the things that I notice is that At least one of the combi matches of the proactive rule could have been disregarded when we take into account the compatibility of different matches within a combi match:
{
[Match {|sensor2| hasLatestValue |?value|=|?s| hasLatestValue |?value|}]=[] -> [sensor2 hasLatestValue ?value, sensor2 type Sensor, sensor2 isPartOf room2](Sensor2KB)
[Match {|?x| isPartOf |?z|=|?s| isPartOf |building1|}]=[?y isPartOf ?z, ?x isPartOf ?y] -> [?x isPartOf ?z]
[Match {|sensor1| type Sensor=|?s| type Sensor}]=[] -> [sensor1 isPartOf room1, sensor1 hasLatestValue ?value, sensor1 type Sensor](Sensor1KB)
}
As you can see above the first and last match map the same variable ?s to different concrete values (namely sensor1 and sensor2). We already know that this will never fly, so we could have disregarded this combi match earlier. Maybe already during graph pattern matching. This could probably happen in the BaseRule#mergeCombiMatches(…) method before we add a match to an existing rule or new rule, we could check whether it is compatible with the existing matches within the combi match. This would probably mean an additional method in the Merge class that allows us to check if two matches (although for different rules) target the same variable and give it a different concrete value.
Of, I could add a method to the CombiMatch class that checks for this and returns a true if possible and false if not possible.