ideas about edge functionality

[swhalemwo]

Hi! I've had some ideas/questions about edges (again ;)), I'd be interested if you have any ideas about them. I (obviously) like org-brain very much, and since I've been using it a lot recently I've been thinking about ways in which edge functionality could be expanded even further.

The first (and most straightforward) thing nice to have would be directed friend relationships. They're currently undirected, and while I for now can use one-way edge annotations to indicate direction it'd be more parsimonious to indicate edge direction through something like #+BRAIN_FRIENDS_IN and #+BRAIN_FRIENDS_OUT.

The second case is when multiple edges exist between nodes. For example, persons x and y can be friends, then person x betrays person y, upon which person y kills person x. At the moment, it would be difficult to store such information in the edge annotation between nodes x and y. A possible solution I could think of would be to use auxiliary notes of actions or events for each of the relationships or interactions, I.e there could be an events.org file with file entry nodes for each interaction (friendship, betrayal, killing) that links to the involved other nodes.

The third case is similar to the previous and concerns concept relations nested in other entities. An example would be that person a argues that x causes z, and person b argues that y causes z. As soon as the number of persons making statements about concepts x, y, z grows beyond a handful, it becomes cumbersome to store information of who said what using the edge annotations between the concepts. Here my idea would also be to use auxiliary "argument" nodes which would be children (presumably headline entries) of the persons making them.

An requirement for such auxiliary nodes would then also be a form of resolution/conversion in relationships to concepts to not have the org-brain visualize buffer cluttered by them. E.g. in the multiedge example, it would presumably be preferable to have the org-brain visualize buffer look like

x <-> y 
      y
      y

(with the current way of edge annotations popping up in the minibuffer when placing the cursor on them) rather than like

x <-> friend_relationship_subnode
      betray_event_subnode
      kill_event_subnode

as the latter would not give an indication which other person(s) the auxiliary nodes involve. Similarly in the second one, the argument auxiliary nodes would probably also have to be "resolved", resulting in

z <-> x
      y

instead of

z <-> argument_subnode_of_a
      argument_subnode_of_b

These are all issues I found that concern my use cases; so I'm not asking for any particular feature to be implemented (I might try and see if I can hack something together along these lines), I was just wondering if you had any ideas about these topics. Cheers!

[bepolymathe]

Hi @swhalemwo

Regarding your first proposal, I think we need to clarify the general use of org-brain-annotate-edge.

For me "friends" links are non-hierarchical connections between information. It's very important to keep this characteristic because that's the whole point of the mapping concept... to make non-hierarchical logical links appear.

The annotations are simply indications allowing to remember something related to this link (why, date, context, etc).

So I think it's not a good idea to imagine directions for "friends" links. To distinguish which entry is the origin and which entry is the target, backlinks seem more suitable to me. For the rest we have "parents", "siblings" and "children" with the possibility to annotate the edges each time.

Cheers !

[Kungsgeten]

It all seems pretty complicated to me, and I don't quite understand the idea. But that doesn't mean that it is a bad idea :-)

To me it kind-of seems like you want to add custom relationships? Maybe there could be a variable where you define custom relationship link types, and then a command to add such a custom relationship? On top of my head each element in that variable could look like this:

("OUTPUT" . "INPUT")

In the case above you could create a custom OUTPUT relationship between A -> B. Entry A would then have B as an OUTPUT and B would have A as an INPUT. You could also add an INPUT relationship the same way. So if org-brain already had used this, the current relationships of parent, child and friend would probably look like this:

(("CHILD" . "PARENT") ("FRIEND" . "FRIEND"))

It might even be possible to add one-way relationships where you don't want "backlinks":

("ADMIRES" . nil)

Now you could have it so A ADMIRES B, but if you're looking at B you will not see B's admirers.

[swhalemwo]

Hi @bepolymathe ! I completely agree with you that friend relations are to be used for non-hierarchical links. But I still think that non-hierarchical relationships can nevertheless be directed. In the example of person A admiring (or killing) person B, the relationship between the two people seems very much directed without a hierarchy being present there. I still haven't gotten backlinks to work, so I can't directly evaluate their potential to indicate direction; but overall it seems to me more parsimonious for both edge construction and retrieval to store information about edge direction as close with the edge as possible rather than using another function for it.

