What if properties could be inherited?
This is my first post in this forum. I’ve been a quiet user for a long time – my vault has grown to around 7,500 notes over the years, and Obsidian has become the central nervous system for most of my thinking. But I’ve never engaged with the community, so if I’m retreading old ground or missing something obvious, I appreciate your patience.
I want to sketch an idea that’s been nagging at me, not as a polished proposal but as a starting point for conversation. Maybe it already exists and I haven’t found it. Maybe there are good reasons it doesn’t. I’d genuinely like to know.
Where this comes from
My vault is a mixed-use environment. There’s a Zettelkasten core with atomic notes and dense linking. There are long-form writing projects – I’m working on a crime novel series, which means folders full of scene drafts, character sketches, and plot outlines. There’s technical documentation: wikis, guides, how-tos for various tools and workflows. And there’s everything in between.
Over time, metadata has become both essential and burdensome. I rely on properties to filter, sort, query, and organize. Dataview runs on them. My project dashboards depend on them. But maintaining them has become a quiet time sink.
The pattern is always the same: I create a new note in a project folder. I open a template or copy frontmatter from a sibling note. I paste. I adjust. Weeks later, I decide the project needs a new field – say, pov-character for tracking narrative perspective. Now I need to add that field to dozens of existing notes. Or I rename a status value from draft to first-draft for clarity. Search and replace, hoping I don’t accidentally mangle something.
Every note is an island. They don’t know they belong together.
The core idea
What if properties could be inherited?
Imagine a project folder that defines a schema: “Notes in this folder have a project field with value hamburg-noir, a status field with default idea, and a protagonist field that must be filled in.” Every note I create there inherits these properties automatically. I don’t write them – they’re just there, flowing down from the folder.
If I set status: revision locally in a note, that overrides the inherited default. But if I don’t, it stays idea. If I later change the folder-level default from idea to concept, every note that hasn’t overridden it updates automatically. One change, one place, propagates everywhere.
This alone would save significant friction. But the interesting part is taking it further.
Beyond folders
Folders are the obvious inheritance source, but they’re not the only way notes cluster. I use tags extensively – not just for topics but for states and workflows. Everything tagged #needs-revision shares something. Everything tagged #project/hamburg-noir belongs together, even if the notes are scattered across folders.
And then there are MOCs – Maps of Content, hub notes that gather related notes through links. My Hamburg Noir MOC links to every note in that project. It’s already a structural parent in some conceptual sense. Why shouldn’t it be able to pass down properties?
So the idea expands: inheritance could flow from folders, from tags, and from explicit parent links. A note might declare parent:: [[Hamburg Noir MOC]] and inherit from that MOC’s schema. A tag like #series/heimer could carry its own property definitions. The vault becomes a layered system where metadata flows through multiple channels.
The complexity: conflicts
Multiple inheritance means potential conflicts. A note sits in a folder that says status: draft. It also carries a tag that says status: active. It links to a MOC that doesn’t define status at all. What wins?
My thinking so far involves two mechanisms.
First, a priority hierarchy. Something like: local definition beats explicit parent link, which beats specific tags, which beats general tags, which beats folder structure. The more intentional and specific the source, the higher its priority. This could be configured at the vault level – maybe you want tags to trump folders, or vice versa.
Second, per-field configuration. Not every field should resolve the same way. Some fields are fine with automatic resolution – just pick the highest-priority value and move on. Other fields might warrant a manual decision: if there’s a conflict, flag it and ask me. And for list-type fields like tags or characters, maybe the right behavior is to merge all sources rather than pick one.
A schema might look something like this:
fields:
project:
type: string
default: "hamburg-noir"
conflict: auto
status:
type: string
options: [idea, draft, revision, complete]
conflict: auto
protagonist:
type: link
conflict: manual
themes:
type: list
conflict: merge
The requirement: transparency
For any of this to be usable rather than magical, I’d need to see what’s happening. If I open a note and see protagonist: [[Joachim Heimer]], I want to know: did I set that here, or did it come from somewhere else? And if somewhere else, where?
I imagine inherited properties rendered with some visual differentiation – perhaps slightly grayed, or with a small indicator showing the source. Hovering might reveal the full story: “Value [[Joachim Heimer]] inherited from [[Hamburg Noir MOC]] (explicit parent), no conflicts.”
When there’s an unresolved conflict – a field marked manual with competing values – the interface could show a small warning. Clicking it opens a resolution view: here are the sources, here are the values, pick one or set your own.
The key is that inheritance should feel transparent, not opaque. I don’t want to wonder why a field has a certain value. I want to trace it back.
What I haven’t figured out
There are edges I haven’t thought through.
What happens when a source disappears? If a note inherits from a MOC and I delete that MOC, should the inherited values vanish? Fall back to the next source in the hierarchy? Persist as orphaned local values? Each choice has implications.
How does this interact with Dataview and other query tools? Ideally, inherited properties would be queryable just like local ones. But the distinction might matter – maybe I want to query “notes where status is locally set to draft” versus “notes where effective status is draft regardless of source.”
What about performance? In a vault of 7,500 notes, computing inherited properties on the fly might be expensive. Caching? Background indexing?
And the big one: how do schemas get defined? A _schema.yml file in each folder? A special block in MOC notes? A central registry? Each approach has trade-offs in discoverability, maintainability, and cognitive overhead.
Why I’m posting this
I don’t have answers, just a direction that feels promising. Before going deeper – or discovering I’m reinventing something that exists – I wanted to test the idea against this community.
A few specific questions:
Does anything like this exist already? A plugin, a workaround, a different approach to the same problem?
Does this resonate with your experience, or is the problem specific to how I’ve structured my vault?
What breaks? What edge cases make this unworkable? What am I not seeing?
I’m happy to expand on any aspect. And if there’s prior discussion I should read, I’d be grateful for pointers.
Thanks for reading this far.