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.
