MOZI web UI

[Linas Vepstas]

Hi Xabush,

So I have a tough question for you: the MOZI webserver ... 

I'm trying to solve a meta-problem: I want to increase developer engagement in opencog/atomspace.  For that, it would be nice to have a web UI. Three of them actually, or four.

1) A web UI that allows users to create new atomspaces, and put (by hand) some atoms into it, and visualize simple graphs. So, people can point their browser at it, and mess around.

2) A job control panel web UI. So, for the language learning project, I have a collection of bash scripts that start and stop the atomspace, and ingest text files, and take hours or days to run.  I thought of MOZI because it has some similar requirements.

3) A data explorer. Given an atomspace, with say, millions of atoms (from language learning, or from biochem), I want to explore what's inside of it: print all atoms in some cluster, ranked by frequency, or plot some histogram of mutual information vs frequency or whatever.  Maybe a kind-of-like jupyter for the atomspace. Again, I think of the MOZI work in this direction.  You were trying to get a simple web UI for biochemists to use. I want the same deal, but for linguists. Under the covers, it's all the same stuff: just atoms in the atomspace.

How can this be accomplished? You've built some kind of custom solution for 2 & 3 for MOZI, but I don't understand how to backtrack out of that, and custom-tailor it so that it works for language learning instead of ChEBI or PubChem.  Any ideas?

I mean, you and Hedra have put a lot of effort into these things...

I see things like this:

https://github.com/MOZI-AI/annotation-service

and this:

https://github.com/MOZI-AI/annotation-service-ui

And I'd like to have it work for the kinds of graphs and systems in the language-learning codebase, instead of biochemistry.  What would it take to have that work? Do I really have to start from scratch? Is there a way to recycle any of the work that you've done, and use it for other applications?

I don't want to go off and state the obvious, but maybe I should go off and state the obvious: if this web UI stuff was generic, then other users could use it, which means that other users could show up and help fix bugs and add features. It would grow the project overall ... it would help anyone interested in the atomspace and in singularitynet and all that jazz ...

BTW, back in the days of Hanson Robotics, we had the same problem ... I think we throw a lot of money at some Brazillian to create a WebUI for the Owyl behavior tree subsystem, but .. of course, that code failed with the AtomSpace, so it was like .. wasted money, wasted effort. .. we still don't have a generic AtomSpace WebUI ...

-- Linas

--

Patrick: Are they laughing at us?

Sponge Bob: No, Patrick, they are laughing next to us.

 

[Lansana Camara]

Linas,

I’m not Xabush, but in regards to your question about a web UI…What are your requirements? 

Building a (globally distributed?) and easily maintainable frontend that communicates with servers via HTTP or some similar protocol is very easy for me; this is my expertise. I can start from scratch and have a web UI up and running on a global CDN in one days time, using open source tech that is understood by the majority of the frontend community (eg React) which means that it would be easily maintainable and extensible. 

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA355C6jVfExiFaqYusBxj4oGwD2Bpd%2B9DY7qP3jyLb7orQ%40mail.gmail.com.

[Linas Vepstas]

On Sat, Jun 26, 2021 at 3:06 PM Lansana Camara <lxc...@gmail.com> wrote:

Linas,

I’m not Xabush, but in regards to your question about a web UI…What are your requirements? 

Heh.  Well, my requirements are exactly the three things I listed in the first email: (1) something that beginners can use to explore the atomspace contents, run the example demos. (2) a job control panel  (3) a data explorer.

Building a (globally distributed?) and easily maintainable frontend that communicates with servers via HTTP or some similar protocol is very easy for me; this is my expertise. I can start from scratch and have a web UI up and running on a global CDN in one days time, using open source tech that is understood by the majority of the frontend community (eg React) which means that it would be easily maintainable and extensible. 

Heh.  You may as well be speaking a foreign language. I don't know what React is or what a CDN is -- or why either of these would be needed. So I don't know how to react to the proposal.

Besides the code in the MOZI github directories, there is this:

https://github.com/opencog/atomspace-explorer

which is written in javascript, and runs inside the browser. It's old and a bit buggy and unmaintained. The demos work, but are filled with obsolete cruft that would need to be cleaned out.  In particular, the demos require an obsolete and unmaintained json file format; it needs to be converted to atomese.

This explorer, if it was cleaned up and modernized, could be a reasonable start for fulfilling requirement (1)  ... maybe.

The biggest problem with the atomspace explorer is that the code is impenetrable. Almost all of the code in that git repo seems to be a cut-n-paste of other projects, so its very hard to figure out where the actual, useful code is, and what part of it is cruft that could be discarded. So ... I don't know how to deal with things like that. It's frustratingly unmaintainable.

The meta-requirement would be that ordinary people could install and run the thing, and use it, and that ordinary programmers could make changes to it. -- add features, enhancements. We're not there yet ...

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAPPXERrO-KhO%3Ddp0UXOhfT4hUQn8O95%3DfzKGw26kpRzXpz-cxA%40mail.gmail.com.

[Lansana Camara]

React is a frontend library written on JavaScript. It enables building single-page web applications. 

CDN is content delivery network. So if you host something on opencog.com and someone requests opencog.com from China, the CDN will deliver the static HTML from a Chinese server (as opposed to from a US server) for optimal speed and page load. It’s in the space of distributed systems.

In regards to rebuilding the current site…without having dug through the code (and while taking your description of the unmaintainable mess into consideration), I would strongly recommend just nuking everything and starting from scratch. 

A new git repo with a one-line setup command could be done in a day. The ability for people to collaborate on it would be enabled simply by using a well-known web UI library like React, and structuring the code such that anyone that has any frontend experience will know how to collaborate immediately without having to think about it. Again, all of this boilerplate can be done in a day. 

If you can ping me in 2-4 weeks, I can kick this off and get this done, while at the very least leaving space for others to come in and actually build out the atomese UI using the foundation that I lay out; I have some other deliverables over the next couple of weeks so my time is taken.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34e%3D-8E0d%2ByeGkwUMaj6jBWOO_Uoi26CDOUubbkeXknxQ%40mail.gmail.com.

[Linas Vepstas]

Hi Lansana ...

Thanks for writing. To be clear, there aren't any others. There is just you & I, and ... sure, OK --  the other people cc'ed on this email, who ... might not be very interested in any of this.

As to starting over -- projects that start all over again are rarely better than the intiali project -- maybe 1 out of 5 times -- this is the industry average.  The other 4 out of 5 times, projects that start over fail completely.  So starting over is usually a really bad idea, best done only if the initial project is so utterly broken that it cannot be saved.

So .. what's the initial project, here? Well,

looking at https://github.com/opencog/atomspace-explorer, I see about 1.5KLOC of javascript.

But that does not include the actual rendering engine, which is located at

https://gitlab.com/icog-labs/atomspace-visualizer

Which gives me a 404 not found. It would seem that the nice folks at icog labs have deleted the repo. The original authors are ...

• Mikyas Damtew
• Kaleab Yitbarek
• Tsadkan Yitbarek
• Stephen Sherman

Do you know any of them, perhaps? Their emails? (Are you at icog-labs, or are you completely unrelated to them?) It would be nice to get a copy of the git repo ... if not, then maybe I can extract the source code from the npm package (which still seems to exist)

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAPPXERoovF6SsLsKD3WPpAa9OwtLc%2BK82Ao6CXzMJkBW2krWnA%40mail.gmail.com.

[Reslav Hollos]

I'm also interested in AtomSpace UI and have had very pleasant dev experience with React (as well as TypeScript which I would recommend).

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34hU%3DOdJBV6pFeCepjDrbsZquNGOZkwpCbwyOOMJcpV_g%40mail.gmail.com.

[Linas Vepstas]

On Tue, Jun 29, 2021 at 8:57 AM Reslav Hollos <reslav...@gmail.com> wrote:

I'm also interested in AtomSpace UI and have had very pleasant dev experience with React (as well as TypeScript which I would recommend).

Well, the current code is in "Angular" -- and is TypeScript.  How different is that?  Are Angular and React two different versions of the same thing, or are they completely different? I can code in javascript just fine, but things like npm and etc. leave me stumped -- when there's a problem, I don't know how to debug it.

  

--linas

[Reslav Hollos]

TypeScript is a language, a superset of JS that adds syntax for optional types (which are extremely helpful). It can be used for React as well and for any other JS project.

Angular is a UI framework which is in my opinion over-engineered and is built on top of bad practices like mutations (eg. two way data binding). Mutations are useful when performance is needed, but if not encapsulated tend to be the cause of too many hidden bugs difficult to detect or even fix. Newcomers I mentored had problems with Angular since it required too much knowledge to contribute even a little. Another example is the model-view-presenter structure which I've found to be hard to maintain on large projects, it was confusing to too many people and allowed for mistakes to happen very easily. Having such complexity at the very beginning takes focus away from the application.

React is a UI library which I believe got it right from the start, it revolves around separation of concerns, app state propagates hierarchically downwards (unidirectional data flow) and changes are done with callbacks instead of directly mutating (these are called controlled components). Mutations can still be used, but are not used by default. React uses virtual DOM and an algorithm called 'reconciliation' that determines when and what to update in the DOM, since state changes generate new objects, to me it's simpler than Angular's Change Detection. All of which is debatable but in React things have mostly worked out of the box for me, while in Angular there were many times an extra step, a solution to a problem that should not have existed in the first place and felt like a workaround. React has JSX syntax that combines HTML and JS and recent updates added 'hooks' syntax which even more simplifies the state management.

In short I think that React based projects have bigger chances for community contributions because of ease of use.

About NPM, it can sometimes be tricky but I think it's manageable, it shares some problems/solutions from many different package managers, like mismatch of node version between dev environments, incorrect handling of package-lock.json (a file that hardcodes all dependencies of dependencies versions) or some library incompatibilities with another library which solution is usually in github issues comments. I use NPM in all JS projects.

This is based on the experience I accumulated over the last 6 years.

Reslav

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34hy9RZBg897pPX-hwhkcf_%2BbHmE%2B4QRSsE60p%3DnjKb9Q%40mail.gmail.com.

[Michael Duncan]

hi linus & interested folks!

some mozi background:  the mozi project is on hiatus but the plan includes a graphical interface to the bio-atomspace that fulfills linus' requirements for allowing easy exploration of & interaction with the atomspace metagraph.

regarding the existing code base, there is a browser based query page that lets users input a list of human gene symbols and use them to query from a list databases imported into a server based atomspace.  the pattern matching results are then converted from an atomese metagraph to a more typical graph format that is returned for display and exploration to the browser interface.  the interface also includes summary tables of the graph results.   the results can also be downloaded as csv tables for subsequent bioinformatic analyses.

instructions for setting up a local version for development are available in the README of this repo:  https://github.com/MOZI-AI/annotation-service.  i haven't tried this out in a year so if there are any problems please post an issue.

there is also a demonstration version available on the singularitynet, there are 15 queries available for free for anyone who wants to try it out there:  https://beta.singularitynet.io/servicedetails/org/mozi/service/gene-annotation-service

mozi will ultimately be a biomedical research tool that will leverage opencog to be an intelligent research assistant/artificial grad student and ultimately a "narrow agi" artificial scientist.  the planned next steps to expand the user interface functionality include:
1.  expanding query functionality to make it type agnostic, so any combination of elements (genes, proteins, RNAs, et) with arbitrarily specific interactions between them can be used to query the bio-atomspace

2.  adding the atomspace explorer as an additional visualization with the ability to select subgraphs in the regular graph viz and show their atomese equivalent in atomspace explorer, and vice versa

3.  adding a database import wizard with a graphical atomese editor to allow the user to define and implament an import script for an arbitrary database

to adapt this system to language processing or a general opencog development interface, it would be necessary to define and construct the atomspace knowledge metagraph, define queries to send from the browser interface, and define relevant output displays and downloadable formats.

Xabush is the main architect of the system but he is on sabatical so may not be available to answer questions for a couple weeks, but i will do my best in his absence.  Hedra designed the import scripts and atomese queries, this code is available here:  https://github.com/singnet/agi-bio

the browser based stuff is all javascript but i don't know what flavor off the top of my head....

[Linas Vepstas]

Reslav,  (and Micheal ... below)

Thanks! That is a very nice summary. I'm not sure quite where that leaves me, except maybe back at square-one. I'd like to see some kind of cute graphical atomspace browser that beginners could run, and ... ideally, run the demos from the examples directory. 

Kind of unrelated to that is that I would like to have a data science dashboard. So, what Mike says about MOZI -- but I am not working on bioinformatics,  I am working on learning. I have similar needs: I have datasets that need to be managed and loaded. I have data-mining jobs that run for hours (or longer). I have to start, stop, checkpoint things, make backups. Then when I'm done, I need to make charts and plots to see what happened.

Currently, I do the above with a strange brew of README files, bash scripts, config files, gnuplot, and the LyX word processor.  I have found that 99% of potential collaborators do not have the attention span to get to the end of a README file.  You have to be super-duper motivated to read it, and follow the instructions.  So I'm thinking that, vaguely, surely, there must be some way of converting that into some kind of interactive web pages that walk you through the steps.

Again: MOZI has built something like this, but it is custom-tailored to bioinformatics. And so I can't use any of it.  If it was general purpose, there would be the benefit of shared development: anything done by one project (e.g. learning) could be used in another project (e.g. bioinformatics).

Dashboards -- well, when I say dashboard, what I think of are things like the BIOS boot-up screen -- menus and lists and configurable parameters and you can navigate it with keyboard or mouse.  My wifi router has a dashboard -- it's a web page, you can configure wifi settings in it.  My (android) cell phone has one: it's the "settings" panel: you can change this or that setting, turn things on and off.

So I'm thinking the same thing but for generic data science with opencog. Take this file, copy it to that  directory, start this script, look at diagnostic output, wait until the dataset is done, and when it's done, paint a green dot, and if it crashed, paint a red dot. That kind of stuff.  Show me a graph of megabytes used so far, cause I have a datacap of 1 million atoms per month. JK.😂

Is there some kind of generic data science dashboard out there, that we could adapt and use for managing opencog systems?

--linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CANHDs8%3DrtH%3DUwMb5zwetbX9UPk3XiFnTnw2hy--aNmDqXkr3%3DA%40mail.gmail.com.

[Lansana Camara]

Linas,

Dashboards -- well, when I say dashboard, what I think of are things like the BIOS boot-up screen -- menus and lists and configurable parameters and you can navigate it with keyboard or mouse.  My wifi router has a dashboard -- it's a web page, you can configure wifi settings in it.  My (android) cell phone has one: it's the "settings" panel: you can change this or that setting, turn things on and off.

 

So I'm thinking the same thing but for generic data science with opencog. Take this file, copy it to that  directory, start this script, look at diagnostic output, wait until the dataset is done, and when it's done, paint a green dot, and if it crashed, paint a red dot. That kind of stuff.  Show me a graph of megabytes used so far, cause I have a datacap of 1 million atoms per month. JK.😂

What you're asking for here is basically what they pay me the big bucks in Silicon Valley to build on a 9-5 schedule 😂

As previously stated, I really don't mind spinning up some boilerplate, such that a new frontend developer familiar with React and other modern technologies can get up and running with little hesitation. That would literally take me a day or two or effort, tops. But it wouldn't really include any functionality -- it'd just include the foundation to build functionality on top of.

If you want a full on production-ready dashboard/control panel experience, with data visualization and data management...that is a different level of responsibility. Even if it isn't built from scratch, plugging your data into a pre-built system is not necessarily more trivial. 

As someone that doesn't have the full context of opencog/atomese that you have, it would be much easier if you could draw up some wireframes (or go to Upwork.com and hire a graphic designer to build some wireframes for like a measly $100) of the screens you're imagining in your mind. Once I see those screens, it will be much better for me in terms of figuring out the scope of work required here, which I can then clearly communicate back to you.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34UVtF9vnOua5YOEVQuwZo_Z3PJkNZGVVYaC3H4yNUycg%40mail.gmail.com.

[Linas Vepstas]

On Tue, Jun 29, 2021 at 11:49 PM Lansana Camara <lxc...@gmail.com> wrote:

Linas,

Dashboards -- well, when I say dashboard, what I think of are things like the BIOS boot-up screen -- menus and lists and configurable parameters and you can navigate it with keyboard or mouse.  My wifi router has a dashboard -- it's a web page, you can configure wifi settings in it.  My (android) cell phone has one: it's the "settings" panel: you can change this or that setting, turn things on and off.

 

So I'm thinking the same thing but for generic data science with opencog. Take this file, copy it to that  directory, start this script, look at diagnostic output, wait until the dataset is done, and when it's done, paint a green dot, and if it crashed, paint a red dot. That kind of stuff.  Show me a graph of megabytes used so far, cause I have a datacap of 1 million atoms per month. JK.😂

What you're asking for here is basically what they pay me the big bucks in Silicon Valley to build on a 9-5 schedule 😂

Sigh. It shouldn't be like that.  I won't create a GUI mockup, for two reasons: first, this is something that artists and designers do, when trying to take an existing system to the next level. Right now, we don't have anything basic. Second, these kinds of things best evolve through regular use: you use it for a while, and if it stinks you stop using it, or you alter it so it works right. It's very hard to predict what that might be in advance. Also, processing steps evolve, flows change. The flow from last month might no longer apply this month.  The process changes; the GUI needs to be malleable.

Now, back in the day of desktop apps, there was this thing called a "gui designer". It allowed you to drag-n-drop menus, text-boxes, buttons, plots, charts, change their color, font size, stuff like that. You could hook them up to code that "did stuff": there was an editor, and you'd fill in the blank: on button-press, do this. On double-click, do that. If you never used one, you should try it. They're awesome!  The one for Gnome/GTK is glade -- https://glade.gnome.org/

Is there something like this for React and/or Angular?

I am confusing you and I am confusing myself, because I am talking about three different things.

1) An atomspace visualizer. This would be for complete beginners, and would be a web-javascript thing, so that we could stick it on a website, and allow people to dink with it, without having to install anything at all.  Bonus: it runs on tablets.

2) A dashboard. I'm starting to think that maybe using Glade and GTK to build a desktop app is not a bad idea.  The only thing wrong with that is it wouldn't run on cell phones and tablets.

3) A science exploration ... system/journal. Perhaps Jupyter is the best choice for this.  The most deeply flawed problem with Jupyter is revision control. If you change one line of code in Jupyter, and do a diff, you get thousands of lines of code changed. That sucks: that makes using git completely useless.  I'm told that there are some maybe-solutions for this, but I haven't really looked/tried.

In some ideal world, a combination of all three would be best.  I guess.

-- linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAPPXERrZ5tpm5HD-nQxs09ykEUERzQ0hAcytrahzU_vE-UBhdg%40mail.gmail.com.

[Lansana Camara]

I don't see why you couldn't get all three with JavaScript. A web application built in JavaScript (React) can be ported into Electron, which enables cross-platform desktop applications. In other words: one language, one application, all platforms and mobile devices.

I've worked on some very sophisticated dashboards that were built for the web, and I'm of the mindset that there is simply no need for complex low level languages like C/C++ in the user interface domain, unless you're dealing with low level embedded systems or something like that. But this problem isn't in the space of embedded systems; it's in the space of mobile/desktop applications. Thus, in my humble opinion, cross-platform mobile/desktop applications are best left to modern user interface technologies like JavaScript/TypeScript and the frontend ecosystem built with it.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37ba8zJnEodzavpSo3hF6b6nAt0Q2rmAvvZC93i%2BCLa_Q%40mail.gmail.com.

