When using hierarchical tags (which I think will always be the case) there are some inconsistencies in digikam handling these tags. Assuming we have the tag "People" with two subtags "Maria" and "George": +People + Maria + George After adding these subtags to a photo (right click photo -> Assign Tag -> Maria (My Tags/People) (and the same with George) I can find these tags in multiple places: 1. the "assign tag"/"remove tag" menu (after right clicking an image) shows the full path of a subtag 2. In the properties view under "digikam properties" I find: Tags: People / George, Maria suggesting that Maria is no more a subtag of People 3. in the database (sqlite in this case) only the child tags are stored (this can be fine) 4. in the XMP section of the metadata view the full hierarchy is saved in various keys of various namespaces e.g. "Xmp.digiKam.TagsList" 5. filtering for people in the left tag view returns all photos having either the people parent tag or *just* any of the subtags 6. filtering for people in the right tags filter view only returns images explicitly tagged with the parent tag people but *no* photos only tagged with the subtag. I am aware of the new feature to set the "auto toggle" for parents and/or children in the right tags filter and tags "edit" view. For the filter this is a really nice feature. For edit tags view I thing this option is superfluous. In my opinion a subtag implies that the parent tag is set as well (if maria is a subtag of people, than maria *is* a person) and should always be set either explicitly (as a separate tag in the various places) or implicitly (handled by the software) but always consistently. Reproducible: Always
> 1. the "assign tag"/"remove tag" menu (after right clicking an image) shows > the full path of a subtag Yes it does > 2. In the properties view under "digikam properties" I find: > Tags: People / George, Maria > suggesting that Maria is no more a subtag of People No, it shows: People / George Maria which is quite different. We could think about using "-" as the list character; we chose " " at the time to limit visual clutter. > 3. in the database (sqlite in this case) only the child tags are stored > (this can be fine) Yes it is > 4. in the XMP section of the metadata view the full hierarchy is saved in > various keys of various namespaces e.g. "Xmp.digiKam.TagsList" Yes it is > 5. filtering for people in the left tag view returns all photos having > either the people parent tag or *just* any of the subtags This depends on your including subalbums or not > 6. filtering for people in the right tags filter view only returns images > explicitly tagged with the parent tag people but *no* photos only tagged > with the subtag. Yes, it does. Same behavior as above. There's auto-toggling children here now, there's I believe indeed no include-subalbums. Precise filtering must be possible. If a parent tag is assigned or not is a matter of taste. Personally, I often assigned up to three tags in the hierarchy when describing places; others may only assign the very child tag. In the contexts of people, I assign only the very child tag (the person) and never any parent tag (the group). Much more contexts can be imagined, we cannot impose interpretations.
My problem with this is that the hierarchical tag system in Digikam simply doesn't work as I would expect. I'm not saying it's wrong, just unexpected. From the term "hierarchical", I would expect that selecting a child tag always selects all parents. Maria is always people. Norway is always Europe. Butterflies are animals. Suppose I have the following structure for a given image: [ ] Cities --- [ ] Amsterdam --- [ ] Hamburg --- [x] Trier [x] Routes --- [x] Long --- [ ] Short In Album View, this is then shown under the image: "Routes, Long, Trier". If I enable "Short", it becomes "Routes, Long, Short, Trier". I don't see how that system is convenient. Also, the order in which I enable tags matter, so that related tags can end up not being next to each other in this comma-separated list. The tool tip for the first case shows: Routes Routes/Long Cities/Trier Here's what I would expect: 1) That Cities was mandatory. 2) That Album View and tool tip showed something like "Cities/Trier, Routes/Long, Routes/Short". The fact that parents aren't mandatory is, imho, your imposed interpretation of how a hierarchy should work. It would probably be good to separate the issues: 1) Should parents be mandatory? How should a tree structure of tags work? 2) How should tags be shown? Full list, compact list, single tag nodes or concatenated? Thanks!