Hi Ely, Nothing that you write suggests that you need to employ any of the sheaves concepts to do what you want to do. The sheaves work is ... very complex, experimental, and only partly implemented. This is in stark contrast to the "conventional" AtomSpace used for "conventional" knowledge representation. I think you need to spend more time getting familiar with the conventional approach, first, before diving into the abyssal depths of sheaves.
For the "conventional" approach, I'm guessing that perhaps the PLN demos are a good place to start. I don't know that we have any wiki pages on "how to do knowledge representation with the AtomSpace", but we should. Nil Geisweiller, any ideas? Ben has several books covering such topics; I think one of them is called "Probabilistic Logic Networks" and you should be able to find the PDF's. This is probably the best place to start to do what you want to do. --linas On Fri, Dec 24, 2021 at 7:30 AM Ely Matos <[email protected]> wrote: > > Hi Linas! Thanks for the answer. Merry Christmas for everyone. > Roughly speaking, I have a kind of "ontology" that I want to traverse > dynamically. For example, I have "book"; "book" can be a "physicalObject" or > a "informationObject" (it is a polysemous lemma). So, I have a Section "book" > and Connectors to "physicalObject" and "informationObject". Then, I have > "blue", forming the phrase "blue book". "blue" is related to "color" and > "color" is related to "physicalObject". Then, when I "join the pieces" I have > an evidence that "book" in this phrase is a "physicalObject". The "join the > pieces" is the dynamic part (a sort of 'parser' - I understood by the paper > that sheaves can be used to do that). > The question here is: I'll create a connector in "book" to "physicalObject", > but I don't want to create a connector in "physicalObject" for all the > possible physical objects. What I've thought is to forcedly create a > connector in "physicalObject" during the parsing-time. (I know the situation > is a bit more complicated because I'll have some other rules to allow or deny > the connection), but it is the main idea. > Thanks! > Ely > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Linas Vepstas > Sent: Friday, December 24, 2021 00:51 > To: opencog > Subject: Re: [opencog-dev] About Sheaf Theory - 'Unidirectional' connection? > > Hi Ely, > > On Tue, Dec 21, 2021 at 8:04 PM Ely Matos <[email protected]> wrote: > > > > Hi! > > > > Still learning (and testing) about sheaf theory. I’m wondering if it is > > possible to have a “unidirectional” connections or if this is against the > > theory. > > Yes, one can have a non-directional connection rule. The connection rules can > also be arbitrarily complicated. There's an example in > https://github.com/opencog/generate/blob/master/examples/trisexual.scm > > > For example, if I have an “ontology” with one type “Entity” and many > > types that are children (is-a) of Entity. Is it possible to specify > > that each children has a connector > > What are you trying to do? > > In basic conventional opencog, there's none of this sheaf stuff, and instead > one has assorted relations for very conventional types of knowledge > representations. Usually people do is-a relations with InheritanceLink > > (Inheritance (Concept "animal") (Concept "thing")) > > and so on. > > See e.g. > https://github.com/opencog/atomspace/blob/master/examples/pattern-matcher/recursive.scm > > and more generally > > (Evaluation (Predicate "some relation") (List (Concept "a")(Concept "b"))) > > > (Connector (Concept "Entity") (ConnectorDir "*")) > > > > But do NOT specify a connector in Entity? So, if I have many instances of > > Entities each one can connect just with one child. If I specific a > > connector for each child in Entity, the same instance could be used by many > > different instances of children and I don’t want this. > > I can't answer your question because I don't know what you are trying > to do. The Connectors are meant for breaking things up into pieces, > and reassembling them. Most people, when they work with ontologies, are not > interested in breaking them nor reassembling them. > > At any rate, Merry Christmas! > > --linas > > -- > 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/CAHrUA34akZ8arG%2Bjd3xtxg8sfs8ynk7ULUiik1Qcay-x-Z1k_w%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/062601d7f8ca%245bdaff00%241390fd00%24%40gmail.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/CAHrUA37nCtwU6YnOf7mTWS2aTDVz1%3D0so2n0zN-yQppm2xK1OQ%40mail.gmail.com.
