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: > >> Hi Linas, >> >> I thank you very much for answer. Sure, I can make the discussion public, >> but I don’t know the correct channel to do that. Discord? Github? Slack? >> MailList? All of them J ? >> > > Great question. For emails, I use the link-grammar and/or opencog mailing > lists, and I'll just start cc'ing those lists from now on. Github is > great when the conversation is more focused; its like > email-but-with-a-reviewable-history best suited for concrete action plans. > > I do hang out on discord ... but chat is more social. > > About the Hobbs book (actually is it very lengthy), I’m attaching a paper >> that presents the idea. Basically it is a try to formalize something we >> call “image schemas”, from Cognitive Linguistics (it is my research field). >> > > I'm skimming. I've seen stuff like this before. So, for example, pages > 156ff uses the for-all, there-exists + logical operators notation. Others > use a lambda-calculus style notation (e.g. the markov logic people do > this). I've slowly come to realize that both notations are inadequate and > lacking, and my current favorite is the "jigsaw" paradigm, which encompases > the best of all these variants, and ditches the worst. > > ... But I guess you already sense this. If not, we should settle this > issue, as I am trying to get more people to understand the how & why of it. > > > 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? 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.
