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]> 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 <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/, 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 >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> <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]. >>>> 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]. >>> 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Uyjdc4DLmGwrV%2Bn77Yybv4RR1-9yHUifRAhrbisDnejw%40mail.gmail.com.
