Nuzz, etc. Just to add a different but related dimension to the discussion -- the way we are going to wrap OpenCog functionality in SingularityNET agents is a bit different…
Each agent will carry out a specific functionality, which may be generic or may be domain-specific For instance 1) An inference agent may take in a set of premises (perhaps probabilistically or fuzzily weighted) and a time limit and a range of effort that’s OK to spend, and output a set of conclusions 2) A question-answering service may take an English-language question as input, and a time limit and a range of effort that’s OK to spend, and output a list of answers (which might be English language sentences and/or URLs to relevant resources) So the SingularityNET agents will be highly “modularized”, each one carrying out a well-defined set of tasks (with certain input and output types), where there is a set of ontologies and each task is characterized by a set of terms in one or more ontologies... Behind the scenes, however, to achieve this kind of modularization at the “user” level (where the user could be after a particular abstract AI functionality like logical inference, or a particular application functionality like question answering), does not require a strict modularity at the underlying OpenCog dynamics level. For instance it does not require that the interface between inference and language processing or evolutionary learning be restricted to a simplistic interface that hampers the flexibility of such interactions. In short what we will do in this context is to provide a simplified way to access (general-purpose or application-specific) *services* implemented using OpenCog (along with many services implemented using other tools besides OpenCog — SingularityNET will not be restricted to OpenCog agents by any means)…. But this does not require a commensurate simplification of the world experienced by OpenCog AI developers (i.e. those who are contributing to rather than utilizing OpenCog AI). For OpenCog AI development, I think we need better debugging tools, better visualization tools, better documentation, better tutorials, etc. But I am unconvinced that we can have a stricter modularization without destroying the AGI potential of the platform. There is a bit of a challenge here in that the crux of AGI is the interaction and interpenetration of different functionalities. This does not rule out modularity in the sense of software dependency management — one can make the building of different AI functionalities more separate than is currently the case. But it does perhaps rule out making simplified interfaces that constrain the flexibility of interaction between different AI modules. The different Ai modules need to interact via their common activity updating Atomspace in real-time, and this has just got to be a complex variety of interactions, with new aspects to be ongoingly explored as the AGI R&D proceeds. — Ben On Fri, Oct 6, 2017 at 7:30 PM, Mark Nuzz <[email protected]> wrote: > On Fri, Oct 6, 2017 at 1:37 AM, Ben Goertzel <[email protected]> wrote: >> *** >> OTOH, If modules or projects were usable in isolation, and the >> dependencies could be effectively treated as black boxes (as most >> software dependencies are), or even simulated/mocked, and if >> meaningful experimentation and feedback still able to be done within >> the narrow scope of that one module, then maybe the tutorials won't be >> so pointless. >> *** >> >> yes, I agree that narrow AI is easier than proto-AGI ... and that if >> we put more effort into wrapping up OpenCog components so they could >> be used as pure narrow-AI component in themselves, or for specific >> narrow applications, then this would attract more developers toward >> these narrow-AI applications and tools... and work on these narrow >> applications and tools would indirectly benefit the quest for >> OpenCog-based AGI... >> >> Nevertheless I feel that the bottleneck is not currently wisdom about >> "what would be nice to do" or "what should be done" but rather the >> lack of any resources earmarked for making these types of >> improvements.... It's not like OpenCog Foundation has a large staff >> and budget that is being frittered away on other stuff... Nearly all >> current OpenCog dev is happening because of commercial projects >> wanting to use OpenCog bits and pieces and aspects for various >> specific purposes, and this sort of funded dev is great but doesn't >> tend to lead to work focused on making the infrastructure easy for >> newbies... >> >> Tensorflow has wonderful documentation, beautiful visualization, >> elegant modularization, etc. It's lovely for what it is. How much do >> you think Google spent on these aspects? >> >> ben >> > > Perhaps this is close to where the real disagreement is. On one hand, > the project is striving for modularity in the form of separate > compilation of modules and components. On the other hand, the idea of > having them as architecturally separate components elicits a belief > that it will be treated as narrow AI, and I know how you (rightfully) > feel about narrow AI. There is probably truth in both of our > arguments, but the difference is that I feel that the architecture I > advocate will lead to AGI much faster than otherwise. And I don't > think that this will necessarily shift the focus to the domain of > narrow AI. Rather, it will still be AGI development, but with the > variability in statefulness being greatly reduced, to the point where > a developer will not have to spend time studying the other moving > parts just to get to the point where they can feel comfortable working > on a specific component. This does not necessarily make it narrow AI > by default. > > I also believe that it's easier to get resources earmarked for > improvements, when a more effective pitch is made for those > improvements. If there's no wisdom about what should be done, then > there's no proposal/plan that makes sense. And if there's no proposal, > there's no effective pitch. No effective pitch means no money. When > you say that the bottleneck is not A, but rather B; but I say that A > is a crucial step to remedy B, then perhaps this could be an idea for > some determined volunteers to try pursuing. It may not be something > easy or possible for the core crew to do, given the tied up resources, > but it might be possible for a small number of volunteers to > accomplish, given enough motivation. > > Most of the money that gets spent by companies like Google on those > top notch architectural aspects, goes toward the leap from being in > the top 10%, to the top 1% of capabilities, or from the top 2% to the > top 0.1%. Talent acquisition involves a bidding war with other > companies, and the economics of it obviously aren't directly > applicable to libre projects... As you might know, Norvig's team > applies narrow AI techniques to the data around hiring and talent > markets, all in the pursuit of having the best talent is concentrated > in that one company. There are plenty of examples of freeware and > libre software with zero budgets, that have elegant architectures. > Inventing them for the first time may be costly, but re-using > paradigms that are already battle-tested and proven, is not > necessarily costly. The catch here is that most programmers don't know > how to do this, as it's not a domain that exists on most projects. > However, it is a domain that I have a personal interest in, so I would > like to help out if anyone else is able to participate... > > I think that it would be a better idea at this point if Ivan and I > (and whomever else is interested) could come up with a more specific > proposal on an architectural design based on this discussion, while > also addressing all of your concerns brought up here. I can't promise > we would be successful (you know me well enough to know how terrible I > am at following through with ideas), but I think a more detailed > proposal would be more productive than debating on a mailing list. > Since a lot of the modularization is already there, as you mentioned, > it might not be too much work at all for one or two people (but > there's no way to know, and no promises). I doubt it will be easy for > a developer who isn't intimately familiar with the system though, but > certainly possible... > > If I make a proposal it won't be something that will break the bank, > and would hope to provide plausible estimates for how it would create > a return on whatever modest investment of time that it would take. > Specific flaws in the proposal can be identified by anyone and then > fixed or addressed, and if at the end of the day it is rejected due to > purely philosophical differences and not due to hard technical errors, > then that makes it a candidate for some volunteers to work on it as a > side project (not a fork) and let the results speak for themselves. It > would probably be something like an alternate build system rather than > a restructuring of the codebase, and treated as a proof of concept > rather than as a replacement for anything. If people get stuck or > intimidated on the project as is but are able to find it easier to get > involved, with the alternate system, then I would consider it a proven > success. And *then* a better pitch could be made to get those > resources needed for a more involved architecture change. This would > happen over a long period of time, of course... > > Will definitely need help on this though, so if Ivan and whomever else > is interested can message me in private perhaps we can get started on > brainstorming. > > -- > 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/CAMyYmr8UnF1vr7BwF%2BY53xdyihdLbCEL72mJ9DdkOVAFng4Zdw%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 [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/CACYTDBcuRat55n4E3FjKLWtZx-6fWHwiXA7n-XTrQhVDrRSzqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
