Well, actually, the way I see it: the idea of “treating scalars in YAML as link potential targets” doesn’t appear to be related to the question of “single frontmatter” vs “second frontmatter block”.
To me, that’s another -ortogonal- discussion. The above idea doesn’t necessarily take any sides in that discussion. It could work either way (with 1 frontmatter block, or 2, or 3, or whatever).
Given some of the above comments, I do see why you are bringing it up, though…
The OP proposal was wikilinks in front matter and that’s not valid yaml. The alternatives are 1) second, non-yaml front matter like blocks or 2) interpreting existing front-matter scalars as links.
I do view them as alternatives for this use case and not orthogonal.
about: “Treating all YAML scalars as potential implicit link targets”
…
To clarify things a bit:
Below is how a plausible/reasonable implementation of the suggested behavior (of treating all YAML scalars as potential links) could look like.
It’s broken into a collection of little sub-features, some of which could be useful on their own.
Any YAML scalar that does not correspond to an existing file would be treated the same way as it is today. Nothing special there.
If a YAML scalar value does correspond to the name (or relative/absolute path) of an actually existing file in the current vault, or else if it looks like a URL, Obsidian could display it as a link, and allow you to open it (or peek at it) in a way similar to a [[wikilink]] (using Ctrl-Click or something similar) or markdown link.
This way, if you so desire, you could keep extra information (notes or data) about the entity being referred to by that scalar, and easily navigate in between.
An algorithm very similar to (if not the same as) the one used for wikilinks can be used for deriving the file names and paths to try (for example : with or without an “.md” suffix, with or without folder path, etc.)
Also, there is no reason to artificially restrain the target file type or extension to markdown, in my opinion:
Ctrl-clicks on it, we open it (or browse to it) if we can; or else indicate that we can’t.Again, nothing fancy should be needed or forced upon for entering scalars (be it actual link targets or otherwise). You should just be able to type them in the way you are doing it today, even for filenames / paths.
When entering a a reference to a note, or any filename/path, though, you could just press a keyboard shortcut (or right-click and choose a context menu) which would allow you type a fuzzy search term and then pick a file, whose name (without any eventual “.md” suffix) would then be textually inserted where the cursor happens to be…
From a pure functionality point of view, it would produce something very similar to what happens when you enter wikilinks (except that the trigger would be keyboard shortcut, not “[[”) and could eventually share much of its code with the wikilink stuff.
In addition, the user could also be given the choice of what text actually gets inserted (just the file name, or a path relative to current file or the vault), whose default could come from vault preferences.
In fact, this particular helper doesn’t even have to be limited to this proposal (or YAML for that matter). It could be providing a generic functionality (perhaps written as a plugin) which could be triggered anywhere where you can enter text.
Another keyboard shortcut (or context menu) could trigger a functionality that allows creating a note whose name is derived from the selected text.
This would do something quite similar to what happens today when you Ctrl-click a [[wikilink]] that doesn’t correspond to an existing file, except that it would be using the selected text instead.
Again, this helper, which can be written as a plugin, doesn’t have to be specific to this proposal or YAML; it could generically work anywhere in the editor wherever you can select text.
For graph visualization purposes, or when enumerating forward/back links, implicit links (scalars that actually correspond to existing files) could well be counted and displayed, if the user so chooses.
In fact, imho, this is the only place where link noise (or digital noise, if you prefer) could potentially creep in, if not implemented carefully.
So, it’s important to give the user a real choice (both in preferences, and also, right where the visualization actually occurs) as to whether or not to count/display those implicit links.
BTW, typed/labeled links, when available, would naturally be supported in this scheme of things; as the link type can be derived from the YAML key-path, as described in the initial suggestion.
For performance reasons:
when trying to detect implicit links in YAML scalars, it may be possible to skip any scalar whose textual length is longer than a configurable value (which could default to 1024 or something).
also, it would be probably very helpful to keep an in-memory cache of the vault index (which is already being done, I think).
Tabulo[n]
OK, yes, I see your point : The suggestion (2) would indeed eliminate the need for non-valid yaml… and hence also the need for another block (1) of non-valid yaml which would otherwise be needed just for achieving links (if those were implemented with a special syntax, like the OP).
On the other hand, there may be other reasons (than links) for wanting the ability to have a second block (or more).
For example:
The usual front-matter typically contains metadata (i.e. data about the current document/note).
In some cases, however, the note itself is a mere entry that is intended to represent a real world entity or concept (movie, song, plant, animal, person, …), just like “spinach”, as in the plant PKB example above.
There, I can see why it would be desirable to have the ability (but not the obligation) to have subsequent YAML block(s) following the usual front-matter, where one could place data about the real world entity represented by the entry, in a way that is at least visually distinguishable from metadata (about the note/document).
Hi @Moonbase59,
I hear your concerns… And on a very high-level (abstract) level, I tend to agree with most of them, or at least share the sentiment.
However, my apologies for failing to understand how those map concretely to the suggestion at hand…
For example, in what concrete way(s) do you see the suggested behavior :
In fact, one of the main constraints I had in mind when jotting that down was to avoid breaking anything at all: either YAML (which doesn’t have any native link syntax), or Markdown, or Obsidian, or any current (and future) workflow that relies on existing behavior, including those like the example you have described.
Also, you do probably realize that a lot of the metadata in your own example could well be considered as “unplanned-for” usage of the YAML front-matter at least by some, right ?
Obsidian itself currently “understands” just a few of those (title, keywords, …). So, strictly speaking, we could say that any of the others weren’t really “planned-for” by Obsidian…
Luckily, Obsidian is quite flexible (which probably was planned-for), so it doesn’t mingle with anything it doesn’t understand, leaving those alone instead…
Hence, you are able to leverage that generic flexibility to fit your own workflow (for me, that’s all fine).
Likewise, some of the metadata in your example (e.g.: author, editor, publisher, documentclass) and even some of the preprocessor directives (e.g. stylesheet, css, highlighting-css) could well benefit from the suggested behavior (if you wished so, of course)…
I went ahead and jotted down what I consider to be a reasonable implementation of the suggested behavior (of treating all YAML scalars as potential link targets) as a response to my initial post.
You may want to take a look.
In a nutshell, this proposal, if implemented, would imply Obsidian displaying Eigenverlag as a link if (and only if) there is a corresponding note or file for it (like eigenverlag.md) in your vault. Same goes for supportfiles/style.css.
Any scalar that doesn’t have a corresponding note would look and behave the same way as it does today…
Noisy? Complicated?
Well… In the end, I have feeling this may actually boil down to what one considers a simple PKM is or ought to be…
Tabulo[n]
I like YAML a lot, I just don’t like it all the time 
Many of my projects need a little, some projects would benefit from much systematic metadata. Some project don’t need any metadata.
Simplicity and flexibility are key just even for my varied uses of Obsidian.
Maybe I am missing something, but couldn’t YAML be implemented as a plug-in? Then people could choose if (and hopefully how) to use YAML to best support their projects?
YAML front matter is a de facto metadata standard for markdown used by editors and static site generators. Obsidian uses it for tags and aliases as a core feature. So no, I don’t think front matter support as a plug-in makes sense.
If tags and aliases do all you need, that’s great. That’s most of my uses too. I can think however of uses, e.g. a curated exhibition inventory used for internal and external purposes where additional YAML attributes would be most helpful.
The system is already flexible in that regard
The point of this discussion is if the Obsidian’s “Linked Mention” system (or even unlinked mention detection) should work on the YAML block.
That would be nice to have a UI selection for just that in Settings. Right now, unless I’m mistaken OR doing something wrong, ‘unlinked mention detection’ lists way too many suggestions, even when trying to limit the search parameters. My thought is that a limitation to YAML Aliases (and/or Tags) would be more advantageous unless I’m misunderstanding the issues.
In YAML, the construct [[something]] actually translates to an array containing an array containing the string “something”. While it would be wEiRd to treat an array containing an array containing a single string element as a link, it is a unique enough form that it is unlikely to conflict with other structured data use and a plugin that was able to treat these as links at least for the purpose of supporting clicks and automatic backlink updating on renames would be hella useful. I don’t know enough about the Obsidian API to know if a plugin can effect a fundamental working of the system such as defining a link to a note, but this would be one way of addressing this need.
For what it’s worth: the reason I want links in YAML is because it would enable me to use YAML to express semantic links between notes in a way that didn’t require introducing cumbersome new syntax to Obsidian links. For example, if I had a note about Luke Skywalker I could have some YAML like:
---
father: [[Darth Vader]]
occupation: [[Jedi knight]]
---
Then using another tool I could do something such as query for all the Jedi who are related to Sith.
That would be so much better than doing it in the note text itself, I do a ton of that right now. Tags in front-matter would also be extremely helpful.
From the ‘use cases’ I have, I can only concur @ChristinWhite @usergenic . Systematic collections, such as inventories of curated archival items, would benefit from links in the YAML section.
May I add that having a plug-in to facilitate the entry, control and access to YAML metadata (and links) could be very helpful too. In other situations, it may be unneeded.
@usergenic and @FrancisH – this is what I use the dataview plugin for. You can query against the data and attributes you add (either as YAML metadata, or inline with content as “key:: value”).
I most often go against tags (which can be declared in frontmatter, or not), see https://forum.obsidian.md/t/dataview-plugin-snippet-
showcase/13673/30
Dataview queries don’t show up as relationships in the graph in the way that a tag would, but that isn’t necessarily a bad thing.
Thanks! I took a look and this really looks useful…
+1 For this. I imagine there are multiple ways of having something work, but something well done here could be great. For example, maybe replacing [[]] with a different symbol in the frontmatter. Even something ugly like escapes could be fine at this point.
There’s been some discussion on the Metatable github page, but the solution should really be implemented directly in Obsidian, for the ability to get backlinks.
Hi, was this ever further addressed by any devs?
The last I saw in the forum was that [“Link Name”] would be supported (as that is consistent with YAML syntax). Discord
But it feels like a lot of folks have moved on to using inline dataview fields elsewhere in their documents for links.
Can’t wait, honestly!
This feature makes sense, and it is essential to my workflow. I do not think that adding another block for metadata is a solution.
Specifying the relations in the body of the note feels forced to me, and I’ll stick with logseq as it does support links in the YAML frontmatter till this feature is implemented.