#7. Statuses and conflict resolution. An additional facility to control resolution of attribute conflicts are statuses. A status is ascribed to each arc in the net as well as to some actions (attribute setting, vertex merging, failing). Status is a positive integer, that may be interpreted as a degree of credibility of a fact or of an action concerning facts. (Originally, a wider use of statuses was intended, but so far no need of it was felt.) In the implementation, status may be omitted, and then all arcs and all actions are assigned by default the same status; it is to this case that previosly presented rules for conflict resolution apply, while with unequal statuses the arc with the higher status always takes precedence.

More precise rules for conflict resolution are formulated in view of the fact that the definition of node merging is recursive and that setting an attribute can result in node mergers. For each attempt to set an attribute or to merge nodes two things are defined, first, the status of the action itself, second, its violation status, defined as the highest status of all arcs which would have to be deleted at performing this action. If the status of an action is not lower than its violation status, the action is performed, otherwise it fails.

For an attribute conflict three decisions are possible, viz., to discard the first or the second attribute or to merge their values (if admissible). For each of the three decisions its violation status is evaluated and the variant with the smallest violation status is chosen; in case of equal statuses merging has a preference; of two attributes with equal violation statuses the new attribute is chosen for the operation of attribute setting and the choice is left undefined for the operation of merging. When two nodes are merged this procedure of choice and computation of minimal violation status is performed for each pair of conflicting attributes, and the highest of violation statuses so obtained is taken to be the violation status of the whole merger. In this recursive process the statuses for "derived" mergers are evaluated under the assumption that the original merger has happened. This process is implemented by means of the techniques of failures and restoring described above.

For each node a special function may be specified (named #MRGTEST) that must be called by the system before an attempt to merge this node with another node. In the procedure called a failure can occur, and then no merging is done. But such a procedure may specify a status for the FAIL operation; if this status does not exceed the status of the merger being performed no failure takes place and the procedure goes on, but the status of the failure is taken into account in evaluating the general violation status. In this process the status of a derived merger is defined as the minimum of the statuses of the two conflicting attributes and the status of the original merger (if any).

This approach to estimating credibility of facts is rather primitive. What has been proposed is essentially a denumerably-valued logic with a maximum operation as conjunction and minimum as disjunction. This decision is not supported by any serious argument, it was chosen for simplicity and possibly will have to be modified (e.g., a distinction may be introduced between the status of an attribute setting operation and the status of the resulting attribute).

Unnamed arcs have statuses as well, but they are never used because no conflict of such arcs is possible. In future it would probably be a good idea to use their statuses to define the order of their enumeration (which is left undefined in the present implementation).

Let us dwell on using merge operation with a status slightly lower than that of most arcs. Such an operation will be successful only in the absence of contradictions between attributes of the nodes being merged (except possibly some low-status attributes) and thus can be used to test admissibility of a merger or to evaluate its violation status (this status is returned by a successful merge operation). This can be used in order to find an object matching a given pattern. The pattern is not distinguished formally from an object and is also represented as a node with the required set of attributes. To test an object against a pattern one has to try to merge them with a lower merge status.

There is a more difficult case when, in an attempt to specify a pattern, we don't know exact values of the attributes of the object to be found, but only intervals where those values must fit or relationships between values of different attributes, etc. Unknown attributes are not included in the pattern while the tests of various relationships are included in the abovementioned procedure of pre-merge testing which must end in a failure whenever the relationships don't hold (this procedure is attached to the pattern). However, this method cannot be used to match one pattern against another pattern like it is done in some AI languages.