How to deal with arbitrariness when using object tags for qualities?

FernandoNobel

Hello!

Yesterday, I experienced a situation that I'm surprised I didn't notice before.

When we use object tags, we seek to identify the objects interacting in a note's main argument. However, there are times when those objects may refer to qualities one may or may not have.

For example, let's imagine I have two different notes where I explain the following ideas:

(1) Being too strict causes problems
(2) Being too relaxed causes problems

In note (1), we could identify the object tag #strict. While in note (2), we could identify #relaxed as an object tag. However, the important point is that this decision is arbitrary. I could perfectly well have written the notes as follows:

(1a) Being too strict causes problems
(2a) Being not enough strict causes problems

or

(1b) Being not enough relaxed causes problems
(2b) Being too relaxed causes problems

In notes (1a) and (2a), I would have identified #strict. In notes (1b) and (2b), I would have identified #relaxed. However, all notes talk about the same object idea: there is a right amount of strictness/relaxation that avoids problems.

So, my question is the following:

• How would you handle this situation?
• Do I accept this arbitrariness and continue using both object tags?
• Or, do I try to find a way to avoid this arbitrariness?

---

The example I showed is a simplification of a text I am processing about Semantic Versioning: https://semver.org/

The paragraph that provoked this situation was the following:

If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable)

Using too tight or too loosely dependency specifications casues problems :-)

ctietze

With the semantic versioning example, I'd actually not put "strictness" or so in the tags, but look for technical terms. Like #incompatibility and #dependency #resolution maybe.

I know that doesn't answer the underlying question: which side of a pair of opposites to pick? less/more, good/evil, lawful/chaotic, ...

Sometimes, it's better to go up a level of abstraction to replace good/evil with "alignment", like I did above.

Writing about the nature of evil in the world is obviously about #evil, directly, not about #good. If it's both, a pro/con comparison, then it's both.

For some terms that are synonyms, you can use as many as you can come up with to err on the side of caution. Or you try to force yourself to favor one over the others with tool automation that replaces tags for you and keep a list of synonyms around. -- I have one about "keyword" and "tag" in German (Stichwort/Schlagwort) with the intent to help me remember which to use when, for example, but it's just a weak aid that almost never comes into action

JasperMcFly

Definitely go up one level of abstraction; "dependency specifications-qualities"

andang76

I don't use tags, but your use case is very interesting.

For me the two (principle) notes are closely related each other (they are the sides of the same medal), they should be tagged with the same tag.

I've trouble finding the good common tag, anyway :-).

As @ctietze stated, maybe it's better having a more abstract one. In this way you can also include with the tag other notes that may be related.

Something like #interface-design-guidelines or #api-design-guidelines

I'm thinking that the the two notes represents together a tradeoff. I'm thinking how to best represent a tradeoff in this case.
In my model, I most likely would write a tradeoff note that links the two principle notes, tagging this note.

How to model a tradeoff wil be my evening thought today :-)

Sascha

How would you handle this situation?

I'd have a specific concept that would be implicitly mentioned in the notes. Or, also likely, don't tag it with anything like #strictness because it is not one of the main concepts used as a building block for the idea at hand.

tjex

I also don't use tags like this. But if I had to, I would try and find the underlying core concept of a note, as they will have more overlap with other notes, and therefore be more fruitful when searching.

So I may end up tagging both notes as such: "trade-offs", "decision making", "consequences".

The problem is that if you don't manage to tag all notes that deal with these concepts, then when you reach for the tag filter to reveal what you have on the topic, you could well miss out on some good past ideas!

Therefore, always backup tags with good linking!

p.s If you're interested in some more detail than "I don't use tags like this", I wrote it up in a blog post, the discussion of which is here on this forum

FernandoNobel

Thanks @ctietze , @JasperMcFly , @andang76 , @Sascha and @tjex for your answers!

You have helped me to go much deeper into the use of object tags :-)

I have finished processing the whole Semantic Versioning webpage. Now I have an overview of how all the ideas fit together and I can clearly see that using #strict and #relax are not the most useful tags. These tags were not object tags (in the notes I am not talking about strictness or relaxation), these tags were qualities of the core object of these notes (which I was not able to define explicitly at the beginning of processing Semantic Versioning).

What is the core object?

Let's imagine I am developing an application that depends on a third-party library called lib_A. I can define my dependency on lib_A in different ways:

1. lib_A == 1.1.0

   In this case, I am defining only lib_A version 1.1.0 as compatible. This situation gives rise to the version lock problem.

2. lib_A >= 1.1.0

   In this case, I define that all versions equal or higher than 1.1.0 are compatible with my application. This gives rise to the version promiscuity problem: I can't really be sure in advance that this will always be true.

3. lib_A >= 1.1.0 AND lib_A <= 2.0.0

   This is the semantic versioning solution: the widest range of versions of a dependency that you can guarantee is safe to use.

Thus, the object is the range of versions of a dependency. This range can be narrow, wide, safe or unsafe, but those are just qualities that it may or may not have in a given situation. So, the object tag I'm going to use is: #dependency-version-range

