C-Command Software Forum

Hierarchical tagging

I don’t really like the Keyword Manager approach, for two reasons:

  1. Auto-assigning the parent tags clutters the display.
  2. Re-arranging the hierarchy can cause confusion.

There’s some discussion of this above. I prefer the Aperture approach, where you can use hierarchy for organization (supported by EagleFiler) and also leverage it for search (not currently supported by EagleFiler) without actually applying all the ancestor tags.

just wanted to chime in some thoughts i had:

What if hierarchy tags were used only to simplify the tagging process ? As someone else mentioned, giving an item the child tag would also give it tags of all parents, aka Aperture way. WIth this in mind, why not also allow same tag to be reused in different places for example:

When user types ‘dogs’, EagleFiler notices that there are 2 or more paths to this tag so does something. This is where i’m not sure how it should work. Originally I was going to say have EagleFiler pop up a menu with all paths like


Let user choose which one, but that doesn’t work well sometimes for example, I want to select the Pet path, however I also want Animals to to be included too. Perhaps a popup mini-window with checklist of all associated tags in 3 or 6 columns.

However tags are deal with, I think the proper way to organize items are to use smart folder with swiss-army searching instead of with tags themselves like in Eagle 1.x for example:
My Pets: <smartfolder: Keywords:Pets & Personal>
Friends Pets: <smartfolder: Keywords:Pets & !Personal>
Friends: <smartfolder: Keywords:Friends & Pets> (hey pets are friends too :slight_smile: )
Animals: <smartfolder: Keywords:Animals>
-Domestic: <smartfolder: Keywords:Pets> (limits search within above folder)
-Wild: <smartfolder: Keywords:!Pets>
Vacations: <folder>
-2006: <smartfolder: Keywords:Vacation Date-Year:2006> (searches entire records)

just my 2.7 cents (.7 to help foot the bailout bill)

Nested tags are beautifully implemented in Things. Yet, this is not necessary. In order to make the tag paradigm useful when your collections grow more complex, you just need a one-level tree structure. Containers do not have to be tags themselves. The container “context” can include the tags, @home, @computer, … Yet you do not need a tag “context.” Nexted tags may be grow counter-productive.

Another useful paradigm is “collection.” Items placed in groups are located in the group. Items placed in collection are still located in the root library. Collection is just a way to group items, not relocate them.

One great advantage: once no more useful, you delete the collection; the content is still on the root library. No accidental deletion of records while reorganizing groups.


I call this the “playlist” model, since iTunes was one of the first applications to support it. EagleFiler’s tags were specifically designed to work in this way. You can use them like tags or playlists, or both depending on the occasion.

unique tags

in my previously wrong opened post I voted for a real tag hierarchy. Then I saw the scenarios here and changed my mind. Still issue remains. All tag names have to be unique. So if I have a sub tag “Pictures” of “france” I can not have this as any other sub tag (e.g. Berlin->Pictures etc.) - right? Then the only way out would be to have real long and confusing tag names like “germany_berlin_pictures”.


Yes, tag names must be unique. That’s a key aspect of what a tag is.

Don’t forget that you can assign multiple tags to each file. So one file can have {Berlin, Pictures} and another can have {France, Pictures}. Then to see all the pictures of France you would search for the intersection of those two tags.

tag hierarchy
Hi Michael,

thinking and thinking over the pros and cons of both approaches I would vote for real hierarchy and would like to explain why.

There is certainly the use-case of having a set of tags “visually” hierarchical structured and having documents below each tag and not having them also on parent tags. If having a couple of tags this can be a fast way of organizing things and still keep the overview.

  • With a larger set of tags it gets more and more difficult to keep the overview and remember to which subtag in the node a certain type of document was assigned. In case of doubt one has to manually click through all tags. At least the tags of a super node where the documents are to be expected (e.g. pictures).

  • When having the possibility to organize items hierarchically this implies (for me at least) also thinking in hierarchic ways. Let’s take the metapher of an apartment where I stock my stuff. Then my picture is like a spatial hierarchy of boxes: Apartment -> Room -> Wardrobe… When I know I stored something in the living room it would be nice to have a list of all things in the living room rather than searching all elements in the whole apartment like box in kitchen, wardrobe in living room, shelf in guest room, etc. Since this is the natural way how we organize things I also think a tagging hierarchy tends to rather have this structure than a set of unique tags hierarchically visualized but not implying a real hierarchical structure.

  • A tag hierarchy not holding a hierarchical structure is just a flat hierarchy like a list of tags (e.g. unique property). Beeing able to have them visually structured hierarchical is certainly a nice feature but the tagging systems stays in it’s nature.

