Label revocation: findings + comments

[vlad]

One topic that emerges from time to time is the following: which metadata field(s) are cleared - or should be cleared - when a label is unassigned from one or more images? This has been discussed mostly w.r.t. locations - and I'm especially interested in that particular aspect too - but I think a more general survey is useful, even if only to provide the larger context for the debate and decisions on location labels and data.

Here is a summary of my findings, which should reflect the state of the current build (3.0.2.2060):

(1) If a label is set up with "Also assign its parent", the parent labels are also revoked when the label is revoked. Each label revocation may, in turn, trigger its own metadata revocation actions, as detailed bellow.

(2) If a label is set up with "Create keywords" (the default metadata setting), then the label revocation also removes the corresponding keyword, from both dc:subject and lr:hierarchicalSubject (assuming the writing of hierarchical keywords is enabled, as recommended).

(3) If a label belongs to the People category, then it has by default an implicit field mapping to iptc4xmpExt:PersonInImage. (That mapping does not explicitly appear inside the "Mapped to" setting.) The PersonInImage field is cleared when the label is revoked - this is consistent with labels inside Events but inconsistent with labels inside Places.

(4) If a label belongs to the Event category, then it has by default a field mapping to iptc4xmpExt:Event. (That mapping does not explicitly appear inside the "Mapped to" setting.) The Event field is cleared when the label is revoked - this is consistent with labels inside People but inconsistent with labels inside Places.

(5) If a label belongs to the Places category, then it most likely has a location field explicitly mapped in the label mapping setting. (See my previous post on location labels and fields for details.) The mapped field does not get cleared when the label is revoked. This is inconsistent with labels belonging to People or to Events, but is consistent with how explicit custom mappings are handled (see bellow).

(6) If a label has GPS coordinates specified in its GEO Location panel, those are not cleared when the label is removed. This is consistent with the policy on location fields.

(7) If a label has a custom mapping specified in its metadata settings, then the mapped field is not cleared when the label is revoked. This is inconsistent with the implicit label mappings to keywords (for all labels), PeopleInImage (for People labels) and Event (for Event labels).

(8) If a label has a detail profile applied specified, then the profile changes applied during assignment are not reverted when the label is revoked.


Hopefully my summary is accurate (as of build 2060), as I haven't had time to retest everything. I am going to write my take on the above In a subsequent post - meanwhile, feel free to write your own comments, additions or corrections.

[chuckhebert40]

Useful summary, Vlad. Two characteristics I personally like to see in any application are consistency and reversibility, and some of the points you make concern processes which aren’t in line with these. I have not looked at GEO data or detail profiles (items 6 & 8 in your list), but would comment on the other points.

(1) If a label is set up with "Also assign its parent", the parent labels are also revoked when the label is revoked.....

If two or more labels with the same parents are assigned, those parents are assigned. If one of those labels is then revoked the parents are also revoked, and the parent keywords will also be removed from dc:subject. This is incorrect - the parents should remain assigned, and as keywords, until the last of the child labels is revoked. (The ‘extra’ entries in lr:hierarchicalSubject (i.e. for each of the parent levels) will also be removed – but these are in any event redundant).
If the aim is to get all parents written to the image file as keywords, then using the global Write setting “Include all parent level labels as keywords” seems in every way preferable. When this setting is used the above problems don’t occur.

(2) If a label is set up with "Create keywords"... then the label revocation also removes the corresponding keyword, from both dc:subject and lr:hierarchicalSubject....

I have deliberately referred above to dc:subject. "Keywords" is an IPTC field, and while it would appear to be correct in the PSU database (i.e. as viewed in the Details Panel) there are problems with what is written to the image file: (i) if more than two labels are assigned, duplicates appear in the Keywords field; (ii) revoking a label does not remove the corresponding entries in the Keywords field (related to the previous point?); and (iii) keywords which contain a space sometimes get treated as two keywords. (The term “keywords” – e.g. as in the global setting “Store keywords in alphabetical order” – really refers to dc:subject, and not to the IPTC field. Not being an expert I don’t know how dc:subject and IPTC-keywords are used elsewhere, nor their relative importance, but the loose use of terminology doesn’t help newcomers to metadata!)

