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! > 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. 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/CAHrUA35TzSkrHKjmpAjsjKN_QJKPBvtwTh2ZdFYkJ4ma5a5Zkw%40mail.gmail.com.
