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. There are far more business application programmers or scientific application programmers that are relying on the OS features and speciality software features (like MPICH) to write and execute their high level application code. 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. 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. 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.). 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. 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? And what to do if our Atomspaces are growing and growing and there is need to improve this in the project? Should be move to the low level job of systems programmers which requires so different expertise? 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. 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. If the language had more formal specification then it would be possible to develop and formalize this specification furher - e.g. go from the textual code to the hypergraph, from programs to the hypergraph transformations and see what we can deduce from such semantics. 3) Third and last obstacle to my adoption was remoteness of the OpenCog ideas and concepts. It was great to have OpenCog experience because it invites me to look deeper in the OO notions. 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. Even more so because I am pretty sure that there are people who have made such mappings for themselves. 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. 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 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/f52988a4-7430-4d56-a67d-ec9087da83ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
