Techniques for tag heirarchies?

mediapathic · November 2017

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.

Does anyone have any ideas for better ways of doing this?

toolboxen · November 2017

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:

#subs-out
#subs.waiting
#subs;edits

Could also try pipes or slashes?:

#subs/out
#subs|waiting
#subs\edits

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?

mediapathic · November 2017

My findings so far (This applies to both The Archive and the current iteration of sublime_zk):

## Will link

    #tag-subtag
    #tag_subtag_subtag3

## Will not link
    #tag|subtag
    #tag/subtag
    #tag;subtag
    #tag.subtag
    #tag:subtag

rene · November 2017

@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).

What do you guys think?

toolboxen · November 2017

either removing colons from the list of stop characters -> supporting colons in tags

I vote for single colon. I suppose single colon only followed by [a-zA-Z0-9] or something?

rene · November 2017

@toolboxen said:

either removing colons from the list of stop characters -> supporting colons in tags

I vote for single colon. I suppose single colon only followed by [a-zA-Z0-9] or something?

I can try. There's the syntax highlighting RE, the tag cut-off, ... should be doable.

rene · November 2017

@toolboxen said:
I vote for single colon. I suppose single colon only followed by [a-zA-Z0-9] or something?

done

@mediapathic if you can live with subs:out that is supported in the plugin now.

Sascha · November 2017

When I used hierarchies in my tags I didn't use anything. Just the next word with a capital letter.

rene · November 2017

@Sascha said:
When I used hierarchies in my tags I didn't use anything. Just the next word with a capital letter.

#camelCaseTagsToTheRescue Brilliant! Why invent a space-pen when you can write in space with a pencil?

ctietze · November 2017

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:

webdesign:color
webdesign:footer
webdesign:headline
webdesign:homepage
webdesign:icon
webdesign:interface
webdesign:layout
webdesign:layout:grid
webdesign:modern
webdesign:simple
webdesign:typography
webdesign:usability

... 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

rene · November 2017

@ctietze wrote
[...]

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.

ctietze · November 2017

I think we do not disagree here at all.

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 · November 2017

@ctietze said:
I see no good reason to not support : in tags names.

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 ?

rene · November 2017

@maclm said:

@ctietze said:
I see no good reason to not support : in tags names.

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 ?

I stop at:

.,/!$%^&\*;{}[]'"=`~()<>\

and a colon when it's the last character in a tag as in the fictional example:

interesting #methods: method_a, method_b, method_c

ctietze · November 2017

@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.

maclm · November 2017

Oh, I see.
I'm so used to place tags in MMD metadata fields, it didn't occur to me those inline scenarios would be problematic.

mediapathic · August 2023

I'm resurrecting this long-ago thread to complain once again

A synopsis for those who don't want to read things from 2017: I asked for support for : as a demarcation for tag hierarchies (my example is from a submissions management system I was using: #subs:ready, #subs:out, etc). Christian and Rene (who was at the time working on sublimeless_zk) both agreed to support them.

What I'm wondering now is: is it time to revisit this notion to possibly include / as a delimiter? That is the syntax used by Obsidian, which has become the 500 lb gorilla of markdown editing. To bring it to a more personal level, since I spent a lot of time in Obsidian, I have a lot of tags of the form #tag/subtag that, in The Archive, only search as #tag. This being The Archive, of course, I can just manually type the rest of the string I'm looking for, so, for me personally this is mostly a matter of convenience. But, it would be nice if I could have the same tags work in both systems (I still have to use Obsidian for some things, due to lack of subdirectory support with The Archive).

@ctietze , Is this worth whatever effort it would take?

ctietze · August 2023

@mediapathic I don't recall a reason to exclude / in particular. I tweaked the tagging regular expression over the years to be more forgiving without matching obvious punctuation, e.g. parentheses (as in this #inline-tag). We can check this out -- noted!

brborghi · August 2023

The syntax #tag/subtag would be useful indeed.

Zettelkasten Forum

Techniques for tag heirarchies?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion