"Modular" and "monolithic" are very general terms. Could you articulate more precisely the ways in which you think OpenCog is "monolithic", and in which you think it could be made more "modular"?
My thinking is: the Atomspace is a distinct module (in its own repo, it builds separately, etc.), and the various AI processes that can be used with the Atomspace are also independently buildable and runnable (MOSES, PLN, the NLP pipeline, ECAN, etc.). Also when we use OpenCog for robot control, it communicates with other AI tools that are wrapped up in separate ROS nodes. This already seems pretty modular to me. So I am wondering what other kind of modularity you are looking for? Regarding Ivan's description *** I was referring to an imaginary system where the whole project would be a set of modules that work together, connected by well known set of interfaces. Each module could be modified or forked out in parallel with the original. It would be up to a user, which sub-forks she/he would choose to use to run the project, or to base her/his contribution on. Probably there would be a need for combination maintainers, something like persons that would choose different flavors of the project, and would propose their "deejay-combo" to the public, optimized for this or that use. Sub-fork combinations of low quality would be avoided, while really useful ones would live on. *** I guess one relevant point is that the different AI tools within OpenCog can interact in many many different ways. E.g. there is no single, simple interface for interaction between PLN and MOSES; there are lots of ways they can interface, conceptually speaking. And figuring out the best ways for them to interface is a current research topic... In building a particular OpenCog application, one can define specific interfaces between the various AI components... But for OpenCog as a general platform, the interactions between the components have to remain flexible because there are so many interesting ways to do it... I think the biggest issue with OpenCog is that we need better tutorials and documentation. I guess if we had that people would be able to understand the system better and then would also make more useful suggestions regarding improving the architecture... ben -- Ben On Fri, Oct 6, 2017 at 2:56 AM, Mark Nuzz <nuzz...@gmail.com> wrote: > On Thu, Oct 5, 2017 at 2:13 AM, Ben Goertzel <b...@goertzel.org> wrote: > >> I regret that OpenCog remains so hard to approach. In large part it >> has evolved this way because the vast bulk of funding that has gone >> into OpenCog has been oriented toward paying a small group of people >> to work, in a hurry, on making OpenCog do something specific.... We >> have not yet had a big chunk of funding dedicated to making it easy to >> use as a platform. Hopefully that will change soon. > > This seems to be a very common theme with projects, especially with > limited resources. Though OpenCog is unique in the sense that it has > survived for so long with so many contributors, so the scale/extent at > which this happened is somewhat larger and therefore require greater > effort and coordination to really solve. > > I'm curious about a few things... > > 1) I know you implied this but I wanted to make sure: Do you see the > goal of an easy-to-use opencog architecture as a high priority item? > > 2) Do you think that the specific architecture direction > (modularization) presented by Ivan is generally the way that this > should be solved? > > 3) Has there been any concrete work in mapping out a specific > architectural direction to fulfill the goal of making opencog easy to > use? > > 4) Are these decisions that have already been formally agreed upon by > the governance of the project? Are there any dissenters among the core > developers, to the extent that it might interfere with such plans if > executed? > > > I am not quite aware of all the details but I have been trying to keep > up with all of the discussions lately in this group. Please forgive me > if I am being too pedantic... My impressions are that funding would be > easier to come by after these items are figured out in great detail > and then incorporated as part of a proposal. Such a proposal could > attract enough of the right unpaid volunteers too, as you know. > > > But yeah, I am not claiming by any means to know even remotely close > to what Ben knows on this subject. But from my vantage point, I am of > the opinion that the monolithic architecture is what's slowing > progress, and not the lack of funding. Suppose you get the funds and > then you hire the wrong people, then you're even worse off than before > because you probably wouldn't get another shot at funding for awhile. > If it were up to me I would have at least one existing core developer > be involved with this effort full-time, preferably whomever has the > most knowledge in modular software architectures. > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to opencog@googlegroups.com. > 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/CAMyYmr-T4gevcMh_2mYHko-YwuRcCK6dyBfGZVwYT%2BuizjH6PQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Ben Goertzel, PhD http://goertzel.org "I am God! I am nothing, I'm play, I am freedom, I am life. I am the boundary, I am the peak." -- Alexander Scriabin -- 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+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. 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/CACYTDBfVnqsuiJV5MbFu4_1rkKffZESjaVroUmkEUDc1K0cUNw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
