Object taxonomy documentation

1 files changed, 226 insertions, 0 deletions

diff --git a/docs/object-taxonomy.org b/docs/object-taxonomy.org
new file mode 100644
index 0000000..ec284eb
--- /dev/null
+++ b/docs/object-taxonomy.org
@@ -0,0 +1,226 @@
+* 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. 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. It
+records the information necessary to understand the logical conditions
+under which a relation value is a semantically consistent
+representation of its intended group.
+
+* 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.
+
+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.
+
+* 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.
+
+* 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.