Multi-edges / Named Links / Sub-graph : a means of capturing fluid associations
(new to zk)
Given all the discussion of how L-style ID's can be association-brittle relative to using just links, I was wondering if the following has an implementation in any digital system.
I'd like the following: an L-style ref to "position-sequence" extended to differentiate between paths through the sequence --based on context -- in which one context path may share some im/proper subset of the other.
Example: given say
context1= {1, 1a , 1b, 1ba, 1bb},
context2 = { x, xa=1b, xb=1ba, xc, ...}
Here we have the shared edge (xa,xb) = (1b,1ba). And indeed it would be stultifying to assume that the meaning in context2 is partially identical to context1 simply because of the shared referential sub-structure.
Question: for the advocates of links only: is there a simple way to differentiate multiple referential contexts. I.e., to allow for the same edge/link to be given different meaning.
This could be via named links -- not just links named for their nodes, or multi-links, or some in-note context to mimic this behavior.
Does such a thing exist?
Howdy, Stranger!
Comments
If I understand you correctly, this would boil down to representing the sequence of notes multiple times for multiple contexts. I don't think that I've encountered an exact copy of say a sequence of 10 related notes in the exact same order that I wanted to use for a wholly different purpose.
I would think that writing about the sequence itself, illuminating it's variations in meaning for your work, in a structure note of sorts would make most sense. Then you can reference that.
Author at Zettelkasten.de • https://christiantietze.de/
You could generate multiple referential contexts with different annotated structure notes that bring together unique contexts. The different structures would thread different zettel or the same zettel with different annotated link references. These would grow over time. The fluidity of these structure notes or minimaps would be a matter of the interest, attention, focus, and time devoted to them.
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
Perhaps this will be illustrative: in the attached image consider the intersectional sub-map (purple2 -> black). We can see it’s generation is possibly far more refined than “is referenced by”, why was it referenced by…
?
It has a different history. ( Red red purple) was an ancestral path— but so was (blue purple): there are zero common connections here and thus very likely that what elaborates black in purple are two different things.
Might you have a suggestion for creating a note associated with a link? This way purple black could have two notes, one for the blue thought process and the other for the red?
In Workflowy, I use the "add the note" function to describe links of this nature. It's not a separate note in the truest sense, but at least I have a mechanism to capture the reasons why I created the link in the first place. I also use summary notes.
I've become lost in this abstraction: my own failing, not yours. I have a simple mind. I don't think I differentiate my notes with this level of sophistication. I need a more concrete example to understand.
Let me preface this with the caveat that I use a digital zettelkasten, but the note application would be the same in an old-fashioned zettelkasten. I'm searching for an example but can't find one. Maybe I don't do this?
Do you mean a pair or more of notes, one portraying an idea thread for one thought process and another note for a second thought process?
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
I think we're both thinking in the same direction, which I've tried to explain a bit in a post here. Unfortunately, as @Will already mentioned, the discussion remains abstract.
You can generate the context automatically. Between any 2 notes in your Zettelkasten, you can:
Doing this isn't hard, but making it work with a Zettelkasten (integration) is a bit of work. Look at plugins for your Zettelkasten-software which can do things with paths (which I think match up with your idea of context).
If you want to do this manually, create a structure note and put links to all interesting notes in there.
See, I'd argue that it doesn't tell you the context at the moment of your linking, it simply says "yes there is a connection" here is one such way of thinking about it. But the issue is different if there are multiple paths -- lets, for fun, assume of equal length -- but where there is a contiguous subset of edges in common.
While that common subset might seem to imply a unified context, it belies the hidden implementation issue: two paths P1, P2, overlapping on some subset S of P, implies there are collapsed multi-edges.
So rather than elucidate with the clarity of single edge paths, this is hiding the true context.
For example,
1. a note about the place of proof in mathematics
Concept <- Objects <- Algorithmic <- Proof <- Realized Concept
vs
2. type theory, curry Howard correspondence, proofs are programs.
Curry Howard <- Algorithmic <- Proof <- Programs
the common path (proof, algorithmic) demands differentiation: ideally without extracting and creating Algorithmic1 as a proxy for the different path.
Perhaps but this implies the sameness between these overlapping paths. There is, at best, symmetry.
Wouldn't any tool for examining paths not differentiate between these paths? it would before the branching, but the shortest path may contain a sub-path which is also on a shortest path between two notes.
Which of these possibilities do you think would be more natural to incorporate into a workflow?:
Have, yes, both a chronological + hierarchical L-style id of triples. In this case the triple of interest is {id, linkid, id} := {id, (id,id),id} so that linkid (id,id), is flanked by two different id's: the ancestor node and the child node. So we might have
{ objects,[algorithmic - proof],realized}
vs
{curry,[same],programs}
Use a structure note as mentioned wherein: The series of notes, including the overlap, are both elucidated with differing context.
Create two notes which points to the first node a in the overlapping paths and the one of the nodes AFTER the overlapping path: in particular perhaps pointing to the block containing the link to the target node.
This first n1 note will describe the context in getting to say [a, _, c] thus elucidating the role of the edge (a,b) in the context of c. The second note n2 will do the same say [a, _, d] and tell us about (a,b) in the context of d. Essentially this pseudo-copies a link (at least descriptively).
I.e. given (a,b), writing a note n1 = ((a,b),c) and n2 = ((a,b),d) allows us to explain n1 == the context of (a,b) in c, n2 == the context of (a,b) in d.
Any thoughts are appreciated.
I think you're overthinking it. All of that looks like a typical misspecification problem in OOP.
If it demands differentiation, it's not a common path. You should probably divide (proof -> algorithmic) to several objects.
I'm not an OOP-P so I'll check that out. But I think, if I understand your comment, that the atomic nature of notes can solve this problem. But, as you know, in research, across domains, there are common sub-paths through a knowledge network. Neither duplicating the nodes, nor creating project folders etc will solve this problem -- assuming we deem the nodes fully relevant to each.
Stupid example: Suppose you copy and past two important passages into two different papers, these nodes are the same, yet the intervening text (that you write) is surely different. I.e. the nodes (pasted passages) are the same, but that doesn't mean the edge between them should be exclusively defined by the nodes and thus identified.
Perhaps I have overthought this. I'll rephrase the question to simply prevent any further frustration
_"Id appriciate a suggestion of a way to annotate an edge between the same two notes, in two different ways, in which the annotation illuminates the fact that the sub-path is common in two different larger context-paths" _
I'm open to simple annotations, L-style id's in addition to chron ID's, "link notes".
Many thanks in advance for everyone's patience.
Bradford Fournier-Eaton
I've read your posts. You hardly have a simple mind. Your tutorials and posts have been helping me in my early journey. I just started ZK a few days back.
As you might have guessed, as a mathematician, I'm always swimming in abstraction.
Yes. If it doesn't happen, you subdivide again. And again.
As far as I understand, you have a structure of logical statements like:
1. A -> B
2. A -> C -> B ( or maybe A & C -> B )
Why C is needed? Probably because A is different in different contexts. It's probably so because you misspecify it. Maybe your A is actually a group and you have something like:
1. A1 -> B
2. A2 -> C -> B
where A1, A2 belong to set {An}.
If you want a strict structure, you transform A to {An}.
If you're relaxed about the distinction (or you can't specify {An} properly for some reason), you can simply write in the notes A and B that "in case X you also need C", forget about it and maybe specify {An} in the future.
I'm not sure if atomic notes should really contain the info to what context paths (link chains) the note(s) belong. Your links evolve and, with time, you'll link to your notes from additional contexts, so further link chains evolve and you'd need to again encode this info within the individual notes. This doesn't scale, IMO. Instead, I think it's the job of a graph (or a plugin/script) to visualise/surface the existing linkages/context paths.
If you really want to indicate that certain notes belong to different contexts, why not simply tag all notes of a certain context with a unique tag (like
#context1
and#context2
etc)? This way, an individual note indicates that it belongs to different contexts, and you can easily find/display all notes from a certain context.Alternatively, if your editor supports link types (see also this discussion), you could also encode the context(s) as link tag(s) within the link, like e.g.
[[context1::context2::LINK_ID]]
. But If it's a broader context, I'd simply use tags.My spider senses are turned up to volume 11.
There is something intriguing about the idea of discovering what connections intersect at the edges of thought maps.
Zettel are proxies for ideas. Structure notes are proxies for thought maps, proofs, trains, graphs, constellations, recipes, webs, or genealogy. Pick your metaphor. Put all the maps on a wall and where the maps intersect is the place of discovery.
How do we find and highlight the intersection of those edges with other maps, so they reveal their novel ideas? Once discovered, how should we document this? Make a new structure note to keep this new and novel ideation in the mix with everything else for a future mashup. What should it include, and how should it be formatted?
It is impossible to know which part will be an edge that touches another map when first creating it. Finding edges that touch is a function of actively looking for them, post hoc. Exploring with a curiosity mixed with trial and retrial. I think this takes some critical mass of thought maps (structure notes) to be fruitful.
A tag denoting the context of the note might be appropriate. I have started formatting many of my links with a "subtitle" to intentionally name the specific context, different in different zettel. This idea could be remixed and applied to idea maps and their intersections. Here is an example of an atomic link in my zettelkasten used in different zettel within two different contexts.
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
I'm still trying to wrap my head around what is meant by context. For me, the context of a connection between notes is the reason why I link the two notes. I will hyperlink sentences in one note to another note, explaining why the other note is interesting. This gives the edge between two notes an additional attribute: the text being hyperlinked. I tend not to use this attribute much though.
You are absolutely right, this is annoying :-).
I'm working around both issues in a lazy manner. I've found that I "value" notes more, as the number of referrals to a note increase. This is a personal preference, but one that I factor into finding the shortest path as weight for the path finding algorithm. With my current Zettelkasten (537 notes, 4 links on average per note) I've found that only a handful of notes actually have multiple shortest paths (at most two), with the rest only having a single shortest path between another note. Cool side-effect: lattices will change over time as I add/update notes, giving new insight as different lattices get connected through notes.
I don't actually find all shortest paths between any two notes interesting, that just tells me that, yes, there is a path. I'm much more interested in lattices: how do i get from the "start" of a lattice to the "end". Lazy optimalisation again:
Following the idea above, I can open any note in my Zettelkasten and see the list of exit notes that this note connects to, and how (shortest path lattice). That's where the surprise comes from, I may have a note on "information security" which has a path to e.g. "high cohesion of notes" because somewhere in the middle of two lattices, they get connected through a note. The shortest path shows me a single (shortest) lattice between those two notes, but I will still work with my Zettelkasten just to get a feeling if there are other notes in between, as there usually will be multiple, larger paths (manually, working with the information). The main advantage for me is seeing (initially and quickly) that there are two seemingly unrelated notes, but that are still linked. Investigation/work is then still needed of course to actually do something with the notes.
To be honest, I don't really like structure notes. They break the "surprise" factor by having me doing the manual work of keeping a structure note up to date, and don't change when something in the "latticed" notes change.
As for the specific context between notes, see my first remark on using the hyperlinked text to explain why the link exists.
I do create structure notes though, but usually as the starting point for a lattice that I find interesting and want to find quickly (I think this is how Luhmann used his registry/hub). I have 15 entry notes (2% of notes) right now, just to keep things manageable. Sometimes I will create a new structure note if I've written something based on multiple notes and I think that the combination of notes is worthwhile in keeping in my Zettelkasten.
Having observed the discussions on these forums for a while now, it has become obvious to me that people working in different fields may come up with very different kinds of Zettelkasten. Lumann was a social scientist, and his needs and interests no doubt influenced the working method that he created. I work in history and psychology, and my needs are different. I have found that verbatim quotes from various sources are very useful to have in my notes archive, whereas I doubt that Luhmann used them much, if at all. As to the idea of a "path" through my notes, that is not really of any interest to me at all. Just about any note in my archive is potentially connected to any other note, or notes. The connection may only become apparent when I am searching for something -- or more probably not when I am searching for something, but when I am doing something else. However, that connection may only be ephemeral. It may only be linked to what I am doing at that moment, and I may not need to remember it or record it. For me, the potential paths in the network are simply too many for it to be possible to record them. In short, nowadays I opt for simplicity, as much as possible. And I tend to see theory as the enemy of practice, unless it is kept well under control. Not too much abstraction in my fields.
@MartinBB
What are the main methods that you use for exploring your ZK, if it's not by using note to note connections? Do you just search on terms?
@GeoEng51 I wasn't clear enough. I do use note to note connections, but not pathways through multiple notes, which is what the OP seemed to be talking about (if I understood correctly, which is not always the case). When I read the first posts above it seemed to me that it was something that might be attempted in Tinderbox, which does facilitate naming types of links (perhaps something like rebuttal, confirmation, replication, etc.). I've never really explored the feature in Tinderbox because I haven't really needed to. But if you wanted to create a pathway as shown in the graphic above, you might be able to do it in Tinderbox. It does all sorts of things that other programs don't.
Link to the Tinderbox documentation: https://acrobatfaq.com/atbref9/index/ObjectsConcepts/Concepts/Links/LinkTypes.html
This is lovely. While im conceiving of paths (sequences of links) I think your idea will help.
The issue is that the (tuples of ) edges (A->B,B->C,C->D) & (Q->B,B->C,C->E), while containing the sub-path (B->C) may contain it for DIFFERENT reasons.
However, by re-factoring the initial node in the common path (here into two different not(d)es, I can state the context for linking to C.
Thus I think, for now, my solution is, given (A->B,B->C,C->D) & (Q->B,B->C,C->E), to create the following: (A->B, B->C, C->D) and (A->B', B'->C, C->D) where B' is just a different note from B (though likely similar but examining the context of the outbound C in a different way.
Still, to be stubborn, it would be nice to be able to give a name to an edge which is distinct from the node to which it points. This may be anti-ZK but its certainly something that would be easy to implement and provide valuable information - any graph database does this.
For those interested id look at ologs, https://en.wikipedia.org/wiki/Olog
Many thanks again to @emps and everyone else in the conversation.
As long as you're willing to add the edge name manually, and accept being limited to a single textual attribute, you can already do this using standard Markdown syntax:
My favorite search engine is [Duck Duck Go](https://duckduckgo.com "The best search engine for privacy").
Example above is from the Markdown Guide. Software support can catch up later, but adding this information now shouldn't break anything in current software. It would certainly make a path between notes better to understand.