Obsidian Properties: Best Practices and Why?

With the release of Obsidian Properties, we now have an easy way to manage metadata. Woohoo!

But with great power comes great responsibility (or at least a little). I think many of us may have found a moment where we spent too much time fiddling with metadata. For the past 3 years, we did it without a nice-looking UI. It was a good forcing function to limit how much metadata we might feel compelled to add.

However, now it’s easy. Maybe a little tooo easy.

With that in mind, I’d like to ask you: what categories are you using for metadata?…especially now that you can easily work with it using Obsidian Properties.

Before the release of Properties, I kept it minimal.

~ [[I'd put the most important "top" link here]]

After the release of Properties, I’m likely going to expand this, but I don’t want to fall into the trap of becoming a janitor of metadata.

  • What are the core categories you use?
  • How many is too many?
  • What are your best practices for managing metadata property?

When I started I included a bunch of stuff like ‘creation date’, ‘modification date’, ‘title’ etc that I realized I wasn’t doing anything with, so I removed them all. Now I only add properties that I have an immediate use for, and I only add them where necessary (I don’t have any blank properties in a note). Here are some that I use:

  • aliases: Often used to enable easier linking
  • type: journal, people, place, organization, recipe, ingredient, medication, etc for use by scripts/queries that process only certain types of notes
  • sleepscore: I have a page that collects my sleepscores to show trends
  • weight: I have a page that collects my weight to show progress
  • elliptical: I have a page that tracks fitness goals

I think many of us may have found a moment where we spent too much time fiddling with metadata.

Yes, these past few days I have spent some time thinking about this as I use one vault for different use cases that require different properties.

  • What are the core categories you use?
  • Type
  • Tags
  • Status
  • Day
  • UID
  • Project
  • Reference

How many is too many?
The above is for many of my notes too many and I have deleted many since. Variation due to capitalised and uncapitalised properties results in too many also.
Therefore I welcome this feature: https://forum.obsidian.md/t/additional-properties-commands-rename-and-remove-properties-and-values-in-all-files/63806

What are your best practices for managing metadata property?
I have been thinking about this for the past few days.
The Cypher manual seems helpful in formulating best practices.

The type of node/note and its roles in problem-solving can help determine essential properties, as well as the data type and values. If a property is not used to answer a relevant question, it should not be included.

A best practice relating to this may be 'articulating and prioritising ‘use-cases’ or questions you want to answer with your notes in obsidian.

I’m curious about other approaches. Thank you for starting this conversation @nickmilo


Here’s another resource that may be interesting for developing (related) best practices


I’ve scaled back to just aliases (I use hashtags instead of the tags field).


Are there any books that talk about this in context of PKM?

1 Like

Interesting. Created date is the most important one for me. You can’t be certain that a file system creation date will stay consistent, especially if you migrate your vault to a new computer in the future.

Having that stored immutably in the note is vital to me for future reference. It’s actually the only metadata field I set in my new note template.


I want to challenge this view. Notes are just notes intended you to produce other work where you will hardcode creation date, like a book or video. Then there is data tracking which involves dates. Again data tracking should be implemented separately and independently of your notes, meaning you can input data using your notes or not (but your data tracking is not dependent on any particular input source).

Notes being “just notes” doesn’t gel for me with the idea of a second brain. Knowing when you first came up with an idea or created a connection is super useful data. Even things like “when did I read that article or read that book” is handy to know - and the note creation date gives you that info.

Consider the task of wanting to review notes you created more than 6 months ago, so you can see if there’s any new sparks of insight - hard to do if you don’t know when you created a note :wink:


I was trialling the following:


But then I realized that related, folks, and locations should just be [[linked]] in the content of my note. So then I was left with


I then removed citation because why should I duplicate what Zotero does so well: one app, one job. I also removed series because I realized I was just “collecting” that information for no real reason and it’s really the individual books in a series that I focus on, whereas creating a note for a series of works didn’t add value. Thus,

aliases: for synonyms and titles
author: only [[linked]] if I think I'll be interested in learning more about a particular author, or if I myself am the author
date: to follow trends over time in my research and my personal journaling
url: for quick access when needed
tags: for the status of a note

I would say “tags” is my biggest open question. I use YAML tags for status, but I use inline tags for other metadata, like #inspiring. I feel like I am under-utilizing tags but this is more a question of process.

In conclusion, very pleased with Properties! Hoping for some added functionality that will support quick refactoring sessions in the future (see my feature request on bulk removal and renaming if interested.


Metadata is context-specific, in my notes. If the note is a book inventory entry, then it has metadata recording book-specific metadata such as publisher, pub-date, ISBN, page count, platform. If the note is a daily note, it needs no metadata. If the note is a person-note then it has aliases in the metadata so I can refer to Chuck Mangione as Chuck and Mangione.


I don’t believe this would be very effective way to work. You should use other more descriptive parameters to filter your notes. By doing so you are not relying your memory about past time. After quering your search you can then sort by time.

Exactly - which is why you need to store the time. Going back to my original point, you can’t rely on filesystem time as it gets changed when copying or syncing.


Then maybe Obsidian should adopt that information internally? I’m not sure how it works exactly, but manually adding the creation date should be out of question. Instead it should be a core feature (not necessarily visible to the user). What do you think about that?


That’s very true, but for the way I work, journals and documents where the date is important have the date as the file name, and for the rest of my notes, the date isn’t important. This just shows that how we use the fields depends on what we’re trying to accomplish, and which workflow we’ve found best to help us do that.


Have expanded YAML with Linked Data Vocabularies. I even used Linter to comply with the new format (which turns out to be Obsidian YAML format necessary for Properties) forced by LDV and now my frontmatter complies with Link with Alias plugin as well.
If I needed to put in a new one, I’d do regex capture and include a new field in batch.


I’d like to share my approach if I may.

At root, i.e. first level variables, I have data like created_at, and updated_at that record when the file was created and modified. I also have a unix_timestamp just in case something happens to created_at. They are handled automatically, so I don’t need to worry. I have title which copies the file name, but I am too lazy to fill it out sometimes. Status, which may be discharged (not expected to be updated), evergreen (expected to be updated continually), or sprout (expected to be updated and discharged), fleeting (anything else). Languages which is a list that shows target languages of the note. As a bilingual I imagine it will be helpful for me to sort notes by language, or a mix of languages. Aliases pretty standard. And genesis which tells me the origin of a note. For example, something that I wrote completely out of my head would be original. If I had an inspiration from a song, or have any other identifiable source that helped me write this note, that would be derived. If I make a note of something I have learned, like definition of a word “Velocity”, that would be external. Mixed would be a note that combines notes of derived/original and external origin. This variable helps me to keep track of how much of my own thoughts are in the vault. If there are too little, I can think of focusing on creating more derived/original notes.

Now, I have my own philosophy for this, and from now on starts the most interesting part. I mentioned root of the YAML variables because it is important. I treat all root variables like variables that belong to the file. For example, if I have a file type of “event”, I wouldn’t put the location of the building where the birthday party was at the root location variable. It is reserved for the location where I’ve taken the note (i.e. created the file). So, what do I do? I create a root variable called event and then populate it with variable location, name, date, address, etc. I feel like it is a robust and logical philosophy that allows to keep my YAML flexible and avoid as much interference in the future as possible.
So it looks like this:

type: event
 location: [12345, 12345]
 type: birthday
 date: 2023-06-14T22:00:00.000Z
 state: passed

To keep track of my syntax I create meta files that describe templates for each of those variables. It makes it convenient. For example, if I want to get the length of a video I can just call video.length in the dataview, which makes sense since the file has type = video. Just length doesn’t make sense as it could be interpreted as a length of a file.
But as for as I know, properties do not support nesting yet? I wouldn’t tell as I’m not an insider. Also plugins like map view have no setting to specify which location variables to look at. So it does create some friction, but ultimately I think it is worth it.


I’ve recently looked into other apps (Notion, Capacities) and now when Properties are more available (and linkable) in Obsidian, it seems as if that is a first step towards objective-oriented note-taking and it’s possible to build systems in Obsidian that has the same features as for instance Capacities.

I’ve just briefly started to explore the property feature with this in mind. What I’ve come up with so far is to have a type (type of object: a travel note, a place note, a city note) and then I’m thinking of adding more properties to those types. E.g. a start date and end date for travel notes, maybe a city property for where the travel was going to. Maybe places can have some kind of category, like restaurant, hotel, sight, etc.

Have anyone else explored the linking side of properties and have more insights?


How can i try “properties”? I’ve never seen it in my obsidian. Using yaml as usual. Is there any guide how to enable em?

Properties are only available on “Insider builds” at the moment :blush: