About Sheaf Theory - 'Unidirectional' connection?

[Ely Matos]

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. 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

 

(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.

Thanks,

Ely

 

[Linas Vepstas]

Hi Ely,

On Tue, Dec 21, 2021 at 8:04 PM Ely Matos <ely....@gmail.com> 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

[Ely Matos]

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

--
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/CAHrUA34akZ8arG%2Bjd3xtxg8sfs8ynk7ULUiik1Qcay-x-Z1k_w%40mail.gmail.com.

[Linas Vepstas]

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

> 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.