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

sri, 22. ruj 2021. u 17:31 Linas Vepstas <[email protected]> napisao
je:

> On Tue, Sep 21, 2021 at 11:26 PM Ivan V. <[email protected]> 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
>
>
> >
> > - ivan -
> >
> > uto, 21. ruj 2021. u 22:07 Linas Vepstas <[email protected]>
> napisao je:
> >>
> >> Hi,
> >>
> >> On Tue, Sep 21, 2021 at 5:00 AM Ivan V. <[email protected]> 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
> >>
> >> >
> >> > All best,
> >> > Ivan
> >> >
> >> > sub, 10. srp 2021. u 18:53 Ivan V. <[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]> 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]>
> napisao je:
> >> >>>>
> >> >>>> Hi Mike,
> >> >>>>
> >> >>>> On Mon, Jul 5, 2021 at 11:30 AM Michael Duncan <
> [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]
> 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/ 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://reactstudio.com or
> 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 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.
> >> >>>>>>>>>>
> >> >>>>>>>>>> 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 [email protected].
> >> >>>>>>>>>> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/d16f492c-26f2-4f21-807e-e02cfd8f7c6cn%40googlegroups.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 [email protected].
> >> >>>>>>>>>
> >> >>>>>>>>> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/CAPPXERrWx4%2B59Kf163pAnmyaOD%2B5bbQ0pSJ89vFbE50CPrSLNw%40mail.gmail.com
> .
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>> --
> >> >>>>>>>> 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/b750b969-6cb6-4303-b986-7e963e0d90bfn%40googlegroups.com
> .
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> 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/CAHrUA35tErzxe%3D%2Bj2hObh36d__4Ghmi_u7b9cJ3LuK8PD%3DeXsQ%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 [email protected].
> >> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Uyjdc4DLmGwrV%2Bn77Yybv4RR1-9yHUifRAhrbisDnejw%40mail.gmail.com
> .
> >>
> >>
> >>
> >> --
> >> 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/CAHrUA37CeXb842bPi2QP6W9f%2B41PWLZQvi9gKJqmD3-vOUeBoQ%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 [email protected].
> > 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
> .
>
>
>
> --
> 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/CAHrUA36jr9g2pWav5sSCJsBi-aXC1PNi19SeKyGOMoRiBk0vwQ%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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/CAB5%3Dj6VMb-ZBUovRaYau5SYQwOO8NyQawoYAvT-sKtfXB1FspA%40mail.gmail.com.

Reply via email to