Use case or problem
Content has no clearly defined “type”/“class”. Generally speaking, the only representation possible is through the creation of templates, with pre-defined properties, types, etc
Without types or classes, it’s impossible for Obsidian to recognize different pieces of content as actually different (e.g., daily note vs meeting note).
Thus, Obsidian cannot provide auto-completion for properties that could/should be type, …
Proposed solution
I propose introducing “Class” or “Type” files, enabling the documentation of content types in a vault.
“Class” or “Type” files could include things such as:
- A name
- An icon
- A list of mappings
- A list of property definitions
- A list of tag definitions
- An associated folder
- …
The list of mappings would create the link between the Class/Type with a specific note/set of notes/documents…
Those mappings could be:
- Tag(s)
- Folder path(s)
- Regex
- Some kind of expression (e.g., similar to base formulas)
- …
Property definitions could include:
- A name (MUST)
- A type (SHOULD)
- A list of allowed values (COULD)
- A default value/set of values (COULD)
- Whether the property is optional or mandatory
- …
Tag definitions could include:
- A tag (MUST)
- A display name
- Whether the tag is optional or mandatory
- …
With such Class/Type files, it would then be possible for Obsidian to:
- Propose dropdowns with expected values for fields (within notes, within bases, etc)
- Automatically add missing properties/tags to relevant notes
- Automatically move notes where they belong (assuming a system where each note type has an associated folder
- Display icons for different note types
- Validate notes & help improve data quality
- Create more powerful/shareable templates
- …
Current workaround (optional)
Currently, the workaround consists in combining templates with plugins such as Metadata Menu, which introduces the notion of “fileClasses”: Metadata Menu