[Adrian Borucki]

On Wednesday, 30 June 2021 at 19:10:38 UTC+2 linas wrote:

On Tue, Jun 29, 2021 at 11:49 PM Lansana Camara <lxc...@gmail.com> wrote:

Linas,

Dashboards -- well, when I say dashboard, what I think of are things like the BIOS boot-up screen -- menus and lists and configurable parameters and you can navigate it with keyboard or mouse.  My wifi router has a dashboard -- it's a web page, you can configure wifi settings in it.  My (android) cell phone has one: it's the "settings" panel: you can change this or that setting, turn things on and off.

 

So I'm thinking the same thing but for generic data science with opencog. Take this file, copy it to that  directory, start this script, look at diagnostic output, wait until the dataset is done, and when it's done, paint a green dot, and if it crashed, paint a red dot. That kind of stuff.  Show me a graph of megabytes used so far, cause I have a datacap of 1 million atoms per month. JK.😂

What you're asking for here is basically what they pay me the big bucks in Silicon Valley to build on a 9-5 schedule 😂

Sigh. It shouldn't be like that.  I won't create a GUI mockup, for two reasons: first, this is something that artists and designers do, when trying to take an existing system to the next level. Right now, we don't have anything basic. Second, these kinds of things best evolve through regular use: you use it for a while, and if it stinks you stop using it, or you alter it so it works right. It's very hard to predict what that might be in advance. Also, processing steps evolve, flows change. The flow from last month might no longer apply this month.  The process changes; the GUI needs to be malleable.

Now, back in the day of desktop apps, there was this thing called a "gui designer". It allowed you to drag-n-drop menus, text-boxes, buttons, plots, charts, change their color, font size, stuff like that. You could hook them up to code that "did stuff": there was an editor, and you'd fill in the blank: on button-press, do this. On double-click, do that. If you never used one, you should try it. They're awesome!  The one for Gnome/GTK is glade -- https://glade.gnome.org/

Is there something like this for React and/or Angular?

I am confusing you and I am confusing myself, because I am talking about three different things.

1) An atomspace visualizer. This would be for complete beginners, and would be a web-javascript thing, so that we could stick it on a website, and allow people to dink with it, without having to install anything at all.  Bonus: it runs on tablets.

I’d like to see a solution that I can run locally and get exports of images with some AtomSpace views visualised. That way I could store them to document how an AtomSpace changes during agent training and review them after, e. g send those to TensorBoard.

 

2) A dashboard. I'm starting to think that maybe using Glade and GTK to build a desktop app is not a bad idea.  The only thing wrong with that is it wouldn't run on cell phones and tablets.

3) A science exploration ... system/journal. Perhaps Jupyter is the best choice for this.  The most deeply flawed problem with Jupyter is revision control. If you change one line of code in Jupyter, and do a diff, you get thousands of lines of code changed. That sucks: that makes using git completely useless.  I'm told that there are some maybe-solutions for this, but I haven't really looked/tried.

Yes, there are solutions like nbstripout that strip all the unnecessary metadata and cell outputs so that you can preserve the notebook in its pristine state - additionally you can install git hooks and filters so that diffs on notebooks and commits are automatically processed with nbstripout. There are solutions for displaying diffs as changes in code instead of changes to the underlying JSON. Sadly, Github doesn’t do that yet. For Python there is even a package (nbdev) for turning it into a literate programming setup.

[Linas Vepstas]

I don't get it ...  javascript *is* a complex, low-level language.  .. it's certainly *much more* complex then C or C++ ... this discussion is not meant to be a language war, it's meant to be about "how can we actually accomplish this?"

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAPPXERpJ1kXpzEZSj8ENMWQdutnu-N4Wa0oTBMpc%2B4x1Ph56Bg%40mail.gmail.com.

[Douglas Miles]

Btw, I too am for an example [G]UI in which can be used by as a debugging pipeline for linguists here are some examples 

https://logicmoo.org/xwiki/bin/view/Main/Developer/Mockups/#HSHOT231

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34cicZZpuDSPSFLg5d%2B8ToXFyqD-2ODQ-9wOxkHyvOFfg%40mail.gmail.com.

[Abdulrahman Semrie]

Hi Linas,

(Sorry for not responding earlier. As Mike have explained, I'm on vacation and don't check my e-mail regularly. I should be able to answer more questions when I'm back next week)

More or less, the three requirements that you mentioned above have either been partially implemented (1) or were planned to be implemented (2 & 3) in the previous Mozi platform iteration, albeit using the (now old?) Python API of the AtomSpace. The code for both the backend and frontend is available on gitlab in a private Mozi repository. I should probably export it to github and make it public.

Going through the list of requirements:

1) We had an interface to create an AtomSpace from a scheme file but back then we had issues keeping the imported data into separate AtomSpaces and accessing them independently. If you remember. this is before you implemented the copy-on-write functionality. However, with the AtomSpace gRPC server that I wrote few months back, this is possible and I have been using multiple atomspaces to run annotation tasks but haven't developed a generic UI around it.

2) I was actually planning to extend the gRPC server by integrating it with Grafana for monitoring purposes. Unfortunately, I didn't find the time to implement it. AFAIK, Grafana handles much of the UI stuff and only needs some API for it to be used as a dashboard/monitoring tool. I think this is easier than writing a new UI code.

3) For the visualization, in addition to the visualizer in https://github.com/opencog/external-tools/,  we developed our own custom Cytospace visualizer that visualized atoms representing biochemical entities using custom layouts. This is the visualizer used in the annotation service you linked above. The main issue we had with the Cytoscape visualizer was calculating the layout algorithms on the front-end when the size of the graph got bigger. I suppose anyone who wants to use a data explorer with the atomspace will eventually run into such a performance issue as the atomspace gets bigger. To resolve this, I created a small library that runs the layout algorithm on the backend and send the coordinates of the nodes and edges to the front-end. This code is not generic but some part of it can be reused or it can be refactored to make it generic.

> Maybe a kind-of-like jupyter for the atomspace.

This kind of functionality was also implemented on the old Mozi platform using cogserver but it needs updating.

In conclusion, a skeleton of what you have listed above exists, but needs refactoring to make it generic/reusable and also merge it into one tool/product.

[Lansana Camara]

Linas,

No language war intended lol, just being direct. I like Abdulrahman's recommendation of Grafana. If that's the kind of plug-and-play system you want, go for something like that. 

Keep in mind that even Grafana's UI is built in JavaScript ;) building a modern frontend like what you're seeking using a language like C/C++ would be an anti-pattern. It's simply harder to do it that way.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/d16f492c-26f2-4f21-807e-e02cfd8f7c6cn%40googlegroups.com.

[Linas Vepstas]

Douglas, that's a vast collection of screenshots, most of which seem appalling. Debugging in the atomspace is .. a whole nuther issue. --linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAER3M5%3DqeZvQLop27%3DGU8iH1eJOX8Q%2BZ9piaB0zZMTgxPJRJkw%40mail.gmail.com.

[Linas Vepstas]

Hi, Good to hear from you ...

On Thu, Jul 1, 2021 at 11:53 AM Abdulrahman Semrie <hsam...@gmail.com> wrote:

Hi Linas,

(Sorry for not responding earlier. As Mike have explained, I'm on vacation and don't check my e-mail regularly. I should be able to answer more questions when I'm back next week)

More or less, the three requirements that you mentioned above have either been partially implemented (1) or were planned to be implemented (2 & 3) in the previous Mozi platform iteration, albeit using the (now old?) Python API of the AtomSpace.

The python API is not "old" ... it's still there, it still works, it's still "official". Nothing's changed.

If you mean the REST API, that was deprecated in 2015, which apparently didn't actually stop people from using it. That's unfortunate, since ... well ... here we are, trying to figure out how to clean up after it. I would like to understand why these accidents keep happening, or rather, figure out how to avoid them. It's some kind of procedural or organizational or communications problem. It feels like (to me) we waste a lot of effort creating unusable, unsupportable code.

The code for both the backend and frontend is available on gitlab in a private Mozi repository. I should probably export it to github and make it public.

Huh. Well, I don't know what that is, or what it looks like, so I can't comment.

Going through the list of requirements:

1) We had an interface to create an AtomSpace from a scheme file but back then we had issues keeping the imported data into separate AtomSpaces and accessing them independently.

I don't understand what you are trying to say here...

If you remember. this is before you implemented the copy-on-write functionality.

I don't actually remember that. I do recall that we had several conversations on usability and requirements for multiple AtomSpaces.... those kinds of requirements are very important, actually, since they make clear what it is that people are trying to do, and making the atomspace easy-to-use and flexible is an important strategic goal. 

If you (or anyone else) has more requirements, problems/issues driven by real-world use, please open github issues (and or email discussions) Again, this stuff is important. I'm eager to solve those kinds of problems, ... 

However, with the AtomSpace gRPC server that I wrote few months back, this is possible and I have been using multiple atomspaces to run annotation tasks but haven't developed a generic UI around it.

I don't know what "it" is. I think I did try to discourage you from writing the gRPC server, but hey, sometimes the best way of learning is by doing. There are often multiple ways of solving a problem.

I did make some general comments about "what's wrong with grpc" on this page: https://wiki.opencog.org/w/Networked_AtomSpaces -- your design might be able to evade some of the criticisms there; I don't know. It's a very slippery surface. Many others before you have tried to walk it, and have fallen off.  It can be done, just it's not easy.

2) I was actually planning to extend the gRPC server by integrating it with Grafana for monitoring purposes. Unfortunately, I didn't find the time to implement it. AFAIK, Grafana handles much of the UI stuff and only needs some API for it to be used as a dashboard/monitoring tool. I think this is easier than writing a new UI code.

Wow! That's actually very pretty! It could be interesting, if it's easy to use. So, for example, I run batch jobs, or "experiments", which are sequences of shell scripts, and they print out to the screen some progress stats ... If I could get live progress stats for each job/experiment, that would be very interesting.

I imagine MOZI has something similar: I know you have jobs that run for hours, it would be nice to get a separate grafana display for each job, to see how it's progressing.

3) For the visualization, in addition to the visualizer in https://github.com/opencog/external-tools/, 

That vizualizer has been moved to  https://github.com/opencog/atomspace-visualizer -- I split it out last week, it should never have gone into external tools in the first place...

The problem is, of course, is that ... it uses the obsolete REST API, which means .. it doesn't work, except for the demos. It's badly bit-rotted, and it's not clear who can fix it. ...

we developed our own custom Cytospace visualizer that visualized atoms representing biochemical entities using custom layouts.

Yeah, I fiddled with cytoscape too. It has lots of confusing menus; it would be cool if we could somehow disable most of them.

I exported atomspace data to "gml" -- https://en.wikipedia.org/wiki/Graph_Modelling_Language -- which is an underwhelming format, .. something nicer/better would be nice, but I couldn't find anything.

This is the visualizer used in the annotation service you linked above.

I don't know what an "annotation service" is -- this is a term that you use a lot in the MOZI code base, but if I type in the phrase "annotation service" into google or duckduckgo, I get assorted random junk ... I never figured out what that is supposed to be..

The main issue we had with the Cytoscape visualizer was calculating the layout algorithms on the front-end when the size of the graph got bigger. I suppose anyone who wants to use a data explorer with the atomspace will eventually run into such a performance issue as the atomspace gets bigger.

OK, this is a conversation I've been having for more than a decade. I'd like to tell you about BindLink. It is a link that returns a limited amount of Atoms. You only graph those. Because, yes, of course, if you have a million Atoms, you can't graph all of them at the same time.  Besides, it makes no sense to graph all of them. I mean, it's like saying "I want to read the assembly code for firefox, and vim won't let me do that"

Which brings me to the next point: you almost never want to graph Atoms directly. You want to graph "what they mean". So a graph of (Evaluation (Predicate "eat") (List (Concept "Ben") (Concept "pizza"))) should not be this complicated five-atom graph, it should be two labelled vertexes and a labelled edge.  That is what should be graphed. And this is exactly the problem that BindLink solves! Oh hey!

To resolve this, I created a small library that runs the layout algorithm on the backend and send the coordinates of the nodes and edges to the front-end. This code is not generic but some part of it can be reused or it can be refactored to make it generic.

Could I make a request?  Can you write a plain-English intro to the README? Like, what the heck is Sugiyama Layout? What's MLL? Why should I care? And again, what's an "annotation service"?

I clicked through enough of the links to think "gee this is interesting", but not enough to think "oh hey, I could make good use of this". The bridge between "interesting" and "directly useful" is a very important bridge to build.

> Maybe a kind-of-like jupyter for the atomspace.

This kind of functionality was also implemented on the old Mozi platform using cogserver but it needs updating.

In conclusion, a skeleton of what you have listed above exists, but needs refactoring to make it generic/reusable and also merge it into one tool/product.

Sigh. I don't know where to begin.  I'm looking for the shortest path, the easiest path, something that is both "interesting" to everyone on this mailing list, and "directly useful" to as many as we can find.  I mean -- there are people lurking in the wood-work.  Look at Doug Miles collection of screenshots. Surely we can have something .. better than that.

--linas

On Saturday, June 26, 2021 at 10:04:34 PM UTC+3 linas wrote:

Hi Xabush,

So I have a tough question for you: the MOZI webserver ... 

I'm trying to solve a meta-problem: I want to increase developer engagement in opencog/atomspace.  For that, it would be nice to have a web UI. Three of them actually, or four.

1) A web UI that allows users to create new atomspaces, and put (by hand) some atoms into it, and visualize simple graphs. So, people can point their browser at it, and mess around.

2) A job control panel web UI. So, for the language learning project, I have a collection of bash scripts that start and stop the atomspace, and ingest text files, and take hours or days to run.  I thought of MOZI because it has some similar requirements.

3) A data explorer. Given an atomspace, with say, millions of atoms (from language learning, or from biochem), I want to explore what's inside of it: print all atoms in some cluster, ranked by frequency, or plot some histogram of mutual information vs frequency or whatever.  Maybe a kind-of-like jupyter for the atomspace. Again, I think of the MOZI work in this direction.  You were trying to get a simple web UI for biochemists to use. I want the same deal, but for linguists. Under the covers, it's all the same stuff: just atoms in the atomspace.

How can this be accomplished? You've built some kind of custom solution for 2 & 3 for MOZI, but I don't understand how to backtrack out of that, and custom-tailor it so that it works for language learning instead of ChEBI or PubChem.  Any ideas?

I mean, you and Hedra have put a lot of effort into these things...

I see things like this:

https://github.com/MOZI-AI/annotation-service

and this:

https://github.com/MOZI-AI/annotation-service-ui

And I'd like to have it work for the kinds of graphs and systems in the language-learning codebase, instead of biochemistry.  What would it take to have that work? Do I really have to start from scratch? Is there a way to recycle any of the work that you've done, and use it for other applications?

I don't want to go off and state the obvious, but maybe I should go off and state the obvious: if this web UI stuff was generic, then other users could use it, which means that other users could show up and help fix bugs and add features. It would grow the project overall ... it would help anyone interested in the atomspace and in singularitynet and all that jazz ...

BTW, back in the days of Hanson Robotics, we had the same problem ... I think we throw a lot of money at some Brazillian to create a WebUI for the Owyl behavior tree subsystem, but .. of course, that code failed with the AtomSpace, so it was like .. wasted money, wasted effort. .. we still don't have a generic AtomSpace WebUI ...

-- Linas

--

Patrick: Are they laughing at us?

Sponge Bob: No, Patrick, they are laughing next to us.

 

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/d16f492c-26f2-4f21-807e-e02cfd8f7c6cn%40googlegroups.com.

[Linas Vepstas]

Hi Lansana,

On Thu, Jul 1, 2021 at 11:58 PM Lansana Camara <lxc...@gmail.com> wrote:

Keep in mind that even Grafana's UI is built in JavaScript ;) building a modern frontend like what you're seeking using a language like C/C++ would be an anti-pattern. It's simply harder to do it that way.

We hear you. You have a very strong opinion. But before you say, once again, how hard C and C++ is, and how easy javascript is,  you should try Glade. https://glade.gnome.org/ And not just try it, but get good with it. Build an app with it.

Now, if we had some kind of app builder for javascript, then, yes, you might have a point. But as long as you use words like "anti-pattern", that is just bomb-throwing. It basically illustrates that .. I dunno .. you are young and inexperienced, and haven't been around the block, yet.  There's much, much more to this big wide world than what your friends are talking about.

When you drink the Kool-Aide, ask yourself, "what did they put in this stuff?"

--linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAPPXERrWx4%2B59Kf163pAnmyaOD%2B5bbQ0pSJ89vFbE50CPrSLNw%40mail.gmail.com.

[Lansana Camara]

We hear you. You have a very strong opinion. But before you say, once again, how hard C and C++ is, and how easy javascript is,  you should try Glade. https://glade.gnome.org/ And not just try it, but get good with it. Build an app with it.

I'll tell you what - you try React/TypeScript, and I'll try Glade. The challenge is to build a cross-platform app that runs on desktop + web. After experimenting, we can both come back with our analysis and compare/contrast things like community support, the time it took us from start to finish, difficulties encountered, etc. Deal? 

You've mistaken me for a biased, opinionated developer. Wrong. I use the right tool for the job.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35AAE89d4K6bxZeofcyDKbrsXkQCCcvBCGtRj-nv6OLhg%40mail.gmail.com.

[Linas Vepstas]

Lansana,

Let me be clear about this. There is nothing wrong with javascript, or with React, and I never once said that there was anything wrong with those technologies, or that this was NOT the correct solution. If you, or anyone else, can cobble together a solution based on that technology, I would welcome it.

I am trying to open your eyes to other possibilities, to other ways of seeing the world.  You are not the first programmer to walk this Earth, you are not the first person to have been faced with these kinds of problems.  I do not enjoy reading insulting, demeaning emails, no matter who writes them.

From what I can tell, you appear to be deeply immersed in "bro culture". This is a toxic behavior pattern, where young guys (usually white guys) think that they have all the answers to everything, and are quite willing to insult and demean anyone who is not a part of their "in group". Don't be that guy. Don't insult everyone who doesn't agree with your viewpoints.

-- linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAPPXERpw8PyF5%3DA9TN4c2FeNcbTqRPnokVA4S%3DOQEukh65qVCg%40mail.gmail.com.

[Lansana Camara]

Linas,

Dude I totally get it. Again, you have me confused for someone I’m not.

Let’s take a step back. Correct me if I’m wrong, but this whole thread is about you wanting to rebuild a UI that was left in a poor state and is difficult to maintain, right? So, how do we make sure we don’t find ourselves in that place again? 

That’s the problem I’m trying to solve. A tried and true technology that has strong community support is typically a good approach to solve that kind of problem. That’s all. 

If you have other recommendations, fine. If they’re better tools to solve the problem at hand, fine. 

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35xZpJ%3Db6a3ZObT2AD1GjLdUVsFa6Q0DSMHBaow4GUSCw%40mail.gmail.com.

[Linas Vepstas]

On Sat, Jul 3, 2021 at 1:33 PM Lansana Camara <lxc...@gmail.com> wrote:

Linas,

Dude I totally get it. Again, you have me confused for someone I’m not.

I'm sorry. Thank you.  Let us continue, then.

Let’s take a step back. Correct me if I’m wrong, but this whole thread is about you wanting to rebuild a UI that was left in a poor state and is difficult to maintain, right?

Yes, something like that. Except it was never a UI  -- it was a neat demo that drew some pretty pictures.  They weren't terribly useful in themselves, it was more of a "proof of concept". There was an implicit promise that this would be a platform which could be extended to perform more sophisticated tasks that "real life users" would need -- to do something "actually useful".

I recently thought to myself "oh hey, that screenshot looks nice, lets run it", and promptly realized that there's a  substantial amount of maintenance needed just to get it operating again.  At this point,  starting all over again becomes a viable option.

 

So, how do we make sure we don’t find ourselves in that place again? 

By understanding how we got to this place, the first time.  At the end of every project, a good project manager performs a "post-mortem" -- an analysis of everything that went right, and everything that went wrong. What should be done the same next time, what should be done differently. So, just like engineering, but with ill-defined social structures and procedures, instead of software. ( I saw one post-mortem that lasted two weeks -- all-day meetings, involving  everybody on the team showing up for at least one day. Maybe we can be quicker here?)

Now I could talk about "what we want in the future", but that is surprisingly ill-defined, so let's take the trip down memory lane.

There have been eight "visualization" attempts with opencog:

* One used "dotty" and converted a select portion of the AtomSpace into a graph. I think Joel created this, and Ben got him to make three graphs that were presented at a conference.

What's wrong with dotty? Well, back then, the pictures it drew were not very pretty. Nor was it some do-everything  visualization tool: it was some quick hacks. It needed to do one task and it did it, but there was no clear path forwards.

* Hopping around in time: just a year ago, I hacked some GML (graphics markup language) to export some very special AtomSpace graphs, and then used Cytoscape to draw them.  This is almost exactly like the dotty situation, just with a completely different set of technology,   There is no obvious path forwards to a "do it all, do everything" atomspace visualizer.

* Tulip. Same story as above, but with Tulip.

* GTK Viewer. This was a learning experience for someone who was writing their first major GTK app. Learning experiences are great, for the people doing the learning. Less so for everyone else. Problem? The requirements were never clear. The requirements were "draw Atoms in the AtomSpace" and it did that. But so what? Who is going to use this? What will they use it for? What is it good for? If you build a tool that no one needs, then it's not a tool, its artwork.

* AtomSpace Viewer -- written in javascript and HTML5. Screenshot looks fairly impressive. I never saw it run. Was it useful for anything? Was it ever used to do anything useful? I don't know, I don't think so. However, based on the screenshot, it looks like it was "almost useful" .. for .. something!?

* Glimpse. No clue what that was. I think it was HTML5 and javasccript. No surviving screenshots.

* GephiMindAgent -- streamed Atoms to Gephi. Written in either C++ or python, not sure. The source code appears to have been lost. (I was unable to find it)

* The present-day (as of 2017) AtomSpace Explorer -- javascript and Angular. Draws pretty pictures, but does not do anything interesting or useful.

Conclusion:

-- three tools were quick hacks that were used to do something actually useful and needed. But, as quick hacks, they had no future.

-- five tools that draw pretty pictures, but did not do anything useful. Some or maybe even all of these might have been "platforms" that could be extended, enhanced to add new, useful features, so that they *could* be used for something useful. However, they all bit-rotted, before that happened.

How do we avoid this problem in the future? Well,

-- The tool needs to do something actually useful, today. Pretty pictures are not enough.

-- It has to be maintainable and extensible. That means cleanly organized code, reasonable documentation, a build process that is reproducible. Should not depend on obscure, hard-to-find, unstable components.

-- I think the above two are enough to guarantee a user base that is interested enough in the code to keep it moving forward. As long as there is a user base, bit rot can be mostly avoided.

This email is too long already so let me cut it off here.  The next task is really to solve the first bullet: what should the new system do, and how will that be interesting enough to keep it maintained? Also: can it be laid out so that the new system can be cobbled together by an extremely small number of programmers with a tiny amount of free time?

These last two questions are non-trivial, and may be "unsolvable", if there are no willing users.

-- Linas

 

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAPPXERony-grxxDKwf_c4TCqKwdUEcGc75FgADefSY1QQG-6HA%40mail.gmail.com.

[Adrian Borucki]

On Saturday, 3 July 2021 at 03:48:53 UTC+2 linas wrote:

Hi Lansana,

On Thu, Jul 1, 2021 at 11:58 PM Lansana Camara <lxc...@gmail.com> wrote:

Keep in mind that even Grafana's UI is built in JavaScript ;) building a modern frontend like what you're seeking using a language like C/C++ would be an anti-pattern. It's simply harder to do it that way.

We hear you. You have a very strong opinion. But before you say, once again, how hard C and C++ is, and how easy javascript is,  you should try Glade. https://glade.gnome.org/ And not just try it, but get good with it. Build an app with it.

Ah, I remember toying with Glade… a decade ago. I don’t think GNOME developers use it anymore - GNOME Shell itself uses JavaScript nowadays for example.

A better proposition for C++ would be QtCreator because it and Qt framework at least are supposed to be cross platform - there is a UI designer in QtCreator of course.

All in all the problem with these is that they make you stuck with a specific tool (Glade / QtCreator) and framework (GTK+ / Qt) and none of those are particularly popular anymore (besides GTK+’s niche in Linux world).

 

Now, if we had some kind of app builder for javascript, then, yes, you might have a point.

A quick search shows that there are some options for JS too, like https://openchakra.app, https://reactstudio.com or https://builderx.io.

[Adrian Borucki]

On Sunday, 4 July 2021 at 23:34:50 UTC+2 Adrian Borucki wrote:

On Saturday, 3 July 2021 at 03:48:53 UTC+2 linas wrote:

Hi Lansana,

On Thu, Jul 1, 2021 at 11:58 PM Lansana Camara <lxc...@gmail.com> wrote:

Keep in mind that even Grafana's UI is built in JavaScript ;) building a modern frontend like what you're seeking using a language like C/C++ would be an anti-pattern. It's simply harder to do it that way.

We hear you. You have a very strong opinion. But before you say, once again, how hard C and C++ is, and how easy javascript is,  you should try Glade. https://glade.gnome.org/ And not just try it, but get good with it. Build an app with it.

Ah, I remember toying with Glade… a decade ago. I don’t think GNOME developers use it anymore - GNOME Shell itself uses JavaScript nowadays for example.

A better proposition for C++ would be QtCreator because it and Qt framework at least are supposed to be cross platform - there is a UI designer in QtCreator of course.

All in all the problem with these is that they make you stuck with a specific tool (Glade / QtCreator) and framework (GTK+ / Qt) and none of those are particularly popular anymore (besides GTK+’s niche in Linux world).

There is another drawback I forgot to mention -- Glade (as well as QtCreator) do not generate code for the GUI (they only generate code stubs for signals/slots). Glade saves an XML (QtCreator has something similar, I don’t remember if it’s XML) which then has to be loaded by GtkBuilder to build the interface on the fly (similar mechanism for Qt) -- this means that if in the future you want to modify this interface you *have* to use those particular tools or learn to navigate XML manually, you do not get everything represented by understandable code, the GUI representation will be more obscured by the process. One advantage of the tools below on the other hand is that they seem to produce actual JS code, so a programmer can just modify it as they see fit later on and you’re not locked to those tools.

[Michael Duncan]

linus, here is a suggestion for a useful domain agnostic graphical interface to attract opensource devs to opencog and lower the learning curve for the opencog system.

start with a knowledge metagraph complex enough to be a useful for the "intro to opencog" tutorial, which would include the atoms in all the examples.  some subset of SUMO small enough to fit into a low end laptop (4-8G ram?) is one possibility but i'm guessing because i haven't actually played with SUMO or any of the examples except for the ones in the unit tests...

 ideally there would be a public server running the demo system so users could run the examples from their phone or a netbook, with step by step instructions for setting up a local instance for more ambitious users

a dashboard shows stats for the complete atomspace (type counts for atoms, data sources, etc), and a menu for pulling example sub-metagraphs from the atomspace server

paired visualizer windows based on atomspace explorer code to show the graph representation of the atomese metagraph and the more conventional knowledge graph triplet translation of the data based on the mozi parsing code.  hovering over nodes or links in either view would show more detailed info and highlight corresponding objects in the other viewer.

each viewer has an editor to visually construct new graphs, directly in atomese in the explorer version or as node-link-node triples in the conventional window that gets translated into atomese in the explorer window.

new sub-metagraphs could then be added to the existing atomspace or a new atomspace depending on server resources.  add a pattern matcher interface window and new metagraphs could be used to query the atomspace.

make some jupyter notebooks of the examples accessible from the server with instructions for following along in the editor and you've expanded the potential audience for opencog by several orders of magnitude.

[Linas Vepstas]

Hi Mike,

On Mon, Jul 5, 2021 at 11:30 AM Michael Duncan <mjsd...@gmail.com> wrote:

linus, here is a suggestion for a useful domain agnostic graphical interface to attract opensource devs to opencog and lower the learning curve for the opencog system.

Yes. The way I like to think of it is "people like visual bling, so how can we make the tutorials visual and entertaining?"

start with a knowledge metagraph complex enough to be a useful for the "intro to opencog" tutorial, which would include the atoms in all the examples.  some subset of SUMO small enough to fit into a low end laptop (4-8G ram?) is one possibility but i'm guessing because i haven't actually played with SUMO or any of the examples except for the ones in the unit tests...

I'm certain that 100% of SUMO will easily fit into a few hundred megabytes, and probably a lot less.  (Size is not a problem; the AtomSpace has been very highly optimized for size and speed.) My only problem with SUMO is "what is it good for?" or "what can you do with it?"  -- someone would need to figure that out.

 

 ideally there would be a public server running the demo system so users could run the examples from their phone or a netbook, with step by step instructions for setting up a local instance for more ambitious users

There are several places where such servers could be run; I have several public servers (for other things) literally within arms length. There's already a cloud instance hosting the opencog site; it could also be used. So availability of servers/compute is not an issue. Heck, you could run the whole thing on a raspberry pi, I think ...

a dashboard shows stats for the complete atomspace (type counts for atoms, data sources, etc), and a menu for pulling example sub-metagraphs from the atomspace server

grafana was suggested for that ... 

paired visualizer windows based on atomspace explorer code

Well, but the atomspace explorer code doesn't work, which is what started this conversation. It would require a large amount of effort to fix it ...  Recall, Lansana suggested that we should throw it away, and replace it with some other system, written in React.  ...

In other words .. start from scratch. Ooof. The only rule of the game here is the person doing the work gets to pick the tools being used. The only advice is a trope from ancient Kung Fu movies: "choose wisely".

Hey, if someone else writes some code to take a flat file of atomese in it, and visualize it, I'll write the code to hook it up to a live atomspace.

--linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/b750b969-6cb6-4303-b986-7e963e0d90bfn%40googlegroups.com.

[Ivan V.]

May I ask did you solve the problem from bullet No. 1? Who will use it and for which purpose?

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35tErzxe%3D%2Bj2hObh36d__4Ghmi_u7b9cJ3LuK8PD%3DeXsQ%40mail.gmail.com.

[Ivan V.]

Hi all :)

Just thinking out loud, these may be some suggestions...

• How hard is it to implement a theorem prover in Atomese? (narrow, but noticeable user base; a strong potential for graph visualization)
• How hard is it to implement a math expression solver in Atomese? (wider user base; weaker potential for graph visualization)
• How hard is it to implement a program code synthesis system in Atomese? (well, this should be the future of programming; almost none potential for graph visualization)

Do I miss something more ear-catching, and more applicable to graph visualization? Does this make any sense at all with fitting into the big OpenCog picture? Lastly, does anyone have any interest in contributing to any of these use cases?

And another "hey" from my littleness - according to Linas' visualisation idea, if someone decides to roll on the whole thing, and if server side scripting not a problem, I would be interested in sponsoring the OpenCog foundation with a fractal graph visualizer for tree structures repo that I'm developing for some time now. Of course, I am able to adjust the visualizer licence to OpenCog licencing standards, and I'm prepared for very flexible terms, so no worries from that side.

Be well,

Ivan

[Linas Vepstas]

Hi Ivan,

Thank you for the invitation to write another essay on symbolic AI.  Before I answer your questions, I'd like to distinguish between 3 or 4 things that are easily entangled.

First -- there is OpenCog. Roughly speaking, this is meant to be a software implementation of Ben's vision for AGI, which he has spelled out in multiple books over the decade(s). I guess the most recent one is "Engineering General Intelligence", now a few years old.

-- There is PLN, "Probabilistic Logic Networks" -- This is another one of Ben's creations -- it is a generalization of First Order Logic to a probabilistic (Bayesian) setting. It's meant to be a mashup of the best of both worlds.

-- There is the AtomSpace, which is a (hyper-)graph database. ("metagraph" is another popular term.) Originally envisioned as a "Knowledge Store" for different kinds of "Knowledge Representations", and for the search and retrieval of specific bits of "knowledge". (KR S&R), the Atomspace has evolved to be "as generic as possible", while still having "extremely fast graph traversal". (i.e. what's connected to what.)

-- There is Atomese, which is a collection of predefined types of Atoms that "do things".  The point of Atomese is to explicitly express relationships between "things", so that algorithms (i.e. machines, not people) can access that structure and manipulate it.  At the same time, Atomese is executable, evaluatable. So if a graph can be thought of "a collection of pipes", Atomese defines "what flows through those pipes." So Atomese is at the same time a Knowledge Representation Language, and also a Graph Database, and also a Programming Language. All three rolled into one.

With that intro:

On Sat, Jul 10, 2021 at 11:54 AM Ivan V. <ivan....@gmail.com> wrote:

Hi all :)

Just thinking out loud, these may be some suggestions...

• How hard is it to implement a theorem prover in Atomese? (narrow, but noticeable user base; a strong potential for graph visualization)

Well, what do you mean by "theorem prover"? I know three different variants.

-- First, there is a collection of mathematical research devoted to understanding "what is a theorem?" "what is a proof?" "How do they work together?" and "where do algorithms fit in?" This is an inder-disciplinary line of work, melding together five or six different branches of mathematics: model theory, proof theory, category theory, type theory, topology and logic. It has been very fruitful, with some of the finest mathematicians generating many notable and important results.

-- Second, there are specific efforts to automate some mundane, routine mathematical tasks. For example, one is to verify the proof for the classification of groups. This proof was published in the 1950's and 1960's, in many hundreds of journal articles, written by many hundreds of authors, spanning many thousands of pages. No human has ever understood the entirety of it -- or even read all of it -- so there may be errors. Thus, it would be nice to automate this, and have a machine crunch through it, and make sure it's right. Doing this requires having practical software that is easy to use and is fast. In some ways, it can be compared to having a calculator, but instead of a calculator for numbers, it's a calculator for rings and fields and orders.  There are a dozen or more such systems, ranging from cutting edge research platforms, as in the first bullet above, to quotidian, practical systems that aspire to little other than being usable and effective.

-- Third, there are neural nets, which suggest interesting theorems. This is kind of weird, because it calls into question: "what is an interesting theorem?" and, more generally, "what is mathematics, anyway?" Humans decide what is interesting, and it's up to sociologists, psychologists and philosophers to figure out what that means, to trace the currents of influence from prof to student, much like fashion styles: dresses, skirts, short skirts, long skirts, jeans, pant-suits. Short hair, long hair, hats. Mathematics ebbs and flows like fashion. It's kind of weird when you ask a neural net to do it for you.

Where might OpenCog, or PLN or Atomese fit in?

-- For me, personally, Atomese is kind of a research platform in the first sense: I am trying to figure out how to mash up all those different branches of mathematics, plus also probability, into a flexible, fast, useful and usable platform for "knowledge representation". I invite everyone to participate; but it's arcane enough that few are drawn into it.

-- For "practical" theorem proving, one must have a system that is fast ... well, you might think that PLN could be used for that.  There's only one catch: PLN is designed to work with probabilities, and this makes it (as currently designed & envisioned) prone to combinatoric explosion, with only the most basic, remedial algorithms for controlling this ("attention allocation" or "ECAN" or "openpsi")  The probability aspect ruins things for "theorem proving" -- because there are no probabilities in theorems. Everything is "crisp logic" -- crisp true/false values. So you can't start with PLN.

You could start with a brand-new project: take some existing system: for example, some SAT solver, or some answer-set programming (ASP) solver, or even something like AGDA or some HOL theorem prover, and figure out how to wrap Atomese around it.  This is doable. It's interesting. It's worthwhile.  And it requires laser-like focus: "why am I doing this?" and "what's it good for?" have to be the primary #1 questions in the forefront. Because these guide the actual design. In this sense, yes, one could write a theorem prover in Atomese, .. as long as you know what it's good for, and what you hope to accomplish.

-- For theorem discovery ... well, yes, that too. However, we still do not have an adequate wrapper for neural nets (e.g. tensor flow) in Atomese. There was an attempt to do this a few years ago, but I feel it went off the rails, and didn't quite work out. I think the general idea is still valid: and in terms of importance, it might be one of the most important things we could do: we need -- we really really really need, a good, solid, strong whizbang Atomese API into tensorflow and/or other frameworks.  I wish someone would step up and do this. 

• How hard is it to implement a math expression solver in Atomese? (wider user base; weaker potential for graph visualization)

Not sure what you mean. Like a symbolic algebra toolkit? Something that factorizes polynomials over ideals and rings? Something that estimates integrals? Say, like the commercial product "Mathematica"?  Hmm, I dunno. So, Wolfram has a proprietary product which generates income which is used to hire programmers to make it better. By comparison, stuff like GNU Octave does not have this virtuous capitalistic feedback loop, where users pay money to make Octave better. Open Source has trouble exploiting simple profit loops. Open source can only exploit more complex, sophisticated and fragile financial feedback loops. I suppose professors of finance and business and economics study how open source makes financial profits, but I have not seen anything particularly strong. There are assorted anecdotes  for running an open source business, but mostly everyone is still scrambling to "monetize" their work.

