Public Digital Garden - Metadata
A reference list of metadata for public digital garden notes.
This is the metadata system devised by me, Caleb, specific for this particular website; it is not one-size-fits-all. But I’m very happy with how it fits me.
You should probably first read Public Digital Garden - Terms of Service for why I’ve taken so much care to design a metadata system!
Common
- Title
- ideally we should grok as much information from the note title itself as possible.
- Description (optional)
Title and description are also used for SEO preview cards.
Temporal
🥬 Modified date
All notes have a “last modified date” field. It is continually automatically updated.
This is a good indicator of my recent interests, of the particular notes that I have made modifications and developments to.
If you had accessed the note prior to the last modified date, this will also inform you that the note content has definitely since been changed.
It is also useful to hint at the “hotness” or “activity” (or “coldness” or “inactivity”) of a note. It’s not a perfect hint, though, since it only tracks note content modification, not reads nor modified backlinks. See that:
- Developing/budding notes can be cold, if untouched for a long time (should we add a
🧊 FROZENbadge?). - Mature notes can be hot. Sometimes it’s really just a small typo correction and not any meaningful change.
🥬 FRESH badge is given to notes modified within the past week (7 days).
🐣 Published date
A few select notes have a “published date” field. It is set on-demand, once. This is the fixed date when I feel a note’s contents is mature enough and “ready for release”.
Every note with a published metadata date field implicitly has the “Published” attribute. Published notes are usually more refined and mature. While 99% of [[these notes are primarily for my eyes]] (broken link, note not found) , Published notes are almost always authored and processed content with an audience in mind. Since the audience expects higher quality from Published notes, the audience should also have more care when I’ve put out revisions and disclaimers.
The published date is also kind of an indicator of “freshness” or “hotness”, more stable than the modified date. If a note was recently published, you the audience should be more provisional and cautious; I may have reached a confidence threshold, but it still may be revised. On the other hand, a note that was published a long time ago may also contain my outdated views.
Just because a note is “Published”, doesn’t mean that it’s locked from later edits. So far, all my published notes have received modifications after their published date!
🐣 NEW badge is given to notes published within the past 1.5 months (45 days).
Many gardens have a “created date” field. I store it in my note, for my own private use, but I personally don’t find it that semantically meaningful when exposing to public. In my notetaking style, notes are often created way before they are meaningfully used or developed on.
Word count
Atomic notes should be 200 words or less. Published notes are also usually more Longform, i.e. more than 1000 words.
Word count shouldn’t be an indicator of note maturity. A short note can be very refined, while a long note could just be long mindless ramblings. Simply, it’s always an indicator of size/volume.
| Badge | Word Count |
|---|---|
• ATOM | < 200 |
▯ 1PAGE | 200-500 |
◨ 2PAGES | 500-1000 |
◈ LONGFORM | > 1000 |
Epistemic metadata
Using the status field, we declare epistemtic statuses. This field is the BEST indicator for note maturity, effort and confidence. In this order:
🌱 Stub
You’ve seen it on Wikipedia. Some gardens use the terms “seed” or “seedling.”
🌱 STUB is used for notes that are very very barebones. It’s useful to have empty placeholder notes, especially with tools like Obsidian where we can use backlinking and fuzzy name searching.
But practically, stub notes have some random content or links that I throw into the note for future development. The content and resources have NOT been vetted or processed, so be extra indifferent about the content of stub notes.
🚧 WIP
Some gardens use the terms “budding” or “sapling”.
🚧 WIP is an abbreviation of Work-In-Progress. It is used to mark notes that are developing.
Of course, a core pillar of digital gardening is that every note is forever developing and never finished. But like stubs, it’s useful to explicitly declare that a note is not mature, and shouldn’t be received as mature, especially when it is unclear. (Of course, when in doubt, always assume that a note is not mature!)
🏁 MVP
🏁 MVP is an abbreviation of Minimum Viable Product. It’s a business term for goods that are “minimum viable” and barely meets the absolute baseline requirements for a product to satisfy core consumer needs.
The specific “minimum viable” requirements for each note is kind of arbitrary and “vibes”. It really depends on the scope of the note. But here’s a three-step process of goals for commercial product development:
- 🏃♂️➡️ Functional
- ✅ Consistent
- 🚀 Efficient
Once a note crosses the “🏃♂️➡️ functional” boundary, it’s marked with 🏁 MVP. The note is then continually tweaked to be consistent with requirements, and then finally efficient with information density. Then we take the 🏁 MVP status off.
It’s a matter of content development maturity, not even spelling or grammatical corrections. A note in 🏁 MVP is not always the same as a Published note, since certain MVPs may need months more of refinement before I consider it published! In the Efficient step, entire sections of paragraphs could be extracted out or inserted in!
Most public digital gardens don’t have this status, and I think it’s super useful to mark a large set of notes that fall into this in-between category, between “developing” and “evergreen”.
No status
Notes have an undefined status by default. This in of itself is an epistemic status.
Other gardens use the terms “evergreen”, [[Evergreen Notes]] (broken link, note not found).
All notes without status can be assumed to be evergreen by default. Unless I create some sort of initial default 🍼 TRIAGE status, which is a lot of status tagging cognitive overhead to manage.
Sometimes it’s really clear that a note isn’t a stub or WIP or otherwise, then I won’t bother tagging it so. It’ll be like this for now.
🚨 Disclaimer
🚨 FYI is an abbreviation for “For Your Information”, but I picked “FYI” because DISCLAIMER or NOTICE were too long. Using the fyi note metadata field, it also indicates epistemic information, in parallel with the status field above.
I really like devonzuegel.com ↗’s epistemic statuses, but writing two sentences per note, one for effort and one for confidence, it’s just too much overhead for me.
So, instead, I just expose one fyi field to display a disclaimer for the specific note. On the authoring/tagging side, it’s extremely flexible to have freeform text for both confidence and effort or whatever disclaimer I need to put out. It’s great.
Relational hyperlinks
Most blogs organise their posts by chronology, sorting by recently published. In digital gardens and second brains, we prefer “Topography over Timelines” — “many entry points but no prescribed pathways”1!
Also, instead of tagging by topic (e.g. #tech, #writing), I’ve opted to follow Obsidian’s natural strengths, where every topical tag is instead a bi-directional associative link to a topic note. We take advantage of backlinks to expose the backwards-direction link! (still implementing backlinks here) So, a note would instead be linked to Technology.md and Writing.md, for example.
If a note has a link to another note, they should be bi-directionally linked. This gives rise to networked information, where each note is a node. Each node/note exists in the context of the notes that it is linked to.
Some (not all) relational note links also follow a structured hierarchy. This means that on top of being “just connected”, the nature of their connection has a specific semantic relationship.
- note has a parent (upwards)
- note has a child (downwards)
- note has a previous note (backwards)
- note has a next note (forwards)
- note has a sibling note (sidewards)
A child note has parent note(s)
Other gardens use the terms “category” and “collection”.
e.g.
- my
2025-07-30daily note has a parent, the2025-07monthly note. - “CSS Selectors” has a parent of “CSS”. “CSS” has two parents: “Web Dev” and “Coding Languages”. Both of these could have the parent “Technology”.
In my own private Obsidian workspace, I try to ensure that each note has a parent. More than any other metadata, the parent note provides the most context about what a note is. This can chain upwards like an ancestry of grandparents, great-grandparents, all the way to the root.
Crucially, a note can also have more than one parent. Certain notes have more than one obvious ancestor. This offers more flexibility than strict folder hierarchy, where each note cannot coexist in two separate directory locations at the same time.
Sometimes a note doesn’t have a parent. Sometimes its place in the network hasn’t been charted out yet. Sometimes it’s a one-off random note, that will never connect to anything else. It happens. This is an Orphan note.
A parent note has children note(s)
In reverse, a parent note has the metadata of knowing what children notes it has.
e.g.
- “CSS” may have multiple children, like “CSS tricks”, “CSS cascade specificity” and “Tailwind CSS”.
For some notes, they function purely as “indexes” that collects links to a bunch of related notes, without having much content in the index note itself. The community has termed this “MOC”, “Map of Content”, “Index note”, “Folder note”.
Some parent notes are “topic” notes
Some notes have an emoji associated with them. These are “topic” parent notes. They’re semantically of equal value to any other note. But usually these “topic” notes are the “index notes” we talked about, and they get a special emoji to make them stand out more. This website also styles their emoji onto their preview card stand out as well from non-“topic” notes.
Some parent notes have a “series” of children
Usually children of parent notes are unordered and un-sequenced. The order doesn’t matter for “Banjo”, “Lute” and “Harp” in the group set of “Stringed Instruments”. There’s no real sequence.
Sometimes, there is a clear sequence. Tuesday comes after Monday. Episode 1 comes before Episode 2. Prequel before sequel.
For these notes, it’s imperative that the children are listed in-order. The note cards are even given a counter! The series children themselves will also show the other notes in the series it belongs to, so it’s easier for people to jump around to desired notes in the related series!
📚 SERIES badge is given to notes where its children come in a series.
Previous / Next
Some note relations are of previous or next relationships. this helps to move you forward or backward through semantically related notes in order.
These are often used when it’s just 2-3 notes in order, that doesn’t justify its own parent series note. Nothing crazy here.
Conclusion
All of this implementation can be found on the open source code ↗ for this website!
Also, I reserve the right to make mistakes and mislabel the epistemic status of notes incorrectly! It happens, man. [[Discern everything]] (broken link, note not found)!