Wikilinks in YAML front matter

[mpaul]

The main issue I have with this approach is that it only works for the most simplest use case. Outside of Frontmatter, Dataview doesn’t have inline object support. If you want to built a list of objects where each has a property that links to a page you have to use hacks and it gets messy.

For example, I have a People folder and each page represents a person. I also have a Teams folder. I intended the team pages to have a frontmatter list of “members”, where each member was an object that linked to a person and described their role. I wanted the links to join up in the graph, but that doesn’t happen.

I tried to then represent this through a markdown table, but don’t like the look of them in live preview (and can’t be styled as a table) and the data isn’t accessible through dataview.

I ended up using tasks, where each property of a member is a subtask, then have dataview roll up those properties via a map function.

I mean, it works, but none of this would be needed if I could use a frontmatter property to opt-in to frontmatter links displaying in the graph, or a second data block somewhere in the page to represent my data. Frontmatter is meant for plugins, but I don’t know if any plug-in that can import those links into the graph.

My understanding is that dataview will eventually have some kind of object support, and when that happens I’ll likely have to go back and redo my setup to support it. (None of this is a big deal, I just wish there were an easier way to do it)

[gobbletown]

Very well stated. Beautifully even. Thank you @dvd1, sincerely.

Tribalism–the selfsame fuel and flame of innovation and limitation–is a universal artifact of the survival instinct.

Dialogue (a la Bohm) with an eye towards optimization allows both the “us’s” and the “them’s” to benefit from the potential “better” way of the “ours.”

Debate = Stagnate

Tribalism is alive and well today: Mac v. Windows || folder v. tags || frontmatter v. inline || functional v. OOP || fuzzy v. standardized…

It’s all much ado, about some thing.

Unfortunately, it’s rarely about the important things, and usually about defending the tribes’ things…

To the OP’s point, and to what seems to be the important “feature” being requested:

@pyrotecx

The most notable idea being able to link anything to anything and use those links as tags themselves.

At the risk of additional sanctimony (though truly none is intended, sincerest apologies for any offense), the thread has focused on this topic’s message and not its meaning.

That is, instead of “YAML ain’t markup…” or “RTFM” or the like, perhaps it would help to dialogue on the potential benefits and then means of implementing the feature of “[linking] anything to anything…”?

The desideratum yet missing from our beloved Obsidian is a simple, standard, universal, and realtime/in vivo means of data disambiguation. All of the dataz, regardless of its type: link, object, string, meta, frontmatter, et al.

It would seem that addressing the absence, potential merits, and means of attaining this capability is most productive?

Instead of “let me count the ways this can’t work” because, reasons: YAML, Dataview, or other meta-califragilisticexpialidocious-ness…

[softplus]

Are there any updates on the status of this request? I’m relatively new to Obsidian and I’ve found that the metadata limitations, particularly the absence of link support, have been the main hindrance for me in the process of transitioning from other applications. I’d love to see this feature added.

[Mara-Li]

Why don’t using Dataview for links ?

[tobei]

To be honest such important feature should be in the design of the core product, so every single view (graph, search…) will exploit it, and every plugin can use and enrich on it. As long as a feature only lives in a plugin, it will always be limited to that plugin, never participate in any standard obsidian view, never be usable to other plugins. That’s why i feel it’s important to get informations about where and if the product is heading in term of design and if such notion-like features will one day become native or if they will be delegated in plugins.

[Mara-Li]

Tbh i don’t understand the point
First, Yaml doesn’t support link, it will be break every attempt to read frontmatter without Obsidian (from mkdocs to Jekill).
Also, you will always saw the link if you put in in a dataview so I don’t really doesn’t understand it.

Also, Notion use a native format that prevent the export outside Notion, and that’s not the point of Obsidian.

[tobei]

And so does obsidian flavor of markdown, which will also “break” here and there because markdown is one of the most poorely standardized language. What’s more important between limiting the functionalities because of a tool or changing the tool for having the functionalities? You get to a point where the chosen language becomes the excuse as to why necessary things can’t be implemented, and the tool becomes the hinderance instead of being the enabler. I can’t care less if it’s YAML, JSON… I can’t care less if a better thing than markdown is necessary, those are just tools, a mean to an end, it’s the end that matters, not the tool. I’m not doing markdown or YAML because they are super nice things, i’m doing them for the mean of structured, human readable knowledge management. If those tools stop being useful to express what I need, then they are no longer a tool but something to get rid of or evolved.

The need for a feature and how it can be implemented should never be mixed in the same discussion, the “but the current language doesn’t support” should never be an excuse to not do something if the feature is necessary. Even the most simple graph database (links as a first citizen promise, remember?) has attributes on both nodes and links. Not only links in obsidian are just barely hyperlinks, but if their most important concepts can’t even be used as attributes then they should just remove the sentence from the product advertisement.

Obsidian is knowledge management tool, not a markdown and YAML editor. The important thing is knowledge management, not how closely they stick to markdown and YAML. One is the aim of the program, the other is just ONE tool among thousands. If it doesn’t fit, change it.

[BarryPorter13]

Obsidian is used as a knowledge management tool, but that is not its only use.
Obsidian IS a PLAIN TEXT note taking app that uses Markdown to make notes
more readable, is multi platform (iOS Android OS, Linux (most flavors), Windows OS
and Mac OS), and is extensible. The programmers have no control over the YAML
Spec, nor the Markdown Spec. And remember, this program is basically on the line
between an Alpha and a Beta program.

[WhiteNoise]

@tobei

Obsidian is knowledge management tool, not a markdown and YAML editor. The important thing is knowledge management, not how closely they stick to markdown and YAML. One is the aim of the program, the other is just ONE tool among thousands. If it doesn’t fit, change it.

Well, I disagree here. Part of the mission is to be compliant with standards so you can take your notes somewhere else. If underling format didn’t matter, Obsidian could just save all your files in json format and handle everything internally.

Back to this specific topic. As I said in one of my previous posts:
It is likely that a single YAML attribute will be chosen for linking to other notes in the frontmatter (still following the YAML syntax). Something like

---
links: ["Note 1", "Note 2"]
---

---
links:  
  - Note 1
  - Note 2
---

It is very unlikely that arbitrary YAML fields will be parsed for linked or unlinked mentions.

It is more likely that Obsidian Core implements something like this

Native support for Inline (Intext) properties (`key:: value` a la dataview)

Use case or problem YAML can be unwieldy, and sometimes just doesn’t support certain values (e.g. links). It would also be great to give yaml fields in the content of a note. Proposed solution The Dataview plugin recently gave support for inline yaml fields in the content of a note. One can type key:: value in the body (not the frontmatter), and dataview recognises it as if it were key: value in the yaml. I propose that Obsidian supports inline fields so that other plugins can also use this f…

[Mara-Li]

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.

[tobei]

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…

[tobei]

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.

[pmbauer]

@tobei

Do you seriously think that putting obsidian .md files into a random markdown parser will give you anything near what you have today?

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.

[BarryPorter13]

@pmbauer

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.

[Ooker]

FYI:

Plugin idea: Metadata links indexer

There is a high demand for obsidian indexing front matter links. Until there is official support, I believe this would be a greatly appreciated plugin.

What does "link as first-class citizen" really mean?

The About page lists the philosophies of Obsidian: Local-first and plain text; Link as first-class citizen; Make it super extensible. At first I thought “Link as first-class citizen” simply means it will focus on links more than other software. But then I found out that First-class citizen has another meaning: In programming language design, a first-class citizen (also type, object, entity, or value) in a given programming language is an entity which supports all the operations generally av…

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.

It is hoped that Obsidian will not be bound by the framework of `.md`

With WYSIWYG, I don’t see that as a limit. If you take a look at the community themes, you can see how much people can achieve with CSS customization. I don’t believe it has anything to do with Markdown – typography can be changed entirely with CSS. Second, does the use of .md format also doomed Obsidian to miss some advanced features? Like a database? We have no plans to implement Notion/Airtable-like database functionalities, but that in theory doesn’t prevent plugin authors from turning …

[JSo]

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.

[AKlay]

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.

[CawlinTeffid]

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.

[CawlinTeffid]

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.

[LilaRest]

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