Page 2 of 2 FirstFirst 12
Results 21 to 37 of 37

Thread: Hierarchical tagging

  1. #21

    Default

    Quote Originally Posted by p694v7x View Post
    I definitely have more photos in iPhoto (7500) than PDFs in EagleFiler (500, down from 2000). And the shareware iPhoto Keyword Manager makes iPhoto tagging much more useful. In fact, I didn't bother tagging photos until Keyword Manager.

    EF's "nested tagging" seems to be quite superficial only, compared to Keyword Manager. Which is cool if that's what the author is going for. But IMHO is not much different from un-nested tags.
    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.

  2. #22

    Default

    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:
    Personal
    -Pets
    --Dogs
    ---Spot
    Nature
    -Animals
    --Dogs

    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

    Personal->Pet->Dogs
    Nature->Animals->Dogs

    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 :) )
    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)
    bob

  3. #23

    Default

    http://culturedcode.com/things/
    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.

    http://mekentosj.com/papers/
    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.

    Charles

  4. #24

    Default

    Quote Originally Posted by cfournier View Post
    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.

  5. #25

    Default unique tags

    Hello,

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

    Toby

  6. #26

    Default

    Quote Originally Posted by t.oby View Post
    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?
    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.

  7. #27

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

    Regards,
    Toby

  8. #28

    Default

    Quote Originally Posted by t.oby View Post
    thinking and thinking over the pros and cons of both approaches I would vote for real hierarchy and would like to explain why.
    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.

  9. #29

    Default

    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.

    Toby

    * sorry for the term real hierarchy - it's pretty fuzzy

  10. #30

    Default

    Quote Originally Posted by t.oby View Post
    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.
    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?

  11. #31

    Default

    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:

    A
    -D
    -E
    B
    -D
    -G

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

  12. #32

    Default

    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?

  13. #33

    Default

    Quote Originally Posted by humanengr View Post
    While keeping the present logic, would it make sense to allow the user to toggle the display to show a flat alphabetical list?
    Could you say a bit about how this would be useful to you?

  14. #34

    Default

    Quote Originally Posted by Michael Tsai View Post
    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).

  15. #35

    Default

    Quote Originally Posted by humanengr View Post
    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.
    How about if there were another column in the Tags window that showed the ancestor tags?

    Quote Originally Posted by humanengr View Post
    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).
    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?

  16. #36

    Default

    Quote Originally Posted by Michael Tsai View Post
    How about if there were another column in the Tags window that showed the ancestor tags?
    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. :-))

    Quote Originally Posted by Michael Tsai View Post
    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?
    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.

  17. #37

    Default

    Quote Originally Posted by crux View Post
    In the meantime, though, you can always just select the whole group at once.
    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.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •