Label revocation: findings + comments

[vlad]

Ok, I think I understand Hert's point: Photo Supreme is perfectly consistent at the implementation level. Indeed, whenever a label has one or more fields specified inside "Mapped to" (within the label details), revoking that label will never clear any of those fields. OTOH, whenever a label controls certain metadata fields (events, persons, simple or hierarchical keywords, ICS fields) via some other internal mechanism, the label revocation will always clear the controlled fields.

That is a useful summary. Yet, while I concede that PSU may indeeed be consistent at some implementation level, as a user I am foremost looking forward at behavioral consistency. At a high(er) level, I don't really care that a label inside Places has location fields appearing inside the "Mapped to" box, while a People or Event label does not have. (To me, that difference is just a design accident or flaw, if you will.) Instead, all it matters to me is that all those labels (as well as other labels that I may set up with custom mappings and/or a detail profile and/or parent mapping processing) have some associated metadata fields - hence, the controlling policy of all those labels and metadata fields should be the same (or, subject to similar rules or user preferences).

Furthermore, from what I have gathered from the forum, Mantis as well as my own experience, it appears that the common revocation policy should be oriented towards clearing all the associated fields (or, at least, offering such a cleanup as an option). That may not be adequate in 100% use cases, but I think overall it would offer a predictable behavior, which would match users' expectations more often than not.

