This website uses tags to sort its items (i.e. blog posts and garden nodes). Tags are a form of search, and as far as I'm concerned the blog and the garden should both be first-class citizens when it comes to search.

This node goes through my general approach to tags on this site, how we apply them, how we consider heirarchy, and how it all works.

General implementation

[11ty][] uses tags for its own internal machinations, so we actually encode tags as the categories variable inside an item's metadata. An item doesn't have to have categories, but if it does, they must be an array.

Tags can be (but don't need to be) heirarchical - a tag can be a child of another tag can be a child of another tag, etc. For example, I have a bunch of tags under rpg, including Fall of Magic and Society of Dreamers. These are tracked via a very simple json file.

Tagged pages can be navigated through a series of semi-automated pages on the garden. Most notably:

• Each tag has a garden node. At the very least, this node will list all the tagged items for the tag. If a garden node already exists for the tag, it will append the list to the bottom of the text.
  • This lets us have descriptive nodes which describe various tags, or nodes which function both as pages within the structure of the garden which also help organise and link content automatically.
• If a given item has a tag which is part of our heirarchy, the item is implicitly tagged with each parent. Implicit tags are not listed as part of a given item's tags, but the item is listed in tag-lists for the implicit tag.

Tag vs non-tag pages on the garden

This does mean there's a chance for collision where I want to write a garden node for the subject foo, but there's also a tag foo in existence. I don't expec this to be much of a problem, but if so I'll resort to Wikipedia-style disambiguation syntax (using "(context)" in the node title).