Properties: Support multi-level YAML (nested attributes)

[ryadaj]

Cool! Thanks for the explanation would the Properties editor basically indicate that YAML is nested simply by indentation, as in source?

[BambooBastille]

+1 for nested properties!

[_tttt]

+1 from me

[crystalatom]

The new features of the properties are nice to have, with easier selection, and the ability to organize the properties. However, the lack of support for nested attributes is a deal-breaker for me to use the new Properties features.

[gino_m]

With a little regex knowledge it would not be hard to mash together the parts (of the keys before colons) belonging together.
Lacking that, even a chat robot below 4.0 could still do it. Then in VSCode or Notepad++, make the replacements.

[Feralflora]

That doesn’t solve the request at all. Especially since workflows like Pandoc exports expect a certain yaml metadata structure.

[gino_m]

I’m not “against” the FR. More like “for” the people who try to find fault with Obsidian putting a cramp in their cozy workflows.

[josh_p]

To rehash the old expression:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

Yes, it’s certainly possible to utilize a “key_nestedKey_” structure and parse out the nesting into unique values…
But… It’s almost always the wrong tool, especially when something like nested YAML, lists of dicts, etc, exist.

Personally I’m more interested in discovering what the “correct” solution would be than I am in getting features added…
family_mother_name: isn’t it because it isn’t going to be supported by queries easily at all. It also isn’t expandable without a ton of work. (family_stepmother_name: for example)

This won’t work either, because you can’t attach data to the relationship.

family:
  - [[mothers_name]]
  - [[fathers_name]]

at least not without a lot of cross-file inference from things like both the mother and father’s pages having a “children” list and determining the relationships that way.

To my mind the ideal probably looks something like:

family:
  - relationship: mother
    record: [[mothers_name]]
  - relationship: father
    record: [[fathers_name]]

but that’s probably because I have years of building relational databases clogging up my brain and I want to force things into that structure.

Organizing metadata is clearly a topic that a lot of us are thinking about and doing in different ways. It would be very helpful to know what the Obsidian devs were thinking about this issue so that we could start aligning with what will be the expected way that development is marching towards.

[gino_m]

Thanks, Josh, you are right. There are many unknowns down the road of regex and it’s not fair or prudent to send people down that road. There is a fair degree of chance people merge multiple parts and end up removing others.
But you see, most people stop being pro-active and taking a personal interest when they see that somebody is “on it”.

I just think in metadata (that nobody sees other than ourselves) it is okay to be repetitive.
E.g.:

family_member:
  - mother
  - father
 family_member_name: 
  - "[[mothers_name]]"
  - "[[fathers_name]]"

• Actually, it was laid out above. Of course there are other ways but programatically we want the best that suits everyone, including those on personal and commercial level.

I do agree though that we need to keep hitting the Properties and YAML irons while they are hot, otherwise the devs’ focus will shift to other topics.
It’s even possible some plugin makers will beat them to it.

But because there are some Database plans in the works and metadata plays a huge part in that, I suspect this YAML upgrade will have be addressed and the time is about right to make the transition. We don’t know what’s going on.
(And there is also DataCore; not sure where DataCore is at at the moment.)
So fingers crossed.

[Snapitup]

+1 from me

[mtcrow]

Not to bloat this, since I already put my support in for this earlier… but this issue has entirely torpedoed my usage of Obsidian. Yes, I could reorganize my work to avoid nesting – but that’s about as easy as it would be to move away from Obsidian.

[TheOrangeMan]

+1, would very much like to have this

[a13ph]

As far as I understand, you can return to mostly old behavior if you choose to show source yaml in the settings of properties

[Sagitman]

+1 from me as well.

Nested YAML would make working with Properties significantly easier and more useful.

[ush]

a big +1.

[Oneechan69]

Also a big +1

[writtenfool]

On the surface I like the ability to nest; at a high level.

Where nesting, and yaml, fails for me:

1. I’ll be forever tacking on more meta data to notes.
2. tags and yaml front matter apply to a note (file).

This conversation reminds me of how we used to normalize database tables; only now we’re attempting to do it with yaml.

Is there not a more modern way of approaching categorizing and searching our vault information, irrespective of the concept of an “atomic note”?

Content tagging incorporating NLP models to automagically extract tags and categories, and store that in the upcoming database functionality in Obisidian comes to mind.

[paljas]

Hey @josh_p, have you tried:

family:
  - [[mothers_name|mother]]
  - [[fathers_name|father]]

A generalized interpretation of your use case would be having a relationship with a single (relationship) property. For this, above seems to work for me.

[4o4]

Can one make a css snippet that makes the json scrollable? So at least one will be able to see all nested properties and select the links to open.

Even better: make a css that also prettified the json and makes all urls clickable (I’m referring to bare urls like https://example.com).

[argentum]

While that “works”, you still lose the semantic information in the key value pairs and make it impossible for other tools and/or plugins to use the metadata. I don’t know enough about Dataview, but I imagine that querying “father” or “mother” is at the very least more convoluted if you use aliases if at all possible.
That workaround either way does not work for tools like pandoc that relies on the nested metadata. So imo the workaround does not get to the core of what this FR is asking.