Parent-child relationship between brains

[borgauf]

I would simply like to have an entry be the child of a parent within its brain, but also the child of a parent in another brain in another directory. How can this be done? I've tried various things with brain: and brain-parent: resource links, but that doesn't seem to be it. Please advise.

[Kungsgeten]

Different brains do not support relationships between each other. Having those relationships would mean that they're the same brain.

[borgauf]

I see.... Hmm. I would really like that sort of functionality. Maybe I should take a stab at it. But then what are the brain: brain-child: brain-parent: links for? I've never figured out their use.

…

On Sun, Jun 13, 2021 at 4:01 PM Erik Sjöstrand ***@***.***> wrote: Different brains do not support relationships between each other. Having those relationships would mean that they're the same brain. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#363 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABA73W3UR2BNXUF34WASV43TSUMELANCNFSM46T54KBA> .

-- ⨽ Lawrence Bottorff Grand Marais, MN, USA ***@***.***

[michaelsjackson]

borgauf, can you give a use case scenario for your idea? If possible as concrete as possible, using simplest case scenario. How could such a linking useful where and why current single-brain technique would not be enough here? Thanks.

[borgauf]

I know it flies in the face of the whole org-mode tags eco-system, but a more graph way of doing tags would be to have any given vertex object be a child of a "concept" (read tag) vertex. For example, if I'm working on a set theory item -- that relates to the Intermediate Value Theorem. I want to have my item be a child of the IVT "concept" vertex (which is a child of, child of...). In the long run, graph theory/querying has much more power than any sort of tag system, IMHO. Tags can't really show "interconnectedness" like a graph can -- unless you turn your pile of tags into some sort of graph itself. If I can't have a separate brain for all these concept vertices, then for every brain I'd have to have all the concept vertices inside that brain, which would no doubt lead to duplication. That is, if I have two brains, both dealing with math things, I don't want to have two sets of math concept vertices for each. In general, any sort of predicate system (a la Semantic Web, RDF, Owl) would have to allow brains to look and connect to outside graphs as well. Also, in general, brains should be able to "intertwine," IMHO.

[michaelsjackson]

If this is your simplest case explanation, thanks friend, you tried at least. But I am not sure if I really got the important parts of it. An example for 5 year old children could be a solution. Feynman could explain it to a 5 year old child I guess. For your explanation I need more (org-)brain. :-)

[borgauf]

I'm simply saying you replace the idea of org tags with actual parent vertices that any vertex can claim as their "concept parent". For example, if I have a heading that would have the tag "society" I would replace it with a parent vertex "society." And that "society" vertex should be in another brain -- and accessible to all other brains -- so I don't have to duplicate it for all brains.

[Kungsgeten]

I don't really see why you'd want to have several "brains" if they share information: then they're the same brain (to me). Also keep in mind that org-brain supports several "roots" in the same "brain graph", so you could have several graphs which never interact with one another, but still part of the same brain.

That being said I saw that @michaelsjackson had a switch-brain link in his config (some snippets here: #366). Not sure about the details (I might have provided tips regarding those links, but I can't remember).

The links brain: brain-child: brain-parent: etc can be used if you want to add inline links to org-brain entries while editing in org-mode. If brain-child is used, the linked entry will be added as a child to the entry you're editing.