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. So again, provide me with trees, and I can store/search trees. It's not hard. 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. 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 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 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/CAHrUA36k_9-PeZOvbwJ2Dtx5%2BE4M7pMsg-QF%3DA_BkCJvDCtzGw%40mail.gmail.com.
