OpenCog Rework [Re: s-expression database]

[Amirouche Boubekki]

> > > > Rocksdb is a serverless, single-system key-value database optimized for SSD disks. It has C bindings, and it's fast. For me, simple and fast are highly desirable properties.
> > > > > > So is wiredtiger https://source.wiredtiger.com/ but GPLv3
> > > > Is wiredtiger actually serverless?
> > It has no network component. It has a notion of table, but that is an optimization. You can use it like rocksdb with a single table, with single key-column and a single value-column.
> > The only drawback is that it is difficult to work with if the dataset does NOT fit in RAM.

Linas replied:

> The AtomSpace wants RAM. Because the AtomSpace is an in-RAM database. So using something else that *also* wants RAM is stupid: it just means that I have to buy a computer with twice as much RAM. I've walked down all of these roads before.

I am not sure I understand: will the new symbol expression database
work along the current AtomSpace?

In any case, whether it is RocksDB, wiredtiger, SQLite, Foundationdb,
or whatever. The decision must not be settled lightly, I was under the
impression they were clear goals and use-cases for opencog, my
recommendation is to extract from those hardware and software
specifications, and quality metrics, then benchmark https://okvs.dev
and dbms.

Be warned that using one or more https://okvs.dev lead to more
economical software framework, hence possibly more profitable (less
bugs, less maintenance cost, easier on-boarding; on a related note,
read [0])

Benchmarking, auditing and evaluating is difficult work, with a very
slow return on investment (ROI) in the short term. The goal of those
is to reduce the risk of making major buggy decisions that are
difficult or impossible to workaround.

Fast-time-to-market is an evil practice. Meanwhile, a good design can
be implemented quickly and can work flawlessly.

> Maybe something like (query ?x (foo bar ?x baz)) to find all lists with four items, three of which as shown and the fourth unknown... would this be an OK API? Have you seen anything like this? any suggestions?

It looks like the symbolic expression database you built looks much
like what I call a 'General Tuple Store' where every object of the
database is a tuple of arbitrary length made of "atoms".

I made up the 'General Tuple Store' three-gram, the literature used to
call it "Tuple Store" or maybe "Tuple Space". I prefer the General
Tuple Store, to differentiate with the nstore aka. Generic Tuple
Store, where tuple length is fixed. A General Tuple Store can be built
on top of a Generic Tuple Store.

Forget about GraphQL [...]. I think something declarative like prolog
or datalog or sparql can work for some audience. It depends on the
app, the niche and what you want to market.

Note: In my experience, given the current state of academic and
industrial practices, most of the time: code is a liability.

[0] https://scribe.rip/@enkiv2/composability-homogeneity-and-language-based-systems-fb00e2c2458

[Linas Vepstas]

On Tue, Nov 9, 2021 at 3:44 AM Amirouche Boubekki
<amirouche...@gmail.com> wrote:
>
> > > > > Rocksdb is a serverless, single-system key-value database optimized for SSD disks. It has C bindings, and it's fast. For me, simple and fast are highly desirable properties.
> > > > > > > So is wiredtiger https://source.wiredtiger.com/ but GPLv3
> > > > > Is wiredtiger actually serverless?
> > > It has no network component. It has a notion of table, but that is an optimization. You can use it like rocksdb with a single table, with single key-column and a single value-column.
> > > The only drawback is that it is difficult to work with if the dataset does NOT fit in RAM.
>
> Linas replied:
>
> > The AtomSpace wants RAM. Because the AtomSpace is an in-RAM database. So using something else that *also* wants RAM is stupid: it just means that I have to buy a computer with twice as much RAM. I've walked down all of these roads before.
>
> I am not sure I understand: will the new symbol expression database
> work along the current AtomSpace?

What "new symbol expression database"? I don't know what you are
referring to here.

> In any case, whether it is RocksDB, wiredtiger, SQLite, Foundationdb,
> or whatever.

I was trying to say something very simple; I'm sorry if I did not say
it clearly. Let me try again:

The AtomSpace is an in-RAM database. When I read about WiredTiger, it
seems to say that it also is an in-RAM database. That means that if I
store something in the AtomSpace, and then use WiredTiger as the
backing store, then, for everything I push out to the backing store,
even more RAM is used up.