Finally, I really liked how the search for good object tags is a way of:

• sharpening our thinking
• making explicit ideas that are implicit.

JoshA

I think #dependency-version-range is too narrow in my opinion.

Long after haven written the note, I don't think I'd ever specifically remember to search for #dependency-version-range, so if tags are search tools (and not just thinking tools), maybe something more general would be better.

Ofc if it's a major topic of research, maybe it would make sense. But these kinds of tags I only end up putting on one note, and never searching for again.

FernandoNobel

@JoshA said:
I think #dependency-version-range is too narrow in my opinion.

Long after haven written the note, I don't think I'd ever specifically remember to search for #dependency-version-range, so if tags are search tools (and not just thinking tools), maybe something more general would be better.

Ofc if it's a major topic of research, maybe it would make sense. But these kinds of tags I only end up putting on one note, and never searching for again.

Does a narrow tag (used in less than five notes) have value as a search tool?

As you point out, we need to be able to remember the existence of these tags in order to use them as a search tool. So the problem is how to remember tags that we use in a very specific way.

The strategies I use are as follows:

1. I use a fuzzy search engine for tags. This way, I don't need to remember the exact words. For example, by typing "version" the tag "#dependency-version-range" would appear in the results. However, this is not a foolproof method.

2. Before creating a new tag, I always do fuzzy searches to make sure I don't have any similar tags. If I ever create more tags about "dependency" or "version", I'm likely to find #dependency-version-range, which allows me to use that tag if it makes sense, or at least to remember that the idea exists.

3. Processing these ideas thoroughly makes it easier for me to remember the concepts. I'm unlikely to forget #dependency-version-range. And, if I do forget, I will probably still have a vague memory that I processed this idea one day.

4. When I browse my structural note on semantic versioning, this note will remind me of the existence of this idea and its corresponding object tag.

5. I believe that an important part of the creative process is forgetting our ideas. If you have forgotten a valuable idea, you are likely to rediscover it in a different context, which can lead to some really interesting new connections. Or, if the idea is bad, you've simply forgotten a bad idea :-)

In short, I think the assured value of such tags is their value as a thinking tool. The value we get as a search tool is more uncertain because there is a risk of forgetting that tag forever and never using it to search.

Sascha

Ah, I overlooked the paragraph:

If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable)

These would be my tags: #versionlock #versionpromiscuity

The tag "#dependency-version-range" would be either a topic tag or you consciously add it as an implicitly used object, similar to the note in the course (#attachement as an implicitly used concept in the definition of mindfulness)

"#strictness" would only be necessary if you build up notes that concerns themselves with the concept of strictness specifically. But this is also domain specific. In my Zettelkasten, #strictness would bring together all kinds of notes from all kinds of domains, moving my thinking into a pretty high meta altitude. So, in your case, a specific term from the domain of coding might do the trick.

If dependency-version-range is a topic that you think a lot about, the tag will likely loose its function when you start with a structure note to structure your thinking and knowledge.

FernandoNobel

Thank you @Sascha for your explanation :-)

I think I already have the whole overview of how to work with object tags. However, I think I have to train my practical skills in identifying and defining object tags.

This reminds me of when I was learning chess:

• First, I learned the theory of the London system.
• But that was not enough to play the London system well.
• I had to train my skills in the real world.

Maybe I could come back to old notes (one or two years ago) and do some drill sessions to train to identify and define object tags (as those notes were not properly tagged). Has anyone tried anything like this before?

Loni

Does a narrow tag (used in less than five notes) have value as a search tool?
As you point out, we need to be able to remember the existence of these tags in order to use them as a search tool. So the problem is how to remember tags that we use in a very specific way.

If I have to use a very narrow tag, I'd rather create a structure note for this specific topic, with explicite question into its title to facilitate futur search and seek.

@FernandoNobel

Maybe I could come back to old notes (one or two years ago) and do some drill sessions to train to identify and define object tags (as those notes were not properly tagged). Has anyone tried anything like this before?

I basicaly did that a lot of time trying to refine my ZK system. You could end up having a first reading object tag idea, refactoring your note and then changing the object tag.

As I struggle to find cohesion into my previous shattered over complicated system, I ask this basic questions to myself before adding tag or anything : "what cluster I want to see emerge? What will my futur self will need to find and to read to understand the thread of thoughts? Is it important to leave this breadcrumb, for what purpose?".

If those notes are related to a very precise subject and become an answer to a precise question that you will need to documente later in the futur, you should choose maybe to write a structure note to articulate this precious answer with links to the specific answers you noted. If those notes take parts to a more global chain of thoughts, a more abstract object tag like the ones that other suggested should do the trick.

FernandoNobel

@Loni said:
..."what cluster I want to see emerge? What will my future self will need to find and to read to understand the thread of thoughts? Is it important to leave this breadcrumb, for what purpose?".

Thank you for these questions, they are really useful :-)