sorry, just unearthed this email. The diagram now looks correct, but I am concerned about emphasis: everything interesting in opencog happens in the main two blocks -- the fact that there just happens to be a compile-time dependency on python, scheme, postgres, cogutils doesn't seem very important. I guess it should be noted, but its not worth a lot of graphical real-estste.
Besides python and scheme, there are also c++ and haskell bindings, and also a REST webapi, and also, a ZMQ binding. The C++ and the REST bindings are in active use. the haskell bindings are exprimental. The ZMQ bindings might have bitrotted. Besides postgres, there is also gearman for distributed processing, and also a binding to the java neo4j database via the zmq bindings. Anyway, none of these things are part of the "architecture", per se; they are all outside of the architecture, they are on the periphery, a way of attaching to the achitecture. The actual architecture is that of the atomspace, and the 100 different atom types, the rule engine, PLN -- that's the actual architecture. These are really what make opencog work. The fact that there's python of scheme of C++ mostly kind-of doesn't matter at all. --linas On Sat, Oct 22, 2016 at 3:05 PM, Apil Tamang <[email protected]> wrote: > Hi Linas, > > Did a little bit of reading around along-side your points. Here's a > diagram I kinda ended up with. It's definitely not exhaustive, but let me > know if is fairly more accurate. As I understand more of opencog, I'll try > to keep updating it. > > > On Sunday, October 9, 2016 at 7:02:25 PM UTC-4, linas wrote: >> >> Hi Apil, >> >> Interesting start. If these were fixed up a bt, they could be published >> on the website. As it is they are not quite right/misleading. >> >> So -- the atomspace depends on guile and python, so those arrows should >> point at the atomspace. >> >> -- The reasoning agents depend on the atomspace (they are actually a >> built-in part of the atomspace -- a subcomponent), they do not depend on >> opencog, nor the cogserver. >> >> -- the cogserver provides some low-level network access, it should not >> be elevated to any special status. Programmers are quasi-welcome to maybe >> propose and use other network daemons/protocols, instead of the cogserver. >> >> -- the cogserver provides the opencog shell. That's the network interface >> that it provides -- the shell is a subcomponent of the cogserver. You do >> not have to use the cogserver to get work done. >> >> -- the atomspace depends on zeromq, but only if you turn it on. It is one >> of the alternative network stacks to the cogserver. >> >> -- Nothing that I know of depends on opengl, sdl or thread building >> blocks These are old hold-overs from some old visualization tools that >> never worked well. These should not appear in the diagram. >> >> -- nothing in opencog depends on moses. It should be in the diagram, but >> currently, its not attached to anything (except that it depends on cogutils) >> >> -- only the NLP subsystem depends on link-grammar. >> >> -- the atomspace depends on postgres, for save/restore from disk. This >> is important, and should appear in the diagram. >> >> Linas >> >> >> >> >> >> On Thu, Oct 6, 2016 at 8:58 PM, Apil Tamang <[email protected]> >> wrote: >> >>> Hey All, >>> >>> So, spent some time researching on the OpenCog architecture. From the >>> little given in the github/opencog <https://github.com/opencog/opencog> >>> and github/opencog-docker <https://github.com/opencog/docker> links, I >>> spawned some high level dependency diagrams of the various subsystems. I am >>> having a bit of difficulty relating what goes here, but I hope the diagrams >>> are relatively okay. Also, I'm having a bit of difficulty relating the >>> docker files to the opencog subsystems. >>> >>> I've put some of my questions on the diagrams themselves. Could anyone >>> take some time to look at it and respond? >>> >>> I think it would be a good idea to grow these diagrams in more detail >>> and clarity. For a newcomer, it is otherwise quite hard to understand how >>> everything fits into the place. I can work on it while I'm ramping up on >>> the project. >>> >>> Is anyone willing to volunteer like an hour or something over >>> skype/google-hangout to help me get some traction? There're just a ton of >>> questions I have about getting setup. >>> >>> -- >>> 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/ms >>> gid/opencog/a5e60576-b68c-48d2-bab3-7431f8eb2278%40googlegroups.com >>> <https://groups.google.com/d/msgid/opencog/a5e60576-b68c-48d2-bab3-7431f8eb2278%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- 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/CAHrUA352f5vaAjiCoKhbYggEVY%2B%2Bjv4NBXDma%3Di7SaDdwVmiWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