Which means I have less RAM available for the AtomSpace. Which is
counter-productive.

I do NOT want to have TWO RAM-hungry systems running, both of them
competing for the same resource.

By contrast, if the backing store to the AtomSpace is a disk drive,
then when I go to save something, I DON'T use more RAM. I just use
some disk. Disk is cheap. That means that most of the RAM in the
system is available to the AtomSpace. Yayy!

> The decision must not be settled lightly,

Why make a decision at all? The AtomSpace currently has five different
storage nodes (file, postgres, rocks, and two cogserver variants)
(actually, seven: two prototypes that work, but were abandoned). You
can use all five at the same time. You can copy atoms from one to
another to your heart's content. You can even do queries across four
of them (the file backend does not support queries)

Add one more storage node for WiredTiger, if that makes you happy.
It's not hard. It's under 2KLOC of code. Closer to 1KLOC, if you don't
count GPL copyright boilerplate and verbose documentation. You could
code this up and test and debug it in about 1-3 days (well, I could.
YMMV) This is simply just not that hard, not worth hand-wringing or
shedding tears over.

> I was under the
> impression they were clear goals and use-cases for opencog,

Sadly, there are not.

> my
> recommendation is to extract from those hardware and software
> specifications, and quality metrics, then benchmark https://okvs.dev
> and dbms.

The link https://okvs.dev just takes me to a wikipedia article. I'm
sure Rocks is an okvs db. It kind of says so.

The benchmarks are at https://github.com/opencog/benchmark These
include a copy of the gene-ontology data from agi-bio, and a copy of
some natural language data.

> > Maybe something like (query ?x (foo bar ?x baz)) to find all lists with four items, three of which as shown and the fourth unknown... would this be an OK API? Have you seen anything like this? any suggestions?
>
> It looks like the symbolic expression database you built

Heh. I didn't build it. Andre Senna and a bunch of Brazillians did,
twenty years ago, under the supervision of mad scientist Ben Goertzel.
All that I did was to work it, make it, do it, harder, faster, better,
stronger, more than before.

Sometimes, it's worth celebrating anniversaries. The AtomSpace is
twenty years old, I believe.

> looks much
> like what I call a 'General Tuple Store' where every object of the
> database is a tuple of arbitrary length made of "atoms".

General s-expression store. Because each element can be another tuple.

General JSON store, because each element can have a name.

General abstract syntax tree store. Because each element stores trees.

General python store. Because python is just syntax trees.

General programming-language-X store, because all programming
languages have syntax trees.

It's general. That's the point.

-- linas

[Amirouche Boubekki]

Disclaimer: I do not want you to think that I want to be rude: please
take time to respond, it seems you misread or read too quickly or
something, what I write. And, please do not hesitate to ask me what I
mean, English is my fourth language (I mix grammar between all the
languages I know), even if that's the one I practice the most
nowadays.

Le mar. 9 nov. 2021 à 18:07, Linas Vepstas <linasv...@gmail.com> a écrit :
>
> On Tue, Nov 9, 2021 at 3:44 AM Amirouche Boubekki
> <amirouche...@gmail.com> wrote:
> >
> > > > > > Rocksdb is a serverless, single-system key-value database optimized for SSD disks. It has C bindings, and it's fast. For me, simple and fast are highly desirable properties.
> > > > > > > > So is wiredtiger https://source.wiredtiger.com/ but GPLv3
> > > > > > Is wiredtiger actually serverless?
> > > > It has no network component. It has a notion of table, but that is an optimization. You can use it like rocksdb with a single table, with single key-column and a single value-column.
> > > > The only drawback is that it is difficult to work with if the dataset does NOT fit in RAM.
> >
> > Linas replied:
> >
> > > The AtomSpace wants RAM. Because the AtomSpace is an in-RAM database. So using something else that *also* wants RAM is stupid: it just means that I have to buy a computer with twice as much RAM. I've walked down all of these roads before.
> >
> > I am not sure I understand: will the new symbol expression database
> > work along the current AtomSpace?
>
> What "new symbol expression database"? I don't know what you are
> referring to here.

