More thinking about knowledge representation.
This commit is contained in:
parent
2d395251b5
commit
cf8cb68b38
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
|
@ -57,6 +57,24 @@
|
||||||
he had he must have had accomplices (Cassius and Longus, who clearly were
|
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 implicate one another), but honourable men don't kill with
|
||||||
accomplices and Brutus is an honourable man.
|
accomplices and Brutus is an honourable man.
|
||||||
|
|
||||||
|
## Features
|
||||||
|
|
||||||
|
The `features` in DTree terms we're interested in to make these inferences are
|
||||||
|
|
||||||
|
* `did-kill` - true of an entity which is in the subject position of a `kill` proposition;
|
||||||
|
* `was-killed` - true of an entity which is in the object position of a `kill` proposition;
|
||||||
|
* `buried` - true of an entity which is in the object position of a `bury` proposition;
|
||||||
|
* `dead` - true of an entity of which either `was-killed` or `buried` is true;
|
||||||
|
* `honourable` - true of an entity, provided that `did-lie` and `did-murder` are false;
|
||||||
|
* `did-murder` - true of an entity x that `did-kill[x,y]` for some object y is true of,
|
||||||
|
provided that there exists some other entity p of whom `did-kill[p,x]` is also true,
|
||||||
|
or that `was-unarmed[y]` is true;
|
||||||
|
* `did-lie` - true of an entity which has offered a proposition which for other reasons we do not believe. Tricky. False by default and I think we probably leave it at that for now.
|
||||||
|
* `was-unarmed` - true of an entity at a time `t` if they were unarmed at the time.
|
||||||
|
|
||||||
|
Note that ALL of this is too complex for the simple DTree logic of the Arboretum /
|
||||||
|
KnacqTools generation. They could not unpack propositions as I'm proposing here.
|
||||||
"
|
"
|
||||||
(:require [wildwood.knowledge-accessor :refer [Accessor]]
|
(:require [wildwood.knowledge-accessor :refer [Accessor]]
|
||||||
[wildwood.advocate :refer [Advocate]]))
|
[wildwood.advocate :refer [Advocate]]))
|
||||||
|
|
|
@ -10,7 +10,25 @@
|
||||||
(defprotocol Accessor
|
(defprotocol Accessor
|
||||||
(fetch [self id]
|
(fetch [self id]
|
||||||
"Fetch all the knowledge I have about the object identified by
|
"Fetch all the knowledge I have about the object identified by
|
||||||
this `id` value, as a map whose `:id` key has this `id` value.")
|
this `id` value, as a map whose `:id` key has this `id` value.
|
||||||
(store [self id proposition]
|
|
||||||
"Add this `proposition` to the knowledge I hold about the object
|
*NOTE THAT:* I now think knowledge should only be managed at the
|
||||||
identified by this `id` value."))
|
Wildwood level as sets of propositions, so the idea of bringing
|
||||||
|
back some sort of object representation here is probably wrong.")
|
||||||
|
(match [self proposition]
|
||||||
|
"Return all the propositions I know which match this proposition. The
|
||||||
|
intended use case here is that you will either supply a fully
|
||||||
|
specified proposition to verify that that proposition is true, or else
|
||||||
|
supply a partially specified proposition to query.
|
||||||
|
|
||||||
|
e.g. passing the proposition
|
||||||
|
|
||||||
|
{:verb :kill :object :caesar}
|
||||||
|
|
||||||
|
would be a way of asking 'who killed caesar', and might return
|
||||||
|
|
||||||
|
[{:verb :kill :subject :brutus :object :caesar}
|
||||||
|
{:verb :kill :subject :cassius :object :caesar}
|
||||||
|
{:verb :kill :subject :longus :object :caesar}]")
|
||||||
|
(store [self proposition]
|
||||||
|
"Add this `proposition` to the knowledge I hold."))
|
||||||
|
|
|
@ -38,7 +38,10 @@
|
||||||
(assoc
|
(assoc
|
||||||
(dissoc record :_id)
|
(dissoc record :_id)
|
||||||
:id id))))
|
:id id))))
|
||||||
(store [_ id proposition]
|
(match [_ proposition]
|
||||||
|
;; I know I've seen how to do this in the Mongo documentation...
|
||||||
|
)
|
||||||
|
(store [_ proposition]
|
||||||
;; don't really know how to do this and am too tired just now.
|
;; don't really know how to do this and am too tired just now.
|
||||||
))
|
))
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue