Unifying tagging and linking

srid

Hello,

I'm the developer of neuron, and I'm interested in your feedback on a syntax proposal unifying the notion of tagging and linking.

Background: In neuron you can link to another zettel [[like this]], and tag a zettel #likeThis.

But is tagging really distinct from linking? The following proposals seek to unify them.

• https://github.com/srid/neuron/issues/379
• https://github.com/srid/neuron/issues/514

The second proposal is of particular interest here. The unification is done in two steps:

1. Extend #likeThis syntax to #[[like this]].
2. Allow any character to the beginning or end of square bracket linking to denote the "label" of that link

Here, # will signify a folgezettel label. And when you link as #[[foo]] then, it means that a connection of type folgezettel is made from "foo" to the current note. When you just link as [[foo]], the same connection is made, but without any connection type (i.e., it is not a folgezettel).

Now what if we flip the direction of the character? When you link as [[foo]]#, the same connection, of type folgezettel, is made - but the direction of the connection is reversed. Instead of "foo" linking to the current note, it is the current note that links (i.e. branches) to "foo".

So, in effect, tagging is essentially no different to linking. By unifying both, we allow users to enrich their links with two concepts: labels (eg: folgezettel) and directionality - both of which aren't possible in current wiki-links syntax. Interestingly, implementing this proposal should not break any Zettelkasten software.

On final note, there is a potential for the user to use arbitrary characters to denote a custom link label ...though, for this proposal, implementing the above syntax would be sufficient. Thoughts? Feedback?

srid

I posted a submission here, followed by a small edit. Immediately the post vanished. Could an admin please resurrect it?

It is dissapointing to see this happen after having spent significant time signing up on this site to write a post inviting feedback from others.

The supposed URL is https://forum.zettelkasten.de/discussion/1604/unifying-tagging-and-linking/p1?new=1

srid

I was able to resurrect the post content from my RSS reader, and it has been re-posted here, fwiw: https://www.reddit.com/r/Zettelkasten/comments/kqjw0a/unifying_tagging_and_linking_markdown/

GeoEng51

@srid I noticed that tagging is something that is used in a number of ways by people on this forum. Some use it a lot, some a bit, some not at all. Some think tagging is quite useful; others not so much. Some think you should tag topics; others think you should tag objects. There is a mild undercurrent of debate on all this, but it's not a highly passionate one.

I see tags and connections as being very distinct but complementary "tools" and in my practice of ZK, I wouldn't want to combine them.

One of the strengths of the Zettelkasten system is its flexibility, particularly in how people develop and use various aspects of the system, such as structure notes and tags. I'm all for maintaining that flexibility. It seems to me that trying to marry tags and connections will make the system less flexible.

brennen

While I don't have a strong opinion about syntax for link type and directionality, I'll chime in to say that I've been treating links and tags as equivalent in personal hypertext systems going back to WalaWiki in maybe 2005 or thereabouts. I've found this to be a pretty helpful pattern, and one I wish more systems were consciously designed around.

A rich enough set of tools for working with links generally should allow any number of tag schemes to be built on top, depending on user preference.

srid

@brennen Yup, that's exactly the goal behind this proposal. It is part of a larger goal to simplify the Zettelkasten setup. I do believe that everything can be, ultimately, reduced to notes and links between them (i.e., a directed graph); and many extra functionality (like tags) are frivolous.

@GeoEng51 The loss of flexibility would depend on the software being used. The plain-text notes themselves would still have the exact same relationships (regardless of the syntax change, such as from #foo to [[foo]]). That said, my goal is to implement whatever workflows tags normally facilitates but using links instead. For eg., you can implement structure notes (or neuron's uplink tree) using links instead of tag rather easily.

ctietze

(The editing of the post triggered our spam filter. I approved the post and merged the original discussion with the comments that came later.)

MartinBB

@srid said:
frivolous

Hmmm -- not the way I would use this word! (Which tends to have the meaning of "silly" to someone of my age and background.)

Since we are talking about "other software", I thought I would mention Tinderbox. One of its most obvious features is the almost infinitely extensible metadata it is capable of holding. If you can think of some item of metadata that would be useful to add to your notes, you can create it yourself. This allows you to filter and arrange (and even alter) your notes in all sorts of ways that don't seem to be possible with other programs. The point I am making is that metadata can be useful, and sometimes in ways that we can't immediately see. It seems to me that reducing the amount of metadata available is not a good idea. In my usage, tags and links are very different things, and I use them to do different things.

msteffens

@srid, see this previous thread that is related to your topic.

As mentioned in that thread, I think it's good if tags (actually, all knowledge elements) are represented by plaintext notes. However, personally, I wouldn't want a new syntax for tags. Software could keep the existing syntax and still have tags represented as plaintext notes.

W.r.t. link types (aka "typed links" aka "semantic links" aka "qualified links" etc), this thread is worth exploring. In my own app, I've implemented a syntax like [[optional link prefix(es)::LINKID]] (e.g. [[refutes::LINKID]] or [[based on::confirms::LINKID]]) which is similar to what others use (e.g. Semantic MediaWiki), and it works quite well. And, unless I didn't understand you correctly, such a syntax strikes me as more flexible and also easier to parse.

Sascha

From a perspective of syntax there is nothing really to object.

I miss thinking in the direction of user experience and the methodological layer.

---

By unifying both, we allow users to enrich their links with two concepts: labels (eg: folgezettel) and directionality - both of which aren't possible in current wiki-links syntax.

It is possible without sacrificing the ability to just tag if you just use your linking syntax additions.

brennen

As best I can tell, "just tagging" is a thing that can always be accomplished in a links-are-tags-are-links system merely by namespacing the links in one way or another.

As a concrete small-scale example of this, I built a tagging system for my blog a while ago:

https://p1k3.com/topics

Those "tags" are modeled as a kind of link from one entry to another (stored in the file structure of the blog rather than the text of the entries, but that's an implementation detail). There's no reason that the entry for 2021/1/1 couldn't be "tagged" to the entry for some other date; it's just a convention that tags go to something in the topics namespace.

Having written this out, though, I have to acknowledge one important distinction in a tagging system based on pure inline hypertext links: If every link is a tag, then you can't really refer to a tag without being included in it. In practice, that hasn't been a problem for me, but it does suggest a reason you might want/need types of link relationship.

micahredding

I do wish [[wiki links]] would behave like #tags.

In the context of The Archive, this would be a literal search:
[[wiki links]] = "wiki links"

Rather than an AND-based search:
[[wiki links]] = wiki AND links

I consider this distinct from ID-based links:
[[202101101038]], or [wiki links][[202101101038]]

I would suggest putting metadata and labels in a similar form:
[folgezettel][[wiki links]]
[-->][[wiki links]]
[<--][[wiki links]]

ctietze

@micahredding said:
I would suggest putting metadata and labels in a similar form:
[folgezettel][[wiki links]]
[-->][[wiki links]]
[<--][[wiki links]]

This used to be the Markdown "extension" I dreamed of, since you could fallback to treating these like regular links. Alas, virtually no Markdown parser is compatible with that. They don't allow additional square brackets inside the link reference definition

micahredding

On the broader topic of unifying tagging and linking, I've wondered about switching from Zettel links syntax to a tagging syntax. Eg, from this:

[[202101121335]] A note on topic X

to this:

#202101121335 A note on topic X

This seems like it would allow you to imitate Markdown citation syntax if you wanted to, making links look like this: [A note on topic X][#202101121335]. It's also just conceptually slightly more cohesive.

Any reasons to avoid doing this? Any benefits to doing so?