Master thread for YAML frontmatter improvements

[alev]

I’m not sure if the devs are still watching this thread…but one idea could be to allow block-level metadata (or inline metadata that applies to the block where they are). The goal would be to enable block queries similar to those enabled by Tana supertags.

[zettelstraum]

I really like the suggestions in this thread but would also love to see something basic added: With the current system, I only have the option to see all metadata or none.

What I would like to do is define what I can see even though metadata iss switched off.

Why?
Because I put my tags into YAML and I also have a lot of other stuff there in many files: csslass info and plugin related stuff.

This latter type of metadata I do NOT want to see in my notes all the time. The tags I DO want to see always.

It would be great to have a toggle that can be put inside the editor that switched betwen two or even three user defined sets of things to display.

[holroy]

@zettelstraum

With the current system, I only have the option to see all metadata or none.

What I would like to do is define what I can see even though metadata iss switched off.

While this feature request lives it life, I would like to point out that using CSS, we can hide/show tags, aliases and other frontmatter.

Reduced frontmatter in Reading view

This should be doable with some CSS. If you turn back on the showing of the frontmatter, it shows all frontmatter, but you can hide stuff you don’t want. Here is an image showing source text, reading view and corresponding DOM elements related to the frontmatter display. [image] What we can see here is that tags and aliases have the CSS classes of frontmatter-section and respectively mod-aliases and mod-tags, and that the other lines just have the frontmatter-section. So if we generally hid…

Details given in my post above.

[zettelstraum]

Oh!

This is VERY helpful. It’s an elegant, well-working solution. THANK YOU!

[flatline]

Borrowing liberally from Metadata Menu, I would love to see YAML classes. Something like this:

yaml_person.md

---
name: {String}
email: {email}
age: {int}
---

That can be loaded into a file dynamically with the built-in template plugin, e.g.

{yaml_person.md}

Becomes:

---
name:
email:
age:
yamlClass: yaml_person
---

Now let’s say I call that new file John add some metadata to it:

---
name: John
email: [email protected]
age: 25
yamlClass: yaml_person
---

It would be cool if, as other mentioned, there was some kind of inline typing going on. E.g. I could say he works at a company, and show an inline list of notes tagged #company, much like we do with Metadata Menu.

Let’s say I then revisit my vault 6 weeks later and decide that all person notes need a birthday. I would update the yaml_person.md file as follows:

---
name: {String}
email: {email}
age: {int}
dob: {date}
---

It would be amazing if Obsidian now cycled through all the notes that had the yaml_person class and added the dob, i.e. John.md becomes:

---
name: John
email: [email protected]
age: 25
dob:
yamlClass: [[yaml_person]]
---

This would save incredible amounts of rework.

If there was then a function to move YAML up or down in the stack, or indent it, you’d be able to restructure your notes on the fly without going back.

You could then probably also do some really great things with inheritance and YAML, where say type: coworker extends yaml_person like so:

yaml_coworker.md

---
company: [[file]]
role: {String}
yamlExtends: [[yaml_person]]
---

And when you hover over [[yamlExtends]], you’d get a preview of {name, email, age}.

So if you were to then change the yamlClass of the note john.md, it would turn into:

---
name: John
email: [email protected]
age: 25
dob:
company: [[acme]]
role: [[design]]
yamlClass: [[yaml_coworker]]
---

[ashish]

Is there any timeline from Obsidian team regarding this?

[jeetsukumaran]

Interesting concept. This would provide some of the functionality of supertags in Tana

[aristot]

Feature: Schema definition and validation

Was this discussed anywhere? I can’t find something.

Use case: I imagine many people apart from me use different frontmatter for different types of notes.

E.g.

Book note:

title: Anything You Want
author: Derek Sivers
summary: A very short, easy to read, beautiful, honest book. Derek shares some of the lessons he learned through his journey of creating, growing, and finally selling his company CD Baby. The book feels incredibly honest and simple. Just read it. You will smile many times, and nod your head in agreement several others.
image: anything-you-want.jpg
type: book-notes
date_read: 2022-11-15
first_published: 2011
isbn: 9781991152398

Generic note:

uid: 2023-05-02-0945
title: A business needs 10x technological improvement to have real monopolistic advantage
type: note
tags: book-notes/zero-to-one

etc.

What I would like is be able to define what key-value pairs should be present for each note type, and what data type should the values be. E.g.:

• type can be any of : note, draft, book-note, journal, reference (so it’s basically an enum).
• date_read should be a date
• isbn should be an int

Related github repos:

• GitHub - docs/frontmatter: ☝️ A fast frontmatter parser for Node.js with schema-based validation
• GitHub - JulianCataldo/remark-lint-frontmatter-schema: Validate your Markdown frontmatter data against a JSON schema — remark-lint rule plugin

I’d love to know if this is of interest to other people, and hear your ideas/feedback.

Edit

Related threads/comments:

• Check that a note conforms to a specific template