So, if Obsidian disappear in some years, you will never had the hability to regain the power of you file, as some contents are parsed only by Obsidian.
Most of the “github flavored markdown” and such initiative appeared because markdown didn’t have them, and they where necessary for their purpose. They needed syntax to represent their business domain : commits and such, so they made them. Syntax was needed to allow sizing and alignment of an image : it was added. Semantic mediawiki needed syntax to represent relations, they added. Wikipedia needed syntax so a link can be conjugated/declinated/agreed on gender and number, they added. It is normal and expected that a tool dares expand on the tools to better represent their business domain.
Do you seriously think that putting obsidian .md files into a random markdown parser will give you anything near what you have today? with so many undefined behaviours, callouts conflicting specs, triple tick back syntax being the equivalent of activex basically when the inside is not standard and left to plugins ? My password manager does use a custom format but as long as the format is open and documented it can be parsed and opened, it can be converted and people can make that importer a breeze.
With that said field:: value would be a quality of life improvement that i would welcome with open arm… done smartly it can also be one step closer to semantic links/named/typed relation. The trade-off will be that my templates will completely replace the now useless frontmatter for a block of front-matter looking key:: value occurence, because that will be a now much better front-matter that can do everything the old one was doing + much more. Plus it will now be completely not standard instead of beeing just a little non standard (extended). Maybe i’m wrong on this and people will use both, but I’m sure myself i will completely replace front-matter with this much better version that contrary to the front-matter gives me the functionality i want…
3 Likes
While we are at is wouldn’t it be nice to have one identical way to attach attributes/values to anything ? Front-matter are just attributes attached to the note itself… There is a large number of request for attribute to be placed on tasks also like due-date and such, who would benefit from being scoped to the task they sit in. I would see huge interrest of having link scoped attributes as it would also go in the direction on the very very numerous “typed links” threads.
From the moment such a capacity exists in the core to attach key value to a note, paragraph or link, plugins can really use those to their full potential and build usecases limited only by imagination. Plugins they won’t have to re-parse the notes themselves or introduce random and often incompatible syntaxes to do basically the same thing.
3 Likes
Yes. Yes I do. And have.
Your arguments that Markdown lacks formal specification so incompatible syntax extensions are fair game is the definition of a non-sequitur. Obsidian does very little trail blazing on syntax and follows CommonMark and de-facto standard GFM for most of its syntax.
Callouts and internal links (wikimedia links) aren’t novel syntax either and are either de-facto standards or have a nicely degrading syntax that is broadly supported (callouts, block quotes).
You can drop text from obsidian into most markdown editors and it just works - confluence wiki, iawriter, Drafts, emacs-markdown. Try it. This is due to intentional, thoughtful design.
at its heart, Obsidian is a plain text editor. Unless something
really radical happened and ASCII text is deprecated (doubtful)
Obsidian files will be able to be read for centuries into the future.
Can’t says that about many many other formats. I remember the
WordPerfect story.
2 Likes
FYI:
And Licat’s answer specifically:
We have no plans to implement Notion/Airtable-like database functionalities, but that in theory doesn’t prevent plugin authors from turning Markdown tables into databases […] This is the trade-off we made for Obsidian, which is why I said I don’t think this would be changed at all. It’s in Obsidian’s DNA. Of course, it’s entirely up to you whether you want to make that trade-off, and we respect that. If you value functionality more than future-proofness, something like Notion or Fibery might work better.
1 Like
I wanted to use front matter for metadata, but found you could not include links to other notes in the YAML. I was okay with that as long as I could create a link within my document using the front matter data value; however, I had difficulty finding a way to create a dynamic link to another note.
I finally found out how to construct this type of link and hope this will help others.
Here’s a simple example for a D&D character. The character race is indicated as “Human” in the front matter, and I want to create a link to the “Human.md” note.
This will create the text “Character Race: Human” where the word “Human” is a link to the file “Human.md” as you see below.
Apologies for embedding images, but I don’t know how to post text without having it reformatted and some of the details lost. Make sure to include a “`” at the beginning and end of the expression. This is the non-shifted version of the “~” key.
Dataview is the only community plugin I have enabled. I don’t believe it is required for this to work, but if you have any issues you might consider enabling Dataview.
This allows me to accomplish what I wanted to do and still use front matter instead of inline metadata link assignment (E.g. “race:: [[Human]]”) somewhere else in the document. This might seem obvious to many of you, but I hope it will help others like me that are new to this.
If anyone knows a simpler or better approach, please let me know.
1 Like
Unfortunately, this construction works as intended only if you use one-word values. With value like “High Elf” it will work only if you replace the space with “%20”, but now there is a stylistic problem — your link looks like “High%20Elf”. Of course, you can create a second field for a “clean” title, but that’s bodging on top of bodging. Still, for simple tasks it is a good solution.
That probably requires DataView — it doesn’t look like default Obsidian functionality.
To post code without losing its formatting, mark it as code: Format your notes - Obsidian Help
For showing Live Preview/Reading Mode formatting, pictures are the way to go.
You can preserve spaces in Markdown links by wrapping the URL/path in angle brackets:
="[" + this.race + "](" + "<"this.race">" + " md)"
Or you can use wiki links instead:
="[[" + this.race + "]]"
I don’t use DataView so I may have garbled the syntax, but the link formatting ideas should work when you have the right syntax to apply them.
1 Like
The Lila’s frontmatter 
Hi there !
I’ve just published a topic about my current frontmatter solution, which allows :
- links to be :
- auto-completed while typing
- clicked in both Editing and Reading modes
- reflected in the graph view
- frontmatter to be :
- easily editable and readable in Editing mode
- else hidden, folded or entirely visible in Reading mode
- properly readable in other Markdown editors
| Theme | |
|---|---|
| Dark |  |
| Light |  |
You can find the full details here
3 Likes
I wanted to share another approach to have a frontmatter with wikilinks. I make use of a hidden text block, that is in between %%.
In addition to that I make use of the plugin Dataview and that is all.
The top of a note could look like this, and could be a used in a template:
%%
created:: 2023-01-26
updated:: 2023-01-26
type:: [[Research]]
rating:: 3
parents:: [[Parent1]], [[Parent2]]
%%
`=[[Dataview]].frontmatter1`
## Abstract
The line =[[Dataview]].frontmatter1 determines how the data will be shown in reading mode.
In the note “Dataview” I have defined how I want the data to appear in all my other notes. This way I only have to change 1 file to change appearance in all my notes.
I made 3 examples in the note “Dataview”:
frontmatter1:: Type: `=this.type`<br>Rating: `=this.rating`<br>Updated: `=this.updated`<br>Created: `=this.created`<br>Parents: `=link(this.parents)`
frontmatter2:: Type: `=this.type` • Rating: `=this.rating` • Updated: `=this.updated` • Created: `=this.created` • Parents: `=link(this.parents)`
frontmatter3:: Type: `=this.type`<br>Rating: `=this.rating`<br>Parents: `=link(this.parents)`<br>Updated: `=this.updated`<br>Created: `=this.created`<br><br>Folder: `=this.file.folder`<br><br>Inlinks: `=this.file.inlinks`<br><br>Outlinks: `=this.file.outlinks`
In reading view it looks like this:
Example1:
Example2:
Example3:
Hopefully it is useful for someone.
9 Likes
This is super useful. I didn’t realize you could create template fields in another page, then use an inline field to evaluate them in the context of the current page! This means we can create some kinds of Dataview templates without needing to use dv.execute(await dv.io.load(...)).
An awesome tool for the toolbelt. Thanks for sharing!
1 Like
I’m glad you find it useful!
Another thing you could also find handy is this functionality with Dataview.
In a note “Dataview” you can also define things like this:
ratings::☆☆☆☆☆%★☆☆☆☆%★★☆☆☆%★★★☆☆%★★★★☆%★★★★★
and in the context in your other notes you can use that to show stars instead of numbers:
=split([[Dataview]].ratings, "%")[this.rating]
So instead of displaying this:
you can display it like this:
To take it one step further, you can also use html in the string in the “Dataview” note.
ratings:: <font class="note-rating">☆☆☆☆☆</font>%<font class="note-rating">★☆☆☆☆</font>%<font class="note-rating">★★☆☆☆</font>%<font class="note-rating">★★★☆☆</font>%<font class="note-rating">★★★★☆</font>%<font class="note-rating">★★★★★</font>
In css you can define the colors like this:
.note-rating{
color: #ffff00;
}
This looks like this:
with this code in the note “Dataview”:
frontmatter1:: Type: `=this.type`<br>Rating: `=split([[Dataview]].ratings, "%")[this.rating]`<br>Updated: `=this.updated`<br>Created: `=this.created`<br>Parents: `=link(this.parents)`
6 Likes
That is totally brilliant!
1 Like
Use case or problem
When I add a date the YAML frontmatter in a note, I want the daily note (titled with that date) to display this note as an Unlinked Mention.
This improves my ability to explore my vault by simply browsing my daily notes, and seeing other notes made on those days through the Unlinked Mentions panel.
Proposed solution
Make unlinked mentions work the same as regular full-text searches, including YAML frontmatter.
(Maybe it doesn’t work this way for a reason. Feel free to let me know)
Current workaround (optional)
Perform full-text searches for dates to explore notes made on that day
Hi @ketchup
You may find this plugin handy GitHub - franciskafieh/obsidian-list-modified: 🪨 A simple obsidian plugin that links all modified files meeting certain criteria to a daily note
1 Like
Hi there,
I have been looking for a solution to this problem for a while, and invested the last 2 days to read through all related work I could find. I tested what I could come up with, and composed everything (Including the very neat solutions by @JayKim and @LilaRest) into one post:
I think we might have a workable solution in reach. @WhiteNoise stated many times that YAML is not to be touched, and with one or two tweaks maybe we don’t have to:
With @JayKim 's solution we have something like:
%%
created:: 2023-01-26
name:: [[Peter Parker]]
parents:: [[Parent1]], [[Parent2]]
%%
`=this.name` is a ...
Where now every information can be stored in one place, used throughout the page and be picked up by dataview, obsidian and humans alike.
3 Likes
Sorry, would you mind sharing some details about what you mean that about “YAML is not to be touched”? Does that mean we should eschew using YAML front-matter for adding our own metadata?
I also remember reading that DataView 2.0 (i.e., “Datacore”) is moving away from inline metadata) …
@jeetsukumaran I was refering to statements like this:
We can use YAML for the purpose YAML was intended for, but can’t stach all other features we want into the same field. So we have two blocks:
YAML
%%
Fancy feature space
%%
Merging those two has +5 to convenience, but -10 to consistency.
At least that’s how I interpreted it, and with building like that the past few days, it worked well enough for me. I barely use YAML nowadays, since most what I wanted to do was part of fancy feature space, for which I “abused” YAML.
3 Likes