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.
