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.
27 Comments
Totally agree! This is a must-have feature for me.
Can this be done using a search field in the #author supertag?
No, because the point I'm raising here is that there should be a way to have bidirectional context. Using a search field is a workaround, not a solution to that inconsistency. Not to also mention the pain of having to toggle open the search node, and adding new entries under the search node - clearly different to fields, because nodes live locally under fields, while search nodes do not house nodes locally - they get automatically housed under the daily page.
The advantages may not be as clear with just two types of supertags. But they become clearer when we start to involve multiple supertags and relationships become more complex. Some form of bidirectional context must exist... A close parallel to this are Relational Databases in Notion.
It should be as in NOTION for the
Sounds good. Thanks for the clarification
Crucial feature for me
I posted a duplicate request before realizing this already existed. Here’s what I said:
Explain the problem as you see it
If you reference a node from within a field, that reference shows up in the “References” section of that node, not in a field within that node.
When specifying structured data (i.e. fields) on a record (i.e. a Tana node), one expects relations between two records to be handled consistently on both sides of the relationship.
In other words:
If a relation is defined as a field on a record, then the relation should show up as a field on both the incoming and outgoing side of said relation.
Instead, the current status quo uses a backlinks-style UI which is borrowed from last-generation tools like Roam, LogSeq or Obsidian which is optimized for handling relations found within unstructured text.
It feels strange that the fields and views UI are borrowed from Notion and Airtable, but bidirectional fields didn’t carry over. This mismatch of UI idioms is frustrating.
Why is this a problem for you?
This is a problem only because Notion and Airtable handles this so gracefully, and Tana does not.
Since Tana is attempting to implement a superset of Notion and Airtable’s databases, this can be classified as a feature regression of sorts, especially if a user (i.e. me) were to migrate from using one of those tools to using Tana.
Example scenario:
Let’s say I have a field inside #Task called “Projects” that is of type “Instance” referencing nodes of type #Project
Inside a #Project, I might have a field called “Tasks”, where I want to see nodes of type #Task that reference said project
This example scenario works out of the box with Notion and Airtable, and doesn’t work with Tana’s fields, which is a crying shame!
Suggest a solution
The easy solution: Make relationships between nodes that are defined inside a field bidirectional. This probably only makes sense for nodes that have a schema inherited from a supertag.
The ideal solution: A better way to define cross-schema relations, replete with the ability to visualize fields and how they relate across #Supertags, probably using some kind of boxes-and-arrows no-code UI that looks like an ER Diagram.
Hell yes! Well framed, absolute need
This is exactly what I do at the moment to achieve what Winston just explained although having to setup such a thing from time to time is indeed cumbersome
From a discussion I had with Matt (from Tana):
Olli Tiainen
[10:07 AM]
I'm in specific very very very (did I say very) interested in your work regarding bidirectional fields Stian mentioned you were experimenting with
[10:08]
And by bidirectional fields, I mean, that if there are two #organization s A and B and organizations have a field [Competitors: #organization] - then if I insert B as a competitor to A's field, A would appear as competitor in B's field too.
Olli Tiainen
10:09 AM
Or similarly, i.e. Project - Client - Team member relationships would show up in all of them without needing
[10:10 AM]
Well, I think it's really the most important additional feature I could imagine having in Tana. It would basically replace my needs for Airtable.
Olli Tiainen
[10:11 AM]
If I tag connect a team member to a project, then if I look at a list of projects, I'd like to see the team members listed
[10:11]
Or if I have a client A that is having a problem B, if I look at the list of problems, I can see all of the clients that have that specific problem
[10:12]
Almost all fields with instances are, in my mind, bidirectional.
[10:13]
References at the bottom help yes, but they are not the same thing at all and don't really help structure and work with the information. They only make the connections somewhat visible.
Quite simply: I am a cousin to my cousin. And that relationship should be expressed only once, not twice, like the current ontology structure requires.
Similarly, if John is working on a project, then the project has a contributor John.
There may be better solutions, but one way to implement this is to create automation/mirroring rules to instance fields of two supertags i.e. "When #person is added to #project's field Team, add that #project to #person's field Working on".
A question I'm pondering: Should the connections between supertag instance fields contain information?
So for example:
I think it matters. Annotated edges are an essential component of graphs.
With Roam-style backlinks, there aren’t any annotated edges between pages that link to each other, but at least the unstructured text does that job of adding context.
With fields, the field label does all the heavy-lifting, but the problem is that they behave like columns in a relational DB than they do edges in a property graph.
What is a desirable mental model here? Is it analogous to relational DB joins, with automatic backlinks, like how Airtable and Notion have implemented it?
Or is it analogous to a property graph where any node can have any type of edge and you can optionally annotate that edge with properties?
Tana seems closer to the latter right now, but end-users are more familiar with Notion/Airtable style UX.
Not sure how to reconcile these differences, but my preference is err on the side of flexibility, which means figuring out a good UX for property graphs where nodes can have properties, but edges can also have properties.
Edge properties could perhaps work like “contextual content”, or that feature could be expanded and rethought to better fill this role. Certainly, that’s the only way you can annotate context when you link between two nodes right now. It works for unstructured data, but there must be a better way for structured data which hopefully isn’t yet another new concept.
I think backlinks make a ton of sense, too, since it’s just backward traversal in a graph, but they need to be rethought (shouldn’t use Roam-style backlinks UX as they’re suited only for unstructured data, and shouldn’t also use Airtable-style backlinks as they’re suited only for relational DBs).
The current “Appears as X on Y” UX, where X and Y are static strings defined by the user, worked in a pre-GPT world, but perhaps backlinks can be semantically transformed by GPT, so “[Person] appears as a [Client] on [Projects]” can instead show up as a magic backlink field on Person that automatically parses that the field label should be called something like “Client for Projects”, or whatever GPT deems fit.
Brilliant thinking. I'm in awe.
Your "ideal solution" is related to what I'm suggesting here: https://ideas.tana.inc/posts/148-taxonomy-a-network-graph-of-supertags-and-how-they-connect-via-extensions-and-field-instances
@Andric Tham do you know if there is any example of edges, annotated edges and edge properties to help visualizing that?
Try the Neo4J Sandbox. Comes with graph and table visualizations of graph data. Not quite an end-user system, but that’s where apps like Tana can shine by innovating on the UX.
@Olli Tiainen @Andric Tham wouldn't mentioned "connection between supertag instance fields information" be contained within the field title and description?
In simple relationships, yes, such as:
But in more complex relationships, this doesn't work anymore:
It doesn't work because field titles don't capture the context of these relationships (the edges). For example, Vitamin D (#nutrient) reduces osteoporosis risk (#symptom). But the context is that this is because Vitamin D helps the intestines absorb calcium from your food. However, neither the fields nor the field titles can capture this explanation of the connection. Instead, the information must be recorded either "under" the medicine or the symptom node, where it doesn't directly explain the relationship and isn't available bidirectionally through the fields or even via backlinks.
I see, so then we would be able to for example explain the mechanism of Vitamin D by describing the relation itself.
Have you seen that implemented in UI anywhere? Where should it go in the app like Tana? Curious to see if there are any which could be helpful for devs