Folks,
There are currently many different ways to bring in additional data to our notes. Apart content data (i.e., links, tags, etc.), there’s currently at least three:
-
YAML front-matter
--- field1: value field2: - value2 --- -
Dataview inline:
[field:: value]
I want to use these fields to keep track of:
- links to vault-external resources (files/directories outside the vault)
- production status of a note
- list of actions that a note might need (“revision”)
- etc.
All things that are not in content, and are not actually content. In my mind, these are not just “metadata” in the broad sense of “data available for queries”, but actual data about the content, but that is not content itself.
I firmly believe that a mechanism to express this data at both a file-scope and a subsfile scope (e.g., list items or task items) are critical to many of our flows and maintenance.
I am very confused as to which we, as users, should be using.
On the one hand, there have been comments (from developers) that suggest that my use of the YAML front-matter is not encouraged: “the YAML block was intended to store per file settings/data of plugins”. So not actually userspace metadata?
Alternatively a number of places recommended that users store metadata using Dataview inline metadata fields ( (2) above), perhaps wrapped in Obsidian comments to hide them from the content:
%%
field1:: etc.
%%
However, the Dataview roadmap shows that there will be pushback against this as well! Furthermore, it should be noted that the dataview inline syntax does NOT allow dictionaries, which are very useful:
---
project-artifacts:
- title: "Manuscript"
directory: "/home/user/docs/project1/manuscript"
open-command: "gnome-terminal"
- title: "Development"
directory: "/home/user/software/project1/"
open-command: "nvim src/*.tex"
- title: "Products"
directory: "/home/user/software/project1/dist"
open-command: "rf product/*.pdf"
---
I recognize the line for “abuse of mechanism” is crossed when we express content in the metadata. And I’m sure there are fuzzy cases. But let’s assume that I am clear on this, and just want to express “metacontent metadata”. And I want express this on a per-note basis (per-task/list item has to be Dataview inline), and want support for lists and dictionaries (and links!).
So, I would love to hear from insiders/developers/etc. on what mechanism do they suggest users use to maintain metacontent metadata on their notes? Preferably something that supports more than simple strings, but also lists and key-value pairs?
(I’m assuming YAML front matter for things like, for e.g., pandoc compile settings will continue to be kosher in the long run?)