Hacker News Reader

Comment by kortex | Hacker News Reader

I think tag aliases are fine, but in my opinion, tags should not have hierarchies. That is just opening the can of ontology worms, and most systems are ill-equipped to deal with ontologies...including ontological systems.

Tags are just dumb strings which label data. They are basically KeyValues, where the value is just always equal to True. We don't think of KVs as hierarchical unless they are explicitly a path string, and in that case, they are forced to be a plain tree with no cycles or diamonds.

View on HN

Not having tag hierarchies doesn't fix the difficulty of classification, it just handwaves it away. There will always need to be (super)tags that are collections of other tags, where it is a bug for an item that has a particular tag to not also have another, related tag. The question should be how you're going to handle that, not if you're going to handle it, or you'll end up with a lot of broken tags of dubious usefulness.

Tags are just dumb strings that label data, but tags are also data. If I can't label tag:"red" a tag:"colored" in your system, it's not great. It's not much better if I'm labeling things tag:"colored-red" because if I'm doing that and there's no central validation to add semantics to that relationship, I'm going to end up with tag:"red" things, tag:"colored" things, tag:"colored-red" things, and probably even tag:"color-red" and tag:"red-color" things.

edit: what's so bad about cycles when it comes to a tag being assigned another tag that has been assigned the original tag? It's just a mutual implication. There's nothing wrong to me with adding a single tag and seeing five more added automatically. It means that you're building a knowledge base.

This is just search with synonym analyzer / partial match. If you make the tag search dynamic, you’ll find the tags you’re looking for quickly.

> It means that you're building a knowledge base.

That's precisely the problem. You started with tags and now you are building a knowledge base. You wanted a banana and now you have a gorilla holding a banana and the whole jungle. If you want to build a knowledge base, use links/URIs/ontologies.

You'll find out the moment you add cycles the algorithms get way more intense. And then once you have stronger algos, you want more search power. Next thing you know you are bikeshedding about things like "apple" is both "fruit" and "tech company" so you need tags-of-tags etc. Just build a knowledge base if you need a knowledge base. Otherwise tags are just a way to do faceted search.

They aren't mutually exclusive, either.

OpenTelemetry, for example, has both tags and references.

Nothing you say is necessarily the case, and is dependent on implementation. Take "value is just always equal to true", well, no, not if your key is a predicate. "Color:red" is more powerful than "#red" or "red:true", and "color:[lookup-ID-for-red-concept]" is substantially more powerful than both.

>"I think tag aliases are fine, but in my opinion, tags should not have hierarchies."

Many years ago I've developed a proprietary database for a media related product. It was a NoSQL Entity-Attribute-Value database where Attribute was basically a tag. Tags had no hierarchy but query language allowed to specify sequence of attributes like Genre, Artist, Album, Title. When said sequence was not empty the result set would be a tree where each level would correspond to an attribute position as defined in query.

Org mode approaches this by making hierarchies and inheritance optional. I personally like both, but I acknowledge (as was mentioned in the tweets) that hierarchies can get to be very convoluted if you don't work to maintain them sensibly.

What I like most about org mode tags is that regular expressions can be subtags (or "members of a group tag" in org mode lingo). So you can specify a hierarchy where the parents have children you don't know in advance.

Optional forests of hierarchy trees are where it's at. Essentially don't encode everything into one gigantic one.

Sometimes you know that users are going to tag `laptop` a bunch and want that to also drag in `personal computer` (but not all `PC`s are `laptop`s) or that `blue dress` is also a `dress` and don't want to hard code special cases.

That said, if you are going to do this, then you must have it controlled by an admin/moderator. Maybe allow for hierarchy request submissions but have it moderated. There is at least one public system where this just works to my knowledge and a bunch of self-hosted ones as well.

> They are basically KeyValues, where the value is just always equal to True

That would be a set of values :-)

Sure, but my point was there that it's really easy to use KVs as a backing store for tags, which you can implement anywhere and easily serialize. Sets, if you have to do something like transform it to JSON, you have a choice to make: dict:true, or list.

I understand your pain, but want to make you aware that LINQ has become so powerful especially with lazy evaluation and expression trees that hierarchical views of tags is really basically simple and actually just one more method of visualizing data...

Reply on news.ycombinator.com