Any ideas or existing implementations on markdown link metadata?

Features
1

When I say 'markdown link metadata', I mean arbitrary metadata added to a link in a Markdown note. And I count 'images' as a subtype of links, so this applies to them as well.

I've been thinking about this for a long time, because I think it would enable a lot of interesting use-cases. This post is just me thinking out loud bout the possibilities; I'd like to know what y'all think.
So here is my overview, my ideas on how this could be used, and my questions.

Overview: From what I've seen in the wild, there are a few approaches of adding more info to the MD link. The most common ones were either adding more data to the URI part, like image width:

![my pic](:/url 640x480)

or link title

[Make URL shady](http://www.shadyurl.com/index.php?e=blank "some title here")

There are variations to both of the above. In Joplin, the 'title' works, but no variation of the image-resizing that I've tried does.

Another approach I've seen is like this:

[Make URL shady](http://www.shadyurl.com/index.php?e=blank){ additional things here }

With the contents/exact syntax of the curly braces wildly varying. This brace syntax is also often used to decorate the preceding element with css formatting info.

The latter syntax seems better to me, because it has less chance of breaking when you export the MD into a different application that does not support it. (For instance, the width-setting syntax just stops otherwise valid image link from rendering in Joplin.)
The curly-brace syntax also seems more flexible and could support arbitrary data. Either as a single value ({ spoiler }), or perhaps as key-value pairs ({kind: parent}).

First question: Do you know if someone already made/proposed a 'standard' version of attaching additional information/metadata to links?

What I imagine it would be great for: besides the obvious uses already mentioned, I think simply being able to attach arbitrary strings to links could be useful. @SeptemberHX already uses something similar to set image width and captions. And I think the various Graph plugins, or @ylc395's Note Link System could benefit by displaying a different 'category' of link.

An example: I make a note about the use of FTL travel in sci-fi literature. I add links to my notes on books A, B, and C. I also want to note that in books X, Y and Z there was no FTL, but the idea was nicely subverted, worked around, or whatever.

After that, when I switch to any of the linked notes (A, B, Z...) I can always see the FTL note in the backlinks; but at a glance I can't tell if I've linked from it because the note I'm looking at is a direct exaple (or a "is-a" relationship, if you will), or a counterexample, or a subversion, or just a random link with no deeper meaning implied.

If I could mark the links with data like, say, {kind: example} or {kind: related} or {kind: subverted}, that is something that Backlinks could then show me. Or group by. Or a Graph plugin could link by different kinds (or colors) of arrows, for example.
Or it could be used to filter links/images based on their category/metadata...

What do you think? For me, Joplin has become a really powerful tool with its native features and many great plugins. This kind of functionality is what I currently miss the most and I think it could make my notes much better organized and powerful.

Haven't seen much discourse around this topic though, so I'm not sure if anybody else really needs this. (And yes, I know this wouldn't be quick and easy to implement.)
Or maybe there already is a solution, I just don't know about it, and could have spared myself a lot of writing? If so, post a link pls. :grin:

2 Likes
2

This is just part of commonmark - CommonMark Spec

A link contains link text (the visible text), a link destination (the URI that is the link destination), and optionally a link title

There are a whole bunch of other things you can do within the title section in regards to text and formatting but nested links are banned.

Reference links are a useful feature I don't see talked about too often and I think these could be a prime candidate for abuse.
You essentially have three parts, link text (like a normal link), link label (which links to somewhere else) and a link label reference which contains your actual location.

e.g.

[link text][link label]

lorem ipsum...

[link label]::/eaa0ac795a954df09982c1a96c760b28

I can imagine that it would be relatively easy to use that link label to contain metadata for categories without breaking anything. For example this works:

[this book][Type:book, Title:Cats]
...
[Type:book, Title:Cats]:http://cat-book.com

Otherwise if these aren't sufficient then at the risk of creating yet another standard (obligatory xkcd), with the prevalence of markdown based or markdown-supported note taking applications it almost seems sensible to have a new "markdown-notes" specification that would allow portability of markdown based notes to different applications that can leverage common features.

The issue of portability is something though - Joplin has a bit of advantage storing notes in the database where anything Joplin specific can be 'trimmed' when exported to pure markdown (like the internal ids do). Apps relying on .md files don't really have that option. It also means that some degree of conversion would need to happen when opening notes in external editors.

There are a number of interesting solutions to the problem - there was a markdown editor I found particularly interesting with its implementation of text and image manipulation.

To sum up, no idea, I've been randomly pecking away at this reply in between pointless messages from work and lost track of what I was trying to say more than a few times. It really is a case of either trying to work around the existing spec or making your notes technically incompatible with actual markdown which reduces portability.

1 Like
3

Thanks for sharing your thoughts.

The main issue with this that I see is how cumbersome it is to use, in many ways: No tools that I'm using is generating MD links like that. It's more annoying to write manually. And I dislike how it reduces the glanceability of the MD note, when viewed in pure text mode. (You don't just see the URL; you have to go hunting around the file for it.)

Personally, I don't see that as too big of an issue: the important thing is that if you import the note to an app that doesn't support those features, the rest of the MD shouldn't be broken.

For example, if you import your MD note heavily using some GFM-specific syntax into an editor that doesn't support GFM, you will get a bunch of semi-legible text. It's not great, but you didn't lose data, and you can just ignore that bit.

That's what I think any link-related functionality should aim for: if your new app doesn't understand the {meta: data} after a link, it will simply ignore them. The worst-case scenario is that it just shows up as text in your rendered markdown view, which is not a problem and can be easily solved. (Here, by 'not a problem' I mostly mean that in the context of switching note-taking apps: if the only problem you have is a few superfluous braces, I'd say your migration went well.)

In Joplin, it currently is even better:

image
image910×104 4.51 KB

No issues at all. And I suspect this would be the case in multiple apps.

4

This is kind of what I'm getting at by the differing standards, if everyone goes their own way then it could actually be breaking.
For example if we have Joplin supporting this syntax somehow but then YetAnotherNoteApp adopts the same syntax for a totally different feature then it completely breaks the portability between the two as neither are conforming to a specification yet both are syntactically correct so far as the other is concerned.

I know it is unlikely and I'm not being critical of your ideas, just playing devil's advocate and thinking of worst case scenarios.

Personally I don't use plugins or features that deviate from the supported markdown standards because I want my notes to behave the same no matter where I put them without requiring manual conversions which most of the time just means using HTML.
I sometimes use pandoc for making my markdown notes into something else so again, if it isn't supported there then I don't want to use it for fear of breaking stuff that I might not even notice until it is too late.

5

Yeah, that's why I started with googling and asking if anyone has already addressed this. It's often better to just use what already exists.

Yeah, I totally get this. I'm heavily leaning toward this myself.
However, there are still improvements in note-taking I'd like to see, and they're clearly impossible in commonmark and any other popular markup language I know of. So I'm also willing to experiment a bit - as long as the only thing that potentially 'breaks' (or regresses to just dumb text) is the new content.

6

Interestingly it looks like this has happened to the curly brackets already with Markdown extra and Multimarkdown does use the reference links I mentioned to allow styling attributes to be added to links images. (I should note I only just came across these in the last few mins).

7

Ah, thanks. I knew it had to be some standard or another, because of the number of times I've encountered the same syntax. Obviously my google-fu failed me.

8

Do you have a plugin installed for this? I can't see it doing anything with base Joplin:

image
image723×232 11.4 KB

9

... ah, the obvious question. :woman_facepalming:t2:
I didn't think I had a plugin that did that, but I have quite a few, so that's completely possible.
Should have occurred to me to check.
Gonna remove that mention from the previous post.

1 Like
10

But I guess it being in multimarkdown, that also means there is precedent, and maybe I could try begging for this to be included in some of the plugins. Ideally in some standardized way, and using data-attributes. :joy:

1 Like
11

could this be related to this NLS feature?

1 Like