copernic: versioned structured data, with change-request mechanic, at scale

[Amirouche Boubekki]

I am pleased to share with you the code of copernic.

copernic is inspired from RDF, but much simpler for the time being. It
is a versioned triple store.

demo: http://copernic.space/
code: https://github.com/amirouche/copernic

I do not assume that you will change from AtomSpace to copernic
(overnight), but there might be ideas that might be useful. In
particular, the code rely on generic tuple store, that is a
generalisation of triple and quad store to tuple of n items
(https://math.stackexchange.com/q/3146568/23663). It rely on
FoundationDB.

It support a workflow similar to github's pull-request.

The code is Python and Django. There is no JSON HTTP API available at this time.

sloccout reports 1 054 Python lines of code.

I will release a v0.2.0 in a few hours more likely tomorrow and will
change the license to CC0.

Change-request and Feedback welcome!

--
Amirouche ~ https://hyper.dev

[Linas Vepstas]

Hi Amirouche;

Here's a hot take:

* Versioning. I thought long and hard about versioning in the atomspace, but came to the conclusion that direct support for it was low priority, and impractical. It's impractical, because atomspace contents churn: If you version only atoms, you might generate thousands of version per second. If you version truth values, this could jump to much higher numbers.  If versioning was really needed, it would need to be per-data-subset.  (The ContextLink is a form of versioning, but its not "automatic".)

* Tuples. The AtomSpace explicitly avoids tuples; a "list" of atoms can be of arbitrary size, and of mixed type. Also, atomspace links are nested: they form trees, and so have a structure beyond that of a flat list. This makes it much easier to represent complex relationships.

You mentioned link-grammar and leading-edge research in another email. The main, primary understanding or "light bulb" that has gone off in my mind, my "ah hah!" moment, revolves around the understanding that a very important, fundamental data structure is a tree with connectors-as-leaves.  I've sometimes called such things "jigsaw puzzle pieces". You will see the jigsaw puzzle-piece analogy in both the original link-grammar papers, and in newer work on category theory (both in e.g. Bob Coecke's work, but also in things like Baez&Stay's "Rosetta Stone")

I have two unfinished, unresolved hypothesis about this structure.

1) Connectors can replace both variables (lambdas), and combinators, and are superior to both.  So lambdas are almost 100 years old now, are turing complete, are the internal language of cartesian-closed categories, etc. etc. Proven track record, of great utility.  Combinators were invented to eliminate variables, but quickly turned out to be unmanageable: combinator strings rapidly become huge and unreadable. 

So, back to lambdas+variables: this works reasonably well, but one then has to invent algorithms like "unification", and unification shows up fairly early in term-rewriting discussions. Variables also need the notion of alpha-equivalence, and explicit code to perform alpha-renaming (or be bruijn indexes, etc.).  Variables sometimes need to be quoted: thus, quote, quasiquote, unquote. These seem to be OK for strings, but cause problems when you want to quote a graph: you have to delineate the portion of the graph to be quoted, and that's hard.

So the hypothesis is that connectors can take the place of variables. Instead of beta-reducing (plugging a value into a slot), one instead hooks up two opposing connectors (the jigsaw puzzle tabs). Just like beta-reduction, the connection is still one-to-one. I think this solves (or simplifies) the unification, alpha-renaming and quoting issues. On the one hand, a connector looks like a variable, but a connector also looks like a value: the two plug together. Individual jigsaw pieces look like combinators, since they are variable-free, but do not have the intractable messiness of combinators. It's an ideal middle-ground.

Second hypothesis

2) jigsaw/connectors are an idea way to unify neural nets (vectors, vector spaces, weights, tuples) with symbolic logic/symbolic reasoning. This is due to a theoretical concept called a "sheaf" which allows you to glue together a collection of "flat things" (vector spaces, tangent spaces) into a "curved thing" (a manifold, a fibre-bundle) (via a kind-of filtration or grading, with different grades gluing up, for example as in enveloping algebras/PBW). Classical math (e.g. algebraic topology) has a well-developed theory of sheaves, but that theory passes over, without modification, onto graphs (mostly because modern treatments of homotopy depend on category-theoretic notions like "skeletons" and etc. which can be, more or less, understood to be graphs, in a very low-brow, unsophisticated kind of way.)  I'm fairly certain that this provides a natural way of "gluing" (a la "gluing axioms") together neural nets into more sophisticated structures that can represent symbolic knowledge (thus solving the ancient question from philosophy: "What does a symbol refer to?", e.g. Plato's abstract notion of an ideal chair.)  Whatever, this is an avenue of research I'm sure is fruitful, but am having trouble convincing anyone, and am having trouble focusing due to financial constraints (wife, kids, life in general)

So I'm looking at future iterations of the atomspace as trying to make forward progress in both of these two areas at the same time.

-- Linas

 

--
You received this message because you are subscribed to the Google Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAL7_Mo97B2or8vt_WtYX0u3Ay1JNe-VYJK4S1eag8MFCXfimGA%40mail.gmail.com.

--

cassette tapes - analog TV - film cameras - you