Danbooru 2

There's been some mention here about rethinking the way parenting works.

Here's my proposal:

Replace the idea of parenting with pools. When you tag something pool:new, it will create a new pool tag, something like pool:123 where 123 is the ID of the pool. You can then tag related posts with this pool tag. This gets rid of the tree like structure of parenting but I'm not sure how useful that was, especially in ambiguous cases. You can later on edit this anonymous pool, giving it a title or ordering the posts however you like.

There could even be a Create New Pool option in the upload form, along with an option to add a new upload to your most recently created pool. Maybe a pool:recent tag would also work.

albert said:
There's been some mention here about rethinking the way parenting works.

Here's my proposal:

Stuff

Will this new version of parenting still include the borders marking similar images?

Re: replacing parenting with pools.

This is how I was imagining it would work the last time this idea was brought up:

Replace the 'Parent' field with a 'Related Posts' field. When you want to group some posts together, you would go to one and enter the post IDs of the others in the Related Posts field. If the other posts are already in an anonymous pool, then the new post is added to that pool. If the other posts aren't already pooled, then a new anonymous pool is created and all the posts are added to it.

This way you don't have to deal with making new pools or with looking up a pool ID to add new posts to a pool. You just need to know the IDs of the related posts, same as with parenting.

evazion said: This way you don't have to deal with making new pools or with looking up a pool ID to add new posts to a pool. You just need to know the IDs of the related posts, same as with parenting.

I think I like the "related posts" idea a bit better. You'd just have a bar up top or whatever saying "This post has related posts, click to see" or something like that.

In moving to pools/pool-like features I will miss the obvious distinction between parent (green) and child (yellow). No, not every parent group was a superior/inferior or before/after relationship but quite a lot were. Unless there's a way to work that in...?

It seems like nested tags might not be implementable easily.

I can only think of two common uses for them:

• Specific attributes of a generic tag, like (thighhighs (striped)) instead of striped_thighhighs.
• Specifying which part of an image the tag applies to, like "(kaguya (black_hair)) (mokou (white_hair))" instead of "black_hair white_hair mokou kaguya".

However, I can't think of a reason to do (a (b (c)), unless it's a combination of the above two.

The first is handled by specific tags implying the less general one, and that might be good enough.
For the second, it could allow only one layer of child tags (but call them attached tags instead), so you could do "(kaguya black_hair) (mokou white_hair) touhou". That's easier to store (I think) and also easier to display (just indent the attachments).

memento_mori said:
The first is handled by specific tags implying the less general one, and that might be good enough.

This is what we are already doing with combo-tags, but it's messy and inelegant. It ends up leading to a potentially combinatorial number of tags (for every adjective noun pair that is meaningful), and each is typically only used for a handful of posts.

Having a string of implications for each combo solves the problem of diluting the more general term (because they will invariably end up being omitted without them), but they have to be done manually, by an admin, after discussion in the forum. More likely someone someone will coin a new combo-tag on the fly, and just slip it in without discussion, causing the implication to not be created.

