hi Alex ... lots of small inline replies below. On Wed, Oct 4, 2017 at 2:17 AM, Alex <[email protected]> wrote:
> I am here since the fall of last year (around year) and if I am allowed, I > would like to make the following thoughts that may make OpenCog project > more attractable in the eyes of developers and users: > > 1) The first feature of OpenCog is its internal complexity. One can read > two-volume AGI book and wonder about ideas about organizing mind agents and > processing nodes in multiprocessor, distributed architectures, about load > balancing and execution priorities, internode communication, etc. All these > are pretty low level technicalities that require the expertise of system > programmers, but this is quite rare expertise. > You can use opencog without knowing anything at all about the above topics. If they are boring to you, just ignore them. If they are interesting to you, then perhaps you could be a low-level infrastructure developer for opencog. We need low-level people, but its not for everyone. > > > I have this discussion in other thread https://groups.google.com/ > forum/#!topic/opencog/X_eKhNErmC8 about possibility to use external > software and external services more extensively in OpenCog project. So far > OpenCog project is about graph database, about graph pattern matching and > graph pattern mining, about rule engine - but all these technical services > are separate project today. I guess that in the time of making first > OpenCog lines, there were no graph databases, the resarch and tools of > graph mathcing and mining was only ascent field. But today the situation is > far more different - today graph databases and mathcing/mining projects are > available. Maybe the development strategy should be changed - maybe one > should more extensively use these projects and there is mismatch of > requirements then contribute to these speciality projects back and not to > try overdo them. > Opencog is far more advanced than any of these other projects. I wish the people who created these other projects had worked on opencog instead. Oh well. > E.g. I do not believe that it is economically feasibile to reimplement > graph database. There are graph database projects, there is ThinkerPop > (JDBC) like interface and there is Gremlin (SQL) like language. > The opencog query language is far more advanced than tinkerpop. It is unfortunate that the tinkerpop folks decided to invent something new, instead of using what we already had. Again -- this is about history, politics, and not about technology. > And can implement algorithms in the graph database-agnostic way and use > all the industrial power of the best database available. Scientists do use > commercial off-the-shelf computers for HPC, why not to use industrial > software? And similar things we can say about use of external reasoners > (linear logic, Coq, Isabelle, etc.). > If you can attach coq to tinkerpop and make it work ... sure. But you would probably have to completely rewrite both coq and gremlin in order to do this. And that is a huge amount of work. > > I guess, that OpenCog graph database, matcher and miner features are more > or less completed, so this work is not required for novice who would like > to contribute to AGI with OpenCog. > That's exactly backwards. These were created to make it easier for the novice to use opencog. > But the question still stands. If one starts to think about load > balancing, about scalability - can we safely assume that from the technical > point of view OpenCog surpasses the industrial graph databases? > No, because we have exactly zero people working on load balancing and scalability. > And what to do if our Atomspaces are growing and growing and there is need > to improve this in the project? > Its been like that for over 10 years now, yet here we are... Should be move to the low level job of systems programmers which requires > so different expertise? > OpenCog has needed systems programmers since the very beginning. However, systems programmers are very rare, as you point out, and they are fully employed. > I am just afraid whether the project is going in the right direction. > People would like to concentrate on their models and knowledge bases not on > the techniques. > You can use opencog today, without having to worry about systems programming issues. Why are you worried about them? > 2) Second obstacle to my adoption of OpenCog was some missed > documentation. E.g. other programming systems have BNF formalization of > their languages and the strict and exhaustive list of the constructions and > available patterns. OpenCog has very good list of all the node and link > types but sometimes I would like to have strict definitions what nodes can > be used with what links. At present I am a bit afraid that I have to do > some experimentation. > You should think of opencog atomese as being like python-0.6 or perl-0.8 -- its not yet at version 1.0, and we are creating, modifying and changing it all the time. > > 3) Third and last obstacle to my adoption was remoteness of the OpenCog > ideas and concepts. > Ten years ago, if you said "graph database", people would have told you either that you are insane, don't know what you are talking about, or that you are an unappreciated genius who should do something useful with your life. The concept of a graph database was very remote and strange. Now, it seems like everyone and their kid brother knows what that is. > It was great to have OpenCog experience because it invites me to look > deeper in the OO notions. > OO like "object oriented"? You should read lambda-the-ultimate to learn what object oriented programming is. It is safe to say that 98% of all C++ and Java programmers have absolutely no clue at all what "object oriented means". They're just ... programmers. They don't need to know, because you can be a good java or C++ programmer without knowing anything about OO programming. > I.e. OpenCog is thinking in more basic terms of extensional in intensional > inheritance/association, OO/UML modelling oversimplifies things. It is > good, but still - some canonical mapping from OpenCog notions to the more > widely adopted knowledge modelling notions would be helpful. > lambda the ultimate. > Even more so because I am pretty sure that there are people who have made > such mappings for themselves. > lambda the ultimate. > And similar things I can say about the probabilistic term logic that is > underlying OpenCog - it is not the most popular thing in the market. > Ten years ago, graph databases were not the most popular thing on the market. Ten years ago, one of the programmers who worked on opencog at the time, Joel Pitt, created a startup, and tried to sell a graph database, but was unable to convince anyone that this was useful for any practical, commercial purpose. Its possible that he was a bad salesman. Its possible that the concept of a graph database was just much too early, and the world was not ready for it. Its possible that both were true. At any rate, the startup failed. We don't have a time machine. We can't fix these issues. We can only go forwards. --linas > Again, I am not against such approach, I just invite to present some > canonical mapping to the more popular logics. I don't exactly remember but > AGI books had such explanation, if I am correct. > > > So - the general conclusion is: there are ideas about modularization of > OpenCog. But it seems to me that everyone here expects that modules will be > developed by OpenCog society. My view is different. Modularization is > required but we should use already available software (be it external open > source) for graph database, mathcer, miner, rule engine and grow these > projects and grow ourselves with the growth of these external projects. > That is the true modularization. > > Well, please, don't take seriously my thoughts I just expressed my > opinions. I am in quite difficult position. I need to make decision to what > knowledge base to commit and I am afraid not to take the wrong decision. > There are so much factors under consideration and sure, everyone has his or > her opinions about the ideal project. But things are coming and going. I am > working in my profession on broadcasting system and I have seen how much > the TV adverstising business is changing and how its supporting software is > changing too. So - why should be expect that the software for cognitive > architectures remains static. > > There were talks about funding. But funding for what? For developing yet > another graph database? Facebook, Google exploited open source software as > much it was possible during the initial growth phase and it was the base on > which the success story was built. Of course, after some time they started > to contribute back to the community. And they are still engaged and open > with the community and it is the mutual growth and for mutual benefit. > > -- > 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/f52988a4-7430-4d56-a67d-ec9087da83ce%40googlegroups.com > <https://groups.google.com/d/msgid/opencog/f52988a4-7430-4d56-a67d-ec9087da83ce%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *"The problem is not that artificial intelligence will get too smart and take over the world," computer scientist Pedro Domingos writes, "the problem is that it's too stupid and already has." * -- 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/CAHrUA36SW7oAbkvmBAU8J6iLvvby-EL2gSKsNZO6TszRnwGzMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
