State Operations

The human body is a mass of interconnected systems, all busily doing their own thing, and influencing other systems as they do it. We need to represent both the states of individual systems, and their interactions. We will do that with states. Some obvious states:

The patient may be alive or dead, conscious or unconscious, breathing or not breathing, feverish or shivering.
Most states need more than simple on-off information - the pulse is weak, the temperature is elevated.
Some states are highly nonlinear - a rare condition may only occur once in a million patients.

We need to represent states in a way that makes them persistent, and yet can influence other actions and states - they have to be linkable objects.

We probably need to differentiate more clearly between actions and the states they alter, and to have a state relation, so “opening the door” changes the state relation on the door, which changes a state. The state can be anywhere in a spectrum, so it can be “open”, "partly open”, “closed”, all handled by the same state relation. States can also be related to specific objects, such as

     Fred alerted John to the danger.
     John is aware of the danger.


 FredAlertedJohn.PNG (53702 bytes)

 John has had a persistent change in state (which may not persist – John can forget it) – exercised through a relation which the action created. We could do this, or we could use a SYNONYMMAP, which can be navigated through during Semantic Searching. That is, if Fred alerted John to the danger, then John is aware of the danger. It adds a refinement to the SYNONYMMAP – it has to handle timings as well, but simplifies the network construction.

 ToBeAware may have its own modifiers – John may only be dimly aware of the danger.

 Starting with opening doors, but remembering we may need specific objects:

  1. The Door Is Open
  2. The door is open.
  3. The door is slightly open.
  4. The door is closed.
  5. The door is open to newcomers, closed to repeat visitors.
  6. The contract is open to misinterpretation.

In case 4, it depends who you are as to what state you encounter, making propagation of the state messy.
In case 5, “is open to misinterpretation” is equivalent to “is able to be misinterpreted” – we need to be clear on what are openable things.

For openable things – doors, meetings – we could operate directly on the state

DoorIsOpen.PNG (32762 bytes)

 The state attribute is an invocation of OpenClosed, which is a spectrum from Open to Closed, making the state bounded and transmissible to another similar object – it can’t lie outside the spectrum.

This statement can be used to assert the door is open, or query the state of the door. The state is radiated, and no error is generated if we hit another relation saying it is closed, but with a different time (the new state may terminate the time of the other relation). If Fred says “It is open” and John says “It is closed”, then we do have an error.

 OpenedDoor.PNG (47613 bytes)

 Note: There are more interconnections than shown – the End Time of the ToOpen relation is linked to the Start Time of the ToBe relation, the logical pins of the ToOpen and ToBe are linked through an AND.

 This looks like too much for a SYNONYMMAP to handle (jumping from an object to its attribute, handling the case where it is overridden by a later relation, etc), so we build a ToBe relation, and couple its start to the finish of ToOpen. When he opens the door, the door stays open, but can be closed without error.

He opened the door slightly.

OpenedDoorSlightly.PNG (49159 bytes)

This already requires some knowledge of the current state of the door – if it is half open, it can be opened slightly more. The “slightly” becomes “slightly” of the remaining interval.

 We will assume that “slightly” means 5% of the interval (whereas “imperceptibly” is relative – if you are going to move something 20 metres, “imperceptible” isn’t 1% of that, it is, say, 1 mm).

The door was partly open, but too little for us to enter. We demanded he open the door – he opened it slightly.

We have several sorts of adverbs – one which modifies the action relation, one which modifies the ToBe relation handling the state, and one which modifies what was used in the action.

 He opened the door quickly. – acts on the ToOpen relation
He opened the door slightly. acts on the ToBe relation
He opened the door carefully. acts on the ToUse relation

 He opened the door a little more.

OpenedDoorLittleMore.PNG (49216 bytes)

 The door was partly open. We asked him to open it. He closed it, made some adjustment, and then opened it a little more.

 Here, we need to go back to a state where the door is open – we ignore where the door is closed.

We will need to control which ToBe relation is in control – the latest one. But sometimes we will be hypothesising about future states – “He may open the door tomorrow” – the action will occur in the future.

 He will open the door halfway tomorrow, close it that night, then open it a little more the next day.

 The statement does not change the current state of the door, but the future states need to be discoverable from the state of the door, which leads us to

 OpenedDoorTomorrow.PNG (137522 bytes)

 The order of connections on the Open attribute is irrelevant – the currently active relation asserts a state, which overrides any existing state on the attribute.

 What do we do with “the door opened”? It seems reasonable to handle this as a RELATION1 version of “He opened the door”. Then what about

 The door opens onto a courtyard.

 This is saying something like “When the door is opened, access is gained to a courtyard”. It is not saying the door is open at this time.

Hypothetical Situations

He may have opened the door by mistake.
He wanted to open the door.
He thought the door was open.
He thought John had opened the door.
It is possible that the door is open.
It is at least conceivable that the door was opened by the criminals in their escape.
The door is probably open.

We will need a probability accompanying the state, and the ability to set a hypothetical case true, to see what happens.

 The Patient Died

 If we use a similar state mechanism for the Alive/Dead state of a patient:

 PatientDied.PNG (64177 bytes)

 If the patient dies (from any cause, not just the particular statement), we get a logical from the ToBe relation to go out and crush the vital signs and anything else that is relevant. The mechanism could handle

 The patient died at 9:03 am, was resuscitated, but later died at 10:27 am.

 There are very few relations that can “undead” a person.

Other State Problems

 We have a “common-rare” state for diseases. If we handle it using state operations, we can accept something being only one in a million (or even one in a billion – “there are six known cases in the world”), whereas this precision would get lost in a Bayesian logical value.

The important difference between these states and Bayesian values is that the spectrum of the state is available wherever it is used, rather than trying to bundle something into a number and hoping it will be understood elsewhere.


He Broke His Leg

 Here we have a change in state which generates a repair process.

He broke his leg.
His leg is broken.
His leg begins repair.
His leg is mended.

 Which looks like (ignoring the fact that breaking a leg means breaking a bone in the leg)
 BreakingAleg.PNG (81468 bytes)

The creation of the self repair relation is immediate, responding to the change in state. This seemingly verbose structure allows the repair to take longer than expected – “The break had to be reset”.

 Just as we are shifting the relation parameter from object to state, it will be necessary to shift from object to component.

 “He broke his silence” is a world away from “he broke his leg”, and we need to catch the difference.

 BreakingABone.PNG (34130 bytes)

 This reduces the number of possible bones, and allows us to pull up any knowledge about repair problems in those bones.

States - a presentation

Relation Hierarchy

 Medical Design Notes