(3) If a label belongs to the People category, then it has by default an implicit field mapping to iptc4xmpExt:PersonInImage..... The PersonInImage field is cleared when the label is revoked

If various People labels are assigned to an image, and if any of those labels are explicitly mapped to PersonInImage, then only those labels will appear in the PersonInImage field – i.e. they negate the PSU built-in mapping of this field.
The Photo Supreme Quick Start document says “You are free to define as many Categories as you like or rename the existing ones.” In order to compare the behaviour of a “People” hierarchy and a normal hierarchy with an identical structure, I renamed the category “People” to “Things”. There was absolutely no change – i.e. PSU seems to regard the category at the top of the list as People, regardless of what it’s called.

(4) If a label belongs to the Event category, then it has by default a field mapping to iptc4xmpExt:Event....[this] is cleared when the label is revoked....

iptc4xmp:Event can only hold one keyword (Why? – Family Meeting could well occur with Birthday, Christmas, etc.) This field is only cleared when a single assigned Event label is revoked. If several Event labels have been assigned, and the one in iptc4xmp:Event is revoked, the content of that field is replaced with another of the assigned events (which one seems unpredictable). Assigning an additional Event will sometimes cause what is in iptc4xmp:Event to be replaced with the new Event. This too seems unpredictable, although using the as-supplied list nothing seems to displace “Birthday”.
If an Event is explicitly mapped to Iptc4xmpExt:Event the behaviour seems to be the same as mentioned for People (see above). Thus, assigning “Halloween” in addition to “Birthday” will not ordinarily displace the latter from Iptc4xmpExt:Event, but if “Halloween” is explicitly mapped to Iptc4xmpExt:Event then that field will change from "Birthday" to “Halloween”. Also like People, if the Category name “Events” is changed to something else, assigning a label will still impact iptc4xmp:Event.

(5) If a label belongs to the Places category, then it most likely has a location field explicitly mapped in the label mapping setting...... The mapped field does not get cleared when the label is revoked.

(7) If a label has a custom mapping specified in its metadata settings, then the mapped field is not cleared when the label is revoked...

The first of these (5) seems to be a particular instance of the latter, but there are particular issues with the Places category. If you revoke the assignment of (say) a City which is mapped (such as Paris in the as-supplied Catalog), not only are the XMP City fields not cleared, but if you remove the image from the Catalog and re-import it, then that City is assigned again, even with no dc:subject or lr:hierarchicalSubject in the image file. This suggests not only an issue with the writing (removal) of the mapped labels, but also an anomaly in the read process; I’ve found this particular problem only with Places.
The differences between mappings that are automatic (i.e. hard-wired in PSU) and those that are specific to a Catalog label can make it difficult to fathom out what’s going on, and lead to some odd results. Suppose Alice is mapped to Iptc4xmpExt:PersonName, but Barbara isn’t. I assign Alice to an image, but I’ve made a mistake, so I revoke Alice and assign Barbara instead. What ends up on the image file is PersonInImage=Barbara, and Iptc4xmpExt:PersonName=Alice. I realise that this example might be far-fetched, but it does indicate the sort of anomaly that can occur where the reversal of a process isn’t clean/complete, especially with the large number of optional settings provided in PSU.

I think these inconsistencies should be addressed, not least because many of the results may well not be noticed unless you are looking at the metadata in the Details Panel (which in itself has several inconsistencies).

[vlad]

Useful summary, Vlad.

Thanks, Charles. You have also made some interesting discoveries and provided very helpful comments.

Two characteristics I personally like to see in any application are consistency and reversibility,

