Wikilinks in YAML front matter

Feature archive
, ,
25

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 :

    1. going against the simple/generic PKM scenario ?
    1. just another “bell & whistle”? (or bloat?)
    1. breaking your current workflow ?

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]

2 Likes
26

I like YAML a lot, I just don’t like it all the time :grinning: 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?

2 Likes
27

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.

3 Likes
28

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.

29

The system is already flexible in that regard

  1. You don’t have to use the YAML block if you don’t want to.
  2. You can use the few YAML attributes handled by Obsidian
  3. Third party plugins can be implemented to handle more attributes for specific workflows.

The point of this discussion is if the Obsidian’s “Linked Mention” system (or even unlinked mention detection) should work on the YAML block.

5 Likes
30

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.

31

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.

8 Likes
32

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.

1 Like
33

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.

7 Likes
34

@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.

3 Likes
35

Thanks! I took a look and this really looks useful…

1 Like
36

+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.

2 Likes
37

Hi, was this ever further addressed by any devs?

38

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.

2 Likes
39

Can’t wait, honestly!

1 Like
40

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.

1 Like
41

Bumping this up again because the use of links in YAML is quite important to my workflow as well. Also, being able to pull-down a search for available pages like we do with [[]] with YAML link syntax → [""] would be great.

6 Likes
42

+1 to this, it’s essential to what I’m trying to accomplish

43

Any news ? This is a very important feature request, I really hope this gets implemented soon.

3 Likes
44

I really like your example:

I usually start my notes with an H1 for the note title (so placed below your red line).

I would also like to have a header in Your Block, so I can fold/unfold Your Block for less clutter, when viewing my note.

I therefore wonder if it conflicts with also having a H1 in the Your Block section?

In other words, does it conflict anywhere if I have two H1’s in one note?

Or should it be a H2 in the You Block section or does it conflict to have an H2 above a H1?

Or should the Your Block section not include a header at all?