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.
