Hi Amirouche! On Thu, Nov 11, 2021 at 9:41 AM Amirouche Boubekki < [email protected]> 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 <[email protected]> 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. -- 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/CAHrUA340kX4GQXzDQdzcg471EA9D1V%3DoA_ASQ4wD%2BMDL0ZQh2w%40mail.gmail.com.