Now if I could only monetize this email. Turn it into a youtube channel. Nurture it to a thousand subscribers ... ten-thousand subscribers. Have some embedded advertisements (may I suggest that Wolfram pays me ten cents for everyone who reads this email? Maybe if I mention McCombs Business School, they'll send some $$ my way.) Or maybe some in-app purchases.  My bitcoin addr is  1MjcVE8A4sKDqbbxSf8rej9uVPZfuJQHnz or the image below

So there. Step 1 ... Step 5. $$$ Profit!

 

• How hard is it to implement a program code synthesis system in Atomese? (well, this should be the future of programming; almost none potential for graph visualization)

There seem to be a handful of existing systems for this. Things that write your for-loops and if-blocks for you. It's ... uhhh ... well. ... sure ... There are aspects of programming that are like ... building websites. You no longer need to know HTML and CSS, You just need to know how to give your credit card to GoDaddy, and drag-n-drop your way to a colorful website for your business. So, sure, there are aspects of programming that will fit in that mold, and these can be found and refined and turned into a business ... I dunno, automated cell-phone app builders, or automated IoT agents, or whatever.

But this is ... a business. Something an entrepreneur might try. Its not part of Ben's OpenCog vision, it's not something PLN can do, and .. sure I guess you could use the AtomSpace to store the "knowledge" of "how to write a program", but, to the aspiring entrepreneur, I cannot offer a compelling use case to choose the AtomSpace over something that the  Apache Foundation might have to offer.

Do I miss something more ear-catching, and more applicable to graph visualization? Does this make any sense at all with fitting into the big OpenCog picture?

Well, I listed three distinct visualization apps. 

(1) graph visualization for the AtomSpace, so that beginners can get comfortable with running the examples and demos.

(2) a sophisticated debug tool for exploring complex hypergraphs/metagraphs

(3) a dashboard/ GUI panel for controlling processing. (In the olden days, Ben called these "MindAgents".) In practice, it's a bunch of shell scripts and perl scripts and scheme and python scripts -- all wired together to create some data processing pipelines.  And .. hey!  It would be way cool to represent that pipeline in Atomese!  It would be wayyy cool to allow different providers to provide these scriplets, and when you wire them together and run them, you could exchange some crypto-token, for doing that processing -- for the CPU, the RAM, the algo. 

So you would have some graphical UI, showing how to wire together different subsystems with drag-n-drop (it's just Atoms/Atomese! The graph browser of (1) is enough for this!), and then watch the processing happen, via a Graphana-type visual interface. And you'd pay each processing provider some ERC20 tokens (no wait, maybe Cardano is better...)  .. This would be drag-n-drop data-mining heaven.  If only there was someone who was interested in building something like that. I even got a cool name for this project: we could call it "the Network of Singularities".  Or NetSing, for short.  I should bend Ben's ear about this, I think it's a really great idea!  Although I guess it could be hard to make it work.

 

Lastly, does anyone have any interest in contributing to any of these use cases?

And another "hey" from my littleness - according to Linas' visualisation idea, if someone decides to roll on the whole thing, and if server side scripting not a problem, I would be interested in sponsoring the OpenCog foundation with a fractal graph visualizer for tree structures repo that I'm developing for some time now. Of course, I am able to adjust the visualizer licence to OpenCog licencing standards, and I'm prepared for very flexible terms, so no worries from that side.

Sure, but I'm not clear what a "fractal graph visualizer" is. And as to a "free structures repo" -- well we already got one -- the AtomSpace -- so I'm not interested in reinventing that wheel. It's more like .. I want to use the wheel I got to build a car.

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6WhiAPmHUH4m8s0Q_YS%2BOFARGvZZ7w7zVjOEKj4wyu97g%40mail.gmail.com.

[Ivan V.]

Linas, thank you for the response.

I believe you misunderstood my original intentions, but there are indeed some shadows I'm currently hunting in that direction. Skip to part 2 of this mail to see me getting back to reality right now.

Part 1

In my mail I didn't try to propose any AtomSpace change, but now that you brought it, I might have some thoughts to share about it.

I'm aware of the community atmosphere around OpenCog: to invent an artificial intelligent entity that would reach and possibly surpass human intelligence. It all sounds very cool, and it should be a dream that we as humanity should follow in a more organized way, I agree. But the thing is - that dream still seems so distant and placed so far in the future, and it may be wise to corroborate it with more concrete material.

My thoughts are pretty simple. The current state-of-art of symbolic AI applications falls into two groups: (1) too narrow AI that has great specific use cases, but seems unattached from the ultimate AGI dream; (2) too broad AGI visions so abstract that it hardly finds a use in the real world. Here, I'm mostly concerned about the point (2). It is too abstract, and I believe most people feel intimidated by it, not because of its complexity, but because of its progressive nature that requires a huge mind-shift. What I see as a possible approach for wider acceptance is a combination of those two. In particular, specific Atomese libraries (narrow AI) could find a real world use while they could be all brought under one umbrella - general Atomspace philosophy (AGI). These libraries could be anything (data computing is almost a limitless source of inspiration), but for this approach to work out and to be accepted by a broader public (I believe this is initial essence of this conversation), it would be necessary to introduce a significant change to AtomSpace philosophy: it should turn into a human operating language, which contradicts the current AtomSpace intention: to be a machine intermediate for accomplishing different tasks.

The benefits should be obvious - it would be closer to a broader public that would understand it, envision new real world uses, and contribute to the project with, I believe, really cool atomese libraries. I can't think of any drawbacks. The only change would be that AtomSpace would not be a machine language anymore, yet it would be intended for human use. And what humans can read and write, machines can also read and write, of course. I'm not sure what specific implementation would satisfy the current OpenCog community, probably some extensible language that compiles to AtomSpace (I might have some ideas about this, but I'll leave this question open for now). To resume the idea - now we have a machine usable language, but if we extend it to human readable format, we don't lose anything, we only gain a broader user base - all the potential troops of end users that may be able to apply parts of OpenCog by hand to specific areas of interest without even touching Scheme, Python or C. Don't know about you, but this sounds very intriguing to me.

Maybe I've gone a bit too far with my dreams, but what the heck, I may be heard by someone who eventually might care. Of course I don't expect radical changes to the whole OpenCog philosophy after all the invested man-hours to bring it to the current state, but if it was 2006 again, I don't know, maybe all this could be worth considering.

But this is more than enough of my lunatic rumblings, so let's get back to the real world. In part 2 there is a specific offer I'd like to make regarding the visualization request.

Part 2

So let's get back to my original offer - the thing you misplaced with AtomSpace change proposition. With both my feets on the ground, I believe you might be interested in the following visualization library (merely a utility not having nothing in particular with AGI, but may help with any kinds of tree data visualizations). It's a fractal-structure-inspired, parent-child-orbiting, zooming-elements-based visualization library. These are some thumbnails to tickle your inspiration:

The whole thing is of a dynamic animation nature, all the navigation is done only by dragging ovals, it runs fast enough within a browser, even on cell phones, but there's a catch - it requires a server side scripting. If you are interested in this to be a part of OpenCog, let me know if I should post the link to a live example and download page because the last thing I want to do is to spam or abuse this mailing list. I'd only like to help with the visualization thing, if that's ok with everyone.

Kindest regards,

Ivan

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34LW2y0ef72%3D4c2OGCLS%2BV9%3DFSVPRUupiBZLALDwrGd7g%40mail.gmail.com.

[Linas Vepstas]

I'm going to top-post, rather than reply to specific points you make.

I understood your intent, and I kind-of intentionally ignored it, to make some different points.

About what could have been, and what might be: So, in 2009, we were on AtomSpace version 2.0, and it could have been commercialized. It would have been among the first, if not the first graph database. To do that, we needed a marketing genius, and a CEO with a drive for creating useful products. Neither were on the scene.

Let's assume that the above had happened: version 2.0 had turned into a successful product. The likely outcome of that is that the current version would not exist: the intervening decade of research would not have happened. The insights would not have happened. We'd be stuck with an old, outdated graph database.

Could the AtomSpace of today be productized? Yeah, I think it could be. It's not too late. No one else has caught up with it, yet, in terms of features and functions. But we would need both a marketing genius to sell it, and an engineering genius to convert it into something people want. Both of these skills are still absent in the organization, still absent amongst the readers of this mailing list.

OK, so maybe we don't need a marketing genius and an engineering genius to do this. Perhaps a group of ordinary skilled programmers could pull this off. Might such a group self-assemble? Not likely, based on past experience.

How much of *your* life would you be willing to spend on a risky venture? Should you write code first, and hope to profit later? Or should you write a business plan first, raise some venture capital, and then hire coders to do the needed work?  Both paths take real effort, concentration, guts, focus, will-power.

Where would I fit in? I would absolutely *love* to closely advise anyone attempting such a commercialization effort. But eventually, we would drift apart. My interests remain in research, and not in commerce. I'm already designing a replacement for the  AtomSpace, a version that abandons the concept of Atoms, Nodes, Links, and replaces them with germs and sheaves. Designing is too strong a word. More like, daydreaming about it. Mulling it over. There's way too much old code to easily make the leap.  There's not yet any clear, easy path from the current code base to a new code base.  And I do NOT want to just jump to a new code base, because that would be a giant step backwards.  I hate going backwards.

If the current AtomSpace is version 8.0 (or whatever it is; I stopped counting long ago.) then version 9.0 will have Atoms and Nodes and Links as a layer sitting on top of sheaves and germs. Maybe. That's what it seems like it would need to be.

----

Re your pictures: they seem to illustrate Mobius Transforms on the Poincare disk. These moves are a cornerstone of the Modular Group, Elliptic Curves and Analytic Number Theory.

Here's some pretty pictures I've drawn that are invariant under the modular group:  First one is the Weierstrass elliptic function g_3

The next one is Klein's J-invariant:

These are both rotated by 90 degrees from your picture. And actually, looking at them, I think they might be using the punctured q-disk instead of the poincare disk. I don't recall.

The poincare disk can be mapped to/from the (poincare) upper half-plane, but also to the real numbers. The sold blue and dashed-yellow lines correspond in the pictures below:

And this:

Note that *all* lines above are perfect semi-circles. These are cut-n-pasted from the following paper: https://linas.org/math/chap-minkowski.pdf

--linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6U9v%2Bu2fJKe8Ykn3LpJoZed_NhDVZ_ixQsYuPA1izBfbA%40mail.gmail.com.

[Ben Goertzel]

Ivan,

Without trying to respond to all your points, I would like to note that the new language we are designing for the "OpenCog Hyperon" system (which will involve creating new systems to play the roles of a bunch of existing OpenCog code, details being worked out) -- which we have been calling "Atomese 2" but will soon have a less awkward name -- is indeed intended to be a human readable/write-able language corresponding to the internal operations of the Atomspace metagraph...

Regarding visualization though, I don't see how to connect the fractal images you show w. Atomspace visualization in a direct way.  Do you have some thoughts there?   Atomspace visualization is one of many OpenCog-related topics that turns out to be much harder than it seems at first...

About narrow-AI applications of symbolic or neural-symbolic AI, certainly they are worthy of attention, and indeed they might be an easier way to garner wide developer enthusiasm than AGI R&D.   And yes both current OpenCog and Hyperon and Linas's future germ/sheaf-based system etc. should be usable for such narrow-AI applications....   If you want to build one many of us are here to offer what guidance we can...

ben

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6U9v%2Bu2fJKe8Ykn3LpJoZed_NhDVZ_ixQsYuPA1izBfbA%40mail.gmail.com.

--

Ben Goertzel, PhD
http://goertzel.org

“He not busy being born is busy dying" -- Bob Dylan

[Ivan V.]

Hi Ben,

Without trying to respond to all your points, I would like to note that the new language we are designing for the "OpenCog Hyperon" system (which will involve creating new systems to play the roles of a bunch of existing OpenCog code, details being worked out) -- which we have been calling "Atomese 2" but will soon have a less awkward name -- is indeed intended to be a human readable/write-able language corresponding to the internal operations of the Atomspace metagraph...

Great! Can't wait to see how it works out. I hope it will be followed by good documentation.

Regarding visualization though, I don't see how to connect the fractal images you show w. Atomspace visualization in a direct way.  Do you have some thoughts there?   Atomspace visualization is one of many OpenCog-related topics that turns out to be much harder than it seems at first...

Thank you for asking, and my thoughts are pretty obvious. As I understand, URE and PLN are all about proofs, so my thoughts may go in that direction. Suppose we have a natural deduction proof composition:

  ---   ---   ---     ---   ---   ---     ---   ---   ---
   I     J     K       L     M     N       P     Q     R
 -----------------   -----------------   -----------------
         A                   B                   C
-----------------------------------------------------------
                             X

You can already see the tree-like composition, but as it may span over a very wide and tall area, it may be required to represent it within an on-demand scaling system. This example roughly shows what I have imagined for proof representation. In the example you can play with ovals, dragging them around and in or out the central area, zooming proof parts of the current interest. Notice how it is possible to represent and navigate nearly infinite length proofs, assuming enough memory space.

If you are interested in the used visualization library, I can private mail you a download link, and we can arrange details about licensing - no worries, I'm a very reasonable guy.

About narrow-AI applications of symbolic or neural-symbolic AI, certainly they are worthy of attention, and indeed they might be an easier way to garner wide developer enthusiasm than AGI R&D.   And yes both current OpenCog and Hyperon and Linas's future germ/sheaf-based system etc. should be usable for such narrow-AI applications....   If you want to build one many of us are here to offer what guidance we can...

Also great. I'm looking forward to seeing how things will be connected together in the next iteration. In the future, I may have an interest in more serious add-on contributions if you would find them appropriate, but I like to work alone, so some amount of time may pass before my next report regarding that cause.

Thank you,

Ivan

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBeScDCuuM2LLXr%2BySsu%2Bh--V7iHgRV0hGUdmjki%2B8Kn9w%40mail.gmail.com.

[Linas Vepstas]

Hi Ivan,

On Mon, Jul 12, 2021 at 6:00 AM Ivan V. <ivan....@gmail.com> wrote:

Thank you for asking, and my thoughts are pretty obvious. As I understand, URE and PLN are all about proofs, so my thoughts may go in that direction. Suppose we have a natural deduction proof composition:

  ---   ---   ---     ---   ---   ---     ---   ---   ---
   I     J     K       L     M     N       P     Q     R
 -----------------   -----------------   -----------------
         A                   B                   C
-----------------------------------------------------------
                             X

You can already see the tree-like composition, but as it may span over a very wide and tall area, it may be required to represent it within an on-demand scaling system. This example roughly shows what I have imagined for proof representation. In the example you can play with ovals, dragging them around and in or out the central area, zooming proof parts of the current interest. Notice how it is possible to represent and navigate nearly infinite length proofs, assuming enough memory space.

Re: navigating trees: if you don't already know this, then I suggest that you really, really should study hyperbolic rotations aka mobius transformations on the poincare disk. They implement your example.  I recall seeing a demo of this at SIGGRAPH two or three decades ago. As you pan around on the hyperbolic disk, different parts of the graph get magnified at the center. And, like an MC Escher print, the rest of the graph remains compressed at the edges. 

For scale-free networks, this doesn't work. And from what I can tell, learning really does result in something close to scale-free networks.  What this means in practice is that there's one vertex with a million edges coming off of it.  There are two, with half-a-million each. Four, with a quarter-million each, and so on. So almost all vertexes have just a handful of edges connected to them, but as you move around, from vertex to vertex, you bump into these monsters. And you can't really draw them: try drawing a vertex with a thousand edges on your 2Kx2K monitor: most of those edges will be less than one pixel from each-other. It'll be just a big blob.

It's important to "eat your own dog-food", as they say, or "smoke your own dope": use your own code to solve actual, real-world problems. This very quickly highlights where all that beautiful theory doesn't quite work out in practice.

--linas

[Ivan V.]

I made a small infinity test too. Each parent virtually has an infinite number of children. Rolling ovals around, zooming ovals in, zooming ovals out, ... Surely it's not exactly perfect, but I could live with it.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34HBqa02JkW9-EVR5OrpSkOWEMGjZBOCPM2vKKpJR2%2B0A%40mail.gmail.com.

[Ben Goertzel]

A reasonable step would be for Nil to send you some real PLN and URE inference histories and see what your visualizer does with them...

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UgLR5xMP9WeE%2BWOkqBynGTr%2BNQTwsmUq9JrSuU1Sh1ZA%40mail.gmail.com.

[Ivan V.]

Great, I'm glad you are interested in an experiment.

A reasonable step would be for Nil to send you some real PLN and URE inference histories and see what your visualizer does with them...

Sure, JSON history files would be perfect (we could make this a standard communication pipe between reasoner and visualizer), but I guess I can somehow manage any existing format you are already used to. You know my mail.

Currently, the library is AJAX-ing an XML tree structure and standard HTMLs as input, with possibility of using php or other server side scripting technology to interface the input files you pass over here. Would that be ok? I have to mention, with some additional effort, there could be other input options such as reading and evaluating JSON file wrapped into javascript source code file. I'm telling this because this would exclude the requirement of running a HTTP and php server, but if it is not necessary, I'd like to avoid this step and do the php trick.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBeOoqMRD20KFDYPGG1YfRqT0qW4wehOGtTKSqTb%3D6L2Jw%40mail.gmail.com.

[Ivan V.]

While waiting for inference histories, I'm developing an idea about turning the inference visualizer into an interactive AtomSpace debugger: http://ocog.atspace.cc/.

[Ivan V.]

this is very cool, ivan!  two suggestions would be to indicate on the ovals with a tick mark where the off-screen nodes are to guide navigation, and a permanent slider/[+,-] buttons for global zoom control.  (i know these are obvious)

Thank you, Michael, for the kind words. About the tick mark, orbiting ovals may be dragged around the central oval to navigate horizontally the inference tree. About the zooming, orbiting ovals are zoomed in by dragging them into the central area and zoomed out by dragging them outside the central area. We should probably include a quick instructions button regarding this subject.

About the inference histories, I decided not to wait for them (people may be on vacation or maybe even uninterested in indulging my requests) . Instead, I decided to make an inference engine agnostic environment. I have in mind something like passing a JSON file consisting of input s-expression connected to specific output inference steps for specific s-expression parts. Knowing that new Atomspace versions may be coming, I'd like to leave the support option open. I believe that the mentioned JSON input would work well enough with the incoming versions.

peace,

ivan

čet, 22. srp 2021. u 00:09 Michael Duncan <mjsd...@gmail.com> napisao je:

this is very cool, ivan!  two suggestions would be to indicate on the ovals with a tick mark where the off-screen nodes are to guide navigation, and a permanent slider/[+,-] buttons for global zoom control.  (i know these are obvious)

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/88dc6d00-07a3-4421-9cc0-9e5e1a8d0052n%40googlegroups.com.

[Ivan V.]

Hi all,

I found some time to play with a certain example exploring the original visualization idea. This is how the inference browser would look like. Provided example is sort of burnt into the page, and it serves only as an idea evaluation prototype. But once the app would be finished, It would probably be of a php kind, accepting as a parameter a JSON file containing an inference tree to be browsed.

Before continuing, I have to ask, would there be any use of it, and would there be a space for this cutie to be a part of OpenCog? And if so, how would it be finally integrated with the OpenCog system?

All well,

ivan

[Linas Vepstas]

On Fri, Jul 23, 2021 at 7:44 AM Ivan V. <ivan....@gmail.com> wrote:

Knowing that new Atomspace versions may be coming, I'd like to leave the support option open.

I do not expect any "new AtomSpace versions".

I believe that the mentioned JSON input would work well enough with the incoming versions.

I understand you were talking abbott JSON in a different context, but there has been enough general confusion (with other correspondents) that I recently added a "what the AtomSpace is not" section to the main README. One of the things it says is "the AtomSpace is not JSON".  I think it might be educational to review this.

cut-n-pste below.

 

What it isn't

Newcomers often struggle with the AtomSpace, because they bring preconceived notions of what they think it should be, and its not that. So, a few things it is not.

• Its not JSON. So JSON is a perfectly good way of representing structured data. JSON records data as key:value pairs, arranged hierarchically, with braces, or as lists, with square brackets. The AtomSpace is similar, except that there are no keys! The AtomSpace still organizes data hierarchically, and provides lists, but all entries are anonymous, nameless. Why? There are performance (CPU and RAM usage) and other design tradeoffs in not using explicit named keys in the data structure. You can still have named values; it is just that they are not required. There are several different ways of importing JSON data into the AtomSpace. If your mental model of "data" is JSON, then you will be confused by the AtomSpace.

• It's not SQL. It's also not noSQL. Databases from 50 years ago organized structured data into tables, where the key is the label of a column, and different values sit in different rows. This is more efficient than JSON, if you have many rows: you don't have to store the same key over and over again, for each row. Of course, tabular data is impractical if you have zillions of tables, each with only one or two rows. That's one reason why JSON was invented. The AtomSpace was designed to store unstructured data. You can still store structured data in it; there are several different ways of importing tabular data into the AtomSpace. If your mental model of "data" is structured data, then you will be confused by the AtomSpace.

• It's not a vertex+edge store. (Almost?) all graph databases decompose graphs into lists of vertexes and edges. This is just fine, if you don't use complex algorithms. The problem with this storage format is locality: graph traversal becomes a game of repeatedly looking up a specific vertex and then, a specific edge, each located in a large table of vertexes and edges. This is non-local; it requires large indexes on those tables (requires a lot of RAM), and the lookups are CPU consuming. Graph traversal can be a bottleneck. The AtomSpace avoids much of this overhead by using (hyper-/meta-)graphs. This enables more effective and simpler traversal algorithms, which in turn allows more sophisticated search features to be implemented. If your mental model of graph data is lists of vertexes and edges, then you will be confused by the AtomSpace.

The actual AtomSpace resembles some aspects of all three, without being specifically any of them. It tries to be general: it wants to let you work with structured data or with unstructured data or with graphs, or any mixture of all three, however you please. It does not force any particular style.

You can store data as ontologies, or as lambda expressions, or as prolog-like logical statements, or as syntactic (BNF-style) productions or as constraints or as RDF/OWL style schemas ... you can mix declarative, procedural and functional styles ... we don't care. The AtomSpace is meant to allow general knowledge representation, in any format.

That said: it means that the AtomSpace is different and unusual. It might be a bit outside of the comfort zone for most programmers. It doesn't have API's that are instantly recognizable to users of these other systems. There is a challenging learning curve involved, here. We're sorry about that: if you have ideas for better API's that would allow the AtomSpace to look more conventional, and be less intimidating to most programmers, then contact us!

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UWpdQOir0eZ2Xj%2B8rYW1s6DtCurK%2BvJ9qa2WoxL61MVg%40mail.gmail.com.

[Michael Duncan]

linus, an outline of the potential new atomspace is here.

ivan, re my tickmark comment, what i was trying to get at is a graphical indicator for the root node so one wouldn't have to try to scoll up a node and fail to know one was at the top of the tree.  having a small window with a representation of the complete tree structure with the portion in the main display highlighted would also be helpful for navigation.

i would find this useful for exploring any tree/dag (directed acyclic graph) in the atomspace.  besides inferences traces this includes ontologies in a declarative knowledge atomspace and the boolean models output by the moses evolutionary learning system.  a dag with up to a couple hundred nodes could be tractably explored by hand.

in the mozi codebase there is an atomese to json parser (via scheme), if you are interested i can find some json examples of the above for you to experiment with.

[Ben Goertzel]

> linus, an outline of the potential new atomspace is here.
>

To be clear, we (the group of us in SingularityNET working on Hyperon,
alongside our other projects) do not yet have a detailed design for a
Hyperon Atomspace, though we do have a lot of ideas that are in an
intensive form of refinement.

Our hopeful timeline is

-- by end of August, to have a coherent, complete-ish description of
the type-system we want for "Atomese2" (the new programming language
that will be used to create and represent structures in the Hyperon
Atomspace). [this is down to Alexey Potapov and myself]

-- by around the same timeframe, to have a specific proposal for the
distributed-processing and backing-store aspects of Hyperon Atomspace,
leveraging existing key-vector stores and such ... (DAS, Distributed
AtomSpace)

-- by around Sep 15, to have some decisions on what tools we want to
use for implementing Atomese2 and DAS

(e.g. what programming language to implement Atomese2, what key-value
stores as the basis for DAS...)

Note that none of the above are specifically about the in-RAM
"Atomspace" in terms of the containers behind the Atomspace API ...

It would be possible to have a new Atomese2 language and DAS, working
together with the current Atomspace. On the other hand, if we're
implementing a new Atomese2 and DAS, it may end up being most
effective to implement a new local in-RAM Atomspace as well... this
will be considered in mid-September ...

Note that the SingularityNET team that is pushing this Hyperon design
initiative is also heavily using the existing OpenCog system, eg for
the Grace humanoid robot software system, for biomedical AI R&D, and
in the ROCCA project aimed at AI agents collectively playing
Minecraft. So the motive for redesigning/rebuilding is not a feeling
that the current Atomspace/OpenCog is bad, but rather that through
this work (and prior work) we are seeing that some things that are
fairly awkward in the current system could be made much
cleaner/easier/more-efficient in a variant system with some different
characteristics... (key examples are real-time learning interactions
btw external deep learning software and OpenCog; and large-scale
logical-inference meta-learning...)

The Hyperon wiki page contains links to a quite a lot of our
early-stage thinking on all this as it's been evolvlng over the last
year...





--

[Linas Vepstas]

On Wed, Aug 4, 2021 at 7:45 AM Michael Duncan <mjsd...@gmail.com> wrote:

linus, an outline of the potential new atomspace is here.

Thank you Micheal! 

I skimmed the proposals. They seem to make sense. Mostly, they are lacking in the next level of detail. They resemble discussions we've been having, on and off, for the last decade, and a number of ways of implementing this stuff have been debated in the past.  Some of the stuff has been prototyped and experimented with. Others have had foundations laid, but no further development done.

(You said "potential new atomspace" but this is a bit of an exaggeration. There's nothing in those proposals that the Atomspace doesn't already mostly do, or couldn't easily do, with assorted relatively minor tweaks. So it's not a "new atomspace", it's some tweaks to what is already there.)

I'm thinking it might be time for having an RFI/RFC process -- "request for implementation" -- detailed documents describing specific features and functions, together with a status for each - accepted, implemented, final, withdrawn. Kind like internet RFC's (requests for comment) or scheme srfi's, or python PEP's (python enhancement proposals).

Each RFC would be issued a number (so we can track its status) Each proposal should address some meta-questions:

* What makes the current AtomSpace inadequate for the envisioned applications?

* Can it be retrofitted with the needed things?

* Can the needed things be designed as modules on top of the AtomSpace, or can they be plugins, or shims? Do they need to be integrated? Do they require deep, difficult changes or are they shallow?

[Meta comments: My general stance is that the current AtomSpace was designed to be extremely flexible, and to accommodate these kinds of ideas. I'm mostly imagining that implementing the various described new features/functions on the Hyperon wiki page is probably straight-forward (perhaps I'm wrong.).  A lot of foundational groundwork has been laid for this kind of stuff. I'd be surprised if these foundations would not be able to accomodate the desired enhancements.]

Until there are users clamoring for these things, nothing really gets done.

I don't know if anyone has time to move forward on any of this stuff, or not. So let me shout out into the wilderness:

Going through the links:

--  The old 2017 "distributed atomspace" documents describe several ideas that have already been implemented and explored, Some are done, others were discarded because they did not work (things like UUID's). So these proposals are bit-rotted, they don't adequately describe the current situation.  This is a bad situation, since newcomers can't tell the difference between fresh-new-promising, and old-stale-broken.

-- Clicking on the first link: "Episodic Memory Design for Virtual Assistant" -- Dagim Sisay, Eyob Yidaw, Solomon Molla -- I see things like "PostGIS for GIS data" with fairly-standard SQL statements.

There is another (different) half-finished proposal for a shim, that would allow any arbitrary structured data to be mapped into the AtomSpace.  That is, instead of writing an importer to pull bulk data into the AtomSpace, the shim would declare that (for example)

Evaluation

   Predicate "foo"

   List

       Concept "bar"

       Concept "baz"

should be mapped to (for example, if its SQL or PostGIS) "SELECT (mambo, jambo) FROM TABLE lumbago WHERE thing=bob;"  and that correspondingly, changes to the AtomSpace, for this one particular type of structure, would be mapped to "UPDATE TABLE lumbago SET mambo=bar, jambo=baz;"

I think such shims can be created for any data source or sink, not just SQL. (so for example, a shim for attaching to a wikidata triplestore, or some semantic web thingy, or maybe an octree for 3D data, or a point-cloud for 3D data, or robotic SLAM systems.) The point here is that this allows different kinds of datasources to be accessed within the framework of the AtomSpace (and specifically, the query engine), without paying the (huge) overhead of trying to import everything, all in one go (and then running out of RAM). 

If anyone is actually interested in this, the idea can be developed further. I think it can be made to work, cleanly and simply, without all that much new code ... but I might be mistaken about the difficulty. Without a proof-of-concept, who knows.

-- Clicking on the second link: "Episodic memory for OpenCog" - Alexey Potapov -- The ideas there seem a bit more sophisticated, but, after a quick skim, I don't see anything that breaks the current paradigm. There are already a number of inverted indexes and caches; only one of them is explicitly exposed to the user; the rest work under the covers, automatically. The proposal seems to be asking for more of the same.  (I skimmed it; maybe I missed something.)  Anyway, not much can be done, until there are users whose needs are so urgent, that they have the time for actual discussions, prototyping, development and testing. Until someone really really needs this stuff, it ends up on the back burner, simmering and stewing.

-- Clicking on the third link, "Episodic Storage Design" - Vitaly Bogdanov - I see this line: "Taking all of the above into account, the minimal set of operations to support by episodic storage is following:..." followed by a list. That list is very similar to the API half-way down the page of https://wiki.opencog.org/w/StorageNode  -- that API has already been implemented, tested, debugged and available in scheme, python and c++ -- So then ..??? Should I update the Hyperion wiki page to say "this part is done already"?  That is, the "Episodic Storage Design" has already been implemented"?

This is why a formal RFC/RFI/RFE process seems like a good idea -- so that we can track the status of where it's all at.

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/1738876c-09a3-42b7-8884-0b4a8449c250n%40googlegroups.com.

[Linas Vepstas]

Hi Ben,

I responded to Mike's email before I saw yours. I have to leave the house in 10 minutes, so very fast reply:

-- The DAS distributed AtomSpace documents are old and stale and describe ideas that have already been tried and discarded (cause they did not work). I mean, there are good ideas in there two, but its all tangled up.

-- The "File:Episodic storage design.pdf" from Vitaly describes something that has already been implemented and debugged and is in current use. In deference to Vitaly, you, others, I don't want to edit that wiki page and just say "done already" -- and thus I'm thinking a formal process to track status would be a good idea.

-- Dagim, etal's File:Episodic Memory Design for Virtual Assistant.pdf  proposal overlaps with another half-finished proposal for a more general variant of the same thing.  That should be resolved to avoid duplicated work.

-- Alexey Potapov's ideas in File:Episodic memory for OpenCog.pdf  are more abstract, but after a very quick skim, they seem like something that can be easily accomplished with minor updates to the existing atomspace (perhaps I am wrong; I just skimmed the thing.)

Overall, I saw nothing particularly earth-shaking, nothing that can't be accomplished with an assortment of shims, plugins, layers, some of which are already half-implemented in the code base. The nature of your email makes me concerned that you might be a bit disconnected with what is already in the code and works well, and with how the foundations have been laid out - literally, foundations, like for a house - groundwork stuff that has been laid out, and is solid, but nothing has been built on it. yet.

I'm not clear on how to easily and quickly communicate the current status, and how that would affect your plans.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBduKz%2BcPHTpmaJvMRJS3Y4y56u6RGrHRzaDVq62Ysy3cA%40mail.gmail.com.

[Linas Vepstas]

On Wed, Aug 4, 2021 at 10:20 AM Ben Goertzel <b...@goertzel.org> wrote:

  So the motive for redesigning/rebuilding is not a feeling
that the current Atomspace/OpenCog is bad, but rather that through
this work (and prior work) we are seeing that some things that are
fairly awkward in the current system

This is indeed the correct way to do things. The current system is the result of using earlier systems, and discovering they were awkward and ill-suited to the task.

could be made much
cleaner/easier/more-efficient in a variant system with some different
characteristics... 

I would really like to know these.

(key examples are real-time learning interactions
btw external deep learning software and OpenCog;

Yikes! This is exactly what the Values subsystem was designed to do well. I suspect that it is not being used as intended. Probably because it is mis-understood. I'm very interested in getting this stuff to work right, because this is important.

 

and large-scale
logical-inference meta-learning...)

No clue what the problem here is. This sounds like a Nil thing.

The Hyperon wiki page contains links to a quite a lot of our
early-stage thinking on all this as it's been evolvlng over the last
year...

As mentioned, what is there now seems to be like minor tweaks to the current system, some of which has already been implemented and is operational. So I'm perplexed that it's being presented as all-new, all-improved.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBduKz%2BcPHTpmaJvMRJS3Y4y56u6RGrHRzaDVq62Ysy3cA%40mail.gmail.com.

[Ben Goertzel]

Hi Linas,

The documents on that "Atomspace" page that Mike linked are not really
the key ones for the Hyperon design, and nor are the 2017 documents
about the DAS so important right now (Senna is in the midst of putting
together something new regarding DAS actually, informed by more recent
investigations...)

In the happy circumstance you decide to take the time to understand
the crux of what we're aiming for w/ Hyperon, Alexey's various
documents linked from

https://wiki.opencog.org/w/Hyperon:Atomese

are important; and then general formal/theoretical context is given by
my 4 papers in the first bullet list in

https://wiki.opencog.org/w/Hyperon

(which are significantly inspired by, and refer to, your work on
sheaves and germs in OpenCog .. you can see that instantly from the
diagrams in the "Folding and Unfolding on Metagraphs" paper).

I understand this is a lot of dense material to go through tho, and
you may not have time...

We are aiming to have concrete proposals for Atomese2 language
(probably with a different name) and {whatever form of Distributed
Atomspace or Atomspace-distributed-processing-framework we have
concluded is most sensible} by (hopefully) end of September.... Your
feedback on these proposals will be valued at that time, and possibly
instrumental...

We had hoped for wrapping up this early first-stage-of-design phase in
July rather than September but with various peoples' summer vacations
and a lot of work for Awakening Health it's taking a little longer.
Anyway these are far from trivial matters as u know...

ben

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA36nXLwq6N-MGWd5nJM-UVk_RLjnNQvmejMM1hSACPN_GQ%40mail.gmail.com.

[Linas Vepstas]

I'll try to take a look, but the next 2 weeks are chaotic and hectic, so I may not get the chance.

The way you talk about this makes it sound like you are contemplating a total rewrite, a brand-new code base, developed from scratch.  This is almost surely a strategic mistake. There have been any number of articles, analysis, blog posts and erudite studies on software project failures. Complete rewrites almost always fail. The school of hard knocks is a tough teacher. Much better to learn from someone-else's mistakes.

When I skimmed Alexey's papers, it seemed that the ideas there could be easily accommodated in the existing AtomSpace (again, I may be mistaken) so I don't really understand the urge to rewrite from scratch. Perhaps Alexey (and others) don't see a path from the existing code base, to one with the desired properties. That doesn't mean there isn't one. Based on past experience, it seems opaque and hidden at first, but then reveals itself.

I'm saying: don't go off half-cocked. You did this once, with the GroundedObjectNode debacle. Don't make that mistake again. There was a communications breakdown shortly before that episode started. I'm concerned we're still looking at flawed communications, and that this will lead to poor engineering decisions.

(BTW, all the groundwork has been set up to redeem and reclaim the GroundedObjectNode concept, with all the various bugs and infelicities fixed. It can be brought back from the dead, but no one has done this. I assume everyone got bored, or decided they didn't need it any more?)

-- Linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBea3_HRLMWsax%2BwSPh5pJ8ZtOsQES5j005KKjJnrKEwtA%40mail.gmail.com.

[Nil Geisweiller]

On 7/12/21 21:30, Ben Goertzel wrote:

A reasonable step would be for Nil to send you some real PLN and URE inference histories and see what your visualizer does with them...

Is that still needed?

Nil

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBeOoqMRD20KFDYPGG1YfRqT0qW4wehOGtTKSqTb%3D6L2Jw%40mail.gmail.com.

[Ivan V.]

Hi Nil,

I don't know, everybody suddenly lost interest (IIRC Linas was the only one interested), and I'm not in position to lead the visualization project on my own. Lastly, this thread mysteriously vanished from my google groups and my mail account a while ago. Now that it is back again, the visualization topic seems a bit strayed from this thread about Atomspace, so if anybody is interested in mentoring me toward a useful (still a open question) bit of visualization fragment of OpenCog, we can continue this conversation in the original thread (this thread is branched from the original "MOZI web UI" thread).

Thank you,

Ivan V.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/1571e542-776a-2aad-c15f-02aaf8ad1ca3%40gmail.com.

[Nil Geisweiller]

Hi Ivan,

I see. Well, it's probably not so much that we've lost interest and
more like we're too busy with other stuff, and so less important stuff
get forgotten. Don't hesitate to re-ping when necessary.

Nil

On 9/21/21 12:28, Ivan V. wrote:
> Hi Nil,
>
> I don't know, everybody suddenly lost interest (IIRC Linas was the only
> one interested), and I'm not in position to lead the visualization
> project on my own. Lastly, this thread mysteriously vanished from my
> google groups and my mail account a while ago. Now that it is back
> again, the visualization topic seems a bit strayed from this thread
> about Atomspace, so if anybody is interested in mentoring me toward a
> useful (still a open question) bit of visualization fragment of OpenCog,
> we can continue this conversation in the original thread (this thread is
> branched from the original "MOZI web UI" thread).
>
> Thank you,
> Ivan V.
>
> uto, 21. ruj 2021. u 09:48 'Nil Geisweiller' via opencog

> <ope...@googlegroups.com <mailto:ope...@googlegroups.com>> napisao je:

>
> On 7/12/21 21:30, Ben Goertzel wrote:
>
>> A reasonable step would be for Nil to send you some real PLN and
>> URE inference histories and see what your visualizer does with them...
>
>
> Is that still needed?
>
>
> Nil
>
>
>>
>> On Mon, Jul 12, 2021, 10:59 AM Ivan V. <ivan....@gmail.com
>> <mailto:ivan....@gmail.com>> wrote:
>>
>> I made a small infinity test

>> <http://ocog.atspace.cc/infinite/> too. Each parent virtually

>> has an infinite number of children. Rolling ovals around,
>> zooming ovals in, zooming ovals out, ... Surely it's not
>> exactly perfect, but I could live with it.
>>
>> pon, 12. srp 2021. u 17:48 Linas Vepstas

>> <linasv...@gmail.com <mailto:linasv...@gmail.com>>

>> napisao je:
>>
>> Hi Ivan,
>>
>> On Mon, Jul 12, 2021 at 6:00 AM Ivan V.
>> <ivan....@gmail.com <mailto:ivan....@gmail.com>> wrote:
>>
>>
>> Thank you for asking, and my thoughts are pretty
>> obvious. As I understand, URE and PLN are all about
>> proofs, so my thoughts may go in that direction.
>> Suppose we have a natural deduction proof composition:

>> *

>>   --- ---   ---     ---   ---   ---     ---   ---   ---
>>    I     J     K       L     M     N       P     Q     R
>>  -----------------   ----------------- -----------------
>>          A                   B     C
>> -----------------------------------------------------------

>>                              X*

>>
>> You can already see the tree-like composition, but as
>> it may span over a very wide and tall area, it may be
>> required to represent it within an on-demand scaling

>> system. This example <http://ocog.atspace.cc/> roughly

>> <mailto:opencog+u...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/opencog/CAHrUA34HBqa02JkW9-EVR5OrpSkOWEMGjZBOCPM2vKKpJR2%2B0A%40mail.gmail.com

>> <https://groups.google.com/d/msgid/opencog/CAHrUA34HBqa02JkW9-EVR5OrpSkOWEMGjZBOCPM2vKKpJR2%2B0A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> 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

>> <mailto:opencog+u...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UgLR5xMP9WeE%2BWOkqBynGTr%2BNQTwsmUq9JrSuU1Sh1ZA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UgLR5xMP9WeE%2BWOkqBynGTr%2BNQTwsmUq9JrSuU1Sh1ZA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> 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

>> <mailto:opencog+u...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/opencog/CACYTDBeOoqMRD20KFDYPGG1YfRqT0qW4wehOGtTKSqTb%3D6L2Jw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/opencog/CACYTDBeOoqMRD20KFDYPGG1YfRqT0qW4wehOGtTKSqTb%3D6L2Jw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:opencog+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/1571e542-776a-2aad-c15f-02aaf8ad1ca3%40gmail.com
> <https://groups.google.com/d/msgid/opencog/1571e542-776a-2aad-c15f-02aaf8ad1ca3%40gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:opencog+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CAB5%3Dj6VVz4h1zkKFg_R1w0kmw6yDfdyrXeyY3L48AT41Dt4teA%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAB5%3Dj6VVz4h1zkKFg_R1w0kmw6yDfdyrXeyY3L48AT41Dt4teA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Ivan V.]

Ok then.

I've got this and this, and I've got some free time. Let me know if I can be useful regarding the OpenCog visualization attempt.

All best,

Ivan

[Nil Geisweiller]

I didn't understand if I need to provide GBs of inference trails, but
anyone in need just let me know.

Nil

On 9/21/21 13:00, Ivan V. wrote:
> Ok then.
>

> I've got this <http://ocog.atspace.cc/inference-tree-browser/> and this
> <http://ocog.atspace.cc/infinite/>, and I've got some free time. Let me

> know if I can be useful regarding the OpenCog visualization attempt.
>
> All best,
> Ivan
>
> sub, 10. srp 2021. u 18:53 Ivan V. <ivan....@gmail.com

> <mailto:ivan....@gmail.com>> napisao je:

>
> Hi all :)
>
> Just thinking out loud, these may be some suggestions...
>

> * How hard is it to implement a theorem prover in Atomese?

> (narrow, but noticeable user base; a strong potential for graph
> visualization)

> * How hard is it to implement a math expression solver in Atomese?

> (wider user base; weaker potential for graph visualization)

> * How hard is it to implement a program code synthesis system in

> Atomese? (well, this should be the future of programming; almost
> none potential for graph visualization)
>
> Do I miss something more ear-catching, and more applicable to graph
> visualization? Does this make any sense at all with fitting into the
> big OpenCog picture? Lastly, does anyone have any interest in
> contributing to any of these use cases?
>
> And another "hey" from my littleness - according to Linas'
> visualisation idea, if someone decides to roll on the whole thing,
> and if server side scripting not a problem, I would be interested in
> sponsoring the OpenCog foundation with a fractal graph visualizer
> for tree structures repo that I'm developing for some time now. Of
> course, I am able to adjust the visualizer licence to OpenCog
> licencing standards, and I'm prepared for very flexible terms, so no
> worries from that side.
>
> Be well,
> Ivan
>
>
> sub, 10. srp 2021. u 07:27 Ivan V. <ivan....@gmail.com

> <mailto:ivan....@gmail.com>> napisao je:

>
> May I ask did you solve the problem from bullet No. 1? Who will
> use it and for which purpose?
>
> uto, 6. srp 2021. u 00:54 Linas Vepstas <linasv...@gmail.com

> <mailto:linasv...@gmail.com>> napisao je:

> <https://openchakra.app>,
> https://reactstudio.com
> <https://reactstudio.com> or https://builderx.io
> <https://builderx.io>.

> <https://github.com/Habush/atomspace-rpc>

> that I wrote few months back, this
> is possible and I have been using
> multiple atomspaces to run
> annotation tasks but haven't
> developed a generic UI around it.
>
> 2) I was actually planning to extend
> the gRPC server by integrating it

> with Grafana <https://grafana.com/>

> for monitoring purposes.
> Unfortunately, I didn't find the
> time to implement it. AFAIK, Grafana
> handles much of the UI stuff and
> only needs some API for it to be
> used as a dashboard/monitoring tool.
> I think this is easier than writing
> a new UI code.
>
> 3) For the visualization, in
> addition to the visualizer in
> https://github.com/opencog/external-tools/

> <https://github.com/opencog/external-tools/>,

> we developed our own custom
> Cytospace visualizer that visualized
> atoms representing biochemical
> entities using custom layouts. This
> is the visualizer used in the
> annotation service you linked above.
> The main issue we had with the
> Cytoscape visualizer was calculating
> the layout algorithms on the
> front-end when the size of the graph
> got bigger. I suppose anyone who
> wants to use a data explorer with
> the atomspace will eventually run
> into such a performance issue as the
> atomspace gets bigger. To resolve
> this, I created a small library

> <https://github.com/Habush/annotation-graph>

> <https://groups.google.com/d/msgid/opencog/d16f492c-26f2-4f21-807e-e02cfd8f7c6cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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.
>
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CAPPXERrWx4%2B59Kf163pAnmyaOD%2B5bbQ0pSJ89vFbE50CPrSLNw%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAPPXERrWx4%2B59Kf163pAnmyaOD%2B5bbQ0pSJ89vFbE50CPrSLNw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
>
>
> --
> Patrick: Are they laughing at us?
> Sponge Bob: No, Patrick, they are laughing
> next to us.
>
>
> --
> 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

> <mailto:opencog+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/b750b969-6cb6-4303-b986-7e963e0d90bfn%40googlegroups.com
> <https://groups.google.com/d/msgid/opencog/b750b969-6cb6-4303-b986-7e963e0d90bfn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
>
>
> --
> Patrick: Are they laughing at us?
> Sponge Bob: No, Patrick, they are laughing next to us.
>
>
> --
> 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

> <mailto:opencog+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CAHrUA35tErzxe%3D%2Bj2hObh36d__4Ghmi_u7b9cJ3LuK8PD%3DeXsQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAHrUA35tErzxe%3D%2Bj2hObh36d__4Ghmi_u7b9cJ3LuK8PD%3DeXsQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:opencog+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Uyjdc4DLmGwrV%2Bn77Yybv4RR1-9yHUifRAhrbisDnejw%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Uyjdc4DLmGwrV%2Bn77Yybv4RR1-9yHUifRAhrbisDnejw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Linas Vepstas]

Hi,

On Tue, Sep 21, 2021 at 5:00 AM Ivan V. <ivan....@gmail.com> wrote:
>
> Ok then.
>
> I've got this

Chicken-fried steak? Do we need to make you an honorary Texan?

> and this, and I've got some free time. Let me know if I can be useful regarding the OpenCog visualization attempt.

There are two large datasets here: https://linas.org/datasets/
Neither are "deep", (hierarchical deep) both are "broad" (have many
connections)

By contrast, Nil's inference trees are more likely to be deep.

-- linas

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Uyjdc4DLmGwrV%2Bn77Yybv4RR1-9yHUifRAhrbisDnejw%40mail.gmail.com.

[Ivan V.]

> Chicken-fried steak?  Do we need to make you an honorary Texan?

Linas, I can't work in such an atmosphere. If that’s the best you can offer, we need to split up. In that case, thank you all for your time but this is too much for me.

- ivan -

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37CeXb842bPi2QP6W9f%2B41PWLZQvi9gKJqmD3-vOUeBoQ%40mail.gmail.com.

[Linas Vepstas]

On Tue, Sep 21, 2021 at 11:26 PM Ivan V. <ivan....@gmail.com> wrote:
>
> > Chicken-fried steak? Do we need to make you an honorary Texan?
>
> Linas, I can't work in such an atmosphere. If that’s the best you can offer, we need to split up. In that case, thank you all for your time but this is too much for me.

!? I'm confused.

Your demo had the words "chicken steak" in it. I've travelled around
the world, and the only place that I know of that has "chicken steak"
on restaurant menus is Texas. They have it in Germany too, but it's
called "Weiner schnitzel" there. (There are a lot of Germans in
Texas.) But you wrote "chicken steak" and not " Weiner schnitzel" ...

https://en.wikipedia.org/wiki/Chicken_fried_steak
https://en.wikipedia.org/wiki/Schnitzel

-- linas

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6V%2Bps2AXzqkUiB-M%3DWm_07p2w1BHX%3D3J-y4E6Ngst%3DEjg%40mail.gmail.com.

[Ivan V.]

Linas,

All right, I'll swallow your unsavory joke, but I don't like it.

As for the visualization tool, I'll have more time in a few weeks when I settle some of my obligations. Then, a kind of OpenCog debugger (or IDE) is what I have on my mind. It would be something like an atomspace editor communicating to cogserver, showing inference trees related to edited fragments. Nothing too fancy, no dozens of options, just a simple atomspace expressions writing aid, as minimalistic as it can get, with an editor on the left and related inference trees on the right side.

I hope to get some answers from you guys about cogserver details if I get stuck. I'll try to keep you informed about the project progress.

Thank you,

Ivan

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA36jr9g2pWav5sSCJsBi-aXC1PNi19SeKyGOMoRiBk0vwQ%40mail.gmail.com.

[Linas Vepstas]

On Thu, Sep 23, 2021 at 12:44 AM Ivan V. <ivan....@gmail.com> wrote:
>
> As for the visualization tool, I'll have more time in a few weeks when I settle some of my obligations.

You don't have to make promises! There is no intent to guilt-trip you
into doing something.

> Then, a kind of OpenCog debugger (or IDE) is what I have on my mind.

In the end, whatever you create has to be for yourself, for your own
entertainment. If it turns out to be useful for others, that would be
wonderful, but, as this long conversation has shown, there's no
general vision of what anyone wants. Different people want different
things; what's useful for one is useless for another.

> It would be something like an atomspace editor communicating to cogserver, showing inference trees related to edited fragments. Nothing too fancy, no dozens of options, just a simple atomspace expressions writing aid, as minimalistic as it can get, with an editor on the left and related inference trees on the right side.

Two part reply. (1) inference trees are very specific to the PLN
backward chainer, and have almost nothing to do with the atomspace.
(other than that they are kept in the atomspace ... for a while ..
until they are deleted. Nil can supply those if that is what you
really want.)

(2) Don't worry about the cogserver. Don't use the cogserver. Just
work with the atomspace directly. Why? (a) you don't need the
cogserver to get things done. (b) if you absolutely must have a
network connection to some remote AtomSpace, use the CogStorageNode
-- it will automatically open a network connection to a remote
AtomSpace, and it will automatically trade atoms with it, bringing
them over to your local AtomSpace. You just have to specify which
atoms. If you are not sure which atoms, you can easily run a query on
the remote AtomSpace.

Documentation:
https://wiki.opencog.org/w/CogStorageNode

Demos:
https://github.com/opencog/atomspace-cog/tree/master/examples

-- linas

[Ivan V.]

Just a quick question while we're at it, if I may: what is the best way to communicate between web browser and atomspace?

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34zZ%2BqFdgycq8PQjp1BvikD0b1Y8HSRSebMMxCfeF5p8Q%40mail.gmail.com.

[Linas Vepstas]

On Thu, Sep 23, 2021 at 3:15 AM Ivan V. <ivan....@gmail.com> wrote:
>
> Just a quick question while we're at it, if I may: what is the best way to communicate between web browser and atomspace?

Currently, none. The "atomspace explorer" used an atomspace server
that was weird, slow, mis-designed, old and incomplete...

Let me take you on a trip.

What is really needed are some javascript bindings that talk to the
cogserver. It is very easy, trivial, even, to talk to the cogserver,
and get a reply. The hard part is to convert the results into whatever
javascript you want -- we do not have any existing layer for that.
Creating this layer would be an excellent project.

Thus, for example:
-- use javascript to open a socket to 17001
-- send command over that socket; for example,
`(cog-value (Concept "foo") (Predicate "some key"))`
-- read the result, for example
`(FloatValue 1.000000 2.000000 3.00000)`
-- close the socket, or re-use it.

Great! But how do you convert `(FloatValue 1.000000 2.000000
3.00000)` into what you want? (What do you want?)

Now, before you get on that airplane, and start writing code to use
javascript to talk to the cogserver, consider this:

If you wrote that code, you would have to cache the results locally,
in javascript. That is, you would have to create a local, in-browser
copy of (Concept "foo") and (Predicate "some key") and remember that
(FloatValue 1 2 3) is attached to it. In other words, you would be
re-inventing the atomspace, locally, running inside the browser. Good
god, why? We already have an atomspace, why reinvent a
browser-specific one? (Because this is what things like the
atomspace-explorer were doing.)

The correct solution is this: create javascript bindings for the
atomspace. That's it, end of story. Want to talk to some remote
AtomSpace? Just use the CogStorageNode! That's it, you're done.

I'll stop writing the email here .. because there is nothing more to
say! People who use web browsers need javascript. If we had javascript
binding to the atomspace, you would have it in your browser.

If you want to create these bindings, I'l create a github repo under
the opencog project, give you full write permission, and you can do
whatever in there. I'm sure many people could use them.

--linas

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UkUirdXC9h7fmgzHvaZzz46coGYTUAU2TdqigTEXX4xw%40mail.gmail.com.

[Ivan V.]

Thank you, I'll take some time to think about it if you don't mind.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35-K8V6T3V%2BM7nLSze0NdPhcuk9txBNAoMAd1XJ%3DGekEw%40mail.gmail.com.

[Linas Vepstas]

Hi Ivan,

On Thu, Sep 23, 2021 at 10:51 AM Ivan V. <ivan....@gmail.com> wrote:
>
> Thank you, I'll take some time to think about it if you don't mind.

Heh. Too late! Rather than nagging you or anyone else about this, I
thought about it a bit, and realized that I could hack up a basic
solution in a day. So I did. If you grabe the very latest atomspace
and cogserver code, then you get a simple network API to the
atomspace, here. The README explains all:

https://github.com/opencog/atomspace/blob/master/opencog/persist/json/README.md

The JSON is delivered as a string, over the network. You still have to
do something with it. If/when you want to create javascript, node.js,
emscripten, or whatever kind of interfaces to it, let me know. I just
now create a new, empty git repo at
https://github.com/opencog/atomspace-js

Anyone who is interested should just ask, I'll provide write access to
that repo.

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Vn5b1NdXa1ptQEtEMXES%3D9H23Ry6J3_X4f%3DAraf%2BEybg%40mail.gmail.com.

[Ivan V.]

Great, I believe it would ease things a lot. Let me notify you when I'm ready to do some more serious coding.

Ivan

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA36dV20DGvtE2hTP94q48-f5BrtBjRi3h%2Bv5U6hYhr3MsQ%40mail.gmail.com.

[Ivan V.]

Hi Linas and others :)