I read that symbol-expression is s-expr, I used to call it
scheme-expression, but I think symbol-expression is a better fit.

>
> > In any case, whether it is RocksDB, wiredtiger, SQLite, Foundationdb,
> > or whatever.
>

[...]

>
> I do NOT want to have TWO RAM-hungry systems running, both of them
> competing for the same resource.
>

OpenCog is a very large and difficult project with the goal to build a
software capable of tackling all tasks that only humans can do at this
time, and with the ability to adapt to new tasks, while considering
the 4 laws of robotics [-1].

[-1] https://wikiless.org/wiki/Laws_of_robotics?lang=en#Isaac_Asimov's_%22Three_Laws_of_Robotics%22

I can not find a good narrative about the subject: it seems to me AGI
is much harder than ITER [0][1]. The human-year total investment is
beyond the 100 for ITER, maybe 100,000 if you take into account people
that are not scientists or engineers.

[0] https://www.iter.org/
[1] https://wikiless.org/wiki/ITER?lang=en

We need to assume people have gone mad, and others will become mad
trying to solve the problem of AGI.

OpenCog should take the maximum care when asking or suggest people to
invest their time and energy into this and that. I know, you old
timers have invested more time than me on the subject.

> By contrast, if the backing store to the AtomSpace is a disk drive,
> then when I go to save something, I DON'T use more RAM. I just use
> some disk. Disk is cheap. That means that most of the RAM in the
> system is available to the AtomSpace. Yayy!
>
> > The decision must not be settled lightly,

You cut off the part where I wrote opencog needs to take the time to
review, audit, benchmark existing tools, material [and publications,
and make that in the open].

>
> Why make a decision at all? The AtomSpace currently has five different
> storage nodes (file, postgres, rocks, and two cogserver variants)
> (actually, seven: two prototypes that work, but were abandoned). You
> can use all five at the same time. You can copy atoms from one to
> another to your heart's content. You can even do queries across four
> of them (the file backend does not support queries)

Consider all code is garbage whether it yours, or someone else.

ONE developer with a good attitude, mood, and agency can change a
whole enterprise [2].

[2] https://danluu.com/culture/

>
> Add one more storage node for WiredTiger, if that makes you happy.
> It's not hard. It's under 2KLOC of code. Closer to 1KLOC, if you don't
> count GPL copyright boilerplate and verbose documentation. You could
> code this up and test and debug it in about 1-3 days (well, I could.
> YMMV) This is simply just not that hard, not worth hand-wringing or
> shedding tears over.

The problem is not only about the coding process, it is coding the good thing.

>
> > I was under the
> > impression they were clear goals and use-cases for opencog,
>
> Sadly, there are not.
>

I have a hot take on that. We should narrow the goal for the immediate
future, something like 5 years, and focus on improving the culture
inside OpenCog such as doing things more in the open (e.g. giving more
access to write on the wiki; having more open-access / open-science
litterature), build tools (tools for thoughts, intelligence
augmentation) and curriculums to help with the onboarding new
developers; that will help to reach both end-users, developers, and
money.

> > my
> > recommendation is to extract from those hardware and software
> > specifications, and quality metrics, then benchmark https://okvs.dev
> > and dbms.
>
> The link https://okvs.dev just takes me to a wikipedia article. I'm
> sure Rocks is an okvs db. It kind of says so.

Yes, that is that. And after 10 years of research, I am convinced OKVS
are a VERY good tool.

But rocksdb... it depends...

>
> The benchmarks are at https://github.com/opencog/benchmark These
> include a copy of the gene-ontology data from agi-bio, and a copy of
> some natural language data.

What can I do with that?

> > > Maybe something like (query ?x (foo bar ?x baz)) to find all lists with four items, three of which as shown and the fourth unknown... would this be an OK API? Have you seen anything like this? any suggestions?
> >
> > It looks like the symbolic expression database you built
>
> Heh. I didn't build it. Andre Senna and a bunch of Brazillians did,
> twenty years ago, under the supervision of mad scientist Ben Goertzel.
> All that I did was to work it, make it, do it, harder, faster, better,
> stronger, more than before.

