A question I'm pondering: Should the connections between supertag instance fields contain information?
So for example:
- If "A" (#solution) is a solution to "B" (#problem), The question of "why" it is a solution belongs in my mind more to the connection between A and B than to either of the nodes.
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.