Part of this FR is realized with the introduction of bases. Although the mental model is different and the definition of type is weaker.
You could think of the “type of a note” as the set of filters that it satisfies in a base. A base defines a type in a sense. The new button creates a notes that satisfies (or should) the filters (type constrains). This FR is a further extensions in this vein with a template.
For me, the crucial difference is that a type systems enforces a note schema a-priori, whereas what we have now with templates and bases are a-posteriori adjustments.
The new button in bases is quite interesting design choice considering one could use it as a primary way to create notes. But not really because the idea of bases is to create dynamic search queries and the new button gives fancy extension to it. There is nothing very special in the new button because it only gives addition to bases.
We need some kind of template language (syntax) to determine how notes will be created (folder, naming scheme, properties etc). QuickAdd offers this but the GUI is not very good and command line access of templates (or choices) is not possible. We could also think wider and consider macro language that allows to automate any actions, not just note creation. For example there have been user requests to create bases automatically.
IMHO, the “problem” with the current a-posteriori approach is that Obsidian is not very helpful when it comes to suggesting values for properties (e.g., for lists & selects), and often, the proposed values are actually incorrect when considering note types (assuming those exist).
Obsidian just doesn’t know anything about the allowed values (if any), except for those it already sees/indexes in the listed notes (which may not represent all the possible/allowed values, or even correct ones), and the type it has guessed/saved in types.json. Because of this, suggestions that Bases make are incomplete and sometimes incorrect. With proper types, Obsidian could always propose the right values, highlight & help fix incorrect ones (improving overall data quality), and also suggest values outside Bases (eg property editor).
Also, as soon as a Base view mixes different types of notes, the Bases proposes values that mix everything, which is problematic for more structured knowledge bases where different note types may share the same property names, but with different sets of values (e.g., status), or even different types.
It makes a ton of sense for me that many people don’t and should not care about this. But for those who do, it would be tremendously beneficial & empowering to be able to state that note X (eg based on path, tags, …) is an instance of type T, which has this and that and that property, each with a clearly defined schema.
In my knowledge base, note types are at the very center of everything. I use those for organization, for search, for Base filters/ordering, saved queries, Dataview queries, publishing, etc.
I actually consider two different, but related problems:
Suggestions for property values (within Bases and also through the properties view)
New Button in Bases
For the New button, in Bases, as soon as a Base view mixes different types of notes, the “New” button doesn’t make sense anymore, and the suggestions for property values don’t either. And same for the mentioned feature request. Being able to use specific templates (eg Templater) with the “New” button would be great because it would at least enable using correct values as a starting point. But it wouldn’t help when it comes to updating property values.
I’m not sure how user friendly DB Browser for SQLite is, but generally this is quite productive choice for mananing structured data with user controlling the schema/structure by different use cases.
I think that the benefit of callumpass’ proposal is that it can easily be managed from within Obsidian, and seems straightforward enough for AI to leverage, all while using Markdown & YAML, which are both already deeply supported in Obsidian
I really like the idea of implementing schemas for obsidian notes (similarly to what Capacities does) and callumpass’ specification is amazingly written! I don’t like, however, all these hard-coded names like “_types” or “mdbase.yml”. We should strive for keeping the set of predefined keywords as minimal as possible for future maintenance and flexibility per user. Why not only defining a “$schema” keyword in the frontmatter and follow JSON Schema specification?
