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:
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.
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 know it’s a common feature request (see here and here and here) but i feel i have to summarize the topic:
we can’t rely on filesystem for dates (they get lost when moving/git synced), even worse we can’t have the date in the filename (diaries need at least yyyy-mm-dd_my_title or we need dates in other contexts). also titles can’t get read just by filenames, and if we want to reorder content, or export to other systems (i use Latex and Hugo, for example) there should be a “weight” field. Last the kind of note we are dealing with.
if Obsidian aims to become a “knowledge IDE” i think it would be better to declare “official” some of these fields. so that plugins can start to use them without inventing each an own system, like they are doing now.
we could have the calender Plugin ro read the “date” field, instead of the filename. bartender use the weight to sort files, everything would use the Title field (if defined) to show note’s title instead of the filename…
what i feel are the more requested standard fields are:
title (to be used everywhere, navigation, graph, links)
date (creation or generic date)
updated (when the note was updated)
weight (to sort with siblings)
type (to declare if the note has a specific template/bahaviour/model) to not be confused with tags which are more about the content.
or do you prefer these fields to be always custom defined by users and plugin developers?
i would prefer date because it’s more common in different systems (Jekyll, Hugo), but it’s ok also created… we can always process these files if needed
