Spherical Database Characteristics and Invariants
Items: details and contexts
- Details are contained in contexts.
- Contexts are details with contents.
- Contexts can be contained within - be details of - other, encompassing contexts.
- Contexts and details are both items.
- Different aspects of items can belong in more in different contexts. Aspects of contextual items (containers) that belong in more than one context can have different constituents across those contexts.
- eg (classic database), a person's address is different in their personal context versus in their work context
- eg (perspective), the salient details of a project vary according to engineering, finance, operations...
- eg (information management/log), some of a project's pending efforts yesterday may be different than they were the day before, or a year ago, or are scheduled to be tomorrow...
- eg more generally (change management), the aspects of an item can have similarities and differences over time and across branches.
- Contextual containment is a kind of scope, delineating a lexical relationship between the container and contained
- Relationships contained within sub-contexts are qualified by the encompassing container.
eg, a person's work address in the context of one employer is different than that person's work address n the context of another employer.
- This scoping realizes spherical containment.
- The differing relationships constitute context-specific categories/classification.
Like HTML5 scoped microdata.
Spaces, Congruence, and Federation
- Spaces are coherent collections of items organized by containment.
A space is an instance of a spherical database. It might be a file, a web location, an object database, etc.
- Manifestations of an item in different places are congruent to each other.
- This is a way of saying that they are the same item, but not restricted to being identical. Specifically, they can have different constituents in different contexts.
With congruence, spherical containment exists across an arbitrary number of dimensions.
- Spaces provide the means for a few kinds of synchronizations between their congruent items:
- No synchronization - the constituents of the instances can be changed independently.
- Bi-directional - changes made to any of the congruent copies of an item are propagated to the others.
- One-directional - only one instance of the item, in one context, can be changed. The congruent copies are changed accordingly.
- Spaces provide for stable external references to items they contain.
- Spaces provide for tracking internal relocation and removal of their items.
- Spaces provide the means for registrations for external notifications of changes to items they contain.
Stable external references and update notifications provide interface protocols for federating spaces by extending congruence relationships across them. External propagation of changes is inherently loosely coupled. Different propagation regimes are suitable for different relationships, particularly for bi-directional synchronization where version drift and reconciliation is feasible. These regimes, and related stuff like capability and capacity authority/rights, etc, could be expressed using these extensible organizations - spherical databases - themselves. Developing such expression is my aim.