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. <[email protected]
<mailto:[email protected]>> 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. <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> napisao je:
Hi Mike,
On Mon, Jul 5, 2021 at 11:30 AM Michael Duncan
<[email protected] <mailto:[email protected]>> 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 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.
On Sunday, July 4, 2021 at 5:49:58 PM UTC-4
[email protected] <mailto:[email protected]> wrote:
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 <[email protected]> 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/
<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.
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://openchakra.app>,
https://reactstudio.com
<https://reactstudio.com> or https://builderx.io
<https://builderx.io>.
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
On Thu, Jul 1, 2021 at 9:53 AM
Abdulrahman Semrie <[email protected]>
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 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
<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>
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.
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
<https://github.com/MOZI-AI/annotation-service>
and this:
https://github.com/MOZI-AI/annotation-service-ui
<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
[email protected].
To view this discussion on the web
visit
https://groups.google.com/d/msgid/opencog/d16f492c-26f2-4f21-807e-e02cfd8f7c6cn%40googlegroups.com
<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 [email protected].
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
[email protected]
<mailto:[email protected]>.
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
[email protected]
<mailto:[email protected]>.
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 [email protected]
<mailto:[email protected]>.
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>.
