Generalized front-matter metadata

When I write notes, I just type my ideas and organically associate them with other concepts as they strike me. However, many notes benefit from having attached additional metadata in form of key-pair values – this is what front-matter is good for. I like to store title, created, for example, or link to a bibliography and similar stuff. Obsidian’s text editor is aware of front-matter in a way that it treats it syntactically differently, but, unfortunately, it does not go beyond that. I think that Obsidian could actually source metadata information from documents and make some useful things with them. Here are few ideas:

  • Source title property if provided and use it as a human-friendly document title instead of filename, because filename has its limitations (eg. they cannot contain certain characters etc.). This would be used in document listing and maybe it could be used for <title> tag in HTML export. There’s already a proposal for something like that

  • Source some front-matter field (eg. created date) field and sort document according to that.

  • Query notes according to their metadata, using some SQL-like language (example: select all notes where created is between X an Y and title begins with Z). This would allow us to treat our notes more like a databse records

  • Generate some table view with front-matter fields as columns

And so on. The possibilities are endless. Thinking this way could open a wide range of new workflows and ways one can process their knowledge base.

As you can see, I don’t have any concrete proposal. In fact, I’m deliberately framing this question so generally because I’d like to spark some discussion. The actual ways the front-matter metadata could be used for various goals are open to discussion. Do you have any ideas?


There are some other front-matter-related discussions:

10 Likes

But frontmatter is reserved for plugin use.
And there’s no detail yet that I’m aware of. I dismantled all mine when I heard that to avoid possible disruption in future.

Well, many of these functionalities I mentioned could be actually implemented as plugins (but, well, I don’t know how the plugin API looks like and what are the possibilities). But this does not mean that front-matter should be exclusively reserved for plugins — those would simply use relevant fields and ignore the others (they could be even namespaced to avoid potential name clashes). But in the end, users should be the ultimate masters and they should decide how front-matter should be interpeted. Front-matter is already a sort of standard; pople are already using it for all sorts of things. For example, pandoc uses front-matter data for text processing.

Users can do what they want, but they ought also to be aware of potential clashes with plugins they might want to use.
The suggestion at the time was for the user front-matter section to come below the main front matter section but I’ve seen no further detail.

And, yes, front-matter is a standard. But in YAML rather than markdown. Usage has crept into markdown apps, but most have specified what works and how it should be used.

And how Obsidian will specify it has yet to be announced.

You’re right that many applications use front-matter for different sorts of things. But I’m not suggesting that Obsidian should make up yet another standard.

My idea was that Obsidian would not make any a priori assumtions about user’s front-matter structure, eg. It wouldn’t dictate any structure. That would be all left to the user’s confguration. For example, I could write some rule like “take created property and sort my files according to that field” or “take title field and use it as display name”. I could also choose different field, like name or headline. But you get the point. By default, there would be no configuration, no assumption about YAML structure and therefore no clashes.

If there was clash with some plugin, user could either (1) disable that plugin or (2) rewrite their own configuration to avoid clash.

1 Like

This is exactly what it’s also being discussed in this forum post: being able to manipulate YAML data doncerning dates, and make Obsidian interpret it.

I strongly second this proposal

1 Like

Yes, something I would like to use is:

`—
Title: This is my paper title - it’s cool eh?

Links: [[Paper number two]]

Tags: [[bibliography]]
`—

I don’t even necessarily want anything special to happen, just want it to be hidden from preview mode completely.

You can do this with HTML comments.

<!-- tag: bibliography --> 

hides it from preview mode, but the tag would be searchable still.

2 Likes

That works great @EleanorKonik
The one funny thing is tag itself doesn’t work, but other “tags” work.

E.g.:
<!-- coffee: strong -->

works!

I don’t have an explanation but I’m glad you mostly got something working!

Related feature request: Date/number ranges within search/filter