I am in agreement, with the caveat that reversibility in software is often a very hard problem - therefore, an application should provide explicit support for it only if it could do it reliably. (For example, I think it could be a killer feature if PSU could keep a history of metadata changes and provide some kind of rollback mechanism - and I have in mind something finer grained and more sophisticated than the existing DB backup/restore - but such a feature could do more harm than good if its implementation was not sufficiently reliable/predictable/consistent.) Regarding consistency, I value it very much and would also like to see some improvements there.

(1) If a label is set up with "Also assign its parent", the parent labels are also revoked when the label is revoked.....

If two or more labels with the same parents are assigned, those parents are assigned. If one of those labels is then revoked the parents are also revoked, and the parent keywords will also be removed from dc:subject. This is incorrect - the parents should remain assigned, and as keywords, until the last of the child labels is revoked.

Excellent point. Would you please enter a feature request in Mantis, such that I can vote for it? (Btw, your comment has reminded me that I had an old draft regarding some suggestions for better handling the editing of label properties - in particular, the automatic assignment of parents. I'll try to see if I could revive it.)

(The ‘extra’ entries in lr:hierarchicalSubject (i.e. for each of the parent levels) will also be removed – but these are in any event redundant).
If the aim is to get all parents written to the image file as keywords, then using the global Write setting “Include all parent level labels as keywords” seems in every way preferable.

I agree.

When this setting is used the above problems don’t occur.

Well, they don't occur at the metadata (keyword) level - but, even with that setting, one could still employ automatic parent assignment (for the purpose of using labels in searches and filters, for example) and expect that labels are properly managed (in particular, upon revocation).

(2) If a label is set up with "Create keywords"... then the label revocation also removes the corresponding keyword, from both dc:subject and lr:hierarchicalSubject....

I have deliberately referred above to dc:subject. "Keywords" is an IPTC field, and while it would appear to be correct in the PSU database (i.e. as viewed in the Details Panel) there are problems with what is written to the image file: (i) if more than two labels are assigned, duplicates appear in the Keywords field;

This is ticket #2252 in Mantis, I've just added my vote for a fix.

(ii) revoking a label does not remove the corresponding entries in the Keywords field (related to the previous point?);

I haven't seen any problem with keyword revocation (just tested it) - could you please explain?

(iii) keywords which contain a space sometimes get treated as two keywords.

Indeed, I've just recently seen a mess presumably caused by keywords (and other metadata) with multiple words.

(3) If a label belongs to the People category, then it has by default an implicit field mapping to iptc4xmpExt:PersonInImage..... The PersonInImage field is cleared when the label is revoked

If various People labels are assigned to an image, and if any of those labels are explicitly mapped to PersonInImage, then only those labels will appear in the PersonInImage field – i.e. they negate the PSU built-in mapping of this field.

Interesting observation. I don't consider the current behaviour desirable at all - it would naturally be resolved by making the mappings explicit.

The Photo Supreme Quick Start document says “You are free to define as many Categories as you like or rename the existing ones.” In order to compare the behaviour of a “People” hierarchy and a normal hierarchy with an identical structure, I renamed the category “People” to “Things”. There was absolutely no change – i.e. PSU seems to regard the category at the top of the list as People, regardless of what it’s called.

I am not suprised: it makes sense that Photo Supreme internally identifies categories by some unique id rather than by their user visible name. (Incidentally, this allows multiple categories with identical names - a flexibility which I consider troubling, though, since it allows us to duplicate entire label hierarchies without any means to distinguish among identically scoped labels, other than their visual position in the catalog explorer.) However, what makes sense from a software implementation perspective doesn't necessary make sense from a user perespective.

Personally, I would recommend slightly tightenining the policy regarding categories:
- forbidding multiple categories with identical names
- forbidding the renaming of categories with special (predefined) logic: People, Events, Places (as of now)

(4) If a label belongs to the Event category, then it has by default a field mapping to iptc4xmpExt:Event....[this] is cleared when the label is revoked....

iptc4xmp:Event can only hold one keyword (Why? – Family Meeting could well occur with Birthday, Christmas, etc.)

I sympathize with with your reasoning, but the main problem lies with the IPTC specification (pg. 39) rather than with PSU: the former specifies that the Event field "names or describes the specific event the content relates to" and, as such, mandates a cardinality of 0..1 (meaning that there is either one event defined or none). (In contrast, the cardinality of PersonInImage is naturally defined as 0..unbounded.)

This field is only cleared when a single assigned Event label is revoked. If several Event labels have been assigned, and the one in iptc4xmp:Event is revoked, the content of that field is replaced with another of the assigned events (which one seems unpredictable). Assigning an additional Event will sometimes cause what is in iptc4xmp:Event to be replaced with the new Event. This too seems unpredictable, although using the as-supplied list nothing seems to displace “Birthday”.

I agree that unpredictability is generally not good. Since the Event field type is free text, I guess that PSU could store each assigned event label as a seperate line of text in the Event field - and remove it (rather than clear or replace the entire field content) upon the label revocation. The problem with this policy is that it would introduce a special logic for events. I would rather have the implicit iptc4xmp:Event mapping being made explicit in the custom mappings field of an event label - and then being handled exactly as custom mappings are generally treated. (In particular, that may entail that all bets are indeed off when we assign multiple labels mapped to the same field with a cardinality of 0..1, be it iptc4xmp:Event or some other one.)

If an Event is explicitly mapped to Iptc4xmpExt:Event the behaviour seems to be the same as mentioned for People (see above).

Same observation as above: the problem would naturally be resolved if all event and person mappings were being made explicit (just as it's already the case with labels within Places).

(5) If a label belongs to the Places category, then it most likely has a location field explicitly mapped in the label mapping setting...... The mapped field does not get cleared when the label is revoked.

(7) If a label has a custom mapping specified in its metadata settings, then the mapped field is not cleared when the label is revoked...

The first of these (5) seems to be a particular instance of the latter, but there are particular issues with the Places category.

Excellent remark. Would you say that it would be good, in general, to clear the field(s) mapped to a label? What should happen if the field has a 0..1 cardinality but there are also other assigned labels mapped to that field? (See the Event use case.)

If you revoke the assignment of (say) a City which is mapped (such as Paris in the as-supplied Catalog), not only are the XMP City fields not cleared, but if you remove the image from the Catalog and re-import it, then that City is assigned again, even with no dc:subject or lr:hierarchicalSubject in the image file. This suggests not only an issue with the writing (removal) of the mapped labels, but also an anomaly in the read process; I’ve found this particular problem only with Places.

Indeed, there are particular problems with places (locations). I started a different thread dedicated to those problems - I intend to soon revisit the topic and will comment at that point. (Meanwhile, feel free to add your own findings and comments there.)

The differences between mappings that are automatic (i.e. hard-wired in PSU) and those that are specific to a Catalog label can make it difficult to fathom out what’s going on, and lead to some odd results. Suppose Alice is mapped to Iptc4xmpExt:PersonName, but Barbara isn’t. I assign Alice to an image, but I’ve made a mistake, so I revoke Alice and assign Barbara instead. What ends up on the image file is PersonInImage=Barbara, and Iptc4xmpExt:PersonName=Alice. I realise that this example might be far-fetched, but it does indicate the sort of anomaly that can occur where the reversal of a process isn’t clean/complete, especially with the large number of optional settings provided in PSU.

I agree. One suggestion that I previously made in the forum (although not yet in Mantis, except in a crude form) is to employ category-specific label templates, with explicit field mappings: http://forum.idimager.com/viewtopic.php ... es#p107832

I think these inconsistencies should be addressed, not least because many of the results may well not be noticed unless you are looking at the metadata in the Details Panel (which in itself has several inconsistencies).

Agreed. I personally consider the inconsistencies and defects affecting the image metadata to be the most concerning (well, perhaps second to those - if any - affecting the data (image) itself).

Thanks for another interesting discussion.

[chuckhebert40]

Thanks Vlad, I'll try to cover the points where you've posed a question (implicit or otherwise).

an application should provide explicit support for it [reversibility] only if it could do it reliably

Agreed. In the current context, the system should at least cope with the basics of revoking a label - that is, to leave things as they would be if that label hadn't been assigned in the first place. One specific case is where two labels which assign parents have been assigned, and one is then revoked. On this one you asked

Would you please enter a feature request in Mantis

Done - Mantis #2836

The Photo Supreme Quick Start document says “You are free to define as many Categories as you like or rename the existing ones.” In order to compare the behaviour of a “People” hierarchy and a normal hierarchy with an identical structure, I renamed the category “People” to “Things”. There was absolutely no change – i.e. PSU seems to regard the category at the top of the list as People, regardless of what it’s called.

I am not surprised: it makes sense that Photo Supreme internally identifies categories by some unique id rather than by their user visible name. (Incidentally, this allows multiple categories with identical names - a flexibility which I consider troubling, though, since it allows us to duplicate entire label hierarchies without any means to distinguish among identically scoped labels, other than their visual position in the catalog explorer.) However, what makes sense from a software implementation perspective doesn't necessary make sense from a user perspective.

I too am not surprised that PSU identifies categories by some internal ID - it's how (e.g.) Excel works - but it's confusing for the user (especially novices), especially when the documentation not only doesn't mention it but implies you can change things freely! I am personally not too concerned about the fact that you can duplicate label names and hierarchies: if you assign a label (e.g. by typing it into the box at the top of the Assign Panel) it does list the options with the details of each hierarchy so you can choose the correct instance. I think that it's up to me not to duplicate a whole hierarchy!
You suggest:

Personally, I would recommend slightly tightening the policy regarding categories:
- forbidding multiple categories with identical names
- forbidding the renaming of categories with special (predefined) logic: People, Events, Places (as of now)

I would support the first of these suggestions.
As regards the second, you make two comments concerning consistency, and reversing processes, which are relevant:

the problem would naturally be resolved if all event and person mappings were being made explicit

and

Would you say that it would be good, in general, to clear the field(s) mapped to a label? What should happen if the field has a 0..1 cardinality but there are also other assigned labels mapped to that field? (See the Event use case.)

I would support not having any special processing, including mappings, built into PSU code (as currently seems to be the case for People, Events and Places - I hate hard-coding generally!). There are good reasons for these categories (and potentially others in the future) having particular mappings, but better to handle this using the overt mapping fields - e.g. with category-specific templates specifying those mappings (and which could be altered if you wanted to), as you have suggested elsewhere. This would need a bit of thought - it would be necessary, for example, to define whether something under Places is a Country or City, etc. (I will look again at your Places thread). On the question of clearing field(s) I'd say yes, absolutely. This is just a specific example of reversibility which I believe should be in the system: if I assign "Paris" to an image, and the Country and City fields in the metadata are populated, then if I revoke that assignment then the consequently populated metadata fields should also be cleared.
On the issue of fields with cardinality 0..1

the main problem lies with the IPTC specification (pg. 39) rather than with PSU

I did wonder whether this was down to the specification, but was too lazy to check. Personally, I'm not bothered (my interest in metadata is almost entirely concerned with being able to re-create hierarchies and labels, whether in PSU or some other software in the future) - which means I'll keep out of any further discussion as to whether anything might be done about the issue. I don't know what would be the most appropriate course of action where one label of several such labels is revoked. Inherently it would seem that the system should either cater for multiple instances, or else at least warn you when you are "breaking the rules". (Currently, if more than one Event label is assigned and you remove one the system will replace it in the metadata with one of the others).

[vlad]

Hi Charles,

Thanks Vlad, I'll try to cover the points where you've posed a question (implicit or otherwise).

an application should provide explicit support for it [reversibility] only if it could do it reliably

Agreed. In the current context, the system should at least cope with the basics of revoking a label - that is, to leave things as they would be if that label hadn't been assigned in the first place.

In some cases, that would require PSU (its database) to keep a history of the metadata. (Please see an example further down.)

One specific case is where two labels which assign parents have been assigned, and one is then revoked. On this one you asked

Would you please enter a feature request in Mantis

Done - Mantis #2836

Thanks - I'm going to review it and add my comments (if any) there.

I am personally not too concerned about the fact that you can duplicate label names and hierarchies: if you assign a label (e.g. by typing it into the box at the top of the Assign Panel) it does list the options with the details of each hierarchy so you can choose the correct instance. I think that it's up to me not to duplicate a whole hierarchy!

That's true - but Photo Supreme also allows (and IIRC it may even produce, upon certain label relocations or merges) duplicate label names under the same parent. I can't see any advantage of this (on the contrary).

Personally, I would recommend slightly tightening the policy regarding categories:
- forbidding multiple categories with identical names
- forbidding the renaming of categories with special (predefined) logic: People, Events, Places (as of now)

I would support the first of these suggestions.

Following on my previous remark, I would add: forbidding duplicate sibling labels. (This entails more thinking, however, on the entire support for structural changes, such as label relocation and merging.)

I would support not having any special processing, including mappings, built into PSU code (as currently seems to be the case for People, Events and Places - I hate hard-coding generally!).

So do I. (I honestly believe that the software world - and the world at large - would be better off if hard-coding was confined only to small scripts, isolated prototypes etc.; although, to be fair, special handling is sometimes necessary and doesn't necessarily imply rough hard-coding, as it could be implemented via programming templates, OO polymorphism, plugins, config files etc.; anyway, that's getting off topic.)

There are good reasons for these categories (and potentially others in the future) having particular mappings, but better to handle this using the overt mapping fields - e.g. with category-specific templates specifying those mappings (and which could be altered if you wanted to), as you have suggested elsewhere.

Great: I'm not alone then. I have finally recorded my proposal in Mantis (#2844) - feel free to add your comments or votes there.

This would need a bit of thought - it would be necessary, for example, to define whether something under Places is a Country or City, etc.

Agreed.

(I will look again at your Places thread). On the question of clearing field(s) I'd say yes, absolutely. This is just a specific example of reversibility which I believe should be in the system: if I assign "Paris" to an image, and the Country and City fields in the metadata are populated, then if I revoke that assignment then the consequently populated metadata fields should also be cleared.

That seems logical. But what if you already had France and Paris filled in the Country and City fields even before defining or assigning the Paris label (which simply overwrote the previous field values with identical values)? In this particular scenario, Photo Supreme would actually clear prior info rather than actually reverting to the previousa state (where the label was not assigned, but the Country and City info did exist). That's why I've said that complete reversibility, in its true sense, is a difficult (and sometimes intractable) problem - and PSU could (perhaps) properly implement it only if it stored a detailed history of image metadata in its DB. (And, yes, I have already said it: if Hert could pull this off - and who could, if not Hert? - then I'll be the first to bow in front of him and sing my praise all around!)

Now, to be honest, perhaps we don't really need true reversibility upon label revocation: after all, a label revocation may already remove a prior keyword - and I haven't heard many (if any) complaints about this. However, the user has fine-grained control over how keywords are read or written - implementing something similar for any metadata field might be overkill. The current policy (regarding locations, at least) seems oriented towards metadata preservation/safety (never touch the location fields upon label revocation) - perhaps it should instead address the most likely scenarios? (After all, one could always re-assign the Paris label if (s)he wants the location fields restored.)

On the issue of fields with cardinality 0..1 [...] I don't know what would be the most appropriate course of action where one label of several such labels is revoked. Inherently it would seem that the system should either cater for multiple instances, or else at least warn you when you are "breaking the rules". (Currently, if more than one Event label is assigned and you remove one the system will replace it in the metadata with one of the others).

Indeed, that's worth further consideration (thinking).

[chuckhebert40]

The more I think about this, the more I believe that the fundamental issue here is “who’s in charge of metadata?” The instance you cite,

what if you already had France and Paris filled in the Country and City fields even before defining or assigning the Paris label

reflects metadata that has either been imported with an image file or input via the Details Panel, in either case with PSU settings such that the Catalog labels are not brought into line with the imported metadata.

It is (in my view) unreasonable and unrealistic to expect PSU to cope with all eventualities where metadata is partially managed outside the PSU Catalog, and I believe PSU should behave as if it, and only it, is managing the metadata (with the corollary that if you choose to use PSU as your DAM, don’t confuse things by using something else as well). In the example, if Paris is assigned in PSU (which would normally, as you say, lead to the completion of Country and City metadata fields), then if Paris is subsequently revoked I would want (and expect) the Country and City fields to be cleared – PSU cannot be expected to know that in this particular instance the Country and City fields came from some other source.

A different issue is the mechanism used to establish what the metadata should be after (for example) revoking a label. I have earlier in this thread cited the case where one of two assigned sibling labels, each set to assign its parents, is revoked. Currently, this leads to the revocation also of the (shared) parent labels, and I’ve suggested this should be addressed: Mantis #2836. If the system were to re-establish what the metadata should be, based on the labels remaining after the revocation of the first sibling, then this would not happen. This would seem to be the most sure way of maintaining metadata integrity - i.e. re-establish what it should be, post-change, rather than simply processing a label revocation by reversing what happens when the label was assigned.

I am aware that there may occasionally be reasons for changing metadata in the Details Panel, but in that case I think it is up to the user to beware of possible consequences. In http://forum.idimager.com/viewtopic.php?f=57&t=23778 Hert has said “There should never be a need to edit keywords in the metadata”. I'll go with that.

[vlad]

Charles, thanks for the very good and thoughtful feedback. I am getting back to this thread since we have had recent discussions on the revocation of labels mapped to location fields - and I think that particular policy ought to be guided by a more comprehensive policy on label revocation in general.

For starters, I think we could agree that the current policy is not consistent - and that's not good. How could it be made consistent? I could see three different policy options (each with its pros and cons) leading to consistency on what should generally happen when a label is revoked:
1. Never clear the mapped fields
2. Always clear the mapped fields
3. Decide whether to clear or not to clear the mapped fields, depending on one or more user preferences, e.g.:
3.1. Global preference(s)
3.2. Per-category preference
3.3. Per-label preference
3.4. Preference modal dialog popping up whenever a user revokes or deletes a label

(N.B.:
In my view, the policies we are discussing would affect the removal of labels that are mapped to metadata fields other than simple or hierarchical keywords. Personally, I am happy with the current policy on always removing the (implicitly) mapped keywords - and I have never seen anyone bringing this up for discussion either.)

The current discussions, as well as some Mantis tickets, suggest that option 1 (never clear the mapped fields) is not good, as it often leads to stale metadata.

In the previous post, Charles has made an excellent case for option 2; personally, I am ready to buy the argument that once you employ mapped catalog labels (which are IdImager/PSU specific constructs), then those catalog labels ought to be tightly coupled to any mapped matadata (just as it's always been the case with keywords). I'll repeat, however, a remark I made elsewhere: in that case, all the relevant global preferences should probably default to "safe" settings (e.g., don't automatically create Place labels for location fields, Event labels for event fields etc.)

Option 3 (always act based on user preferences) appears to provide the most flexibility, but it could add complexity. Let's see:

3.1.) At the minimum, this would entail the addition of a single global metadata setting: "Revoke all mapped metadata when revoking a label" (Yes/No). A finer grained implementation would allow to define a list of metadata fields to be always preserved and/or a list of metadata fields to be always cleared whenever one or more labels mapped to those is/are removed.

3.2.) Per-category options would allow to independently specify, for each label category, if the mapped fields should be cleared whenever an underlying label is revoked. This would allow one, for example, to clear PersonInImage when revoking a label inside People but to keep the content of location fields when revoking a label inside Places.

3.3) A per-label option could be a simple toggle ("Clear mapped fields upon label revocation") under the existing ""Mapped to" text field (within the label details panel). If ticked (the default?), it would clear all the mapped fields. (N.B.: I am assuming here that all label mappings, except keywords, are going to be made explicit - this is not currently the case.)

Still, there is an additional detail: what should happen for a label (with or without its own mappings) which has "Process parent mapping(s)" enabled? Any option(s) about metadata clearing should cover that setting as well. (Think about an image having a city label assigned, but not having the upper country label assigned. Should the city label revocation trigger the clearing of the country metadata too?)

3.4) The greatest flexibility is in theory achievable by explicitly asking the user what he intends to happen with the corresponding metadata whenever he revokes or deletes a label with mapped fields (and/or GPS info?). However, such an implementation has some potential complications and drawbacks:

a) It could easily make the revocation of labels very annoying; a "don't ask again" option could still be provided in the asking dialog, but that could still leave some room for interpretation (...until FR #2907 gets implemented, at least): does the asking dialog get subsequently disabled for the revocation of that particular label or for *all* labels?, etc.

b) All parent labels are automatically revoked when a label with "Also assign its parents" is being revoked. Should a separate asking dialog pop up for each parent label removal? That seems overkill.

