Aliasing bound_arms → bound
Link to alias

Reason:

also other bound_* (limbs) tags, unless someone can make a reasonable argument towards keeping them.

Since bound_arms isn't even being used, I won't argue in this case.

However in general I like the tagging system to have more specificity. It would be easy to manage a whole group of bound_<limb> tags by just implicating them to bound.

Wyvrn said:
Since bound_arms isn't even being used, I won't argue in this case.

However in general I like the tagging system to have more specificity. It would be easy to manage a whole group of bound_<limb> tags by just implicating them to bound.

When specificity is needed, and provides a benefit, I'm for it... but these tags aren't at all, only bound is. Most people seem to not care if they are bound in a specific part or not, going by that.

What do you mean these aren't tags at all? Just because the distinction doesn't matter to you doesn't mean everyone else feels the same way.

The cost of maintaining separate specific tags is minuscule, especially in cases like these where the difference between bound_arms and bound_legs is simple and unlikely to lead to any confusion.

Even if the separate tags weren't always used perfectly, having them both implicated to bound means you would still be able to search for any kind of binding as a baseline. Whereas if we aliased everything to bound, searching for all types of binding is the maximum functionality available.

I just can't see the justification for removing specificity in these sorts of situations.

Wyvrn said:
What do you mean these aren't tags at all?

Reread please.

The cost of maintaining separate specific tags is minuscule, especially in cases like these where the difference between bound_arms and bound_legs is simple and unlikely to lead to any confusion.

Just because they're specific doesn't mean they should be kept; If the tags aren't being tagged, then they are clutter and should be cleaned up.

Even if the separate tags weren't always used perfectly, having them both implicated to bound means you would still be able to search for any kind of binding as a baseline. Whereas if we aliased everything to bound, searching for all types of binding is the maximum functionality available.

Unless, as noted, no one tags them. Which no one really does. If it was actively tagged by more than a few people (in short, it's not just a few people tagging it, while the majority aren't tagging it), you'd have a valid point, but it just isn't used.

I just can't see the justification for removing specificity in these sorts of situations.

Tags sitting and rotting with a few posts that aren't being used just makes tag lists bloat. Specificity that doesn't enhance searchability with a logical, generic definition (generic in the sense that it applies equally regardless of fandom) is pointless.

I misinterpreted you about these not being tags. Yes, currently bound_arms and bound_legs aren't actively used.

But why is the default response to that to roll them all up and alias them to bound? Why not take it as an invitation to add specificity, to get the ball rolling on these tags? After all, the only way people are going to get to know and start to use the tags is if they see them being used. That's how we all got used to the plethora of cum_on_* tags floating around here.

You say "bloat" and "clutter" as if there's inherently something wrong with a long tag list, but who is impacted negatively by the tag lists being a bit longer? What exactly is the problem with having just a few pictures tagged with bound_arms or bound_legs, even if for a while the vast majority are only tagged with bound?

Wyvrn said:But why is the default response to that to roll them all up and alias them to bound? I personally see it as an invitation to add specificity, to get the ball rolling on these tags. That's how we all got used to the plethora of cum_on_* tags floating around.

No, people started using tags because they felt them appropriate to tag and so tagged them. tags that don't get tagged don't get supported to start getting used. Earth pony got dealiased frm Pony, but people didn't start tagging it even though they knew images had earth ponies, for example- and that's with an active large fanbase that swamps us with tons of MLP content. Now it's being aliased away again, because of lack of use.

You say "bloat" and "clutter" as if there's inherently something wrong with a long tag list,

There is. It's called "needle in a haystack syndrome". Too many tags makes the tag list an intimidating pile of meaninglessness. Try actually getting anything of use out of one of those massive walls of tags from the multi-character, multi-topic images we have that have tag lists that go on multiple times longer on the page than the comments section and the image combined. You might be able to pick a few tags out at random, sure, but the number of relevant images is only going to be a bare handful because of overspecification so long as you don't overgeneralize your picks (choosing tags like "equine sex breasts" is an obvious example of overgeneralizing, there, and just proves that you migrate towards common tags that are more general and less specific, so).

