Topic: [Feature] New tag ambiguity resolution feature - makes disambiguation tags useful, hanging disambiguation tags are impossible!

Posted under Site Bug Reports & Feature Requests

I first posted this here: https://e621.net/forum_topics/35332 but I think it deserves its own thread.

This is a pretty big feature, but I think implementing this would really be worth it.

Idea

Ambiguity feature:

This proposed feature aims to allow disambiguation tags to be more accessible and useful, while also making sure adding an ambiguous tag to a post impossible. If a user tries to add an ambiguous tag, their edit is halted until they specify which tag(s) they meant to add.

Editing an existing post that has a hanging ambiguity would require the editor to resolve the ambiguity before they can submit their edit.

Searching with an ambiguous tag would show results with all of the ambiguities, and the user would be shown the ambiguities and could select one to refine their search.

How it works

It would work similar to an implication, can be added to BURs like this:

ambiguate pool -> billiard_table
ambiguate pool -> swimming_pool

When tagging

When an ambiguous tag is attempted to be added to a post/detected on an existing post, the edit is halted, and the following message would appear:

You attempted to add the tag pool, but that tag is ambiguous. Please specify from the following:

☐ - 8k swimming_pool - [wiki]
☐ - 485 billiard_table - [wiki]

[Confirm] [Remove "pool" tag]

The boxes to the left are checkboxes used to select the applicable tags. When the user hits confirm, the pool tag is removed and the selected tags are added to the list instead.
This has the benefit of never allowing hanging disambiguations being tagged onto new posts, and if any current post has a disambiguation tag, if it is edited, the editor is forced to resolve the ambiguity.

When Searching

If a user searches pool, they would see something like the following:

(make the background here yellow or something so it's more obvious)
You searched pool, but that tag is ambiguous. Did you mean:

1. swimming_pool
2. billiards_table
(if the list is long, put the list in a spoiler that shows the first few items)

Posts:

post #4159471 post #4012280 post #3947318 post #4147117

The user would see search results from swimming_pool, billiard_table, and any post with a hanging ambiguity of pool.
If they clicked on a tag in the tag list, the pool tag in the search bar would be replaced with the tag they clicked, allowing the user to refine their search.

Using the proposed feature to resolve existing hanging ambiguities

I would recommend adding a new metatag for searching: hanging_disambiguation:true.

A lot of posts would have hanging ambiguities if this were to be implemented on all disambiguations all at once. As such, this should be implemented in phases of three or four large tags first.

Then people on the tagging project can search pool hanging_disambiguation:true to find posts with hanging disambiguations and then fix them. Once all of the hanging disambigs are resolved, move onto the next set of tags.

Once all of the large tags are done, ambiguations can be added to smaller tags, and people on the tagging project can just search hanging_disambiguation:true to find hanging disambiguations to fix.

Wow it's been 10 months and that useless pool tag which is ambiguous but not a disambiguation is still there with nearly 300 posts, amazing. Glad we solved a problem with that one.

But back to the suggestion. Yes. This, or something along the lines of this, would be a very necessary feature to implement.

The key problem with the disambiguation system right now is that it's hard to search. It really needs to give a notice to users that are searching all invalid tags - not just disambiguations, but in the case of disambiguations it can suggest better tags.

Suggesting better tags upon upload would be a nice-to-have, but I'm not convinced that everybody would actually use it.

Not too sure we need a metatag when we've already got *_(disambiguation) or invtags:>0

---

I'll also dump my own idea here from that thread.

dubsthefox said:
There could be a big link to the wiki on the top of the search page, if someone tried searching for a tag with the _(disambiguation) suffix.
This would at least help to find the wiki.

You tried searching for "pool_(disambiguation)", have a look at the wiki.

This is really the best solution - no matter what route we take for disambiguation tags. I asked for this a long time ago (with the old site code I think, back when Parasprite was the lead developer) and I was told it was impossible to add. I really don't see why not. It's probably overkill for the system and too difficult to implement but something like the way Wolfram|Alpha handles it would probably be the ideal solution.

faucet said:
Wow it's been 10 months and that useless pool tag which is ambiguous but not a disambiguation is still there with nearly 300 posts, amazing. Glad we solved a problem with that one.

But back to the suggestion. Yes. This, or something along the lines of this, would be a very necessary feature to implement.

The key problem with the disambiguation system right now is that it's hard to search. It really needs to give a notice to users that are searching all invalid tags - not just disambiguations, but in the case of disambiguations it can suggest better tags.

I agree the search for them is awful.

Suggesting better tags upon upload would be a nice-to-have, but I'm not convinced that everybody would actually use it.

Interruption UI theory would make it in-your-face, if implemented like OP mentioned.

Not too sure we need a metatag when we've already got *_(disambiguation) or invtags:>0

Yeah, this seems kind of redundant.

This is really the best solution - no matter what route we take for disambiguation tags. I asked for this a long time ago (with the old site code I think, back when Parasprite was the lead developer) and I was told it was impossible to add. I really don't see why not. It's probably overkill for the system and too difficult to implement but something like the way Wolfram|Alpha handles it would probably be the ideal solution.

You'd have to handle parsing the entries to generate the (albeit small) database of ambiguous tag trees. I assume doing that automatically would lead to hilarity like grabbing ALL tags between brackets in a Wiki entry. The metadata is just not there so it's "impossible"*.

*without a lot of work

  • 1