Out of curiosity: why aren’t you all using a proper relational database for this kind of structured information instead of trying to make Obsidian fit a use case that it has not been made for?
Generally you’d normally want your fields to stay consistent across all records etc. which is extremely easy to break in Obsidian and a given in tools made for the job such as e. g. Airtable.
Keeping structured data in unstructured documents hence is normally a pretty bad idea. But I might be missing something.
Nice. I got it to work following your instructions. However, it requires insertion of a minimal one-line dataviewjs snippet.
I am wondering whether it is possible to add a field in the yaml header to trigger this property editing capability.
Currently the Nested Property Editor (NPE) is just a dataviewjs view. So the view can only be displayed inside a dataviewjs container. To automatically add it to a note just based on a yaml field in the header, would require that an instance of the editor is running in the background and listens to changes of the workspace (switching between tabs, opening of notes, changes of the editor-mode, etc.). Since dataview doesn’t support startup scripts, having the NPE running in the background would require other plugins like CustomJS. But this would still require to implement all the event-listeners and callbacks. Essentially one would need to do almost the same things to write an obsidian plugin, with the downside that it is not a true plugin but would still rely on other plugins like CustomJS. That said my priority would be to port the code into an obsidian plugin. It is somewhere on my todo-list but currently not my top priority, since it would still require quite a bit of work and I’m still not that familiar with the obsidian plugin API. So if there is anyone out there that can help to make the NPE an obsidian plugin, this help would definitely be appreciated.
It’s because my use case is just in that uncanny valley between “too complicated outside obsidian” and “too simple within obsidian”
In short, it’s because I maintain a short note for each person in my life. This means I keep track of things like their gender, preferred pronouns, my relationship to them, their birthday etc. but also track of their relationship with others.
Doing this in say an SQL database or Airtable is literally overkill, and the main way I keep track of their relationship with others is by [[HyperLinking]] to their notes.
Nesting would be nice because then I could do something like this
Is it the core Obsidian or a plug-in enabled the display of nested yaml header in a recent update? I noticed the note now has two collapsable items for the YAML header. The Properties was the original,
It would be really nice to have this feature especially with the new base feature integrating some of the more queriable feature from plugins into the base app.
And here I thought it finally works. MAKEmd is an opinionated plugin that changes how obsidian works quite a bit. I want to like it but it is hard to learn
This needs to be vanilla feature, MAKEmd, dataview, metadate menu support this natively. And with the new .base format it is more important than ever
yeah. I noticed that MAKE.md changed Obsidian’s behavior a lot, and sometimes the yaml header of a note is not automatically updated, it also makes OB slower as well. For now, I did not change any configuration with MAKE.md, just using it for the nested yaml header editing.
I agree nested yaml header needs to be supported natively.
Even if Obsidian doesn’t support multi-level YAML, currently if you have a list of lists as [ ] it expands it into - - format so it imposes some kind of structure. That still doesn’t allow it to be used.
Either it should leave this kind of YAML alone or handle it fully. The software now screws with YAML that it reports it doesn’t recognize, and then it still doesn’t recognize it after doing so. What’s the point of that exercise?
The worst part is that any edits in Bases are treated as an update to the YAML in the same way, causing it to screw with multilevel YAML thus expanding lists of lists. This makes it basically impossible to keep organized multilevel YAML readable for use in dataviewjs, because all conveniences related tangentially to YAML break it.
Either do nothing or implement it fully, don’t enforce unwanted structure into YAML that you’re not handling anyways
The problem arises since obsidian internally converts the YAML frontmatter into a JSON object. Whenever you make changes to the frontmatter through the obsidian API (properties editor, new bases feature, or any plugin that uses the obsidian API to handle the frontmatter), processFrontmatter is called to convert the JSON frontmatter object back into YAML. Through this conversion process, the original YAML frontmatter format is lost, since JSON doesn‘t support different styles of list definitions as YAML does nor does it support comments.
So the problems you describe are mostly inevitable by the design choice of the obsidian team to handle the frontmatter internally as a JSON object. Technically, it would probably be possible to store additionally hidden metadata fields for list style, comment, etc., so that the original YAML structure could be restored. But since there aren’t even signs that we could get support for nested YAML natively in the properties editor, it‘s even more unlikely in my eyes that we will see support from the obsidian team for this list of list JSON-YAML conversion problem.
Even if the Obsidian development team chose to represent the YAML header as a JSON object, they could still implement a parser to handle JSON-compatible YAML, only excluding non-JSON-compatible features like anchors. Since nested YAML structures are fully compatible with JSON, I don’t see a reason why this feature should not be supported.
On another note, I am not a coder, but I recently tried Claude.ai to write an Apps Script (essentially JavaScript) to sync between a YAML file and a Google Sheet record, and it handles conversion, including nested YAML, pretty well, so I don’t see this as a technical issue.
