Questions about frontmatter

I hope this is the best place to ask this question. I’ve watched a few videos by different people to see how they are using obsidian and I have a couple questions about front matter.

  1. Different approaches/syntax for declaration:

Some people make declarations nested between ---s and using single colons and others without the dashes but with double colons. So far I haven’t noticed a difference between these two methods. Is there one?

  1. Redundant frontmatter?:

Some people put file created and file modified in the frontmatter. Since these variables are already available for dataview queries isn’t this declaration redundant?

Thanks in advance for any insight you can provide.


1 Like
  1. No, Meta isn’t the right place to ask for help. I’ve moved it to Help. :+1:

  2. As far as I understand, the double colon is for when you want inline metadata anywhere in your note. Otherwise YAML frontmatter is inside the ---'s and must be at the top of your note.

And I don’t know if inline metadata is actually supported by Obsidian. It might be a Dataview thing only. I don’t see it in the help docs. And I don’t see inline tags showing up in my Obsidian tags. This Feature Request seems to suggest that it isn’t supported in Obsidian directly.

  1. The reason some people do this is because depending on your sync tools or OS’s filesystem, you can’t always rely on the creation and modified data to stay static. So people write it into their metadata manually so they can trust it stays the same. (There might be other reasons. That’s the one I know.)

Thanks. It was more philosophical so I put it here. Cheers.

Thanks for the input. Re question 1, I haven’t so far found anything declared that way to act any differently when using the double colon syntax. I guess there’s an aesthetic difference in view mode. My note volume is mounting fast and I just want to avoid pain down the road because I’ve created a lot without yaml frontmatter since the other method has been working so far.

1 Like

As a reference point, the developer of Dataview and Datacore has given this insight about the future direction of YAML:

Obsidian is adding support for new frontmatter and YAML adding functionality, and has recommended that Datacore move away from Inline Fields (since they are much more bespoke). Inline fields will still be supported for users who prefer it, but …

See: datacore/ at master · blacksmithgu/datacore · GitHub


Some notes on declaration differences

There are subtle difference here and there, but the general principle is that whether the field was defined in the frontmatter or as inline field it shouldn’t matter.

One difference is related to accessibility, where in Dataview frontmatter fields are accessible through file.frontmatter in addition to just the field names. Similarly Templater has a tp.frontmatter access, but not direct access to inline fields. In Tracker there are also different ways to access the frontmatter fields, versus the inline fields (with some caveats of its own in either implementation).

Another difference is that declaration syntax varies on whether you’re using the frontmatter or inline fields. Lists and/or links have caused more than a little frustrating at times, since it’s not a clear cut which syntax works where.

Handling of links is also a vital difference when it comes to frontmatter vs inline fields. Both with regards to the syntax, but also in how Obsidian handles the links, both related to backlinks, inlinks and if you rename a “link” placed in the frontmatter. E.g. it’ll not follow the rename strategy which applies in the rest of the vault (with the exception of within any code blocks). The Frontmatter Links plugin tries to counter this behavior.

Redundancy in frontmatter

In some circumstances the file creation and modification times can be changed due to sync tools, file system issues, backup issues, or what not. Another case is when importing files from a different system. In all of these cases, it renders the metadata associated with the actual file possibly incorrect.

Personally, I’ve imported many files from the Day One app, and it uses a slightly different file format, so when I imported/transformed these file, the file creation date (of the new files) was naturally set to the day of the transformation. Luckily, the file had the creation date as metadata, so I could transform that into my Obsidian variant of those files.

Another case is if you do daily journaling on different mediums, and move them into Obsidian at a later stage. Here you’re also wanting to be able to set the creation date related to when it was written, and not when it was created as a digital file. I’ve also done this if I write a journal entry in retrospect, where I then set the creation date to be the actual date of the entry.

The last case I would highlight, is if you change metadata associated with your entries, and you don’t really want neither the creation nor modification date to reflect that. Like I changed from tags to a field for some information, and that would of course trigger the actual file modification, but I wouldn’t like it to trigger the entry modification.


I really appreciate the detailed response and all the information. After messing around a bit I think I’ll move most of my fields into the frontmatter. After some messing around it does seem that in-line fields have their uses, too.


1 Like

It has kind of been said already, but to be clear: the inline, double-colon syntax is specific to the DataView community plugin. The single-colon syntax that goes at the top of notes is an independent language called YAML which can potentially be used by apps outside of Obsidian (its use in Markdown files was pioneered by software for generating websites).

1 Like

I’m still using in-line for assigning fields to list items and todos. Also not all frontmatter is displayed in read mode. Arbitrary declarations are shown but up and sibling type of field names don’t. Breadcrumbs deal with the parent relationship but I’m still redundantly using in-line declaration at the top for display of other relatives.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.