Skip to main content
tana
Product Company Community App Get early access
Community
Search
Log In
Log In Sign Up
Arnoud Otte

Arnoud Otte

Joined Oct 18, 2024 Last seen Feb 19, 2025
Posts 1 Comments 5

⁨Arnoud Otte⁩'s Comments

Newest Top
Newest Top
    1. ⚡️ Ideas
    2. Taxonomy: A "network graph" of supertags, and how they connect via extensions and field instances
    Arnoud Otte Arnoud Otte Nov 29, 2024

    As this item seems to have traction, I'd like to bump my Matrix idea up here, as I think the concept could support this idea. It would allow for a sleek way to view supertags from different angles.

    For example:

    • Supertags across, fields down, field configuration in cell
    • Extended Supertags across, Extending supertags down, field names in cell
    👍️ 2 Like Loading...
    Reply Actions
    1. ⚡️ Ideas
    2. Tana Web Clipper
    Arnoud Otte Arnoud Otte Nov 28, 2024

    Please make it available on the three major platforms: Chrome, Safari, and Firefox.

    👍️ 4 Like Loading...
    Reply Actions
    1. ⚡️ Ideas
    2. Drag nodes between groups to change field value 🔃
    Arnoud Otte Arnoud Otte Nov 6, 2024
    In reply to Adam J. Richman Adam J. Richman
    Adam J. Richman Adam J. Richman Oct 1, 2024
    2024-09-30 at 09.27.22 - Tana - Tana [Curïo]@2x.png

    This is a reasonable UX expectation, given that in card view we can move the project card from one grouping to another and the field updates accordingly.

    Reply Actions
    1. ⚡️ Ideas
    2. View and manage cards in a matrix by allowing different groupings for columns and rows
    Arnoud Otte Arnoud Otte Nov 1, 2024
    In reply to Darren Brierton Darren Brierton
    Darren Brierton Darren Brierton Oct 30, 2024
    In actual Kanban boards (for project management) these are known as "swim lanes", and would indeed be a powerful addition to Tana.

    Ah, yes, "swimlanes", same term for process flow diagrams depicting systems or responsibilities.

    Just hope this makes it in, as it seems such a natural fit for the UX, and offers so much more insight into the graph.

    Reply Actions
    1. ⚡️ Ideas
    2. Bidirectional Fields
    Arnoud Otte Arnoud Otte 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:

    • https://ideas.tana.inc/posts/401-need-to-be-able-to-create-search-node-that-uses-the-field-has-semantic-function-part-of-setting-to-find-all-the-nodes-that-are-in-a-hierarchy-created-in-this-field
    • https://ideas.tana.inc/posts/490-new-semantic-function-dependency-of
    • https://ideas.tana.inc/posts/230-includes-the-inverse-of-part-of-semantic-fields

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

    👍️ 1 Like Loading...
    Reply Actions