Properties: Support multi-level YAML (nested attributes)

Current view shows my category property as ‘unknown’;

No type selected;
CleanShot 20230728 165422 tuRT4yEV


Same, I use nested YAML for several things, they work with Dataview, and switching to source view to edit them is not ideal.


+1 I use nested properties loads in my notes - particularly the TTRPG related ones.
The usability with Dataview is notable, but there are also plugins like Fantasy Calendar that relies on nested YAML.


I have reported this as a bug. Two weeks ago, nested attributes were fully supported. Now they are broken. Cannot edit nested properties in Preview mode


Would be good if the below worked as well:

    first: https://....
    second: https://....
  website: https://....

Unfortunately, after reporting this as a bug, I inadvertently accepted an answer for it and it then got put in the “resolved bugs” graveyard. Derp derp!

So, if others would like this followed up on, perhaps you can bring it up in the bug reports; I don’t want to wear out my welcome on this topic. :slight_smile:

I did not understand what you mean by “work using maps.” Can you explain? Thanks.

Adding my voice to this feature request, I too use nesting to structure my frontmatter


Objects, i.e., key-value pairs, in addition to just lists.

1 Like

+1 for me too

Adding my voice as well – while I can manually format a property as an object in source view, my dataview tables and filtered graph views really shine with nested property values.

+1 from me for support for nested properties

+1 for me too… most of my front matter are nested.
i asked on Discord abt this & they directed me here

Suggestion –

How about “flattening” nested properties by using a dot ‘.’ as separator? This would make the naming consistent with what one would see if they had previously used Dataview to display nested fields without a column name alias.

For example, with the following YAML:

  finished: 2023-09-01 
  format: Digital
  status: Reading

The new Properties editor could display it as:

book.started: 2023-09-01
book.format: Digital
book.status: Reading

I think this would be an improvement over the current approach, which displays it in JSON format:

book: {"started": "2023-09-01", "format": "Digital", "status": "Reading"}

+1 from me on this. I organize a lot of my notes with nested links off to external resources that they relate to.

1 Like

I tried this approach by manually introducing the dot notation in my YAML. But it didn’t play well with Dataview for some reason, not even allowing the fully nested key.

The best approach would be an expandable nested list but until then editing in source is the only way there is.

I concur with the opinions here. It always seemed odd that nested YAML was something that is harder to work with in Obi. Overall it helps with sorting and creating supersets of elements.
It would be even cooler if we could define a YAML “class” that is effectively a new property type that works like an organized property template.

Much of the meta data I hold onto would be flattened if the Obi team did this.


I may be wrong, but it seems to break the dataview. Nested fields are separated by a dot.


re: @vasujan @maksim77

Sorry if it wasn’t clear, but I didn’t propose to rename the key.

book.started would only be for display in the Obsidian editor, not as a YAML key.

Basically, when Obsidian parses the frontmatter YAML, it could implement a simple function to flatten the nested structures before displaying them in the editor.

And If someone writes a property name with a dot ‘.’ in the key, it would be considered a nested field when written back to YAML.

Currently, if one writes a property key with a dot ‘.’, it will appear exactly as written in the YAML, and Dataview indeed won’t be able to read it properly.

The tricky part, I guess, occurs if someone writes the following in the editor:

book.format = Digital
created_at = 2023-09-01
book.status = Reading

because upon converting it back to YAML, it has to be written into something like:

    format: Digital
    status: Reading
created_at: 2023-09-01

and thus, the ordering could change between book.status and created_at. But I think it’s quite rare for people to not want to display those in the same nesting consecutively (?)

Alternatively, I think having some kind of property “grouping” in the editor display would be nice. But this is more challenging because the current autocomplete assumes that property key will only be a single string.


I’ll also throw my hat into the ring for this. Prior to properties being released I managed note metadata with inline dataview fields, largely because this gave me more control over the aesthetics and organization of metadata in my notes.

I like the look and features of the new properties system, and started updating my PKM worflow to use properties instead of inline dataview fields, but I ran into an issue of poor aesthetics and usability / readability in the properties UI when the number of properties grows large (see Properties UI: add option for inserting visual elements to help visually group related properties). Thus the ability to nest properties seems really important for both aesthetics and functionality, especially when the number of properties in a note is large.

This has caused me to hold off on further integration of properties in my PKM until the nested property issue is handled, as I find it’s not feasible to use properties as it’s currently configured for notes with many properties.