Synonymous tags

[banan314]

It would be great to have synonyms for tags, like on Stack Exchange (SE).

Thanks to it, it'd be easier to search for a tag and it's easier to tag notes.

SE

On SE, we have a tag info and a manager with details.

I need about 200 points to be able to create new synonyms, so I can't show how it looks right now, but I will update this post here when I reach 2500.

Suggestions for Joplin

Of course, in Joplin we need a little different things. I suggest the following feature parts:

• manager for tag synonyms
• create, delete and update tag synonyms
• one tag is the main tag for a synonym group
• in the tags view, show only the main tag and synonyms on hover
• searching for a synonym has the same effect as searching for any other tag in the synonym group
• on the tags below the notes, the tag that was added to a note is shown
• tags are added to a note as is, not the main tag

For shared notebook

proposing, voting and accepting a new tag synonym would be a dream for a shared notebook

Use cases and benefits

Many people know use more than one language. I use 5 languages and I don't remember in which language I tagged a note, so I use a tag in many languages for a single note. It creates a mess. It would be better if I could create a tag synonym for each language for a word.

Search for a tag synonym is easier.

Tags view would be cleaner that way - less tags to look at.

Emoji tags would make sense.

Words have synonyms as well or are very similar, like dove and pigeon. We don't want to have to remember if we used one or another.

UPDATE

I scored 2500 and I can present more of the tag synonyms interface on StackOverflow.

You can click Synonyms after you searched for a tag.

where you can suggest a new synonym for it

[graphit0]

To adjust your idea to Joplin terms, how do you think, can synonyms for tags be achieved using hierarchical tags?

Say you marked a note with a tag dove that's inside a tag tree called birds. For example:

birds
  large
    eagle
  small
    dove
    pigeon

Now, ideally you could be able to search notes by the root name of tag tree (which is birds) not specifying what tag exactly you're referring to.

The search might look like this. The symbol '*' might signify any other item inside the structure, say 'birds/small/dove'

tag:birds* // for finding all notes containing the tags in the tree
tag:~dove // for finding all notes containing same level tags as `dove` in the tag tree
// I imagine tilda (~) is not the best implementation of it, so suggestions are welcome

Note that for now it's purely hypothetical exercise as hierarchical tags are yet to be implemented. However, it might be a useful use case to consider when the time comes.

Anyways, what do you think of this way to achieve the functionality of tag synonyms you're proposing?

[banan314]

We have to be cautious with searching by root name. If we had a hierarchy

fish
  large
    stockfish
    salmon
  small
    sardine
birds
  large
    eagle
  small
    dove
    pigeon

searching for birds shouldn't return notes about fish. Is it feasible? Yes, if all notes with eagle have tags birds and large as well. Otherwise, it would also hit salmon I guess (birds, so large and small as well, so one of them, so large, so salmon as well.

We could search only for notes with birds and large at the same time, but wouldn't it be cumbersome to a user? We can make all eagles have tags birds and large as well, but an implementation challenge comes about.

Instead of ~, we can use +, like CSS sibling selector.

I don't want to be forced to write tag: though. Simple +tag as a shortcut would be great.

Overall, I think it's a good idea.

[graphit0]

@banan314

We have to be cautious with searching by root name.

Fair point. Moreover, I'd say we have to be cautious about duplicates in tags in general.

The previously attempted implementation of hierarchical tags was designed around tag structure divided by slashes tag/subtag (in this PR). That way the tag dove is technically birds/small/dove.

In this context, as far as I understand, if you search for notes with large tag, you'd have to explicitly specify what tree you're searching in or get the results from both tag trees (fish and birds) by encapsulating large with *. Yes, it might be quite cumbersome to type the complete path to a tree, so having a drop-down with path suggestions would be highly desirable.

For example, tag:birds/large would return only notes containing the tag large inside birds tree (i.e. birds/large tag)

Subsequently tag:birds/large* would give you notes with eagle and birds/large tags.

If you search for tag:large I imagine the search would expect the tag large to be outside of any tag tree (has no parents or children) or a root parent of a tag tree. In our case, large is not a parent and there's no root parent called large therefore the search would give no results.
I agree it might look confusing having 2 tags large in 2 tag trees and there's no search results via tag:large but it is how it was imagined. Any suggestions?

To get the results from fish and birds trees, I imagine, you'd need to search for tag:*large*. It gives the results for notes with birds/large, fish/large, stockfish, salmon and eagle tags.