Diving deeper into OpenCog, I learned some basics of interfacing with Atomspace. I decided to delay the initial idea of visualizing the inference process, and to simply focus my attention to s-expressions which is atomspace based on. See my latest experiment with s-expressions at:

http://ocog.atspace.cc/atomizer/

The experiment simply parses provided s-expression string, breaks it down to its elements recursively, and shows it on the screen to navigate by. It isn't a super-king of usability, but it may look fancy to beginners, and attractive enough to show off to someone how the bare Atomspace concept looks like.

If bundled with an appropriate opencog input/output system like REPL or something, it may form a usable whole, at least to beginners who learn basics of interacting with Atomspace.

Finally, there may be a chance I stitch it to OpenCog. If I opt out for this, I think I'll be using telnet to connect to cogserver. I may want to make read-eval-print-loop accessible from web browsers, updating the visualization of the current Atomspace state on each cycle. There already exist some telnet libraries to do this with php, so I believe this may be a simpler solution than the proposed wrapping atomspace interface for use with js. Maybe not as flexible as Linas' proposition, but simpler.

Be well,

Ivan

[Linas Vepstas]

Hi Ivan!

Well that was fun!

There are two REPL loops (four, actually) the guile/scheme repl loop;
the guile/scheme repl loop provided by the cogserver, which is almost
the same except it runs over telnet. Then there's the python repl,
and the cogserver provides a telnet python repl, too. The telnet
python REPL is almost the same as regular python, but not quite, it
hand;es whitespace differently. Python is to blame for that:
whitespace rules for repls are different from whitespace rules on
files. Whatever. At any rate, these are all inter-operable: atoms
created in one show up in the other.

