Limited OWL reasoning, materialized into the pod

[tophcodes]

Limited OWL reasoning, RDFS and something in the OWL-RL neighbourhood, materialized into the
pod, reusing the machinery #63 builds rather than growing a second one.

Query-time entailment is not on the table: Oxigraph's documentation describes SPARQL query and update and claims no entailment regime, so inferences have to be materialized somewhere. That makes placement a design question rather than an implementation detail.

What reuses #63 directly

Derived output is one named partition per producer (#65), read-only, replaced rather than merged, visible through containsGraph, and carrying its own provenance (#75). The authority argument from #63 carries and arguably carries better: an entailment is by definition something the user already said, written out.

The configuration is an auxiliary of its own kind, /.aux/{subject}.entail, holding the
logic, alongside .extract (#66). The inheritance and defaults rule should be defined once
for the family of interpreted auxiliary kinds rather than per kind.

What does not reuse it, and needs its own answer

Input scope. Extraction is intra-resource: the bytes of a subject produce triples about that subject, so its invalidation is a single key. Entailment needs a TBox that lives elsewhere, possibly in another pod, and often triples from other resources. The input is a set, not a subject.

The invalidation trigger. Reconcile watches bytes; an ontology changing is not a byte changing in the vault, so nothing in #70 fires. Two mechanisms, and they are complements rather than alternatives:

• the configuration declares what an entailment depends on: this ontology, this subtree, so a write to a declared dependency marks the dependent partitions stale. Cheap, needs no analysis, and the graph stays small.
• a partition records the version of the ontology it was computed against, which makes staleness detectable rather than only triggerable. Without it, a wrong or missing declaration preserves false inferences silently.
• a periodic full run under a long debounce is the backstop for exactly that case. The debounce machinery exists from Reconcile: what triggers it, what it walks, and what it must skip #70 with a different constant.

Where pod-wide output goes. A whole-pod run produces triples about many subjects at once
and has no single subject to hang them on. /.aux/.meta, the root container's own
description resource, is the natural home, and it fits the existing scheme without inventing
anything: the root is a subject like any other. Two costs to state rather than discover:

• triples about /person/alice sitting in the root's .meta are not discoverable from /person/alice, whose describedby link points only at its own. The internal SPARQL endpoint sees everything, so this bites link-following HTTP clients rather than queries.
• it is the one resource that grows with the pod, which makes it the sharpest test of the size and ETag handling in Projection: TriG for .meta, symlink targets, and a size that lives nowhere #71.

"Over" versus "from" the subject. #64 and uri-space.md describe .meta as the index over its subject. Entailment systematically produces triples about other subjects, so either the wording becomes "derived from the subject", or such triples are dropped and the inference is incomplete in a way that has to be written down.

Not now

Fourth stage on a machine whose first stage is not built. Filed so the analysis is not lost,
and because two decisions in #63, the family naming in #66 and the provenance placement in
#75, are cheaper to get right while this is in view.