[Zettel Feedback]: Poetry Is The Science Of The Real

Will

I'd like to present this note as an example of an atomic idea.
What do you think?

Do you have other comments or questions?

ZettelDistraction

@Will said:
I'd like to present this note as an example of an atomic idea.
What do you think?

Do you have other comments or questions?

A couple of comments

Emerson advocated "rearranged the prose into a poem." (L635)

Should this be

Emerson advocated "... rearrang[ing] the prose into a poem." (L635)

Years ago I read that "poetic truth presents a problem for philosophy," but I am unable to locate the reference.

Will

Thanks for the edit. Accurately recording quotes is something I'm working on, and this helps.

Our old, old esteemed fellow, Plato, thought poetry has no place in society because it is deceptive, harmful, and corruptive.

I noticed that you changed your avatar here back to the drawing of someone. Is it a drawing of you, is it a self-portrait?

ZettelDistraction

@Will said:
Thanks for the edit. Accurately recording quotes is something I'm working on, and this helps.

I noticed that you changed your avatar here back to the drawing of someone. Is it a drawing of you, is it a self-portrait?

It's a photograph of a portrait that my father pointed of me when I was around 17.

GeoEng51

@Will said:
I'd like to present this note as an example of an atomic idea.
What do you think?

Do you have other comments or questions?