An interesting visualization is this one:
(List (Word "this") (Word "that"))
(List (Word "this") (Word "thing"))
(List (Word "this") (Word "cat"))
(List (Word "that") (Word "cat"))
...
So, if you start at (Word "this") and move up, you'll find a thousand
List's. Pick one (say, "cat") move down and then back up, you'll find
a thousand Lists that "cat" is in. Bouncing around in this network
can be entertaining, provided the pairs are meaningful.

The point here is that the s-expression (Word "that") is globally
unique: it is one and the same, everywhere.

--linas

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6WS5S0vLzNRTpBP8BSh9N6XhDmd0wxyXgES4fs2iQjHvw%40mail.gmail.com.

[Ivan V.]

Hi linas,

Nice to see someone having fun with this thingy :)

Thousands of nodes might seem a bit of overkill for this system, especially considering the fact that this system is a brute s-expression listing machine, without caring what nodes stand for the same one. I believe the system wouldn't choke on that, but navigating them would be a Hell of a task.

However, there is one trick that might render all this usable: what if there was a query system (already a part of AtomSpace) to narrow down only the nodes we are looking for. For example, a command `display some-query` could intercept an output and pipe such an output to the visualisation module, showing only atoms of our interest, not the entire Atomspace.

I was also thinking of advancing REPL to editing sessions for Atomspace scripts. Such session would first check if Atomspace is empty (eg. no one is currently using it). Then the telnet would populate Atomspace from the editing session, with intercepting `display` commands, concatenating them ino one s-expression and piping it out to the visualizer. Lastly, after ending the script, telnet would wipe out the entire Atomspace to prepare it for the next visualization cycle.

I believe this would do the trick for reasonably small scripts, just to make things simpler for newcomers, so they can play with smaller scripts.

But even if this would work, multi-user access is concerning me as a quirk I would like to avoid. Guaranteed empty Atomspace between display sessions would somehow do a job, but it does not scale very well. It would be awesome if there would be some on-demand allocating of a namespace specific to individual users connecting to cogserver.

I agree that implementing editing sessions in this way (with keeping current Atomspace state empty) sounds somewhat strange. Are there other options for doing this from telnet?

All well,

Ivan

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35rxQTu%2BNG7-k0h791LruXCLksyUCju-YgzGTC4eaQMOw%40mail.gmail.com.

[Linas Vepstas]

On Thu, Oct 7, 2021 at 3:41 PM Ivan V. <ivan....@gmail.com> wrote:
>
> Hi linas,
>
> Nice to see someone having fun with this thingy :)

Yeah. I don't know why people ignore this mailing list these days.
Maybe it's covid.

> Thousands of nodes might seem a bit of overkill for this system, especially considering the fact that this system is a brute s-expression listing machine, without caring what nodes stand for the same one. I believe the system wouldn't choke on that, but navigating them would be a Hell of a task.

Yep. and that is exactly what the atomspace does!

> However, there is one trick that might render all this usable: what if there was a query system (already a part of AtomSpace) to narrow down only the nodes we are looking for.

Yep!

> For example, a command `display some-query` could intercept an output and pipe such an output to the visualisation module, showing only atoms of our interest, not the entire Atomspace.

Yep! There is no need to "intercept it". It is given to you,
directly. The actual syntax would be
(display (cog-execute! (MeetLink ... the actual query)))
and since display doesn't print a newline, use formated print instead:

(format #t "And the answer to the query is ~A\n" (cog-execute!
(MeetLink ... the actual query)))

> I was also thinking of advancing REPL to editing sessions for Atomspace scripts.

Well, the existing repls allow you to edit to your hearts content. So
I guess you mean a new web-page repl?

> Such session would first check if Atomspace is empty (eg. no one is currently using it).

well, in typical use, you don't start empty, but either attach to some
existing database, or dump a bunch of atoms in.

> Then the telnet would populate Atomspace from the editing session, with intercepting `display` commands, concatenating them ino one s-expression and piping it out to the visualizer. Lastly, after ending the script, telnet would wipe out the entire Atomspace to prepare it for the next visualization cycle.

Well, wiping it out would be a bit much...

However, there is one weird trick ...

In your local atomspace, you can do this:

(cog-open (CogStorageNode "cog://example.com:17001"))
(fetch-atom (Concept "foo")) ; this will get all the (truth) values ...
(store-atom (Concept "bar")) ; this will store all the values
(fetch-incoming-set (Concept "foo")) ; get every Link that foo is inside of ...

so if example.com is running a cogserver on port 17001, then you can
have access to it. and copy atoms between it and your local atomspace.
Just don't trash it's contents, the owner might not be happy.

--linas

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6V2EFAbtSA-DaLgA9Kod85%3D6yMwVgz1xWoV49QQ0QGAQg%40mail.gmail.com.

[Ivan V.]

I finally got some time to move further with the OpenCog Atomspace visualisation project. Front-end is more or less finished. It includes:

• read - print - loop (RPL without Eval in the middle)
• remembering history of passed input
• reporting errors on invalid s-expressions
• visualizing valid s-expressions

The link to try it is the same: http://ocog.atspace.cc/atomizer/

What remains is the juicy part - connecting eval and print to OpenCog server REPL. Hopefully soon.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37UtMHuv-UvU3vUqnCqSuFf0Kvx3%2Be0RHPctdwrJ26aLw%40mail.gmail.com.

[Ivan V.]

Hi Linas and others,

Sorry for the delay, I've been busy with my other projects. Now I tried to install OpenCog, made through several make steps until my machine started to hang. Tried several times, it always hangs on the same build step. I guess this is a penalty for having only 4GB on my machine, right?

And then I tried another option: I installed OpenCog from here: `https://github.com/opencog/docker`. I tried to follow `README.md` instructions, ran `./docker-build.sh -a` (the script successfully completed), but then I got stuck starting cogserver because the `cogserver/build/` folder is empty.

Does anyone have some time, please, to assist me on how to run cogserver with docker if that is possible? I'm on Ubuntu 20.04.3 LTS.

Thank you in advance,

Ivan

[Linas Vepstas]

On Sun, Dec 19, 2021 at 2:11 PM Ivan V. <ivan....@gmail.com> wrote:
>
> Hi Linas and others,
>
> Sorry for the delay, I've been busy with my other projects. Now I tried to install OpenCog, made through several make steps until my machine started to hang. Tried several times, it always hangs on the same build step. I guess this is a penalty for having only 4GB on my machine, right?

It builds just fine on my six-year-old 1GB laptop (which cost $200
when new, so low end from the get-go.). I can even browse the web
while it's building.

Open a bug report. describe the problem.

> And then I tried another option: I installed OpenCog from here: `https://github.com/opencog/docker`. I tried to follow `README.md` instructions, ran `./docker-build.sh -a` (the script successfully completed), but then I got stuck starting cogserver because the `cogserver/build/` folder is empty.

The docker containers are possibly stale.

--linas

[Ivan V.]

Ok, this was fun...

I restarted the computer in the meanwhile, deleted the whole OpenCog, and recloned and rebuilt everything without any problems. This time I put all the additional assets I needed like cogserver under `opencog` directory, if that means anything.

Cogserver is now up and running on port 17001, successfully communicating to rlwrap telnet. The initial test went fine.

Next, the plan is to telnet it from php, and pipe it to html visualizer, if that's ok.

Wish me luck :)

- ivan -

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34a2O624WCfk821t3wqUEYeg0WM%2B571AOKxGG2cCUB_xA%40mail.gmail.com.

[Linas Vepstas]

On Mon, Dec 20, 2021 at 3:39 PM Ivan V. <ivan....@gmail.com> wrote:
>
> Ok, this was fun...
>
> I restarted the computer in the meanwhile, deleted the whole OpenCog, and recloned and rebuilt everything without any problems. This time I put all the additional assets I needed like cogserver under `opencog` directory, if that means anything.

You should be able to `git clone` to anywhere at all. And after
building, saying `sudo make install` puts everything under the
`/usr/local` directory.

My guess is that you had old and incompatible clones: you would have
to say `git pull` in all repos, to get a self-consistent version.

> Cogserver is now up and running on port 17001, successfully communicating to rlwrap telnet. The initial test went fine.
>
> Next, the plan is to telnet it from php, and pipe it to html visualizer, if that's ok.

probably the simplest way to do this is by wrapping php around netcat.
Warning, there are two incompatible versions of netcat you can
install. They are *almost* compatible, but not quite; one needs an
extra flag that the other doesn't, else it hangs up too soon.

I have the bsd version installed the package is `netcat-openbsd`

Use it like so: `nc localhost 17001 (+ 2 2)` or `nc localhost 17001
(cog-prt-atomspace)` and so on.

> Wish me luck :)

Good luck! and Merry Christmas, too!

-- linas

>
> - ivan -
>
> pon, 20. pro 2021. u 20:00 Linas Vepstas <linasv...@gmail.com> napisao je:
>>
>> On Sun, Dec 19, 2021 at 2:11 PM Ivan V. <ivan....@gmail.com> wrote:
>> >
>> > Hi Linas and others,
>> >
>> > Sorry for the delay, I've been busy with my other projects. Now I tried to install OpenCog, made through several make steps until my machine started to hang. Tried several times, it always hangs on the same build step. I guess this is a penalty for having only 4GB on my machine, right?
>>
>> It builds just fine on my six-year-old 1GB laptop (which cost $200
>> when new, so low end from the get-go.). I can even browse the web
>> while it's building.
>>
>> Open a bug report. describe the problem.
>>
>> > And then I tried another option: I installed OpenCog from here: `https://github.com/opencog/docker`. I tried to follow `README.md` instructions, ran `./docker-build.sh -a` (the script successfully completed), but then I got stuck starting cogserver because the `cogserver/build/` folder is empty.
>>
>> The docker containers are possibly stale.
>>
>> --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+u...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34a2O624WCfk821t3wqUEYeg0WM%2B571AOKxGG2cCUB_xA%40mail.gmail.com.
>
> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6WYVbV14e4xZPWYJm-iEnzNdi21YXQK%2BbmWRa5f%2B29j4w%40mail.gmail.com.

[Linas Vepstas]

Shoot. I wrote the wrong thing.
Try this:

echo "(+ 2 2)" |nc -N localhost 17001

The -N flag closes the socket after getting the reply, otherwise it
hangs waiting for more input.
So you'd replace the echo by php print and pipe to command.

-- Linas

[Linas Vepstas]

And one more, I hit send too soon.

echo -e "scm quiet\n(+ 2 2)\n" |nc -N localhost 17001