@Kungsgeten thanks, I like this idea of custom edges a lot! They sound like a generalization of what I had in mind with #+FRIENDS_IN and #+FRIENDS_OUT, just even more powerful due to the higher degree of customizability (I'm not sure if I'd make much use of not having backlinks tho; I can't really think of a situation where I wouldn't want to be able to traverse the network in either direction, so I'd likely always use ("ADMIRES" . "ADMIRED_BY")). Overall, I think these custom relationship would perfectly cover the first idea of directed friends relationship.

The second case (multiple relationships between two entities) could I think also work quite well with custom edges since it would (presumably) be possible to have multiple of these custom edges between two entities. This would then allow multiple directed relationship (e.g. A admires B, B kills A). The only minor limitation I could imagine here would be if these custom relationships involved other entities (such as in the case of interactions, a time and a place) since a custom edge type would still "only" involved the two primary entities.

The third idea (concept relationships embedded in other entities) could theoretically also be covered by these custom edges, although I'm less certain if they would the most efficient tool for this task. The primary use case I had in mind for this would be to keep track of the academic literature of my studies, which basically consists of papers making statements about relationships between concepts. If I'd model these relationships with custom edge types, I would have to make one custom edge type for every paper to be able to keep the arguments of the papers separate. Technically this would work, but it would imply that the argument x->z of paperA would be a different type as argument y->z of paperB, while both actually are of the same type (causal relationship).

Also on the technical level I think argument subnodes would be more efficient to query links (for my visualization project). Currently, (if i understand the technical aspects correctly) many of org-brain's function that retrieve edges take nodes as input (i.e. edges are not stored as entities separately), so if papers were entities with arguments as headline entries, it would be easy to retrieve which arguments are made by which paper (with org-brain-children). If the arguments would be custom edges, I'd have to query all edges and check for all whether they concern one of the papers I'm interested in (alternatively, it would be necessary to add some kind of indexing of the edges that would retrieve all edges of a certain custom type). (On a more general level, the question is maybe also what to model as edges and what as nodes, for which I found this discussion quite interesting https://news.ycombinator.com/item?id=16542183 ; my (personal) takeaway from it is to model as much as possible as nodes ;)).

But please don't get me wrong, I still think that custom edges are a great idea (i very much admire the 'abstraction' to a more general level) and would be a very nice feature to have!

[michaelsjackson]

Just read it now, after posting in my inputs outpus pins issue/topic, this seems to be indeed very similar, even input and output are mentioned above. :cake:

Sequential flow

Input output are needed for getting the sequential flow, parent child are great for placing them in hierarchical position, of our thoughts, friend is anything else (no parent, no child, no input, no output, but still somehow in any other form related, worth keeping close). This is how I am seeing it, as a very general concept.

Zachman framework: who, what, when, where, why, how

Other than that, if I would want to add many more relationships, but not directly visualized, only as a listing somewhere, first thing I would think of would be something like a Zachman framework with: who, when, where, what, why, how. And even here, I am seeing how as input, why as output. From those 6 "Zachman dimesions", 4 would remain: who, when, where, what. Staying at 6 related concepts, it could be interesting using a hexagonal structure around current thought, each of those 6 corners representing that "Zachman dimension", using again a different color maybe, all those 6 essential "Zachman dimensions" should use a separate color.

Games

Something like the tilemaps, created for games, field to field one could navigate between the thought entries. Parent child would lead just to different levels of maps, parent you go up, child you go down, like in a big market elevator.

Risk board game

It could be also interesting later, printing a "risk game map" of your brain concept maps, each hierarchy level as a separate map, so during gameplay you would also switch the maps. Why not, right? Or taking some interesting book, converting into concept maps, then again printing as risk-board-game-concept-maps.

[michaelsjackson]

I clarified my related ideas here, how it could be implemented in org-brain: https://github.com/Kungsgeten/org-brain/issues/371#issuecomment-877590526

and here: https://github.com/Kungsgeten/org-brain/issues/371#issuecomment-877589045