diff --git a/doc/Analysis.md b/doc/Analysis.md index 95e9f07..645b629 100644 --- a/doc/Analysis.md +++ b/doc/Analysis.md @@ -775,7 +775,7 @@ believe'); and, implicit in the qualifier, the possibility of a rebuttal: ![Argument schama after Toulmin, p 104](../img/toulmin-argument-schema.svg) In conversation, Toulmin argues, it may be natural simply to say -'<data> so <c|aim>' ; to say '<c|aim> because <warrant> because +'<data> so <claim>' ; to say '<claim> because <warrant> because <data>' "...strikes us as cumbrous and artificial, for it puts in an extra step which is trivial and unnecessary". diff --git a/doc/Arboretum.md b/doc/Arboretum.md index 04d9b0d..6e01df9 100644 --- a/doc/Arboretum.md +++ b/doc/Arboretum.md @@ -102,7 +102,7 @@ is true": ![Simplest possible DTree](../img/simplest-possible-dtree.svg) -fig 3: simplest possible rule Conjunctions are represented by columns of +fig 1: simplest possible rule Conjunctions are represented by columns of nodes, only the last of which has the colour to be returned if all are true and disjunctions by branches, each of which terminates in the colour to be returned if any are true. These can be combined in any @@ -111,7 +111,7 @@ individual rule structures small. This is shown in the figure below: ![Example DTree](../img/example-dtree.svg) -fig 4: example rule, showing syntax The rule would read: "(rootnode) is +fig 2: example rule, showing syntax The rule would read: "(rootnode) is false unless (first conjunct) is true and (second conjunct) is true, in which case it is true unless either (first disjunct) or (second disjunct) is true". @@ -262,11 +262,11 @@ our knowledge base contains the following rules: ![DTree for 'Entitled to Widows' Allowance](../img/dtree-widows-allowance.svg) -fig 1: Rule for "Entitled to Widow's Allowance" +fig 3: Rule for "Entitled to Widow's Allowance" ![DTree for Living with Partner](../img/dtree-live-with-partner.svg) -fig 2: rule for "Living with Partner" +fig 4: rule for "Living with Partner" which, together, partially encode the following legislation fragment, from the Social Security Act 1975 diff --git a/doc/Bialowieza.md b/doc/Bialowieza.md index e0a96cd..10e9874 100644 --- a/doc/Bialowieza.md +++ b/doc/Bialowieza.md @@ -48,7 +48,7 @@ So we shall say that a proposition will be represented as a Clojure map with at Thus - {:verb :killed :subject :brutus :object :caesar} + {:verb :kill :subject :brutus :object :caesar} is a proposition which asserts that Brutus killed Caesar. @@ -61,36 +61,72 @@ There may be many other privileged keys, such as * `:data` - an argument structure...! * `:authority` - id of agent from whom, or rule from which, I know this; -and so on. The exact set of privileged keys is probably actually a matter for particular advocates rather than for the engine itself, although if the advocates in the game don't broadly share the same set of privileged keys then it won't work very well. +and so on. The exact set of privileged keys is probably actually a matter for +particular advocates rather than for the engine itself, although if the advocates +in the game don't broadly share the same set of privileged keys then it won't +work very well. *However...* -The attentive reader will note that some of the proposed privileged keys map closely onto the [Toulmin schema](Analysis.html#the-toulmin-schema). Thus we can say: +The attentive reader will note that some of the proposed privileged keys map +closely onto the [Toulmin schema](Analysis.html#the-toulmin-schema). Thus we can say: * that the proposition itself is a `claim` in the sense of the **C** term; * that `:data` above is precisely `data` in the sense of the **D** term in Toulmin's schema, but may (is likely to) also provide a `warrant` in the sense of the **W** term; * that `:truth` and `:confidence` are both `qualifiers` of the claim in the sense of the **Q** term; * that `:authority` is a form of `backing` in the sense of the **B** term. -So what, then, is an 'argument structure', as described above? It seems to me that it may be exactly a proposition, with the special feature that the value of the `:data` key is not minimised. +So what, then, is an 'argument structure', as described above? It seems to me +that it may be exactly a proposition, with the special feature that the value +of the `:data` key is not minimised. + +Recall that in the chapter on Arboretum I observed that [the working of the DTree decision algorithm caused precisely those nodes to be collected whose fragments which provided the most relevant explanation](Arboretum.html#relevance-filtering) to support the decision, in a natural sequence from the general to the particular. I believe that precisely the same fortuitous alchemy will provide the argument structure to provide Toulmin's **D** - out `:data` term. The DTree itself then becomes the **W** - the `:warrant`; and the author of the DTree becomes the `:authority`. #### Proposition minimisation -How are the values of `:subject`, `:object` and so on to be passed? If we pass rich knowledge structures around, then we lose the insight that different advocates may know different things about given objects. Thus, while internally within each advocate's knowledge base objects may be stored with rich data, when they're passed around in propositions they should be minimised - that is to say, the value should just be a unique identifier, such that, for every object in the domain, if an advocate knows anything at all about that object, it knows its unique identifier and knows the object by that unique identifier. +How are the values of `:subject`, `:object` and so on to be passed? If we pass +rich knowledge structures around, then we lose the insight that different +advocates may know different things about given objects. Thus, while internally +within each advocate's knowledge base objects may be stored with rich data, when +they're passed around in propositions they should be minimised - that is to say, +the value should just be a unique identifier, such that, for every object in the +domain, if an advocate knows anything at all about that object, it knows its +unique identifier and knows the object by that unique identifier. -Thus the unique identifier has something of the nature of a 'true name', in the magical sense. A given true name, a given unique identifier, refers to precisely one thing in the world, and provided that two advocates both know the same true name, they can debats propositions which refer to the object with that true name. +Thus the unique identifier has something of the nature of a 'true name', in the +magical sense. A given true name, a given unique identifier, refers to precisely +one thing in the world, and provided that two advocates both know the same true +name, they can debats propositions which refer to the object with that true name. -Generally, a true name shall be a Clojure keyword. That keyword, passed to any advocate in the game, shall identify either `nil` (the advocate knows nothing of the object), or a map representing everything the advocate knows about the object, and within that map, the value of the key `:id` shall be that true name. +Generally, a true name shall be a Clojure keyword. That keyword, passed to any +advocate in the game, shall identify either `nil` (the advocate knows nothing +of the object), or a map representing everything the advocate knows about the +object, and within that map, the value of the key `:id` shall be that true name. -But in saying 'the advocate knows', actually, the advocate knows nothing. The advocate has access to a knowledge base, and it is in the knowledge base that the knowledge is stored. It may be an individual knowledge base, in which case we can implement that idea that different advocates may have the different knowledge about the same object, or it may be a shared consensual knowledge base. +But in saying 'the advocate knows', actually, the advocate knows nothing. The +advocate has access to a knowledge base, and it is in the knowledge base that +the knowledge is stored. It may be an individual knowledge base, in which case +we can implement that idea that different advocates may have the different +knowledge about the same object, or it may be a shared consensual knowledge +base. -A proposition is represented as a map. So to minimise a proposition, for every value in that map, if the value is itself a map it shall be replaced by the value of the key `:id` in that map. +A proposition is represented as a map. So to minimise a proposition, for every +value in that map, if the value is itself a map it shall be replaced by the +value of the key `:id` in that map. -This means that every implementation of the `wildwood.knowledge-accessor/Accessor` protocol must transduce whatever token its backing store uses as the primary key for an object to `:id` when it performs a `fetch` operation. +This means that every implementation of the `wildwood.knowledge-accessor/Accessor` +protocol must transduce whatever token its backing store uses as the primary key +for an object to `:id` when it performs a `fetch` operation. ## Thoughts on the shape of a knowledge base -The object of building Bialowieza as a library is that we should not constrain how applications which use the library store their knowledge. Rather, knowledge accessors must transduce between the representation used by the particular storage implementation and that defined in `wildwood.schema`. However, what we've described above suggests that a hierarchical database would be a very natural fit for knowlege base data - more natural, in this case, than a relational database. +The object of building Bialowieza as a library is that we should not constrain +how applications which use the library store their knowledge. Rather, knowledge +accessors must transduce between the representation used by the particular +storage implementation and that defined in `wildwood.schema`. However, what +we've described above suggests that a hierarchical database would be a very +natural fit for knowlege base data - more natural, in this case, than a +relational database. ## Prejudice, and defaults diff --git a/docs/codox/AgainstTruth.html b/docs/codox/AgainstTruth.html index f08d291..b57928d 100644 --- a/docs/codox/AgainstTruth.html +++ b/docs/codox/AgainstTruth.html @@ -1,6 +1,6 @@ -Against Truth

Project

Topics

Namespaces

Against Truth

+Against Truth

Project

Topics

Namespaces

Against Truth

Simon Brooke

“Hey, what IS truth, man?” Beeblebrox, Z, quoted in [Adams, 1978]

diff --git a/docs/codox/Analysis.html b/docs/codox/Analysis.html index a4aec03..d387c6b 100644 --- a/docs/codox/Analysis.html +++ b/docs/codox/Analysis.html @@ -1,6 +1,6 @@ -Analysis

Project

Topics

Namespaces

Analysis

+Analysis

Project

Topics

Namespaces

Analysis

Accounts from the Philosophy of Science

(Towards another chapter. What l want to do is: ,

    @@ -262,7 +262,7 @@ a is x

He draws on the practice of jurisprudence to find alternative schemae; and synthesises one such comprising the following elements: a statement of some assertion, which implicitly carries with it a claim as to the truth of the assertion; and data, information which is consensual at the time of argument (or is supported by some futher argument), which tends to support that claim; some inference rule, a warrant, which will allow the argument to move from the data to the claim (for example, ‘all as are bs’), again optionally supported by some further argument or bagking; an optional qualifier (e.g. ‘probably’, ‘I believe’); and, implicit in the qualifier, the possibility of a rebuttal:

Argument schama after Toulmin, p 104

-

In conversation, Toulmin argues, it may be natural simply to say ‘<data> so <c|aim>’ ; to say ‘<c|aim> because <warrant> because <data>’ “…strikes us as cumbrous and artificial, for it puts in an extra step which is trivial and unnecessary”.

+

In conversation, Toulmin argues, it may be natural simply to say ‘<data> so <claim>’ ; to say ‘<claim> because <warrant> because <data>’ “…strikes us as cumbrous and artificial, for it puts in an extra step which is trivial and unnecessary”.

Toulmin sets out to validate this schema by comparing it with the syllogism, and asking "‘What corresponds in the syllogism to our distinction between data, warrant, and backing?"’ He devotes special attention to arguments of the forms ‘Almost all A’s are B’s’ and ‘Scarcely any A’s _are B’s’ - forms which are, of course, of the utmost importance in default logics, but which are beyond the scope of the syllogistic. He shows that such arguments are representable using his schema without difficulty, and that the traditional syllogism forms are also so representable.

But beyond this he observes that the major premiss of a syllogism plays a dual role with hegemonistic implications: it is at once an inference step and an assertion of some piece of information. Thus one may challenge it in its role as warrant, on the basis that it is not relevant to the case, and as backing, on the grounds that it is not true. TouImin’s schema, by separating these roles, makes clearer from what grounds a counter argument can be launched.

{**TODO**: Again back-reference this when I’m arguing that argument is hegemonistic!}

diff --git a/docs/codox/Arboretum.html b/docs/codox/Arboretum.html index 5b79dbb..dd478ba 100644 --- a/docs/codox/Arboretum.html +++ b/docs/codox/Arboretum.html @@ -1,6 +1,6 @@ -Arboretum

Project

Topics

Namespaces

Arboretum

+Arboretum

Project

Topics

Namespaces

Arboretum

This chapter describes briefly an inference mechanism, implemented in the Arboretum prototype; this is included here to show the results achieved in the author’s early work on explanation, on which it is hoped to build in the current work. A fuller description of this mechanism, and of the Arboretum prototype, will be found in [Mott & Brooke 87], from which this chapter is largely drawn.

Arboretum was written in InterLisp-D[4] using LOOPS [5] object oriented facilities, to allow people to manipulate DTree structures through graphical representations: to build arbitrarily large knowledge bases, to use these to provide answers to questions about objects in domains admitting incomplete information - and to provide natural language explanations of these answers. The inference process by which answers are produced is shown as an animated graph. The user can ask the system how the value of any particular feature was arrived at, and what that value was. . It was developed for the Alvey DHSS Large Demonstrator Project, and sought to meet early perceptions of the needs of DHSS Adjudication Officers. Adjudication Officers decide claimants’ eligibility over a wide range of welfare benefits. There is a very large volume of work to be done, so they work under considerable pressure.

The Adjudication process within the DHSS has its own levels of authority culminating in the

@@ -15,9 +15,9 @@

These trees can then be directly interpreted as rules by the DTree algorithm, the root idea of which is that a decision has always been made, there is always an answer available, but one which the system is currently trying to refute. The eventual decision is simply the last one made, the one that the system has failed to refute. At any point it tries to “change its mind”, and when it can no longer do so that is the decision it delivers. After all, if there is nothing as yet unexamined that could make you change your mind why deliberate further, while if there is how may you legitimately stop? The idea of an alternating ‘yes/no’ with decision characterised simply by its position at the end is a very old one indeed due to Thomas Hobbes (16]. The emphasis on trying to refute rather than trying to confirm is of course Popperian (passim, but see for example his [17]).

Let us summarise how to read a DTree rule structure. The basic units are nodes and the edges between them. An edge should always be read downwards, and, when connecting different colours, as meaning ‘unless’. Thus the most basic structure is “hypothesis is false unless condition is true”:

Simplest possible DTree

-

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 true and disjunctions by branches, each of which terminates in the 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:

+

fig 1: simplest possible rule Conjunctions are represented by columns of nodes, only the last of which has the colour to be returned if all are true and disjunctions by branches, each of which terminates in the 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

-

fig 4: example rule, showing syntax The rule would read: “(rootnode) is false unless (first conjunct) is true and (second conjunct) is true, in which case it is true unless either (first disjunct) or (second disjunct) is true”.

+

fig 2: example rule, showing syntax The rule would read: “(rootnode) is false unless (first conjunct) is true and (second conjunct) is true, in which case it is true unless either (first disjunct) or (second disjunct) is true”.

A DTree system contains at any time a number of features, objects and nodes. In a LISP implementation these are litatoms equipped with property lists; the LOOPS implementation is rather different but not in any way that affects the underlying ideas.

A feature has the properties:

<methods DTreeRootnode default activeFlg>
@@ -46,9 +46,9 @@
 
In the case of a ‘yes’ decision we chose the opposite approach and selected the shallowest sticking node available. This was partly because the claimant who succeeds is less concerned about why, but mostly because it is not relevant to describe how a long and tortuous inference path finally delivered ‘yes’ when a much shorter less involved one did so too. Again this seems in accord with ordinary ideas of relevance.

 
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 Widows’ Allowance

-
fig 1: Rule for “Entitled to Widow’s Allowance”

+
fig 3: Rule for “Entitled to Widow’s Allowance”

 
DTree for Living with Partner

-
fig 2: rule for “Living with Partner”

+
fig 4: rule for “Living with Partner”

 
which, together, partially encode the following legislation fragment, from the Social Security Act 1975 [6], chapter 14, section 24, as amended by the Social Security (Miscellaneous Provisions) Act 1977, chapter 5, .section 22(2). This reads:

 
24.-(1) A woman who has been widowed shall be entitled to widow's
 allowance at the weekly rate specified in relation thereto in Schedule
diff --git a/docs/codox/Arden.html b/docs/codox/Arden.html
index 9c00ea0..0d3474f 100644
--- a/docs/codox/Arden.html
+++ b/docs/codox/Arden.html
@@ -1,6 +1,6 @@
 
-Arden
Project
Topics
Namespaces
Arden

+Arden
Project
Topics
Namespaces
Arden

 
Why Arden?

 
It was something of tradition in the InterLisp-D community to give successive versions of a project codenames with successive alphabetical initials. So the first version would have a name starting ‘A’, the second ‘B’, and so on. The first prototype for Wildwood was called ‘Arden’, because it starts with an ‘A’, and because it is a fantastical dream-like forest depicted in Shakespeare’s play ‘As You Like It’, which if I recall correctly was performed as a promenade performance by the Duke’s Theatre in Lancaster in that year. While Arboretum - that carefully tended garden of trees - had been, as I’ve said, largely Peter’s in concept, Wildwood would be mine.

 
Background

diff --git a/docs/codox/BatesonKammerer.html b/docs/codox/BatesonKammerer.html
index 6a588d8..35607eb 100644
--- a/docs/codox/BatesonKammerer.html
+++ b/docs/codox/BatesonKammerer.html
@@ -1,4 +1,4 @@
 
-The Bateson / Kammerer debate
Project
Topics
Namespaces
The Bateson / Kammerer debate

+The Bateson / Kammerer debate
Project
Topics
Namespaces
The Bateson / Kammerer debate

 
{ TODO: analyse the style and motivations of the Bateson / Kammerer debate, drawing out the use of polemic and rhetoric to achieve hegemony }

\ No newline at end of file
diff --git a/docs/codox/Bialowieza.html b/docs/codox/Bialowieza.html
index 30e1afa..67e0823 100644
--- a/docs/codox/Bialowieza.html
+++ b/docs/codox/Bialowieza.html
@@ -1,6 +1,6 @@
 
-Bialowieza
Project
Topics
Namespaces
Bialowieza

+Bialowieza
Project
Topics
Namespaces
Bialowieza

 
{ this chapter is in active development; quite a lot of the technical detail in this chapter at present will probably end up in Implementing, while additional high level and conceptual design, as it develops, will be here. }

 
Why Bialowieza?

 
Bialowieza is the second iteration of the Wildwood engine, and this following convention its name should start with ‘B’. Białowieża is Europe’s last great wild wood, and it is currently under threat.

@@ -29,7 +29,7 @@
   
  • :object - to whom (or what)
    • 
 
 
    Thus
    
-
    {:verb :killed :subject :brutus :object :caesar}
+
    {:verb :kill :subject :brutus :object :caesar}
 
    
 
    is a proposition which asserts that Brutus killed Caesar.
    
 
    There may be many other privileged keys, such as
    
@@ -51,6 +51,7 @@
   
  • that :authority is a form of backing in the sense of the B term.
    • 
 
 
    So what, then, is an ‘argument structure’, as described above? It seems to me that it may be exactly a proposition, with the special feature that the value of the :data key is not minimised.
    
+
    Recall that in the chapter on Arboretum I observed that the working of the DTree decision algorithm caused precisely those nodes to be collected whose fragments which provided the most relevant explanation to support the decision, in a natural sequence from the general to the particular. I believe that precisely the same fortuitous alchemy will provide the argument structure to provide Toulmin’s D - out :data term. The DTree itself then becomes the W - the :warrant; and the author of the DTree becomes the :authority.
    
 
    Proposition minimisation
    
 
    How are the values of :subject, :object and so on to be passed? If we pass rich knowledge structures around, then we lose the insight that different advocates may know different things about given objects. Thus, while internally within each advocate’s knowledge base objects may be stored with rich data, when they’re passed around in propositions they should be minimised - that is to say, the value should just be a unique identifier, such that, for every object in the domain, if an advocate knows anything at all about that object, it knows its unique identifier and knows the object by that unique identifier.
    
 
    Thus the unique identifier has something of the nature of a ‘true name’, in the magical sense. A given true name, a given unique identifier, refers to precisely one thing in the world, and provided that two advocates both know the same true name, they can debats propositions which refer to the object with that true name.
    
diff --git a/docs/codox/Errata.html b/docs/codox/Errata.html
index 7173161..ae7ba03 100644
--- a/docs/codox/Errata.html
+++ b/docs/codox/Errata.html
@@ -1,6 +1,6 @@
 
-Errata
    Project
    Topics
    Namespaces
    Errata
    
+Errata
    Project
    Topics
    Namespaces
    Errata
    
 
      
   
    1. On title page: the claim that Zaphod Beeblebrox is quoted as saying ‘Hey, what IS truth, man?’ in the printed text of Douglas Adams ‘Hitchhikers Guide to the Galaxy’ is false.
      2. 
 
    
\ No newline at end of file
diff --git a/docs/codox/Experience.html b/docs/codox/Experience.html
index 27b6eef..fe42674 100644
--- a/docs/codox/Experience.html
+++ b/docs/codox/Experience.html
@@ -1,4 +1,4 @@
 
-Experience
    Project
    Topics
    Namespaces
    Experience
    
+Experience
    Project
    Topics
    Namespaces
    Experience
    
 
    {Not yet written. To cover an evaluation of the Clojure Wildwood library, when it works, and what I can learn from it going forward}
    
\ No newline at end of file
diff --git a/docs/codox/HegemonicArgument.html b/docs/codox/HegemonicArgument.html
index 8b3348e..fc73f11 100644
--- a/docs/codox/HegemonicArgument.html
+++ b/docs/codox/HegemonicArgument.html
@@ -1,4 +1,4 @@
 
-Hegemonic Argument
    Project
    Topics
    Namespaces
    Hegemonic Argument
    
+Hegemonic Argument
    Project
    Topics
    Namespaces
    Hegemonic Argument
    
 
    { new chapter, beginning a sequence which argues that the purpose of argument is to achieve hegemony, not find truth. In this chapter we’ll cover the sources we’ve used already, and show that the philosophers of science, whatever they claim about the purpose of argument, actually argue in a highly polemical, persuasive manner, seeking to achieve widespread belief of their chosen position - that is, to achieve hegemony; and further, even those who make strong claims to the value of candour are frequently not candid in their own argument }
    
\ No newline at end of file
diff --git a/docs/codox/History.html b/docs/codox/History.html
index 6b8e177..fff7722 100644
--- a/docs/codox/History.html
+++ b/docs/codox/History.html
@@ -1,6 +1,6 @@
 
-History
    Project
    Topics
    Namespaces
    History
    
+History
    Project
    Topics
    Namespaces
    History
    
 
    History: Introduction
    
 
    The object of this chapter is to describe and discuss the development of Expert System explanations from the beginning’ to the most recent systems. The argument which I will try to advance is that development has been continuously driven by the perceived inadequacy of the explanations given; and that, while many ad hoc, and some principled, approaches have been tried, no really adequate explanation system has emerged. Further, I will claim that, as some of the later and more principled explanation systems accurately model the accounts of explanation advanced in current philosophy, the philosophical understanding of explanation is itself inadequate.
    
 
    {I ought to add to this chapter to give some overview of what’s happened since 1990, and look at explanations of neural network decisions, because that will help in later parts/chapters of Part One}
    
diff --git a/docs/codox/HuxleyKropotkin.html b/docs/codox/HuxleyKropotkin.html
index 6e91493..f9133b8 100644
--- a/docs/codox/HuxleyKropotkin.html
+++ b/docs/codox/HuxleyKropotkin.html
@@ -1,4 +1,4 @@
 
-The Huxley / Kropotkin debate
    Project
    Topics
    Namespaces
    The Huxley / Kropotkin debate
    
+The Huxley / Kropotkin debate
    Project
    Topics
    Namespaces
    The Huxley / Kropotkin debate
    
 
    { TODO: analyse the style and motivations of the Huxley / Kropotkin debate, drawing out the use of polemic and rhetoric to achieve hegemony }
    
\ No newline at end of file
diff --git a/docs/codox/Implementing.html b/docs/codox/Implementing.html
index b2e1047..1558920 100644
--- a/docs/codox/Implementing.html
+++ b/docs/codox/Implementing.html
@@ -1,4 +1,4 @@
 
-Implementing
    Project
    Topics
    Namespaces
    Implementing
    
+Implementing
    Project
    Topics
    Namespaces
    Implementing
    
 
    {not yet written. To cover the actual structure of the Clojure Wildwood library, as I do it}
    
\ No newline at end of file
diff --git a/docs/codox/JAccuse.html b/docs/codox/JAccuse.html
index 573ddda..c7758fb 100644
--- a/docs/codox/JAccuse.html
+++ b/docs/codox/JAccuse.html
@@ -1,6 +1,6 @@
 
-J'Accuse
    Project
    Topics
    Namespaces
    J’Accuse
    
+J'Accuse
    Project
    Topics
    Namespaces
    J’Accuse
    
 
    { Conclusion of the thesis.
    
 
    title of this chapter may change, but it needs to be confrontational and polemical.
    
 
    Draw together all that has been learned in parts one and two into a single, closely argued polemic, in best academic style. }
    
\ No newline at end of file
diff --git a/docs/codox/KnacqTools.html b/docs/codox/KnacqTools.html
index 66641e9..7d51ebe 100644
--- a/docs/codox/KnacqTools.html
+++ b/docs/codox/KnacqTools.html
@@ -1,6 +1,6 @@
 
-KnacqTools
    Project
    Topics
    Namespaces
    KnacqTools
    
+KnacqTools
    Project
    Topics
    Namespaces
    KnacqTools
    
 
    Background
    
 
    KnacqTools (’Knowledge Acquisition Toolkit") was essentially a productisation of the ideas developed in Arboretum. It was written in C, originally for Acorn’s RISC OS operating system, and later ported to UNIX. The only major innovation of KnacqTools was that it was able to transform DTree knowledge structures into the rule languages of a number of contemporary ‘expert system’ inference engines.
    
 
    Thus the expected use of KnacqTools was not to run an inference process itself (although of course it could do this), but to allow a knowledge engineer, using Peter Mott’s ‘elicitation by exception’ technique, which I and others had polished in the field, to enter DTrees elicited from domain experts, compile these DTrees into production rules, and export those prodution rules to the selected expert system package for deployment.
    
diff --git a/docs/codox/Manifesto.html b/docs/codox/Manifesto.html
index a4525b8..79901ba 100644
--- a/docs/codox/Manifesto.html
+++ b/docs/codox/Manifesto.html
@@ -1,6 +1,6 @@
 
-Manifesto
    Project
    Topics
    Namespaces
    Manifesto
    
+Manifesto
    Project
    Topics
    Namespaces
    Manifesto
    
 
    Machine inference – automated reasoning, the core of what gets called Artificial Intellegence – has ab initio been based on the assumption that the purpose of reasoning was to preserve truth. It is because this assumption is false that the project has thus far failed to bear fruit, that Allan Turing’s eponymous test has yet to be passed.
    
 
    Clockwork minds
    
 
    Of course it is possible to build machines which, within the constraints of finite store, can accurately compute theora of first order predicate calculus ad nauseam but such machines do not display behaviour which is convincingly intelligent. They are cold and mechanical; we do not recognise ourselves in them. Like the Girl in the Fireplace’s beautiful clocks, they are precisely inhuman.
    
diff --git a/docs/codox/OnHylasAndPhilonus.html b/docs/codox/OnHylasAndPhilonus.html
index c9fe731..1c53c59 100644
--- a/docs/codox/OnHylasAndPhilonus.html
+++ b/docs/codox/OnHylasAndPhilonus.html
@@ -1,6 +1,6 @@
 
-On the First Dialogue of Hylas and Philonous
    Project
    Topics
    Namespaces
    On the First Dialogue of Hylas and Philonous
    
+On the First Dialogue of Hylas and Philonous
    Project
    Topics
    Namespaces
    On the First Dialogue of Hylas and Philonous
    
 
    The argument that our perception of a ‘real world’ does not prove its existence is not new, of course. Here is a classic statement of a similar argument from BerkeIey’s First Dialogue of Hylas and Philonous:
    
 
    
   
    Hyl.: Do we not perceive the stars and moon, for example, to be a A great way off? Is not this, I say, manifest to the senses? I
    
diff --git a/docs/codox/PredicateSubtext.html b/docs/codox/PredicateSubtext.html
index 8277857..134e837 100644
--- a/docs/codox/PredicateSubtext.html
+++ b/docs/codox/PredicateSubtext.html
@@ -1,6 +1,6 @@
 
-On the subtext of a predicate
    Project
    Topics
    Namespaces
    On the subtext of a predicate
    
+On the subtext of a predicate
    Project
    Topics
    Namespaces
    On the subtext of a predicate
    
 
    Predicates are not atomic. They do not come single spies, but freighted with battalions of inferable subtexts. Suppose Anthony says
    
 
    Brutus killed Caesar in Rome during the ides of March
 
    
diff --git a/docs/codox/TheProblem.html b/docs/codox/TheProblem.html
index 42bcfda..00ea801 100644
--- a/docs/codox/TheProblem.html
+++ b/docs/codox/TheProblem.html
@@ -1,6 +1,6 @@
 
-The  Problem
    Project
    Topics
    Namespaces
    The Problem
    
+The  Problem
    Project
    Topics
    Namespaces
    The Problem
    
 
    In this chapter talk about the perceived need for expert system explanations. Advance:
    
 
    the arguments used by expert systems designers, saying why explanations are needed;
    
 
    the arguments used by critics which claim that the explanations given are not good enough.
    
diff --git a/docs/codox/index.html b/docs/codox/index.html
index 0736575..40d1772 100644
--- a/docs/codox/index.html
+++ b/docs/codox/index.html
@@ -1,3 +1,3 @@
 
-Wildwood 0.1.0-SNAPSHOT
    Project
    Topics
    Namespaces
    Wildwood 0.1.0-SNAPSHOT
    Released under the EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0
    A general inference library using a game theoretic inference mechanism.
    Installation
    To install, add the following dependency to your project or build file:
    [wildwood "0.1.0-SNAPSHOT"]
    Topics
    Namespaces
    wildwood.advocate
    An agent capable of playing the explanation game.
    Public variables and functions:
    wildwood.bialowieza
    The second iteration of the core inference engine for Wildwood
    Public variables and functions:
    wildwood.caesar
    A dummy set of advocates and knowledge accessors with knowledge about the death of Julius Caesar.
    Public variables and functions:
    wildwood.dengine.engine
    An implementation of the DTree engine adapted to wildwood.schema propositions.
    Public variables and functions:
    wildwood.dengine.node
    A dtree node.
    Public variables and functions:
    wildwood.knowledge-accessor
    The key point of building Bialowieza as a library rather than a complete application is that it should be possible to hook it up to multiple sources of knowledge. Thus we must design a protocol through which knowledge can be accessed, and a schema in which it will be returned. Note that the accessor must be able to add knowledge to the knowledge base, as well as retrieve it.
    Public variables and functions:
    wildwood.schema
    The knowledge representation. This probably ends up looking a bit like a Toulmin schema, where claims are represented as propositions. There also need to be rules or predicates, things which can test whether a given proposition has a given value. There may be other stuff in here.
    Public variables and functions:
    
\ No newline at end of file
+Wildwood 0.1.0-SNAPSHOT
    Project
    Topics
    Namespaces
    Wildwood 0.1.0-SNAPSHOT
    Released under the EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0
    A general inference library using a game theoretic inference mechanism.
    Installation
    To install, add the following dependency to your project or build file:
    [wildwood "0.1.0-SNAPSHOT"]
    Topics
    Namespaces
    wildwood.advocate
    An agent capable of playing the explanation game.
    Public variables and functions:
    wildwood.bialowieza
    The second iteration of the core inference engine for Wildwood
    Public variables and functions:
    wildwood.caesar
    A dummy set of advocates and knowledge accessors with knowledge about the death of Julius Caesar.
    Public variables and functions:
    wildwood.dengine.engine
    An implementation of the DTree engine adapted to wildwood.schema propositions.
    Public variables and functions:
    wildwood.dengine.node
    A dtree node.
    Public variables and functions:
    wildwood.knowledge-accessor
    The key point of building Bialowieza as a library rather than a complete application is that it should be possible to hook it up to multiple sources of knowledge. Thus we must design a protocol through which knowledge can be accessed, and a schema in which it will be returned. Note that the accessor must be able to add knowledge to the knowledge base, as well as retrieve it.
    Public variables and functions:
    wildwood.mongo-ka
    A knowledge accessor fetching from and storing to Mongo DB.
    Public variables and functions:
      wildwood.schema
      The knowledge representation. This probably ends up looking a bit like a Toulmin schema, where claims are represented as propositions. There also need to be rules or predicates, things which can test whether a given proposition has a given value. There may be other stuff in here.
      Public variables and functions:
      
\ No newline at end of file
diff --git a/docs/codox/intro.html b/docs/codox/intro.html
index b2eb986..67b385c 100644
--- a/docs/codox/intro.html
+++ b/docs/codox/intro.html
@@ -1,6 +1,6 @@
 
-Introduction to Wildwood
      Project
      Topics
      Namespaces
      Introduction to Wildwood
      
+Introduction to Wildwood
      Project
      Topics
      Namespaces
      Introduction to Wildwood
      
 
      I started building Wildwood nearly forty years ago on InterLisp-D workstations. Then, because of changing academic projects, I lost access to those machines, and the project was effectively abandoned. But, I’ve kept thinking about it; it has cool ideas.
      
 
      Explicable inference
      
 
      Wildwood was a follow on from ideas developed in Arboretum, an inference system based on a novel propositional logic using defaults. Arboretum was documented in our paper
      
diff --git a/docs/codox/wildwood.advocate.html b/docs/codox/wildwood.advocate.html
index e0ad8af..615150c 100644
--- a/docs/codox/wildwood.advocate.html
+++ b/docs/codox/wildwood.advocate.html
@@ -1,6 +1,6 @@
 
-wildwood.advocate documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.advocate
      An agent capable of playing the explanation game.
      
+wildwood.advocate documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.advocate
      An agent capable of playing the explanation game.
      
 
      An advocate must have its own knowledge accessor. Different advocates within a game may be accessing different knowledge bases, or different subsets of the same knowledge base with different - potentially competing - knowledge. It also needs to know the schema in which knowledge will be presented.
      
 
      Since the mechanism by which the application will communicate with the library must include a way for users to interact with the game, and since the role of the user in the came is just as a participant, advocate must be defined as a protocol, in order that it may be extended by code within the application which is passed in to the game when the game is started. Indeed, multiple agents - the user(s) and potentially non-player characters - may be passed in.
      
 
      In this conception, nothing within a default advocate has to be able to produce or consume natural language. It is sufficient for the API exposed by wildwood.advocate to receive and return wildwood.schema objects.
      
diff --git a/docs/codox/wildwood.bialowieza.html b/docs/codox/wildwood.bialowieza.html
index c2f0ca6..7980273 100644
--- a/docs/codox/wildwood.bialowieza.html
+++ b/docs/codox/wildwood.bialowieza.html
@@ -1,6 +1,6 @@
 
-wildwood.bialowieza documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.bialowieza
      The second iteration of the core inference engine for Wildwood
      decide
      (decide proposition & agents)
      Decide the truth value of this proposition by convening a game between these advocate agents. Iterate the game until all agents PASS; then finally offer each agent’s record method the proposition together with the decided truth value (true or false), before returning that value.
      
+wildwood.bialowieza documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.bialowieza
      The second iteration of the core inference engine for Wildwood
      decide
      (decide proposition & agents)
      Decide the truth value of this proposition by convening a game between these advocate agents. Iterate the game until all agents PASS; then finally offer each agent’s record method the proposition together with the decided truth value (true or false), before returning that value.
      
 
      The proposition is a proposition as defined in the wildwood.schema; that is to say, the predicate wildwood.schema/predicate? returns true of it. If the proposition isn’t a predicate, throw an exception.
      
 
      Each of agents should be an object implementing the wildwood.advocate/Advocate protocol. If an agent isn’t an Advocate, throw an exception.
      
 
      Do not throw an exception under any other circumstances.
      
diff --git a/docs/codox/wildwood.caesar.html b/docs/codox/wildwood.caesar.html
index bf9bd7b..56d192a 100644
--- a/docs/codox/wildwood.caesar.html
+++ b/docs/codox/wildwood.caesar.html
@@ -1,6 +1,6 @@
 
-wildwood.caesar documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.caesar
      A dummy set of advocates and knowledge accessors with knowledge about the death of Julius Caesar.
      
+wildwood.caesar documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.caesar
      A dummy set of advocates and knowledge accessors with knowledge about the death of Julius Caesar.
      
 
      The Case Against Marcus Brutus
      
 
      Did Brutus conspire to kill Caesar in the forum in the Ides of March?
      
 
      Falco, the detective, must find out.
      
@@ -23,4 +23,7 @@
 
      Drusilla’s can be doubted because 1. She wasn’t a witness and 2. Is a woman.
      
 
      Gaius’s can be doubted because 1. he wasn’t a witness, and because 2. it’s inconsistent with the evidence that Caesar was buried on the 18th.
      
 
      The conclusion
      
-
      Thus, I think, Falco must conclude that Brutus didn’t kill Caesar, because if he had he must have had accomplices (Cassius and Longus, who clearly were accomplices and implicate one another), but honourable men don’t kill with accomplices and Brutus is an honourable man.
      anthony-kb
      Mark Antony knows that Brutus is honourable, and that Caesar is buried.
      view source
      april
      The month of April, 44BC, as a range.
      view source
      brutus-kb
      Brutus will admit that he and Cassius were in the forum in the Ides of March
      view source
      cassius-kb
      Cassius and Longus each bear witness that the other killed Caesar in the Forum on the Ides of March.
      view source
      drusila-kb
      Drusila has heard that Brutus killed Caesar in the forum. She keys it on all three, for efficiency of retrieval.
      view source
      eighteenth-march
      18th March, 44BC
      view source
      faldo-db
      Falco believes that Caesar has been killed, but doesn’t know by whom or when.
      view source
      gaius-db
      Gaius has heard that Brutus killed Caesar, but believes it happened in April.
      view source
      ides-of-march
      16th March, 44BC
      view source
      longus-kb
      Cassius and Longus each bear witness that the other killed Caesar in the Forum on the Ides of March.
      view source
      march
      The month of March, 44BC, as a range.
      view source
      
\ No newline at end of file
+
      Thus, I think, Falco must conclude that Brutus didn’t kill Caesar, because if he had he must have had accomplices (Cassius and Longus, who clearly were accomplices and implicate one another), but honourable men don’t kill with accomplices and Brutus is an honourable man.
      anthony-kb
      Mark Antony knows that Brutus is honourable, and that Caesar is buried.
      view source
      april
      The month of April, 44BC, as a range.
      view source
      brutus-kb
      Brutus will admit that he and Cassius were in the forum in the Ides of March
      view source
      cassius-kb
      Cassius and Longus each bear witness that the other killed Caesar in the Forum on the Ides of March.
      view source
      drusila-kb
      Drusila has heard that Brutus killed Caesar in the forum. She keys it on all three, for efficiency of retrieval.
      view source
      eighteenth-march
      18th March, 44BC
      view source
      faldo-db
      Falco believes that Caesar has been killed, but doesn’t know by whom or when.
      view source
      gaius-db
      Gaius has heard that Brutus killed Caesar, but believes it happened in April.
      view source
      ides-of-march
      16th March, 44BC
      view source
      longus-kb
      Cassius and Longus each bear witness that the other killed Caesar in the Forum on the Ides of March.
      view source
      march
      The month of March, 44BC, as a range.
      view source
      
+=======
+wildwood.caesar documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.caesar
      A dummy set of advocates and knowledge accessors with knowledge about the death of Julius Caesar.
      april
      The month of April, 44BC, as a range.
      view source
      drusila-kb
      Drusila knows that Longus killed Caesar in the forum. She keys it on all three, for efficiency of retrieval.
      view source
      faldo-db
      Falco knows that Caesar has been killed, but doesn’t know by whom or when.
      view source
      gaius-db
      Gaius knows that Brutus killed Caesar, but believes it happened in April.
      view source
      ides-of-march
      16th March, 44BC
      view source
      marc-anthony-kb
      Mark Antony knows that Brutus is honourable.
      view source
      march
      The month of March, 44BC, as a range.
      view source
      
+>>>>>>> Stashed changes
diff --git a/docs/codox/wildwood.dengine.engine.html b/docs/codox/wildwood.dengine.engine.html
index 5b57e17..c518b44 100644
--- a/docs/codox/wildwood.dengine.engine.html
+++ b/docs/codox/wildwood.dengine.engine.html
@@ -1,3 +1,3 @@
 
-wildwood.dengine.engine documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.dengine.engine
      An implementation of the DTree engine adapted to wildwood.schema propositions.
      decide
      (decide proposition node accessor)
      Decide the truth value of this proposition, using the dtree rooted at this node and knowledge provided by this accessor.
      view source
      
\ No newline at end of file
+wildwood.dengine.engine documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.dengine.engine
      An implementation of the DTree engine adapted to wildwood.schema propositions.
      decide
      (decide proposition node accessor)
      Decide the truth value of this proposition, using the dtree rooted at this node and knowledge provided by this accessor.
      view source
      
\ No newline at end of file
diff --git a/docs/codox/wildwood.dengine.node.html b/docs/codox/wildwood.dengine.node.html
index 765d0a1..eecdc84 100644
--- a/docs/codox/wildwood.dengine.node.html
+++ b/docs/codox/wildwood.dengine.node.html
@@ -1,3 +1,3 @@
 
-wildwood.dengine.node documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.dengine.node
      A dtree node.
      colour
      (colour node)
      If this node is a valid dtree node, return its colour.
      view source
      node?
      (node? o)
      Return true if this o is recognisable as a dtree node, else false.
      view source
      
\ No newline at end of file
+wildwood.dengine.node documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.dengine.node
      A dtree node.
      colour
      (colour node)
      If this node is a valid dtree node, return its colour.
      view source
      node?
      (node? o)
      Return true if this o is recognisable as a dtree node, else false.
      view source
      
\ No newline at end of file
diff --git a/docs/codox/wildwood.knowledge-accessor.html b/docs/codox/wildwood.knowledge-accessor.html
index 6e124b5..2f749b5 100644
--- a/docs/codox/wildwood.knowledge-accessor.html
+++ b/docs/codox/wildwood.knowledge-accessor.html
@@ -1,3 +1,3 @@
 
-wildwood.knowledge-accessor documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.knowledge-accessor
      The key point of building Bialowieza as a library rather than a complete application is that it should be possible to hook it up to multiple sources of knowledge. Thus we must design a protocol through which knowledge can be accessed, and a schema in which it will be returned. Note that the accessor must be able to add knowledge to the knowledge base, as well as retrieve it.
      Accessor
      protocol
      members
      fetch
      (fetch self id)
      Fetch all the knowledge I have about the object identified by this id value, as a map whose :id key has this id value.
      store
      (store self id proposition)
      Add this proposition to the knowledge I hold about the object identified by this id value.
      view source
      
\ No newline at end of file
+wildwood.knowledge-accessor documentation
      Project
      Topics
      Namespaces
      Public Vars
      wildwood.knowledge-accessor
      The key point of building Bialowieza as a library rather than a complete application is that it should be possible to hook it up to multiple sources of knowledge. Thus we must design a protocol through which knowledge can be accessed, and a schema in which it will be returned. Note that the accessor must be able to add knowledge to the knowledge base, as well as retrieve it.
      Accessor
      protocol
      members
      fetch
      (fetch self id)
      Fetch all the knowledge I have about the object identified by this id value, as a map whose :id key has this id value.
      store
      (store self id proposition)
      Add this proposition to the knowledge I hold about the object identified by this id value.
      view source
      
\ No newline at end of file
diff --git a/docs/codox/wildwood.mongo-ka.html b/docs/codox/wildwood.mongo-ka.html
new file mode 100644
index 0000000..a02b075
--- /dev/null
+++ b/docs/codox/wildwood.mongo-ka.html
@@ -0,0 +1,4 @@
+
+wildwood.mongo-ka documentation
      Project
      Topics
      Namespaces
      Public Vars
        wildwood.mongo-ka
        A knowledge accessor fetching from and storing to Mongo DB.
        
+
        Hierarchical databases seem a very natural fit for how we’re storing knowledge. Mongo DB seems a particularly natural fit since its internal representation is JSON, which can be transformed to EDN extremely naturally.
        
\ No newline at end of file
diff --git a/docs/codox/wildwood.schema.html b/docs/codox/wildwood.schema.html
index 8d30e2d..9a08179 100644
--- a/docs/codox/wildwood.schema.html
+++ b/docs/codox/wildwood.schema.html
@@ -1,7 +1,7 @@
 
-wildwood.schema documentation
        Project
        Topics
        Namespaces
        Public Vars
        wildwood.schema
        The knowledge representation. This probably ends up looking a bit like a Toulmin schema, where claims are represented as propositions. There also need to be rules or predicates, things which can test whether a given proposition has a given value. There may be other stuff in here.
        
+wildwood.schema documentation
        Project
        Topics
        Namespaces
        Public Vars
        wildwood.schema
        The knowledge representation. This probably ends up looking a bit like a Toulmin schema, where claims are represented as propositions. There also need to be rules or predicates, things which can test whether a given proposition has a given value. There may be other stuff in here.
        
 
        Internal representation of most of this will be as Clojure maps.
        argument-keys
        Every argument is a proposition, which additionally has these keys.
        view source
        argument?
        (argument? o)
        True if o qualifies as an argument structure.
        
-
        An argument structure is a (potentially rich) proposition which, in addition, should have values for :confidence and :authority. A value for :data may, and probably will, also be present but is not required. The value of :confidence must be a number in the range -1 to 1.
        view source
        consensual-keys
        Every proposition which has these keys, in a given decision process, must have the same semantics and types for their values. The exact representations used for the values of these keys does not matter, it is consensual between all participating advocates in a decision process.
        view source
        minimise
        (minimise o)
        Expecting that o is a (potentially rich) proposition, return a map identical to o save that for each value v of key k in o, if v is a map and k is not a member of argument-keys, then the returned map shall substitute the value of (:id v).
        
-
        see also wildwood.knowledge-access/maximise.
        view source
        proposition?
        (proposition? o)(proposition? o minimised)
        True if o qualifies as a proposition. A proposition is probably a map with some privileged keys, and may look something like a minimised the-great-game.gossip.news-items item.
        
-
        If minimised is passed and is true, then the proposition must be minimised - that is to say, the values of keys in a proposition map may not themselves be keys. Where the value of a key represents an object in the world, that value must be simply the id of the object, not a richer representation.
        view source
        required-keys
        Every proposition is expected to have values for these keys.
        view source
        rule?
        (rule? o)
        True if o qualifies as a rule. A rule is a structure which comprises * an id and * a function of two arguments, a proposition and a knowledge accessor, and which should (if this can simply be checked) return an argument structure.
        view source
        truth
        (truth p)
        If p is a proposition, return whether the value asserted by that proposition is true. If the :truth key is missing, true is assumed.
        view source
        
\ No newline at end of file
+
        An argument structure is a (potentially rich) proposition which, in addition, should have values for :confidence and :authority. A value for :data may, and probably will, also be present but is not required. The value of :confidence must be a number in the range -1 to 1.
        view source
        consensual-keys
        Every proposition which has these keys, in a given decision process, must have the same semantics and types for their values. The exact representations used for the values of these keys does not matter, it is consensual between all participating advocates in a decision process.
        view source
        minimise
        (minimise o)
        Expecting that o is a (potentially rich) proposition, return a map identical to o save that for each value v of key k in o, if v is a map and k is not a member of argument-keys, then the returned map shall substitute the value of (:id v).
        
+
        see also wildwood.knowledge-access/maximise.
        view source
        preserved-keys
        Keys whose values should not be minimised during proposition minimisation
        view source
        proposition?
        (proposition? o)(proposition? o minimised)
        True if o qualifies as a proposition. A proposition is probably a map with some privileged keys, and may look something like a minimised the-great-game.gossip.news-items item.
        
+
        If minimised is passed and is true, then the proposition must be minimised - that is to say, the values of keys in a proposition map may not themselves be keys. Where the value of a key represents an object in the world, that value must be simply the id of the object, not a richer representation.
        view source
        required-keys
        Every proposition is expected to have values for these keys.
        view source
        rule?
        (rule? o)
        True if o qualifies as a rule. A rule is a structure which comprises * an id and * a function of two arguments, a proposition and a knowledge accessor, and which should (if this can simply be checked) return an argument structure.
        view source
        truth
        (truth p)
        If p is a proposition, return whether the value asserted by that proposition is true. If the :truth key is missing, true is assumed.
        view source
        
\ No newline at end of file
diff --git a/project.clj b/project.clj
index 6a8e5af..e674fb5 100644
--- a/project.clj
+++ b/project.clj
@@ -5,7 +5,9 @@
             :url "https://www.eclipse.org/legal/epl-2.0/"}
   :dependencies [[org.clojure/clojure "1.8.0"]
                  [org.clojure/math.numeric-tower "0.0.4"]
-                 [com.taoensso/timbre "4.10.0"]]
+                 [com.taoensso/timbre "4.10.0"]
+                 [com.novemberain/monger "3.1.0"]
+                 [prismatic/schema "1.1.12"]]
   :codox {:metadata {:doc "**TODO**: write docs"
                      :doc/format :markdown}
           :output-path "docs/codox"
diff --git a/src/wildwood/mongo_ka.clj b/src/wildwood/mongo_ka.clj
new file mode 100644
index 0000000..1817e7f
--- /dev/null
+++ b/src/wildwood/mongo_ka.clj
@@ -0,0 +1,44 @@
+(ns wildwood.mongo-ka
+  "A knowledge accessor fetching from and storing to Mongo DB.
+
+  Hierarchical databases seem a very natural fit for how we're storing
+  knowledge. Mongo DB seems a particularly natural fit since its
+  internal representation is JSON, which can be transformed to EDN
+  extremely naturally."
+  (:require [monger.core :as mg]
+            [monger.collection :as mc]
+            [wildwood.knowledge-accessor :refer [Accessor]])
+  (:import [com.mongodb MongoOptions ServerAddress]
+           [com.mongodb DB WriteConcern]
+           [org.bson.types ObjectId]))
+
+;; MongoDB data items are identified by ObjectId objects. In the retrieved
+;; record from MongoDB, key value is the value of a keyword `:_id` I don't
+;; think there's any *in principle* reason why we should not use these objects
+;; as key values - they're presumably designed to be globally unique.
+;;
+;; In which case, on the way down we have to set `:_id` to the value of `:id`
+;; and vice versa on the way back up.
+
+(defrecord MongoKA
+  ;; It's not clear to me whether we need to pass both the connection and the
+  ;; database in - it's possible that the connected database handle is
+  ;; sufficient. The value of `:collection` is the name of the collection
+  ;; within the database to which this accessor writes.
+  [connection db ^String collection]
+  Accessor
+  (fetch
+    [_ id]
+    (let [oid (cond
+                (instance? ObjectId id) id
+                (string? id) (ObjectId. id)
+                (keyword? id) (ObjectId. (name id)))
+          record (mc/find-by-id db collection oid)]
+      (when record
+        (assoc
+          (dissoc record :_id)
+          :id id))))
+  (store [_ id proposition]
+         ;; don't really know how to do this and am too tired just now.
+         ))
+
diff --git a/src/wildwood/schema.clj b/src/wildwood/schema.clj
index 5f747b2..abb7dc1 100644
--- a/src/wildwood/schema.clj
+++ b/src/wildwood/schema.clj
@@ -29,6 +29,11 @@
     :authority  ;; id of agent from whom, or rule from which, I know this.
     })
 
+(def preserved-keys
+  "Keys whose values should not be minimised during proposition minimisation"
+  ;; TODO: actually, this may end up being just :data
+  (set (cons :data argument-keys)))
+
 (defn proposition?
   "True if `o` qualifies as a proposition. A proposition is probably a map
   with some privileged keys, and may look something like a minimised
@@ -92,6 +97,8 @@
     (number? (:confidence o))
     (<= -1 (:confidence o) 1)))
 
+(set (cons :data argument-keys))
+
 (defn minimise
   "Expecting that `o` is a (potentially rich) proposition, return a map identical
   to `o` save that for each value `v` of key `k` in `o`, if `v` is a map and `k`
@@ -110,7 +117,7 @@
           {k
            (let [v (k o)]
              (if
-               (and (not (argument-keys k)) (map? v))
+               (and (not (preserved-keys k)) (map? v))
                (:id v)
                v))})
         (keys o)))