Finished - for now - the chapter on Arboretum

doc/Arboretum.md

@@ -100,11 +100,7 @@ downwards, and, when connecting different colours, as meaning 'unless'.
 Thus the most basic structure is "hypothesis is false unless condition
 is true":
 
-Basic DTree
-
-Hypothesis -
-
-Condition +
+![Simplest possible DTree](../img/simplest-possible-dtree.svg)
 
 fig 3: simplest possible rule Conjunctions are represented by columns of
 nodes, only the last of which has the colour to be returned if all are
@@ -113,17 +109,7 @@ colour to be returned if any are true. These can be combined in any
 fashion desired, although we consider it good practise to keep
 individual rule structures small. This is shown in the figure below:
 
-Example DTree
-
-Root Node -
-
-1st Conjunct -
-
-2nd Conjunct +
-
-1st Disjunct -
-
-2nd Disjunct -
+![Example DTree](../img/example-dtree.svg)
 
 fig 4: example rule, showing syntax The rule would read: "(rootnode) is
 false unless (first conjunct) is true and (second conjunct) is true, in
@@ -137,7 +123,7 @@ any way that affects the underlying ideas.
 
 A feature has the properties:
 
-    (methods DTreeRootnode default activeFlg)
+    <methods DTreeRootnode default activeFlg>
 
 where methods is the list of
 methods that the feature applies to see if it holds of the given object,
@@ -156,7 +142,7 @@ just the list (DoTree Default) and describe the algorithms accordingly.
 
 A DTree for a feature is a list of nodes. A node has the properties:
 
-    (feature, colour, children, parent)
+    <feature, colour, children, parent>
 
 Feature points to a feature of the
 system, colour is either Yes or No, children point to successor nodes of
@@ -244,6 +230,8 @@ did not) when that node was conceived as the only sticking node. The
 structure of the system itself then ensured that in the final text, the
 fragment would follow sensibly from the preceding one.
 
+This is described in more detail, with worked examples, below.
+
 We discussed and experimented with several algorithms for the recovery
 of explanations. The one we used worked as follows: when a search
 resulted in a 'no' decision (ineligible for a benefit) then we
@@ -272,31 +260,11 @@ To provide a small worked example of an explanation generated by the
 system, which is yet large enough to give some flavour, let us assume
 our knowledge base contains the following rules:
 
-DTree for Entitled to Widow's Allowance
-
-Entitled to Widov's Allowance -
-
-Satisfies conditions for Widoy's Allowance +
-
-&gt;26 Yeeks Killed husband - Dead - bereaved -
-
--
-
-in prison - Levering with
-
-in prison - Living Yith
-
-Partner -
+![DTree for 'Entitled to Widows' Allowance](../img/dtree-widows-allowance.svg)
 
 fig 1: Rule for "Entitled to Widow's Allowance"
 
-DTree for Living with Partner
-
-Living with Partner -
-
-Remarried +
-
-Cohabiting +
+![DTree for Living with Partner](../img/dtree-live-with-partner.svg)
 
 fig 2: rule for "Living with Partner"
 
@@ -374,15 +342,101 @@ that she had not, in fact remarried.
 
 ## Explanation: a discussion
 
-{\*\* Write something (preferably rather a lot) here \*\*}
+### Writing explanation fragments
 
-This ability to abstract relevant information from an inference engine's
+Arboretum's explanation fragments are canned text written by the knowledge
+engineer in constructing the rule system. However, because of the way they
+are concatenated, they are extremely easy to write. Each is basically just
+a declarative sentence saying, in natural language
+
+    <name of feature at root node> is <colour of this node> because
+    <name of feature at this node> is true and none of
+    <names of features of children of this node> are true.
+
+Thus, for the `Remarried -` node referenced above, the automatically
+generated canned text - had we automatically generated the text, which
+we did not - would have been
+
+> Living with partner is true because remarried is true.
+
+which would probably have been good enough. However, because texts are
+concatenated from the sticking nodes of the successive trees, we know that
+the previous sentence will have ended with some natural language expression
+of the proposition
+
+> Living with partner is true.
+
+Thus, provided we know that the tree for which we are writing the node texts
+is not the top level tree in the decision system, we can avoid rewriting this
+proposition. So the declarative sentence becomes simply
+
+    <name of feature at this node> is true and none of
+    <names of features of children of this node> are true.
+
+But in this instance there are no children of the node `Remarried +`, so this
+reduces to
+
+    <name of feature at this node> is true
+
+The actual, manually written text used in the system, as stated above, was
+
+> We understand that you have remarried.
+
+As you can see, this sentence is a polite and understandable representation
+of the proposition
+
+    Remarried is true
+
+Thus, the claim I am making here - but mildly, it's not a strong claim - is
+that even without hand written canned texts, the conceptual
+design of the DTree engine would allow the automatic construction
+of perfectly usable explanations.
+
+Arboretum was the first deliverable system from the Alvey DHSS Large
+Demonstrator project actually to be delivered, and, I think, of the systems
+the project did deliver, the most polished and most functional, if not the
+most ambitious. However, it was not intended that the systems built by the
+project would actually be put into front line use, and indeed none ever were.
+
+Nevertheless, in designing the system, we took very seriously the idea of how
+an adjudication officer would use such a system in the real world. It's
+important for the officer to explain clearly to a claimant why a claim has
+been disallowed, in language the claimant will understand. Thus, manually
+written fragments made for much less stilted English, and produced a
+plausible verisimilitude of an entirely personal letter.
+
+As one of the problems that the DHSS was experiencing at the time was appeals
+made because the claimant had not understood the reasons for a decision not
+to award benefit, these very simple, clear, apparently-personal letters seemed
+to us a significant feature in the potential usability of the system.
+
+### Relevance filtering
+
+This brings us to the question of how Arboretum managed relevance filtering.
+The answer, as the intelligent reader will already have spotted, is that we
+did not. Relevance fell fortuitously out of the process of evaluation. The
+deepest sticking node on each tree on the path to the final decision
+represents the 'interesting' reason to refuse, within the context of that
+tree; the concatenation of the 'interesting' reason to refuse from the
+successive trees along the path constructed the argument from the general
+to the particular which is precisely a good explanation of a decision.
+
+What's interesting about this was that in our later experience with
+[KnacqTools](KnacqTools.html), which was essentially a commercialised
+reimplementation of Arboretum on less illustrious hardware, we found that
+this explanation algorithm, designed to assist adjudication officers, provided
+explanations which were welcomed as clear and understandable in domains as
+diverse as industrial process control and the diagnosis of fish diseases.
+
+## Conclusion
+
+Arboretum's ability to abstract relevant information from an inference engine's
 backtrace represents a partial solution to the problem described in the
 preceding chapters.
 
 ## References:
 
-3\. Xerox Corporation: InterLisp Reference Manual ( Xerox Corporation,
+3\. Xerox Corporation: InterLisp Reference Manual (Xerox Corporation,
 1985)
 
 4\. Daniel Bobrow & Mark Stefik: The LOOPS Manual (Xerox Corporation,