What the engine does with each term of its own grammar — the answer to "is this
declaration enforced?", which is otherwise only readable by grepping special.clj and
checks.clj.
The question exists because nothing about a declaration's shape says whether anything
reads it. A naming invariant passes on anything correctly spelled, so
(maxCardinality parentOf 2) is a well-formed ternary fact, storable, believed, and
read by nobody — and a KB author gets identical silence from a constraint that is
enforced and one that was never implemented. A roster is what turns that silence into
an answer.
Population: CoreContext's own terms. Not every predicate in the KB — a domain
relation is supposed to be inert, and (likes Fred Mary) asks nothing of the engine.
CoreContext is the vocabulary microtheory, whose charter (see the header of
resources/kb/CoreContext.txt) is exactly "the engine-interpreted special predicates
and the predicate meta-ontology", and its file is term-centric: one (comment <term> …) block per term. So the terms it comments are precisely the grammar, and precisely
the set where "declared but unimplemented" is a defect rather than the normal case.
Two classes, and the distinction is the point. :enforced means some code path
reads it and the KB will refuse, derive, or answer differently because of it — the
:by string says which path, and whether that path is keyed on this functor by name or
is a generic mechanism the declaration merely enrols in. :inert means nothing does,
with :why recording that this is a decision rather than an omission: most of the
inert entries are derived predicate types, which exist so a KB can be queried for
what a mark implies, and are read by no check because the mark itself is what the
checks read.
What keeps it honest is audit, and two tests over it: a term CoreContext comments
with no roster entry fails, and a roster entry naming a term CoreContext no longer
comments fails. So the next plausible-looking functor cannot land unimplemented in
silence, and a retired one cannot leave a stale claim behind. The :enforced side is
cross-checked against special/entries as well, which is machine-readable: a functor
the table gives an arm to and the roster calls inert is a contradiction, not a matter of
opinion.
Why the answer does not live in the ontology. A (notEnforced P) marker was the
obvious alternative and is self-defeating — it would be a declaration the engine does
not read, which is the exact defect this namespace exists to find. Putting it in each
term's comment prose is worse: nothing can check prose without matching strings, so it
would drift the first time a check was added and the sentence was not. A roster in code
drifts too, but a test can see it drift.
What the engine does with each term of its own grammar — the answer to "is this declaration enforced?", which is otherwise only readable by grepping `special.clj` and `checks.clj`. The question exists because nothing about a declaration's *shape* says whether anything reads it. A naming invariant passes on anything correctly spelled, so `(maxCardinality parentOf 2)` is a well-formed ternary fact, storable, believed, and read by nobody — and a KB author gets identical silence from a constraint that is enforced and one that was never implemented. A roster is what turns that silence into an answer. **Population: CoreContext's own terms.** Not every predicate in the KB — a domain relation is *supposed* to be inert, and `(likes Fred Mary)` asks nothing of the engine. CoreContext is the vocabulary microtheory, whose charter (see the header of `resources/kb/CoreContext.txt`) is exactly "the engine-interpreted special predicates and the predicate meta-ontology", and its file is term-centric: one `(comment <term> …)` block per term. So the terms it comments are precisely the grammar, and precisely the set where "declared but unimplemented" is a defect rather than the normal case. **Two classes, and the distinction is the point.** `:enforced` means some code path reads it and the KB will refuse, derive, or answer differently because of it — the `:by` string says which path, and whether that path is keyed on this functor by name or is a generic mechanism the declaration merely enrols in. `:inert` means nothing does, with `:why` recording that this is a decision rather than an omission: most of the inert entries are *derived* predicate types, which exist so a KB can be queried for what a mark implies, and are read by no check because the mark itself is what the checks read. **What keeps it honest** is `audit`, and two tests over it: a term CoreContext comments with no roster entry fails, and a roster entry naming a term CoreContext no longer comments fails. So the next plausible-looking functor cannot land unimplemented in silence, and a retired one cannot leave a stale claim behind. The `:enforced` side is cross-checked against `special/entries` as well, which is machine-readable: a functor the table gives an arm to and the roster calls inert is a contradiction, not a matter of opinion. **Why the answer does not live in the ontology.** A `(notEnforced P)` marker was the obvious alternative and is self-defeating — it would be a declaration the engine does not read, which is the exact defect this namespace exists to find. Putting it in each term's `comment` prose is worse: nothing can check prose without matching strings, so it would drift the first time a check was added and the sentence was not. A roster in code drifts too, but a test can see it drift.
(audit kb)Classify every term vocabulary-context declares in kb:
{:enforced [[term "where"] …]
:inert [[term "why"] …]
:unclassified [term …] ; declared, and the roster says nothing — the defect
:retired [term …] ; the roster claims a term the KB no longer declares
:contradicted [term …]} ; called inert, but the special table gives it an arm
:unclassified is what this exists for: a declaration that landed without anybody
deciding whether the engine reads it. :retired is the mirror — a claim about a term
that is gone, which is how a roster goes quietly wrong. :contradicted is the check
that needs no judgement at all.
Vectors sorted by term, so two runs over one KB compare.
Classify every term `vocabulary-context` declares in `kb`:
{:enforced [[term "where"] …]
:inert [[term "why"] …]
:unclassified [term …] ; declared, and the roster says nothing — the defect
:retired [term …] ; the roster claims a term the KB no longer declares
:contradicted [term …]} ; called inert, but the special table gives it an arm
`:unclassified` is what this exists for: a declaration that landed without anybody
deciding whether the engine reads it. `:retired` is the mirror — a claim about a term
that is gone, which is how a roster goes quietly wrong. `:contradicted` is the check
that needs no judgement at all.
Vectors sorted by term, so two runs over one KB compare.(classify term)What the engine does with vocabulary term term: {:enforced "where"},
{:inert "why"}, or nil for a term the roster does not cover.
Nil is not "nothing reads it" — the roster's population is CoreContext's grammar, so an ordinary domain predicate is simply not a term this question is asked about.
What the engine does with vocabulary term `term`: `{:enforced "where"}`,
`{:inert "why"}`, or nil for a term the roster does not cover.
Nil is **not** "nothing reads it" — the roster's population is CoreContext's grammar,
so an ordinary domain predicate is simply not a term this question is asked about.term -> {:enforced "where"} or term -> {:inert "why"}, over every term
CoreContext comments.
The :by prose names a code path, so it is the thing to update when one moves — and
audit is what notices when a term moves without it.
`term -> {:enforced "where"}` or `term -> {:inert "why"}`, over every term
CoreContext comments.
The `:by` prose names a code path, so it is the thing to update when one moves — and
`audit` is what notices when a *term* moves without it.The microtheory whose terms this roster is about. core-context/load-into names the
same symbol; it is the one context whose contents are the engine's own grammar.
The microtheory whose terms this roster is about. `core-context/load-into` names the same symbol; it is the one context whose contents are the engine's own grammar.
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 |