Doug, can you point me to documentation on the ALEPH-like inductive reasoner you mention?
thx ben On Mon, Nov 8, 2021 at 6:16 PM Douglas Miles <[email protected]> wrote: > > > > On Mon, Nov 8, 2021 at 10:02 AM Linas Vepstas <[email protected]> wrote: >> >> Hi Douglas, >> >> Interesting email... >> >> On Mon, Nov 8, 2021 at 12:14 AM Douglas Miles <[email protected]> wrote: >> > >> > >> > guile-log would be an ideal system as it supports overloaded unification >> > (overloaded from scheme) >> > >> > It would be nice to allow Prolog programs to be ran and maintained as >> > Atomeese and vice versa >> >> I can suggest several solutions, and can even offer to write some of the >> code. >> >> As of very recently, you can now store arbitrary s-expressions in the >> atomspace. These are stored in such a way that they are searchable. So >> you can write "(junk stunk)" and "(stuff stunk)" and then ask "find >> all s-expressions with 'stunk' at the end of them". (or any other >> query). >> >> So, if you can convert prolog to s-expressions, they can be stored. >> >> Another possibility is that I can store prolog "natively". Or any >> language, for that matter: python, perl, java, javascript ... just >> provide me with a parser (written in C/C++) that will convert that >> language into an abstract syntax tree, and I can store that tree. The >> query engine can then query such trees. >> >> I was going to do one for JSON but got immediately bored. Storing it >> in the atomspace is easy, but so what? The only "interesting" part >> would be to write a query language, but that exists already: >> "GraphQL", and so I could port graphQL to sit on top of the pattern >> engine, but so what? Who cares? >> No one would use such a thing. It seemed pointless. > > > I often realize too late the amount of utility such things provides on paper > sounded good.. but as soon as I have it I ask "now what?" ( Just because > people can query my system in their format of choice does not mean that they > will want to ) > >> >> So again, provide me with trees, and I can store/search trees. It's >> not hard. > > > In prolog, when i want to be searching trees I organize my trees into graph > nodes (a predicate per arc) and search that way. That tree structure > usually stored in a prolog hashmap or other structure.. but I have do do a > small conversion to predicate arcs first to make search efficient. > > >> >> The "hard part" is inventing a query language that users >> would want to use. The raw, low-level pattern matcher language is >> powerful but verbose and intimidating to new users. Some >> domain-specific language would be more socially appealing. > > > In my case the reason I produce the "efficient [at least to prolog] > structure" is for my program to be able to search and use the tree. It > would be hard to make it socially appealing as you say something else is > going to be better. > > >> >> >> Hmm. But that is not what you wrote. You wrote >> >> > It would be nice to allow Prolog programs to be ran and maintained as >> > Atomeese and vice versa >> >> and that is kind-of harder. One possibility is that prolog programs >> could be converted into URE rules, but the URE was designed for >> probabilistic inference, and so would run slowly for crisp-logic >> prolog. > > > I'll try to restate the problem I think you are pointing out: Normally > lightning fast prolog programs are fast because they are leveraging > crisp-logic but will run slower because they would now have to compute > probability at each step? > > > Now separately my usecase: > > > I have 3 prolog programs that I was considering trying to convert to > URE/Atomeese: > > > One is the ALEPH-like (an inductive reasoner) that computes/guesses new rules > that recreates the data observed (high-level sensory data or whatever) > called LPS-ALEPH > > And the other is one that creates an imaginary playable world .. (to get a > understanding, here are some rules it uses > https://github.com/logicmoo/prologmud/blob/master/prolog/prologmud/vworld/world_2d.pfc.pl#L210-L241 > ) PrologMUD > > With the combination of the two programs I am working on a system that allows > the ALEPH-like program to observe the Prolog Virtual World (Hand coded in > rules) and have it create a 3rd program in Prolog/Atomeese Virtual World > called NomicMU. So LPS-ALEPH's goal is to create an inductive copy > PrologMUD program into NomicMU and continue to make additions and edits. > > What I am imagining is making my system more socially acceptable to > OpenCogers by having these (three) programs exist and run as Atomeese instead > of prolog. > > >> >> I have a partial fix for that: I think I can make a "simple" >> fast forward-chainer on the pattern engine; this would fit prolog much >> better. > > > > > > > >> >> >> This demo: >> https://github.com/opencog/atomspace/blob/master/examples/pattern-matcher/recursive.scm >> shows how to do recursive queries, and so prolog would be a >> fleshed-out version of that demo. >> >> To convert (a subset) of atomese into prolog is "easy": just write >> some code that takes atomese trees, and prints them as prolog. Of >> course, you can't convert everything; prolog isn't powerful enough. >> >> -- Linas >> >> > >> > - Douglas >> > >> > >> > On Sunday, August 29, 2021 at 2:51:19 PM UTC-7 linas wrote: >> >> >> >> Hi Anatoly, >> >> >> >> I think it would be interesting (useful?) to write dynamic, run-time >> >> shims between the AtomSpace and prolog (or other systems). The user >> >> would write a small shim or conversion template, for example, something >> >> like >> >> >> >> :- x(y,z); <<==>> (Evaluation (Predicate X) (List (Concept Y)(Concept >> >> Z))) >> >> >> >> or whatever mapping the user wants, and then every time prolog needs this >> >> info, it could fish it out of the atomspace, and vice-versa: whenever >> >> prolog generates output, it would automatically be written into the >> >> atomspace. >> >> >> >> I haven't really thought about this for prolog, but I did think about >> >> this for external data stores. Currently, the only way to get data into >> >> the atomspace is a giant batch import, and this can take an hour or two >> >> to run (e.g. the agi-bio dataset). It would be nicer to do this "on >> >> demand", "as needed". Output is likewise: instead of one big dump, just >> >> update the remote dataset bit by bit. >> >> >> >> I thought about this a little bit, and I think it's doable and not that >> >> hard. I don't have any incentive to work on this, just right now. >> >> >> >> On Tue, Aug 24, 2021 at 2:53 AM Anatoly Belikov <[email protected]> wrote: >> >>> >> >>> >> >>> >> >>> you can write something like that: >> >>> ?- assert(likes('Bob', exploration('space', ('rockets'; 'solarsails')))). >> >>> true. >> >>> >> >>> It almost works, but I can't make prolog to return all the solutions: >> >>> ?- likes('Bob', exploration('space', X)). >> >>> X = (rockets;solarsails). >> >>> >> >>> ср, 18 авг. 2021 г. в 21:02, Linas Vepstas <[email protected]>: >> >>>> >> >>>> >> >>>> >> >>>> On Wed, Aug 18, 2021 at 5:32 AM Anatoly Belikov <[email protected]> >> >>>> wrote: >> >>>>> >> >>>>> What do you mean by Prolog not allowing trees? >> >>>> >> >>>> >> >>>> You can write >> >>>> :- likes (Bob, baseball); >> >>>> >> >>>> but you cannot write >> >>>> :- likes (Bob, :- exploration (space, :- or(rockets, solarsails))) >> >>>> >> >>>> The second example is a 3-level deep binary tree ... but is not valid >> >>>> prolog. Of course, you can convert it into valid prolog, but then it is >> >>>> no longer a single, deep tree, it would have to be three shallow trees. >> >>>> >> >>>> The game being played here is "how do you represent knowledge?" and >> >>>> there's a whole rainbow of choices: trees and graphs and directed >> >>>> graphs or undirected graphs or hypergraphs, .. or RDF or "semantic >> >>>> triples" or datalog or json or tables, or whatever. And any one of >> >>>> these systems is really enough for "anything" - you can represent >> >>>> knowledge with any of these systems. >> >>>> >> >>>> The real questions become: How easy is it to use? For example, you can >> >>>> represent "the green ball is under the couch" with "semantic triples" >> >>>> but it becomes hard and verbose. Another example: you can represent a >> >>>> hypergraph with just ordinary graphs, but how much extra RAM and CPU >> >>>> does that need? If CPU and RAM were free, if it weren't for these >> >>>> kinds of concerns, we could just layer datalog on top of Apache >> >>>> tinkerpop and use graphQL and declare victory. >> >>>> >> >>>> --linas >> >>>> >> >>>>> >> >>>>> ср, 18 авг. 2021 г. в 02:40, Linas Vepstas <[email protected]>: >> >>>>>> >> >>>>>> I spent the last week trying to convince a group of scheme >> >>>>>> enthusiasts to build a "database for s-expressions", which, after all >> >>>>>> is said and done, is all that the Atomspace is. This idea went over >> >>>>>> like a lead balloon. >> >>>>>> >> >>>>>> The primary stumbling block seems to be conceptual. People can >> >>>>>> visualize a database of rows and columns -- basically SQL -- very >> >>>>>> conventional. They can visualize a database of key-value pairs -- >> >>>>>> basically, noSQL. Also very popular. The idea of a JSON database is >> >>>>>> now common enough. JSON is, after all, a nested, hierarchical >> >>>>>> key-value store, having the form {name1:value1, name2:value2, ...} -- >> >>>>>> you can think of name1, name2, .. as being like column labels, and >> >>>>>> (value1, value2, ...) as being rows. The biggest difference between >> >>>>>> tables and JSON is that tables are fixed-width, with fixed column >> >>>>>> labels, while JSON is free-form: every JSON expression carries it's >> >>>>>> own labels. And, since it's hierarchical, each value can be another >> >>>>>> JSON expression, nesting arbitrarily deep. It's a labelled tree. >> >>>>>> >> >>>>>> When I suggested that one can store just plain s-expressions -- i.e. >> >>>>>> just (value1, value2, ...) without the labels ... an unlabeled tree >> >>>>>> ... this seemed to make people's heads explode. So my efforts, it >> >>>>>> seems, were for naught. Perhaps I planted a seed, though. >> >>>>>> >> >>>>>> The goal of a generic, agnostic database of s-expressions is to >> >>>>>> overcome the marketing problem the AtomSpace has. If some other >> >>>>>> organization could explain to the world what that is, and provide >> >>>>>> agnostic, generic API's, I think that would be a good thing. However, >> >>>>>> based on the cold reception I got, I'm thinking it may take another >> >>>>>> 10 years before the idea catches on. >> >>>>>> >> >>>>>> (The reception I got was "why don't you use JSON?" so I had to >> >>>>>> explain the problem with the labels. Once that was clear, the next >> >>>>>> suggestion was "why don't you use Prolog/Datalog?" I tried to explain >> >>>>>> how prolog is limited to crisp true/false values, and how prolog does >> >>>>>> not allow trees - it's not hierarchical the way s-expressions and >> >>>>>> JSON are - but this argument did not seem to gain traction. Somehow, >> >>>>>> just saying "it's a database of s-expressions" is not enough to >> >>>>>> convey the idea. People stumble on this. And yet, that's all that it >> >>>>>> is...) >> >>>>>> >> >>>>>> I'm saying this out loud, right here, right now, because if you are >> >>>>>> reading this, and you are thinking to yourself "I never quite >> >>>>>> understood what the atomspace is" -- well, it's that. It's a database >> >>>>>> of s-expressions. It's difficult to take the next step, until this >> >>>>>> first basic idea becomes clear. I want this first, basic idea to >> >>>>>> become clear to everyone. >> >>>>>> >> >>>>>> As to Hyperon -- Ben, I skimmed through everything written on >> >>>>>> Hyperon, and it seems (to me) like it could be "easily" implemented >> >>>>>> within the existing AtomSpace framework. I think this would be the >> >>>>>> right direction to move in, but I don't think that is possible until >> >>>>>> there is some sort of shared understanding about how things work, >> >>>>>> about how things could work, about what needs to be done. Reaching >> >>>>>> that shared understanding may require real work and hard thinking -- >> >>>>>> there's no magic wand of sudden enlightenment -- but its doable. And >> >>>>>> it can be done with, ahhh talking and email. I very strongly >> >>>>>> encourage discussion. Let the sun shine in. >> >>>>>> >> >>>>>> -- Linas >> >>>>>> >> >>>>>> On Tue, Aug 17, 2021 at 3:24 PM Ben Goertzel <[email protected]> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> https://wiki.opencog.org/w/Hyperon >> >>>>>>> >> >>>>>>> On Tue, Aug 17, 2021 at 1:39 AM Amirouche Boubekki >> >>>>>>> <[email protected]> wrote: >> >>>>>>> > >> >>>>>>> > Is there a page that gathers all the publications regarding the >> >>>>>>> > new design ? >> >>>>>>> > >> >>>>>>> > -- >> >>>>>>> > 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/CAL7_Mo_7ihMrRCZY%2BCLwAZ5KcHGqbRqwQgpOb8pLz1qY9Rj%2BSw%40mail.gmail.com. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Ben Goertzel, PhD >> >>>>>>> http://goertzel.org >> >>>>>>> >> >>>>>>> “He not busy being born is busy dying" -- Bob Dylan >> >>>>>>> >> >>>>>>> -- >> >>>>>>> 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/CACYTDBf8jVx8pxaiwvmvkf0ACJgqGQeF6X8s3E%3D%3DdXhr2sPCvA%40mail.gmail.com. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> 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/CAHrUA34_UMZf-3t0giA7TZVQmXs%3DO2-aHB3sn5FC0o-6YBdzCg%40mail.gmail.com. >> >>>>> >> >>>>> -- >> >>>>> 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/CAFj%2Bw-sueAkJQaU1C0Ef4t60FrtFG3A%3DWQk-z%2BjSM56PQzE%3Dvw%40mail.gmail.com. >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> 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/CAHrUA37UtA8YZ4qrvFSYdkBSPEVZeUZP5wbyyqS8oA-3UZ4VJw%40mail.gmail.com. >> >>> >> >>> -- >> >>> 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/CAFj%2Bw-uc3Mnt1zFDwosk11AoM%2B%2BjkJsp_U-dtcEdHaxVR%3DtgUw%40mail.gmail.com. >> >> >> >> >> >> >> >> -- >> >> 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/df24d2f4-ba28-44e9-975f-5ca09edc44a8n%40googlegroups.com. >> >> >> >> -- >> 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 a topic in the >> Google Groups "opencog" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/opencog/xQbA8_6Wg5w/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/opencog/CAHrUA36k_9-PeZOvbwJ2Dtx5%2BE4M7pMsg-QF%3DA_BkCJvDCtzGw%40mail.gmail.com. > > -- > 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/CAER3M5mT0a6ni8eLPT9StSETOaB%2BpOgPDAx9jTgt6ELPHgFkJw%40mail.gmail.com. -- Ben Goertzel, PhD [email protected] "My humanity is a constant self-overcoming" -- Friedrich Nietzsche -- 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/CACYTDBcj_bW_t80KCC88iBGu%3DFPUo10Eg%2B%2BAKs%2BO-f7L8W3TBQ%40mail.gmail.com.
