Great thread. Good questions. Good answers.
Two things unexplained …
Pacifist Cross-Cutter
TT
And I find myself very much on the other side. I find it easy enough to write [tag[website]tag[garage]] when I want the combination, but to also use [tag[website]] or [tag[garage]] and to mix and match with [tag[book]tag[garage]] or [tag[garage]tag[band]] as needed.
If I used such tags often for TOC entries, I might have to rethink this, but so far that hasn’t really been an issue.
I think in my use case it’s that I don’t need to write filters for tags very often, but I have an automatic tag-cloud in my sidebar which I use heavily (or maybe lazily is a better description).
If I was writing filters directly more often, I’m sure I’d prefer the flexibility of the seperate tags
aha thanks! yeah I am so far leaning to keep my current tags, which have just grown being separate ones, which I add as needed
however this also sometimes results in a tiddler with like 10-15-20 tags 
We call this “tag Pollution”, too many tags making the wiki or tiddlers harder to use. Tags are an easy to use way to organise information, I personally avoid them if I can and use fields and list fields and my flags solution (a no-touch form of tags). We can also use alternative tags fields or hide some tags from visibility. I do not feel combination tags is going to help much as it does not change the amount of information in the tags field.
I hope one day to release a set of tools which are Tag adjacent one day. I just need to find a set of User Interface elements to accompany them, see this discussion on flags
I have a fairly different notion of tag pollution. To me, tag pollution is when the wiki as a whole has too many tags. I’ve done this on several occasions when I used tags to manage a large table of contents. For instance in my King James bible wiki, you can see that there are over 1250 tags. I have since found better ways to manage my tables of contents for such wikis. For instance the TOC for a policy manual. When I get around to revisiting the bible wikis, I will probably use something like this, reducing my tag count below 20, I imagine.
I don’t think I’ve personally ever had more than 10 tags on a tiddler, and rarely more than a handful. But of course different wiki designs will have different outcomes. For what it’s worth, tiddlywiki.com has these counts today, among all tiddlers and shadows:
| Tags | # of Tiddlers |
|---|---|
| 0 | 2139 |
| 1 | 1566 |
| 2 | 511 |
| 3 | 98 |
| 4 | 26 |
| 5 | 8 |
| 6 | 0 |
| 7 | 3 |
| 8 | 0 |
| 9 | 1 |
| 10 | 3 |
| 11 | 2 |
| 12 | 5 |
| 13 | 3 |
| 14 | 0 |
| 15 | 2 |
So, yes, this could get out of hand if many tiddlers have a lot of tags. I think it’s less of a problem, though, than having too many tags across the wiki. This is another reason for [tag[website]tag[garage]]. It avoids the proliferation of tags.
Right. Your chart of tiddlywiki com tag use is interesting to see!
My own takeaway is simply that “Tag function” in TW is incredibly flexible—for structuring, finding and everything else.
FWIW, in my typical usage, I mostly …
… use TW tags to aid Structure;
And I the use (not TW tags) #hashtags in plain text in the body for Categorizing content.
TBH, a competent researcher of Information Design could easily spend a year figuring out all the ramifications of TW Tagging—it’s that good.
TT
#scott - #taggery - #tw
sorry what - hashtags? 
do you then have filters and etc kind of organisations tools using hashtags, that’s another whole dimension to this !
Have you adopted a solution to support these?
Wrapping such hastags to turn them into missing tiddler titles [[#hashtag]] would be a start.
I have “played” for altering the parser and the $link widget to detect #title in content and make it into a link
links[] and backlinks[] and missing tiddlers (if missing) in which case prefix[#] allows you to list all “hash tags”.The key advantages with turning hashtags into titles is opening them up to further use all without filling the tags fields up.
That is my default position, that “too many tags in the wiki is tag pollution”, however if a lot of tiddlers require a lot of tags, especially if the number of tags causes a new line in the list of tags on any given tiddler indicates the wiki is being “driven” by mostly tags only. I think it fair to consider this a different case of “Tag Pollution” or overuse.
A tool to find one or more hash tags in a tiddler text when viewing that tiddler would be helpful but if they are titles, even missing titles, then freelinks plugin can highlight them (unnecessary If the parser made them links)
somewhat related to the topic, you can create a tiddler icon cascade template to show the permalink-button icon to all tiddlers or specific ones that meet a filters criteria.
I used to do this, though I was a bit bummed by it not actually adding the tiddler title of the permalink-button to the icon field of the tiddler.
same can be applied by automatically coloring tiddlers.
I used to group my tiddlers based on ‘topic, category, status’ where every tiddler was a topic, if a tiddler was tagging any others, it would be a category, and some category tiddler tags were status categories, i.e. ‘topic > category > status’ and thus would apply colors and icons defined by this.
I don’t remember if manually adding a tiddler title to the icon field would override the Tiddler Icon cascade or not, but im sure if it doesnt you could just add a condition in the filter like [!blank[icon]then[....]] or something to that effect.
(sry, doing this from my phone, might be some typos)
The thread is about TW Tags, not #hashtaggery, so I will keep this short.
MY specific use of #hashtags in Tiddler body text is very simple.
It is the easy way to Find Content Without Complexity.
Example “#test” …
TT
almost like two tag types, or tiddler tags and hash tags. how many types of tags is too many though 
I suppose it’s all in the name, tags are on the tiddler hashtags are in the content, if we wanted we could add features to tiddlywiki to turn hashtags into titles, these links allow you to open and see related hash tag, items but we could also divide tagging between tags and hash tags and even use the existence of a named hash tag within a tiddler to behave like a tag in the various cascades.
This could go a long way to reducing standard tags field, tag pollution, while adding new features.
Keeping in mind it adds no more complexity, only features to how you use hash tags @TiddlyTitch
but wait, there is more, the steak knives 
If we return to the beginning of this topic we see the issue of naming tags with a prefix and the pros and cons. it comes to mind that when we use tags to construct a table of contents the titles are somewhat different and less likely to be the type of wordy title tags we would apply a prefix to, they tend to be existing tiddlers, that are not utility tags and tiddlers like @Springer speaks of. They, TOC tags would also tend to be only one on each tiddler, which indicates the parent.
for example what if TOC tags, typically a title in a specific tag hierarchy, could be selected from a specific tag heirachy but not appear in the standard tags dropdown, Thus not intefear by making that list much bigger.
Similarly we could insert hashtags in text from a dropdown of existing hashtags from the editor toolbar or just type it of course.
all of these enhancements are achievable and not rocket science 
to implement, but most importantly once available, will be easy for users to understand and use, and to me that is compelling.
Okay.
Call in-text category markers preceded by “#” ‘Category Markers’ rather than “tags” 
My point was nothing special. “#hashtags” are simply text. Finding them is just text search.
They have a big, easy, relevance to Tiddler search.
But they do nothing other than be text.
TT
It’s an interesting idea. I think at times it might work for me. But more often it wouldn’t work. I have numerous wikis similar to my SQL Playground or Periodic Table where the root of the TOC contains a mix of top-level information about the wiki and TagTiddlers that I will use in other places besides the TOC.
I know you have done a lot of work on alternatives to standard tagging. I’ve found little need for that myself. I find standard tags cover nearly everything I need for categorization and organization, except for one thing: in a number of scenarios, they are problematic for TOC’s. Tag-based TOC’s are simply not flexible enough for me in many cases. For my use-cases, the trick is not in updating tag handling but in using better TOC tools.
Agreed. And the one from @EricShulman is as well, both adding flexibility in different directions.
But my needs are sometimes still not covered. I’ve taken to writing custom TOCs for various wikis. I haven’t yet found enough commonality to consider attempting a generic solution for them… although I hope one day to be able to.
Just one example: RHAM Policy Manual. In this far-from-complete wiki, the TOC is generated almost entirely from the structure of the titles.
For instance Policy5113(HS)(I)(A) (usually known by its caption, “Excused Absences”) is a child of Policy5113(HS)(I) (“Classification of Absences”), which is a child of Policy5113(HS) (“Attendance Policy (High School)”), which is a child of Policy5113 (“Attendance Policy”), which, finally, is a child of Section5000 (“5000 - Student”).
All of this is handled by a custom TOC implementation, which is modeled after the one in the core, but uses the title structure instead of tags to calculate the hierarchy. The TOC should look like a standard one, but it’s a very different implementation.
This is a useful technique for wikis that are mostly hierarchical. But it would likely be entirely inappropriate for other wikis I maintain.
And now that I write this up, I can start to imagine a common implementation. I will try to think it through soon.
I think that’s totally fair, for this special usecase. Our toc-macros have been written in a way, that they can be modified. It’s the recursion stuff that is hard to understand for new users. But if you dig into it, also customising the core TOCs is possible, without completely overwriting them.
There are a lot of “sub procedures” now, that can be locally ovewritten, without overwriting the global macro. The only thing missing here is more step-by-step examples
-m
Probably mainly because the docs is not finished yet. That’s totally my fault.
