Sometimes it seems like we have a "knot-tyer" – something that can come to a situation, assess it, connect the loose ends, and leave. Here is something along the same lines –
The structure is found by the normal operation of grammatical patterns. It is connected as a STRUCTURE2, and then its head begins operating. It finds the TEST operator and then the appropriate test – in this case, a SIMILARITY. It runs the test, finds a result, and returns it. The TEST operator then activates one of the secondary STRUCTURE1 operators, resulting in a new STRUCTURE2 operator being constructed. The original STRUCTURE2 is removed. The new STRUCTURE2 can incorporate an ADDPROPERTY, allowing properties to be added, changed or removed.
The mechanism has the virtue of allowing a different form of solving to take place interleaved with pattern matching without resorting to writing a specific procedure.
Some limitations:
There may be several tests required – this could be handled by AND and OR in the TEST input line. A couple of WITHPROPERTY operators, say, doing a test such as
WITHPROPERTY(A, ToInclude) AND WITHPROPERTY(B, ToProvide)
OR
WITHPROPERTY(C, ToInclude) AND WITHPROPERTY(D, ToProvide)
The SIMILARITY test might have half a dozen objects to compare similarity with – a prepositional chain like
A of B, C and D of E and F of G, H and J of K, L and H
We could have lots of these structures, each one slowly rolling up the chain as False was returned and we changed the scope of each And and Comma.
There may be more than two possibilities of construction, so True and False would not be sufficient as a result of the TEST. The False line could build another SemanticChoice operator, which would then choose between two new operators, allowing a (slow) cascade.
There may be more than one new structure to be built, say inserting a new property on one node and building a structure on several others – this could be overcome by inserting an AND in the outgoing control line.