Hi Ben, I responded to Mike's email before I saw yours. I have to leave the house in 10 minutes, so very fast reply: -- The DAS distributed AtomSpace documents are old and stale and describe ideas that have already been tried and discarded (cause they did not work). I mean, there are good ideas in there two, but its all tangled up. -- The "File:Episodic storage design.pdf <https://wiki.opencog.org/w/File:Episodic_storage_design.pdf>" from Vitaly describes something that has already been implemented and debugged and is in current use. In deference to Vitaly, you, others, I don't want to edit that wiki page and just say "done already" -- and thus I'm thinking a formal process to track status would be a good idea. -- Dagim, etal's File:Episodic Memory Design for Virtual Assistant.pdf <https://wiki.opencog.org/w/File:Episodic_Memory_Design_for_Virtual_Assistant.pdf>proposal overlaps with another half-finished proposal for a more general variant of the same thing. That should be resolved to avoid duplicated work. -- Alexey Potapov's ideas in File:Episodic memory for OpenCog.pdf <https://wiki.opencog.org/w/File:Episodic_memory_for_OpenCog.pdf> are more abstract, but after a very quick skim, they seem like something that can be easily accomplished with minor updates to the existing atomspace (perhaps I am wrong; I just skimmed the thing.)
Overall, I saw nothing particularly earth-shaking, nothing that can't be accomplished with an assortment of shims, plugins, layers, some of which are already half-implemented in the code base. The nature of your email makes me concerned that you might be a bit disconnected with what is already in the code and works well, and with how the foundations have been laid out - literally, foundations, like for a house - groundwork stuff that has been laid out, and is solid, but nothing has been built on it. yet. I'm not clear on how to easily and quickly communicate the current status, and how that would affect your plans. -- Linas On Wed, Aug 4, 2021 at 10:20 AM Ben Goertzel <[email protected]> wrote: > > linus, an outline of the potential new atomspace is here. > > > > To be clear, we (the group of us in SingularityNET working on Hyperon, > alongside our other projects) do not yet have a detailed design for a > Hyperon Atomspace, though we do have a lot of ideas that are in an > intensive form of refinement. > > Our hopeful timeline is > > -- by end of August, to have a coherent, complete-ish description of > the type-system we want for "Atomese2" (the new programming language > that will be used to create and represent structures in the Hyperon > Atomspace). [this is down to Alexey Potapov and myself] > > -- by around the same timeframe, to have a specific proposal for the > distributed-processing and backing-store aspects of Hyperon Atomspace, > leveraging existing key-vector stores and such ... (DAS, Distributed > AtomSpace) > > -- by around Sep 15, to have some decisions on what tools we want to > use for implementing Atomese2 and DAS > > (e.g. what programming language to implement Atomese2, what key-value > stores as the basis for DAS...) > > Note that none of the above are specifically about the in-RAM > "Atomspace" in terms of the containers behind the Atomspace API ... > > It would be possible to have a new Atomese2 language and DAS, working > together with the current Atomspace. On the other hand, if we're > implementing a new Atomese2 and DAS, it may end up being most > effective to implement a new local in-RAM Atomspace as well... this > will be considered in mid-September ... > > Note that the SingularityNET team that is pushing this Hyperon design > initiative is also heavily using the existing OpenCog system, eg for > the Grace humanoid robot software system, for biomedical AI R&D, and > in the ROCCA project aimed at AI agents collectively playing > Minecraft. So the motive for redesigning/rebuilding is not a feeling > that the current Atomspace/OpenCog is bad, but rather that through > this work (and prior work) we are seeing that some things that are > fairly awkward in the current system could be made much > cleaner/easier/more-efficient in a variant system with some different > characteristics... (key examples are real-time learning interactions > btw external deep learning software and OpenCog; and large-scale > logical-inference meta-learning...) > > The Hyperon wiki page contains links to a quite a lot of our > early-stage thinking on all this as it's been evolvlng over the last > year... > > > > > > -- > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/CACYTDBduKz%2BcPHTpmaJvMRJS3Y4y56u6RGrHRzaDVq62Ysy3cA%40mail.gmail.com > . > -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34v-__NAJmN0YNdMSD6CS5AoasSbFBTa3t8gBFOFD2Ynw%40mail.gmail.com.