c) All descendent labels are automatically deleted when a parent label is deleted. Should a separate asking dialog pop up for each child label deletion? That seems overkill.


Based on the above analysis, I am now thinking that the best design tradeoff (between flexibility and complexity) would be 3.2: providing a per-category setting wrt. the revoking policy for any underlying label; it would always affect a label's own mappings, as well as all parent-level mappings (if "Process parent mapping" is in effect). Failing that, my next preference would be 3.1. (a global label revocation setting, especially if that would allow different per-field policies). Finally, I would be happy even with option 2 (always clear the mapped fields), as argued by Charles.

(N.B.:
Metadata fields could also be appended, written or overwritten via a metadata detail profile associated to a particular label. I think it would be excellent if the label removal policy could also clear up those fields. In the case of a value appended to a bag (multi-value) field, the clearing should affect only the added value rather than all the values in that field.)


To me, neither option 1 (leaving stale metadata) nor the status quo (inconsistent policies for different label categories) are acceptable, so I would really like to see a major improvement here in the next major release of Photo Supreme.

Charles, are we pretty much on the same page now?
Hert, are we overthinking the revoking/clearing aspect?
Any other opinions or comments?

[Hert]

Vlad, PSU will never clear fields when revoking a catalog label. If they are for you then there must be another reason for that...maybe other assigned catalog label that is set to write metadata?