I know there are technical issues implementing this but I do believe this will boost the value of EagleFiler by magnitude. The main reason I took notice from EagleFiler was difference in the tagging system to the competing approaches.


First, I think the term “real hierarchy” is vague and should not be used.

Second, I don’t think anyone is saying that the status quo is the way things should remain. Rather, the two approaches under consideration are distinct ways of using the hierarchy:

  1. Assigning a child tag to a record also assigns all the ancestor tags.
  2. Viewing or searching an ancestor tag (optionally) views/searches records with the child tags.

In other words, does the hierarchy take affect early or late? I tend to think that (2) is more useful because it better handles changes to the hierarchy and remembers which tags you assigned.

Hi Michael,

with my post I wanted to express my arguments for approach one (1). I know there arguments for both approaches and neither of them can be judged as better or worse. It totally depends on the user how he is doing the tagging. I am a user who would like to do a conceptual tagging (1) * rather than having a folder-like view (2) on my files.


  • sorry for the term real hierarchy - it’s pretty fuzzy

I think either you don’t understand (2) or I don’t understand your explanations, because to me they merely support the use of a hierarchy, not (1) or (2). Have you used Aperture?

From a purely academic point-of-view, tagging is not hierarchical in the sense presented in this discussion, and the way it is implemented by most apps. Tagging is based on mathematical sets, here’s an example:

Set A contains
Set D
Set E
Set B contains
Set D
Set G

If the sets represent collections of objects having the set’s name (a tag) you could define a hierarchy as follows:


… but the ideal hierarchy is not flat (single parent), instead tagging should be a directed graph in which a node may have multiple parents.

The problem above is D appears in two different locations, which is problematic when using D to tag a file and wanting to include parents (will it be A or B or both?). If D = “France” and A=“Country”, B=“UN Member”, then it would be reasonable to include A, B, D as tags for an item. But in other tagging designs, multiple parents may not be desirable. What Michael has to struggle with is how to implement a tagging system that does not get too complex to implement and to display in a GUI.

While keeping the present logic, would it make sense to allow the user to toggle the display to show a flat alphabetical list? If so, could the path to each tag be parenthetically indicated to the right of the tag? If this would crowd the tag list in the pane, could this be done in the Show Tags window?

Could you say a bit about how this would be useful to you?

Sometimes I find myself trying to remember a tag (was it “bash” or was it “scripting” or ?) that clairvoyance doesn’t suggest and I can’t quickly find in a hierarchical list. But I also want to quickly get an idea of the hierarchy to refresh my recollection of the library’s foci.

So, when I scan my tag list, I find myself wanting to quickly see all the tags as well as get some idea of the hierarchical organization. To my mind, the first goal is satisfied most efficiently with a flat, alphabetical list (like Show Tags) because the eye doesn’t have to traverse longitudinally to follow the outline structure and the mind doesn’t get distracted by expansion of portions of the outline not particularly germane to the current scan.

A middle ground would be to expand the entire hierarchy with, say, a single <cmd><opt>-click on one triangle (reserving an <opt>-click for a local hierarchy).

How about if there were another column in the Tags window that showed the ancestor tags?

Are you saying that instead of Option-clicking the root you want to be able to Command-Option-click some other triangle and get the same result?

My initial inclination was for ancestor tags in small font in parentheses, but that is probably a poorer aesthetic than your proposal. (Also, the toggle should have a shortcut. :-))

Yes – command-option-click on any triangle (not just the “TAGS” root triangle) to expand all triangles for all tags; option-click on any triangle to expand only its children’s triangles.

But how do I query the hierarchy in a smart folder? There is no “has a tag whose parent is x”.

Specifically I have tags like “sentDec2011” and would like a list of records that aren’t assigned any of those.

BTW this could also be done by adding pattern matching for tag names.