⁨Arnoud Otte⁩'s Comments

Oct 24, 2024

The simplest path would allow two field names (the source/the reference name) for any field, so that the referenced node can display the source(s) as a field?

But if we want information on the link itself...

Concern

Scanning through the posts, it appears that we are asking a lot from the bidirectional link, to the point that I'm wondering if this is overloading it? Going about it the wrong way? Take the Vitamin-D example. I am no doctor, so please allow for misinformation and oversimplification:

[Osteoporosis #symptom] -caused-by-> [Calcium #deficiency] -caused-by-> [Reduced calcium absorption #symptom] -caused-by-> [Vitamin D #deficiency].

Cause and effect is a weighted directed acyclical graph, but for this bidirectional link use case, we're looking at it as a chain. And it seems we are talking about ways to collapse the chain between the two end nodes into a single link and squeeze the information from the chain onto that link.
This feels opposite to what tools like Tana are supposed to do for us. They help us get to the nitty-gritty like above, and then we can re-use those chains, aggregate in searches, and see new paths evolve. The tricky part is to know whether we have those chains already. And getting that answer quickly when we are in the heat of dumping brain content into Tana.

Semantic Functions (alternative for bidirectional link — part 1 of 3)

I'm thinking we should be looking to extend semantic functions with user-defined ones, such as “caused-by”. Then, Tana could impute chains based on the end points of the “caused-by”? I.e. :

[Osteoporosis #symptom] -caused-by-> [Vitamin D #deficiency]

…but because we have defined…

[Calcium #deficiency] -caused-by-> [Reduced calcium absorption #symptom] -caused-by-> [Vitamin D #deficiency]

…maybe Tana can offer us the “missing chains”, the other paths that lead to [Vitamin D #deficiency]. We can then choose to ignore and use our direct path, or pick a chain and, in this case, let Tana change [Vitamin D #deficiency] with [Calcium #deficiency]. We would now know we have chosen to replace the direct link with a more correct/complete/accurate/precise/fill-in-the-blank chain.

It feels to me that this is a more natural path than conflating our information into a single relation.

Visualization of backlinks (alternative for bidirectional link — part 2 of 3)

As for the visual UI arguments, how would Tana know what to name the field on the other side? I can see Options/Options from Supertag fields, allowing an inverse field name to be defined. That would help some, but might also cause awkward namings for different supertags. Think mother/father/parent, daughter/son/child, sister/brother/sibling. My brain turns to a pretzel when considering due dates in this scenario. Do we now bidirectionally present this node on all dates between Start and End dates?

So, maybe, the logical follow-through would be to have our user-defined semantic functions have three names: Source field label ⇾ Semantic Function ⇾ Target field label. E.g. CausedBy ⇾ CauseAndEffect ⇾ Causes.

Theoretically, we could even assign supertags to CausedBy and Causes, signaling to Tana that we would expect these to be seeded as Optional fields to those respective supertags. This way we do not have to add them to supertags ourselves, and can cleanly maintain the semantic function.

“True” relation attributes (alternative for bidirectional link — part 3 of 3)

Now the focus can be much smaller, and I believe reduced to a simple “weight”. E.g. Not everything causes something else for the full 100%, we need to consider necessary and sufficient. So we would set a flag whether our semantic function is weighted or not (perhaps with a default value). If so, Tana could allow us to set a weight supertag, i.e. an Option from supertag.
If we need more attributes than weight… Well, everything is a node, so weight is a node with the supertag specified on our semantic function. That means Tana could already add for us the CausedBy and Causes fields to hold the nodes on with side, with a supertag of CauseAndEffect, and we would effectively “extend” it to hold what we want/need.
To keep context of these "weight" field contents clean and clear, these fields could then be only shown when "editing" the node/reference within the relationship field of the related node. I.e. edit the relationship fields showing on [Calcium #Deficiency] in the [Osteoporosis #Symptom].CausedBy field. Or, likewise, only show these fields when "editing" [Osteoporosis #Symptom] on [Calcium #Deficiency].Causes.

Conclusion

I think this approach will provide us much more freedom to define our “tagsonomies” (not my pun, but so good) and hits most, if not all the items discussed above. It provides extra semantic context and insight to us, and Tana AI.
And as it comes in three parts, the Tana team can gradually build us toward it, although some of these will be bigger than others. And it feels very Tana-esk.

Extras that seem to come with

We can search these “chains” with low-noise results: #symptom CausedBy COMPONENTS_REC [Calcium #deficiency] or #deficiency Causes COMPONENTS_REC [Osteoporosis #symptom.
We can query relationships through their semantic function supertags: #CauseAndEffect Weight=100 AND Causes #symptom; display Causes and CausedBy (What symptoms are guaranteed to be caused by one single cause, and what is that cause?)
We can extend to our hearts content the relationships we want, and the fields we want to record for them.

These thoughts might also address:

If you are still here after this lengthy exposition: Thank you for reading.