Skip to content

Data Model

Jump to bottom
Oleksandr Nikitin edited this page Oct 4, 2016 · 8 revisions

Hypergraph of linked facts (observations? events?) with data and metadata

TODO: need better words for fact, provider, etc. need terminology

Fact Structure

  • User

  • tenant owning things that are happening, resource root

  • logical context owner

  • tx time authority

  • TX time

  • logical time, causal, relative to other TX times, usually serialized at physical_viewpoints

  • may contain links to ptime but this is hard to do and better done in logical context

  • Space/Universe/Provider/Repository

  • managed or unmanaged object provider/locator/sync channel/index (materialized view)

  • logical storage/repository too

  • provider of rules for the logical context

  • side effect handler

  • may also be a canonicalization rule provider

  • Physical Viewpoint

  • representation/reflection of an inference agent/system performing the derivations, required to reason about performance and resources

  • contains users, providers (many-to-many), indices

  • Logical Context

  • user-chosen subset/viewpoint of the universe containing inference traits/flavors

  • inference rules, coercion/canonicalization rules (always logical, don't belong to universe apart from physical_viewpoint), construction/deconstruction rules

  • acquisition keys like precision or source trust

  • target context eg criteria of what data we choose to use/disclose, permissions belong here

  • logical_viewpoint eg the task that we're currently solving, or just session (timeline + state)

  • Fact / Event Locator

  • physical time, relative to universe, stuff like GPS coordinates also belongs here

  • not strictly mandatory but really useful.

  • derivations are logical-context dependent

  • Domain Data

  • may overlap with Event Locator, all other data.

  • derivations are same as event locator data

Object Identification and Canonicalization

  • Objects are identified by "nominal_id:query" where nominal id must be GUID of provider, query may also be ID or it may be filter by event locator
  • Logical context and/or providers give canonicalization relations between providers and/or individual objects. Sync flow and inference flow should respect canonicalization.
  • IDs must not be concatenated into "paths" because same object may totally legally exist at multiple providers.
  • Canonicalization relations are tx-scoped by logical context, and if possible locator-scoped (note the recursion here...)

Sync Model

We totally need to support both state-based and event-based sync, even given the complications that necessarily arise.

State-based sync happens ONLY between managed + unmanaged objects, syncing unmanaged + unmanaged is undecidable.

Clone this wiki locally