[vlad]

Hert, there may be some misunderstanding here. Are you saying that revoking an Event label does not clear the Event field? I can't retest this right now (as I'm far from home and my PSU installation), but this certainly was the case in build 2060, which I was using when I originally started the thread.

[Mke]

Are you saying that revoking an Event label does not clear the Event field?

Revoking an event clears metadata fields on my system, as does revoking a person label...

[Hert]

The Event metadata is indeed controlled by the Event catalog label. I thought you were talking about label mapping. PSU maintains the Event and People and Place metadata from catalog labels in the respective top category's structure.

[Mke]

Hmm. I've got some labels mapped to Iptc4xmpExt:AOCreator and can also confirm that these aren't cleared when unassigning a label. That's not what I would expect.

[Hert]

Indeed, that's what I stated above: PSU will not erase manually created mapping or manually added metadata in a catalog label.

[Mke]

I guess there must be some, but I can't think of an obvious reason for not clearing the metadata, nor for why the two cases should be handled differently. It doesn't happen very often, but the normal reason I remove a label is because it was incorrectly assigned - and if I unassign the label for that reason, I wouldn't want incorrect information to persist in the metadata.

[chuckhebert40]

For the moment, just a question.

Hert, you say

PSU maintains the Event and People and Place metadata from catalog labels in the respective top category's structure.

My understanding is that this is true of Event and People, where the mapping is implicit (built into PSU), but Place metadata is only created when explicit mapping is defined on the individual labels. Is this not the case?