Summary of Thoughts on Metadata

rak1

I've spent many hours scouring through this forum picking up tips and tricks from a number of great contributors. I wanted to share my own thoughts on how to structure the headers of Zettels:

After much thought, testing and experimenting, here are the conclusions I came to for myself:

• Metadata are best kept within a YAML block at the top of the Zettel. This allows the data to be cleanly stripped when exporting from Pandoc, Typora, Marked, or other Markdown presentation tools.
• For simplicity, the metadata should contain: uid (within square brackets so that it's easy to read and clickable to instantly bring up a search for that same ID); date of creation (yyyy-MM-dd); and tags.
• Date should come after the uid on the same row (to save space)
• The "uid" key should be followed by two whitespaces (to align the value with the "tags" value)
• The header tag should follow the metadata block with one line separating the two

Sample:

---
uid:  [[202103041955]] 2021-03-04
tags: #tag1 #tag2
---

# My Header

Will

Here's what my YAML looks like currently.

Where @rak1 has # My Header, I have the note title as the first level.

I'm constantly stealing new and better ideas. Last week, I saw someone somewhere adding a people field to their YAML block, and I can see where this would be useful, hence the theft. I'm leaning towards having the date on the same line as the UUID to shorten the space used.

rak1

@Will said:
Where @rak1 has # My Header, I have the note title as the first level.

Same here, that's what I meant, actually. First level 1 header is the note title.

For people, I actually use @ within a tag, to denote a relationship with a person or organization: e.g. #@will or #@acmeinc. Not sure if this will prove troublesome from a compatibility standpoint, but so far, so good!

PS- @Will, I've taken a lot of inspiration from your past posts!

rak1

@rak1 said:

@Will said:
Where @rak1 has # My Header, I have the note title as the first level.

Same here, that's what I meant, actually. First level 1 header is the note title.

For people, I actually use @ within a tag, to denote a relationship with a person or organization: e.g. #@will or #@acmeinc. Not sure if this will prove troublesome from a compatibility standpoint, but so far, so good!

PS- @Will, I've taken a lot of inspiration from your past posts!

Another advantage of this approach is less space taken up:

• uid + date in the same line
• tags + people in the same line

Will

I worry about putting too much on one line.
YAML is a formal format that has an inline style that looks like this:

--- # Shopping list
   [milk, groceries, eggs, juice, fruits]

It has a very specific format.

I like the idea that the contents of the YAML header are hidden from Markdown previewers but I'm mainly exploring their use with pandoc.

Pandoc has only a few keys that it recognizes and I'm only early in this exploration.

What can I control with YAML header options in pandoc?
Learn YAML

rak1

@Will said:
I like the idea that the contents of the YAML header are hidden from Markdown previewers but I'm mainly exploring their use with pandoc.

Pandoc has only a few keys that it recognizes and I'm only early in this exploration.

I can certainly see the benefit in following YAML a bit more strictly, but personally I'm using the YAML block to strip out the metadata in exports/previews. I'm not super concerned with syntax or structure, but have aimed to keep my metadata as useful as possible for myself while maintaining some aesthetic value...

Would love to hear more about what your goals with YAML are!

Will

I suspect that the keyword/variable pairings can be used in exports/previews to add fine-grained nuances.

And yes, I've not been too concerned with syntax or structure but want to explore the opportunities. One particular use case is when printing. I want the UUID to print on the same line as the first heading, only right justified. A preprocessor like pandoc or Marked2 could read the YAML and perform the right justification of the UUID given the right template commands.

rak1

@Will said:
And yes, I've not been too concerned with syntax or structure but want to explore the opportunities.

I'd love to learn more about what you learn through this process...

henrikenggaard

@Will said:
And yes, I've not been too concerned with syntax or structure but want to explore the opportunities.

A benefit of sticking to some structure or syntax is that the structured data can then be processed using some programming language.

I keep a note for each project* I am currently working on. In each of these notes I have a "progress" field which I set the the percentage "done" that I feel they are. I then extract these and show a little progress bar to motivate me:

I keep this list on my "homepage" for my note collection.

* Project in the "Getting Things Done"-sense: more than one step.

Will

@henrikenggaard said:
A benefit of sticking to some structure or syntax is that the structured data can then be processed using some programming language.

Great example!

Yes, sticking to a standardized syntax for metadata helps process the workflow, as your example clearly shows.

I keep a note for each project* I am currently working on. In each of these notes I have a "progress" field which I set the the percentage "done" that I feel they are. I then extract these and show a little progress bar to motivate me:

I keep this list on my "homepage" for my note collection.

Beautiful. I'd not thought about keeping a tally of the percentage complete for tasks, but this is 100% doable.

Here is the list I keep on my "homepage" to help motivate me.

Zettelkasten Statistics
       ★★★★★
1801 - total number of notes
369247 - total word count
       ★★★★★

** 5 - 2do’s **
** 13 - notes in the INBOX **

0 new notes were created yesterday.
23 notes modified in the last 24 hours. 

[1 notes created on 03/07/2020](thearchive://match/›[[20200307)
[1 notes created on 03/07/2019](thearchive://match/›[[20190307)

ctietze

To get "visual" progress bars, y'all may want to try https://changaco.oy.lc/unicode-progress-bars/ and copy your favorite over

These are my favs:

■■■◧□□□□□□□ 32%
■■■▨□□□□□□□ 32%
■■■▥□□□□□□□ 32%
████░░░░░░░░░ 32%

rahuljha

@Will said:
I worry about putting too much on one line.
YAML is a formal format that has an inline style that looks like this:

--- # Shopping list
   [milk, groceries, eggs, juice, fruits]

It has a very specific format.

I like the idea that the contents of the YAML header are hidden from Markdown previewers but I'm mainly exploring their use with pandoc.

Pandoc has only a few keys that it recognizes and I'm only early in this exploration.

What can I control with YAML header options in pandoc?
Learn YAML

you can also learn HTML programming Language

rahuljha

@Will said:
I worry about putting too much on one line.
YAML is a formal format that has an inline style that looks like this:

--- # Shopping list
   [milk, groceries, eggs, juice, fruits]

It has a very specific format.

I like the idea that the contents of the YAML header are hidden from Markdown previewers but I'm mainly exploring their use with pandoc.

Pandoc has only a few keys that it recognizes and I'm only early in this exploration.

What can I control with YAML header options in pandoc?
Learn YAML

you can also learn HTML programming Language

crossskatee

@Will said:
Here's what my YAML looks like currently.

Where @rak1 has # My Header, I have the note title as the first level.

I'm constantly stealing new and better ideas. Last week, I saw someone somewhere adding a people field to their YAML block, and I can see where this would be useful, hence the theft. I'm leaning towards having the date on the same line as the UUID to shorten the space used.

I like the idea that the contents of the YAML header are hidden from Markdown previewers but I'm mainly exploring their use with pandoc.