* Branch A branch represents a coherent state of one or more multigroups at a particular point in their history. It holds the references to the multigroups visible from that state and provides an isolated context in which subsequent changes may be expressed. Relations are sets and are therefore not mutated in the set-theoretic sense. Change in the represented world is instead understood as a succession of relation values. The relation predicate establishes the membership criteria of a relation, while its extension consists of the tuples currently asserted to satisfy those criteria. Ordinary changes in facts therefore alter the extension without necessarily altering the intension. Consider an EMPLOYEES relation representing the employees of a company. Hiring a new employee does not ordinarily change what it means to be an employee. Rather, a tuple representing the newly hired employee becomes an asserted member of EMPLOYEES in a later database state. The predicate and constraints defining admissible membership may remain invariant while the extension differs between the earlier and later states. A branch identifies one such coherent state and provides the basis from which another may be produced. Each state names the one it succeeded, under =previous=, so the history of a branch is reached by path. It therefore gives RNT a representation of change without requiring mutation to be part of the relational semantics. How successive states are physically represented, shared, or persisted is an implementation concern. * Schematics Schematics describes the logical constitution of objects known to RNT. For a relation, it describes its attributes, the domains on which those attributes are defined, its predicate and constraints, and its dependencies on other relations. An attribute represents a property in the context of a particular group. Its domain establishes the kind of values the attribute may assume, while constraints establish the conditions under which tuples constitute admissible members of the relation. Constraints involving multiple relations place an individual relation within the wider semantics of its multigroup. Schematics therefore describes more than the shape of a relation, recording the information necessary to understand the logical conditions under which a relation value is a semantically consistent representation of its intended group. Schematics being a protocol forces an object to know its own type through =describe=, which yields a description of a multigroup, of a relation, or of a tuple (for now only these). There is no separate notion of a heading: the type of a relation is the schematics object it points to, and a tuple drawn from that relation is described against the very same type. A tuple description then, carries both the description of the relation it belongs to and the domains its own attributes exhibit, and therefore comparing the two is the admission test (membership criteria). #+begin_src ocaml type description = | Multigroup of multigroup_description | Relation of relation_description | Tuple of tuple_description #+end_src For now, types are only opaque tags carried by attributes, and schema operations preserve this metadata without trying to resolve these tags, comparing types, or checking values against domains. Structural checks, such as rejecting unknown projection attributes, remain valid however. Membership criteria, their evaluation, and constraint derivation are not also implemented. * Namespace A namespace is a component of RNT's hierarchical object/name space. It provides a scope in which names are associated with runtime objects and through which those objects may be located. Namespaces form a tree, allowing objects to be organized under paths such as =/system=. This hierarchy is an administrative property of the kernel rather than a relational property of the objects contained within it. The fact that one object appears beneath another namespace does not, by itself, assert a relationship between the things represented by those objects. Namespaces therefore provide naming, organization, lookup, and scoping without imposing additional semantics on relations or multigroups. * Transaction A transaction is a bounded context in which tentative changes are performed against a branch. It begins from a particular database state and accumulates changes without making those changes part of the committed state until the transaction successfully commits. A transaction provides a protocol through which operations may be committed or rolled back. Committing produces an accepted successor state from the accumulated changes, subject to the fitting constraints. Rolling back discards those changes and leaves the originating state unaffected. Transactions participate in the kernel lifecycle. Disposing of a transaction that still contains uncommitted changes causes those changes to be rolled back. Thus tentative state cannot accidentally become durable merely because the runtime object representing a transaction ceases to be referenced. * Domain A domain is the logical representation of a property and establishes the values and operations appropriate to that property. Attributes appearing in relations are defined on domains. A domain is not merely a physical data type. Its purpose is to give values their logical interpretation and to establish the operations and constraints suited to them. Different attributes may be defined on the same domain when they represent the same kind of property in different group contexts. Domains therefore form part of the semantic foundation on which relation predicates and constraints are expressed. * Group A group is represented in RNT by a relation. The relation has an intension, expressed through its predicate and constraints, and an extension consisting of the tuples asserted as its members in a particular database state. RNT distinguishes relations according to how their membership is established and the role they play in computation. ** Substantial Relation A substantial relation belongs to the factual basis of a multigroup. Its asserted tuples represent facts supplied directly about the world being represented rather than facts obtained solely by relational derivation. For example, EMPLOYEE may be substantial because assertions and retractions of employee tuples represent substantive changes in the state of the company. Hiring an employee adds a fact to the represented state; an employee leaving causes the corresponding fact no longer to be asserted in a subsequent state. "Substantial" does not mean physically stored. Whether a substantial relation is materialized, reconstructed, cached, or represented by some other storage technique is a physical implementation matter. What makes it substantial is its logical role as part of the factual basis from which other facts may be derived. ** Ephemeral Relation An ephemeral relation is produced through relational operations over other relations. Selection, projection, join, and the other relational operations yield relations in their own right, and these results may exist as runtime objects without becoming part of the substantial factual basis of a multigroup. For example, selecting employees whose salary is greater than 1000 and projecting particular attributes produces an ephemeral relation derived from EMPLOYEE. Its tuples are consequences of the facts asserted in EMPLOYEE together with the conditions introduced by the relational expression, which are part of its intension. Ephemeral relations retain provenance and lineage. Provenance identifies the origins of their attributes and other semantic components, while lineage records the derivation through which the relation was produced. This permits RNT to preserve and infer applicable constraints rather than treating an algebraic result as an anonymous collection of tuples. Ephemerality concerns the runtime existence of such a derived value. A derived relation may subsequently be named, cached, persisted, or otherwise given a longer lifecycle without changing the relational fact that it was obtained by derivation. ** Procedural Relation A procedural relation exposes a procedure through a relational interface. Rather than obtaining its extension from a set of asserted base facts or solely from relational algebra over existing relations, membership is established through computation. For example, PLUS[A, B, C] may represent the relation for which C is the sum of A and B, while GREATER_THAN_NATURAL[X, Y] may represent ordered pairs of natural numbers for which X is greater than Y. Such relations can participate in relational expressions in the same manner as other relational operands where their evaluation properties permit it. A procedural relation need not have a finitely enumerable extension. Some may be countably infinite, making it impossible to materialize their complete extension as an ordinary runtime relation value. RNT must therefore distinguish the ability to decide membership, enumerate members, establish the cardinality of a particular invocation, and guarantee termination of an expression consuming the relation. The line that matters (operationally) is not countable vs uncountable sets, but whether the extension can be enumerated to exhaustion. A relation whose extension is uncountable cannot be enumerated at all, so it is excluded by construction rather than by a check: such a relation is given intensionally, by its membership criteria, and offers membership testing without carrying enumeration. A countably infinite relation may be enumerated, but never exhausted, so an expression that must materialize it is the thing to reject. Membership is in any case always intensional! One does not ask whether a value is extensionally among the naturals (for that is very wasteful and naïve), only whether it satisfies the criteria for being one, and the extensional lookup a substantial relation can afford is an optimization that is valid only because admission already enforced those criteria (which will obviously include constraints). Sol, as RNT's total relational language, admits procedural relations only where the required evaluation properties can be established. An unrestricted procedure must not silently introduce partiality or nontermination into an otherwise total relational expression. * Tuple A tuple is a value of a relation rather than an object of the administrative tree. It is not registered with the object manager and holds no name of its own, since it is reached through the relation that asserts it. It remains an object at runtime, carrying Schematics so that it can describe the type it claims. A tuple is a type label together with its attributes. The label names the relation whose criteria the tuple claims to satisfy, which is what allows a tuple to be handed to a multigroup and routed to the relation representing its type, instead of being inserted into a relation chosen by the caller. Admission is then a matter of typing and constraints: the multigroup resolves the label, compares the tuple against the relation's schematics, and applies its predicate and local constraints before the tuple becomes asserted. The label is redundant while a tuple sits inside a relation, since the relation already names the type. It earns its keep for a tuple in flight, which is the admission case. Two representations exist for the same value. The evaluator and the protocols carry tuples as plain values, which is what a cursor yields and what a program receives as bindings. Storage keeps the attributes as their own content addressed subtree, so that two tuples asserting the same thing share one representation, and identical attributes yield an identical address regardless of the order in which they were written. Ephemeral tuples, which are never interned, are values that simply never reach storage. * Multigroup A multigroup represents a collection of related groups and is represented logically by a database of relations considered together under common constraints. Relations within a multigroup are not independent merely because each has its own predicate. Constraints may involve multiple relations and thereby express conditions that must hold of the database as a whole. The multigroup provides the context in which these interrelation constraints acquire their meaning. A multigroup is consequently the principal unit of coherent relational state exposed through a branch. A branch may reference multiple multigroups and determine the particular state of each that is visible from that view of the world. Within a multigroup, relations are grouped into schemas, which for now are only namespaces: \multigroup\[m]\schema\[s]\relation\[r]. The canonical name of an attribute is therefore =m:s:r:a=. * Session A session contains state specific to an interaction between a client environment and the RNT kernel. It establishes the execution context within which requests are interpreted and kernel objects are accessed. Session state may include such things as the active identity, namespace, branch, transaction, open handles, capabilities, and frontend-specific context. This information governs how a client interacts with the kernel but does not alter the logical meaning of the relations being accessed. A session therefore provides continuity across operations while maintaining the separation between frontend concerns and relational semantics. Different frontends may establish different kinds of sessions while ultimately operating on the same relational kernel. * Clock A clock is a kernel coordination object responsible for ordering and dispatching events. It provides infrastructure for work that must occur in response to time, state transitions, or other observable kernel events. A clock may schedule periodic or deferred services, coordinate event delivery, and provide interception points for workflows. It may also participate in mechanisms commonly associated with triggers, where an event causes additional work to be dispatched. Such procedural reactions must remain distinct from relational constraints. A constraint determines whether a database state is semantically admissible; an event handler determines what computation should occur in response to an event. A constraint must therefore not depend for its truth on whether a scheduled or triggered procedure happened to execute. Clock time is likewise distinct from relational time. The clock coordinates execution in the running system, whereas branches and successive database states represent change in the information managed by RNT. A correspondence between the two exists only when that correspondence is explicitly established.