[Bug 303690] New: hierarchical tags inconsistencies

[Patrick Scharrenberg]

https://bugs.kde.org/show_bug.cgi?id=303690

            Bug ID: 303690
          Severity: normal
           Version: 2.7.0
          Priority: NOR
          Assignee: [hidden email]
           Summary: hierarchical tags inconsistencies
    Classification: Unclassified
                OS: Linux
          Reporter: [hidden email]
          Hardware: Other
            Status: UNCONFIRMED
         Component: Tags
           Product: digikam

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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=303690

Marcel Wiesweg <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #1 from Marcel Wiesweg <[hidden email]> ---

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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=303690

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
   Version Fixed In|                            |3.0.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Niels]

https://bugs.kde.org/show_bug.cgi?id=303690

Niels <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #2 from Niels <[hidden email]> ---
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!

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel