Parent keywords and parent label assignment: pros and cons

[vlad]

Charles,

Thanks for sharing your findings and thoughts, you made some very good points.

t
I agree that only the assigned catalog label (the lowest in the hierarchy) is written to the image. However, I question whether this has changed. I have gone back to a clean (empty) installation of PSU v2, and in build v2.0.0.1016 (the one I was recently using until recently) the behaviour was exactly the same. I have also checked in v1 (1.8.1.129), and the behaviour there too appears to be the same, although the metadata switch which in v2 & v3 is “Create keyword for this label” in v1 was the reverse: “Do not create keyword for this label”.

What do you mean when you say that "it was in reverse"? Are you talking about one or more specific labels in your catalog? Anyway, I hope we all agree, at least, that the processing of parent mappings should never write keywords for labels set up to not create keywords.

Whatever the situation, I would agree that if I have selected “Process Parent Mapping” in the Metadata settings for a catalog label, then I would expect the parent to be written to the image.

I would agree that a label has an implicit keyword mapping, but I don't necessarily share your expectation. (That's why I would suggest the following rewording: "Process All Custom Parent Mappings").

Think about this: the labels in the Places category are set up (by default) with location mappings + the processing of parent mappings enabled. Are you and Tom suggesting that the keywords for the upper Country and City levels should always be written if I assign a location label under the City level? (If you want the upper keywords written, why don't you assign - manually or automatically - the upper labels, or, alternatively, check "include all parent levels as keywords" in the global preferences?)

[One change I have noticed between v2.0.0.1016 and v3.0.2.2060 is that if you have chosen “Also assign its parent” for a label, then if you remove that label PSU now removes the parent also, which it didn’t previously – it’s now more consistent.

Thank you very much for noting this - I do agree it's a very good change (although I don't personally have any labels set up like this). I will edit my original statement about automatic parent assignment being fragile with respect to label revocation - I will leave only the reference to structural catalog changes (label relocations + merges).

(Note: a user could still inadvertently lose the parent labels if he unassigns a label set up with "Also assign its parents" and then assigns a sibling label without that setting - but this simply suggests we should set up our labels properly/consistently. Sensible design makes a big difference, but it almost never is a complete substitute for good practices.)

This is not mentioned in the “What’s new” document for v3, but maybe it was introduced in one of the later v2 releases which I haven’t used].

Nope, I've tried it in build 2.2.5.1045 (the last for v2, I think) and it does *not* work that way. I have no idea if the change came up with the initial release of v3 or in a later build.

Question: what is the best tool for reading the metadata written to jpg image files. I have been using EXIFTool, but it isn’t exactly friendly.

Have you also tried the graphical version (ExifToolGUI)?

For image management (DAM) I am only interested in using PSU, and as long as it works I clearly do not need to use the “Also assign its parent” facility. Using that facility, then if hierarchies are written to image files considerable redundancy is the result – e.g. in addition to Places|Europe|France|Paris|Eiffel Tower, you’ll also end up with Places|Europe|France|Paris and Places|Europe|France and Places|Europe on the image file. Given these two points, and the fact that hierarchies can be written to images by other means, I don’t see the value of this facility, unless you only want selected hierarchies to be written to image files.

Excellent points. Perhaps the warning about the redundant hierarchies could be mentioned in the help tip for "Also assign its parents"?

Of more concern to me (having experienced problems), is the question of robustness. The basic requirement must be to have the label hierarchy stored on the images in a form that can be used by PSU to re-create the catalog in the event of a disaster. I presume that choosing "Write hierarchical keywords" in the general preferences is sufficient. (I have “Automatically write out Catalog changes to the image file” and “Only update out-of-sync images” checked). I take the point you’ve made, Mike, about the extra data available if you choose “Write catalog data to IDimager ICS scheme”, and I’ve now set this.

Keep in mind that enabling the setting does not mark any image as out of sync, so you might want to save the metadata again for *all* your cataloged images. (However, be also aware that a bug w.r.t. the writing of portfolio collections in ICS has been discovered - and just fixed - so you might also want to wait for the next build before performing that operation.)

One question this does raise in my mind is, what happens if images are read into PSU with conflicting hierarchy information?

What do you mean by this?

I haven’t checked this, and it shouldn't be an issue, but my concern reflects questions over whether what is written to images is always 100% reliable and consistent, especially if the catalog has at some stage been re-arranged.

Ah, let me see if I've now realized your concern: images may get cataloged and synced at different times and the metadata across various parts of your entire image collection may thus reflect different (and possibly incompatible!) catalog structures/states. This is an interesting issue (and a hard one to sensibly and reliably handle at the software level, in my experience) - perhaps it suggests several guidelines we should follow:

1) Avoid cataloging images or writing image metadata with different programs. (Use only PSU for this.)
2) If legacy keywords are no concern, then let PSU drive the keyword writing (e.g., "Replace keywords with catalog labels" is more predictable and trouble free than "Merge catalog labels with keywords").
3) Avoid placing in the same catalog images that (are meant to) end up with incompatible label hierarchies.
4) Avoid or be mindful of big structural changes (via label merges and relocations) to label hierarchies.
5) Always (re)write-sync all cataloged image from time to time, to make sure they reflect the latest state. (But check and pray that no serious metadata bug has creeped in the current build, and/or do an image backup first.)

What do you think about the last point, in particular? (I have my own doubts there.) Other thoughts or amendments?

Writing out hierarchical keywords and the IDimager ICS scheme obviously involves some redundancy, but in terms of storage / performance the impact is presumably trivial. Hierarchical keywords are obviously needed in case you should ever want to use a DAM tool other than PSU, the IDimager ICS scheme being of no value except when using IDimager Inc software.

Agreed.

One final thought, about changing preferences:

Preferences settings don't have to remain constant; they can be temporarily changed to suit particular needs.

Indeed – but I do find it quite difficult to ensure, after I’ve been making changes, that I’ve set things back to my default settings, especially if I’ve made changes on specific labels!

As one of those who like to tinker & experiment with different settings, I know exactly what you're saying.

(In theory, it would be nice to have a lightweight function ("tool") inside Photo Supreme to save and restore the entire catalog structure (including details like all the label settings, version placeholders etc.), without keeping any info about the cataloged images and their metadata. But, then again, what should happen upon restoring an old catalog structure if some recent catalog changes have yielded metadata which no longer matches the previous catalog structure?)

Lots of good food for thought! Thanks again.

[tstoddard]

I have to apologize for an oversight on my part. I looked again at the labels that I had created for butterflies and this time I noticed that the dc:subject had been mapped in the metadata settings of the parent labels. I don't know how I missed that the first few times I looked at them. Probably because I was focused on the child label which doesn't have that mapping and on the "Create keyword for this label" setting.

I guess now I know that I can accomplish what I want to accomplish by doing it this way but I will need to be careful because of the issue that vlad discovered about mixing the "Create keyword for this label" with the mapping of dc:subject. As long as I don't assign the parent label, my method will work fine. If I assign the parent I get unexpected results.

[vlad]

Tom,

Thanks for the update. I am relieved: labels with identical settings and diverging behaviors seemed like a bizarre minefield. Yet, I must say that even if the bug affecting the explicit keyword mappings was fixed (and I am pretty sure it will be, especially since it affects all array typed fields), I wouldn't employ or recommend such a fragile setup. IMHO, playing with 'dc:subject' on top of the standard support for keywords is just asking for trouble. (Btw, did you check if the hierarchical keywords are also generated for parents? I didn't. Perhaps you need to also add lr:hierarchicalSubject as a custom mapping in all the parent labels? I'm not even sure if that would work, perhaps you could let us know.)

Could you briefly share with us why would you opt to write parent keywords that way?

[tstoddard]

Yet, I must say that even if the bug affecting the explicit keyword mappings was fixed (and I am pretty sure it will be, especially since it affects all array typed fields), I wouldn't employ or recommend such a fragile setup. IMHO, playing with 'dc:subject' on top of the standard support for keywords is just asking for trouble. (Btw, did you check if the hierarchical keywords are also generated for parents? I didn't. Perhaps you need to also add lr:hierarchicalSubject as a custom mapping in all the parent labels? I'm not even sure if that would work, perhaps you could let us know.)

vlad,
You're comment about hierarchical keywords made me curious so I looked into it. I also have been considering whether or not it would be best just to assign parents in order to get a keyword written for the parent. You seem to consider my former approach of just mapping dc:subject for the parent label to be "fragile" so I went ahead and did some testing. Here is what I found:

First let me define my label hierarchy for the label I tested. The complete hierarchy is: "Object -> Animal -> Insect -> Butterfly -> Monarch". "Object" is a category so it doesn't have any settings, "Animal" and "Insect" have what I think are the default settings, no fields are mapped, they are set to create keywords, they are not set to assign parents or process parent mapping.

Before changing anything, I looked at one file that had one label assigned to it, which was "Monarch". The lr:hierarchicalsubject xmp field for that file contained one entry: "Object|Animal|Insect|Butterfly|Monarch" and it had two entries in the dc:subject (keywords) field, "Monarch" and "Butterfly". This means that a hierarchical keyword is not getting written when the keyword is created by the dc:subject mapping.

Then, I changed the settings of my Butterfly and Monarch labels so that the Monarch label assigned its parent labels and I deactivated the "process parent mapping" option. I then took the dc:subject mapping out of the parent label. After PSU resynced all of my Butterfly files (I neglected to change my global setting not to automatically sync) I looked that the xmp:lr:hierarchicalsubject field for the same file and found:

Object|Animal
Object|Animal|Insect|Butterfly|Monarch
Object|Animal|Insect|Butterfly
Object|Animal|Insect

The file also had 4 keywords, "Animal", "Insect", "Butterfly", and "Monarch".

So, where does this leave me? Well, I prefer having granular control over what is written to my files. Assigning parent labels doesn't allow that. From my example you can see that if I assign one parent, I'm assigning them all. I don't necessarily want that. I guess it wouldn't be so bad to have the Animal and Insect keywords written to those files but I don't really want them there. Also, the extra hierarchical keywords that get written to the lightroom field seem redundant, but, that might be necessary in order for a program to properly recreate my label hierarchy at some point in the future. I would be curious to know how Lightroom would interpret this file in its original state (2 dc:subject entries and 1 lr:hierarchicalsubject entry). Would it show 1 keyword, 2 keywords, or 4 keywords? I don't use Lightroom so I can't say. I would venture to guess that most other programs would just look at the dc:subject field for what they would consider to be "keywords". I looked at it in a few programs that I do use and they all look display the dc:subject field having 2 keywords. One of the programs also displays the lr:hierarchicalsubject field with the one hierarchical keyword in it. Windows explorer shows 2 "Tags" for the file in the file properties. None of these programs build "catalogs" so having 2 keywords and only 1 hierarchical keyword does no harm. If I was ever to move my catalog to a different program, however, I'm not sure what the ramifications would be. Also, if I wanted to restore my label hierarchy to PSU by reading lightroom hierarchical keywords I might also find some issues because of this. Since I would most likely use ICS for this purpose, that doesn't concern me.

I can think of three possible modifications in PSU that would resolve my issue of having control over what is written to my files. One would be if PSU would write a matching hierarchical keyword when it maps a label to the dc:subject field. The other would be to change the logic used when assigning parent labels so that a child could only assign its "parent" not its "parents". If I want to cascade assignments up the hierarchy, I would just need to set the parent label to do the same. The third would be for "process parent mapping" to write a keyword for the parent if the parent was configured to "Create a keyword for this label". I prefer the first or third options over the second because they would enable me to assign a keyword for a parent label without assigning the label. I'm not sure why that really matters to me, I guess I'm just being a control freak.

Edit: Actually, I see not reason why all three of these modification could not be done.

I would be interested in having Hert weigh in on the subject.

[vlad]

Hi Tom,

First let me define my label hierarchy for the label I tested. The complete hierarchy is: "Object -> Animal -> Insect -> Butterfly -> Monarch". "Object" is a category so it doesn't have any settings, "Animal" and "Insect" have what I think are the default settings, no fields are mapped, they are set to create keywords, they are not set to assign parents or process parent mapping.

Just for the sake of completeness, my understanding is that you then explicitly mapped 'dc:subject' in the details of Butterfly and set "Process parent mapping" in Monarch (only). Is that correct?

Before changing anything, I looked at one file that had one label assigned to it, which was "Monarch". The lr:hierarchicalsubject xmp field for that file contained one entry: "Object|Animal|Insect|Butterfly|Monarch" and it had two entries in the dc:subject (keywords) field, "Monarch" and "Butterfly". This means that a hierarchical keyword is not getting written when the keyword is created by the dc:subject mapping.

Frankly, that's exactly what I expect.

Then, I changed the settings of my Butterfly and Monarch labels so that the Monarch label assigned its parent labels and I deactivated the "process parent mapping" option. I then took the dc:subject mapping out of the parent label. After PSU resynced all of my Butterfly files (I neglected to change my global setting not to automatically sync) I looked that the xmp:lr:hierarchicalsubject field for the same file and found:

Object|Animal
Object|Animal|Insect|Butterfly|Monarch
Object|Animal|Insect|Butterfly
Object|Animal|Insect

The file also had 4 keywords, "Animal", "Insect", "Butterfly", and "Monarch".

Again, that meets my expectations.

So, where does this leave me? Well, I prefer having granular control over what is written to my files. Assigning parent labels doesn't allow that.

Qualification: automatically assigning parent labels doesn't allow that. Manually assigning parent labels and/or customizing your label metadata settings may allow that.

From my example you can see that if I assign one parent, I'm assigning them all. I don't necessarily want that.

Then, you might want to manully assign only the parent(s) you desire (Butterfly, in this case).

I guess it wouldn't be so bad to have the Animal and Insect keywords written to those files but I don't really want them there.

Fair enough. But may I ask if you ever want to write those keywords? If not, then you could simply set those labels to not create keywords. (However, I suspect you might still want to write Insect as a keyword when you don't know what kind of insect it is. Is that the case or do you always assign and write leaf labels?)

Also, the extra hierarchical keywords that get written to the lightroom field seem redundant, but, that might be necessary in order for a program to properly recreate my label hierarchy at some point in the future. I would be curious to know how Lightroom would interpret this file in its original state (2 dc:subject entries and 1 lr:hierarchicalsubject entry). Would it show 1 keyword, 2 keywords, or 4 keywords? I don't use Lightroom so I can't say.

I don't use it either, but I would be interested if someone could answer your question.

I would venture to guess that most other programs would just look at the dc:subject field for what they would consider to be "keywords".

Agreed.

I can think of three possible modifications in PSU that would resolve my issue of having control over what is written to my files. One would be if PSU would write a matching hierarchical keyword when it maps a label to the dc:subject field.

Frankly, I sympathize with what you're trying to achieve, but I doubt that's a reasonable expectation. PSU already has builtin support for both regular and hierarchical keywords, and that is exposed via dedicated settings. I find it reasonable that a hierarchical keyword is automatically written (or removed) for a regular keyword only when the later is written (or removed) through the standard label/keyword mechanisms.

If your suggestion got implemented, it could start a slippery slope. For example, why not then request that a hierarchical keyword is also automatically written (or modified, or removed) when the user edits 'dc:subject' via a detail profile or directly inside the Details panel? If Hert is willing to reliably implement all the special handling required to always keep dc:subject and lr:hierarchicalKeywords in sync, then that's fine by me. (I would only object to a partial implementation, because the behavior then becomes very hard to predict, at least without proper and detailed documentation.) But, again, I wouldn't raise the bar as high...just yet.

Getting back to business: have you laso tried adding lr:hierarchicalKeywords as a custom mapping too? Does that work? If so, then you might want to consider it. If that doesn't work, but you really need (want?) to bother with explicit dc:subject mappings, then perhaps you, Hert or myself could one day write a script that tries its best to line up all hierarchical keywords with all the regular keywords. As a matter of fact, such a script might have a more general use. (Note that, in theory, one could also tinker with lr:hierarchicalKeywords, without worrying about dc:subject, so the keyword divergence could go either way - or both ways, in worst case scenarios.)

The other would be to change the logic used when assigning parent labels so that a child could only assign its "parent" not its "parents". If I want to cascade assignments up the hierarchy, I would just need to set the parent label to do the same.

FWIW, someone already entered a feature request (#2599) to automatically assign only the direct parent, as an additional option. (Simply replacing the existing logic would most likely displease some users.) Personally, I'm not too keen to support it (I'm somewhat wary of additional complexity, even if appreciate flexibility myself), but I think it's fair to let you know about it.

The third would be for "process parent mapping" to write a keyword for the parent if the parent was configured to "Create a keyword for this label".

Again, I think this would not work for those users who intend to cascade custom mappings (such as location field mappings) but do not intend to cascade the keywords too. (Well, you might suggest that they could/should explicitly set their upper labels to not create keywords, but that wouldn't always work: for example, I might want to always write a city label to the photoshop:City field, but to write the city as a keyword only when I don't specify a sub-location too.)

This might not even work for you, assuming "process parent mapping" applies to all the parent chain (as I think it currently does), because you would then get Animal and Insect also written as keywords in your example above. Right?

I prefer the first or third options over the second because they would enable me to assign a keyword for a parent label without assigning the label.

The problem is that you want to do this only for some of the labels (otherwise you could use "include all parent level label keywords" - this automatically syncs the hierarchical keywords, too) and only for some of the images (otherwise, you could permanently turn off the creation of keywords for labels like Animal or Insect).

I'm not sure why that really matters to me, I guess I'm just being a control freak.

As a software user, I'm sometime the same - I just try to not let the freakiness get the best of me (As a software designer, I'm more cautious.)

(Overall, PSU's control/predictability balance suits me pretty well, especially given a lot more custom behavior is achievable via scripting. Just for the sake of pondering a hypothetical "what if" scenario, we could imagine that Hert might conceivably document and open to scripting the API for user interface/settings + event listeners (think of label assignment or revocation, for example). Then, someone very well versed in programming/scripting could, in theory, design his or her own modded PSU version. At that point, however, I don't see how IDimager could reasonably be expected to still ensure stable and consistent functionality for all users, not to mention free PSU support.)

Edit: Actually, I see not reason why all three of these modification could not be done.

Everything is possible in software (...except when it's impossible ). That doesn't mean every possible addition or change is beneficial.

[tstoddard]

vlad,

Your comments and thorough analysis of my ramblings are very helpful and make a lot of sense. In the end, if I really want to achieve my goal, which is to have my parent labels written to files as keywords without assigning the parent labels, then the way I'm doing it works fine. I'm not certain about whether lr:hierarchicalsubject and dc:subject really need to be in sync in this instance.

For completeness, I will try to answer some of your questions.

Just for the sake of completeness, my understanding is that you then explicitly mapped 'dc:subject' in the details of Butterfly and set "Process parent mapping" in Monarch (only). Is that correct?

That is correct.

I guess it wouldn't be so bad to have the Animal and Insect keywords written to those files but I don't really want them there.

Fair enough. But may I ask if you ever want to write those keywords? If not, then you could simply set those labels to not create keywords. (However, I suspect you might still want to write Insect as a keyword when you don't know what kind of insect it is. Is that the case or do you always assign and write leaf labels?)

That is an interesting question. As my label hierarchy evolved, that changed. At first, as I was cataloging my files, I would come across some pictures of insects that I had not identified so I created an "Insect" label and assigned it to those pictures. As I identified some of them, I created new labels for each of them, assigned the specific label and unassigned the parent label. This way, I could select the parent label and easily find only images of insects that I had not yet identified. Eventually, I created a label for "Unidentified Insect" and assigned that to the ones still needing to be identified so that I could unassign the parent label. This partially explains the reason that I wanted to be able to write keywords without assigning labels. Initially, I did want the "Insect" keyword to be written but I didn't want the label to be assigned.

Using my insect example, if I wanted to go back to my collection of insects and find only the ones that I had not yet identified, it was easy to do that if I didn't assign the parent label to those that I had already identified. I could simply click on the "Insect" label, and only unidentified pictures would appear in the collection viewer as separate files. If I had assigned the parent label to all of my insect pictures then all of the identified pictures would appear in the collection viewer along with the unidentified ones and it would have been difficult to isolate the unidentified ones. Sure, I could use dynamic search and exclude all of the children labels, but that wasn't very efficient. At some point, I got in the habit of creating an "unidentified" child label for many of my parent labels. As my insect category grew, some of the children, such as "Butterfly", gained their own children labels. At that point, I decided that I wanted keywords for "Butterfly" and for its children but I didn't want "Insect" written to those files. The issue with unidentified pictures continued down the hierarchy. Some swallowtail butterflies are very similar so I would often just label an image as a swallowtail and then come back later to try to identify those and create or assign a child label to them. I didn't want to have to create an "unidentified swallowtail" label also.

I hope this lengthy description helps to explain why I am trying to do some of these things.

have you laso tried adding lr:hierarchicalKeywords as a custom mapping too? Does that work?

I don't think this is possible, unless I'm missing it somehow. The lr:hierarchicalSubject field is not one of the metadata mapping options offered in the label details metadata settings panel.

[vlad]

vlad,

Your comments and thorough analysis of my ramblings are very helpful and make a lot of sense.

Thanks, Tom. (I often feel like I'm also rambling a lot, but the truth is that putting my thoughts and findings in writing helps me understand things better and hopefully take better decisions too. I'm glad if it helps others as well.)

In the end, if I really want to achieve my goal, which is to have my parent labels written to files as keywords without assigning the parent labels, then the way I'm doing it works fine. I'm not certain about whether lr:hierarchicalsubject and dc:subject really need to be in sync in this instance.

I'm no DAM expert and I can't offer an educated opinion as such - I've just raised the issue. However, as a general rule, I do think it's a worthy goal to keep in sync (both at the application design + usage levels) all the multiple metadata which encode common or correlated semantical info. The way I see it (which may be different than how LR or some other program sees it), the 'Animal|Insect|Butterfly|Monarch' list indeed encodes the Monarch hierarchy - but it doesn't say that both the Butterfly and Monarch tags are important to you, while Animal and Insect are not. By this token, having also 'Animal|Insect|Butterfly' recorded inside hierarchical keywords cannot really be considered redundant in itself (since it provides an additional piece of information). However, if both regular and hierarchical keywords are taken into account, I would agree that the following joint two pieces of data completely (and minimally) encode the information that you want to convey:

• dc:subject: Butterfly, Monarch
  lr:hierarchicalSubject: 'Animal|Insect|Butterfly|Monarch'

(Recalling a remark from Charles Hubert, I would also note that additional complications may ensue for labels with duplicated names.)

To me, the relevant questions (for compatibility+interoperability) now become:

1) Which programs interpret the flat keywords only?
2) Which programs interpret the hierarchical keywords only?
3) Which programs interpret both the regular and hierarchical keywords?
3a) Which programs interpret the hierarchical keywords and, if not present, fail back on the flat keywords?
3b) Which programs (correctly) merge the info from hierarchical keywords and the flat keywords (assuming both are present)?

(Hopefully, someone will be able to at least shed some light on (ahem) Lightroom itself, as I don't know if it falls under 3a or 3b. Heck, I don't even know how Photo Supreme behaves on reading dc:subject vs. lr:hierarchicalSubject (not to mention the ICS), perhaps Hert or someone else could offer some hints.)

At some point, I got in the habit of creating an "unidentified" child label for many of my parent labels. As my insect category grew, some of the children, such as "Butterfly", gained their own children labels. At that point, I decided that I wanted keywords for "Butterfly" and for its children but I didn't want "Insect" written to those files. The issue with unidentified pictures continued down the hierarchy. Some swallowtail butterflies are very similar so I would often just label an image as a swallowtail and then come back later to try to identify those and create or assign a child label to them. I didn't want to have to create an "unidentified swallowtail" label also.

Yep, I understand exactly the issue with "unidentified <whatever>" - I actually raised this issue when I read the advice of assigning leaf labels only. On paper, this seems like a very good and easy to follow convention, but I also find it has some limits or drawbacks in practice. (Of course, this may depend on the kind of pictures one takes, as well as on what one intends to use the labels/keywords for.)

have you laso tried adding lr:hierarchicalKeywords as a custom mapping too? Does that work?

I don't think this is possible, unless I'm missing it somehow. The lr:hierarchicalSubject field is not one of the metadata mapping options offered in the label details metadata settings panel.

