Explain the problem as you see it
Using an example, when we create Alice in Wonderland #book with the Author field as Lewis Carroll #author, currently we are unable to automatically populate Lewis Carroll #author such that its Books field shows Alice in Wonderland #book.
Why is this a problem for you?
The only way to access what books Lewis has written is to look at the References section below the page when we zoom into the node, or when we shift click > click the number of references. Way too many clicks. And also, it is only contextualised one way - this means that Tana only has the ability to contextualise in one direction.
Suggest a solution
Allow bidirectional fields.
31 Comments
Yes. This is also what Andric refers to with
The point here is that connections between supertags never contain any additional structured or unstructured information that explains the context.
I haven't seen any good UX for this - nor can I immediately imagine what a good simple solution could look like, especially in a bidirectional context. But here's what a bad and complex solution could look like that would do it's job in the context of this very narrow example - but it would probably hardly generalize:
The node "Osteoporosis #symptom" has a field "caused by" that would take multiple supertags + unstructured data as input
In the field, I would write
-- [Caused by] "Vitamin D #nutrient" deficiency because Vitamin D helps absorb calcium.
-- [Caused by] "Estrogen #hormone" reduction because Estrogen suppresses bone resorption.
The node "Vitamin D #nutrient" has a connected field "Effects". The field would automatically contain
-- [Effects] "Osteoporosis #symptom" caused by Vitamin D #nutrient" deficiency because Vitamin D helps absorb calcium
The node "Estrogen #hormone" has a connected field "effects". The field would automatically contain
-- [Effects] "Osteoporosis #symptom" caused by "Estrogen #hormone" reduction because Estrogen suppresses bone resorption
If we are supporting this kind of relationships, i think one important option to validate is whether the relationship is
Solution! Multiple ways to conceive...
Node <----> Connection <----> Node
Node1 <----> Connection <----> Node2
Subject <----> Connection <----> Object
Subject <----> Predicate <----> Object
The connection/predicate would get the same treatment as a node, except perhaps it would be have a special property highlighting the contextual connection between 2 other nodes. Essentially they would be hybrids between fields, properties, and nodes.
If the user can define the connection/predicate node, or an AI suggests it — why wouldn't your example generalize?
Obviously different spheres of knowledge would require different connection/predicate types, and there would be some work needed by the user/AI to define them.
But I think this is what power PKM users are asking for. Just give us the tools to build every type of connection between nodes that is possible, even if it requires work, and I will do it.
For example, in the nutrient/symptom example you gave, we might see a rise of ontological "tag" templates. the realm you are talking about is health. So perhaps all nodes related to health will follow the same or similar higher level ontological structure. Users can define their frameworks or can borrow from a community library of "tag" frameworks.
On the high level, a health framework would contain terms like {symptoms, treatments, nutrients, psychological, physiological, nervous system, digestive system, allopathic, ayurvedic...}. On the lower level, we would have the specific types, kinds, names of these higher level things {vitamin d, estrogen, spleen, runny nose, acupuncture, stem cell therapy, back fusion surgery...}.
An example of a connection/predicate node set might include members such as {caused by (x thing), symptom of (x illness), organ of (x system), treatment type of (x health/medical philosophy), treatment type for (x set of symptoms)...}
Again, users can generate their own frameworks and degree of hierarchy or can borrow from a community sharing of frameworks that makes sense given a certain domain (eg health).
One potential issue I see here with bidirectional linking along with aliases is that eventually most of the words in our nodes will be tags and only the most mundane will not be tags. Because eventually we will want a "page" for everything in our pkm.
So the example above,
will become, "#[Caused by] #Vitamin_D #nutrient #deficiency because #Vitamin_D helps absorb #calcium."
Most of us will want to be able to directly filter for all these words if our pkm contains a lot of info about health. In other words, we will want to know about all things related to Vitamin D, not just how it's related to osteoporosis or calcium absorption. Most of use will want to see a filter view related to all the kinds of nutrient deficiencies. Most of us will want to see a filter view with all related calcium info bits.
I didn't hashtag {helps, because, absorb} because those are more mundane or perhaps too broad to want to capture all the things related to those terms. But I did tag {caused by} because we certainly may want to filter for {caused by} especially if we may use that filter to help us bidirectionally link {effects} or use it as part of a complex filter for some other view we want to see.
To a certain degree then, I think where the pkm world is heading is that (just about) every word written is potentially click-able and it's own node. And the user then mostly defines the action of the click.
For example, when I click on a word, do I want to see it's dictionary definition? Do I want to see a page of all it's backlinks, aliases, linked & unlinked references? Do I want to see the user-defined definition in context? Do I want to go to the word's "SuperPage" where I can access all these views through an easy toggle? Do I want a context menu to pop-up when clicking a word to show me the options before automatically navigating somewhere?
So maybe next, we need a PKM that treats every word the same. As a potential node, field, property, tag, etc. And every word has the potential for all possible actions. And to keep the interface clean, we can't have a hashtag in front of multiple words every sentence. Users just start to assume they can click on any word and some action occurs. And like I said above, ideally over time, users can define for themselves the kinds and flows of these actions.
etc...
Well, yes, every word in any text suggests a relation between concepts that are in that text. One could argue that that’s the purpose of writing text in the first place.
Guess what groundbreaking technology was recently integrated into Tana that’s designed with the ability to understand these latent relations in text? That’s right, LLMs.
Although, I’d argue that latent relations suggested by words inside text (unstructured data), is not quite the same as bidirectional relations inside fields (structured data).
It’s the difference between a vector database and a SQL database. Bidirectional relations between entities are not the same as bidirectional relations between words (technically, n-grams, if you’re using LLMs).
The former can be modeled with relational algebra or graphs as pages of tuples, the latter with linear algebra as n-grams in text embedding space.
The former requires a structured query (such as SQL or Datalog) sent to a database query planner, the latter requires inference that runs on GPUs.
The two shouldn’t be confused or conflated.
I don’t know if SQL-style relationships are necessary, although when modeling certain domains, being able to restrict how many instances of a type of something can be related to another type of something could be essential to ensure correctness of data.
What you’re after is the ability to constrain a relationship’s cardinality.
I believe I stumbled upon some unpolished area of Tana where it’s possible to set cardinality of any given field. I think it might have been an abandoned feature?
To implement this function, you need to provide an alias for the node.
The best answer of all. But this does not exist yet in Tana Inc. At the moment I use notion for some Data systems, but to record my processes and data I use Tana Inc. I will have to combine both for my productivity.
Regarding bidirectional fields mentioned in AMA Posted also in Slack.
Search nodes are ok in many cases, in some they are even better. But still they are a different feature. Sometimes when using bidirectional fields I don’t aim to have any searching, I just want to have a field filled automatically in connected node/field. There are some differences between these two features and the key difference is that searches are asymmetrical and bidirectional fields are symmetrical, as mentioned below:
Searches:
Bidirectional fields:
Additionally bidirectional fields seem to be less of a challenge for Tana as they are static, without dynamic searching in searches which could be heavy for Tana with multiple bidirectional fields/searches.
Maybe there is some way to connect a field with a search in one special field wich would behave like a bidirectional field normally but could be expanded to enable search and linking links in unlinked references to display that searched nodes in this field in the future without the need for search (with searched and then linked nodes modified like bidirectional nodes should be modified automatically).
For me the greatest win with bi-directional fields would be the fact that they are visible directly in a table without having to expand bullets and search nodes. I love Notions approach to this, the functionality and execution is exemplary, just copy that! :)
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:
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. :
…but because we have defined…
…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
These thoughts might also address:
If you are still here after this lengthy exposition: Thank you for reading.