Right now bound_arms and bound_legs both have zero posts, while bound has over fourteen thousand. That's not because nobody ever tried to use bound_arms or bound_legs, it's because every time those tags were added, somebody else came along and replaced them with just bound.

You can't argue that nobody is trying to add specificity to bound if you're also going to 'clean up' every attempt someone makes. Improvements to the tagging system shouldn't have to spring up overnight, fully applied across the site in order to be accepted. There needs to be some provision for slow changes that start gradually.

I agree that it is possible for a tag list to grow too long, but that's not a blanket reason to oppose the introduction of all new tags. Especially when there are simple programmatic means of shrinking the tag lists, such as by hiding implied tags in a dropdown under the tag which implied them.

Wyvrn said:
Right now bound_arms and bound_legs both have zero posts, while bound has over fourteen thousand. That's not because nobody ever tried to use bound_arms or bound_legs, it's because every time those tags were added, somebody else came along and replaced them with just bound.

Right. Totally. Every single time it's been changed. It's not just that it's very rarely used at best. Nope. It's people slyly fixing it in the background JUST TO GET RID OF THE TAG. Totally. (yes, that's sarcasm. Yes, I'm being a bit of a dick using it. But seriously? Seriously? Saying it's only because people change the tags?!)

You can't argue that nobody is trying to add specificity to bound if you're also going to 'clean up' every attempt someone makes. Improvements to the tagging system shouldn't have to spring up overnight, fully applied across the site in order to be accepted. There needs to be some provision for slow changes that start gradually.

If in all the time I've been here (which is since its inception, I just didn't make a user name when i first was a lurker) people actually tried to tag it, it would be used. The tag wasn't even aliased away before, it's been sitting, available for people to tag with it, this entire time. They haven't been. People, as in, the majority of, on this site, don't bother tagging it. It is an over-specific tag for general use. If you want to separate it out so much, use a set.

I agree that it is possible for a tag list to grow too long, but that's not a blanket reason to oppose the introduction of all new tags.

And I agree, which is why I don't oppose the introduction of all new tags and support new tag creation as much as I work to prune tags that have shown to not be of use. Nice try at hyperbole though.

Especially when there are simple programmatic means of shrinking the tag lists, such as by hiding implied tags in a dropdown under the tag which implied them.

Because nested tags that have to check each tag and then sort them in trees beneath other tags is simple. And that'd never have any issues with things like an image tagged with both gay and straight sex, it'll... just be under both of the tags that imply it, I guess? That's not useless at all. (In case you can't tell, no, that's not a good idea, even if it was simple to program, which it most likely would not be considering the thousands of tags and the hundreds of thousands of images we have. We've disabled trending tags and tag edit history past page one because of issues already.)

123easy said:
Right. Totally. Every single time it's been changed. It's not just that it's very rarely used at best. Nope. It's people slyly fixing it in the background JUST TO GET RID OF THE TAG. Totally.

Except yes, that's exactly what happens. Why don't you take a look for yourself before you go into sarcastic dick mode. Someone adds the tag. Someone else sees only a handful of posts use the tag, and then they remove the tag.

Because nested tags that have to check each tag and then sort them in trees beneath other tags is simple. And that'd never have any issues with things like an image tagged with both gay and straight sex, it'll... just be under both of the tags that imply it, I guess? That's not useless at all.

Yes, it would be simple. And no it wouldn't be a problem if an implied tag appeared below multiple implying tags, sex-toy hidden beneath both butt_plug and dildo for instance, but nice try at arguing against something you hadn't fully thought out. It wouldn't require a performance hit either, the per-image implication hiding can be pre-calculated in linear time and stored with each image's record, and only has to be changed when an implying tag is removed from the image, or there's a change to the implications on that image's tags. Not computationally expensive at all.

