why do we have different syntax for bibliography and links?

zk_1000

of course this doesn't apply to everyone, but those that are using Markdown probably use similar conventions for their Zettelkasten:

• [[202008121800]] : wikilink to refer to another note
• @yoda2010 : citation link to refer to bibliography entry

Is there a difference in referring to a citation and referring to another note? Essentially we are simply referring in our note to another source in both cases. What would happen if we use the same syntax for both?

Is there a difference in the way we think about those references? Aren't we simply referring to content, regardless of the type of source? Can we treat ourself just like any other random author?

ctietze

I'm not sure I get what you're hinting at. I always found the way MultiMarkdown solved this to be quite elegant:

• [click me](https://example.com) for regular inline links
• [click me][link-id] for regular reference-style links
• [look me up p 123][#authorYEAR] for reference style citations

Sadly, most Markdown parsers don't support this (yet?), but I'd have loved to see [click me][[202012081542]] work. Another square bracket inside the other square brackets is considered illegal by most parsers, though ;(

This leaves us with the flexibility to cite [666][#ironmaiden1982] to tell Markdown processors to convert this to a citation, and [[ironmaiden1982]] for a structure note or whatever on the reference item.

The real reason to distinguish this is computers and tooling, I guess, to ansert your titular question.

zk_1000

@ctietze wow, you're right Multimarkdown really is elegant. I should consider using it.

The other thing is that link-id and #authorYEAR both are unique ids so i was wondering whether i need this distinction. For example, i could use [look me up][#authorYEAR] and [look me up][#202012081542] because i don't see a difference in providing the source for a citation and providing the source for any referred information. As long as there are no collisions a key is enough for computers to find as much meta data as i like and process it in a smart way (using a combination of YAML, bibfiles, etc).

When i want to refer to something, a link is a link is a link. However, i am now reconsidering and think it is not a good idea because it does pollute autocompletion. So there are some usability issues with software.

ctietze

Back in 2010 or so, I linked notes using [click me][§202012082234]. Similar to how MultiMarkdown extended what Markdown reference style links already did by using the hash-prefix ID convention, I figured the § prefix might work as well. Becuase in the end, as you said, everything is a link then: You just need a pre-processor to append the link definitions on your behalf automatically, like [§202012082235]: file:///Users/foo/notes/202012082235.txt or whatever. Then it's 100% Markdown compatible then.

Why add a prefix at all? So you can tell Markdown pre-processors (and extensions like the MultiMarkdown software tools to convert md2pdf) what which reference thingie means. Some are regular hypertext links, e.g. for web addresses; some are citations and should be rendered differently; and some are Zettel links in the file system.

The tools never made it into existence, and [[wiki links]] are far better known. This is another convention to pick up, but one that also transcends Markdown, for those who don't care about Markdown. It's a totally different compromise, but as you can see when you look around the note-taking app space of 2020, that idea was picked up by quite a few other tools with ease! And having a compatible note format that works with multiple note-taking apps ultimately was more important to us.

holland

@ctietze said:

• [click me](https://example.com) for regular inline links
• [click me][link-id] for regular reference-style links
• [look me up p 123][#authorYEAR] for reference style citations

This leaves us with the flexibility to cite [666][#ironmaiden1982] to tell Markdown processors to convert this to a citation, and [[ironmaiden1982]] for a structure note or whatever on the reference item.

Perhaps my question is more appropriate for the Plug-in Beta category, but I'm both a new poster on this forum (I have periodically trolled for answers to little questions I have) and one of the new beta testers of the Plug-in. I am not a programmer so my question will come off as hopelessly naive to the advanced folks that explore the deeper recesses of digital note-taking apps. With my disclaimer said, here's my question:

I really quite like the potential of the Statistics of All Tags plug-in and find that it works as designed, sort of. Some background on how I work. I learned from @ctietze how to use Markdown syntax to cite sources with cite keys many years ago in his original tutorial on the subject, which is summarized in the short bullet points above. Although a struggle to wrap my head around at first, I grew accustomed to the syntax habit of using a hashtag in a cite key as shown above. I use Text Expander to store my cite key snippets and use Bookends to archive my sources. I like how quickly Bookends can generate Bibliography and citation references, although the cite key aspect of Bookends is difficult to grasp (for me). And perhaps this last piece of background data reveals the place where I'm having trouble with the potential of the Statistics of All Tags plug-in.

The issue: Since the Markdown syntax uses that hashtag to identify all tags (I understand tags), the plug-in thus lists all of the sources in which I've used a hashtag. However, as I hope my reader(s) can imagine at this point, those sources aren't intended to be tags in my little Zettel world.

Solutions: Given my technical naivety, I imagine that there is a simple solution on my end. I've tried, eliminating the cite key hashtag in a test file, but that breaks the elegant markdown footnote citation I've come to rely on. It appears to me that the hashtag is essential. When I look at my Bookends settings, I see that there are other types of syntax by which to create cite keys, but these settings go way over my head. And of course, perhaps there might be some sort of adjustment to the Statistics of All Tags plug-in that would ignore my cite keys when counting tags.

Sorry for all the words, but I needed to make an attempt at making my question clear. And to whomever moderates this forum, you may want to move this to the plug-in area. I just didn't know how to respond to this post but move it myself to a more appropriate space. I just happened upon this helpful post while looking around for some help on my little issue.

If I'm not clear enough I invite follow-up questions. Just know that I don't check in here daily.

ctietze

Good point: if a program is looking for #tags like this, it should be aware of [#authorYEAR] citation exceptions. (If the current plug-in implementation you mention isn't doing that, I'll fix that!)

Will

When I put a citation like [666][#ironmaiden1982] in a note and run the 'Statistics of All Tags" plugin, I don't get #ironmaiden1982 in my tag list.