Need help ramping up on the project

[Apil Tamang]

Hey All,

 

So, spent some time researching on the OpenCog architecture. From the little given in the github/opencog and github/opencog-docker links, I spawned some high level dependency diagrams of the various subsystems. I am having a bit of difficulty relating what goes here, but I hope the diagrams are relatively okay. Also, I'm having a bit of difficulty relating the docker files to the opencog subsystems.

I've put some of my questions on the diagrams themselves. Could anyone take some time to look at it and respond?

I think it would be a good idea to grow these diagrams in more detail and clarity. For a newcomer, it is otherwise quite hard to understand how everything fits into the place. I can work on it while I'm ramping up on the project.

Is anyone willing to volunteer like an hour or something over skype/google-hangout to help me get some traction? There're just a ton of questions I have about getting setup.

[Amen Belayneh]

Hi,

1. On opencog shell (aka cogserver): See https://github.com/opencog/opencog/blob/master/opencog/cogserver/server/README
   
2. On Docker images
•  cogutils is a dependency for atomspace and moses. Atomspace, which is installed in opencog-dev:cli & opencog-dev:ide(by the way this image is not maintained), is a dependency for opencog/opencog repo.
•  Yes, you can use the regular docker commands.
•  buildbot is a continuese-integration tool, that used to be used by the team. Now we are using Jenkins.

The videos @ http://wiki.opencog.org/w/Hong_Cog-a-thon_May_2016 might be helpful

[Linas Vepstas]

Hi Apil,

Interesting start.  If these were fixed up a bt, they could be published on the website.  As it is they are not quite right/misleading.

So -- the atomspace depends on guile and python, so those arrows should point at the atomspace.

-- The reasoning agents depend on the atomspace (they are actually a built-in part of the atomspace --  a subcomponent), they do not depend on opencog, nor the cogserver. 

-- the  cogserver provides some low-level network access, it should not be elevated to any special status.  Programmers are quasi-welcome to maybe propose and use other network daemons/protocols, instead of the cogserver. 

-- the cogserver provides the opencog shell. That's the network interface that it provides -- the shell is a subcomponent of the cogserver.  You do not have to use the cogserver to get work done.

-- the atomspace depends on zeromq, but only if you turn it on. It is one of the alternative network stacks to the cogserver.

-- Nothing that I know of depends on opengl, sdl or thread building blocks  These are old hold-overs from some old visualization tools that never worked well.  These should not appear in the diagram.

-- nothing in opencog depends on moses.  It should be in the diagram, but currently, its not attached to anything (except that it depends on cogutils)

-- only the NLP subsystem depends on link-grammar.

-- the atomspace depends on postgres, for save/restore from disk.  This is important, and should appear in the diagram.

Linas

 

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to ope...@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/a5e60576-b68c-48d2-bab3-7431f8eb2278%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julia Mossbridge]

Hi Apil,

I don't know much about the system, I am a newbie too, but I have a question about your notes -- the arrows you drew are pointing toward the system on which another system is dependent? My intuition is I would put the arrows in the opposite direction -- point toward the child. Am I missing something?

Thanks,
Julia

[Apil Tamang]

Hi Julia,

Your intuition is understandable. It is intuitively the other way around. However, what is shown is fairly standard in formal software engineering to represent dependencies. It is merely a convention and I've no idea why this is so.

[Julia Mossbridge]

Hi Apil,

Okay, thanks for letting me know. I'm from a psychology/neuroscience background, so I can't help but think software engineers may want to reverse the relationship between parent and child...though that is probably reading too much into it!

I admire your efforts to simplify the architecture!

Julia

[Apil Tamang]

Hi Linas,

Did a little bit of reading around along-side your points. Here's a diagram I kinda ended up with. It's definitely not exhaustive, but let me know if is fairly more accurate. As I understand more of opencog, I'll try to keep updating it.

On Sunday, October 9, 2016 at 7:02:25 PM UTC-4, linas wrote:

Hi Apil,

Interesting start.  If these were fixed up a bt, they could be published on the website.  As it is they are not quite right/misleading.

So -- the atomspace depends on guile and python, so those arrows should point at the atomspace.

-- The reasoning agents depend on the atomspace (they are actually a built-in part of the atomspace --  a subcomponent), they do not depend on opencog, nor the cogserver. 

-- the  cogserver provides some low-level network access, it should not be elevated to any special status.  Programmers are quasi-welcome to maybe propose and use other network daemons/protocols, instead of the cogserver. 

-- the cogserver provides the opencog shell. That's the network interface that it provides -- the shell is a subcomponent of the cogserver.  You do not have to use the cogserver to get work done.

-- the atomspace depends on zeromq, but only if you turn it on. It is one of the alternative network stacks to the cogserver.

-- Nothing that I know of depends on opengl, sdl or thread building blocks  These are old hold-overs from some old visualization tools that never worked well.  These should not appear in the diagram.

-- nothing in opencog depends on moses.  It should be in the diagram, but currently, its not attached to anything (except that it depends on cogutils)

-- only the NLP subsystem depends on link-grammar.

-- the atomspace depends on postgres, for save/restore from disk.  This is important, and should appear in the diagram.

Linas

 

On Thu, Oct 6, 2016 at 8:58 PM, Apil Tamang <apil.tama...@gmail.com> wrote:

Hey All,

 

So, spent some time researching on the OpenCog architecture. From the little given in the github/opencog and github/opencog-docker links, I spawned some high level dependency diagrams of the various subsystems. I am having a bit of difficulty relating what goes here, but I hope the diagrams are relatively okay. Also, I'm having a bit of difficulty relating the docker files to the opencog subsystems.

I've put some of my questions on the diagrams themselves. Could anyone take some time to look at it and respond?

I think it would be a good idea to grow these diagrams in more detail and clarity. For a newcomer, it is otherwise quite hard to understand how everything fits into the place. I can work on it while I'm ramping up on the project.

Is anyone willing to volunteer like an hour or something over skype/google-hangout to help me get some traction? There're just a ton of questions I have about getting setup.

--
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+u...@googlegroups.com.

[Linas Vepstas]

sorry, just unearthed this email.  

The diagram now looks correct, but I am concerned about emphasis: everything interesting in opencog happens in the main two blocks -- the fact that there just happens to be a compile-time dependency on python, scheme, postgres, cogutils doesn't seem very important. I guess it should be noted, but its not worth a lot of graphical real-estste.

Besides python and scheme, there are also c++ and haskell bindings, and also a REST webapi, and also, a ZMQ binding.  The C++ and the REST bindings are in active use. the haskell bindings are exprimental.  The ZMQ bindings might have bitrotted.

Besides postgres, there is also gearman for distributed processing, and also a binding to the java neo4j database via the zmq bindings. 

Anyway, none of these things are part of the "architecture", per se; they are all outside of the architecture, they are on the periphery, a way of attaching to the achitecture.  The actual architecture is that of the atomspace, and the 100 different atom types, the rule engine, PLN -- that's the actual architecture.   These are really what make opencog work. The fact that there's python of scheme of C++ mostly kind-of doesn't matter at all.

--linas