Topic: Why is solo_male aliased to male?

Posted under Tag Alias and Implication Suggestions

To me, these two tags mean different things. Solo_male means this picture contains a single male character and no others, while male just means this picture contains a male. And I've used -solo_male specifically when I don't want to see images in the search pool that has a lone male, and while the same result of solo_male can be achieved through searching solo and male, as far as I know, there's nothing like -(solo male) only to remove pictures with a single male. -solo and -male won't work, as that removes things that simply have one character or contain a male character. I think I should also mention that this is how this tag is used on other sites with a similar tagging system. What I've said also goes for solo_female, which is aliased to female.

Putting solo male on one line in your blacklist should hide the content properly, but I don't think there's any way you can actually do that when searching.

A little unrelated, but I've never really been sure why but some reason e621 has a history of not wanting to tag character quantities that dates back like 10 years or something, despite being commonplace in other boorus. On Danbooru you can search 2girls 1boy and specifically find images that have 2 female characters and 1 male character. For some reason e6 aliased away all those tags for being invalid years ago, making there no way to search character amounts precisely like this...

Meanwhile we get other things like incredibly overdetailed taxonomy tags for animals or 20 different tags on each image relating to the color or pattern of all the clothing. Tags like male_anthro, nude_female, looking_back_at_viewer, outside_sex are also just combinations of two tags and those always seem to get a free pass to exist, despite the arguments for their existence being the exact same as solo_male and solo_female.

faucet said:
Tags like male_anthro, nude_female, looking_back_at_viewer, outside_sex are also just combinations of two tags and those always seem to get a free pass to exist, despite the arguments for their existence being the exact same as solo_male and solo_female.

Difference is, solo+male is equivalent to solo_male, since 'solo' indicates the image only has a single character, and consequently male or female would mean that character is male or female. nude+female isn't equivalent to nude_female though, since nude only needs to apply to one of any number of characters, and a female needn't be the one that's nude. Similar for looking_back_at_viewer, as looking_back means one of any number of characters is looking backwards relative to themself, while looking_at_viewer means one of any number of characters is looking at the viewer; it needn't be the same character doing both. Similar for outside_sex: outside only indicates that the image viewpoint is outside, while sex indicates there's sex occurring somewhere in the image. outside_sex means two or more characters are having sex outside, while outside+sex can mean the image viewpoint is outside while two or more characters are having sex inside (and outside_sex also catches instances of two or more characters having sex outside while the image viewpoint is inside or ambiguous, so "outside_sex sex -outside" would be a valid combination).

Maybe because they put quite some work into it, to remove those tags, and now they don't want to change it back. (even though, maybe it would be better, just to make searching easier?) Adding the feature to exclude tag combinations would solve that problem, but this would mean a whole rewrite of the search function, IIRC.

Correct me if I am wrong, but there is no way to search for a threesome that features exactly two males and one female, for instance. I personally think the tags 1_male, 2_females, etc. could be valid and are not useless.

dubsthefox said:
I personally think the tags 1_male, 2_females, etc. could be valid and are not useless.

The question then becomes, where does the counting stop? You have ambiguous_gender, male, and female, along with intersex which is implied by gynomorph, herm, maleherm, and andromorph. So you'd result in 8*(n+2) sex tags where n is the maximum count (the normal male/female/etc tag, the <1...n>_male/etc tags, and a final set to cover everything above n, resulting in n+2 of every sex tag). Then you'll have people saying we should also have n_anthros/n_humans/n_taurs/n_humanoids/n_ferals/etc tags too. The number of tags would explode, and mistags would be more annoying to fix.

Updated

You are right that it can lead to annoying tag implications we'd have to fix, but I think the gain would out weight the downsides. It improves the system and makes it easier to search for specific things. Even if we'd have 500 new tags, would it cause any dramatic problems? Maybe it's a little annoying to set up the implication, but as soon as this is done, almost only upsides.

(Just in theory, it wouldn't hurt to go above 10_gender. I'd set the limit to 5. This should cover most posts)

I know I'd probably be one of only like 10 people who'd be able to wrap their head around it, but I wish that e621 was based on a triple store and allowed querying using SPARQL. This would give it a rich set of tags that could be as granular as people wanted, since you can build relations in a graphing database sense and attach metadata to either nouns or verbs. However, as I said, this likely would be very difficult for everyone but the most technical to understand, and the current system does balance usability and power quite well.

dubsthefox said:
(Just in theory, it wouldn't hurt to go above 10_gender. I'd set the limit to 5. This should cover most posts)

I would've said 3-5, but the part of my brain that wants every number to end in 5 or 0 leans more towards the latter.

Personally, I don't see anything wrong with adding numerical gender tags. Yes, it'd be adding a lot of tags. Yes, it'd take a lot of time and effort going back to old posts to fill out the tags. But the amount of times I've seen this come up tells me that an interest is clearly there. It would certainly make searching for specific group setups easier. Although, I'm generally just of the mindset that more tags are good, as long as they remain useful.