Provides an implementation of McCarthy's `amb` operator with
binding forms and acceptance test operator.

Constraints solving functions that operate on a Constraint Description
which is a map describing a constraint description containing the mappings:
- :variables -> seq of LVars
- :formula -> list describing a predicate expression composed of a mix of
  the LVars in :variables and Clojure functions.

Most functions in rv work off of one or more of the following core
concepts:

Entity: a hashmap with a :kb/id key mapped to a unique value and namespaced keys.

{:kb/id       :person/john-doe
 :person/name "John Doe"
 :person/age  42}

Table: a set of hashmaps or Entities. Tables represent unstructured or
semi-structured collections of data.

#{{:kb/id :city/blt :city/name "Baltimore"}
  {:kb/id :city/atl  :city/name "Atlanta"}}

Fact: a vector triple in the form [entity-id attribute value] that describe that
a given entity has an attribute with a specific value. You can tie facts together
by referencing their :kb/ids.

[:person/john-doe :person/age 42]
[:city/blt :city/name "Baltimore"]

Relation: a set of Facts pertaining to a particular Entity. You can tie facts
together by referencing :kb/ids in value positions.

#{[:person/john-doe :person/age 42]
  [:city/blt :city/name "Baltimore"]
  [:person/john-doe :address/city :city/blt]}

LVar: a logic variable that can unify with any value in its :range

(map->LVar {:domain 'x :range (range 0 5)})

Ground: a concrete value, like a keyword, number, string, etc.

42, "John Doe", :city/blt

Query: a set of Facts containing a mix of LVars and Grounds used  to find
bindings for the LVars that satisfy a set of Facts.

Rules: a set of Facts describing derived or synthetic relations in terms of
existing ones.

Production: a map containing :antecedent -> query and :consequent -> Facts
to be asserted if the query fires.

KB: a set of Relations about many Entities and possibly containing Productions. It
represents all the knowledge currently known or derivable.

Engine: describes how a KB is processed, including: which matching Production fires
next, how the stream of successive Facts are shaped, and how to know when to stop.

Constraint Description: a set of LVars and a Formula describing the domain
of their values.

Formula: a list describing a predicate expression of mixed LVars and clojure functions.

A minimal implementation of Datalog.

I came across the Soundex algorithm when researching the retro KAMAS outlining application.
Soundex is a phonetic algorithm for indexing words by sound.

Provides internal unification functions.
DO NOT USE THIS NS.
There is no guarantee that it will remain stable or at all.

Common learning-related functions and protocols.

Version spaces are a binary classification, empirical learning algorithm.
The approach, as described in 'Version spaces: a candidate elimination approach
to rule learning' by Tom Mitchel (1977) takes training examples (currently
Tuples of a like-arity) and manages a 'version space'. A version space is a
map containing two 'boundaries' `:S` and `:G`. The `:G` boundary contains 'hypotheses'
corresponding to the most general versions of the training data that are consistent
and `:S` is the most specific versions. When a version space is presented with a new
example it runs a 'candidate elimination' algorithm to modify the boundaries `:S`
and `:G` accordingly. Examples can be marked as 'positive' examples, meaning
that they are preferred instances. Anything not marked as 'positive' are taken as
negative examples. Once trained, a version space can  classify new examples as
`::positive` or `::negative`. If new examples are not covered by the existing hypotheses
in either boundary then they are classified as `::ambiguous` instead.

The simplest possible production rules system. A run pairs two
abstractions: a knowledge base (facts + rules) with an engine (a
rule-selection strategy paired with a quiessence-detection strategy).

A production rules system is built from two abstractions:

  1. A knowledge base is the rules and the facts they operate on (the WHAT)
  2. An engine is the policy that applies the rule processing (the HOW)

Productions are represented as maps having two privileged keys:
{:antecedent ...
 :consequent ...}

The :antecedent key in the production map contains a sequence of EAV
3-tuples with logical variables at key locations for the purpose of
pattern matching:

  [[?id :person/name     "Fogus"]
   [?id :language/speaks ?lang]]

The antecedent describes the patterns that must be present in the EAV
set in order for the production to activate. The antecedent is also
known as the left-hand-side (LHS) of the production.

When a production activates, the structure in the :consequent key in
the production map is applied to the knowledge base to potentially
create new facts. The consequent also contains a sequence of EAV
3-tuples with logical variables at key locations. However, these tuples
describe new facts with values bound to embedded logic variables as
defined within the antecedent context of a production activation.

A production set is a data structure defined as such:

  1. A production set is simply a vector of production definitions
  2. A production definition is a map containing :antecedent and :consequent keys
  3. An antecedent is a vector of EAV 3-tuples representing patterns in data
  4. An EAV 3-tuple is a vector of three elements: id, attribute, value
  5. A consequent is a vector of EAV 3-tuples representing new attribute assertions

A fact base is a set of EAV 3-tuples.

A knowledge base is a map of productions and facts, mapped to keys:

{:productions #{...}
 :facts       #{...}}

An engine describes how a knowledge base is processed: which
matching production fires next, how the stream of successive fact sets
is shaped, and how quiessence is detected:

:rule-choice -> fn to pick which production fires next
:state-xform -> transformer of fact-set states
:quiesce     -> a completing reducing function that detects when to stop

The production rules system implemented herein runs an engine against
a knowledge base in four stages:

  1. Antecedent unifications over the KB's facts
  2. Production selection via the engine's :rule-choice
  3. Consequent substitution and assertion
  4. System quiessence via the engine's :quiesce, through :state-xform

Common search-related functions and protocols.

A* search implementation.