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
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.