Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

The AtomSpace project should probably be promoted on its own, have its 
own webpage, purpose, reference manual, tutorial, etc.


Also what is missing to get more main stream is a way to define atom 
types within atomese itself, so it could being used as a more neutral 
graph db. That's really the only missing piece since TV and AV have been 
replaced by generic key x value.


Nil

On 10/04/2017 11:02 AM, Linas Vepstas wrote:

hi Alex ... lots of small inline replies below.

On Wed, Oct 4, 2017 at 2:17 AM, Alex > 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 

Re: [opencog-dev] Contributing to Opencog

['Nil Geisweiller' via opencog]

On 10/04/2017 11:02 AM, Linas Vepstas wrote> 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 never tried Coq or Isabelle, but the provers I've tried (E and 
Vampire) were using resolution 
https://en.wikipedia.org/wiki/Resolution_(logic), which doesn't work for 
a para-consistent logic like PLN, at least not out-of-the-box. On top of 
that PLN is probabilistic (or even meta-probabilistic we could say). 
These make it difficult or at best unnatural to use traditional 
automatic theorem provers. Maybe there's an easy way, or a more general 
framework that I missed, but that was my impression when I studied the 
domain.


Nil

--
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/a261e2b5-7d6e-74f9-fe87-cd83304adb2a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

hi Alex ... lots of small inline replies below.

On Wed, Oct 4, 2017 at 2:17 AM, Alex  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

Re: [opencog-dev] Contributing to Opencog

[Linas Vepstas]

Ivan, Mark,

The project that Ben is referring to is here:
https://github.com/opencog/singnet -- it will allow a number of different
AI agents to communicate with one-another and exchange information.

Now is a good time to alter the course of events; that project is getting a
lot of effort at this particular instant.

--linas

On Tue, Oct 3, 2017 at 5:34 PM, Ben Goertzel  wrote:

> Yes.  My focus at the moment, frankly, is oriented toward raising the
> funds required to make this happen...
>
> On Tue, Oct 3, 2017 at 5:23 PM, Mark Nuzz  wrote:
> > Ivan,
> >
> > This is essentially the vision I have for the project too. I wish I could
> > say that it could be done by a determined volunteer, but the logistics
> are
> > very difficult for pulling this off. It would require multiple
> experienced
> > and skilled engineers working full-time, possibly paid. That isn't going
> to
> > happen by itself.
> >
> > Maybe there is a realistic path to making it happen. Let's talk in more
> > detail later since I'm interested too, but I can't promise any
> commitment as
> > its tough these days for me to put in the hours in addition to what
> keeps my
> > bills paid...
> >
> >
> > On Oct 2, 2017 9:50 PM, "Ivan Vodišek"  wrote:
> >>
> >> > But Ivan, no one forks opencog; almost all extensions are placed back
> >> > into the core code base.
> >>
> >> I'm aware of that. If someone forks the entire project, it would have
> been
> >> called some other name. 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. Just a bit of brainstorming in a direction of
> >> decentralization. The goal is to have industry-strength project
> abilities
> >> with liberal multi-user maintaining policy. It is on my long-term to-do
> >> list, but I could share my thoughts with someone who wants to implement
> it
> >> sooner.
> >>
> >> Thank you all for your patience :)
> >>
> >>
> >> 2017-10-03 4:33 GMT+02:00 Linas Vepstas :
> >>>
> >>> Hi Anastasios,
> >>>
> >>> Yes. But first: complaining that opencog is written in C++ is like
> >>> complaining about the fact that the linux kernel on your cellphone is
> >>> written in C. Who cares? It does not affect 99.% of all cellphone
> users
> >>> because they do not write kernel device drivers.
> >>>
> >>> Think of the atomspace as being like an OS kernel.  You probably should
> >>> not be writing new C++ extensions it.  Instead, you should be writing
> apps
> >>> for it.  The apps are where the action is.
> >>>
> >>> So far, we've offered maybe half-a-dozen app APIs for it, with varying
> >>> degrees of success.
> >>>
> >>> Having an instance on the cloud would be great, where people could spin
> >>> up an instance, and log into it. I've long long wanted to do this;
> hell, I
> >>> could just throw an old PC onto my internet connection. I don't have
> time to
> >>> mess with this.
> >>>
> >>> For cloud-cog, the only thing available would be the app API's, and
> maybe
> >>> that would make the bitching about C++ stop...
> >>>
> >>> --linas
> >>>
> >>> On Mon, Oct 2, 2017 at 6:47 AM, Anastasios Tsiolakidis
> >>>  wrote:
> 
>  Well isn't OpenCog having a busy weekend :) As a lurker I have already
>  expressed my dissatisfaction at "advanced C++" which is the trend in
> the
>  project, and would probably carry over my disapproval of "idiomatic
> C#".
>  There is absolutely no reason for the coding to be more difficult to
>  comprehend that OpenCog's design itself. If anything, the code should
> make
>  plain and simple what the bloody design is trying to do! Now, my
> particular
>  wet dream would be to see people pulling together their own "free
>  resources", like the free tiers at AWS, Google Cloud etc, to create a
>  hive-mind. If somebody was brilliant enough to throw away big chunks
> of the
>  code and instead achieve (some of) the same results with a DB of
> sorts, AWS
>  lambda etc, that would be quite something. Then, for the parts that
> don't
>  fit the "cloud" box, if someone could come up with the "CloudCog",
> some
>  probabilistic graph, inference engine or whatever is missing from the
> garden
>  variety PAAS and SAAS, then we could really be heading somewhere. I
> don't
>  know much about the project beyond the demos, but I do believe the
> project
>  is being hur

Re: [opencog-dev] Tracking of an atomese mind through the generations

['Nil Geisweiller' via opencog]

You can also evolve atomese programs maximizing some fitness, like MOSES 
does, you don't necessarily need experience. MOSES is gonna be ported to 
the AtomSpace, it sounds related to what you want to do.


Nil

On 10/04/2017 07:48 AM, Linas Vepstas wrote:
Learning requires a bunch of experiences from which to generalize, and 
some way of deciding if the thing that was learned is worth remembering. 
Oh, and then using what you've learned.  You might enjoy debating on the 
AGI mailing list, to discuss how this might be achieved.


--linas

On Wed, Oct 4, 2017 at 10:54 AM, Daniel Fagerlie 
mailto:danielfager...@gmail.com>> wrote:


I just had a passing thought, and I wanted to see how others have
done something similar; what it is called?

I may not understand the atomspace fully. If so, forgive my blunder.
Also, I'm no expert on these subjects, which is about to be obvious,
but I decided to make this post anyways for the experience.

My thought is to grow a certain number of atoms within an atomspace
using a genetic algorithm approach, but track the change from
chaotic atomspace to the ordered atomspace. The problems that the
simple mind is to solve should be something interesting but small
enough to be properly evolved within a reasonable time frame (I'd
have to give this more thought, but maybe an environment where logic
is needed, not just action/reaction). The idea is to study the
process of how genetic learning happens in the context of opencog,
and how it relates to the current work in creating mind agents for
learning.

Maybe this has already been done, or it's a concept hatched before I
have sufficiently gained understanding. Anyways, there it is.

-- 
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/9627a84f-758c-41e2-b410-da7ce317213b%40googlegroups.com

.
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 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/CAHrUA36ue%3DW3vXFjp0e_hka3MhOdqLtvTGHgt5-i6vr_FOvDuw%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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/8509d80f-c9c7-9f07-4c62-d36e7b1a9c4b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.