Constraint Reasoning Using Diffuse Operators
In the rest of Orion's structure, an operator maintains consistency among nodes using direct connection. For a strongly hierarchical and relational structure, where information can come from many different directions, this is not particularly useful. Instead, a diffuse model is preferable - excitation causes the operator to be created virtually, it does its work and then disappears. An example is given for maintenance of start date, finish date and duration for a relation.
The connection between StartDate and FinishDate for a relation can depend on the duration and the calendar.
The duration may be specified, such as
....Starting on 31st August for two weeks
or may be inferred from two dates and a calendar, or may be implicit with no start or finish dates
...he repaired the generator after the hailstorm....
We don’t know when it stopped, but in general, repair takes 1- 4 weeks, and if we have a handle on the date of the hailstorm, we can assemble a chain of events.
We may not have one of the dates, or we may have no date, but the duration is tied to a specific calendar - "10 business days".
We may be given a calendar for a specific relation, or we may have to search up its hierarchy looking for a calendar – if we don’t find one, use straight addition/subtraction.
There will usually be no operator connected to all the nodes required for its operation – the operator is diffuse, implicit in the web of connections, but present nowhere.
Instead of a dedicated operator, the change of state coming into an ATTRIBUTE operator causes a search for any required activity. The ATTRIBUTE operator searches its head, and then its hierarchy, then searches a higher level ATTRIBUTES operator and its hierarchy. It finds ‘ACTIVITY1’, which causes a call to this diffuse operator.
The operator assembles the things it needs –
StartDate.Value# (a DateTime representation of the date)
FinishDate.Value#
Duration.Value#
Duration.Unit
Calendar
creating a virtual object for anything it cannot find.
The search for duration and calendar may take it up the hierarchy of the relation whose time period this is (the TimePeriod may not be attached to a relation, and a relation may have several TimePeriods).
Calculation is performed, and the information is propagated on the relevant connections, the operator having existed only virtually.
Why do this – we could build an operator and all the relevant structure, but this would be expensive to maintain and the operator would still need to search its surrounds to establish some of the values it uses, or risk becoming out of date as attributes are added around it. For instance, it may find a duration right up the tree and link to it, then be oblivious to a new duration on the first parent of the relation.
What a real ACTIVITY1 operator would look like, as distinct from a diffuse one.
See Constraint Reasoning in Parsing