Hi, Good to hear from you ... On Thu, Jul 1, 2021 at 11: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 python API is not "old" ... it's still there, it still works, it's still "official". Nothing's changed. If you mean the REST API, that was deprecated in 2015, which apparently didn't actually stop people from using it. That's unfortunate, since ... well ... here we are, trying to figure out how to clean up after it. I would like to understand why these accidents keep happening, or rather, figure out how to avoid them. It's some kind of procedural or organizational or communications problem. It feels like (to me) we waste a lot of effort creating unusable, unsupportable code. 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. > Huh. Well, I don't know what that is, or what it looks like, so I can't comment. > > 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. > I don't understand what you are trying to say here... If you remember. this is before you implemented the copy-on-write > functionality. > I don't actually remember that. I do recall that we had several conversations on usability and requirements for multiple AtomSpaces.... those kinds of requirements are very important, actually, since they make clear what it is that people are trying to do, and making the atomspace easy-to-use and flexible is an important strategic goal. If you (or anyone else) has more requirements, problems/issues driven by real-world use, please open github issues (and or email discussions) Again, this stuff is important. I'm eager to solve those kinds of problems, ... 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. > I don't know what "it" is. I think I did try to discourage you from writing the gRPC server, but hey, sometimes the best way of learning is by doing. There are often multiple ways of solving a problem. I did make some general comments about "what's wrong with grpc" on this page: https://wiki.opencog.org/w/Networked_AtomSpaces -- your design might be able to evade some of the criticisms there; I don't know. It's a very slippery surface. Many others before you have tried to walk it, and have fallen off. It can be done, just it's not easy. 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. > Wow! That's actually very pretty! It could be interesting, if it's easy to use. So, for example, I run batch jobs, or "experiments", which are sequences of shell scripts, and they print out to the screen some progress stats ... If I could get live progress stats for each job/experiment, that would be very interesting. I imagine MOZI has something similar: I know you have jobs that run for hours, it would be nice to get a separate grafana display for each job, to see how it's progressing. > 3) For the visualization, in addition to the visualizer in > https://github.com/opencog/external-tools/, > That vizualizer has been moved to https://github.com/opencog/atomspace-visualizer -- I split it out last week, it should never have gone into external tools in the first place... The problem is, of course, is that ... it uses the obsolete REST API, which means .. it doesn't work, except for the demos. It's badly bit-rotted, and it's not clear who can fix it. ... we developed our own custom Cytospace visualizer that visualized atoms > representing biochemical entities using custom layouts. > Yeah, I fiddled with cytoscape too. It has lots of confusing menus; it would be cool if we could somehow disable most of them. I exported atomspace data to "gml" -- https://en.wikipedia.org/wiki/Graph_Modelling_Language -- which is an underwhelming format, .. something nicer/better would be nice, but I couldn't find anything. This is the visualizer used in the annotation service you linked above. > I don't know what an "annotation service" is -- this is a term that you use a lot in the MOZI code base, but if I type in the phrase "annotation service" into google or duckduckgo, I get assorted random junk ... I never figured out what that is supposed to be.. 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. > OK, this is a conversation I've been having for more than a decade. I'd like to tell you about BindLink. It is a link that returns a limited amount of Atoms. You only graph those. Because, yes, of course, if you have a million Atoms, you can't graph all of them at the same time. Besides, it makes no sense to graph all of them. I mean, it's like saying "I want to read the assembly code for firefox, and vim won't let me do that" Which brings me to the next point: you almost never want to graph Atoms directly. You want to graph "what they mean". So a graph of (Evaluation (Predicate "eat") (List (Concept "Ben") (Concept "pizza"))) should not be this complicated five-atom graph, it should be two labelled vertexes and a labelled edge. That is what should be graphed. And this is exactly the problem that BindLink solves! Oh hey! 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. > Could I make a request? Can you write a plain-English intro to the README? Like, what the heck is Sugiyama Layout? What's MLL? Why should I care? And again, what's an "annotation service"? I clicked through enough of the links to think "gee this is interesting", but not enough to think "oh hey, I could make good use of this". The bridge between "interesting" and "directly useful" is a very important bridge to build. > > 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. > Sigh. I don't know where to begin. I'm looking for the shortest path, the easiest path, something that is both "interesting" to everyone on this mailing list, and "directly useful" to as many as we can find. I mean -- there are people lurking in the wood-work. Look at Doug Miles collection of screenshots. Surely we can have something .. better than that. --linas > 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> > . > -- 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/CAHrUA37D-ikj4DU%2B_aehXWKcuX5CnuWCn4b3Nc%3Dswd5ht%3DN5ww%40mail.gmail.com.
