The current atomspace abstraction is that there is a unique, independent key-value store *per atom*. Think of each atom being an independent database. Just like any normal key-value database, its not indexed, not searchable, and thus its very fast, and great for volatile knowledge. But if instead you want structured data that is searchable, then instead, use Atoms, and not Values - however atoms are slower, bulkier; the relationships they partake in are immutable.
Using your notation, I'm tempted to write (vertex-of-graph, key, value) as the core atomspace structure, but that would be grossly misleading, precisely because the two parts of the atomspace (the Atoms, and the Values) are so very different from each other, in terms of performance, in terms of the kind of data they are best suited for. Some algos work best on atoms, others work best on values; by having a system that integrates both kinds, perhaps we have the best of both worlds. That, at least, is the hope. --linas On Wed, May 2, 2018 at 1:27 PM, Amirouche Boubekki < [email protected]> wrote: > > > On Sunday, February 18, 2018 at 4:40:08 PM UTC+1, Amirouche Boubekki wrote: >> >> I think I found the correct union of features that would be helpful in a >> data science context. That is a database that works like git or *git for >> data* >> kind of database. >> >> It's mainly inspired from datomic and two papers: >> >> - Git for triples http://www.hyperdev.fr/project >> s/neon/ldow2013-paper-01.pdf >> - Revisions for triples http://www.hyperdev.fr/project >> s/neon/10.1.1.662.1619.pdf >> >> Unlike datomic, the history is direct-acyclic-graph (DAG). That is, *you >> can have branches*. I think that's the feature that makes all of this >> worthy. You can populate your database with wikidata and then create a >> branch to add edits and test your program against both versions of the >> database and compare the results. The data is stored efficiently without >> copying. >> > > You might haved noticed Apple releasing FoundationDB [0]. It's a very > similar database that the storage engine of Neon, except it's distributed. > I support ACID transactions and I think you can not relax that constraint. > Transaction are limited to 5s. The default behavior is to retry tx > indefinitly. > > [0] https://www.foundationdb.org/ > > Which leads me back to Neon. I still think it's useful. > > >> Do you think this kind of database can be useful in your work? >> > > I did not end writing the full RDF specification. Right, now what it does > is filter four tuples in the form (namespace, uid, key, value) or if you > prefer (namespace, graph, key value) or encore (graph, subject, predicate, > value). I read the book that talks about representations of knowledge in > the indistruby, like done in commercial knwoledge bases. It doesn't say > anything about AtomSpace at all :( > > I am rather confident at this point in time. The (graph, subject, > predicate, key) tuples allow to represent a lot of things, especially when > there is an ordering in the tuples. A global order or watt ever. In neon, > it's not the case right now since graph subject predicate and value are > string of scheme values serialized with write, even if I used msgpack it > won't work as expected because it doesn't preserve the correct order > between the tuples. > > So, I need to write a packing function I deleted from my hard disk and > need to do some archeology in my past attempts at building a scalable > knowledge database that is ameable to easy coding with better constraints > that would allow to discovers things more quickly. > > The underlying storage is (graph subject predicate point-int-ime) where > point-int-ime is a directly acyclic graph or if you prefer a forst of > trees. You can think it's linear like SVN but it doesn't change a lot. > Another optimal optimization wolf be to > > I need your help to decide a quest=on, do you prefer Python or Gu7e? > > Who is up for the task of implementing the second best? > > [1] https://forums.foundationdb.org/t/neon-a-versioned-quad- > store-that-works-like-git-requires-a-lock/305 > [2] https://github.com/amirouche/neon/blob/master/doc/ > MOCHA2018/preview/neon-mocha-2018-preview.pdf > [3] https://fr.wikiversity.org/wiki/Recherche:Pens%C3%A9es_ > Profondes_et_Dialogues_Pertinents > > > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/opencog. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/opencog/51557b5b-bfb8-4aae-a0cb-280770dfe0b4%40googlegroups.com > <https://groups.google.com/d/msgid/opencog/51557b5b-bfb8-4aae-a0cb-280770dfe0b4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- cassette tapes - analog TV - film cameras - you -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35QzLkBKmmfaf%2BGs8-0Pmbm2sZmHcs7vBWogr8ORjAjDA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
