How a read client reaches a KB — directly in-process, or over the daemon HTTP API
(vaelii.impl.serve). It re-exports the slice of the vaelii.core read surface the
browser uses, so the browser is written once against these names and runs unchanged
against a local KB or a remote daemon.
A target is either a real KB (treated as local) or an access value from local /
remote. A KB-read op dispatches on it:
:remote → the client (vaelii.impl.client/call) — one HTTP round-trip
:local → vaelii.core, via serve/ops (the very allowlist the daemon serves, so
local and remote answer through the same table and cannot drift)
a raw KB → the same local path (so a caller holding a plain KB needs no wrapper)
The pure display fns (term-role, reified-term?, readable-sentence,
indexable-terms, levels)
and the bootstrap fns (open-kb, clear!) take no target and just delegate to
vaelii.core — they are here only so a caller can require this one namespace and
reach the whole surface it needs.
Reads — including check / check-edit, which answer what assert would refuse
and write nothing — plus the three writes the browser performs: edit (an
assert/retract batch in one settle), forward-chain, and preview (which stores
nothing but applies a batch and rolls it back, so it holds the single writer). A remote result is already
EDN-clean (the daemon projects sentex records to maps); a local result is the raw
record, and both answer to the same keys, so a caller handles them identically.
How a *read* client reaches a KB — directly in-process, or over the daemon HTTP API
(`vaelii.impl.serve`). It re-exports the slice of the `vaelii.core` read surface the
browser uses, so the browser is written once against these names and runs unchanged
against a local KB or a remote daemon.
A **target** is either a real KB (treated as local) or an access value from `local` /
`remote`. A KB-read op dispatches on it:
:remote → the client (`vaelii.impl.client/call`) — one HTTP round-trip
:local → `vaelii.core`, via `serve/ops` (the very allowlist the daemon serves, so
local and remote answer through the same table and cannot drift)
a raw KB → the same local path (so a caller holding a plain KB needs no wrapper)
The pure display fns (`term-role`, `reified-term?`, `readable-sentence`,
`indexable-terms`, `levels`)
and the bootstrap fns (`open-kb`, `clear!`) take no target and just delegate to
`vaelii.core` — they are here only so a caller can require this one namespace and
reach the whole surface it needs.
Reads — including `check` / `check-edit`, which answer what `assert` would refuse
and write nothing — plus the three writes the browser performs: `edit` (an
assert/retract batch in one settle), `forward-chain`, and `preview` (which stores
nothing but applies a batch and rolls it back, so it holds the single writer). A remote result is already
EDN-clean (the daemon projects sentex records to maps); a local result is the raw
record, and both answer to the same keys, so a caller handles them identically.(ask target & args)(ask? target & args)(believed target & args)(chain-stats target & args)(check target & args)(check-edit target & args)(conflicts target & args)(context-size target & args)(contexts target & args)(contradictions target & args)(count-with-arg target & args)(count-with-functor target & args)(defeat-class target & args)(dependent-justifications target & args)(disjoint-metatypes target & args)(disjoint? target & args)(edit target batch)Apply an edit batch to the target, local or over the daemon. batch is
{:add [[sentence context opts?]…] :remove [handles…]}; adds land before removes and
the whole thing settles once (vaelii.core/edit). Both of the browser's mutations —
saving edited sentexes, asserting new ones, retracting a selection — are this one
call, so every write it makes is one settle.
Apply an edit batch to the target, local or over the daemon. `batch` is
`{:add [[sentence context opts?]…] :remove [handles…]}`; adds land before removes and
the whole thing settles once (`vaelii.core/edit`). Both of the browser's mutations —
saving edited sentexes, asserting new ones, retracting a selection — are this one
call, so every write it makes is one settle.(edit-with-consequences target batch)(edit-with-consequences target batch opts)edit, and what the batch turned out to mean — the belief it added and took away
(vaelii.core/edit-with-consequences, docs/preview.md). The browser's commit paths
use this rather than edit so a page can say what followed from a save; the extra
answer is sentences and handles, EDN-clean, so it crosses the wire like any read.
`edit`, and what the batch turned out to mean — the belief it added and took away (`vaelii.core/edit-with-consequences`, docs/preview.md). The browser's commit paths use this rather than `edit` so a page can say what followed from a save; the extra answer is sentences and handles, EDN-clean, so it crosses the wire like any read.
(escalate target & args)(explain-levels target & args)(exposed-clashes target & args)(find-sentexes target & args)(find-terms target & args)(forward-chain target & args)Run the forward-chaining fixpoint over the target's KB — {:derived n :truncated? bool}. A write (it derives and places conclusions), and the browser's one way to
ask what a load's rules would conclude without asserting anything new.
Run the forward-chaining fixpoint over the target's KB — `{:derived n :truncated?
bool}`. A write (it derives and places conclusions), and the browser's one way to
ask what a load's rules would conclude without asserting anything new.(genls target & args)(handle-of target & args)(in? target & args)(isa? target & args)(justification target & args)(local kb)A local access over the in-process KB kb (optional — a raw KB works directly too).
A local access over the in-process KB `kb` (optional — a raw KB works directly too).
(local-kb target)The in-process KB behind target, or nil when the target is a remote daemon.
Every op above works either way, so a caller that only reads never needs this. It is
for the one thing that cannot go over the wire: handing the KB itself to a component
written against vaelii.core rather than against this facade — the LLM proposal path
reads a term's neighbourhood, its vocabulary and its checks through dozens of calls,
and doing that a round-trip at a time is not a thing to offer a reader. A nil answer
is the honest one: say so, rather than degrade silently.
The in-process KB behind `target`, or nil when the target is a remote daemon. Every op above works either way, so a caller that only reads never needs this. It is for the one thing that cannot go over the wire: handing the KB itself to a component written against `vaelii.core` rather than against this facade — the LLM proposal path reads a term's neighbourhood, its vocabulary and its checks through dozens of calls, and doing that a round-trip at a time is not a thing to offer a reader. A nil answer is the honest one: say so, rather than degrade silently.
(lookup target & args)(metatype-members target & args)(possible-relations target & args)(premise? target & args)(preview target batch)(preview target batch opts)What editing batch would make the target believe and stop believing, without
leaving it done (vaelii.core/preview, docs/preview.md).
Filed with the writes although it stores nothing: it applies the batch and rolls it back, so it holds the single writer for its duration and is not a thing to run beside one. The answer is EDN-clean either way — sentences and handles, no records — so it crosses the wire like any read.
What `edit`ing `batch` would make the target believe and stop believing, without leaving it done (`vaelii.core/preview`, docs/preview.md). Filed with the writes although it stores nothing: it applies the batch and rolls it back, so it holds the single writer for its duration and is not a thing to run beside one. The answer is EDN-clean either way — sentences and handles, no records — so it crosses the wire like any read.
(provable? target & args)(prove target & args)(qualitative-network target & args)(qualitative-scenario target & args)(qualitative-scenarios target & args)(query target & args)(query-plan target & args)(query? target & args)(remote host port)A remote access to the daemon at host:port — builds a client connection the
KB-read ops send over.
A remote access to the daemon at `host`:`port` — builds a client connection the KB-read ops send over.
(sentex target & args)(sentex-count target & args)(sentexes-in-context target & args)(sentexes-matching target & args)(sentexes-with-arg target & args)(sentexes-with-functor target & args)(specs target & args)(supporting-justifications target & args)(term-count target & args)(term-expression target & args)(terms target & args)(types target & args)(types-of target & args)(violations target & args)(why target & args)(why-not target & args)cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |