X-Git-Url: http://www2.svjatoslav.eu/gitweb/?p=sixth-data.git;a=blobdiff_plain;f=doc%2Findex.org;h=d58e2e32e9132b9abcb2fc14e8424c53a1022da0;hp=42a9704a411a23bd79f0eeaad2c3e411ce8673fa;hb=c2e5bc51afcb4776720ff274596bd68595f793d7;hpb=bb7b2daf4049f53eefbde9912daca7f31a3b6717

diff --git a/doc/index.org b/doc/index.org
index 42a9704..d58e2e3 100644
--- a/doc/index.org
+++ b/doc/index.org
@@ -28,18 +28,23 @@
 #+HTML_HEAD: </style>
 
 * Vision / goal
-Provide versioned, clustered, flexible, object-relational database
-functionality for the [[http://www2.svjatoslav.eu/gitbrowse/sixth/doc/index.html][Sixth computation engine]].
-
-+ I hate object-relational impedance mismatch.
-
-+ I don't like to convert data between persistent database and runtime
-  objects for every transaction. How about creating united
-  database/computation engine instead to:
-  + Eliminate constant moving and converting of data between 2 systems.
-  + Abstract away difference between RAM VS persistent storage. Let
-    the system decide at runtime which data to keep in what kind of
-    memory.
+  :PROPERTIES:
+  :ID:       f6764282-a6f6-44e6-8716-b428074dd093
+  :END:
+Provide versioned, clustered, flexible, distributed, multi-dimensional
+data storage engine for the [[http://www2.svjatoslav.eu/gitbrowse/sixth/doc/index.html][Sixth computation engine]].
+
++ Speaking of traditional relational database and object oriented
+  business applications:
+  + I hate object-relational impedance mismatch.
+
+  + I don't like to convert data between persistent database and
+    runtime objects for every transaction. How about creating united
+    database/computation engine instead to:
+    + Eliminate constant moving and converting of data between 2 systems.
+    + Abstract away difference between RAM VS persistent storage. Let
+      the system decide at runtime which data to keep in what kind of
+      memory.
 
 ** Inspiration
 + Relational databases:
@@ -53,38 +58,27 @@ functionality for the [[http://www2.svjatoslav.eu/gitbrowse/sixth/doc/index.html
   + (Git as a database:
     https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/ )
 
-** Solution (the big idea)
-I see 4D data structure.
-
-[[file:data model.png]]
-
-Dimensions:
-+ List of all the objecs in the system (rows).
-+ List of all declared unique object fields (columns).
-+ List of all historical transactions/commits/versions (think of
-  sheets of paper).
-+ List of all concurrently running branches/threads. Branches can
-  appear and merge over time as needed.
-+ (Every cell is concrete field value within an object)
-
-Partitioning/clustering:
-+ Why not to partition/(load balance) as required across networked
-  physical computers along arbitrary dimension(s) declared above ?
-
-Indexing (for fast searching):
-+ Why not to index along arbitrary dimensions (as required) ?
-
-Further optimizations:
-+ In current early stage, trying to focus on minimum possible set of
-  features that would provide maximum possible set of power/benefit :)
-+ Once featres are locked. Anything can be optimised. Optimization for
-  size (deduplication) can be solved using Git style content
-  addressible storage mechanism.
++ Brain (appears to have more than 3D dimensional design. Food for
+  thought...)
+  + https://singularityhub.com/2017/06/21/is-there-a-multidimensional-mathematical-world-hidden-in-the-brains-computation/
+    + From there comes following idea: Maybe every problem can be
+      translated to geometry (use any shapes and as many dimensions as
+      you need). Solution(s) to such problems would then appear as
+      relatively simple search/comparison/lookup results. As a bonus,
+      such geometrical *data storage* AND *computation* can be
+      naturally made in *parallel* and *distributed*. That's what
+      neurons in the brain appear to be doing ! :) . Learning means
+      building/updating the model (the hard part). Question answering
+      is making (relatively simple) lookups (geometrical queries)
+      against the model.
+
 * Current status
-- Implemented very simple persistent key-value map.
+- More or less defined [[id:f6764282-a6f6-44e6-8716-b428074dd093][Vision / goal]].
 
-Long term goal is to implement more advanced features on top of this.
+- Implemented very simple persistent key-value map.
+  - Long term goal is to use it as a backing storage engine and
+    implement more advanced features on top of this.
 
 * TODO
-** check out Magma
++ check out Magma
   + http://wiki.squeak.org/squeak/2665