Faster at doing synthetic queries solving no real world problems?

>
> Sometimes, it's worth celebrating anniversaries. The AtomSpace is
> twenty years old, I believe.
>

That is great, but... we are not done yet :)

> > looks much
> > like what I call a 'General Tuple Store' where every object of the
> > database is a tuple of arbitrary length made of "atoms".
>
> General s-expression store. Because each element can be another tuple.
>
> General JSON store, because each element can have a name.
>
> General abstract syntax tree store. Because each element stores trees.
>
> General python store. Because python is just syntax trees.
>
> General programming-language-X store, because all programming
> languages have syntax trees.
>
> It's general. That's the point.

Maybe I am completely missing the point and I just made a fool of
myself. You're laughing at me...

--
Amirouche ~ https://hyper.dev

[Linas Vepstas]

Hi Amirouche!

On Thu, Nov 11, 2021 at 9:41 AM Amirouche Boubekki <amirouche...@gmail.com> wrote:

Disclaimer: I do not want you to think that I want to be rude: please
take time to respond, it seems you misread or read too quickly or
something,

Oh dear, I have to be the one to apologize. I do not think you are being rude! I may indeed have misread! I strive to be clear and direct.

(Offtopic: over the years, I have learned that being "clear and direct" can sometimes evoke disruptive emotional states in the listeners. Sometimes being "clear and direct" makes you an uncaring, entitled asshole (throw in "white" and "male", if you wish). Avoiding this pitfall is difficult: not only do you have to figure out the message that you want to say, you have to *also* try to imagine how the listener will feel, when they read/hear your words. This can be mentally exhausting.  -- From what I can tell, many (most?) engineers, scientists and technical people suffer from this pitfall. They spend 8-12 hours a day focused on technical issues, instead of being focused on the other humans around them. The resulting conversations can be explosive, and the injury to egos can be brutal. Natural language is a minefield of misunderstanding.) 

 

Le mar. 9 nov. 2021 à 18:07, Linas Vepstas <linasv...@gmail.com> a écrit :
>
> > I am not sure I understand: will the new symbol expression database
> > work along the current AtomSpace?
>
> What "new symbol expression database"?  I don't know what you are
> referring to here.

I read that symbol-expression is s-expr, I used to call it
scheme-expression, but I think symbol-expression is a better fit.

OK, there are two or five distinct conversations, ideas I am trying to have.

1) Given everything I've learned about that AtomSpace, and "what it is", it seems that it might be appropriate for the lisp/scheme community to create an "s-expression database". This would make lisp/scheme stronger, and offset some of the loss of mindshare to json (e.g. GraphQL is a "JSON database") or to the RDF/triple-store/"Semantic Web" world. (Cyc was written in lisp. Doug Miles, who is on this mailing list, can tell you more abou Cyc and lisp. And the semantic-web anti-pattern.)

2) I did add an s-expression module to the existing AtomSpace. It took about an afternoon of coding. It works -- you can store arbitrary s-expressions as abstract syntax trees in the atomspace. You can then apply all the other AtomSpace machinery to work with this. There's a demo online.

3) Just like the above, I was going to add  a JSON module to the existing AtomSpace, but I got bored before I finished it. It would take about a day to add. It would allow you to store arbitrary JSON in the AtomSpace, and then  apply all the other AtomSpace machinery to work with this (this being the name-tagged abstract syntax trees, which is what JSON is.)  With this, one could have a competitor to systems such as grakn.ai .. but so what? No existing grakn.ai customer will ever switch to the AtomSpace.  And the likelihood of new users seems infinitesimal. So why bother?

4) Just like 3, but for python. Or Java. Or perl. Or rust. Or Haskell, OCaml, prolog ... its all "abstract syntax trees", in the end. The atomspace is a place to store abstract syntax trees, and to perform queries to find collections of subtrees. Or supersets of trees. Whatever.  It's a generalized abstract syntax-tree store.

5) Ben and his friends are creating a new system called "hyperon". I do not understand what it is, so I cannot comment any further on that.

 

> I do NOT want to have TWO RAM-hungry systems running, both of them
> competing for the same resource.
>

