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.
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... 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 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 paired visualizer windows based on atomspace explorer code 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.
