Meaning of parent/ child category relation?

[nji9]

In other words:
When shall I make a category make the child of some other?

Up to now my thinking was that a child category is a refinement/ specialisation
of the parent category.

Example:
Category Paris has to be child of category France.
An image can be categorized/ labelled by France.
A subset of the images labelled France may be labelled Paris.
And every image labelled Paris will obviously have to be labelled with France.
Simple and clean.

But recently I noticed that the parent labelling is optional:
Settings / MetaData / Categories and keywords (!!!) / "Automatical assign parent category".

So my understanding of XnViewMP's concept of parent/ child category relation
must be wrong. The option to turn off "Automatic..." contradicts it.

What meaning has parent/ child category in general,
if it is possible for an image to be labelled with a category,
but not with its parent category?

[michel038]

Your understanding is right.
Categories should be exported as embedded (hierarchical) keywords in photos.
However, some users may organize categories with subcategories, for example:
Animal, A, Ape
Animal, Z, Zebra

In such cases, they may not want the intermediate levels (e.g. Animal, A, Z) to be written as keywords.

In other software, the term "category" is used to define these structural levels (A, Z) and to prevent them from being exported as keywords.

[nji9]

Your understanding is right. ...

But "my understanding" is contradictory!

(That's what I tried to explain, and that's why I ask).

Let's keep it as simple as possible:

I'm not at all about import/ export to metadata.

My question is just about the concept of so-called categories in XnViewMP.
(For me the word "label" fits better however )

So, just to prevent misunderstanding:

If Animal is parent category of category A,
and A is parent category of Ape...

... this means every Ape is an A, and every A is an Animal, right?

But if this is correct, then it shouldn't be possible to
disable the mentioned "Automatical assign..." setting (???).

As an image labelled as Ape, but not as Animal would be wrong.

So either it must not be possible to disable "Automatic assing..."
or
the concept of parent/ child relation is different from refinement/ subset.

???

[jkm]

But "my understanding" is contradictory!

Then your understanding is wrong, because you are thinking too rigidly.

You are treating categories like a directory structure, where the parent/child relationship is inseparable and is absolutely required, at all times, to locate a node.

But categories are not a directory structure. They are labels, used for the convenience of humans. The parent/child relationship is also merely a convenience for humans to help them organize large numbers of these labels, called categories.

Because they are merely labels, it is a human prerogative to use as many or as few as is pleasing in a certain situation.

You must accept that fundamental fact. It is a matter of preference. One way is not right and another wrong.

The example michel038 gave you was an excellent one. Spend more time thinking about it in light of what I’ve said above.

Here’s why it was a good example….

Depending on how a person chooses to organize their many categories, they might want parent categories always assigned, OR THEY MIGHT NOT. That is why the option exists.

If the structure is Animal/Mammal/Ape then it would indeed be appropriate, in my opinion, to automatically assign all parent categories: because an Ape IS a mammal and it IS an animal.

But if a person, for reasons of their own personal preference prefers a structure of Animal/A/Ape then, in my opinion, it would be undesirable to automatically assign parent categories, because an Ape is NOT an “A” and having “A” as a label on the image would be unsightly.

You said every Ape is an “A”. But some people, like me, think that’s nonsense. There is no such thing as an “A” biologically; it’s just a letter, and has zero taxonomic value. You think that every image labeled with Ape MUST also be labeled with Animal. But here’s the thing: on MY images, not if I don’t want it to be! Must every image labeled with David also be labeled with Human? Not on my images.

Whether or not you agree with these examples is irrelevant. It’s a matter of personal opinion.

The option exists to cater to people who have different opinions as to what constitutes good organizational structure, and what are appropriate labels to assign.

Other people may think differently from you. Surprise! That is why the option exists.

Hopefully that clears things up.

[nji9]

I absolute agree that people shall have different opinions.

Even if it's about facts there are different opinions.

