add page about tagging
This commit is contained in:
parent
4f9ba31228
commit
e6c076a8f4
38
content/wrong/tagging-too-basic.md
Normal file
38
content/wrong/tagging-too-basic.md
Normal file
|
@ -0,0 +1,38 @@
|
||||||
|
it's often stated that hierarchical categories are too limited and that a tagging system is better. putting aside arguments about what a "category" represents taxonomically and how it differs from a "tag" (e.g. "grouping vs describing", "general vs specific", etc), there ought to be more flexibility in tags and tagging in order to make it a worthwhile mental model shift vs. categories.
|
||||||
|
|
||||||
|
i generally agree that a strict hierarchy is not the best, even if it is sometimes (often?) good (enough?). the classic issue is with e.g. folders in a filesystem, a folder can have only one parent. sure you can set up symlinks but the one-parent rule is an issue that needs to be worked around.
|
||||||
|
|
||||||
|
the shift from categories to tags "solves" this "one-parent rule" issue. (but again, you could just as easily say that an item can belong to multiple categories; etc etc. we leave this argument out because it is too similar to the taxonomic argument above)
|
||||||
|
|
||||||
|
now we have to come up with improvements to the tagging system. below are some mechanisms
|
||||||
|
|
||||||
|
## hierarchical tags
|
||||||
|
|
||||||
|
> x.y.z implies x.y and also implies x. it might also imply y (unclear)
|
||||||
|
|
||||||
|
cons: it replicates the one-parent rule and its issues, and it's unclear how inheritance works. also what do you use as the separator between hierarchy layers? a dot? a slash?
|
||||||
|
|
||||||
|
prior art:
|
||||||
|
|
||||||
|
- also called "nested tags" by obsidian
|
||||||
|
|
||||||
|
## taggable tags
|
||||||
|
|
||||||
|
just like modern OOP principles tell you to favor composition over inheritance, we favor taggable tags over hierarchical tags.
|
||||||
|
|
||||||
|
> z is tagged with x and y; therefore, anything tagged with z implies x and implies y
|
||||||
|
|
||||||
|
example: tagging a character from a series implies tagging the series. #gaimon_(one_piece) is your classic booru style binary tag that is too basic. what you *want* is to imply that #one_piece tag without actually having to tag it yourself. but you also want to imply many other tags: #green_hair, #treasure_chest, #afro, and so on. you don't want to add these tags yourself every single time.
|
||||||
|
|
||||||
|
prior art:
|
||||||
|
|
||||||
|
- hydrus network calls this "tag parents". it works off of semantic subsets and supersets.
|
||||||
|
|
||||||
|
## tag aliases
|
||||||
|
|
||||||
|
> z implies zee (and vice versa); z implies zed (and vice versa)
|
||||||
|
|
||||||
|
prior art:
|
||||||
|
- also called "tag siblings" by hydrus network. allows you to set up equivalence between semantic concepts.
|
||||||
|
|
||||||
|
you can chain these together transitively or keep them flat, but it is generally a good idea to mark one of the ends as "canonical" implying it overrides the other. say you want to have a common misspelling be overridden by the correct spelling
|
Loading…
Reference in a new issue