Note: I'm using the word "character" in the general sense.

Let's say I want to find images that focus on a cephalopod character. Stuff like this:

However, while the majority of results do have a cephalopod in them, they aren't the focal point:

Another example would be regarding ray-finned fish (a.k.a. fish that aren't sharks etc.). Stuff like this:

Unfortunately, the No Cartoon Fish trope comes into full effect; Most of the resulting images feature fish as background objects, food, etc. not actually presented as any sort of character.

So yeah, what the thread title says. I'm not sure if it would be something that fits within the scope of tagging (it might need to be separate functionality?).

Moe_Biehl said:
So yeah, what the thread title says. I'm not sure if it would be something that fits within the scope of tagging (it might need to be separate functionality?).

This is absolutely the type of usage that Char's idea of 'tag groups' would be great for. Unfortunately, while it's not too hard to think up how to store tag group data, technical challenges of making tag group queries run efficiently are nontrivial.

Tho it might be a good idea, stress on the server would be a problem when it needs to take EVERY SINGLE IMAGE ON THE SITE. And give one of it's tags the bonus of "Focal Point" in order to list them like that.

Durandal said:
There is the solo_focus tag.

What OP is looking for is not that.
It's more like.. "cephalopod_focus", "fish_anthro_notshark_notdolphin_focus" -- 'solo_focus' can easily return images with solo focus but only containing a cephalopod, rather than focused on them. Obviously, having actual tags like that would be silly.

This particular request could be implemented if E621 supported tag-values, so for example we could tag images with focus=cephalopod focus=solo, and query using that same string "focus=cephalopod focus=solo". TMSU is a good example of a tagging system which efficiently implements optional tagvalues.

Not sure about OP's second case, though, in which the value is basically a query. The second case probably requires a tag groups implementation, which is hard. And people to actually bother with grouping tags, which could be equally hard ;)

savageorange said:
Not sure about OP's second case, though, in which the value is basically a query. The second case probably requires a tag groups implementation, which is hard. And people to actually bother with grouping tags, which could be equally hard ;)

If/when we implement tag-grouping, the tag editing interface itself will likely be reworked so that you'll end up automatically grouping tags without really having to think about it. For instance, click an "add character" button to bring up a new tag-edit box specifically for a character/species that you specify, and then add tags relevant to that character in that character's tag edit box. The site would then group all those tags together.

As far as the OP's question, I really can't think of anything that would be a workable solution currently. As others have said, I think tag-grouping will need to happen first, and then we can have a "focus" tag that you can add to the tag groups for the necessary characters in the post.

Moe_Biehl said:
I think it may also involve increasing the rigidity of several aspects of tagging.

I went off on a bit of tangent here, but I did a bit of brainstorming. The relevant section is where the biggest comment block is.

Also, it's anything but some sort of "complete and finalized concept." I was just toying around with some ideas.

Comments

• Consider using YAML as the notation format. It's similar to your current format but avoids some boilerplate (notably '{content},')
• Legs enum: how would an octopus, snake, or eg post #492746 be classified? the whole xxxgrade thing is pretty much dependent on actually having feet.
• In general strings should probably be integer IDs, as this is what they will be queried by in the database
• You need 'unspecified' options for many things -- for example I don't think people should be required to fill out iris/sclera color, heterochromia for eyes. We should make it easier to fill out as much information as possible, but avoid making posting into a chore.
• multiple copyrights for a single character is a thing
• "arrray"
• SQL databases are bad at strongly structured data, so any implementation probably wouldn't look like this
• Personally I think the level of structuring required could be seriously relaxed if we had tag categories (eg 'anatomy', 'environment', 'object') with a tag being able to fall into multiple categories rather than just the existing narrow concept of 'tag types': we could then require 'a minimum N tags from category C, ...' and achieve a reasonable descriptiveness of the image. This would depend on tag completion, which is something we really need implemented in E621 to keep tag proliferation down.