Linas, About DAS (Distributed Atomspace), this file
https://wiki.opencog.org/wikihome/images/1/16/Distributed_Atom_Space_-_Requirements.pdf reviews four potential use-cases in moderate detail. It would be very interesting to understand what you think is the shortest path to fulfilling the requirements outlined for these use-cases, via creating policies that leverage the mechanisms you've created using RocksDB. I am being very literal here, I would love to understand what your thinking is in this regard. I understand there are some aspects of that document, like the assumption of UUIDs, that you don't like, but I think the outline of the use cases and the queries involved in them is basically independent of any of these "questionable" assumptions. I would also be interested to understand what if any are the key differences between your approach and Figure 6 of https://wiki.opencog.org/wikihome/images/f/fd/Distributed_Atom_Space_-_Architecture.pdf It seems to me that the role played by the "Atom DB" in that Figure, which is a key-value store, could potentially be fulfilled by your RocksDB backing store. But maybe I'm missing something. Adam wrote: >> The distributed use case would usually be when you have a compute cluster >> and you want to distribute data and tasks across its units - so for example >> you might have 100 machines there with a sharded AtomSpace and want to make >> a query such that all these shards get analysed and results pooled together >> in the end (a la MapReduce). >> I do not know much about distributed computing myself but there would have >> to be some sort of orchestration process, ideally this would all be >> integrated with modern tools for cluster management like Kubernetes. So in the distributed Atomspace architecture high level sketch linked above, the sharding of the distributed Atomspace is packed into the internals of the key-value store. If you want to have a distributed AI process that acts separately on each shard, that is do-able but subtle-ish. Suppose we have N machines, each of which has on it -- an AI process (e.g. say some PLN logical reasoning) -- a local Atomspace (in RAM) -- a piece of the distributed persistent Atomspace, say in RocksDB Then of course the AI process on machine X can query the local Atomspace specifically as it wishes. If it wants to query the persistent backing store, it can query RocksDB and it will get faster response if the answer happens to be stored in the fragment of RocksDB that is living on the same machine as it. There will be some bias toward the portion of the distributed RocksDB on machine X having Atoms that relate to the Atoms in the local Atomspace on machine X ... but this depends on the inner workings of RocksDB. Or at least that's how I'd think it would work, this is speculative... Management of all these Atomspaces, AI processes and RocksDB portions indeed should likely be done using Kubernetes and other commonplace scalable tools... > We have a kind-of dysfunctional mode of operation in opencog-land. Everyone > is very eager to provide requirements, to suggest ideas. When those > requirements, ideas show up in code, well, it turns out that no one was > actually interested in using them. Discussions are great, sure; I'd like to > see more discussion. But there also has to be an implicit agreement, > understanding: if what you wanted showed up tomorrow, would you still want > it? Long experience shows the answer is usually "no". People ask for stuff, > and then come back and say "never mind". > > (This is one of the primary pitfalls of "requirements gathering" in software.) We (meaning SingularityNET) have a decently-funded commercial project that uses the current Atomspace/OpenCog (Awakening Health, a JV with Hanson Robotics). We are also doing, as you know, genomics research using bio-Atomspace and PLN. And exploratory R&D using both Hyperon prototype and current Atomspace to control agents playing Minecraft (still early stage). So OpenCog improvements that are genuinely useful in these applications... will be used... ben -- 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/CACYTDBcNngevGAu-79SZHe-yQiwhkbUWwkxWUpD0Q2yAH6Y3JA%40mail.gmail.com.
