Shoot, I hit "send" too soon. Hi Adrian,
On Tue, Dec 7, 2021 at 7:50 PM Linas Vepstas <[email protected]> wrote: > > > On Tue, Dec 7, 2021 at 6:50 PM 'Adrian Borucki' via opencog < > [email protected]> wrote: > >> >> >> wtorek, 7 grudnia 2021 o 23:27:38 UTC+1 linas napisał(a): >> >>> >>> >>> On Sat, Dec 4, 2021 at 9:49 AM Ely Matos <[email protected]> wrote: >>> >>> >>> To be more specific about my doubts: >>>> >>>> - If I have a logic expression like >>>> >>>> give (a b c) >>>> >>>> representing “a gives b to c”, I want to set a type for ‘variables’ >>>> “a”, “b” and “c” – handling “give” as a seed and the variables as >>>> ‘connectors’. >>>> >>> Bingo! >>> >>>> Some another atom “x” would be of “type a” – in the sense “x” would be >>>> a seed with a connector compatible to “a”. In the generation process, “x” >>>> (possibly) would be attached to “give” (using the “a” connector”). So any >>>> knowledge relative to “a” would be indirectly available to “x” via graph >>>> links. >>>> >>> Yes! >>> >> >> So let me see if I understand correctly — what this essentially means is >> that variable unification from above is represented by having these typed >> variable-connectors that later attach to values (atoms) of appropriate >> type, right? >> > > Err, no not really. The word "unification" has a narrow technical sense, > described here: > https://en.wikipedia.org/wiki/Unification_(computer_science) which is a > very lengthly article, so here is a a shorter blog: > https://eli.thegreenplace.net/2018/unification/ > > The concept of connecting connectors is unrelated, and much simpler: > either they connect, or they do not, and connectivity is determined by some > very simple, almost trivial rules. The simplest rule is "any connector > connects to any other". The second simplest is "a connector will connect > only to other connectors having the same name." > > After that comes ideas like "a connector will connect to another if it has > the same name and also it has the opposite polarity". This is the variant > that link grammar uses. (Actually LG uses something just slightly more > complicated, but its effectively just this, in the end.) > The two polarities that LG ises are called "+" and "-" and stand for "to the left" and "to the right". The two polarities that the programming world (and electronics world) generally uses are called "input" and "output" -- you can only connect an input to an output, and never-ever two inputs or two outputs. Furthermore, the types have to match: you cannot connect a string input to a floating-point output (or a usb cable into the house wiring.) (you'd need a converter, in either case, taking the right kind of input and output). I'm guessing that the language of talking about "functions" and "variables" and "inputs" and "outputs" is what made you think of unification. However, in general, the concept of "connectors" does not include any concept of "variables", nor of "functions". You can build variables and functions out of connectors, but not vice-versa. (well, maybe you can, its a bit like arguing about what atoms are made out of; this is the "atomic physics" of computing. There are lots of deep subtleties involving category theory that start showing up here.) > The goal of the https://github.com/opencog/geneate code was to allow the > user to define "arbitrary" connection rules, but in keeping with the > general idea that connector types are type-theoretical types. > > Perhaps it is possible to define connection rules that perform > unification, but I've never thought about that before. > > --linas > > >> In term of “parsing” (it is my real intent) I want – for example - to >>>> uncover some words like in some cases of metonym: >>>> >>>> - John opens the beer. >>>> >>>> - Actually “John opens (the bottle of) the beer. >>>> >>>> This is handling using GLT (Generative Lexicon Theory). In this example >>>> “open” has a connector to “bottle”, “bottle” has connector to “beer”. >>>> Although not expressed in the sentence we would have the three atoms in the >>>> atomspace and via generation process the “covered” word (among others >>>> possibilities) would be uncovered. >>>> >>> Yes. So my main focus is supposedly the "language learning project": >>> https://github.com/opencog/learn and it is very much my intent that I >>> be able to automatically learn not only the grammar, but [the bottle of] >>> semantic content. I am still quite a long ways from doing that. >>> >>>> >>>> >>>> - After your explanation, I think my trouble is really with >>>> the graph exportation to GML. I tested using head/dependent pairs (H/D) but >>>> when the graph is exported, the link (in GML) is ‘undirected’ (this is, the >>>> ‘source’ can be the connector ‘H’ or ‘D’ indistinctly). I guess after >>>> connection we ‘lost’ the information about directionality because it is >>>> from connector, not from the seed (what is correct, because the seed can be >>>> ‘H’ for one connect but ‘D’ for other connector). >>>> >>> Foo. The GML stuff is a hack. Here's the general idea: >>> -- All of this language stuff -- the parsing, generation, whatever, it's >>> all a graph. >>> -- I've gotten used to visualizing graphs in my head, but most people >>> don't want to or can't or find it too time-consuming. >>> -- So I'd like to have some kind of "graphical visualizer" software for >>> this stuff. >>> -- I don't want to write one from scratch. >>> -- Perhaps I can use some existing system? >>> -- The "export to GML" code is the hack: I searched for "graph file >>> formats" and GML is one of several. I read the GML spec. A bit thin, but it >>> seemed usable. I tried it; it seemed to work. So I wrote some minimalist >>> "export to GML" code. Its just barely good enough to not be totally useless. >>> -- Something better is needed. If nothing else, a patch to fix your >>> complaints. (Yes, github issues is the right place for this kind of >>> "narrow" issue) >>> -- The opencog atomspace has a decade-long legacy of half-baked >>> graphical visualizers. There is no workable, general solution on the >>> horizon. We're stranded at sea, looking at the flotsam and jetsam drifting >>> by. >>> >> >> There is one visualiser on the horizon in the form of a Jupyter notebook >> widget — the advantage of it is that it’s embedded in the already existing >> infrastructure for this sort of thing and easy to use in-place from a bunch >> of code. We will see how it fares. >> >> >>> >>> So that's the state of affairs, there. >>> >>> Linas. >>> >>>> Once more, thank you! If you want I can post this doubts in the >>>> maillist (or another preferred channel). >>>> >>>> Ely >>>> >>>> >>>> >>>> *From:* Linas Vepstas [mailto:[email protected]] >>>> *Sent:* Friday, December 3, 2021 23:39 >>>> *To:* Ely Matos >>>> *Subject:* Re: About Sheaf Theory - OpenCog implementation >>>> >>>> >>>> >>>> Hi Ely, >>>> >>>> >>>> >>>> On Fri, Dec 3, 2021 at 6:26 PM Ely Matos <[email protected]> wrote: >>>> >>>> Dear Linas, >>>> >>>> Sorry by disturb using a direct message, >>>> >>>> >>>> >>>> No problem. But nothing you are asking couldn't also be said in a >>>> public forum; there is nothing embarrassing here. >>>> >>>> >>>> >>>> but I really need help in (maybe too simple) >>>> >>>> >>>> >>>> Nothing is ever too simple :-) >>>> >>>> >>>> >>>> two questions about how to use the current sheaf implementation at >>>> OpenCog (I’ve read the papers and run the examples at opencog/generate >>>> github repo): >>>> >>>> >>>> >>>> Let me tackle the questions in backwards order. >>>> >>>> >>>> >>>> - I have a bunch of FOL theories (from the Gordon & Hobbs >>>> book [1]) and I’d like to know if – in the current version – it is possible >>>> to implement some kind of logic using sheafs. >>>> >>>> >>>> >>>> I find this confusing in several different ways. For me, "FOL" stands >>>> for "first order logic"; the book you point at is about the psychology of >>>> common sense. I don't see what they have to do with each other. To me, >>>> common-sense reasoning has nothing to do with logic, but perhaps the >>>> authors make some strong argument about that. I have not seen this book >>>> before. Anyway, my confusion here is not that important. >>>> >>>> >>>> >>>> More important: the "generate" code base aims to generate all >>>> possibilities of something, meeting some given constraints. Is that what >>>> you want to do? What do you want to generate? >>>> >>>> >>>> >>>> In mathematics, and conventional first-order-logic, this is commonly >>>> done with theorem provers: the goal is to generate all possible theorems >>>> stemming from some axioms, or to generate all possible proofs subject to a >>>> statement of a theorem. The present day theorem-provers (there must be a >>>> dozen such projects) are surely 1000x faster than my code, although... they >>>> are not designed for generating English or other generic things; I am >>>> interested in the generic problem. >>>> >>>> >>>> >>>> Now about the code itself: >>>> >>>> >>>> >>>> * It's still rather primitive and undeveloped; it does a few basic >>>> things but much much more can be done. >>>> >>>> * The original intent was to use it to generate English language >>>> sentences, given a collection of abstractions .... it does not do this yet. >>>> I still want to do this but am distracted by many other projects. >>>> >>>> * The design was meant to allow it to generate "anything", not just >>>> language, but any kind of structures. >>>> >>>> * The current generator works by exhaustively enumerating all >>>> possibilities. This is not terribly fast. >>>> >>>> * I recently learned about this: https://marian42.de/article/wfc/ - it >>>> might be a more efficient algorithm for generation. I think I see how to >>>> generalize it, but have not tried. But that's off-topic, other than to note >>>> the current generation code is both primitive, and slow. >>>> >>>> * The theorem provers I mentioned (HOL, Vampire, prover9... ) are >>>> probably filled with great ideas that could make the opencog/generate code >>>> run much faster... but it's a huge amount of work to implement these ideas. >>>> https://en.wikipedia.org/wiki/Automated_theorem_proving >>>> >>>> >>>> >>>> >>>> >>>> - I see that network generation can be a way to ‘glue’ >>>> different sections, based on connector specification. >>>> >>>> Yes. >>>> >>>> But (a) I didn’t see how to implement constraints (on the linking >>>> between two nodes) and (b) I didn’t see how to force directionality. >>>> >>>> >>>> >>>> I'm not sure how abstract I should be in answering. A somewhat short >>>> high-level review is here: >>>> https://wiki.opencog.org/w/Connectors_and_Sections >>>> >>>> >>>> >>>> So let me give an answer using the low-level notation. >>>> >>>> >>>> >>>> A connector has the form >>>> >>>> >>>> >>>> (Connector >>>> >>>> (Bond "FOO") >>>> >>>> (Direction "bar")) >>>> >>>> >>>> >>>> The (default) rule is that connectors of type "FOO" can only connect to >>>> other connectors of type "FOO" and nothing else. (I envision non-default >>>> styles, too, but there might not be an API for that yet. I don't remember) >>>> >>>> >>>> >>>> If the above is satisfied, then the next check is made: do the >>>> directions "match"? In one of the examples, there are only two directions: >>>> + and - and they must always be opposites. Thus, FOO- can only attach to >>>> FOO+ and never to another FOO-. One of the examples shows how to declare >>>> which directions can attach to which. Here >>>> >>>> >>>> >>>> >>>> https://github.com/opencog/generate/blob/43cfa2c22ac03859494b45268b3a85372896da2b/examples/grammar.scm#L30-L45 >>>> >>>> >>>> >>>> shows how to define +/- opposites, while the below shows how to connect >>>> anything to anything: >>>> >>>> >>>> >>>> >>>> https://github.com/opencog/generate/blob/43cfa2c22ac03859494b45268b3a85372896da2b/examples/basic-network.scm#L86-L92 >>>> >>>> >>>> >>>> you could also create rules that say, "a and b can join together, and b >>>> and c can join together, (and nothing else)" by saying: >>>> >>>> >>>> >>>> (define sexuality-set (Concept "abc example")) >>>> >>>> (Member (Set (ConnectorDir "a") (ConnectorDir "b")) sexuality-set) >>>> >>>> (Member (Set (ConnectorDir "c") (ConnectorDir "b")) sexuality-set) >>>> >>>> >>>> >>>> So that is a "tri-sexual" example: a can only joint to b, but not to >>>> other a's and not to c's. B can mate with a or c but not with other b's. >>>> >>>> >>>> >>>> Also -- I recently renamed "ConnectorDir" to "Direction". It's easier >>>> that way. >>>> >>>> >>>> >>>> --linas >>>> >>>> >>>> >>>> -- >>>> >>>> Patrick: Are they laughing at us? >>>> >>>> Sponge Bob: No, Patrick, they are laughing next to us. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> 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/aa8fae14-2f42-4bee-b2b9-ca27133f53e5n%40googlegroups.com >> <https://groups.google.com/d/msgid/opencog/aa8fae14-2f42-4bee-b2b9-ca27133f53e5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Patrick: Are they laughing at us? > Sponge Bob: No, Patrick, they are laughing next to us. > > > -- 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/CAHrUA37_ku4t5Fi0y%2B_enZ%2BWHsGmP0jVa9kRYZPo1V6w4cwTzw%40mail.gmail.com.
