Re: About Sheaf Theory - OpenCog implementation
Linas Vepstas
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 ?
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).
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’.
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.
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.
- 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).
Once more, thank you! If you want I can post this doubts in the maillist (or another preferred channel).
Ely
From: Linas Vepstas [mailto:linasv...@gmail.com]
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 <ely....@gmail.com> 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
shows how to define +/- opposites, while the below shows how to connect anything to anything:
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.
--
Linas Vepstas
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 ?
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).
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’. 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.
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.
- 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).
Once more, thank you! If you want I can post this doubts in the maillist (or another preferred channel).
Adrian Borucki
On Sat, Dec 4, 2021 at 9:49 AM Ely Matos <ely....@gmail.com> 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.
Linas Vepstas
wtorek, 7 grudnia 2021 o 23:27:38 UTC+1 linas napisał(a):On Sat, Dec 4, 2021 at 9:49 AM Ely Matos <ely....@gmail.com> 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?
--
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 opencog+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/aa8fae14-2f42-4bee-b2b9-ca27133f53e5n%40googlegroups.com.
Linas Vepstas
On Tue, Dec 7, 2021 at 6:50 PM 'Adrian Borucki' via opencog <ope...@googlegroups.com> 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 <ely....@gmail.com> 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.)