Tags in the era of "YAML front matter abundance"

Lately, I found myself re-thinking my preferred context of the use of tags; especially after starting to usie Dataview to construct MOC-like notes. (I don’t call these exactly MOCs as the term deserves more than adding self-updating tables into the note. To me, a typical MOC would typically involve more manual labor.)

My current position is as follows: In the existence of YAML front matter as a significant part of the note content I feel that I can think of more efficient ways to use them + redefine the way I use tags. Preferably, this will be mostly in shape of ‘simplifying’ tags, maybe reducing the weight they carry for grouping/categorizing notes, shifting some of the weight onto some new front-matter keys?

Without getting into details of this effort yet, I wanted to check if anyone else in the community feels the same way: Do you think the the fact that front matter content is now much easier to query makes a difference in the way we use tags?


Sure we’ll do. As long as no one interferes with the few “tags” I really need. Here’s an example from an older publication:

title: 'Linux für Dich: Electronic Publishing mit Markdown'  
documentclass: 'scrbook'  # book (no abstract), memoir, …; default: article
author: 'Matthias C. Hormann'  
email: '[email protected]'  
editor: 'Matthias C. Hormann'  
publisher: 'Eigenverlag'  
copyright: '© 2015 Matthias C. Hormann. All rights reserved.'  
rights: '© 2015 Matthias C. Hormann. All rights reserved.'  
cover-image: 'images/cover-image.jpg'  
stylesheet: 'supportfiles/epub-style.css'  
css: 'supportfiles/style.css'  
highlighting-css: 'supportfiles/highlighting.css'  
date: '2015-08-07'  
lang: 'de'  
keywords: 'Markdown, Electronic Publishing, epub, PDF, HTML, how-to, Linux, Ubuntu, Mint'  
subject: 'Markdown, Electronic Publishing, epub, PDF, HTML, how-to, Linux, Ubuntu, Mint'  
header: ''  
footer: 'Linux für Dich: Electronic Publishing mit Markdown'  
numbersections: 'yes'  
#geometry: 'a4paper, portrait, twoside, includeall, nomarginpar, inner=20mm, outer=20mm, top=20mm, bottom=20mm, bindingoffset=10mm'  
#geometry: 'nomarginpar, twoside, bindingoffset=10mm'  
date-meta: '2015-07-28'  
pagetitle: 'Linux für Dich: Electronic Publishing mit Markdown'  
title-prefix: ''  
quotes: 'yes'  
crossrefYaml: 'supportfiles/pandoc-crossref-de.yaml'  
bibliography: 'literatur.bib'  
biblio-files: 'literatur.bib'  
#biblio-title: 'Literatur'  
csl: 'supportfiles/iso690-numeric-brackets-de.csl'  
description: 'Linux für Dich: Electronic Publishing mit Markdown'  
#toc-title: Inhalt  
lof: 'yes' # List of Figures  
lot: 'yes' # List of Tables
lol: 'yes' # List of Listings
#abstract-title: Kurzübersicht  
#abstract: |  
# In der Reihe "Linux für Dich!" findest du praxisnahe Tipps und Tricks für den alltäglichen Umgang mit deinem Linux-System.
# In der Ausgabe "Electronic Publishing mit Markdown" wird eine hocheffiziente Arbeitsumgebung für Autoren beschrieben – von der Installation benötigter und sinnvoller Programme bis hin zur #Erstellung fertiger Dokumente als E-Book, PDF oder HTML-Dokument.
# Das Buch wendet sich an Autoren, die unter Linux (Ubuntu oder Mint) arbeiten und sich zielgerichtet möglichst ohne Ablenkung aufs Wesentliche konzentrieren wollen: Das Schreiben – und die effiziente Weitergabe ihrer Texte über verschiedenste Medien. Angesprochen werden Studenten, Lehrende, Ersteller technischer Dokumentationen und professionelle Autoren.
# Ausgehend von einer einfachen und vor allem *lesbaren* Textdatei wird der Weg bis zum fertigen Buch (oder einer Anleitung wie dieser) erklärt – zielgerichtet, ohne Ablenkung, reproduzierbar, möglichst automatisiert bis zum fertigen Dokument in den verschiedensten Ausgabeformaten.
# Es wird erklärt, welche Werkzeuge und Programme man *wirklich* braucht und wie sie genutzt werden:
# * *Geany*, ein Texteditor (es kann aber nahezu jeder andere verwendet werden)
# * *Markdown*, eine einfache Syntax für Textdokumente
# * *JabRef*, Software zur Verwaltung von Literaturangaben und Zitaten
# * *LaTeX*, eine Satz-Software, die »im Hintergrund« für schöne Ausgabe sorgt
# * *Pandoc*, das »schweizer Armeemesser« unter den Dokumentenkonvertern
# * *Calibre*, Software zum Verwalten, Anzeigen und Bearbeiten von E-Books
# * *Freeplane*, eine Mindmapping-Software zum visuellen Gedankensammeln