OpenCog is a very large and difficult project

I am not talking about OpenCog. I am talking about the AtomSpace.

with the goal to build a

I am not going to talk about that, in this email, because it is off-topic.

That is a very very different conversation, which is interesting, but unrelated to the idea of the lisp/scheme community creating a nice, clean usable database for s-expressions.

You cut off the part where I wrote opencog needs to take the time to
review, audit, benchmark existing tools, material [and publications,
and make that in the open].

I'm going to cut off this part too.  Why? Because

a) anyone writing new code should do this. This is not advice specific to opencog.

b) It is not relevant to the idea of having the lisp/scheme community create a database for s-expressions.

I have a hot take on that. We should narrow the goal for the immediate
future, something like 5 years, and focus on improving the culture
inside OpenCog such as doing things more in the open (e.g. giving more
access to write on the wiki;

Do you want write access to the wiki? There are 5 or 10 people who can give you that. Whenever we turn on global write permissions, we get spammed with advertisements for sex toys and hair-growth potions. So wiki write permissions are turned off by default.

having more open-access / open-science
litterature),

I am not aware of any work with opencog that is *not* open-access/open-science.  Are you?

build tools (tools for thoughts, intelligence
augmentation)

I do not understand what you are saying. For me "cmake" is a build tool. I don't know what a "tool for thought" or a "tool for intelligence augmentation" is.)

 

and curriculums to help with the onboarding new
developers;

Hmm. From where I sit, we mostly don't need "developers". We need "senior research scientists".  We need people who understand the broad range of AI concepts and optimization algorithms, and also sociology, anthropology, culture, politics, neurobiology, evolution, machine learning, neural nets, category theory, type theory, term rewriting, inference and reasoning, Bayesian learning, and .. certainly a few things I forgot.  Do you know of anyone like that?

I mean, sure, sometimes "ordinary developers" could step in, and fix assorted bugs, or polish up a few modules. But I never go to bed at night thinking "wow, I wish there were more developers on this project."

that will help to reach both end-users, developers, and
money.

There are no end-users, because there is no end-use.  Or rather, the only end-users are the "senior research scientists", of which there is a small handful.

The money ... heh. Well, Douglas reminded me of a forgotten project: LarKC -- the "Large Knowledge Collider" -- they got something like 250M euros in funding. What do they have to show for that money? I dunno. Something, I suppose. Lots of jobs for everyone. Certainly nothing that seems to be relevant or interesting for AGI, as best as I understand it.

 

> The link https://okvs.dev just takes me to a wikipedia article. I'm
> sure Rocks is an okvs db. It kind of says so.

Yes, that is that. And after 10 years of research, I am convinced OKVS
are a VERY good tool.

But rocksdb... it depends...

Leave it alone. Rocks is just another implementation of OKVS.  This is not rocket science or something deep. This is just another shallow optimization algorithm.

> The benchmarks are at https://github.com/opencog/benchmark These
> include a copy of the gene-ontology data from agi-bio, and a copy of
> some natural language data.

What can I do with that?

You can benchmark it.

Maybe I am completely missing the point and I just made a fool of
myself. You're laughing at me...

Here. Watch this video. It explains everything. It's less than 2 minutes long: https://www.youtube.com/watch?v=X9Cd4_BWNxg   (If you wish, the "county line" is the path to AGI -- "King Neptune's Crown" in "Shell City". In a less juvenile setting, this is Joseph Campbell's Hero's Journey. Natural language may be a minefield for us ordinary folks, but is the working medium of playwrights and authors.)

--linas

--

Patrick: Are they laughing at us?

Sponge Bob: No, Patrick, they are laughing next to us.

 

[Douglas Miles]

 

Le mar. 9 nov. 2021 à 18:07, Linas Vepstas <linasv...@gmail.com> a écrit :

OK, there are two or five distinct conversations, ideas I am trying to have.

2) I did add an s-expression module to the existing AtomSpace. It took about an afternoon of coding. It works -- you can store arbitrary s-expressions as abstract syntax trees in the atomspace. You can then apply all the other AtomSpace machinery to work with this. There's a demo online.