```

---

UUID: ›[[202105201745]]
cdate: 05-20-2021 05:45 PM

tags: #writing #reading-strategies

Poetry Is The Science Of The Real

Will - I think it's a good example of an atomic note. The only question I have is this - how does the title relate to the content of the zettel? If your title is your thesis, then I don't see how the zettel makes a case for it. Nevertheless, I like the zettel. Perhaps it is the title that needs to be re-thought / re-written?

Mike_Sanders

@Will said: Do you have other comments or questions?

I understand the rationale for timestamps, but...

UUID:      ›[[202105201745]] 
cdate:     05-20-2021 05:45 PM

. for me its terribly unreadable due to the string length and lack of unit separation

. cdate seems redundant, I know it serves to make things more readable but its only needed because UUID is not that readable

. this schema seems to not deal at all with modification* times

Why not roll it all into a single spec?

filename: yyyy-mm-dd-hh-mm-ss-milli-suffix
uuid:     yyyy-mm-dd-hh-mm-ss-milli-suffix
mdate:    yyyy-mm-dd-hh-mm-ss-milli // date of last modification

or...

filename: yyyy.mm.dd.hh.mm.ss.milli.suffix
uuid:     yyyy.mm.dd.hh.mm.ss.milli.suffix
mdate:    yyyy.mm.dd.hh.mm.ss.milli // date of last modification

Having said all that, the card itself looks great.

* modification times:

char *getfilemod(char *fname, char *s, int z) {

  /*
  #include <sys/stat.h>
  #include <time.h>
  */

  memset(s, 0, z);      // z is typically around 30-50 bytes
  struct stat attrib;   // structure upon which to overlay results
  stat(fname, &attrib); // fname is the name of the file
  strftime(s, 30, "%Y.%m.%d-%H:%M:%S", localtime(&(attrib.st_mtime)));

  return s; // output the input string as a pointer with embedded dates

}

Will

@GeoEng51 said:
The only question I have is this - how does the title relate to the content of the zettel? If your title is your thesis, then I don't see how the zettel makes a case for it.

Thanks for this observation. On reflection, you are right that the title doesn't reflect my thesis. I might have in a prior incarnation of this note. The note has been refactored multiple times but the title has remained the same. This points to a lesson; editing the note probably will lead to the need to edit the title to keep the title synchronized with the note.

The author's quote enamored me - Poetry is the "science of the real" (L249) initially, and I never went back to review it.

Two title candidates I came up with, and I'm favoring number two. Do you zettelnauts have a suggestions.

1. # Vasulating poetry and prose
2. # Prose morphs back a forth towards poetry

Will

Thank you for your comments. They have sparked the idea of maintaining the mtime of every note.

@Mike_Sanders said:

I understand the rationale for timestamps, but...

UUID:      ›[[202105201745]] 
cdate:     05-20-2021 05:45 PM

. for me it's terribly unreadable due to the string length and lack of unit separation

. cdate seems redundant, I know it serves to make things more readable but it's only needed because UUID is not that readable

I agree, and you are right about the redundancy. The UUID has become more readable over time. Honestly, there are not too many times I, as the end-user, concern myself with the creation date/time of a note. I'm more interested in the ideas. These two lines are in the YAML, which is not strictly supposed to be human-readable. It is there to facilitate programming and conversion. This is how I use the YAML front matter, which disappears and is consumed during conversion.

This is an example of conversion. The YAML header does not print.

---

. this schema seems to not deal at all with modification* times

Why not roll it all into a single spec?

This is timely. I'm in the early stages of a side project where I'm looking at creating an idea explorer and have been confronted with the need to track modification times.

I see the value in using a single spec, but I wonder about the filename being part of that single spec. Isn't it more human-friendly to see note titles in a file list?

What language is this? I'm a beginner Pythonista, so I kind of understand what is happening here.

* modification times:

char *getfilemod(char *fname, char *s, int z) {

  /*
  #include <sys/stat.h>
  #include <time.h>
  */

  memset(s, 0, z);      // z is typically around 30-50 bytes
  struct stat attrib;   // structure upon which to overlay results
  stat(fname, &attrib); // fname is the name of the file
  strftime(s, 30, "%Y.%m.%d-%H:%M:%S", localtime(&(attrib.st_mtime)));

  return s; // output the input string as a pointer with embedded dates

}

Mike_Sanders

@Will said: I agree, and you are right about the redundancy. The UUID has become more readable over time.

Yes sir, didn't mean to imply anything was off, but rather with a tweak or two, you might be able to gain greater readability from the err... 'manifest ?' you've created (not sure what if anything you've named it).

> This is an example of conversion. The YAML header does not print.

Ahh, ok I understand now. I don't have access to a Mac & The Archive so, can only watch from the sidelines...

> This is timely. I'm in the early stages of a side project where I'm looking at creating an idea explorer and have been confronted with the need to track modification times.

Now that sounds nifty. Looking at the level of fluency I see in your code, I bet you can knock this 'out of the park' .

> I see the value in using a single spec, but I wonder about the filename being part of that single spec. Isn't it more human-friendly to see note titles in a file list?

What I failed to describe was 'suffix', let me circle back & redescribe what I'm attempting to convey. The filename in my thinking (already using cdate - a decidedly good thing) ought to be encoded with unit separators. But first the ISO standard, (don't have the link just at the moment), is in order of decreasing magnitude...

year > month > day...

So all is up to snuff there (mdate can be used elsewhere). Where I feel it could be tightened up is with the use of delimiters to demarcate 'fields' in the timestamp string. Further if those fields used '.' (a dot) to separate tokens just as we already do with file extensions (.txt, .md, etc) the string will achieve -total- uniformity, consider...

yyyy.mm.dd.title.ext

Now we can extract a given field without any fuss (here & below I'll use the standard 'cut' utility)...

echo 2023.01.01.title.md | cut -d . -f 1-3 #      date: 2023.01.01
echo 2023.01.01.title.md | cut -d . -f 4   #     title: title
echo 2023.01.01.title.md | cut -d . -f 5   # extension: md

Imagine a directory with these 3 files...

2021.01.01.house.jpg
2022.01.01.report.xls
2023.01.01.project.md

Now, one could use the dot delimiters like so...

#!/bin/sh

FILTER="$(ls | grep -i ^[0-9])"
CDATES="$(echo "$FILTER" | cut -d . -f 1-3)"
TITLES="$(echo "$FILTER" | cut -d . -f 4)"
EXTS="$(echo "$FILTER" | cut -d . -f 5)"

clear

# because screen writes consume so many cpu cycles,
# we'll only write to screen once via a here-doc:
# https://en.wikipedia.org/wiki/Here_document

cat <<END

  here are the items we talked about...

  $TITLES

  the dates vary considerably...

  $CDATES

  oh, and here are the extensions...

  $EXTS

END

# eof

> What language is this? I'm a beginner Pythonista, so I kind of understand what is happening here.

Vanilla (ie standard) c & will run as coded on any of Mac/Nix/Win. C has the singular distinction of being the only language whose libraries are intrinsic to every OS. But lots of interpreted languages ought to be plenty good enough & up to the task.