The "quiet" mode suppresses the printing of the guile prompts.
Unfortunately, the first prompt is always sent :-(

-- linas

[Ivan V.]

I was thinking more in a direction of including some MIT licensed php telnet library. If I'm on the right path about this, then there is no need for installing netcat, "only" php and Apache web server. But from your examples, netcat command prompt seems pretty simple to use. I'm still not sure about php running native programs, especially receiving an output from them, including running the whole app directly from the web.

- ivan -

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35jXYy0AgLtum%3DvynpN%3DjvTH0r%2Bv5NPnBWncMVAxaKjtw%40mail.gmail.com.

[Linas Vepstas]

Hi Ivan,

Some quick remarks about networking.

-- Using telnet to access the cogserver is wild technology overkill.
Telnet was designed to provide a teletype terminal over the network,
including lots of complex teletype escape sequences. The cogserver
needs exactly zero of that.

-- the cogserver network interface is extremely low-level. So
low-level, you can't get any lower. It's rock-stupid simple and basic.
You open a socket. A very basic, simple, plain ordinary socket. Then
you read and write characters to it. That's all. That's it. It's not
any harder than opening a file, and reading/writing to that. Uses the
same read/write API that files use. If you know sockets well (and it
seems very few people do) it's about 5-10 lines of code. Or less.
There's absolutely no need for complexity.

I don't know php well enough, but the pseudocode really should be
```
sock = open (locahost, 17001)
write (sock, "(+ 2 2)")
read(sock, buffer)
close(sock)
```
Really little or nothing more than that..

FWIW, that's my coding philosophy: remove as much complexity as
possible ("but no more"). Kind of everything is guided by that.

Linas

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6XaSAiommr7aLKHs880h7G_yEY0Nx2QKTismCoZRzw9nw%40mail.gmail.com.

[Jacques Basaldúa]

Hi Ivan, 

Maybe, if you use zeroMQ (there is a PHP version, https://www.php.net/manual/en/book.zmq.php) you can use the sockets just like Linas is saying.

In Python, the actual code would be:

```

import zmq

context = zmq.Context()

socket  = context.socket(zmq.REQ)

socket.connect ("tcp://localhost:17001")

socket.send ("(+ 2 2)")

message = socket.recv()

```

That requires the server to listen to the tcp socket connection which is the transport layer of your telnet connection. Telnet itself would be the application layer and, as Linas says, is probably not necessary.

My 2 cents.

Jacques.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37G6CUQrdHQpwMS%3DkmM3StUZNCrUrmsVohr-sd51ZSsgA%40mail.gmail.com.

[Ivan V.]

Thank you, Jacques, for your thoughtful response.

I've been experimenting with php for a few hours now. It's exactly as Linas said, like reading and writing files, completely php native, no addons. I'll probably go like an ajaxing php script that opens a connection, sends a command, reads a response, and closes the connection. Things look promising for now, it is just that little something I'd like to avoid: mandatory sleeping php for 125 milliseconds (on my machine) to give a time for getting the response after sending a command. But I'm out of ideas on how to avoid it.

- ivan -

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CA%2B_pmb6BgsVcp%2B9HuYY%3Dmm-%2BwNjmf7aX7aBLK1ZJ1R%3DxwZpe-Q%40mail.gmail.com.

[Linas Vepstas]

On Tue, Dec 21, 2021 at 10:05 AM Ivan V. <ivan....@gmail.com> wrote:
>
> Thank you, Jacques, for your thoughtful response.
>
> I've been experimenting with php for a few hours now. It's exactly as Linas said, like reading and writing files, completely php native, no addons. I'll probably go like an ajaxing php script that opens a connection, sends a command, reads a response, and closes the connection. Things look promising for now, it is just that little something I'd like to avoid: mandatory sleeping php for 125 milliseconds (on my machine) to give a time for getting the response after sending a command. But I'm out of ideas on how to avoid it.

Ah. But of course it's never as simple as it seems.
-- conventionally, socket-reads are blocking: the call does not return
until there is something to be read,
-- blocking kills interactivity, so usually people do socket i/o is
done in it's own thread.
-- if you don't like threads, then there are async i/o libraries that
try to avoid this,
-- and it rapidly goes downhill from there, because you have to deal
with things that hang, never return, crash, return only partial
messages, and its a general horror show.
-- I've used one async library in my life, the boost c++ async
library, and it is 100% awful.

This is why network programming is challenging.

--linas

p.s. you don't have to close the cogserver socket after one message,
you can keep it open.

> To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6XmuXC81OSgOBfa0-VWJ4TWKi80biNHbJ%3DBwa%3D1SXyYQQ%40mail.gmail.com.

[Ivan V.]

Well, this would be a pre-release of Atomizer4oc:

This is a web app that connects to CogServer via php telnet. The screenshot is taken from a session of working with OpenCog.

All of this is really a visual html/php app that communicates to OpenCog. On the left pane, there is a scheme command prompt where commands are sent to CogServer. Upon each command send, the command output is brought back to the prompt interface, and the right pane visualizer is updated to reflect the current AtomSpace contents. I believe it could be fun communicating to OpenCog this way.

Unfortunately, the app has to be installed on a local machine in order for php telnet to communicate to a local CogServer instance which is not visible to the public web. This means having php and web server on a local machine in order to run the app.

Does anyone care for a test drive? It works on my machine, but I'd love to see if it works elsewhere. You can download it from here: http://ocog.atspace.cc/atomizer4oc.zip. Unzip it and view the README.md for installation instructions. I'd love to hear bug reports, insights, criticism, or general reviews.

And finally, I'd like to hear if the app fulfills criteria for inclusion in the official OpenCog distribution. If it doesn't, I'd like to know what's missing or needs to be changed. If it does, I'm interested in sending a pull request at a place you'd find appropriate.

Thank you,

- ivan -

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34AdmAmWMxNL4dXD4ReNgcrybOiF8JXQgv2Aa7r_On09Q%40mail.gmail.com.

[Linas Vepstas]

On Wed, Dec 22, 2021 at 7:27 AM Ivan V. <ivan....@gmail.com> wrote:

And finally, I'd like to hear if the app fulfills criteria for inclusion in the official OpenCog distribution.

Yes, it does.

 

 If it does, I'm interested in sending a pull request at a place you'd find appropriate.

The current procedure is every component get's its own git repo, in this case, https://github.com/opencog/atomizer  (or pick a different name, as you wish, let me know.)  This repo gets created, and you'd get full read/write privileges to it. So you can send pull reqs and then merge them (without anyone else's involvement)  

 

it could be fun communicating to OpenCog this way.

It would be fun to load up the atomspace with one of the big datasets, e.g. at https://linas.org/datasets/ and prowl around in that and see what happens.

--linas

 

[Ivan V.]

Hi Linas and others,

In the meanwhile, I fixed some bugs and superficially tested it on Opera, Chrome and Firefox. I also decided to change the app name to "CogServerLab", if that's ok. The name is unique, and Google Search likes it.

>> And finally, I'd like to hear if the app fulfills criteria for inclusion in the official OpenCog distribution.

> Yes, it does.

I can't express my gratitude, it is the best Christmas present ever. Thank you very much.

> The current procedure is every component get's its own git repo, in this case, https://github.com/opencog/atomizer  (or pick a different name, as you wish, let me know.)  This repo gets created, and you'd get full read/write privileges to it. So you can send pull reqs and then merge them (without anyone else's involvement)

That would be great, could you please open a `cogserverlab` repository, or a directory with the similar name under visualizations project, whichever you prefer (I hope others would be fine with this, too). I'll clone it then, and send a pull request. Also, what license does OpenCog prefer? I'm totally  flexible when it comes to licensing. I'd sign the OpenCog foundation in the license file, if that's ok.

> It would be fun to load up the atomspace with one of the big datasets, e.g. at https://linas.org/datasets/ and prowl around in that and see what happens.

It depends on the amount of RAM. The biggest issue is bitmap caching, so if each oval takes 500 x 500 pixels in average, 4B per pixel, then it is about 1MB per oval, meaning 1GB of free ram should be able to hold about 1000 ovals. In practice, the shallowest oval bitmap is the biggest one, grading down with structure depth. Maybe I could work on this, to remove caching, then it would be more scalable because only visible ovals would take the bitmap memory, but the rendering would be slower and blocking. I'll try to provide both versions (cached and non-cached) switch in a separate configuration file. Other than bitmaps, an s-expression array and its tree structure array are required to reside in RAM all the time.

But I'm not sure that mega-sized-datasets are practical examples of using CogServerLab. I imagine some other uses where newbies can play with a few hundreds of atoms while learning how AtomSpace behaves on what Scheme commands in a realtime. It would be also great to see someone making an OpenCog introduction or feature video using CogServerLab. Certainly, I agree CogServerLab wouldn't be the most useful application in the world, but I guess it could be fun to play with.

There is also an option of recognizing some raw commands like `vis-only`, to run queries and visualizing only their output instead of the whole atomspace. I have to think about this one, I'm trying to keep the usage complexity at the minimum.

---

Otherwise, what is happening with OpenCog Wiki pages? It would be nice to have an objective reference to CogServerLab from there.

---

Anyway, great news, and I can't thank you enough, you're the best!.

All well,

- ivan -

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37kKaJXSio4jv-YycGp4tP%2Bdk-5DCCv6eS1F21VoJ4KZg%40mail.gmail.com.

[Ivan V.]

Hi all,

Still waiting Linas response...

While waiting, I tested the app a bit more, found no new bugs, updated the readme.md a bit, made a new cool browser tab icon , and changed the app name to CogProtoLab.

For those who can't wait, here's a new download link: http://ocog.atspace.cc/cogprotolab.zip.

All best, and merry Christmas everyone,

- ivan -

[Ivan V.]

Hi,

Progressing further in a hope that someone finds this useful:

CogProtoLab isn't tied only to visualizing hidden (cog-prt-atomspace) command output anymore. Now there is an input field where we can put any query to an AtomSpace part intended to be visualized. It should still be a gigabytes-sized-memory-mess for big dataset outputs (estimating more than several thousands of atoms), but if we query only a subset of what AtomSpace holds, ... well, it's some improvement.

Just in case someone's interested, download link is here: http://ocog.atspace.cc/cogprotolab-2.zip

Happy New Year, and be well,

- ivan -

[Linas Vepstas]

Hi Ivan,

Sorry for the late response, I guess I was taking a vacation from myself.
... More reblow

On Thu, Dec 23, 2021 at 11:33 PM Ivan V. <ivan....@gmail.com> wrote:
>
> I also decided to change the app name to "CogServerLab", if that's ok. The name is unique, and Google Search likes it.

I just now created
https://github.com/opencog/cogprotolab/
per your later emails. I could not figure out what your github ID is,
so I could not give you access. What's your github ID?

> I can't express my gratitude, it is the best Christmas present ever. Thank you very much.

Well, apparently, the gift is a bit late ..

> Also, what license does OpenCog prefer?

Almost all the repos use agplv3

> > It would be fun to load up the atomspace with one of the big datasets, e.g. at https://linas.org/datasets/ and prowl around in that and see what happens.
>
> It depends on the amount of RAM. The biggest issue is bitmap caching, so if each oval takes 500 x 500 pixels in average, 4B per pixel, then it is about 1MB per oval, meaning 1GB of free ram should be able to hold about 1000 ovals. In practice, the shallowest oval bitmap is the biggest one, grading down with structure depth. Maybe I could work on this, to remove caching, then it would be more scalable because only visible ovals would take the bitmap memory, but the rendering would be slower and blocking. I'll try to provide both versions (cached and non-cached) switch in a separate configuration file. Other than bitmaps, an s-expression array and its tree structure array are required to reside in RAM all the time.

It's hard for me to imagine how rendering takes more than fractions of
a millisecond per bubble.

> But I'm not sure that mega-sized-datasets are practical examples of using CogServerLab.

They're not mega-sized, they're "normal sized". Except for assorted
toy problems and demos, datasets consisting of 1 to 100 million atoms
would be "typical". They fit easily into RAM, they don't need the
fancy footwork that Ben talks about.

> I imagine some other uses where newbies can play with a few hundreds of atoms while learning how AtomSpace behaves on what Scheme commands in a realtime. It would be also great to see someone making an OpenCog introduction or feature video using CogServerLab. Certainly, I agree CogServerLab wouldn't be the most useful application in the world, but I guess it could be fun to play with.

Yeah, we need demos like these. We don't have enough "hello world"
entry level stuff.

> Otherwise, what is happening with OpenCog Wiki pages? It would be nice to have an objective reference to CogServerLab from there.

People who have logins can create wiki pages. You could too.
Accounts have to be added by hand, as otherwise spammers take over.

--linas

[Linas Vepstas]

On Tue, Jan 4, 2022 at 2:21 PM Ivan V. <ivan....@gmail.com> wrote:

Hi,

Progressing further in a hope that someone finds this useful:

CogProtoLab isn't tied only to visualizing hidden (cog-prt-atomspace) command output anymore. Now there is an input field where we can put any query to an AtomSpace part intended to be visualized.

That would actually be awesome! A menu or drop-down list of standard queries would be great ... writing queries by hand is tedious and error-prone, and they're verbose, so having a menu would be great. A configurable menu would be even better.

 --linas

[Ivan V.]

Hi Linas,

A simple feature update on your idea: a configurable menu of queries is implemented - I still don't know of what form are the standard queries to include them in the menu, but it should be just a matter of adding strings in a separate quasi-JSON init file. For now I included only (cog-prt-atomspace) and a rudimentary inheritance-variable-concept matching, but I hope to get some help in this direction. And of course, all other ideas, suggestions, advices, feature requests, or any other criticism or help is more than welcome.

My github ID is: contrast-zone

I look forward to a fruitful collaboration :)

Be well,

- ivan -

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37X0pXKFvnJUkv%2BHSviVD2ThJ_h1bcd_un7%2B9nKb6SR8A%40mail.gmail.com.

[Linas Vepstas]

On Wed, Jan 5, 2022 at 11:04 AM Ivan V. <ivan....@gmail.com> wrote:

Hi Linas,

A simple feature update on your idea: a configurable menu of queries is implemented - I still don't know of what form are the standard queries to include them in the menu, but it should be just a matter of adding strings in a separate quasi-JSON init file.

The most common query I do by hand is `(cog-incoming-by-type some-atom 'FooLink)` which is relative to `some-atom` and 'FooLink is the type that I want to track down. I often precede this by `(length ...)` just to see how many I will get, to avoid endless scrolls of tens of thousands of results.

I use `(cog-report-counts)` frequently, just to see what's going on. This might be suitable for a dashboard.

Almost all manual querying that I do is relative to one or two or three atoms, and I want to see how they connect. This is usually by calling functions that have been pre-defined. e.g just today: `(LLOBJ 'get-cross-sections SEC))` where SEC is some atom.

Maybe what I need is an IDE. What I actually typed in was

+       (define allx
+               (append-map (lambda (SEC) (LLOBJ 'get-cross-sections SEC))
+                       rsect-list))

which returns a list of atoms.   Then I printed them

+       (for-each (lambda (XSE)
+               (format #t "before all cross= ~A\n" (prt-element XSE)))
+               allx)

When these looked good, I set it running, with the print statements printing every 500 loop iterations. A few hours later .. well, so far, it seems to be working.

The 'get-cross-sections method takes one rather complicated atom SEC and returns a bunch of other rather complicated atoms. The `prt-element` function prints a simplified representation of that complicated atom, just to keep it small and readable.

In a sense, I'm working at a meta-level: there is another graph I'm working with, and it is made out of complex sub-assemblies of atoms.  It's like ... I dunno ... its like, well, if one atom was a transistor, then I'm working with small IC's (integrated circuits) -- a dozen atoms that are pr-arranged in a way that I want them to be, and I work with those units, connecting things together.

That's why I suggested looking at the genetics data dump -- the biology people usually don't work with single atoms; they work with genes and proteins, and these are specific pre-assemblies of atoms. Those assemblies are all of the same "shape".  The goal is to visualize how genes and proteins interact.

--linas

For now I included only (cog-prt-atomspace) and a rudimentary inheritance-variable-concept matching, but I hope to get some help in this direction. And of course, all other ideas, suggestions, advices, feature requests, or any other criticism or help is more than welcome.

My github ID is: contrast-zone

I look forward to a fruitful collaboration :)

Be well,

- ivan -

sri, 5. sij 2022. u 00:58 Linas Vepstas <linasv...@gmail.com> napisao je:

On Tue, Jan 4, 2022 at 2:21 PM Ivan V. <ivan....@gmail.com> wrote:

Hi,

Progressing further in a hope that someone finds this useful:

CogProtoLab isn't tied only to visualizing hidden (cog-prt-atomspace) command output anymore. Now there is an input field where we can put any query to an AtomSpace part intended to be visualized.

That would actually be awesome! A menu or drop-down list of standard queries would be great ... writing queries by hand is tedious and error-prone, and they're verbose, so having a menu would be great. A configurable menu would be even better.

 --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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37X0pXKFvnJUkv%2BHSviVD2ThJ_h1bcd_un7%2B9nKb6SR8A%40mail.gmail.com.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6VN_j_%3D7UxW_4U40%2BXGy6L1zn62U%3Dzq7UEx28Fa5_kTNQ%40mail.gmail.com.

[Ivan V.]

Linas,

Thank you for the invite, I uploaded the initial commit.

Queries you use are pretty specific to tasks one wants to accomplish. Not to over engineer the whole thing, maybe it's better to leave out specific queries for specific users to edit init files to suit their specific needs? But if there are more general and wider-use queries, those would be good candidates for populating the initial menu. Overall simplicity may have a certain value, and if it is not necessary, could it be better not to complicate things too much?

(cog-report-counts) seems interesting, maybe I'll give some thought to that. But something else bugs me more (beside raising the loadable atoms count limit). If some commands run for a long time, CogProtoLab sleeps in the meanwhile, waiting for the final result. Moreover, long running processes may occasionally print out some status or some info, before finally ending, as is in your case. CogProtoLab doesn't print anything while it sleeps, as it only reads the entire finished output in a Javascript AJAX call prone to connection timeout. Maybe some php thread simulation, partial AJAX reads, or something similar would solve it, I'll have to think about it and inform myself more properly about solving this problem.

But as I see CogProtoLab right now, it is more like a beginner's toy than a full blown scientific dashboard. Maybe someday it may grow beyond being just an introductory toy, but it would still be a kind of a toy, this time for serious people who are playful kids in their hearts. It would certainly be interesting to see what kinds of queries are possible in structuring their clever results in parent-child manner, but the road seems not too easy.

Kind regards,

- ivan -

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34APJmf-FeOM2dnNDOzcndYhjxaXzTxXazTHy%3DtF-%2B3wg%40mail.gmail.com.

[Linas Vepstas]

Hi,

On Wed, Jan 5, 2022 at 1:43 PM Ivan V. <ivan....@gmail.com> wrote:

Linas,

Thank you for the invite, I uploaded the initial commit.

Yep. Looks good. Looks like you squashed the git history, or you weren't using git before this first upload.

Queries you use are pretty specific to tasks one wants to accomplish.

OK, so the general philosophy is that a tool is useful only if it does something that someone wants it to do. That means using it, and then making iterative improvements to it. So I was trying to sketch -- "here are the things that I typically do" with the idea that "if there's some tool that would make it easier for me, I would use it"

For the last two weeks, I was stuck in an extremely boring, tedious debugging session. I showed you some of the things I typed at the command line in the last email. (I think I finally fixed the last bug, just now! Phew!)

Next week, I'm doing something completely different: I'll be making about a dozen graphs showing the dependency of the number of whatszits vs. the quantity of whojies.  Much more interesting work, but still a bit tedious.   Here's how I do this:

1) write 10 or 20 line long scheme snippets to count whojies and whatszits and dump them into a CSV file.

2) Write a gnuplot command file to generate a graph.

3) Use Lyx to maintain a diary.  The graph is embedded in the diary. I look at it, think of two or four clever things to say about that graph. Think about what it all means. The meaning of life, the universe, and everything.

4) git commit the scripts of 1, the gnuplot and eps or 2, and the lyx of 3. Then go to step 1.

For a while, it seemed like Jupyter notebooks would be a better way of doing the above. However, this failed at step 4.  And it is very important to understand why!

I use git to make sure I did not make any mistakes in the previous step. I make a very large number of very small commits. This allows me to carefully review each and every commit, to make sure it does not have any mistakes.  My work lives & dies by my ability to use `git diff` to audit, to verify, to catch mistakes.

Jupyter notebooks expand into extremely verbose javascript. The `git diff` of single-line changes to a jupyter notebook blows up into a thousand-line-of-code javascript diff.  This makes it utterly, completely unauditable. That completely wrecks my workflow. Thus, while Jupyter has a beautiful on-screen layout, it has an unusable UI for diffs.  Now, I've been told that there are some work-arounds for this, but I have not explored them.  Are they any good? I dunno.

What I'm saying is that perhaps it would be good to integrate cogprotolab as a module into a jupyter notebook, assuming that the git-diff problem could be solved.

One way to verify that "this is useful" would be to create notebooks for the demos in https://github.com/opencog/atomspace/tree/master/examples/atomspace  -- so instead of looking at text files and wiki pages to understand thigs, they could plink around in the browser.

Just an idea.

(cog-report-counts) seems interesting, maybe I'll give some thought to that. But something else bugs me more (beside raising the loadable atoms count limit). If some commands run for a long time, CogProtoLab sleeps in the meanwhile, waiting for the final result. Moreover, long running processes may occasionally print out some status or some info, before finally ending, as is in your case. CogProtoLab doesn't print anything while it sleeps, as it only reads the entire finished output in a Javascript AJAX call prone to connection timeout. Maybe some php thread simulation, partial AJAX reads, or something similar would solve it, I'll have to think about it and inform myself more properly about solving this problem.

The cogserver does print partial output from long-running commands. So if you keep polling the socket, you will see output arrive as it is printed.

The cogserver is fully multi-threaded: you can open many connections to it at the same time; each connection works independently. Last time I stress-tested this, about 2-3 years ago, it scaled nicely up to about 20 or 30 simultaneous connections, and then it got slow. I don't remember why.  Some important parts of the atomspace have changed since then, so things might be better (?)

But as I see CogProtoLab right now, it is more like a beginner's toy than a full blown scientific dashboard. Maybe someday it may grow beyond being just an introductory toy, but it would still be a kind of a toy, this time for serious people who are playful kids in their hearts. It would certainly be interesting to see what kinds of queries are possible in structuring their clever results in parent-child manner, but the road seems not too easy.

The journey of a thousand miles begins with a single step.

I think integrating either with jupyter notebooks, or one of the main jupyter competitors would be a good idea. Being able to have graphical whiz-bang demos of the demo suite would be a good idea.

When I last looked, 4-5 years ago, there was some other notebook technology, that solved the jupyter unmaintainable-javascript problem. It was nice. But I've been happy with my lyx+gnuplot->PDF flow, so I didn't bother to change.

Now, if I could use lyx, but have it work in a notebook-style ... wow! That would be pretty awesome.

--linas

 

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6XeZwSmgZXLiE9RrKT4jLFehUy62dPdPMpJ23PtHyMbWA%40mail.gmail.com.

[Ivan V.]

Yeah, Jupiter, Matlab, Scilab, Mathematica, and company have always been magical to me. As my main project which would save my life, for a while now, I'm thinking of bundling together concepts from notebook + LaTeX + RuleBasedEngine + SomeVisualization, but in my own interpretation. I'm stuck at the RuleBasedEngine implementation part (it was a Hell of a problem to me just to conceptualize it), but things are developing in the right direction, maybe slowly, but steadily. In the meanwhile, SomeVisualization turned into orbiting ovals, was implemented to some extent, and I thought I could do something useful with it, hence CogProtoLab is made. I will spend some more time completing and debugging CogProtoLab, but then I have to return to my main project because I need something more than air to survive. Of course, I'll make sure to be always available for bug fixing, tweaking, or reasonably upgrading CogProtoLab because being part of the OpenCog community means a lot to me. AI is the future of the world, and with wise management, it may turn this world into something beautiful. I'm aware how small my contribution is, but whatever it is, it makes me happy.

And just to be noted, the more I learn about AtomSpace, the more I like it. There are some things I'd do differently, but AtomSpace is already here and working well right now, at this moment. Good job.

- ivan -

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35nDvOGCmPwLpoRD27Q8abv-KHtvsDa85Knb1LrJ8_Cvg%40mail.gmail.com.

[Linas Vepstas]

On Thu, Jan 6, 2022 at 7:07 AM Ivan V. <ivan....@gmail.com> wrote:

I'm stuck at the RuleBasedEngine implementation part (it was a Hell of a problem to me just to conceptualize it), but things are developing in the right direction, maybe slowly, but steadily.

Well, you realize that both prolog, and the opencog URE are "rule-based engines"?  (as are STRIPS, drools, and various others)

The URE was originally conceived to replace several other rule engines being used in opencog (thus the "U" -- stands for "Unified"). The "replacing other rule engines" step never happened, as the URE never got an easy-to-use API.

Perhaps I could convince you to look at the URE, and figure out how to layer your idea of a "rule" on top of it?  (There are many ways to write rules, and there are many ways to write rule engines.  The hard part is to make it both generic and also easy-to-use. I believe the URE is generic; I think it's missing the easy-to-use, domain-specific parts to it.)

The opencog "openpsi" subsystem is another rule-based engine. Completely different from the URE. In some ways, its almost more interesting.  The biggest problem it has, though, is that it has a (simplistic) model of human psychology tangled into it; and it really should be untangled.

Then there is a third rule-like system in opencog... I should stop talking. The general lesson is that it's easy to get started walking down the rule-engine path. It's much harder to build something nice, usable, feature-ful, generic. There is a rainbow of design choices. Very few have been explored, none in depth.

I'm interested in this stuff, but what I have to say is .. difficult.

but then I have to return to my main project because I need something more than air to survive.

Ahh. Well. I know that feeling. The problem is, of course, that most activities are mundane. A few minutes of heroic achievement are always surrounded by months of plodding, boring work.

 

And just to be noted, the more I learn about AtomSpace, the more I like it.

Thank you!

There are some things I'd do differently,

Well, you can voice those.  The AtomSpace is not carved in rock.  It's malleable.

but AtomSpace is already here and working well right now, at this moment. Good job.

Again, thanks. My mission is to remind everyone of this.  Starting from scratch, at the beginning, always makes the journey longer. Many hands make the work light.  I'm interested in exploring "what comes next", but, well, I guess there is no general agreement yet on which direction "next" lies in.

The space of ideas is a hyperbolic space: all paths diverge, and the farther you go down some path, the farther away you get from anyone traveling a "parallel" path.  It's hard not to get isolated and lost in such a space.  I dislike being isolated.

--linas

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6W73LrT7JL6KR6q7Q48YLEZdDcT64tfGiv48OwmvmPxYw%40mail.gmail.com.

[Ivan V.]

> Perhaps I could convince you to look at the URE, and figure out how to layer your idea of a "rule" on top of it?

Well, it has begun to be more of a personal matter between me and God. I've been working and experimenting on this cause for more than twenty years now, and although I reinvented the hot water with most of my work, I feel I'll just explode if I don't do it my own way now. Now I'm aware of URE and Prolog, those are good tools, and it would be faster for me to use them, but I also have this little bit different perspective of mine to try to justify my efforts. I simply can't come out of all this trouble with my empty hands. I hope you'll understand it.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA36A_cVzAtYaxVFh0%2BokoJMDuNZ3W8nprLC2u0jaJD110A%40mail.gmail.com.

[Linas Vepstas]

On Thu, Jan 6, 2022 at 12:27 PM Ivan V. <ivan....@gmail.com> wrote:

> Perhaps I could convince you to look at the URE, and figure out how to layer your idea of a "rule" on top of it?

Well, it has begun to be more of a personal matter between me and God. I've been working and experimenting on this cause for more than twenty years now, and although I reinvented the hot water with most of my work, I feel I'll just explode if I don't do it my own way now. Now I'm aware of URE and Prolog, those are good tools, and it would be faster for me to use them, but I also have this little bit different perspective of mine to try to justify my efforts. I simply can't come out of all this trouble with my empty hands. I hope you'll understand it.

Well, you have to do what you have to do.  Smart people who don't get to do what they want to do end up unhappy in life.  I've seen it happen far too often, and this is why success should always be celebrated: it is rare, it is uncommon, and so when it happens, it should be trumpeted.

This conversation is in the context of AGI research. In doing this, what does it mean to come away empty-handed?  Well, in AGI, everyone does. Whatever you build, it won't work. At best, you have an incremental achievement: maybe you've learned something you haven't known before. Maybe you've learned something no one has known before, and successfully communicated it to others.

How about software in general? A long long time ago, I worked on a software system developed by NASA (wow! you might say) It was a combo bug-tracker and project-management-tracker. It was really pretty good, actually. But no one used it, it never became popular, it died in total obscurity, and is forgotten. My work on it (I think I spent months on it) you could say, I left "empty-handed". But then I did learn something, and part of what I learned has influenced the design of the atomspace.  It was educational.

But even this is rare.  Approx 99% of all software ever written dies a lonesome death. The 1% that survives is very lucky. But we who work in software, we are lucky, because we can sometimes build something enduring. Compare this to stage actors in a theatre play: once the show is over, that's it. It lives on only in memory, and in stage-bills. That's it. Compare this to insurance agents, who push around paper all their lives: what do they have to show for their work? Maybe a house that once burned down, now can be rebuilt? Or a nurse, a doctor: they save someone, who can then live a few more years before they die?  Life is transient. We all leave, empty-handed, as it were.

Some few people, more and more these days, have the luxury of deciding what to do to be effective. Funny, but that decision turns out to be a hard problem. I think things work out better when we work together, but ... so it goes.

--linas

[Ivan V.]

Hello all,

CogProtoLab came pretty close to what I expected it to be, plus some extra things that followed suggestions from Linas:

The project link is at: https://github.com/opencog/cogprotolab

These are some of more important changes since the initial commit:

• UX regarding to sending commands / updating visuals is redefined
  
• left-top pane is redesigned to include some utilities we considered helpful
  
• cmd-delay time is removed. Php telnet script now waits for guile> prompt to be read, then returns the output. Interfacing command prompt works faster now.
• some bugs have been eradicated

I'm interested in constructive criticism, usage reviews, suggestions, feature requests, and bug reports.

All best,

- ivan -

[Linas Vepstas]

Quick minor but perhaps irritating note: -- I guess there's a way of attaching to some existing cogserver? And also: the prompt is configurable, so different cogsrever instances will use different prompts. (Sorry!) --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+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6UCYKNykYfOvGqTaENQACU8Hi9Z61wbejK%2BYzEnyWosPg%40mail.gmail.com.