Port to Atomese API

[linas]

Change request, per discussions with @edyirdaw in pull req #6

Get rid of the RESTful API and port to Atomese. If you don't understand why, let me know, I can explain. If you don't understand how, I can explain that too.

There are three ways to port to Atomese.

• One is to open a connection to the cogserver, and just send whatever scheme you want, and parse the replies. This allows you to do pretty much anything at all. If you open the connection in "quiet" mode, then parsing the results will be easier, as you won't get the extra markup to make it human-readable. This requires you to write a brand-new parser, in js, for Atomese. This would be all-new code, no one has done this before.

• A second option is to do the above, but limit yourself to the StorageNode API. This is almost the same as above, except that it's faster, tailored for good network performance and ... prints no error messages, making it harder to debug. See https://wiki.opencog.org/w/StorageNode half-way down the page.

• Either of the above would be written in js, and, because its generic, should probably be a brand-new js project, so that others can use it (and not just the explorer) I can create a git repo for you, to hold this new code.

• Write a brand-new cogserver plugin to return json. This would replace the RESTful thing. The returned json would need to be designed to fix all the mistakes in the RESTful API. This might be easier to do (??) than the first two options above. The brand-new code would be in C++. I don't really recommend this option, but ... it wouldn't be that bad. The API would be the same StorageNode API, except sending and receiving json instead of s-expressions.

So basically, if you want to write js, pick the first few options; if you want to write C++, pick the last option. I can help with any of these.

[chris-altamimi]

Hello Linas!

We're very interested in helping this with this. Our extensive experience in Javascript / Typescript with both Restful APIs as well as React based UIs should allow us to knock this out easily using option 1 or 2.

@Mforrest20 and I will likely get started on this later this week or early next week.

Edit:

What do you suppose is the better of the two options? I can recognize some of the benefits that one brings over the other such as option 2 having better maintainability and ease-of-development.

However, I would love to know what you would choose if you had the resources to accomplish any of these options?

[mjsduncan]

i'm not linus but i'm eager to use a good graphical interface to the atomspace! one possibility to consider is porting the metagraph rendering code here to this visualizer, which has a good interface (using option 1 i think) but only visualizes the scheme s-expressions.

there's also a guile module to parse json for options 1 & 2

[linas]

Hi Chris!

That would be great! I'm not sure what I need to say to get things moving. Do you want to have a long conversation here in github comments? Or maybe chat ... there's an opencog server in discord, I sort-of-ish glance at it every now and then. The task is "easy" in that I know exactly what to do; it's hard only in that I would have to go over the details, so that you don't end up wasting time & breaking your head on dead-ends.

[linas]

Oh, to answer your question:

I would love to know what you would choose if you had the resources to accomplish any of these options?

I'm neutral. Here are some pros-n-cons:

• Option 3 is to write a cogserver plugin (in C++) to send-receive json. This allows "anyone" intersted in json to use it. I could even volunteer to write the code myself: a day or two to get the basics working, a day or two to polish it up, make it pretty, a day or two to write the docs. My only complaint is that this is about 5 days longer than I can easily spare...
• Option 1 & 2 are "almost identical", require no new C++ code, no effort from me to make anything work. Mostly, I'd have to make sure that you clearly understand what the AtomSpace actually is, so that you know what to do with the returned data. Well, option 3 requires this as well: if you don't understand what the AtomSpace is, then it's ... tough going.

The key concepts are "what is an Atom" "what is a Value" "what is the incoming set" and "what is the outgoing set". Wrap your mind around those, I think you'll be OK ...

[Ontopic]

Would love to have a go at exposing interacting with Atomspace through different web-based interfaces. A basic C++ implementation (Docker would be extra nice) for a JSON send-receive would I feel open up the possibilities of exploring the OpenCog universe to quite a few interested developers to build cool stuff on, not just me.

[chris-altamimi]

I am a fan of the C++ implementation only because we can rely natively on the C++ api rather than having to develop a completely separate parser for the atomspace. I would expect this to be relatively more cumbersome and require extra work to maintain if the atomspace is extended or edited.

However, at the same time, I feel that the JS approach would open things up to UI focused developers since they tend to favor JS/TS ( React, Angular, Vue etc etc ), which I feel could very likely make a much more elegant and user friendly visualizer if they have a javascript API to work with.

On top of this, I think that there would be great benefit to having an Atomese Parser outside of the visualizer such as analytics outside visualization.

@Ontopic are you saying you could likely pull something together in C++ fairly quickly? If this is the case then I don't want to step on any toes, please feel free to take over. As we've just now started to piece together a js approach.

Ultimately, I'd rather approach with the best solution for the community.

[chris-altamimi]

Also,

@linas We will join the discord server, however I think a conversation at this point might be premature and result in wasting your time, which I am keen to avoid, given your noted lack of time to spare.

I truly would like to hear everyone's opinions regarding the best approach.

While I feel I have the expertise to tackle this issue ( heavy experience in both C++ and JS ), I think the experience using OpenCog is invaluable, and thus I am all ears to those with more of it than I.

As soon as we land on a choice, then I feel we would be ready to have a discussion on your requirements, constraints and anything else you wish to share about the matter at hand.

[linas]

I could knock out a basic cogserver plugin (written in c++) in about a day or two, if you're serious about using it and ask me nicely. You would use it by opening a socket to the cogserver, sending any one of about a dozen rather simple JSON snippets, and then getting back a (usually large) answer, in JSON.

I'm offering to do this mostly because its a cut-n-paste of an existing plugin, which changeups for handling json instead of s-expressions. If course, you could do this cut-n-paste job too. It's not hard.

I've failed to look at discord for a few weeks. Ooops! Looking now.

[Ontopic]

My C++ skills are sadly limited, especially in an unfamiliar codebase. I whole heartedly love all OpenCog is doing and would love to use it in an interactive way. I'm sure there's a lot more people that would be able to grasp the concepts of Atomspace when given a proper in browser visualizer / editor (repl) in a modern UI.

If this JSON interface would be here, I'd be building an editor and Atomspace playgrounds right now

[Ontopic]

So, kind sir linas, if you might find yourself in a position with some time to throw at this, and in the mood to do so, I hope you do! Thanks for all your efforts anyhow. Was following the issue in the REST repo, I feel it was a little unfair how you were treated, still, with this out of the way, next time you can say "you can implement the REST yourself, based on the JSON interface" ;)

[linas]

Huh. Well, looking around, it seems that a bare-bones json interface already exists. See the README here: https://github.com/opencog/atomspace/tree/master/opencog/persist/json It's maybe enough to get you started. I will poke around a bit today, and try to add some of the missing features.

More generally, this is all kind of useless, unless you have some specific dataset you want to work with. I can quickly and easily offer two: one is a gene+protein dataset, another is a language dataset. You can run them locally, or I can set up a remote server running these.

[linas]

Added more stuff w/ pull req opencog/atomspace#2952

Notes:

• The API is pseudo-JSON -- if it looks weird or isn't pure-json-enough or is otherwise broken, open a bug report. (or send a pull req)
• There might be bugs. I hand-tested case by case but was too lazy to write unit tests. Yes, skipping unit tests is bad coding practice. Today, I made an exception.

[linas]

I'll give write permission to https://github.com/opencog/atomspace-js to anyone who wants to create javascript wrappers for this thing. ... or anything else.