Topic: [age]_on_[age] Implication BUR

Posted under Tag Alias and Implication Suggestions

The bulk update request #6178 is pending approval.

create implication adult_on_young (12578) -> age_difference (68676) # duplicate of implication #50877
create implication adult_on_adolescent (652) -> adult_on_young (12578)
create implication adult_on_child (1729) -> adult_on_young (12578)
create implication adult_on_toddler (96) -> adult_on_young (12578)
create implication adult_on_baby (706) -> adult_on_young (12578)
create implication adolescent_on_adolescent (732) -> young_on_young (9785)
create implication adolescent_on_child (465) -> young_on_young (9785)
create implication adolescent_on_child (465) -> age_difference (68676)
create implication adolescent_on_toddler (5) -> young_on_young (9785)
create implication adolescent_on_toddler (5) -> age_difference (68676)
create implication adolescent_on_baby (2) -> young_on_young (9785)
create implication adolescent_on_baby (2) -> age_difference (68676)
create implication child_on_child (1148) -> young_on_young (9785) # duplicate of implication #51004
create implication child_on_toddler (9) -> young_on_young (9785)
create implication child_on_toddler (9) -> age_difference (68676)
create implication child_on_baby (8) -> young_on_young (9785)
create implication child_on_baby (8) -> age_difference (68676)
create implication toddler_on_toddler (4) -> young_on_young (9785)
create implication toddler_on_baby (0) -> young_on_young (9785)
create implication toddler_on_baby (0) -> age_difference (68676)
create implication baby_on_baby (3) -> young_on_young (9785)

Reason: Setting up an implication tree now that the age groups are properly formalized. All of these should be self-explanatory.

The bulk update request #6179 is pending approval.

create implication adult_on_child (1729) -> child (28554)
create implication adult_on_toddler (96) -> toddler (2965)
create implication adult_on_baby (706) -> baby (5504)
create implication adolescent_on_toddler (5) -> adolescent (16683)
create implication adolescent_on_toddler (5) -> toddler (2965)
create implication adolescent_on_baby (2) -> adolescent (16683)
create implication adolescent_on_baby (2) -> baby (5504)
create implication child_on_toddler (9) -> child (28554)
create implication child_on_toddler (9) -> toddler (2965)
create implication child_on_baby (8) -> child (28554)
create implication child_on_baby (8) -> baby (5504)
create implication toddler_on_toddler (4) -> toddler (2965)
create implication toddler_on_baby (0) -> toddler (2965)
create implication toddler_on_baby (0) -> baby (5504)
create implication baby_on_baby (3) -> baby (5504)

