Multiple Dates in One Zettel

GeoEng51

I'm getting to the point in working with my ZK that I have re-visited certain zettels several times - whether that is just to read the zettel or to "finish" it (if it was still in rough form, having the tag "#unfinished"), or to add information from new sources. There could be numerous reasons.

My point, though, is that I don't always want to update (or "refactor") a zettel; sometimes I just want to (legitimately) expand it. I've started adding dates to the new material and some zettels now appear as:

1. Date 1 (UUID) with original material.
2. Date 2 with new material.
3. Date 3 with even newer material.

This approach has an added advantage in that it allows me to see a progression in an idea - what did I write initially and what are my thoughts now?

Has anyone else implemented this practice? If so, what is your experience with it? Whether you have or not, do you see any potential benefits from doing this? Any drawbacks?

andang76

I'm not at this point of my experience (i've discovered zk only in october). I think that if you find useful... why not.

It might make sense in some cases.
Highlighting a difference, a progress could be a piece of knowledge itself.

I wouldn't do that every time, howewer. In other cases integrating two contents in a single block could have its own value.

Mike_Sanders

Using a similar method here. Sort of a log with descending history & date at the leftmost (mimics Cornell notes) that provides a quick & easy to visually scan 'in note index'. Unix man pages are laid out in the same fashion. Probably not for everyone, but I'm happy with it.

Syntax is...

date one-line-summary
     line 1
     line 2
     line nth

Example...

2023.01.02 rolled back last changes pending more research

           Lorem   ipsum   dolor   sit   amet, consectetur
           adipiscing   elit,   sed   do   eiusmod  tempor
           incididunt  ut  labore  et dolore magna aliqua.
           Risus  quis  varius  quam quisque id diam. Enim
           tortor at auctor urna. Lectus nulla at volutpat
           diam ut venenatis tellus in

2022.12.01 changed aspect ratio

           Cursus  turpis  massa  tincidunt  dui ut ornare
           lectus. Dignissim convallis aenean et tortor at
           risus  viverra  adipiscing.  Egestas  fringilla
           phasellus  faucibus  scelerisque eleifend donec
           pretium vulputate sapien. Pellentesque sit amet
           porttitor eget dolor morbi non.

Edit: another variant...

2023.01.02 rolled back last changes pending more research
           Lorem   ipsum   dolor   sit   amet, consectetur
           adipiscing   elit,   sed   do   eiusmod  tempor
           incididunt  ut  labore  et dolore magna aliqua.
           Risus  quis  varius  quam quisque id diam. Enim
           tortor at auctor urna. Lectus nulla at volutpat
           diam ut venenatis tellus in

2022.12.01 changed aspect ratio
           Cursus  turpis  massa  tincidunt  dui ut ornare
           lectus. Dignissim convallis aenean et tortor at
           risus  viverra  adipiscing.  Egestas  fringilla
           phasellus  faucibus  scelerisque eleifend donec
           pretium vulputate sapien. Pellentesque sit amet
           porttitor eget dolor morbi non.

Mike_Sanders

@andang76 said: ...progress could be a piece of knowledge itself.

Yes, you nailed it, at least in my thinking.

ctietze

@GeoEng51 I do have some (very few) notes where I added IDs further down to act as jump-marks. Eventually I seem to extract a new Zettel from these, but technically, it works, yes.

If you imagine your whole Zettelkasten in 1 large file instead of spread out, every ID would be a jump-mark of sorts. (The discussion about that approach stems from the old comment system before we had a forum, so no easy search or linking, unfortunately.)

zk_1000

I think I have a link relevant to @ctieze 's comment: https://forum.zettelkasten.de/discussion/1508/zettelkasten-vs-one-big-text-file
but there is more on this.

micahredding

@GeoEng51 said:
1. Date 1 (UUID) with original material.
2. Date 2 with new material.
3. Date 3 with even newer material.
...
Has anyone else implemented this practice? If so, what is your experience with it? Whether you have or not, do you see any potential benefits from doing this? Any drawbacks?

I've ended up with something like this on accident, as I've circled to and rediscovered certain ideas from different vantage points. When I discover the connection, I can try to bring it together like this.

I like the idea of a log, or history of development. However, in most cases, what I end up doing with new material is refactoring the note. So I might end up with Date 1 as a sub-concept, Date 2 as a sub-concept, Date 3 as a container concept pointing to Date 1 and Date 2. Or reversing that, Date 1 may end up as a container for more refined concepts in Date 2 and Date 3.

It just depends on the concepts themselves. And I find using these additions to drive refactoring to be a very valuable process.

GeoEng51

@micahredding said:
I've ended up with something like this on accident, as I've circled to and rediscovered certain ideas from different vantage points. When I discover the connection, I can try to bring it together like this.

I like the idea of a log, or history of development. However, in most cases, what I end up doing with new material is refactoring the note. So I might end up with Date 1 as a sub-concept, Date 2 as a sub-concept, Date 3 as a container concept pointing to Date 1 and Date 2. Or reversing that, Date 1 may end up as a container for more refined concepts in Date 2 and Date 3.

It just depends on the concepts themselves. And I find using these additions to drive refactoring to be a very valuable process.

Thanks for sharing and I know exactly what you mean. When you cycle back through notes with new material, sometimes it makes sense to refactor everything (in different ways) and sometimes I like the "history of development" approach. I thought I'd bring it up in case there were some people who felt they needed to always refactor, when that might not make the most sense.

Sascha

I see the UID as truly universal. You can give any item an adress that you want to refer to in a software agnostic manner. I give research projects in my research file managed by taskpaper UIDs. Then I refer to it from my ZK. I also give footnotes IDs (date+word e.g. 20230119sample) using the markdown synthax.

So, anything that I want to refer to has an address.

Has anyone else implemented this practice?

I use a similar approach when I do versions of aphorisms. Though, I just give them letters. So, if I'd refer to a specific version as "See version B of aphorism x [[202301190133]] as an illustration of this principle". But I could use just another ID. I just like the letters more.

If so, what is your experience with it?

The above practice is not exactly what you are doing. But the general habit of asigning UIDs to what I want to refer to is pretty useful to me in many circumstances.

Whether you have or not, do you see any potential benefits from doing this? Any drawbacks?

I personally do see neither. It doesn't harm. That I am pretty sure of. But I never had any benefits of versioning of my level of understanding. I end up ignoring everything but my best=current understanding.

Tochinet

Potential drawback : it makes the note reading a bit less obvious. I mean, do you want to see IDs at all ?

I personally use Joplin, that allows a nice automatic sync between phone and different computers, and hides the UUIDs from me (they are its internal .md filenames). Maybe not ideal either, but it allows to make a link between notes in 2 click (right-click on note, select copy MD link, and Ctrl-V.)