Techniques for tag heirarchies?

I've been considering the possibility of doing hierarchical tagging, but nothing really complex: really, I just want to have a set of tags with different states. By way of example, from my evolving submissions tracking method:

I have a Zettel for each story I have on the market, a Jobsheet of sorts. I'd like to be able to tag each story with a status, like

#subs:out
#subs:waiting
#subs:edits

etc.

The #tag:subtag doesn't work in either The Archive or with Rene's SublimeText plugin, because, quite reasonably, the regexes involved miss the :. I'm currently doing stuff like #subs_out, which works alright but is kind of unattractive.

@toolboxen said:
Try a dash - or period . or semi-colon ; instead of colon? I'm partial to periods although not sure how the regex would handle them:
[...]
Could also try pipes or slashes?:

I would prefer the colon, as in my opinion it better conveys the notion of a hierarchy, reminds of YAML blocks that some ppl already use in their Markdown texts, and also of e-mail headers like from:, subject:, etc.

I think it would be safe if a tag regex treated a colon immediately followed a character as belonging to a tag or would this conflict with any other common usage? @rene and @ctietze any thoughts?

I don't know if it would conflict but supporting colons is not a big deal. In the SublimeText plugin I define a set of stop-characters to cut off garbage from tags in ag's search results (think "sentence ending with a #tag.") That simple logic would need to be adapted to support colons followed by letters and numbers, etc. Just colon followed by (any) character would probably not be sufficient in weird http:// like cases.

So I suggest: either removing colons from the list of stop characters -> supporting colons in tags or maybe supporting double-colons (as in C++ scopes: #subs::waiting).

Then again, Flickr used key--value-combo tags like #country:USA for a while in the beginning. Camel-cased tags are not a good fit if you want to use stuff like this for technical processing -- which, frankly, is the only useful application of these kind of tags.

I used tag hierarchies for my earliest del.icio.us bookmarks. See the list of all my current tags. It was nice to have some context at first, seeing all related tags at a glance:

... but then I found myself assigning, say, webdesign:color and interior-design:color to the same bookmark instead of webdesign interior-design color. Going down this rabbit hole is a waste of time. I prefer "show related tags" (in set logic: show all intersections) as part of the toolchain.

So @mediapathic's#subs:PROJECTNAME suggestion is more akin to assigning arbitrary metadata as key--value pairs. You could, theoretically, represent the whole zettel for a machine using this notation.

#title:"My new Zettel" #id:201711181053
#readability #zettelkasten #software
#content:"Using tags only is not very readable. Welcome to structured markup languages!"

It should be apparent that this is is bad idea for human computer operators.

I do see the value of using simple structured tags instead of more elaborate metadata. After all, it's less of a commitment than introducing MultiMarkdown or YAML headers for metadata when all you need is attaching a simple flag.

I see no good reason to not support : in tags names. I'll relax the matcher's rules for The Archive accordingly. We do support uncommon exceptions like dashes and multiple hash characters, too, after all

I see your points, my thinking goes this way: Key-Value pair tags may be a beginner's mistake. Instead of tracking the status with #subs:out, #subs:waiting, etc, I bet it would be pretty clear to oneself to read just #out or #waiting and in order to differentiate from other notes, one could use #subs along with the former: #subs #waiting -- but that would require sophisticated search capabilities for tag combinations with exclusions, etc, to just find waiting submissions and not other notes tagged with waiting. That again, works against the element of surprise of a Zettelkasten. So what's wanted is distinct tags for #subs-waiting and just #waiting, along with a notion of hierarchy like in #subs-. In my eyes, using a colon here is OK. I don't see the need for being strict either.

Just #waiting would be weird; there could be a lot of notes on, say, The Mediative Practice of Waiting (just made that up) and you'd want to use the tag for notes with relevant content. So tags with prefixes of some kind can come in handy, be it an abbreviation (#subswaiting), characters (#§°!waiting), or a tag category (#subs:waiting).

@maclm said:
Just out of curiosity, what character, aside from space (and maybe , as it is often used as tags separator in other apps) SHOULDN’T be supported in tags ?

A lot of punctuation, depending on the context, including brackets and parentheses so you can type foo (#bar) baz; also the backtick ` for code, and in some cases Markdown syntax characters like asterisks and underscores -- although I think I am not supporting adding _emphasis around #tags_ in The Archive properly at the moment.