Reason: Part II (If you think I missed some it's probably because they already exist).

pleaseletmein said:
bump to get above the wall of approvals

LOL, and then they happen again.

Well, surprised I see not pros or cons mentioned by this and only 2 voters. I'm actually waiting to see what others say, before voting.

We already have [form]_on_[form] and [gender]_on_[gender] tags, so setting up the [age]_on_[age] tags with implications should be ok.

Though this does bring up a question, since there's the [gender]_on_[form] tags, does that mean we should also be equipped with [gender]_on_[age] and [form]_on_[age] tags too?

Updated

snpthecat said:
Though this does bring up a question, since there's the [gender]_on_[form] tags, does that mean we should also be equipped with [gender]_on_[age] and [form]_on_[age] tags too?

I personally don't think there should be gender_on_form tags. That's exactly the type of combinatorial explosion we were hoping to avoid when the admins said we were allowed to have combo tags again.

wat8548 said:
I personally don't think there should be gender_on_form tags. That's exactly the type of combinatorial explosion we were hoping to avoid when the admins said we were allowed to have combo tags again.

Yeah, it's a fine balance. I personally only use stuff like <gender>_penetrating_<gender> as a tagging shortcut. I would probably rarely search it. But it automatically creating those other tags means the tags I DO search are actually there.

I really, really try to avoid creating mixed tags for that combinatorial explosion issue. I went and cleaned up cub_receiving which was probably better named cub_oraled or cub_receiving_oral but then Cub Apoc-a-lips happened and it went bye-bye, anyways. Sigh, I tried to get the people using it to better define it or defend it, but it was a super niche tag. The reasoning for getting rid of it was that we already had plenty of tags like oral and younger_penetrating as an example of how you'd search for it. It would potentially lead to a whole bunch of tags like <age>_receiving/giving_oral/vaginal/anal/thigh_sex/... which is like 100 tags. Yeah, no... catching tags got nuked in the crib.

snpthecat said:
We already have [form]_on_[form] and [gender]_on_[gender] tags, so setting up the [age]_on_[age] tags with implications should be ok.

Though this does bring up a question, since there's the [gender]_on_[form] tags, does that mean we should also be equipped with [gender]_on_[age] and [form]_on_[age] tags too?

In practice, tags like adult_on_teenager have been replaced with adult_on_young and teenager, instead of just an implication. I still wonder if that was a mistake.

Updated

wat8548 said:
I personally don't think there should be gender_on_form tags. That's exactly the type of combinatorial explosion we were hoping to avoid when the admins said we were allowed to have combo tags again.

the mixed category pairing tags have existed for a really long time, though, with male_on_feral existing as early as 2013 with most of the rest going into use in 2015.

Donovan DMC

Former Staff

Tags existing for a long time isn't a good reason for keeping/expanding them. Cub existed since 2010, yet was still nuked, showing just how little a tag's age matters.

I am also of the opinion that those gender_on_form tags are needless bloat

alphamule said:
I would probably rarely search it.

I'm still of the opinion that around 95% of general tags are not particularly searched. They only exist because one person tagged them, and then other people only tagged them because they exist. Not because they are particularly valuable, and I wonder how often compulsive taggers actually care about the tags they add. These tags might tell people what something is called and efficiently implicate other tags, but they do not get used much. If every penetration tag disappeared today, I would not be negatively impacted. My e621 use would improve because I'd have less tags to worry about.

So I see threads like this, and it's the same thing all over again. I think young_on_young has value because a huge amount of young posts with multiple characters do not have young characters interacting, making such content difficult to find at all. Further specialization matters a lot less.

The thing I think people actually want, which has been the case for over a decade, is competent child tagging. That's what they wanted from cub. The younger_*/older_* tags, which was pretty much only a roundabout way (therefore bad) to tag young_* that I'm now doing, and all these other young tags have just been people spinning their wheels, finding 6 different ways to describe the thing they wanted but always missing the mark.

gender_on_form tags are useful for blacklisting, I think removing them would be a bad idea. Combo tags are honestly a necessity on this site when images contain a bunch of stuff that has to be tagged, but no way to tell which tag is interacting with which other tag. I don't really see the harm in "tag bloat" when it doesn't really do anything except provide that avenue for someone as long as it's not literally just one person. There's no other proper way to indicate gender_on_form with other tags that would make it not conflate with just form and gender tags in the same image but not interacting...

I've considered adding tag comboing to my custom search syntax, but it requires users to actually do the tagging, which isn't going to happen for a userscript.

abadbird said:
I'm still of the opinion that around 95% of general tags are not particularly searched. They only exist because one person tagged them, and then other people only tagged them because they exist. Not because they are particularly valuable, and I wonder how often compulsive taggers actually care about the tags they add. These tags might tell people what something is called and efficiently implicate other tags, but they do not get used much. If every penetration tag disappeared today, I would not be negatively impacted. My e621 use would improve because I'd have less tags to worry about.

let's just get rid of all of the <color>_* tags, in that case.

just because a tag isn't often used for browsing dosn't mean that it lacks significant utility. there are going to be tags that just have neigh zero value for browsing.

our goals with tagging isn't just to facilitate scrolling through a few dozen posts untill a user gets off. we're not just a porn site, we're an archive, and our goals are to have that archive as well tagged and as large as we can manage.

sipothac said:
let's just get rid of all of the <color>_* tags, in that case.

just because a tag isn't often used for browsing dosn't mean that it lacks significant utility. there are going to be tags that just have neigh zero value for browsing.

our goals with tagging isn't just to facilitate scrolling through a few dozen posts untill a user gets off. we're not just a porn site, we're an archive, and our goals are to have that archive as well tagged and as large as we can manage.

Yes, and this goal is better served by deliberately limiting the number of accepted tags to those that are likely to be both read frequently and written thoroughly. An archive with 90% of posts adequately tagged is better than an archive with 2% of posts having a thousand tags and the rest tagged haphazardly if at all.

wat8548 said:
Yes, and this goal is better served by deliberately limiting the number of accepted tags to those that are likely to be both read frequently and written thoroughly. An archive with 90% of posts adequately tagged is better than an archive with 2% of posts having a thousand tags and the rest tagged haphazardly if at all.

But you know this doesn't happen...

Watsit

Privileged

wat8548 said:
I personally don't think there should be gender_on_form tags. That's exactly the type of combinatorial explosion we were hoping to avoid when the admins said we were allowed to have combo tags again.

I think gender_on_form tags are alright since it would be impossible to properly search for certain kinds of content otherwise, and the genders of the particular forms in mixed-form pairings may be important to some people. Say, you like human female on anthro male but not human male on anthro female, "male/female human_on_anthro" will equally include human male on anthro female, while "male/female female_on_anthro" gives more desirable results. Or human male on feral female, "male/female human_on_feral" will have more feral male on human female, while "male/female male_on_feral" will give more pertinent results. Penetration doesn't always apply, so the x_penetrating and x_penetrated tags aren't always there to help.

However, I do think gender_verbing_form tags are too far, and they lead to the combinatorial explosion as a result as each also needs a reversed duplicate form_verbing_gender, despite already having x_verbing and x_verbed tags for both form and gender.

wat8548 said:
Yes, and this goal is better served by deliberately limiting the number of accepted tags to those that are likely to be both read frequently and written thoroughly. An archive with 90% of posts adequately tagged is better than an archive with 2% of posts having a thousand tags and the rest tagged haphazardly if at all.

but that's not really how it ends up, there are a bunch of tags that are pretty much totally DoA even though in theory they've got a valid use case. they get created, added, maybe they even get "canonized" with implications and aliases, and they that just very rarely get used (ex: tag pop of clothed_* tags other than clothed_feral ). users don't tend to add excessive amounts of tags to most posts, they tend to gravitate to using tags that have some actual utility.

also the website dosn't really "reward" the kind of behavior you described. the way the user profile tracks edits kind of encourages you to tag a lot of posts rather than add as many tags to a single post as possible.

watsit said:
I think gender_on_form tags are alright since it would be impossible to properly search for certain kinds of content otherwise, and the genders of the particular forms in mixed-form pairings may be important to some people. Say, you like human female on anthro male but not human male on anthro female, "male/female human_on_anthro" will equally include human male on anthro female, while "male/female female_on_anthro" gives more desirable results. Or human male on feral female, "male/female human_on_feral" will have more feral male on human female, while "male/female male_on_feral" will give more pertinent results. Penetration doesn't always apply, so the x_penetrating and x_penetrated tags aren't always there to help.

Even that would be better served by combo tags for a single character. We literally just canonised a whole set of young_gender and young_form tags. Ideally you would be able to search male_human female_feral human_on_feral, except the gender_form tags have been (inconsistently) aliased away despite being objectively less convoluted and less of a problem than the current system of four-dimensional combos. Hmm, I wonder whose idea that was...

Looks like there's a popular BUR to undo those aliases at topic #29463. Although it too is incomplete - male_human (at least) is missing.

wat8548 said:
topic #27467

Looks like there's a popular BUR to undo those aliases at topic #29463. Although it too is incomplete - male_human (at least) is missing.

Oh hell, that feral_<gender> thing made sense when we had cub tags? Sigh, work is never done. XD I'm actually hoping we don't get feral_male and such.

Updated

Bumping this. Is older_on_young excluded for a reason? Would be useful to have a tag for young characters involved in age difference pairings, since age_difference applies to any two characters interacting.

oopsitripped said:
Bumping this. Is older_on_young excluded for a reason? Would be useful to have a tag for young characters involved in age difference pairings, since age_difference applies to any two characters interacting.

because it's a mixed category paring tag and we're unsure what it should be aliased to. older is a relative term only used in older_* tags which all imply age_difference, while young is an absolute term which means a character is, well, young.

we could just alias it to adult_on_young, which is what the tag seems to mostly be used for but is kinda different from what the tag's name is, we could alias it to young, since that would at least move it to the most "important" tag, or we could alias it to age_difference, which is the closest adjacent valid tag.

sipothac said:
because it's a mixed category paring tag and we're unsure what it should be aliased to. older is a relative term only used in older_* tags which all imply age_difference, while young is an absolute term which means a character is, well, young.

we could just alias it to adult_on_young, which is what the tag seems to mostly be used for but is kinda different from what the tag's name is, we could alias it to young, since that would at least move it to the most "important" tag, or we could alias it to age_difference, which is the closest adjacent valid tag.

I meant implications for all the relevant [age]_on_[other age] tags to older_on_young, but I realize now that it isn't needed if all the [age]_on_[age] tags were to stay.

Bumping since I've run into many situations where these implications would be useful.

  • 1