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%3Dj6Ww%3DmLqkC4fEjUgO3FyoHbWV5eXsQcKGu_sB4dX8KuMWg%40mail.gmail.com.