Thirdly, the string of implications, or even just manually adding the base tag (and adjective if it's a tag on its own, like striped, tartan, checked, etc) leads to tag bloat in the taglist of the posts in which it is used.

See also forum #35599 for a practical example of some of the problems with this method.

memento_mori said:
For the second, it could allow only one layer of child tags (but call them attached tags instead), so you could do "(kaguya black_hair) (mokou white_hair) touhou". That's easier to store (I think) and also easier to display (just indent the attachments).

I'm not sure that this would be a lot easier to implement than the general case, though if it is, I'm sure nesting of limited depth would be better than none at all.

For the problems in the first case though, and the incompatibility of combining the two cases if we use nesting for both without multiple levels, I would still look at exploring ways to do two levels or deeper if possible.

Even in the ideal case, limiting the depth wouldn't be much of a problem, though one level would be quite limiting.

I don't think display would ever be a huge issue (displayed indented or in a file-tree like you say) so long as levels can be closed/hidden and the taglist scrollable. Both of which are relatively easy to do with CSS and AJAX.

Different feature request: show edits involving a particular tag sorted by time. I want to know who invented sleeves_past_wrist.

Shinjidude said:
Tag ontologies: I think by explicitly defining ontologies based on tag generality or specificity could be very useful, would provide semantics to a common category of implication, and would allow us to have shorter, less cluttered tag lists. For example we could define (miniskirt < skirt < bottom < clothing). That way anything tagged "miniskirt" would imply all of the above without having to explicitly state it in the taglist either via implication or otherwise. We could then use those semantics to say query bottom to get all instances of miniskirts, pants, bike_shorts, etc.

I don't know how, but E-shuushuu.net uses something like this; for example when an image is tagged bird , it will come up in a search for animal , because "animal" is a parent tag of "bird", but images tagged "bird" are not also tagged "animal".

Yes, that is basically what I'm talking about. Also if you look at their version of our wiki pages (e.g. http://e-shuushuu.net/tags/9 ) you can see that parent tags and alias tags are explicitly displayed there. (also interesting that "cat" is tag #9)

I'm not sure where these are set, perhaps they are admin-only. If it is, that would put a lot of work on Albert & jxh2154. If we implemented something similar, I'd suggest we leave it open for at least jan+, maybe contrib+ to help maintain.

ZeroChan also appears to have a form of tag parenting, if anyone's interested.

Okay, I just thought of one. When you fetch Pixiv tags and other info, can you get the medium, too? It'd be a good reminder.

I assume you mean the medium as in traditional_media, not the "medium" size image?

I think he means the program used to author the image. I'm not sure if the equivalent of our "traditional_media" is an option, but most Pixiv posts indicate the medium used, such as SAI, Photoshop, ComicStudio, etc.

EDIT: After checking, it appears that traditional mediums such as pencil, mechanical pencil, colored pencil, watercolor, fine-tipped pen, copics etc are also indicated.

A few more ideas:

• Allow images to have more than one source link.
• Provide a way to record an image's title, if the artist provided one.
• Record the date & time the image was originally published, if it can be found.

evazion said:
Provide a way to record an image's title, if the artist provided one.

This used to exist and it was only ever used for evil.
That was in the pre-Pixiv days, though.

evazion said:
Provide a way to record an image's title, if the artist provided one.

phane said:
This used to exist and it was only ever used for evil.
That was in the pre-Pixiv days, though.

Posting title/commentary in the comments in conjunction with the commentary tag seems to suffice without inviting abuse.

evazion said:

• Record the date & time the image was originally published, if it can be found.

Speaking of recording time & date of an image, would it be possible to install something that tell you the time & date of a post based on your timezone instead of what Danbooru use? Military time always confuses me so much. Also would it be possible to install some kind of cool-off period between user uploads? 5 minutes max seems like a good idea. Something to allow others to actually get something valuable.

BTW, When will the new system(s) be installed? In the coming week or so?

Edit: Okay...maybe that cool-ff idea a bit silly to throw out there. It was just something I wanted to say really.

Mr_GT said: Speaking of recording time & date of an image, would it be possible to install something that tell you the time & date of a post based on your timezone instead of what Danbooru use?

Worthwhile probably.

But what I really want is more precise timestamps. "One month ago" for emails and such creates problems when I'm doing admin-like things, such as trying to determine if someone persisted in bad behavior after I emailed them about it or not. Same with comments.

I know there's ways to tell what day an image was posted, but I wish it would say so on the page.

Regarding integration of IQDB:

I would definitely like to do this, but I'm not sure how useful it'd be. When you're uploading in image, Danbooru doesn't have the image file, so it can't run a similarity query yet. If you're uploading from a URL I guess it could automatically download the image, but that means viewing the upload form takes longer. And this doesn't help people who upload files local from their computer.

Is there any way this could be done asynchronously? Say load the default page, and let people begin tagging it, and later load any sort of issues related with duplicate entries?

This should also be possible for directly uploaded files, I think as there are sites that provide their own AJAXy upload meter and can do work as the file is loading.

This would also be a good way to provide suggested tags, as that process is likely slow as well.

EDIT: I don't know if it's useful at all, but a quick google brought up http://valums.com/ajax-upload/ as an example. You had mentioned looking at using jquery, and this sample uses it to accomplish asynchronous upload.