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)
Activity
07-Jan-24 10:32
assigned to @btasker
07-Jan-24 10:36
The argument against this is that it may lead to a confusing search experience: I've searched for
fooand 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).
07-Jan-24 10:42
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: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 indexThe 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)07-Jan-24 10:47
It's probably easier to build a PoC implementation of
2.than1.(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.07-Jan-24 11:16
changed title from {-Tag equivalence-} to {+Ability to set tag equivalence to create Implied Tags+}
07-Jan-24 11:17
mentioned in commit 78038a2368a239be022f1b9057093a705f3879ea
Commit: 78038a2368a239be022f1b9057093a705f3879ea Author: B Tasker Date: 2024-01-07T11:15:45.000+00:00Message
feat: implement intial support for implied tags (utilities/file_location_listing#36)
07-Jan-24 11:18
Searching for
returns no results.
Applying a simple config
That tag now returns results (although there's currently nothing to show that it's because of an implied match)
07-Jan-24 11:34
We now include a
tagtypeattribute in returned items, with one of the following valuesna: match wasn't against tagsactual: matched a tag present on the referenced documentimplied: matched an implied tag07-Jan-24 11:39
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
metathat's fine, but what if I'd searched formet(or perhaps searchedmetaand the implied tag wasmeta-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)
07-Jan-24 11:51
If an implied tag is used (i.e. if
tagtypeisimplied), we now include aimplied-tagattribute 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
07-Jan-24 11:52
mentioned in merge request !2
07-Jan-24 11:55
mentioned in commit e3c102864311d24e060cbfb61a5d28aea6457400
Commit: e3c102864311d24e060cbfb61a5d28aea6457400 Author: Ben Tasker Date: 2024-01-07T11:55:41.000+00:00Message
feat: support implied tags (utilities/file_location_listing#36)
(implied)to end of tag matchtype indicator if implied tags were usedfeat: report tag matchtype
This will report
tagtypeas one of the followingna(match was not against a tag)implied(an implied tag was used)actual(matched an actual tag)feat: implement intial support for implied tags
07-Jan-24 11:55
mentioned in commit 1d4f8a4db563b5a525808a7ea896cefae8eec2f2
Commit: 1d4f8a4db563b5a525808a7ea896cefae8eec2f2 Author: Ben Tasker Date: 2024-01-07T11:55:41.000+00:00Message
Merge branch 'implied-tags' into 'main'
feat: support implied tags (utilities/file_location_listing#36)
See merge request utilities/file_location_listing!2