@TW_Tones But e.g. how can I search all Tiddlers which are included white trousers. With your tag example this tiddler would be listed too, but the trouser is blue. I think the direct assignment between type and color is necessary. Or is there another solution to search?
I concur with @pmario and @TW_Tones that fields would make so much more sense here. It will reduce the computational overload if your combination-search isn’t scanning for all tag combos, and it will allow you to set up efficient filters easily.
You can have filters looking for any combination of fields and values in those fields. For example, {{{ [trousers[blue]has[hat]!has[scarf]] }}} lists all tiddlers with blue in trousers field, and some value in hat field, but NO value in scarf field.
When it comes to your initial interest in a tag-combination frequency overview, I find myself wondering what patterns really matter, and why. A fields-based solution is likely to be more powerful.
It could be as simple as [all[]tag[white]tag[trousers]] however if the thing is trousers you could make one or more trousers tiddlers by having the field “thing” containing the value trousers, then all trousers is [all[]thing[trousers]] then only white ones ``[all[]thing[trousers]tag[white]]`
ChatGPT v3.5 says the following when asked;
Explain the difference between organising things with tags verses with field value pairs?
Organizing things with tags and organizing things with field-value pairs are two different ways to structure and categorize information.
Tags are keywords or labels that are assigned to items to help categorize them. They are typically user-defined and can be assigned to an item to indicate its relevance or to help find it later. Tags are flexible and allow for non-hierarchical organization, meaning that items can be tagged with multiple tags, and each tag can be applied to multiple items. This allows for a more organic, fluid way of categorizing items.
On the other hand, organizing things with field-value pairs involves defining specific fields for each item and assigning values to those fields. This approach is more structured and hierarchical, as each item must fit into a predetermined set of categories. For example, if you were organizing a collection of books, you might have fields for author, title, publication date, and genre. Each book would need to fit into one of these categories, and there would be no overlap.
In summary, organizing things with tags is a more flexible, user-defined way of categorizing items, whereas organizing things with field-value pairs is a more structured, hierarchical approach. The choice between the two will depend on the nature of the items being organized and the preferences of the person or organization doing the organizing.
Personally I would use tags for grouping things as needed, in an ad hoc way. I would use fields to categorise tiddlers, or give them (the tiddlers or products) attributes such as type, color subclass etc…
- Once you learn your filters both are easy to use.
@TW_Tones I feel like this suggestion departs dramatically from @Ransche’s purpose. 
The project (described in post 18) focuses mainly on tiddlers for outfits (rather than individual garments). So, using a “thing” field with value “trousers” would not seem to make sense, especially because giving the whole tiddler a “white” tag (simply in virtue of having white trousers) would not allow OP to distinguish white-trousers blue-shirt from blue-trousers white-shirt outfits.
As @pmario suggested above, having a field for trousers (with any attributes of those trousers as values of the field) and a field for belt (with values as attributes of belt), etc., seems to be much clearer. Presumably tags would make sense only for “top-level” attributes of an outfit (business-casual vs loungewear vs athletic or that kind of conceptual space, perhaps, plus the actual tag “outfit” – if the wiki also has tiddlers for specific garment-types or styles, etc.)
Still, the details of a project like this will depend greatly on the purposes and workflow to which it’s devoted. Color names in particular are a huge data challenge! (To make searches meaningful, one needs a plan about whether to distinguish solid white from solid beige or ecru or khaki, all those from tan, tan from brown, and a way to handle any complexities like patterns, textures, stripes – which may or may not seem, at a distance, like the average of those colors…)
All this isn’t to discourage @Ransche but to highlight that getting meaningful data out (like how many outfits have white trousers with blue shirts) will depend on whether this universe of outfits offers neat cubby-holes for garment-types, colors, etc.
Perhaps it does, but I was simply illustrating a different and I argue better way to use fields and tags. I could have systematically reviewed the details of the project and hope to fully reverse engineer a full solution, but there is a limit to how much advice, especially when it is not the original request.
- With the example of colour you could name all colour variations, or you could introduce color wheels etc…
A full solution needs the designer to know the data they wish to represent and map that to an appropriate “data model”. This is something we can help with but to do it all is something more than that.
I was not sure if I should quote ChatGPT directly again, my prior quote was from ChatGPT 3.5 but I did use Chat GPT 4 this time and thought it may be a better answer. Of course I can work on it a little more before sharing
@Ransche welcome to the community, would you like a more thorough outline?