backlinks

[swhalemwo]

continued from https://github.com/swhalemwo/obr-viz/issues/2#issuecomment-589557756

[swhalemwo]

hi @bepolymathe! unfortunately i can't get backlinks to appear; neither with brain links nor standard file links. it also doesn't seem matter if one or both files are included in org-brain, or if one or both are file or headlines entries. I also noticed that my headline entries don't get a :RESOURCES: drawer.

From what I've seen written about them (here and in the org-brain manual), I also cannot see what functionality they offer; if i want to connect entries in org brain (like in your picture example), I would just link them as friends (and if the target wouldn't be an org-brain entry, I wouldn't need a backlink) but maybe it would become clearer if they'd work. However, if backlinks indeed were working and queryable through org-brain functions, it wouldn't be that difficult to parse them into nodes and links for visualization. do you have any ideas to get them to work?

[bepolymathe]

Yes, I understand your hesitation. From my point of view, "backlinks" and "friends" don't have the same function. Backlinks are useful to indicate resources contained in other notes (a bit like the org-roam model). Viewing them would give you an idea of the connection between resources, which can be very useful in a research project that requires a lot of reading and documentation. On the other hand, the "friends" links allow, in my opinion, to connect ideas/projects. Visualizing them is also very interesting for thinking outside of any hierarchical structure.

We could "simply" imagine that the "backlinks" links appear in a certain color and the "friends" links in another one. But it's true that it depends a bit on the workflow of each one...

[bepolymathe]

So it's interesting... I just found an Org-brain feature I didn't know about: org-brain-annotate-edge

This allows you to comment on the "friends" relationship by producing an org-brain property.

What do you think about this ?

[swhalemwo]

hm maybe i'll have a look at org-roam and see how the relationships between entries and resources work there. if the idea is to refer to different types of entities (backlinks for resources, friends for ideas), it seems to me that edge annotations can provide this distinction to some extent (I'm indeed using edge annotations in the current version, primarily to indicate the direction of an edge (with C-u e the comment is applied only to one edge)). So with these annotated edges it would be possible to annotate friend relationships to resources with e.g. "res", and color them in python accordingly.

However, I'm wondering if the current data model of edges is not somewhat limited. The main problem imo is that edges are not really objects/entities that can have attributes (or pointed at by other nodes), but that edges "arise" from the list of friends in the nodes (i hope it's somewhat clear what that means). The edge annotations are somewhat of a bandaid in that they allow an edge to have one property, but that's it; it's not possible to store more information in that edge. Other network applications I've worked with (e.g. graph-tool or neo4j) allow much more (basically arbitrary) amounts of information to be stored on edges, and also have things like edge classes through which the graph can be filtered.

So I don't really have a solution laid out, but the goal would be to make edges more "tangible". I've been thinking that maybe headline entries can work as edge objects, then each edge could also have a property drawer with all kinds of information. but this might not work for people who use org-brain primarily with headline entries (i primarily use file entries). maybe it's also necessary to create some external storage of the edges similar to org-ids, although i wouldn't really like this as i quite like that all of org-brain is easily accessible in org-mode. I also gonna have to ask kungsgeten about this some time.