Spirit LoveRoot
Spirit LoveRoot's Comments
-
- Ideas
- Bidirectional Fields
-
- Ideas
- Bidirectional Fields
In reply to Olli TiainenOlli TiainenMay 4, 2023 Yes. This is also what Andric refers to with > 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...Solution! Multiple ways to conceive...
Node <----> Connection <----> Node
Node1 <----> Connection <----> Node2
Subject <----> Connection <----> Object
Subject <----> Predicate <----> ObjectThe 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...