Tag aliases

[echo6ix]

Per Tag Improvements on the road map, "Tags should be able to have sub-tags [...] this still needs to be fleshed out more", and as discussed on stashapp/stash#115 and stashapp/CommunityScripts#410 inherited tags.

I don't know if what requires fleshing out is what functionality this would bring to the user or how it would be implemented on the backend.

What are tag aliases?

As originally discussed from the Ruby project, tag aliases would act as an alternate set of tags for any primary tag [primary meaning any tag that is currently used in Stash]. This feature request was tied to stashapp/stash#6 Tagging based on file name. With that original relationship in mind, the requested application of tag aliases was to use similar terms to describe the primary tag as a means to make file-name based tagging a lot more thorough.

But they can also be used for manual tagging with keywords that are used interchangeably to mean the same thing. For example tagging something with the words tiny, petit, or small is basically the same for many people. We don't need primary tags of all of them if we're using them to mean the same thing. But once you develop a long list of tags it's difficult to remember the exact keyword you have used for something. Tag aliases would alleviate this problem, remove tag clutter, and help with organization.

A description of this in pseudo-code would be,

"tags": {
    "primary tag": "car",
        "tag alias": [
            "automobile",
            "vehicle"
        ]
    }, {
    "primary tag": "threesome",
        "tag alias": [
            "3some",
            "3-some",
            "menage-a-trois",
            "menage a trois",
            "mmf",
            "fmm",
            "ffm",
            "mff"
        ]
    }
}

The above tag alias contains alternate terms of the primary tag.

Example functionality

Let's suppose the following filenames that Stash is going to scan and auto-tag (when and if that gets implemented):

Scanning new files...
"threesome.mp4" : Primary tag found in filename. Scene auto-tagged with "threesome"
"milf.thresome.mp4" : Primary tag found in filename. Scene auto-tagged with "threesome"
"horny.blondes.ffm" : Tag alias found in filename. Scene auto-tagged with "threesome"
"dp_mmf_mature.mp4" : Tag alias found in filename. Scene auto-tagged with "threesome"

Without a tag alias Stash would have only picked up half of those filenames. With the tag alias, Stash identifies keywords belonging to the primary tag, and attributes the primary tag only to each filename.

Conflicting primary and tag alias names

What if primary tag uses the same name as a tag alias of another primary tag? Or if two different primary tags contain a tag alias of the same name? I gave this some thought and think any tag, whether primary or an alias, should have a unique name.

I suspect there is the potential for many awkward usability issues if allowing duplicate tag alias names that might make the program and code unnecessarily complex, but this isn't my forte so maybe there's a good solution and use-case examples of where duplicates would be desirable.

Where does the user create tag aliases?

Obviously tags would require their own page containing their data that can be edited, such as

• primary tag, renaming or deleting
• tag aliases, renaming, creating, and deleting
• maybe it would be a good idea to allow tag type conversion? converting a tag alias into a primary tag and converting a primary tag into a tag alias of x.

The creation of a tag edit page seems inevitable since stashapp/stash#5 Tag thumbnails are on the roadmap. The UI could be similar to my concept for the Studio edit page here: https://user-images.githubusercontent.com/37937507/63980020-6a579b00-ca88-11e9-89ad-b46f63368c8a.png

Relationship between manual scene tagging and tag aliases

If the user is manually tagging a scene and they type the name of a tag that already exists as a tag alias what should the behavior of the program be?

(1) Stash should filter the list of tags based on the name (as it currently does), but should handle matching tag aliases differently to avoid confusion. Therefore, the filtered list should only display the primary tag of a user typed tag alias once there is a complete match of the tag alias rather than a partial one. For example lets say,

• there exists a tag alias named "automobile" associated with a primary tag called "car"
• the user is typing a tag name and so far they have partially typed the string "auto".
• the list will filter any primary tags containing the word "auto", as it currently does
• the filter list should not look for partial matches of tag aliases, thus it should not show the primary tag "car" based on a partial match of the word "automobile"
• the filter list should only show the primary tag "car" once there is a complete match for the tag alias "automobile"

My reasoning for this specificity is because otherwise the filter will be bogged down with too much irrelevant partial matches.

(2) Stash should follow the behavior proposed in (1) but cosmetically highlight the match of any associated primary tag in a subtly different colour as a visual indicator that it's different from the partial name matches on the filtered list.

(3) If the user types a tag alias and it's primary tag is applied to the scene, there should be a temporary (like 3 or 5 seconds) visual indicator (such as those already existing green informational popups that Stash uses) informing the user this was the intended behavior of the program, such as: "{Tag alias name} is a tag alias of {primary tag}". This will help avoid any confusion since the user is basically typing a keyword, applying it, and then something different than what they typed is being applied.

(4) Or forgot option (1) completely, and just filter the list based on all primary and alias tags, but this should definitely warrant option (2) that cosmetically denotes any tag aliases in the list, and option (3) as once they submit their tag alias it will be converted into its primary tag.

Should Stash display tag aliases in any of the tag lists or grid views pages?

