Spherical Database Characteristics and Invariants

Contexts

• Contexts are items that have contents.
• Context contents can be simple string attributes or other contexts with contents.
• A context can effectively be present in more than one (contextual) container
• A context can contain different contents depending on the context in which it is viewed
• eg databases: a person's address is different in their personal context versus in their work context
• eg point-of-view: project details considered salient vary when between engineering, finance, operations, admin...
• 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 contents of an item can change over time and be different across branches.
• In order for a context's contents to vary depending on container, the instances must be distinct yet also retain track of the original identity
• 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.