Suppose you tag a post with `eagle`. Eagles are simply a type of bird, so ideally, you would like people who search for `bird` to see your `eagle` post. You could tag your post with both `eagle` and `bird`, but this starts to get tedious after a while.
Tag implications can be used to describe is-a relationships. An eagle is a type of bird. When an `eagle → bird` implication is created, then whenever someone tags a post with `eagle`, e621 will also tag it with `bird`.
Tag implications have a predicate and a consequent. The predicate is what is matched against. In the previous example, it would be `eagle`. The consequent is the tag that is added. In the example, it would be `bird`.
You can have multiple implications for the same predicate. e621 will just add all the matching consequent tags. For example, if we created a `eagle → avian` implication, then anytime someone tagged a post with eagle it would be expanded to `eagle bird avian`.
Implications can also be chained together. Instead of `eagle → avian` we could create a `bird → avian` implication. The end result would be the same.
This implication process occurs AFTER the alias process.
It's easy to go overboard with implications. It's important not to create implications for frivolous things; for example, we could theoretically implicate everything to an `object` tag, but this is pointless and only adds bloat to the database. For cases where the predicate and the consequent are synonymous, "aliases":/help/tag_aliases are a much better idea as they have lower overhead.
While you can "suggest":/tag_implication_request/new new implications, only an administrator can approve them.
[quote]Note:
Hiding an implication request's forum does not reject it; you need to go to the `implication #___` link & reject it there. Only the creator & admins can reject these requests.[/quote]