(Perhaps PSU should ask the user's confirmation regarding metadata cleanup whenever a label is deleted from catalog - as opposed to just unassigned from images - since in that case any erased metadata could not be easily rewritten by simply reassigning that label.)

Does that make sense?

[Mke]

Yes, that's a neat summary and, for me too, would be a preferable behavior.

(Perhaps PSU should ask the user's confirmation regarding metadata cleanup whenever a label is deleted from catalog - as opposed to just unassigned from images - since in that case any erased metadata could not be easily rewritten by simply reassigning that label.)

A good point. At the moment such data is retained in the image, whether mapped to the metadata by the program or manually by the user.

[fbungarz]

Hi all,
very interesting topic. Due to the hickups and lack of time I admit I still haven't concluded my migration to Photo Supreme.
I was completely unaware that in PSU some categories are automatically mapped per default to certain metadata fields and am now worried if that may cause further problems migrating that data from IDI.

So far I have been using hierarchical labels within my People category. For example, I do have a label "family" as parent of people that belong to my family (my parents, in-laws, etc.). If all labels that are part of people and automatically mapped to iptc4xmpExt:PersonInImage how ill such a hierarchy be written? I am part of my family, so photos that show me are tagged with "People|family|Bungartz|Frank Bungartz". Will the entire hierarchy be written to the XMP field? Or only some? For example, it would not make any sense if the metadata field iptc4xmpExt:PersonInImage contains "family"...

Regarding the Places category: again I am using a nested hierarchy that to some extend does not necessarily conform to a particular standard, e.g.:
Places|Continents|America|South America| Ecuador|Galápagos|sout-eastern/Centro Sur|Santa Cruz|Isla Santa Cruz
Places|Borders|Ecuadorian-Peruvian border
Places|regions|Sonoran Desert
etc.

So, the logic here is not all places are exact geographic localities, but borders, regions that go beyond state lines...
And in Galápagos with more than 120 islands and islets it makes sens the a particular island (Isla Santa Cruz) belongs together with closely neighboring ones to a larger group of islands (Santa Cruz).
Also, place names in use by large international companies like Google are frequently outdated. In Galapagos nobody uses the old English Island names anymore (like Charles for the island of Floreana), but the official names given to the islands by the state of Ecuador are also not typically used (so, Santa Maria is not used, but Floreana is)

I guess, what I am saying is: I would not want to have PSU mess up my People or Places category - which took me considerable time to build...

Is there an option to switch "auto fill" for those categories off???

Thanks,
Frank

[LifeIsLong]

I agree with vlad as well. The more I look into this issue, the less I understand about PSU labels. I thought setting up the details mapping on a per label basis would handle assigning and unassigning. In theory (or how vlad laid it out) I think it is a very powerful feature. As it is... just confusing and not very intuitive.

So how do places, people, and the details mapping interact? Maybe I should just stop using features that are not documented.

[vlad]

Hi Frank,

If all labels that are part of people and automatically mapped to iptc4xmpExt:PersonInImage how ill such a hierarchy be written? I am part of my family, so photos that show me are tagged with "People|family|Bungartz|Frank Bungartz". Will the entire hierarchy be written to the XMP field? Or only some? For example, it would not make any sense if the metadata field iptc4xmpExt:PersonInImage contains "family"...

If the pictures featuring you are assigned only the Frank Bungartz leaf label, then only Frank Bungartz will be written to iptc4xmpExt:PersonInImage. If you also assign (manually or automatically) the parent labels, then those (including "family") will be written to PersonInImage too. (If you don't like that, I'll point out a Mantis ticket that you could support.)

So, the logic here is not all places are exact geographic localities, but borders, regions that go beyond state lines...
And in Galápagos with more than 120 islands and islets it makes sens the a particular island (Isla Santa Cruz) belongs together with closely neighboring ones to a larger group of islands (Santa Cruz).
Also, place names in use by large international companies like Google are frequently outdated. In Galapagos nobody uses the old English Island names anymore (like Charles for the island of Floreana), but the official names given to the islands by the state of Ecuador are also not typically used (so, Santa Maria is not used, but Floreana is)

These are interesting use cases (and I would love to learn more about Galapagos), but I think it's better to discuss them in the geo tagging thread or in the location field thread. I simply don't know what to make out of them in the context of this thread.

I guess, what I am saying is: I would not want to have PSU mess up my People or Places category - which took me considerable time to build...

Is there an option to switch "auto fill" for those categories off???

There are global settings for the processing of location fields, including full turn off. I don't remember any way to disable either the link between labels inside People and PersonInImage fields, or the link between Event labels and fields.

[fbungarz]

Thanks Vlad for clarifying!
There are still to issues I do not quite understand. You mention only the label assigned is being written to the field. That makes sense. I am still using hierarchical keywords, but that being deprecated in PSU, their use being discouraged I have been thinking to switch to simple keywords, but in that case would probably configure quite a few labels to automatically assign parents as well. Now, if I assign a label (in People, Event, Places) that is configured to automatically write the parent, what content is then actually written to the XMP field? Only the label that I just manually assigned, only its parent or both?

Also, how do these special categories interact with custom mapping? I could envision a conflict if someone creates a label in a different category and maps it to an XMP field that per default would be auto-filled from labels in People, Event or Places. Which mapping then gets priority? PSU default settings for the the custom mapping created by the user? Which label is being written to the field then. The one mapped by the user or the one mapped per default by PSU?

There are global settings for the processing of location fields, including full turn off.

Where can I find these settings (apparently not under Preferences?). Are the enabled by default?

I don't remember any way to disable either the link between labels inside People and PersonInImage fields, or the link between Event
labels and fields.

That is unfortunate. While I can see that these settings may be a big time saver for some people, perhaps at least a registry hack could be shared to turn this off by people who not prefer to use this feature.
[If there is no option to turn it off, the only workaround may be to create different categories and not use the ones supplied with PSU at all. For example, leaving Events, People, Places empty and custom create the categories Occasion, Persons, Locations. Not being able to use default categories shipped with PSU, having to create alternatives, because these categories cannot configured as desired does not seem to make a lot of sense though...]

Cheers,
Frank

Thanks,
Frank

[vlad]

Hi Frank,

I am still using hierarchical keywords, but that being deprecated in PSU, their use being discouraged I have been thinking to switch to simple keywords, but in that case would probably configure quite a few labels to automatically assign parents as well.

I am surprised: why are you saying that hierarchical keywords have been deprecated or discouraged? Afaik, they are as recommended as ever. Perhaps you're making a confusion with delimited keywords?

Now, if I assign a label (in People, Event, Places) that is configured to automatically write the parent, what content is then actually written to the XMP field? Only the label that I just manually assigned, only its parent or both?

Both. (And don't forget that automatic parent assignment assigns all upper labels, not just the immediate parent.)

Also, how do these special categories interact with custom mapping? I could envision a conflict if someone creates a label in a different category and maps it to an XMP field that per default would be auto-filled from labels in People, Event or Places. Which mapping then gets priority? PSU default settings for the the custom mapping created by the user? Which label is being written to the field then. The one mapped by the user or the one mapped per default by PSU?

Are you talking about duplicated labels (in different categories)? Why does it matter which label gets eventually written, as long as you end up with the same (desired) value in your metadata? Actually, there may be a problem indeed for bag type fields (such as PersonInImage), because I'm afraid you could end up with duplicated values from duplicated labels. But I'm not sure if this answers your question or why would you maintain duplicated labels in the first place. (Or, are you perhaps afraid about PSU automatically creating such duplicates?)

There are global settings for the processing of location fields, including full turn off.

Where can I find these settings (apparently not under Preferences?). Are the enabled by default?

IIRC, they are somewhere under Preferences->Metadata settings. Look for a setting referring to location processing, which allows you to specify the level of processing (Up to City level, Up to Country level etc.) via a dropdown.

I don't remember any way to disable either the link between labels inside People and PersonInImage fields, or the link between Event labels and fields.

That is unfortunate. While I can see that these settings may be a big time saver for some people, perhaps at least a registry hack could be shared to turn this off by people who not prefer to use this feature.

I'm not fond of registry hacks. If cutomization is important for you, feel free to support label/category templates, which (in my view) would allow making the People and Event mappings overt and configurable rather than hardcoded and hidden.

[If there is no option to turn it off, the only workaround may be to create different categories and not use the ones supplied with PSU at all. For example, leaving Events, People, Places empty and custom create the categories Occasion, Persons, Locations. Not being able to use default categories shipped with PSU, having to create alternatives, because these categories cannot configured as desired does not seem to make a lot of sense though...]

You are talking about workarounds, but it's not clear around which specific problems. Besides locations (which are indeed problematic because they are hierarchical and because of issues with geo lookups and reverse lookups), the automatic Person and Event mappings work pretty smoothly. Try it out and you may actually like the current implementation.

Best,
Vlad

[vlad]

Now, if I assign a label (in People, Event, Places) that is configured to automatically write the parent, what content is then actually written to the XMP field? Only the label that I just manually assigned, only its parent or both?

Both. (And don't forget that automatic parent assignment assigns all upper labels, not just the immediate parent.)

EDIT:
My previous answer is obviously true only for labels mapped to a bag (multi-value) field, such as People/PersonInImage. For events, only one of the label values will be written (as constrained by the standard) - but I don't think PSU provides any guarantee with respect to which one. (This aspect has been touched upon in the first couple of posts of this thread.) It would be interesting to test.

[fbungarz]

Hi Vlad,
sorry for the confusion. Yes, I was talking about delimited keywords...

Why does it matter which label gets eventually written, as long as you end up with the same (desired) value in your metadata?

That is my point, I can have different labels mapped to the same field, say a label in the category People, which gets written out into iptc4xmpExt:PersonInImage and another, different label in a different category that I manually mapped to that field. Such a scenario might be unlikely, but it is possible. Which then gets priority? the custom mapping or PSU default mapping? Perhaps I worry too much, its a fairly unlikely scenario.
The duplicated values for duplicated labels may be yet an additional problem...

Try it out and you may actually like the current implementation.

Quite possible. Still, I already experience quite a few issues with migrating the catalog that I 'd prefer to keep things simple for now. If there is an option to enable/disable, I'd probably disable it for now, at least until I am sure the migration worked without further glitches...

I think your request for catalog label templates is a great idea and voted for it. It would be a fantastic way to custom configure my taxonomy category so that its hierarchy of labels is automatically written into the DarwinCore fields without manually having to map these labels. Still, implementation of such a functionality would be rather complex and I doubt your request has a chance to get implemented soon...

Thanks,
Frank

[Mike Buckley]

Yes, I was talking about delimited keywords...

I also have to wonder if you didn't also mean that you intend to change to LR hierarchical keywords rather than to simple keywords.

[fbungarz]

Hi Mike,
I am using delimited keywords and LR hierarchical ones at the moment. I have been using IDI long before LR even existed and started with delimited keywords, in fact I complained back the that IDI would only use a comma "," as delimiter and he eventually changed this so other keyword delimiters could be used. Since then I have been using the pipe "|" symbol.
I am not quite sure about simple keywords, why they would be an advantage. In fact, having a keyword like for example my name embedded in the image, does not mean a thing, does it? It could be that it measn I am the person on that photo, that I took the photo, that I own the copyright, etc. etc.
I realize that the XMP standard recommends that keywords are "simple" keywords and that LR hierarchical ones have become a "de facto" standard. That's why IDI says delimited keywords are "deprecated" (or "not recommended"). I am not sure if it makes sense to re-write keywords to thousands of images. But since I am migrating from IDI to PSU, have to re-import all images, check if they came across OK. IF I decided to use simple keywords, perhaps now would be time to make that change. But if I make that change, writing the parents would perhaps make sense.
I don't know ...

[Off-topic: I had just hoped the whole migration would be easier now, with PSU having matured to version 3. So much of what was missing in version 2 is now available and I really begin to like the way PSU works. But when I tried migrating a few weeks ago, having two weeks to do it, it turned out to be rather complex. Thus, I spent the entire two weeks figuring out a possible migration route. Time was up, I still hadn't migrated... ]

Frank

[Mike Buckley]

I am not quite sure about simple keywords, why they would be an advantage.

I can't think of a single situation when using simple keywords would be an advantage. Quite the opposite, it's very easy for me to think of situations when using only simple keywords could be a huge disadvantage.

[fbungarz]

I can't think of a single situation when using simple keywords would be an advantage. Quite the opposite, it's very easy for me to think of situations when using only simple keywords could be a huge disadvantage.

Me neither, but Hert still recommends using them instead of delimited keywords, because the XMP standard officially asks for simple keywords, not delimited ones.

[vlad]

Ok, let's try to come up with a clear summary and then hopefully get back on topic:

Simple keywords (dc:subject): essential metadata, supported by default (global settings, label properties etc)
Hierarchical keywords (lr:hierarchicalKeywords): strongly recommended, enabled by default
Delimited keywords: deprecated, strongly discouraged

ICS writing: recommended, although turned off by default
ICS reading: not recommended (unless needed), turned off by default

Hope I've got that right (from memory) - and hope it helps.

[Hert]

I never recommended using single keywords. As Vlad states, my recommendation is to use hierarchical keywords.