hi Alex ... lots of small inline replies below.
On Wed, Oct 4, 2017 at 2:17 AM, Alex <[email protected]
<mailto:[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
<https://groups.google.com/forum/#%21topic/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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/opencog
<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
<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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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
<https://groups.google.com/d/msgid/opencog/CAHrUA36SW7oAbkvmBAU8J6iLvvby-EL2gSKsNZO6TszRnwGzMw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