Awesome.. would you point out the demo link?

 

3) Just like the above, I was going to add  a JSON module to the existing AtomSpace, but I got bored before I finished it. It would take about a day to add. It would allow you to store arbitrary JSON in the AtomSpace, and then  apply all the other AtomSpace machinery to work with this (this being the name-tagged abstract syntax trees, which is what JSON is.)  With this, one could have a competitor to systems such as grakn.ai .. but so what? No existing grakn.ai customer will ever switch to the AtomSpace.  And the likelihood of new users seems infinitesimal. So why bother?

Is AtomSpace ever (or always?) used to supply a connection between the OpenCog projects as a live KR system?  That is it being a place that could hold their configurations and bootstrap data and share their deductions for runtime? (Such as the world state of simulation.)

[Linas Vepstas]

On Fri, Nov 12, 2021 at 9:07 PM Douglas Miles <logi...@gmail.com> wrote:

 

Le mar. 9 nov. 2021 à 18:07, Linas Vepstas <linasv...@gmail.com> a écrit :

OK, there are two or five distinct conversations, ideas I am trying to have.

2) I did add an s-expression module to the existing AtomSpace. It took about an afternoon of coding. It works -- you can store arbitrary s-expressions as abstract syntax trees in the atomspace. You can then apply all the other AtomSpace machinery to work with this. There's a demo online.

Awesome.. would you point out the demo link?

It's here:

 https://github.com/opencog/atomspace/blob/master/examples/foreign/sexpr-query.scm

Caution: its "raw Atomese" -- if you ever wanted to use this, you would want to write conveience wrappers around it to make it easier to use.

 

3) Just like the above, I was going to add  a JSON module to the existing AtomSpace, but I got bored before I finished it. It would take about a day to add. It would allow you to store arbitrary JSON in the AtomSpace, and then  apply all the other AtomSpace machinery to work with this (this being the name-tagged abstract syntax trees, which is what JSON is.)  With this, one could have a competitor to systems such as grakn.ai .. but so what? No existing grakn.ai customer will ever switch to the AtomSpace.  And the likelihood of new users seems infinitesimal. So why bother?

Is AtomSpace ever (or always?) used to supply a connection between the OpenCog projects as a live KR system?  That is it being a place that could hold their configurations and bootstrap data and share their deductions for runtime? (Such as the world state of simulation.)

Since the dawn of time. That is it's reason for being.

It was created in 2001 or 2002 in Brazil, for this purpose, with a mad scramble at that time w.r.t the tamaguchi craze. As I recall, Disney paid $250M for some animated avatar penguin or something. There are some opencog youtube videos from circa 2009  that show an animated dog that you can talk to. https://www.youtube.com/watch?v=FEmpGRLwbqE  and https://www.youtube.com/watch?v=vZtnjKcrdZQ and https://www.youtube.com/watch?v=ii-qdubNsx0  Those all use atomspace under the covers. You can even dig out the code for that out of github.  It's all there.

Since then... heck. It was used in some of the Hanson Robotics Sophia demos.   It was used to datamine genes encoding longevity. I think you were the person who typed in "the cat sat on the mat" to the IRC chatbot circa 2011 or 2012 -- that ran on the atomspace. The atomspace is the part that "remembers" the earlier conversation, and provides all the background facts.

I'm doing language learning on it now -- millions of atoms in it.  Circa 2018, Ben's russsian's hooked up tensorflow to it.  Everything that the URE and PLN do is on the atomspace. The agi-bio code, where the genetics work gets done, is all on the atomspace -- millions of genes and proteins.

So, yes, its the core component. I don't think that there is anything at all in the opencog code base that does not use it directly.

 

--linas

[Ben Goertzel]

> So, yes, its the core component. I don't think that there is anything at all in the opencog code base that does not use it directly.
>
> --linas

Well.. classic MOSES, right? But now there's Atomspace-MOSES ;)

[Douglas Miles]

On Fri, Nov 12, 2021 at 9:03 PM Linas Vepstas <linasv...@gmail.com> wrote:

On Fri, Nov 12, 2021 at 9:07 PM Douglas Miles <logi...@gmail.com> wrote:

Is AtomSpace ever (or always?) used to supply a connection between the OpenCog projects as a live KR system?  That is it being a place that could hold their configurations and bootstrap data and share their deductions for runtime? (Such as the world state of simulation.)

Since the dawn of time. That is it's reason for being.

Those all use atomspace under the covers. You can even dig out the code for that out of github.  It's all there.

 The atomspace is the part that "remembers" the earlier conversation, and provides all the background facts.

I'm doing language learning on it now -- millions of atoms in it.  Circa 2018, Ben's russsian's hooked up tensorflow to it.  Everything that the URE and PLN do is on the atomspace. The agi-bio code, where the genetics work gets done, is all on the atomspace -- millions of genes and proteins.

Sorry, the question was not whether or not AtomSpace is used for each project independently.  (thank you for the detailed answer though)  It was meant to ask if multiple projects use AtomSpace as a blackboard in order to interoperate. 

[Ben Goertzel]

> Sorry, the question was not whether or not AtomSpace is used for each project independently. (thank you for the detailed answer though) It was meant to ask if multiple projects use AtomSpace as a blackboard in order to interoperate.

They don't at the moment, in practice.

For this to work, one would need a common ontology across the multiple
projects. The ontology implicit in the built-in set of Atom types is
generally too low-level to admit practical unification of multiple
applied Atomspace projects.

In our AI-DSL project at SNet (which does not use Atomspace at
present, but probably will in future when we shift it from Idris2 to
MeTTa as a base language), we are using SUMO as a base ontology for a
similar purpose

One would then need to e.g. map the ontology used in the current
OpenCog Bio-Atomspace into SUMO (which would not be so hard)

I have been discussing w/ Josef Urban (who is collaborating with Adam
Pease the SUMO dude) some projects using neural models to
automatically map NLP expressions into SUMO interpretations. This
would be a narrow AI project obviously not AGI, but could be useful as
a tool supporting some sorts of AGI dev...

-- Ben

[Douglas Miles]

On Sat, Nov 13, 2021 at 12:14 AM Ben Goertzel <bengo...@gmail.com> wrote:

> Sorry, the question was not whether or not AtomSpace is used for each project independently.  (thank you for the detailed answer though)  It was meant to ask if multiple projects use AtomSpace as a blackboard in order to interoperate.


They don't at the moment, in practice.

For this to work, one would need a common ontology across the multiple
projects.   The ontology implicit in the built-in set of Atom types is
generally too low-level to admit practical unification of multiple
applied Atomspace projects.

In our AI-DSL project at SNet (which does not use Atomspace at
present, but probably will in future when we shift it from Idris2 to
MeTTa as a base language), we are using SUMO as a base ontology for a
similar purpose

One would then need to e.g. map the ontology used in the current
OpenCog Bio-Atomspace into SUMO (which would not be so hard)

I have been discussing w/ Josef Urban (who is collaborating with Adam
Pease the SUMO dude) some projects using neural models to
automatically map NLP expressions into SUMO interpretations.   

Nifty, Adam in 1999 employed me for a couple year to write the first SUMO theorem prover which can be found here:  https://github.com/logicmoo/sigma_ace/tree/master/engine (later on it was replaced by Vampire-KIF) 

I use SUMO+CycL  as the output of my NLP code as well

 (can see the output here) 

https://docs.google.com/document/d/1IELBApotKwFxTvsUsEgU5nPqofuHVsyuDzxTBw4ca_A/edit

 

This
would be a narrow AI project obviously not AGI, but could be useful as
a tool supporting some sorts of AGI dev...

I see nothing wrong with that idea, in fact I am using my NLU->SUMO translator to help produce narrative stories to provide the initial content for a virtual world in which an AGI can train in.   Also since my world is maintained as a SUMO/CycL KB  and my translator works both ways (English->Sumo and Sumo->English) It makes for making the world and rules that make it up easier to debug. 

 

-- Ben

--
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 opencog+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBeuyYE0YFQ5e%2B-rsmwe2r%3Da18pe0uJTgvv-wKUT7Qo3Sw%40mail.gmail.com.