Furthermore, you use the sibling selector + If you want a synonym of large inside the birds tree, i.e. small tag : tag:birds/+large

A tree of synonyms, gives you notes with dove, pigeon and birds/small tags: tag:birds/+large*

@banan314

I don't want to be forced to write tag: though. Simple +tag as a shortcut would be great.

Oh well, that's our search syntax. Changing it is whole another topic. I suppose you could create another tread and illustrate your suggestions.

Data and search examples

The user view tag tree

fish
  large
    stockfish
    salmon
  small
    sardine
birds
  large
    eagle
  small
    dove
    pigeon

Technical view of tag tree

birds
birds/large
birds/large/eagle
birds/small
birds/small/dove
birds/small/pigeon
fish
fish/large
fish/large/stockfish
fish/large/salmon
fish/small
fish/small/sardine

Search	Notes with tags
tag:large	no results
tag:*large*	birds/large birds/large/eagle fish/large fish/large/stockfish fish/large/salmon
tag:birds/large	birds/large
tag:birds/large*	birds/large birds/large/eagle
tag:birds/+large	birds/small
tag:birds/+large*	birds/small birds/small/dove birds/small/pigeon
tag:birds/+	birds/large birds/small

Sibling selector sign

Having written those examples, I start to think that sibling selector is more logical to be - rather than +. Writing a plus and expecting exclusion of the item is a bit weird behaviour. What are your thoughts?

[banan314]

@graphit0

In this context, as far as I understand, if you search for notes with large tag, you'd have to explicitly specify what tree you're searching in or get the results from both tag trees ( fish and birds ) by encapsulating large with * . Yes, it might be quite cumbersome to type the complete path to a tree, so having a drop-down with path suggestions would be highly desirable.

Sorry to say, but such a solution would become unusable. It would take too much time to input it and we would never take the main advantage of synonymous tags search - we don't want to remember what tags exactly we used for a particular note. Because that's what it's all about - we don't want to remember what synonymous we attached to the note. Having to type the whole path makes it even worse - we have to remember not only the particular tag, but also the whole path leading to it. It sounds horrible!

@graphit0

If you search for tag:large I imagine the search would expect the tag large to be outside of any tag tree (has no parents or children) or a root parent of a tag tree.

Please keep in mind that a tree with only one element is also a tree, so if a tag has no parents or children, it is a root of a tag tree as well.

---

My idea is that we get the results for tag siblings if they are all leaves at the same level and they are not roots. In other words: if I'm a tag, I have a parent but no children, I'll give you the results for all my childless siblings.

In our user view tag tree, modified a little:

fish
  large
    stockfish
    carp
    salmon
      roe
      run
  small
    sardine
birds
  large
    eagle
  small
    dove
    pigeon

we would get the following search results.

Search	Notes with tags
large	no results
birds	tags pertaining to birds only, not fish
dove	birds/small/dove, birds/small/pigeon
stockfish	fish/large/stockfish, fish/large/carp

[banan314]

We discussed the feature with @graphit0 and have come to a conclusion that we cannot kill two birds with one stone and implement tag synonyms based on hierarchical tags. Tag synonyms have to be implemented separately.

Reasons why tag synonyms shouldn't be implemented based on hierarchical tags

This approach causes inconsistencies and should not be used because of:

• search syntax has to be consistent but that makes it complicated
• we don't want to use duplicates for the sake of synonyms

Search syntax

Search is a feature in itself, it should fulfill the search function quite well. Synonymous tags, in that regard, (as a use case) is a secondary feature, that might be allowed but primary function of search is searching.

Yet, if we just simulate synonyms with a sophisticated search syntax, the feature would become too complicated and unusable.

The user-friendly syntax I proposed seems impossible to implement or at least causes inconsistencies.

Duplicates

Duplicates are needed because we need to create an artificial hierarchy sometimes. It's not that bad in our tree, because all relevant tags are subcategories. Subcategories have parents, which makes our life much easier. But often (or sometimes, depending on a person I guess) we want to have a synonym for a tag which is not a subcategory. If a tag is not a subcategory, then I would use the following trick. Let name be a master tag and designation, title, and term be synonyms thereof. Let's further assume that none of them is a subcategory. I would create a hierarchy

name
  name
  title
  designation
  term

thus name is a duplicate.
Thanks to such an artificial hierarchy, searching for a tag synonym would be easy, because it's just a search for a tag or sibling.

If we use hierarchical tags as a framework for tag synonyms, then I think duplicates are inevitable, but using tag duplicates as means to create tag synonyms is not a good idea.