You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My proposal is to add namespaces/sources to tags, like "Some Site / Tag Name", to preserve their original (and possibly distinct) meanings. These tags should then be mapped to the StashDB tags by dynamic parent/child tag relationships, like the ones in Stash.
Long Form
The main problem with tags from different sources is that they could easily mean different things. For example, "Medium Ass" could have a precise numerical meaning on one site, and be much more fuzzy on another. This makes the whole tag's meaning much more fuzzy if these different tags are treated as the same one.
As far as I can tell, currently this problem is solved by mapping the source tags to more appropriate StashDB ones when importing the metadata. This requires some level of expertise, for each tag on the site, from the one doing the importing, at the time of import and ultimately makes the process more difficult and slow. And without expertise or care, or by mistake, it pollutes the meaning of existing tags.
On the other hand, tag namespaces would allow to:
preserve distinct meanings of tags with same or similar names but from different sources;
prevent SEO noise from polluting the tags on StashDB;
preserve the original tags of the scenes and allow searching by them, even if they're fuzzy, since it could still be useful, but do so without polluting other tags;
allow to easily add tags from new sites even when there's no existing corresponding tags on StashDB, without tag pollution;
simplify importing the metadata, since it would only require copying the source tags as is;
allow users to distinguish their own tags from the imported ones.
Then, these namespaced tags could be dynamically mapped to the StashDB's ones, like in Stash, by using parent/child tag relationships. And if a mapping is wrong, it's easier to fix, since it wouldn't require re-importing the scenes, only editing the parent/child relationships.
In other words, the idea is to threat the sites/sources as the ones responsible for their tags' meanings.
Examples
For example, the Vaginal Sex tag has the alias "Vaginal", which is not wrong by itself, but which could also mean Vaginal Penetration, depending on the source. And it's not always instantly obvious which tag is meant by the site.
In this case, the namespaced tags could be:
Cool Site / Vaginal
Another Site / Vaginal
Both of these tags could be mapped right away to the generic "StashDB / Vaginal Penetration" tag, if it's clear that they're not SEO noise. So, the scenes of the "Cool Site" would have the "Cool Site / Vaginal" tag, but could be found by "StashDB / Vaginal Penetration", too.
Then, it's determined that "Cool Site / Vaginal" actually means "StashDB / Vaginal Sex" and the mapping is updated.
My Experience With This Method
I use this idea in my local Stash, by naming the tags with a namespace prefix (just as a naming convention). I've also updated the scrapers locally to include the namespace, too. This made my tags much more precise. I no longer need to fight with the imported tags polluting my manually-tagged scenes, the tag scraping is now completely automatic.
I find the dynamic nature of parent/child tag relationships to be much better suited for gradual organization. If I see that a mapping is missing, it's easy to add one for the whole site. And if a mapping is wrong, it's trivial to delete or change it, too.
The text was updated successfully, but these errors were encountered:
Scope
My proposal is to add namespaces/sources to tags, like "Some Site / Tag Name", to preserve their original (and possibly distinct) meanings. These tags should then be mapped to the StashDB tags by dynamic parent/child tag relationships, like the ones in Stash.
Long Form
The main problem with tags from different sources is that they could easily mean different things. For example, "Medium Ass" could have a precise numerical meaning on one site, and be much more fuzzy on another. This makes the whole tag's meaning much more fuzzy if these different tags are treated as the same one.
As far as I can tell, currently this problem is solved by mapping the source tags to more appropriate StashDB ones when importing the metadata. This requires some level of expertise, for each tag on the site, from the one doing the importing, at the time of import and ultimately makes the process more difficult and slow. And without expertise or care, or by mistake, it pollutes the meaning of existing tags.
On the other hand, tag namespaces would allow to:
Then, these namespaced tags could be dynamically mapped to the StashDB's ones, like in Stash, by using parent/child tag relationships. And if a mapping is wrong, it's easier to fix, since it wouldn't require re-importing the scenes, only editing the parent/child relationships.
In other words, the idea is to threat the sites/sources as the ones responsible for their tags' meanings.
Examples
For example, the Vaginal Sex tag has the alias "Vaginal", which is not wrong by itself, but which could also mean Vaginal Penetration, depending on the source. And it's not always instantly obvious which tag is meant by the site.
In this case, the namespaced tags could be:
Both of these tags could be mapped right away to the generic "StashDB / Vaginal Penetration" tag, if it's clear that they're not SEO noise. So, the scenes of the "Cool Site" would have the "Cool Site / Vaginal" tag, but could be found by "StashDB / Vaginal Penetration", too.
Then, it's determined that "Cool Site / Vaginal" actually means "StashDB / Vaginal Sex" and the mapping is updated.
My Experience With This Method
I use this idea in my local Stash, by naming the tags with a namespace prefix (just as a naming convention). I've also updated the scrapers locally to include the namespace, too. This made my tags much more precise. I no longer need to fight with the imported tags polluting my manually-tagged scenes, the tag scraping is now completely automatic.
I find the dynamic nature of parent/child tag relationships to be much better suited for gradual organization. If I see that a mapping is missing, it's easy to add one for the whole site. And if a mapping is wrong, it's trivial to delete or change it, too.
The text was updated successfully, but these errors were encountered: