project Utilities / File Location Listing avatar

utilities/file_location_listing#36: Ability to set tag equivalence to create Implied Tags

Issue Information

Issue Type: issue
Status: closed
Reported By: btasker
Assigned To: btasker

Milestone: v0.2.3
Created: 07-Jan-24 10:32


Currently this is, at best, a partial thought.

I sometimes find that I need to mark a tag as being equivalent (or perhaps superseded by) some other tag.

As a simple example, on my website I have the tag Facebook, with a smattering of posts going back 13 years.

But, in October 2021, Facebook announced that it was rebranding to Meta (in order to try and launder their reputation). In this case, I've not started a Meta tag but I can quite see that I might, one day, search for Meta rather than Facebook.

That sort of thing should be quite rare, so it would be nice if there was a way to tell the indexer that anything with tag x should also be considered to have tag y (although, of course, it means I'd need to consciously add a mapping)

Toggle State Changes


assigned to @btasker

The argument against this is that it may lead to a confusing search experience: I've searched for foo and this result clearly doesn't include it.

If we were to implement this, we'd probably want to include some kind of indicator in search results to denote that the match was based on an implied tag (that way the search portal could make it clear that that was the case).

I think, though, that it's definitely feasible, although there are two ways we could go at it.

Assuming we have a config line like


There are a couple of ways we could add the additional tags to anything tagged with facebook:

  1. Indexer references the implied tag config and inserts additional tag(s) into the index where one matches
  2. When reading the index, additional tags are inserted

The advantage of 1. is that it means additional tags are a one-time cost: you build the index and off you go. If we wanted to mark a tag as implied, though, we'd need to add a field to the index

The advantage of 2. is it makes it much easier for us to flag that a given tag is implied and config changes can be (almost) immediate. But, it does come at the cost of a longer tag index load time (though, it should be pretty slight)

It's probably easier to build a PoC implementation of 2. than 1. (at least, once you factor in the need to communicate that it's an implied tag along with a desire to test against existing indices), so I think we start with that.

changed title from {-Tag equivalence-} to {+Ability to set tag equivalence to create Implied Tags+}


mentioned in commit 78038a2368a239be022f1b9057093a705f3879ea

Commit: 78038a2368a239be022f1b9057093a705f3879ea 
Author: B Tasker                            
Date: 2024-01-07T11:15:45.000+00:00 


feat: implement intial support for implied tags (utilities/file_location_listing#36)

+43 -0 (43 lines changed)

Searching for

meta matchtype:tag mode:exact

returns no results.

Applying a simple config

$ cat config/impliedtags.txt 

That tag now returns results (although there's currently nothing to show that it's because of an implied match)

We now include a tagtype attribute in returned items, with one of the following values

  • na: match wasn't against tags
  • actual: matched a tag present on the referenced document
  • implied: matched an implied tag

The inclusion of that attribute allows the searchportal to mark results as being the result of an implied tag matching:


However, it doesn't currently show the implied tag that matched. When searching for meta that's fine, but what if I'd searched for met (or perhaps searched meta and the implied tag was meta-analysis).

The portal needs to be given the ability to display the relevant implied tag (and needs to be able to mark that as being implied)

If an implied tag is used (i.e. if tagtype is implied), we now include a implied-tag attribute in responses, which the portal consumes in order to include the tag in the tagging area:


Initial testing seems fine, so I think we're probably ready to merge the branch

mentioned in merge request !2

mentioned in commit e3c102864311d24e060cbfb61a5d28aea6457400

Commit: e3c102864311d24e060cbfb61a5d28aea6457400 
Author: Ben Tasker                            
Date: 2024-01-07T11:55:41.000+00:00 


feat: support implied tags (utilities/file_location_listing#36)

  • feat: include details of the implied detail that matched
  • feat: append (implied) to end of tag matchtype indicator if implied tags were used
  • chore: fix whitespace
  • fix: Lookup the cross-module value just once
  • feat: report tag matchtype

    This will report tagtype as one of the following

    • na (match was not against a tag)
    • implied (an implied tag was used)
    • actual (matched an actual tag)
  • feat: implement intial support for implied tags

+96 -13 (109 lines changed)

mentioned in commit 1d4f8a4db563b5a525808a7ea896cefae8eec2f2

Commit: 1d4f8a4db563b5a525808a7ea896cefae8eec2f2 
Author: Ben Tasker                            
Date: 2024-01-07T11:55:41.000+00:00 


Merge branch 'implied-tags' into 'main'

feat: support implied tags (utilities/file_location_listing#36)

See merge request utilities/file_location_listing!2

+96 -13 (109 lines changed)