My opinion is no, it just increases clutter. Their purpose is analogous to an email alias that catches old, associated, or commonly mistyped addresses into one umbrella. Your email client doesn't need to show you all its aliases outside a settings page.

The only exception I can think of would be if there was a dedicated page to each primary tag analogous to stashapp/stash#115 my studio page concept at, where a list of tag aliases could be displayed beneath the main tag heading and thumbnail or something like that.

[GernBlanston12]

(This comment concerned Parent Tags, the functionality of which should be separate from, but implemented alongside, Tag Aliases. They are not the same thing.)

[echo6ix]

I think we've basically described the same functionality, on this thread and elsewhere, except with regard to unique tag alias names. But I only mentioned unique tag alias names because I'm not a programmer and wasn't sure if allowing duplicate tag aliases would make things like searching awkward. After giving it some thought it probably wouldn't be awkward at all.

Say you have the following tags:

"tags": {
    "primary tag": "car",
        "tag alias": [
            "motorcar",
            "vehicle"
        ]
    }, {
    "primary tag": "truck",
        "tag alias": [
            "pickup",
            "vehicle"
        ]
    }
}

And the user queries the tag alias vehicle. This would return hits for the primary tags car and truck, which in retrospect would be perfectly fine.

Does Pornganizer allow it with their aliasing? I haven't used it since Stash was released tbh, but something tells me you can use the same alias name for different primary tags.

[GernBlanston12]

Tag aliasing is NOT the same as inherited tags. Tag aliasing means the program interprets multiple words as belonging to a given, common tag. Tag inheritance means the tag itself is a sub-set of a larger, more general, parent tag, and that the more general, parent tag is applied whenever the child tag is. It's "tagging of tags". A user case would be: I create tag "Tattoos" and I also create "Sleeve", "Neck", and "Thigh" tags. Afterward, I "tag" the Sleeve, Neck, and Thigh tags with "Tattoos" as a parent. Now, whenever I add the "Sleeve" tag to a video, OR if the auto-tagger picks up "Sleeve" in the file name, it automatically adds "Sleeve" AND "Tattoos" tags to the video, without me doing anything. Thus, if I query "Tattoos," I get videos with Sleeve, Thigh, and Neck tattoos, but if I query "Sleeve" I just get vids with sleeve tattoos. The reverse is NOT true: A child tag is not automatically tagged to a video when a parent tag is.

Here is another use case, involving studios: Mofos is a studio that split from Brazzers, and now hosts sites I Know That Girl and Public Pickups on their main Mofos website. If I create studio tags for "Mofos","I Know That Girl", and "Public Pickups", and then I specify that "Mofos" is a parent of the other two, then whenever the child studio is tagged to a movie, auto-tagger or otherwise, the parent studio is added as well. All "Public Pickups" videos are "Mofos" videos, and I shouldn't have to tell the database that over and over and over. NOT all Mofos videos are Public Pickups, but that's why it's "inherited" and not an "alias".

[GernBlanston12]

The difference between the two issues is, aliases roll up to the same 1 thing, where inheritance works on a parent/child basis to add both tags, making each function independently as a way to query/sort, as well as showing up when their parents are queried. The number of levels and nature of these hierarchal relationships is totally up to the user. You could have parent tag "POV", with child tags "Male POV" and "Female POV"....then you could make "POV" a child of "Steadycam", if you wanted. Another use case would be leggings of various types under the parent tag "leggings", which is itself a child of parent tag "Lingerie".

A use case for "tag alias" is, Kara Bare, Kara Mynor and Sasha Lenee are all the same person. Tagging any one of those, auto-tagger or otherwise, should invoke the same Performer tag. A use case for inherited tags is, Sasha Lenee is a (dyed) blonde. Whenever I tag a video with Performer Sasha Lenee, that video should also get tag "blonde" without me doing anything, if I have specified once that "blonde" is a parent, or is inherited by, "Sasha Lenee". It compresses user effort, eliminating all those times you have to illustrate these relationships to the database, and it allows the user to define limitless hierarchal relationships among tags. Both have their function, both are necessary, but parent/inherited is not the same as alias of.

[Leopere]

This sounds like a really good but super complex system to develop. It could be really useful long term for organizational mapping of metadata but I think for the most part thats just search and relational display and potentially related to recommendation systems. If this app goes that far it starts courting the concept of transitioning from a stash app to a portable video site.

This seems to me like a very late game addition.

[GernBlanston12]

"If anything is tagged with A, tag also with B, C, and D" can't be that hard to implement, at least where inherited tags is concerned.

[WithoutPants]

I've removed the "sub-tags" part of the title since it is easily conflated with a tag hierarchy (parent/child tags) concept.

[WithoutPants]

$25 bounty placed.

[WithoutPants]

Design note: allowing multiple primary tags to have overlapping aliases would result in ambiguity when resolving the primary tag during auto-tagging or scraping operations. For ease of implementation, I'll restrict tag aliases to be unique. The case for making these non-unique can be made in another issue.