Another Discussion On Tags And Tagging

#1

I thought I’d share with you my tagging naming methods. I’m hoping it might inspire a little discussion. Of course, everyone does things differently, so it would be ridiculous for me to give you a “you should do it like this”. I would like to hear from others how they do it.

All my tags begin with [ and another symbol denoting the type of tag. If it’s a time or a location tag, I’ll use a decimal or “period”: [.202506 for all of my “June 2025” tiddlers. [.Office for my office. None of my tags have spaces and instead are CamelCase-Like, have hyphens (to separate ideas) or underscores to separate words in a string: ["Do_It_Like_This.

If it’s a “User” name or owner, (i.e. yours truly), I’ll use the forward slash: [/AF. For me and my wife: [/IA. My own company: [/SE. etc.

If it’s a version, revision, duplicate, I’ll use [(. Such as in [(FirstDraft.

A web site: [:. An email address: [@. A password, code or serial number: [#. Major category: [+. Minor: [-.

I’m sure you can guess what I’d use for queries: [?.

What I’ve found is that I’m able to handle a long list of tags as they seem neatly categorized and a little more searchable.

Looking forward to your thoughts. Thank you for reading. Everyone: PEACE AND GOODWILL TO ALL!!

#2

I think starting with [ for tags it not the best idea.

I don’t know if we have safeguards against opening braces in all filter operators. But it could cause problems with filter runs. Eg: [tag[[.something]] works, but it looks wrong for everyone that does not know your rules. The operator seems to start with 2 opening [[ braces, which is a syntax error for all other tags not following your rules.

Everybody who reads the tag-documentation will be confused. They have to know your custom “rules” to make sense for them.

You can use your rules, if they work for you, but I think we should not promote them as a standard. So I did change the category back to “Discussion”

There is a reason why we show a warning for tiddler titles that start or end with some braces | [ ] { }. We simply can not guarantee that they work in all circumstances.

image
image1446×225 4.34 KB

1 Like
#3

Absolutely, I get what you’re saying and I appreciate the comment. I want to be clear, though, I am not promoting my way for the community. Thank you for changing the category to “Discussion”. It’s more appropriate as you point out.

Thank you again!

#4

It seems to me that the goal in using the leading [ in your tag naming method is to create a visually distinct prefix that can be readily recognized as saying “this is a tag value”.

However, as @pmario has already noted, it’s generally a bad idea to use the [ symbol for this purpose, as it is extensively used in TiddlyWiki filters to enclose filter runs, as well as to enclose literal values for filter parameters. It is also used in TiddlyWiki wikitext to enclose links to non-CamelCase tiddler titles (e.g., [[sometitle]] or [[Title with spaces]]) and some other syntax such as [ext[...]] for external links.

Unfortunately, nearly all common punctuation is already “claimed” by TiddlyWiki as having a special meaning, so it’s hard to suggest a symbol that won’t result in some collision/confusion with existing syntax. One possibility that might be a workable alternative would be to use = as your tag prefix. It is visually distinct, and also seems to say “what follows this symbol is an indicator of the type of tag”.

The = symbol also has the advantage of not being commonly used in wikitext syntax, as well as meaning “don’t de-duplicate this value” when it occurs in filter syntax, which makes references to =SomeTag nearly the same meaning as SomeTag, so you could write filters like:

{{{ [tag[=.Office]] [tag[=/AF]] [tag[=(FirstDraft]] [tag[=+Project]] [tag[=-Task]] }}}
or
{{{ [[=.Office]] [[=/AF]] [[=(FirstDraft]] [[=+Project]] [[=-Task]] +[tagging[]] }}}
or even
{{{ ==.Office ==/AF ==(FirstDraft ==+Project ==-Task +[tagging[]] }}}

In all of these examples, the result will be a list of tiddlers that match at least one of the indicated tags. Note that in the last example, the = is doubled. The first = is the “don’t de-duplicate this item” filter syntax, while the second = is treated as part of the literal list item value.

Also, within wikitext you can use the square brackets in the normal manner to create links to your tag tiddlers, like this:[[=.Office]] instead of [[[.Office]] (which seems harder to visually interpret as a link to a tag tiddler, since it has an unbalanced number of open square brackets that all blend together).

enjoy,
-e

4 Likes
#5

You know what, Eric, that just might work for me. Visually appealing and easy to spot, logical. Moreover, = are allowed in file names and paths.

I will be changing all of my tags over.

My tagging issues came about years ago when I would import all of the non-system tiddlers from TW.com’s site to my personal TW. That would result in my own tags being lost in the “hundreds” of other tags. In fact, for a while, I abandoned tags altogether thinking them unnecessary.

Another problem is with long tag names. That can happen when we “create a new tiddler tagged with this one”.

Yet another is when there are spaces in tag names.

Does anyone have a “philosophy” of tagging in TW that’s similar to the philosophy of tiddlers?

#6

There are my older “poltergeist” adventures and particularly this post of yours How to snatch tags from another tiddler? - #20 by EricShulman , which recommends more caution about using particularly = and generally any special symbol as tag prefix.

There are new TiddlyWiki users tempted to use # as tag prefix a la Twitter hashtags, while # is at least used in HTML anchors.

There’s the Namespacing section in Grok TiddlyWiki — Build a deep, lasting understanding of TiddlyWiki , which may make it tempting for some users to use just : as prefix for personal tags… and then they learn that : is a legit citizen in filter syntax too, albeit not as often as [. The problem is that a subset of new users (myself included) start with the official TiddlyWiki docs as primary knowledge source, and only later add GrokTiddlyWiki as secondary, complementary wisdom resource. Also, most if not all new users start making use of tags long before they start writing wikitext filters, thus learn about the special meanings of special symbols in filter syntax. The warning for special symbols in tiddler titles that @pmario mentions above, is relevant (since tags are tiddlers), yet very succint.

These facts only prove that tag naming conventions are a big and complex issue, and that new users inevitably end going through changing their tag naming policies and painful refactoring of their wikis as they learn more.

Perhaps they can be helped by having a set of postulates explicitly carved in stone in the official docs, like having a table with all these special symbols and for each of them a couple of examples when using them as tag prefixes causes troubles, similar to the "pesky brackets"™ resource? Something like:

[ - widely used in filter syntax, also clashes with “no nested brackets” rule
+ - used as filter run prefix
: - used as filter run prefix, operator suffix

etc

#7

My philosophy of tagging is my philosophy of tiddlers. That is, something is a good tag name pretty much only if it’s a good tiddler name (with exceptions related to existing system tags of course).

My reasoning is: At every tag pill, the top entry is the tag name, and it’s a shame not to have lots of rich connections through those nodes.

1 Like
#8

My tagging philosophy is to lean heavily on the ability for any tid to tag any other tid (and then for structure between them to emerge somewhat organically). This means an identificable-as-a-tag naming style is something mostly steer clear of - though I can definitely see the attraction and benefits.

That said, I do kind of do it - for cases where something is distinctly tag-first rather than tid-first, AND there are a family of tags of that style, I name them in a tagfamily:tagname type structure. Hence I have tags website:garage website:personal from:stickies from:files from:tw2, and so on. Usually these will be tagged from the family name (website) but not always (eg - the “from:” tags are children of import).

Because I use inter-tid tagging so much, I found value in each tid not only showing what it was tagged by, but what was tagged by it, hence my tid footers look like this (import continues to be a nicely innocuous example):

image
image1808×186 27 KB

And more recently, added a per-tid expandable table-of-contents tree to the info page (this screenshot also showing that the import tag is tagged as TODO

image
image1820×656 82.2 KB

The other distinct tagging thing I do is to group similarly themed tags by colour. So for example, all my TODO-related items are shades of red. My website related tags are shades of green. People related tags are shades of blue, and so on. Usually I add CSS tweaks to the tid views themselves to suit this colouring, which can sometimes result in interesting (and tbh, sometimes ugly) mixes of colours. For instance, here a tid gains a green border for having a tag matching “website:*”, and a red background for matching “TODO”. When it loses the TODO and gains an “ONLINE” tag, it’ll get a green background

image

1 Like
#9

Hi you don’t need to use special prefix to categorize your tags. You could simply use color, like the screenshots above, todo with red, and website is green, and the color is more easy to distinguish.

1 Like
#10

Are tag colors hardcoded or do they automatically adapt when changing the palette?

#11

tag colours are implemented by CSS colour syntax - so they’re hardcoded, but the hardcoding can include an alpha setting allowing them to tint whatever they’re in front of.

But they’re not dynamic in as far as changing between a light-mode colour and a dark-mode colour, or other palette flexibility

The tag manager is the best place to play with this

edit: here’s an example with my scratch tag set to the colour of #0002, and set on an “ONLINE” tid with a green tinted background, and a “TODO” tid with a red tinted background

image
image400×736 33.2 KB

#12

All of these are excellent ideas and thoughts.

Categorizing by colour. I had forgotten about that, so I started doing that again today. But the thing is: the colours don’t move with the tiddlers; what happens, as you know, that in a new TW, they are reverted to default colours.

That’s not to say that it can’t be resolved. But one would need to export the tiddler/tiddlers along with the tag tiddler (which, having been assigned a colour value, would no longer be a missing tiddler).

Assigning colours or icons to the tags is a nice quick way to give the missing tag tiddlers some existence from which we can edit their text fields to have topical list filters.

As with Eric’s suggestion that one of the only standard characters left would be the =: We could use emojis, as well, I suppose. I don’t know how they’re accessed conveniently on Linux and Mac, but in Windows, if you don’t already know, the keyboard shortcut to emojis and special characters is Windows+[.] Androids a little less convenient. I don’t know about iPhone.

#13

This is one reason I gravitate towards “HTML” colours. Some of their colours appeal to me, others don’t. But most of the colours in this scheme seem to be appropriate in both light and dark themes. On top of all that, they have easy-to-remember names which can be freely used in place of their #hex value.

#14

tags can have icons set though - see the examples in most of the tags in my above screenshots, and here’s another showing another being set in the tag manager (and showing it can be an arbitrary image too - can even be images referenced by _canonical_uri)

image

1 Like
#15

Good point! And to that, I actually derive my tags from the tiddler title. I’ll include the “tags” at the end of my titles. This isn’t for everyone, though.

Your solution/philosophy is reminiscent of the TiddlyMaps, which I liked, but found it a little challenging to understand and made the TWs a little bloated.

But I think I might understand what you’re getting at: wouldn’t it be nice to click on the tags, and not only getting a list (with the tag being at the top), but getting a mind-map with edges and nodes to viualize the relations (and possibly distant relations) of the tiddlers. If that makes sense. Then, I guess we’d be Obsidian level and put them out of business. :slight_smile:

1 Like
#16

One person’s easy-to-remember is another person’s “arbitrary and perceived as pointless to remember”. I like unambiguous RGB codes that I can (sometimes) have an idea of the basic colour by reading the code, and if I want it slightly tweaked (bluer?, lighter?, etc, it’s easy). But if I want a slightly greener version of ‘AliceBlue’? big shrug. I just dont do enough CSS to have any interest in learning what 140 colour names are. (The ‘RoyalBlue’ in one of my examples above is only because the TW built-in colour picker is by named colours)

I’m also pretty lazy, so usually use the 3-character shorthand when writing my own CSS, which limits me to just 4k colours. But for a lot of this stuff (and all my examples above), it’s on a private TW for me, so looking pretty is a low priority, so long as it’s functional. I’d put more effort in on something intended to be public!

#17

For a mapping from 151 standard “X11” color names to #RGB codes, see TiddlyTools/Settings/Colors/X11. Note that this tiddler has type=application/x-tiddler-dictionary, so it can be used for lookups using filter syntax like this:

{{{ [[TiddlyTools/Settings/Colors/X11]getindex[AliceBlue]] }}}

enjoy,
-e

#18

that’s neat! (I wont ever use it, but I find colour naming to be of interest)

Curious why just those 151? (my local X11 rgb.txt (unchanged in 25 years apparently) has 753 entries, though some colours have multiple names - collapsing those it’s still 516 entries, and netpbm has a named colour list with nearly 2000 entries, not to mention the XKCD one generated from crowd data!)

#19

My list is based on the “Color name chart” shown in the Wikipedia X11 Color Names article. That list is, in turn, derived from “the standardized X11 color names from the X.org source code”. While this is certainly not universally definitive nor comprehensive, it seemed like a good place to start.

Note that my list does not include:

  • Alternative spellings (e.g. LightGray vs. LightGrey)
  • Any of the 202 numbered shades of gray (e.g., Gray0 to Gray100 and Grey0 to Grey100)
  • Numbered color variants (e.g., Blue1, Blue2, Blue3, and Blue4)
  • Names with spaces (e.g., alice blue vs. AliceBlue, old lace vs. OldLace, etc.)

My list is used in various TiddlyTools add-ons, such as the color value dropdowns in my enhanced TiddlyTools/Palettes/Manager. This add-on also uses the X11 index tiddler to map the color names to #RGB values so they can be correctly handled by the <$edit-text ... type=color/> “color picker” input controls (which only accepts #RGB values).

-e

#20

oh huh, despite knowing the X11 rgb.txt for many years, I’ve never looked it up on wikipedia before. The differences to the W3C colour names I didn’t expect at all! Some good analysis of it all there too. Thankyou!