The second example reflects a situation, in which you have added Black Bear and then removed its forebears
The hierarchical keywords structure contains the relevant information about keywords and their relations, dc:subject seems irrelevant - at least as far as keyword display is concerned in the apps we tested with. Maybe we need to take on a new view?
Nope, my four bears are still there…
It might be all well and good for those apps which use the hierarchy to build the display but, it really doesn’t help with those apps which rely on the the dc:subject tag for searching - like macOS Spotlight, which knows nothing about lr:hierarchicalSubject.
…then it’s welcome that C1, Lr etc. rebuild the dc:subject entries.
I’ve not yet come across an app that does not write dc:subject and modifying it “externally” is not a way to manage that tag regularly imo.
Making sure that animal>mammal>bear is added together should provide the best possible foundation for exchange of keywords between apps…which means that I’d have to enter keywords from the keyword lists, rather than typing them in, which does the fourbears in DPL and LrC.
@Joanna, @platypus the Capture One “interpretation” of the Photo Mechanic output appears to show C1 avoiding any radical changes to the original layout but adding the “leaf” keyword to allow for searching generally or because it needs that for its own internal management.
I think my concerns are more philosophical than real with respect to keeping DxPL in line with any external reformatting because if we changed the 'Write to image" to C1 format then it is the equivalent of one of the DxPL formats and would show up as All assigned in DxPL any way.
If using a “sparse” layout like the PM layout then the output would be restricted but the additional keywords are contained in the component keywords in the hierarchical keywords anyway and the format templates indicate how those can be translated.
Hence with a “sparse layout”, DxPL can fill in the “gaps” using the hierarchical keyword components and remove excess duplicate keywords using de-duplication logic to trim the more voluminous layouts, that could become even more voluminous when they are then passed through a some of the templates!
Hence I think it is better to update DxPL with the new keyword layout when it has been written to the image to ensure that DxPL is tracking what is on disk but it would probably have been useful from the beginning to allow the original image data to be (optionally) preserved (always a useful feature when implementing something new!?).
Plus @Musashi can we have a feature to enable the “standard” launch background to be replaced by a user image, I was bored with the current one before we even finished Beta testing, e.g. @Joanna’s fourbears or
More than four bears plus associated “friends” and their fans! My old teddy and my wife’s are somewhere in the loft, Fredbear and threadbear!
