Actually I've had this idea long ago. What if we join definite tags into tag groups? I mean, mass tagging mode is a powerful tool, and there are loads of pics that aren't properly tagged. But since there are certain restrictions regarding search pages and amount of tags (and now also because the new search constantly crashes), 6 tags are not really enough for a precise query.
For instance, I want to tag all the images that have no hair color or hairstyle tags. Of course I could do something like "kirisame_marisa -blondehair -alternate_hair_color -monochrome -longhair -shorthair". But you can't know names of all characters or series. And there are also copyright_request and original images. Same goes for clothes, actions, gestures etc.
But what if we create a collective tag for different types of tags? Like "group:hair_color", which implies all the hair color tags that we have or "group:upper_body_clothing" or something like that, and then make it possible to search "-group:hair_color". It would be so convenient, don't you think? Of course it must be a hell of a task, but I still want to suggest it.
Pretty sure you can't negate any metatag except rating so this wouldn't work.
For now. That should only be a relatively minor implementation detail.
And no we're not adding a new tag that only serves to group other tags.
We already have them. We just call them "umbrella tags" and they're general.
We also (manually) create a certain degree of vertical ontology with the tag group wiki pages, which are a crude hack we use in absence of better solutions.
The only real question with this is whether it could be done without leaning on incredibly slow queries. It's pretty clear that query time is the limiting factor for almost any feature we might want.
DschingisKhan said: For now. That should only be a relatively minor implementation detail.
If I remember correctly it wasn't available in danbooru 1 as well. So I don't see a reason for your confidence that this is going to be implemented in the new version. Perhaps it could, but I wouldn't expect it, especially with how slow/unreliable are the search options we have currently.
Also, your comparison with "umbrella tags" is invalid. They are really different to what MarUsca is asking for. We do have some rather broad tags, but they are always used for something specific that is present in the image and can be used alone too, not only as an "umbrella".
Basically, I'm against creating collective tags that will serve no other purpose than to group other tags. Perhaps something like this can be implemented as new meta-tags, or even as a whole new tag structure/system. But again, I wouldn't expect it anytime soon.
MarUsca said: So that is why the search is dying anytime I try to search for something complicated? Is there a new shorter query timeout limit?
There is. At least for some meta-tags and queries, not sure about all of them.
Basically, I'm against creating collective tags that will serve no other purpose than to group other tags.
I think I didn't quite get things across. I don't mean that this tag groups will be in tag list of an image, I wanted to make it - you called it metatags? Probably yes. By the way, why is it not possible to negate them?
There is for source: searches because of how long they were taking just to fail anyway, but I can't remember seeing anything about shorter timeouts for other searches.
Log said:
Pretty sure you can't negate any metatag except rating so this wouldn't work.
This is not quite true. Looking at the source code, these metatags can be negated:
user:
approver:
pool:
fav:
rating:
The other metatags cannot be negated, but I'm not sure if this is due to technical constraints or not.
The ones that can't be all seem to be ones that no one would want to negate in the first place. For example, there would be no reason to negate a score:..5 search when you could just search for score:6.. and get the exact same results. So this may be an intentional choice.
As far as this idea goes, a taggroup: metatag doesn't sound like a bad idea conceptually. I don't know if it would be feasible performance-wise or not, though.
Toks said: There is for source: searches because of how long they were taking just to fail anyway, but I can't remember seeing anything about shorter timeouts for other searches.
Well, it wasn't said directly, but from https://github.com/r888888888/danbooru/issues/433 I got the impression that order: searches and maybe some other too were limited to save the server resources/time.
I've almost certainly missed a couple, but off the top of my head the implementation considerations are at least these:
Performance constraints need to be examined in detail. This is the most likely place for this to fall on its face. (Might it be feasible to cache results for group metatags and update it with posts made in the delta between its last use and the present?)
Adding metatags needs to be formalised and automated through code. This also includes UI, privilege level, and due process concerns.
Editing of what is bound to a group metatag needs to be formalised (equivalent to editing the wiki page for our current tag groups). This too has components of UI and process, as well as additional concerns of job time to populate it if a cache is used.
Question: How long do the user subscription jobs take now? There would probably be about three orders of magnitude fewer group metatags, but they have the potential to be much larger than the twenty-tag limit of subscriptions.
MyrMindservant said:
If I remember correctly it wasn't available in danbooru 1 as well. So I don't see a reason for your confidence that this is going to be implemented in the new version.
My confidence is because I understand how code works. It would be fairly difficult to make allowing negation to be anything other than a relatively minor change. Whether it should be implemented is why we're discussing it.
Also, your comparison with "umbrella tags" is invalid. They are really different to what MarUsca is asking for.
Semantically, they're nearly identical. The only significant difference between what's talked about here and our current "umbrella" tags is whether they're intended for display or only as a search aide.
MyrMindservant said:
Well, it wasn't said directly, but from https://github.com/r888888888/danbooru/issues/433 I got the impression that order: searches and maybe some other too were limited to save the server resources/time.
Also, from Twitter: "searches like source:*.pixiv will fail fast now. this probably breaks a #danbooru greasemonkey script or something. those kinds of queries are always slow, and were already failing every time, and they were overloading the db server #danbooru"
Question: How long do the user subscription jobs take now? There would probably be about three orders of magnitude fewer group metatags, but they have the potential to be much larger than the twenty-tag limit of subscriptions.
I didn't quite get the idea, sorry. Could you put it in simpler words?
DschingisKhan said:
Also, from Twitter: "searches like source:*.pixiv will fail fast now. this probably breaks a #danbooru greasemonkey script or something. those kinds of queries are always slow, and were already failing every time, and they were overloading the db server #danbooru"
Now this is frustrating, because even something simple like multiple_girls solo is not accessible too..
I didn't quite get the idea, sorry. Could you put it in simpler words?
If this idea was implemented, it would probably work similarly to subscriptions. The question is how much time do subscriptions currently take to update, and how much would this idea take if implemented. Albert is probably the only one who can answer that.
MarUsca said:
Now this is frustrating, because even something simple like multiple_girls solo is not accessible too..
That tweet is only related to source: searches (such as source:*.pixiv).
Searches like multiple_girls solo failing is a bug, not intentional. It should hopefully be fixed soon.
DschingisKhan said: My confidence is because I understand how code works. It would be fairly difficult to make allowing negation to be anything other than a relatively minor change. Whether it should be implemented is why we're discussing it.
This is different from what I was replying to. Your first message did sound like you are certain that it will be implemented. And I've replied that there are no reasons to expect this.
DschingisKhan said: Semantically, they're nearly identical. The only significant difference between what's talked about here and our current "umbrella" tags is whether they're intended for display or only as a search aide.
Not really. I've already said why they are very different. Being an "umbrella" is only a secondary functionality for such tags, they still remain and are being used like other usual tags. While meta-tags proposed by MarUsca are generalized categories that can only be used in search queries, and only for negation too.
Toks said: Searches like multiple_girls solo failing is a bug, not intentional. It should hopefully be fixed soon.
I wouldn't call it a bug. It's not a mistake in code or unintended functionality, server simply can't process the query in time. For the record, multiple_girls solo did work for me at the moment of writing this message, even if only once out of several attempts I've made.
Ah, just one more thing. Don't want to make a separate thread for that. Speaking about metatags, we have a parent:none tag (which purpose I really don't understand). Since now it's impossible to negate it, I would suggest creating an opposite tag and make it possible to search for posts that actually have parents. Most of them are duplicates, so I could just copy the tags from one image to another or tag them both simultaneously. Is this idea viable?
Ah, just one more thing. Don't want to make a separate thread for that. Speaking about metatags, we have a parent:none tag (which purpose I really don't understand). Since now it's impossible to negate it, I would suggest creating an opposite tag and make it possible to search for posts that actually have parents. Most of them are duplicates, so I could just copy the tags from one image to another or tag them both simultaneously. Is this idea viable?
I don't know, but parent:none doesn't seem to be currently working in the first place. Maybe it was removed.
