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.