Wyvrn said:
Except yes, that's exactly what happens. Why don't you take a look for yourself before you go into sarcastic dick mode. Someone adds the tag. Someone else sees only a handful of posts use the tag, and then they remove the tag.

You mean the person replacing it with the <limb>_tied tag? that actually gets used by more than a sparse handful of people, so is consistant?

Yes, it would be simple. And no it wouldn't be a problem if an implied tag appeared below multiple implying tags, sex-toy hidden beneath both butt_plug and dildo for instance, but nice try at arguing against something you hadn't fully thought out.

Except I did. That would be even worse tag bloat than having overly specific tags that are rarely used. It'd also be even more work for Tony to put it into effect, assuming the added complexity didn't kill the mem usage of the servers and break functionality. It's a bad idea, plain and simple.

It wouldn't require a performance hit either, the per-image implication hiding can be pre-calculated in linear time and stored with each image's record, and only has to be changed when an implying tag is removed from the image, or there's a change to the implications on that image's tags. Not computationally expensive at all.

4899 pages * 75 images a page = 367,425 images (give or take 30 or so by the time I'm finished writing this) currently on the site. At least a few hundred more get added each day, and either get declined or approved, and older images get scrapped for one reason or another.

You're trying to tell me that to apply a formatting function that not only changes how the tag sidebar structure works for the site (which itself is a performance hit, though minor) but also run a sorting algorithm over each of those images that checks each tag against the implication cache and then adds the implied tag as a sub-catagory to each of those tags, will not be computationally expensive. Basically, you're saying that a whole other implication tagging system, embedded within the already existing tagging system, after rewriting it to allow for multiple existances of the same tag, is simple and cheap, not even factoring in all the aliasing and implications that are constantly involved with the tags... When we're cutting secondary pages of tag history because we don't have the ability to keep them and the rest of the site running optimally, or Trending Tags functional beyond the very basic top 30 tagcount tally that it does without searching for the same reason. Even if the initial sort is done outside the current database that's far too much to load onto the already straining system.

*sighs, rubbing temples* Are you legitimately that oblivious about the current state of affairs, or are you just white knighting this because it makes you feel better? I'm asking that honestly, because if you'd taken two seconds to just check, you'd have seen there's already the arms_tied and legs_tied tags and you could have brought tht up for aliasing towards instead of this entire ridiculous attempt at totally revamping the entire tagging system with unneeded drek.

123easy said:
You mean the person replacing it with the <limb>_tied tag? that actually gets used by more than a sparse handful of people, so is consistant?

Well furrypickle did that, you didn't. I am totally in favour of consistency though, bound_arms should probably be aliased to arms_tied. Knowing that that tag exists, I concede that bound_arms shouldn't.

Overall though, I'm not trying to make a point about any individual tag, all I'm trying to say is the the anti-bloat, anti-clutter, anti-upstart-tag atmosphere is a bad thing. It inhibits the gradual introduction of new tags in places they might be beneficial. Its inflexible, and it encourages problems to build up until they can't be ignored, by which time it takes massive tagging projects to fix them. I don't know the solution, or if there even is a solution. Maybe the current system - despite its flaws - is less bad than all the others. I don't know, but I think it deserves talking about.

Except I did. That would be even worse tag bloat than having overly specific tags that are rarely used.

The way I see it, this feature would go a long way to reducing tag bloat. Let me explain my reasoning: The implied tags don't usually need to be shown in the tag list, by definition they're implied by the other stuff. Having sex_toy in the list when you already have dildo is a waste of space and mental energy.

Sometimes you do want to see every tag on an image though, so we shouldn't hide implied tags completely. I think the best place to tuck them away would be in an expandable dropdown below the implying tag, which defaults to being closed on page load. What I picture is similar to a folder tree like this. The tags with implications would have a little plus sign or arrow next to them you could click to reveal all the tags they imply.

The case where multiple tags on an image imply the same tag - like butt_plug and dildo both implying sex_toy - is tricky. One solution is putting the implied tag under only one of the implying tags. That has the benefit of every tag still only appearing once in the list, but the cost is that the an implying tag sometimes won't have all its implied tags in its dropdown.

The other solution is putting the implied tag under each tag that implies it. This has the benefit of being conceptually simple, a tag will always have all its implied tags in its dropdown, no matter which image it's on. The cost is that the implied tag will appear multiple times in the list.

The uniformity of the second solution appeals to me, and I don't consider the cost to be very great. I don't agree that having an implied tag in multiple dropdowns contributes to tag bloat. You're only going to see the tag multiple times if you expand multiple dropdowns at once, normally it would be completely hidden. If you're information hungry enough to expand multiple dropdowns at once, I think you would appreciate being told that sex_toy is implied by both butt_plug and dildo rather than bemoan it's appearance on your screen multiple times.

It'd also be even more work for Tony to put it into effect, assuming the added complexity didn't kill the mem usage of the servers and break functionality. It's a bad idea, plain and simple.

4899 pages * 75 images a page = 367,425 images (give or take 30 or so by the time I'm finished writing this) currently on the site. At least a few hundred more get added each day, and either get declined or approved, and older images get scrapped for one reason or another.

You're trying to tell me that to apply a formatting function that not only changes how the tag sidebar structure works for the site (which itself is a performance hit, though minor) but also run a sorting algorithm over each of those images that checks each tag against the implication cache and then adds the implied tag as a sub-catagory to each of those tags, will not be computationally expensive. Basically, you're saying that a whole other implication tagging system, embedded within the already existing tagging system, after rewriting it to allow for multiple existances of the same tag, is simple and cheap, not even factoring in all the aliasing and implications that are constantly involved with the tags... When we're cutting secondary pages of tag history because we don't have the ability to keep them and the rest of the site running optimally, or Trending Tags functional beyond the very basic top 30 tagcount tally that it does without searching for the same reason. Even if the initial sort is done outside the current database that's far too much to load onto the already straining system.

Sure, it would take some effort to add, every new feature does. As for the performance impact, well excuse my frankness, you are obviously not a web developer. Even if the servers were as strained to the breaking point as you think they are, the computation required for this is so simple, so inexpensive, that it could all be done client side if we wanted.

Here's how:

Dump the entire site's implication table to a text file. There are less than 2000 implications on this site so this file will be tiny. Format the file by associating each implying tag with the list of tags it implies:

{"cat": ["feline"], "pizza": ["food"], "hyper_breasts": ["huge_breasts", "hyper"], ... }

Send this file along with every image page. Since this file is so tiny, easily compressible in transit, and cacheable, the average transit cost is negligible. At most a kilobyte or two per pageload.

Then you put some javascript on the image page and, armed with the implication table, it can do this enitre funky formatting trick without a single extra hit to the server. Here's the algorithm:

For each tag T on the image
    For each tag U which is implied by T
        Remove U from the top level of tags on the image if this has not already been done
        Create a dropdown box below T if this has not already been done
        Put an instance of U in the dropdown box below T
        Add that newly created tag to the list of tags the outer loop is iterating through

Simple as that. Purely cosmetic, doesn't require any changes to tagging practices, the underlying tagging system, or the way tags are stored. And it would be even simpler if performed serverside. Our talented Tony could make quick work of it.

*sighs, rubbing temples* Are you legitimately that oblivious about the current state of affairs, or are you just white knighting this because it makes you feel better? I'm asking that honestly, because if you'd taken two seconds to just check, you'd have seen there's already the arms_tied and legs_tied tags and you could have brought tht up for aliasing towards instead of this entire ridiculous attempt at totally revamping the entire tagging system with unneeded drek.

I'm honestly just trying to point out issues with the site that I think deserve discussion. Let's not gloss over the fact that you didn't know about arms_tied either, since you didn't add it to the image you deleted bound_arms from, or use it in this very alias suggestion. This has been a learning experience for both of us.