But if there is a fact (let's just for an example take 1+1=2),
than if someone is of different opinion, then his opinion is wrong.

I admit we agree about that.

So if your personal opinion (I do well understand) should be true,
then category-hierarchy in XnViewMP IS NOT meant as subset semantic,
but a kind of "has-something-to-do" semantic.
A support for grouping/ structuring.
User can freely decide how to use it.
As mentioned, as far that is only your opinion.
And the existence of the option to disable "Automatic assign..."
seems to support in XnViewMP it is meant that way.
To say it again explicitely:

Hierarchical parent/child in XnViewMP is not meant (solely) for refinement/ specializing/ subsetting,
but as a general grouping.

(Any confirmation/ contradiction by anyone?)

So it's about the same as the "Category Sets" panel.
Assistence on handling, structuring (many) categories.
The difference between "Category Sets" and parent categories:
"Category Sets" are not categories themselves.

Actually I do use "parent categories" and "Category Sets" for different concepts:
"Parent category" is for refining/ specializing/ subsetting.
While "Category Sets" is for "belongs to a topic" (Example: Category Set named "Location")
Both concepts are important and different, and they are independent.
A program offering any kind of labeling/ tagging/ categorizing
should support both of them.

However...
I don't think it's a good idea to allow a program's use,
so that the same concept (the "belong-to-topic" meaning) is used by different program functions.
This leads to unstructured, inconsistent and incompatible use.

Better (suggestions):

Parent/child hierarchy for specializing only (i.e. no option to unable "Automatic assign...").

For grouping ("belong-to-topic" meaning) there are the Category Sets only.
"Category Sets" should be (optional) shown "parent-like" in "Category Filter" and "Search" panes.
viewtopic.php?t=49278

[jkm]

Hierarchical parent/child in XnViewMP is not meant (solely) for refinement/ specializing/ subsetting,
but as a general grouping.

(Any confirmation/ contradiction by anyone?)

You are close, but not exactly correct. A more accurate statement would be

Hierarchical parent/child relationships in XnViewMP Categories are not exclusively meant for indicating specialization. They can be used for indicating specialization, as in a taxonomic tree, or as general grouping in a collapsed list, as in a dictionary.

The word "meant" is important here. It means intended, as in intended by the author of the software. Because the above statement is not an opinion, it is a fact. The opinion of the author of the software, that it is acceptable to use categories either way, has been made fact by the act of creation of the software. In XnViewMP, flexibility is preferred.

This is important not only from a standpoint of user choice, which Pierre thinks is important, but also because of compatibility. Not all software supports hierarchical categories/subjects/labels. XnViewMP is designed to be able to do both.

As an aside, for people who are not native English speakers, the way you phrased it and the why I phrased it may seem the same. But a native speaker would see a difference, that your construction implies that "general grouping" is the norm, and "specialization" is merely allowed. My construction implies that both are equally acceptable.

However...
I don't think it's a good idea to allow a program's use,
so that the same concept (the "belong-to-topic" meaning) is used by different program functions.
This leads to unstructured, inconsistent and incompatible use.

Better (suggestions):

Parent/child hierarchy for specializing only (i.e. no option to unable "Automatic assign...").

No.

Because now, although tacitly acknowledging that people can (as in, should be allowed to) have different opinions, you seek to impose your opinion on everyone.

The flaw in your thinking, and it is a flaw, is that you believe that the parent/child hierarchy of categories is, or should be, exclusively for specialization. You believe that it OUGHT NOT be used for simple organization, and merely easing the finding of labels.

Perhaps you believe that what you see on the screen, the tree-like structure with disclosure triangles and hierarchy is an actual literal delineation of structured data. But it's not. It's just a graphical display. That's a fact, not opinion. You can make the data relationships match the display (hierarchical subjects, automatically assigned), or you can not do that. The graphical display does not mandate one and not the other, as you seem to think it does, or should.

You talk about "unstructured, inconsistent and incompatible use" as if it is a problem. That use, ACROSS DIFFERENT USERS, should not be unstructured, or inconsistent, or incompatible. And imply that that is an obvious fact that it's a problem. But it actually is merely your philosophy.

And so your view is that this use of the application should be banned and made impossible. You're trying to force everyone to work and think the same. That's Apple's kind of flawed thinking: that restricting user choice, because it makes things simpler and more consistent, is better. But it's only better for the people who create the product, not the people who use it. Or at least not most of them.

You assert that other some peoples' opinions, that it's ok to use it for simple organization in order to have less cluttered screens and shorter lists (Animal/A/Ape) when finding labels, are WRONG or IMPROPER, because they don't honor specialization, and that they should not be allowed.

And at the same time, you start to recognize that in fact Pierre, by including the feature, wanted to allow people of different opinions to be able to comfortably use the software, and that he wanted the software to adapt to the user, instead of forcing the user to adapt to a single methodology imposed by the software. Fortunately for everyone else, his opinion prevails.

You are advocating for the position that everyone must use the feature the way you think it should be used, and no other.

The solution for that sort of thinking, is for you to go and write your own software; then users will have to use it the way you want them to.

In closing, I will explain one further thing, which will perhaps shed some light on why the approach you're advocating is not used:

When XnViewMP is changed/updated/improved, and new functionality is added, there is thinking that goes into that process. The thinking goes like this: "Here's a capability that is desired to be added. How should it work? How COULD it work? Does it have to work a particular way, in order to function properly, or can it work multiple ways to accommodate different needs? Does it have to be mandatory to function properly, or can it be optional? Is it so important for the service of some other goal that it has to be mandatory anyway? What complications does flexibility, or the lack of flexibility, add?"

All these things are taken into account, and flexibility is preferred. Sometimes, full flexibility is not always achieved, because it simply might be too much work, but it is considered. Issues of complexity, from the standpoints of UI, program flow, and user understanding, are also considered.

The fact that flexibility is preferred goes to the very core of the software. Large portions of the Interface can be removed or rearranged by the user. Critical and powerful functionality, like the catalog (database) and comprehensive metadata support, can be enabled or disabled by the user. XnViewMP can be a powerful cataloging tool, or a dumb image viewer, based on user choice. You might have noticed, the app has a lot of options.

That is the way it's done. Flexibility is preferred, and user choice is prioritized.

[nji9]

In your argumentation you overlook that there might be important reasons
to restrict special user actions.
E.g. when entering values, or doing contradictory settings etc.

I named that reasons for this thread's topic in my post above:
"unstructured, inconsistent and incompatible" catalog data.

Allowing to realize the same concept (grouping) by different means (parent categories
and category sets) within the same category system will lead to... well see above.
That's why I strongly discourage to allow that (by deselection "Automatic assign...").

My aim is not to restrict other user to use XnViewMP in a way I think it's best,
but to assist in building well structured catalogs, to prevent serious drawbacks.

"Full flexibility"?
Yes, but not by ignoring any arguments.

[nji9]

Additional argument:

Moreover there is no reason to provide a mean for "free" grouping categories
that generates inconsistencies (by category parents/childs),
as there already exist a perfectly adequate mean for that (by category sets).

The only thing missing (but easy to implement) is (optionally) showing
category sets in panes "Category Filters" (parent-like) and in search.
viewtopic.php?t=50128

Filed a suggestion for that
viewtopic.php?t=50237

[user0]

settings are the same as in Bridge, the only diff:
- Bridge does not allow to select 2 options together ('Automatically apply parent Keywords' and 'Write hierarchical Keywords')
- there is bug

there is no issue with 'Automatically assign parent Keywords'

but, it is pointless to discuss this topic without understanding:

• tags
  there is no universally accepted or officially enforced metadata standard for hierarchical keywords.
  Hierarchy exists only through vendor-specific conventions layered on top of XMP
  
  • IPTC:Keywords and XMP:dc:subject
    are unordered list/bag of strings, flat by design and have no defined hierarchy semantics.
    Its up to app how to write/read strings with separator
  • XMP:lr:hierarchicalSubject
    Adobe's proprietary tag in Lightroom namespace, which is widely adopted de facto

• data write settings
  metadata_hierarchical_keywords_write_modes.png
  • Automatically assign parent Keywords
    only exists to simplify user workflow by auto-selecting parent in UI, it does not change how metadata is serialized
  • Write hierarchical Keywords
    controls serialization strategy for IPTC:keywords and XMP:dc:subject tags
    XMP:lr:hierarchicalSubject is not affected and always stores hierarchy

ps: 'Category(Keyword) Set' is a purely UI/workflow convenience in app and only stores in app db.

[nji9]

Thank you for providing your thoughts and the information.

However I've to repeat what I tried to make clear in my post above

...
Let's keep it as simple as possible:

I'm not at all about import/ export to metadata.

It is just to have the category system coherent within itself.
(I think it's a bad idea to design that to be in line to some metadata format.)

'Category(Keyword) Set' is a purely UI/workflow convenience in app and only stores in app db.

"Only in app db"?

To my understanding the db is the master (of everything).
Not the metadata.

Especially the inheritance hierarchy is of semantic information.

The grouping (by category/label sets) also is more than just for UI.

If you want to understand what I'm about:
Just forget anything about metadata for a moment.
Think on a system for labeling and categorizing data.
The label net will be a kind of semantic net (quite useful).

How to match that to the metadata is a secondary question,
and should not determine XnViewMP's labeling system.

That way everything will be simple and clear.
viewtopic.php?t=50238

[michel038]

Sometimes I need to change a single keyword in my photos. Categories is the best tool for doing this (editing metadata is tricky for this use case, and updating the database directly as well). So I uncheck the option, set my category, then check the option again.

This option should simply be enabled by default, if it is confusing for users.

There are many other options in XnViewMP that may confuse users.

Info
If you use only the database (no metadata), remember to make regular backups of xnview.db.

When new versions of XnViewMP introduce major changes in database management, I am not sure that databases from previous versions can be imported safely.