Wikilinks in YAML front matter

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

3 Likes

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?

You can use H1, H2 or whatever you want. No problem.
I personally use this template for my notes:

---
aliases: []
tags: []
---
sources:: []()
***

# Content Begins

2 Likes

Thank you for sharing.

  1. So in your case your can’t fold your on block?

  2. Is there any other way to make your block section fold without giving it a header above “sources::”?

  3. Is *** a different way to write a horizontal rule, just without the need of blank lines above and below?

  4. and just out of curiosity: how do you personally write multiple tags in your YAML? And do you use put your tags in " ? And with a # or not?

Hi @WhiteNoise,

this may be a stupid question but anyhow. What is the advantage to use the info on sources as inline meta data (sources::)?

Best regards

@SamAdams, One reason would be the limitations on using links in YAML front matter.

See for example explanation in:

And in:

Hi @Birgitte,
Thanks for the clarification. :+1:

Currently if I define

---
url: https://someurl.com
---

it will be interpreted as a URL (it will be shown as a link, not just a string). Same could be applied to [[]] notation, and we still have the benefit of autocomplete, something that won’t be available with alternative notations.

1 Like

Is the :: in sources:: using some sort of syntax for something or is that just your personal choice.

@SamAdams seems to think it’s “inline meta data” but I personally haven’t seen that syntax before and I don’t see it adding anything when I put it in my vault.

@DandyLyons - the key:: value syntax is used for the “Dataview” Obsidian community plugin: GitHub - blacksmithgu/obsidian-dataview: A high-performance data index and query language over Markdown files, for https://obsidian.md/.

2 Likes

Apologies if I’ve missed mention of this somewhere above, but why isn’t "[[…]]" the least bad option for syntax?

---
Link: "[[Note with \"Double Quotation Marks\" in Title#Heading|Display Text]]"
---

is valid YAML. Ideally Obsidian’s wikilink autocomplete function would detect that the context is a YAML header and escape the necessary characters.

Wikilinks in YAML headers simply being Command-clickable in edit mode would go a long way for me.

See also: Can [[wikilink]] in YAML ever be “done right”? NO. But there could be a “route of least pain”.

2 Likes

Hello, @WhiteNoise

Toying with this issue in my own notes. What is the advantage of having both a YAML block and a personal block?

Why not just use the personal-block double-colon format throughout and dispense with the separate YAML block?

Thanks

Angel

I believe this issue boils down to what the YAML block is for, the YAML block was intended to store per file settings/data of plugins. Some people have hijacked for the purpose of storing their content and are 1) unhappy because linked/unlinked mention don’t work there or 2) complain because their text doesn’t flow since they have to adhere to the YAML syntax.

I understand the needs of the users and perhaps we will revisit this other FR at some point in the future: https://forum.obsidian.md/t/native-support-for-inline-intext-attributes-yaml-fields-key-value-a-la-dataview/17092

4 Likes

Very grateful for the reply. Wasn’t adding to this thread as a means of asking for any change to be made. Was just trying to understand the rationale of keeping both YAML and personal blocks.

Thanks to your explanation, I now have a clearer grasp of how I can best structure my notes and make more use of the data I have.

Many thanks for sharing your time and knowledge.

Angel

1 Like

Correct me if I’m wrong, but one reason I can’t completely dispense with YAML is aliases. I don’t think it’s possible to create these with double colons and then have Obsidian recognise them when creating links. I’d love to be wrong about this.

Good point. I think you are right.

Thanks for sharing.

Angel

This is a great thread. It is about one standard that is constrained, but a suggestion is to add to that constrained standard an area dedicated to whatever a user would like to stuff in there.

Historically there have been two similar standards - for Information Managers there is the ‘Topic Map Data Model Standard’ standard (see https://www.isotopicmaps.org) and for older programmers there is Java Serialization (Serialization and Deserialization in Java with Example - GeeksforGeeks). Both of these are reducible to YAML if you beat yourself on the head until you figure out some way to put into yaml every conceivable object property type (serialization) and if you force every kind of identifier (in the Topic Standard, an Identifier can appear many times in the same record, each unambiguously identifying the subject of the Topic Object) into YAML - and that is before the user gets the power to write a non-YAML or a personalized user area.

To state this with less cleverness, the need being discussed is on the one hand some form of object structuring (by properties for now) where naming is standardized up to a point, and on the other hand the need for writing stuff with an understandable markup language. The markup language issue could be due to starting from nothing and getting some distance quickly as the most realistic dev approach (NOT because that is the way it was started, but because it was a realistic approach). The YAML markup language approach still works because it is easier to convey and requires less development of tools.

But there are stresses that will rise higher and higher on this. Add pointers / links —— oh, wait, how about pointers into this or that database for indirection / cross-referencing, or how about highly tuned references (Bluebook standards: 3 or four different standards each a ‘uniform system of citation for legal texts’), or some easy mobility standard where there might be 20 directories on a machine that are various versions of the same database so there has to be some ‘root’ for the object and for the database. This will go on and on while the object structure is developed. In some ways that is fun.

There are ways around it. For instance a simple tool and a simple base object structure could be developed for reading/writing a major part of the settled structure out into YAML (or some other newly accepted standard for the auto read/write portion). The tool could be improved over time to translate whatever is in the base area to the new standard (as it gets released), and accept other YAML that is being added to the released standard and writing it out in the new standard. This is the realistic method for moving properties with new data types into the object structure. It is used in versioning mechanisms for data and programs.

The real reason behind the need for these versioning / upgrading scenarios is complexity, and complexity grows. Notice the Topic Standard’s allowance of multiple unambiguous identities and thus identifier field values. With complexity, that structure falls apart. Consider that in the early 1970’s there were so many people with the same exact social security number that on a campus of 30,000 students it was anticipated that there would be 25 students with an overlapping SSN. At Penn State there were 3 students with the same SSN, and two had the last name of Murphy. That was all fixed with versioning and a lot of hassle. Main point is that there has to be this kind of mechanism.

Consider what it will be like if the mindmap gets more structured and solidified. Pointers will be used. Nice diagrams. BUT, what happens when the same topic appears with good reason in two different maps. Or, how about at two places in the same map. Or, how about if it is in different places in 50 maps, and where it appears is dependent upon outside variables. How about where it is a root in one map that allows only trees, but is also a root in a map that allows forests, and thus has to be moved down one layer. How about if the location of the topic in a map is dependent upon the ‘fuzzy set’ of relationships into it as compared to other children of a parent. That is a head scratcher but it is what happens when positions of topics depend upon variables on relationships.

There are other methods for handling this kind of issue. First rule - don’t get locked in (and handle the griping / misunderstanding / over-broad explanations). Second rule - don’t under spec - there will be almost obvious situations that can be handled early to save a lot of later pain. Third rule - listen a lot and listen early by outing opinions.

(Aside: I think Obsidian is going to good places, and I think I can help, so I will. Thanks for being there.)

D

3 Likes

Hi! I know you started this thread a long time ago. And I really wanted that same thing you did.

But after a million videos I found a solution that seems to be enough for me and it’s so simple that I’m baffled.

It seems that when you use :: in the body of the note it is picked up by dataview and you can use tags and links and they are all clickable in the tables.
So, other than not being “invisible”, which is nothing incredible because you can just create a header and hide the contents, and not being able to be read by some kind of other app, which is probably only important for specific purposes of which I am not aware, then it seems that everything else works.

Am I missing something?

See the attachment: and sorry for the weird names that’s just a test vault and I just write weird names instead of thinking of things hahaha

:thinking::thinking::thinking:

2 Likes

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)

3 Likes

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 tribesthings

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

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…

5 Likes