Tom, you are right: the entire XMP Advanced section is missing there and in detail profiles. I wonder if this is intentional or an oversight. (Hert?)

Anyway, you could still manually write 'lr:hierarchicalSubject' (without quotes) in the "Mapped to" input text field. I have tried this and it works, but it does not produce the desired result: as I expected, it only adds the label name to hierarchical keywords, rather than the whole upper hierarchy. (I don't think that's a bug, since that's what any mapping to an array typed field does: it appends an element with the label name.)

[chuckhebert40]

Vlad, thanks for your detailed response, and sorry not to come back sooner; as I said, I am a casual user, and I have not been near PSU, let alone this forum, for a while. There’s a lot of thought gone on between you and Tom since I last looked! I have not managed to digest all that, so for the moment I will just respond to your questions/comments.

On your first question, in connection with creating keywords from labels,

‘What do you mean when you say it is in reverse”?’

I merely meant that in PSU v1 you had to check a box if you did want a keyword created for a label, whereas v2 & v3 will create a keyword from a label by default, i.e. you need to take action if you do not want a keyword created.

The next point you raise is about keyword mapping. I wasn’t being sufficiently clear, and need to get my thoughts straighter. It was also a mistake to pick a Places hierarchy as an example, since this has the particular additional implication of creating a location keyword. I also realise, reading what you and Tom have written, that I need to extend my knowledge & understanding: I will study further.

Thanks for the tip about ExifToolGui – excellent.

I asked the question of what happens if images are read into PSU with conflicting hierarchy information, and you asked

"What do you mean by this?"

What I meant was, if you have one photo with the hierarchy Animal|Insect|Butterfly|Monarch, and another with Animal|Insect|Monarch (ignoring how this might happen), what does PSU do? However, I realise the answer’s absolutely obvious – it just creates two hierarchies!

I raised a concern about the consequences of what is written to images not being 100% reliable and consistent. I will study your response. I would also add that my concern was not prompted by a specific/known problem in PSU. However, I have just looked at a copy of a photo with hierarchical keywords inserted using PSU. The copy was made some time ago, outside PSU. I’ve just looked at the current version of the same photo as catalogued in PSU, and I find that this hierarchy information is no longer there. I know that it’s easy to lose track of what you’ve done when tinkering, but in this case the hierarchy is still in the PSU Category list, and I cannot conceive why I would have removed the information from that photo (and several others). I find it disconcerting when it seems I’ve lost information – but cannot be 100% sure.

I will do some more studying of your and Tom's responses, and of what PSU does, and hopefully soon. Thanks for an interesting and useful thread.

[vlad]

in PSU v1 you had to check a box if you did want a keyword created for a label, whereas v2 & v3 will create a keyword from a label by default, i.e. you need to take action if you do not want a keyword created.

FWIW, I find the current behaviour natural.

I know that it’s easy to lose track of what you’ve done when tinkering, but in this case the hierarchy is still in the PSU Category list, and I cannot conceive why I would have removed the information from that photo (and several others). I find it disconcerting when it seems I’ve lost information – but cannot be 100% sure.

I'm straying away from the original topic, but your comments are really enticing me to do so. Lately I've been thinking that it would be great if Photo Supreme could maintain (by default or on demand) a history of all metadata changes for every image - and also allowed the user to store and tag a metadata snapshot for any arbitrary collection (rather than the entire catalog, as implemented by the current backup feature). Eventually, this would allow the user to:
1) pick an image and browse one or more previous states of its metadata
2) pick an image and compare (i.e., show the diffs) between two different metadata versions (snapshots) stored at two different points in time (typically, the latest metedata vs. some previous metadata)
3) roll-back the image metadata (or, perhaps, only selected field(s)) to some previous state (identified by either a timestamp or a snapshot tag)
4) roll-back the metadata of multiple images to some previous state (identified by a snapshot tag)

Given the standard, XML-based representation of metadata, I would expect that implementing (1) and (2) would not be too hard - and it could possibly bring significant benefits for whoever asks: "hmm, what happened to my image metadata since time T"? Regarding (3) and (4) (the actual metadata roll-back), things might get trickier - since previous metadata (such as keyword hierarchies) might not line up with the current catalog structure (e.g., label hierarchies). To follow the current read settings and be predictable, perhaps an individual or bulk image metadata roll-back could be implemented simply as a re-import of image(s) based on their current content + the specified (past) state of their metadata.

I realize that I'm talking here about a significant feature, akin to so called revision or version control systems (VCS) - but I'm thinking that the PSU equivalent wouldn't need to be nowhere nearly as sophisticated as dedicated, full-fledged solutions. Moreover, it could be implemented incrementally - wouldn't it be useful even to simply store and browse image metadata history (without any diff or roll-back facility, for starters)? Or maybe implementing this feature would be overkill - with it being truly helpful in only a handful of instances (and mostly for technical users)?

Does anyone have other thoughts on this?

I will do some more studying of your and Tom's responses, and of what PSU does, and hopefully soon. Thanks for an interesting and useful thread.

Thanks for your feedback.