The CxCore ontology — Vaelii's vocabulary context. It defines and
documents the core predicates the engine interprets, as sentexes in CxCore:
the special-predicate surface (types/contexts, arg, disjoint, the set/*Rule
wrappers, the predicate metadata, negation, ist, the evaluables) and the
predicate meta-ontology. Documentation rides on comment sentexes,
(comment <term> "...") — ordinary sentexes (stored, indexed, queryable) — so the
KB documents itself in its own representation.
The content is a KB file, resources/kb/CxCore.txt (read by
vaelii.host.seed); this namespace loads it and reads the docs back.
CxCore is the spindle head: the root every context sees, and the only
layer a core-only KB has. The layers below it — the definitional upper
contexts (between Core and Universe) and the theory middle contexts (between
Universe and Well) — are the starter's, not the core KB's, and each wires itself
into the spindle in its own KB file (see vaelii.host.starter).
The CxCore ontology — Vaelii's vocabulary context. It defines and documents the core predicates the engine interprets, as sentexes in CxCore: the special-predicate surface (types/contexts, arg, disjoint, the `set/*Rule` wrappers, the predicate metadata, negation, `ist`, the evaluables) and the predicate meta-ontology. Documentation rides on `comment` sentexes, `(comment <term> "...")` — ordinary sentexes (stored, indexed, queryable) — so the KB documents itself in its own representation. The content is a KB file, `resources/kb/CxCore.txt` (read by vaelii.host.seed); this namespace loads it and reads the docs back. CxCore is the spindle **head**: the root every context sees, and the only layer a core-only KB has. The layers below it — the definitional `upper` contexts (between Core and Universe) and the theory `middle` contexts (between Universe and Well) — are the starter's, not the core KB's, and each wires itself into the spindle in its own KB file (see vaelii.host.starter).
(comment-of kb term)The documentation attached to term by comment sentexes, in content order.
Ordered because every caller takes the first one — the vocabulary card, the prompt's
predicate lines, a selection's gloss. sentexes-matching promises the set and not
an order, so a term carrying two comments (the shipped ontology gives each one; a KB
that adds a gloss of its own gives two) would otherwise be displayed with whichever
the index happened to yield first, and the same knowledge loaded in two orders would
read differently. A vector, since the ranking realizes the matches either way.
Ranked through nm/name-key rather than on the value: comment's second argument is a
string by convention and nothing refuses another type, and a comparison of a string
against a number throws where this only has to be total. name-key is str for the
scalar the convention promises and the guarded print-key for anything else, so a
comment written as a compound cannot collapse two entries into one key under an ambient
*print-length*.
The documentation attached to `term` by `comment` sentexes, in **content order**. Ordered because every caller takes the first one — the vocabulary card, the prompt's predicate lines, a selection's gloss. `sentexes-matching` promises the *set* and not an order, so a term carrying two comments (the shipped ontology gives each one; a KB that adds a gloss of its own gives two) would otherwise be displayed with whichever the index happened to yield first, and the same knowledge loaded in two orders would read differently. A vector, since the ranking realizes the matches either way. Ranked through `nm/name-key` rather than on the value: `comment`'s second argument is a string by convention and nothing refuses another type, and a comparison of a string against a number throws where this only has to be total. `name-key` is `str` for the scalar the convention promises and the guarded `print-key` for anything else, so a comment written as a compound cannot collapse two entries into one key under an ambient `*print-length*`.
(load-into kb)Assert the CxCore vocabulary into kb from its KB file
(resources/kb/CxCore.txt). Returns kb.
The topology edge (genlCx CxUniverse CxCore) is asserted before the file, and
it is here rather than in the file because of when it has to hold. A
decontextualized_predicate declaration lifts the facts already present into
CxUniverse, and a rule stated in CxCore fires on the copy — so the two contexts must
already be comparable for that firing to be placed on arrival. The file is read
term-centrically in natural sort order, which puts genlCx after functional; a firing
that finds no placement is re-joined when the edge arrives, so the KB is the same
either way, and asserting the edge first is what spares the load that second pass.
The (forced_decontextualized_predicate genlCx) and (forced_monotonic_predicate genlCx) declarations go in ahead of the edge, so the edge is stored in CxUniverse and
at :monotonic, as the file's own edges are.
Assert the CxCore vocabulary into `kb` from its KB file (resources/kb/CxCore.txt). Returns kb. The topology edge `(genlCx CxUniverse CxCore)` is asserted **before** the file, and it is here rather than in the file because of *when* it has to hold. A `decontextualized_predicate` declaration lifts the facts already present into CxUniverse, and a rule stated in CxCore fires on the copy — so the two contexts must already be comparable for that firing to be placed on arrival. The file is read term-centrically in natural sort order, which puts `genlCx` after `functional`; a firing that finds no placement is re-joined when the edge arrives, so the KB is the same either way, and asserting the edge first is what spares the load that second pass. The `(forced_decontextualized_predicate genlCx)` and `(forced_monotonic_predicate genlCx)` declarations go in ahead of the edge, so the edge is stored in CxUniverse and at `:monotonic`, as the file's own edges are.
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 |