Talk about abundance. :grinning_face_with_smiling_eyes:

But yes, since Dataview I find myself re-using lots of the Pandoc/LaTeX YAML fields, and several new. Makes things so easy …


I’ve been asking myself this question. I like also the way it makes a clean note in View mode. My understanding is that YAML does not appear in the normal Obsidian search, only Dataview. That seems an important limit. Has that been your experience?

I think I’m accidentally using both at the same time! Not YAML front matter per se but the Key:: Value pairs similar to YAML for use with Dataview.

I use #watched:: [[Burn After Reading (2008)]] with [[Akash]] a lot in my daily notes, sometimes for YouTube videos, but mostly for films. And here watch becomes the key for Dataview while at the same time being a tag for Obsidian and other markdown apps. There’s discussion on GitHub regarding delimiting these Key:: Value pairs in some way for quite a few benefits, one of them being of significance to me in that it will end up allowing a more natural way of writing so I can write I #watched:: ABC... or for tracking any number of parameters in our daily notes. One caveat with using it like this, right now, is having multiple tags in the same file as a key causes only the last one assigned to be fetched by Dataview. But that’s going to change as well since the dev has responded positively to implementing the feature to return such values as a list instead. I’m not sure if YAML syntax allows duplicates like that but to my workflow, this duplication is quite useful.


I did not try but YAML should appear in the normal search function IMO. Good point. I’ll try…

So are you using these in the body of the (rather than in front matter)?

@Moonbase59: that front matter content is crazy for me :)) How do you keep up with it?

Yes. Some of my notes have a lot of front matter like in case of the actual movie note, it has around 30 fields. But that’s all filled with Templater fetching data from the OMDB api including all cast info, genre, year, etc.

But for my daily notes, there’s no structured way to include something since the item I’m tracking can change in any random way. Some days I #watch a lot of stuff, other days I track my fathers BloodSugar or my #workout. Those can’t go in a template since I want the flexibility to have an infinite amount of those available to use. That’s why instead of the YAML, they go in the note body, almost in natural language. Below is a real example of it from one of my recent notes.

Father got his HbA1c test report back. HbA1c:: 8.1

It’s mainly for production, i.e. making a book, a PDF or an ebook, thus it gets added rather late in the process, except a few fields. So I can manage :wink:

I’ve been using Markdown, Pandoc and LaTeX for many years, and only discovered Obsidian a few months ago. So I’m still pondering if I should include all this in a big vault.

If Obsidian doesn’t become a clicky-glitzy monster like Word, LibreOffice or others, with WYSIWYNG (what you see is what you never get), but stays a fast, well-focused raw text indexer, I might move over completely.

1 Like

do you guys have any guides on how to manage yaml. for tags at least there is a central way to see them in side pane, but yaml is very hard to remember and use. is there any method in software develpment world that be helpful to develop some yaml front for my vault? i use yaml for my projects and books with some success but beyond that it is a huge mess

1 Like

I agree. I am yet to come up with a practical way to manage/use yaml effectively

1 Like

This is all I do for YAML:

creationdate: {{date}}
creationdatetime: {{time}}
zettelkasten: {{date:YYYYMMDDHHmm}}
- Triage

This is just using the built in plug-in for templates in Obsidian. Each time I create a note (Called “standard note” in my system) this is what gets placed at the top. When it gets created the {{}} are replaced as the formatting implies. The only slightly tricky one is the zettelkasten ID, which I use as a compromise between having it in the title of the note and not having a zettel ID at all. (I find having it in the title of the note makes it so tedious to neatly link in note contents; I have to use a | if I want just the name to display in a link).

Aliases are useful if I ever start using the synonym or acronym of a note that already exists. You just add a list of entries with a single square bracket: [Alias]. Obsidian will then offer that as an option for “Unlinked Mentions” and wikiinks around that new word will link back to the note.

Tags just work like tags, but without the use of a #. (Sub-tags also work).

I don’t really use frontmatter for the way it was really intended, I think. I mostly just use it for that little bit of alias functionality and to clean up my notes and put all the metadata in one place. It allows me to go in and edit metadata quickly, since it is always at the top, but then know all of my actual content appears right below the frontmatter.


yes, aliases are best part of yaml imo. i use them extensively as the real title and give the note title some code (like above) to just be short and unique. i had some problems with windows max character limit in the past so that is my way of not making happedn anymore.

I think limiting yaml is not the way though. the power of yaml is that it is unlimited and fully customizable. i just wish i had a standard system to make them and keep track of them so that i can use its full potential

1 Like

There is certainty a lot of power in YAML. But power is just equivalent to options, in my opinion.

I don’t limit my YAML use by any means. Honestly, I just don’t have any use for it beyond aliases and a tidy way to format my metadata. But I also pretty much just use Obsidian exclusively for notes. I don’t have a lot of metadata to attach to a note.