Hi Ivan,
Thank you for the invitation to write another essay on symbolic AI. Before
I answer your questions, I'd like to distinguish between 3 or 4 things that
are easily entangled.
First -- there is OpenCog. Roughly speaking, this is meant to be a software
implementation of Ben's vision for AGI, which he has spelled out in
multiple books over the decade(s). I guess the most recent one is
"Engineering General Intelligence", now a few years old.
-- There is PLN, "Probabilistic Logic Networks" -- This is another one of
Ben's creations -- it is a generalization of First Order Logic to a
probabilistic (Bayesian) setting. It's meant to be a mashup of the best of
both worlds.
-- There is the AtomSpace, which is a (hyper-)graph database. ("metagraph"
is another popular term.) Originally envisioned as a "Knowledge Store" for
different kinds of "Knowledge Representations", and for the search and
retrieval of specific bits of "knowledge". (KR S&R), the Atomspace has
evolved to be "as generic as possible", while still having "extremely fast
graph traversal". (i.e. what's connected to what.)
-- There is Atomese, which is a collection of predefined types of Atoms
that "do things". The point of Atomese is to explicitly express
relationships between "things", so that algorithms (i.e. machines, not
people) can access that structure and manipulate it. At the same time,
Atomese is executable, evaluatable. So if a graph can be thought of "a
collection of pipes", Atomese defines "what flows through those pipes." So
Atomese is at the same time a Knowledge Representation Language, and also a
Graph Database, and also a Programming Language. All three rolled into one.
With that intro:
On Sat, Jul 10, 2021 at 11:54 AM Ivan V. <[email protected]> wrote:
> 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)
>
> Well, what do you mean by "theorem prover"? I know three different
variants.
-- First, there is a collection of mathematical research devoted to
understanding "what is a theorem?" "what is a proof?" "How do they work
together?" and "where do algorithms fit in?" This is an inder-disciplinary
line of work, melding together five or six different branches of
mathematics: model theory, proof theory, category theory, type theory,
topology and logic. It has been very fruitful, with some of the finest
mathematicians generating many notable and important results.
-- Second, there are specific efforts to automate some mundane, routine
mathematical tasks. For example, one is to verify the proof for the
classification of groups. This proof was published in the 1950's and
1960's, in many hundreds of journal articles, written by many hundreds of
authors, spanning many thousands of pages. No human has ever understood the
entirety of it -- or even read all of it -- so there may be errors. Thus,
it would be nice to automate this, and have a machine crunch through it,
and make sure it's right. Doing this requires having practical software
that is easy to use and is fast. In some ways, it can be compared to having
a calculator, but instead of a calculator for numbers, it's a calculator
for rings and fields and orders. There are a dozen or more such systems,
ranging from cutting edge research platforms, as in the first bullet above,
to quotidian, practical systems that aspire to little other than being
usable and effective.
-- Third, there are neural nets, which suggest interesting theorems. This
is kind of weird, because it calls into question: "what is an interesting
theorem?" and, more generally, "what is mathematics, anyway?" Humans decide
what is interesting, and it's up to sociologists, psychologists and
philosophers to figure out what that means, to trace the currents of
influence from prof to student, much like fashion styles: dresses, skirts,
short skirts, long skirts, jeans, pant-suits. Short hair, long hair, hats.
Mathematics ebbs and flows like fashion. It's kind of weird when you ask a
neural net to do it for you.
Where might OpenCog, or PLN or Atomese fit in?
-- For me, personally, Atomese is kind of a research platform in the first
sense: I am trying to figure out how to mash up all those different
branches of mathematics, plus also probability, into a flexible, fast,
useful and usable platform for "knowledge representation". I invite
everyone to participate; but it's arcane enough that few are drawn into it.
-- For "practical" theorem proving, one must have a system that is fast ...
well, you might think that PLN could be used for that. There's only one
catch: PLN is designed to work with probabilities, and this makes it (as
currently designed & envisioned) prone to combinatoric explosion, with only
the most basic, remedial algorithms for controlling this ("attention
allocation" or "ECAN" or "openpsi") The probability aspect ruins things
for "theorem proving" -- because there are no probabilities in theorems.
Everything is "crisp logic" -- crisp true/false values. So you can't start
with PLN.
You could start with a brand-new project: take some existing system: for
example, some SAT solver, or some answer-set programming (ASP) solver, or
even something like AGDA or some HOL theorem prover, and figure out how to
wrap Atomese around it. This is doable. It's interesting. It's
worthwhile. And it requires laser-like focus: "why am I doing this?" and
"what's it good for?" have to be the primary #1 questions in the forefront.
Because these guide the actual design. In this sense, yes, one could write
a theorem prover in Atomese, .. as long as you know what it's good for, and
what you hope to accomplish.
-- For theorem discovery ... well, yes, that too. However, we still do not
have an adequate wrapper for neural nets (e.g. tensor flow) in Atomese.
There was an attempt to do this a few years ago, but I feel it went off the
rails, and didn't quite work out. I think the general idea is still valid:
and in terms of importance, it might be one of the most important things we
could do: we need -- we really really really need, a good, solid, strong
whizbang Atomese API into tensorflow and/or other frameworks. I wish
someone would step up and do this.
> - How hard is it to implement a math expression solver in Atomese?
> (wider user base; weaker potential for graph visualization)
>
>
Not sure what you mean. Like a symbolic algebra toolkit? Something that
factorizes polynomials over ideals and rings? Something that estimates
integrals? Say, like the commercial product "Mathematica"? Hmm, I dunno.
So, Wolfram has a proprietary product which generates income which is used
to hire programmers to make it better. By comparison, stuff like GNU Octave
does not have this virtuous capitalistic feedback loop, where users pay
money to make Octave better. Open Source has trouble exploiting simple
profit loops. Open source can only exploit more complex, sophisticated and
fragile financial feedback loops. I suppose professors of finance and
business and economics study how open source makes financial profits, but I
have not seen anything particularly strong. There are assorted anecdotes
for running an open source business, but mostly everyone is still
scrambling to "monetize" their work.
Now if I could only monetize this email. Turn it into a youtube channel.
Nurture it to a thousand subscribers ... ten-thousand subscribers. Have
some embedded advertisements (may I suggest that Wolfram pays me ten cents
for everyone who reads this email? Maybe if I mention McCombs Business
School, they'll send some $$ my way.) Or maybe some in-app purchases. My
bitcoin addr is 1MjcVE8A4sKDqbbxSf8rej9uVPZfuJQHnz or the image below
[image: btc.png]
So there. Step 1 ... Step 5. $$$ Profit!
>
> - 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)
>
> There seem to be a handful of existing systems for this. Things that write
your for-loops and if-blocks for you. It's ... uhhh ... well. ... sure ...
There are aspects of programming that are like ... building websites. You
no longer need to know HTML and CSS, You just need to know how to give your
credit card to GoDaddy, and drag-n-drop your way to a colorful website for
your business. So, sure, there are aspects of programming that will fit in
that mold, and these can be found and refined and turned into a business
... I dunno, automated cell-phone app builders, or automated IoT agents, or
whatever.
But this is ... a business. Something an entrepreneur might try. Its not
part of Ben's OpenCog vision, it's not something PLN can do, and .. sure I
guess you could use the AtomSpace to store the "knowledge" of "how to write
a program", but, to the aspiring entrepreneur, I cannot offer a compelling
use case to choose the AtomSpace over something that the Apache Foundation
might have to offer.
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?
>
Well, I listed three distinct visualization apps.
(1) graph visualization for the AtomSpace, so that beginners can get
comfortable with running the examples and demos.
(2) a sophisticated debug tool for exploring complex hypergraphs/metagraphs
(3) a dashboard/ GUI panel for controlling processing. (In the olden days,
Ben called these "MindAgents".) In practice, it's a bunch of shell scripts
and perl scripts and scheme and python scripts -- all wired together to
create some data processing pipelines. And .. hey! It would be way cool
to represent that pipeline in Atomese! It would be wayyy cool to allow
different providers to provide these scriplets, and when you wire them
together and run them, you could exchange some crypto-token, for doing that
processing -- for the CPU, the RAM, the algo.
So you would have some graphical UI, showing how to wire together different
subsystems with drag-n-drop (it's just Atoms/Atomese! The graph browser of
(1) is enough for this!), and then watch the processing happen, via a
Graphana-type visual interface. And you'd pay each processing provider some
ERC20 tokens (no wait, maybe Cardano is better...) .. This would be
drag-n-drop data-mining heaven. If only there was someone who was
interested in building something like that. I even got a cool name for this
project: we could call it "the Network of Singularities". Or NetSing, for
short. I should bend Ben's ear about this, I think it's a really great
idea! Although I guess it could be hard to make it work.
> 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.
>
Sure, but I'm not clear what a "fractal graph visualizer" is. And as to a
"free structures repo" -- well we already got one -- the AtomSpace -- so
I'm not interested in reinventing that wheel. It's more like .. I want to
use the wheel I got to build a car.
-- Linas
>
> 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 <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%3Dj6WhiAPmHUH4m8s0Q_YS%2BOFARGvZZ7w7zVjOEKj4wyu97g%40mail.gmail.com
> <https://groups.google.com/d/msgid/opencog/CAB5%3Dj6WhiAPmHUH4m8s0Q_YS%2BOFARGvZZ7w7zVjOEKj4wyu97g%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/CAHrUA34LW2y0ef72%3D4c2OGCLS%2BV9%3DFSVPRUupiBZLALDwrGd7g%40mail.gmail.com.
