This is the output from a test currently running on my Test machine for A - “Animal”, B=“Mammal”, C=“Bear” and D= “Black bear” with PL5.1.4.4728 on Windows 10.
PL5-1-4_4 is the result of selecting B (“Mammal”) but automatically selected A as well and PL5-1-4_5 is the scenario with “Mammal” and “Black Bear” selected and PL5-1-4_3 is all selected which correspond exactly to what you are showing
I have to admit I have no knowledge of the workings of the metadata but what you have written Joanna certainly looks logical to me. I certainly would like to see DxO get their coding working correctly resulting in minimal maintenance and only additions for any bright ideas. Once they achieve that that will allow more time for improving the image editing or adding to whichever maybe, my time for bug fixing and more time for bringing the 2 versions more compatible.
Sorry for my ulterior motives.
Understood (shortest response ever - oops spoilt it)
Agreed that is what one gathers from the many and varied problems when the put the worn image with the wrong DOP to the wrong database and get Virtual Copies, so they dump or clear the database first!
It is whether you agree or not you are simply using it to you advantage. DxO consider the database to be the “holy grail” hence the fact that the database entry is always the [M[aster in any battle and the DOP the [1] slave even if the data in the DOP is more up-to-date that the database!
Arguably not entirely true with Lightroom but the third time I used it for testing the database was declared as corrupted so I threw it away but lost everything (I was not and am not an LR expert). It would be a scary notion but that is why you have the image and the DOP.
I was told by DxO that the feature was never intended to handle two way conflicts, if I made the changes I should know the score! I was not and am still not impressed. That is not an excuse for leaving the “ship” half painted, either “laziness” or the economics of actually implementing it with other pressures on budgets. I want the equivalent of LR and suggested that the pointed end of the ‘S’ could be used to point at the direction of the mismatch(es).
The bulk of the code is there already, someone is trying to cut corners and I am not impressed (not that that counts for anything).
Because some users are trying to keep DxPL generated metadata away from the image!
That is the reason that I have written more responses than you can shake a “cat” at when ‘Rating’ and ‘Rotation’ have been lost when users believed that the PL5 DOP would preserve the data. It does for PL4 DOPs, it is there but remains unused for all options pre 5.3.0.
On PL5.3.0 they changed the rules but instead of providing an option to use DOPs as a metadata input they tied it to the AS(OFF) setting! So now we have
If I wrote that into a play no-one would believe it @Musashi!
I am pedantic not autistic nor OCD. I do not know how much the audience know about the subject and English is not the first language for many users and my thought processes can lead to a rather stilted and slightly non-liner English. i.e. there is actually a simpler way of putting it but redoing it yet again gets to be a real …
5.1.4.4728 on Windows 10
Hmm!
I understand but it requires a certain amount of understanding on both sides and currently there is way too much coming only from the forum and not the other way.
I am certainly not doing this for the “good of my health”, nor the copious accolades that I receive(not) (in truth I sometimes feel that the “finder” of “bugs”/problems are seen as the cause of the problem)!?
I want a more lightweight set of DAM features available and doing what they should be doing!
Any and all changes in functionality (other than turning something that fails into something that works - and even that can be problematic because users can be using a “fault” as a feature) should be implemented in such a way that the old is preserved and users can elect to use the new as and when they are ready (or not at all).
PS this topic is becoming “long post nirvana” or should that be “long post hell”!? Replies to that comment are not solicited and will be treated as a “bug”, i.e. an unwanted feature.
That was what was so amazing about our “relationship” - we both gave each other the right to say that they were wrong, even when we knew they were right, in order to make the other prove, beyond all doubt, what they were proposing. It might sound daft but it was such a change from the usual “Joanna is being paid for being right, therefore she must be” that a lot of developers would come back with.
After the bulk of my work was done there (over 7 years) my “adversary”, the managing director and chief programmer, turned to the development team and told them to have the same questioning (even argumentative) attitude to his ideas 
Please @Musashi don’t either just accept what we say, or go off on your own track without being prepared to defend your stance. I’m sure I speak for the “others” when I say we have the best of intentions to get this right for the benefit of both DxO and their users. And you get the benefit of several brains for free 
I have just done a “reverse” test, using the principles I outlined in this post
I started by using my app to apply Animal|Mammal|Bear from the known hierarchy Animal|Mammal|Bear|Black Bear
Now, my app assumes that all levels above a selected node will automatically be included, so I get an XMP that looks like this…
<dc:subject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Mammal</rdf:li>
<rdf:li>Bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Animal|Mammal</rdf:li>
<rdf:li>Animal|Mammal|Bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which PL5 then reads like this…
Perfect!
If I then manually edit the XMP file to remove Mammal from the hierarchy…
<dc:subject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Mammal</rdf:li>
<rdf:li>Bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Animal|Mammal|Bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… PL5 shows the “out of sync” icon and, upon refreshing, then shows…
This also seems to be as expected.
If I then go back to my app and re-read the file, I get…
… which makes me a very happy bunny, because my app doesn’t care about any “missing” nodes in lr:hierarchicalSubject, as long as all nodes down to the lowest leaf are included in dc:subject.
However, if I remove Mammal by unchecking it in PL5, this then re-writes the XMP, not only removing Animal|Mammal form lr:hierarchicalSubject, which is perfectly fine to do, but it also removes Mammal from dc:subject…
<dc:subject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Animal|Mammal|Bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which is not so fine as it breaks the ability to search in other apps like mine and macOS Finder.
In my opinion, this test proves that the only thing that needs to change in how PL5 writes hierarchies is that dc:subject must contain all keywords mentioned in lr:hierarchicalSubject.
Unless someone (Bryan @BHAYT @Musashi) or others can prove I have got it wrong, I believe that DxO uses the lr:hierarchicalSubject tag to determine which keywords to “select” in their keywords display and that this is sufficient for compatibility with other software but…………
… only as long as dc:subject contains all keywords mentioned. i.e. as in PL5.1.3/4
I have even tried removing any DOP and XMP sidecars to force reading from the database and, so far, haven’t found any need to mark keywords as “applied”. It would seem that DxO’s use of lr:hierarchicalSubject to list only those “hierarchies” that are checked is sufficient.
As a final double check, I manually added Mammal back in to the dc:subject only and it didn’t affect what PL5 displayed in either the keywords field or the tree view.
… as shown here:
Indeed. I just wanted to clarify things in my own mind to submit here for a sanity check by you guys 
One thing that we might want to look closer into is not just a) the way how keywords are stored and/or transmitted but also b) which keywords (of a hierarchy) are shown and how.
I think that these two are independent, b) being a choice (see my post up there) or selection of a).
As far as I’ve looked and thought about it, each app handles a) correctly-ish and does whatever it likes in the b) field, without giving the user a choice of how to do b):
I think this is so important. How data is stored should never be dependent on how it appears - appearance should only ever be an interpretation of data. Simplest example is a clock (data), which can be visualised as either analog hands on a dial, or a digital display.
Can I dare to bring the subject of whether a “dictionary” of keywords is a good idea or not?
In my app, all keywords can exist as standalone, hierarchies are simply one or more organisations of those keywords. This allows any keyword to be integrated into multiple hierarchies if necessary, or to be used on their own.
My app provides a two column browser, which allows dragging and dropping from the global list to the hierarchy view. This avoids the horror of PL5’s minute hierarchy display, where you have to drag a word to try and find the parent you want to attach it to, with the scrolling going crazy when you touch either the top or bottom boundary.
The “dictionary window” also separates organisation from assignment, in that keywords can be verified for spelling instead of hoping you have spelt them correctly whilst typing new keywords into the keywords entry field.
In my app, the rules allow for the direct entry of new keywords whilst assigning to an image, but such new words are initially only assigned as standalone. This allows for later organisation of such words into one or more hierarchies without losing the immediacy of being able to search for that single keyword.
Of course, once keywords have been assigned to images, if they are then added to new hierarchies, the user would need to search for images that contain the standalone keyword and replace it with its hierarchical counterpart. Once more, this provides a safe way of ensuring the correct hierarchy has been applied.
Using a managed dictionary also means that we are not reliant on PL5 scanning folders on disk to build up the list of already available hierarchies, with the chance that certain unvisited folders will not be scanned and some hierarchies not included.
Once we have our managed dictionary, entering hierarchical keywords is no longer prone to memory lapses and incorrect assignment that can happen when typing a separated list of keywords in the hope that something, somewhere can organise them correctly.
It would also pave the way for the possibility of importing pre-defined lists and hierarchies but, more importantly, it takes out the “multi-purpose” add/edit/compose nature of the tiny little palette we presently have, where it is difficult to know whether you are deleting a word from an image or the entire list of hierarchies.
Deleting a keyword in the token field of my app is only ever about removing it from the selected image(s). In order to remove it from the dictionary, or change the spelling, you need to go to the manager window where, deleting or editing a keyword will automatically update every image to which it has ever been applied.
Does this help or further confuse?
That sounds absolutely logical and hopefully less programming in the future.
@Joanna and @platypus I have no time today to digest your posts and respond but a few of things have occurred/bugged me
2: How do you edit the last character in any edit of anything? Just managed it but the margin to select the critical point versus deselect the item is very small! @sgospodarenko
it can be viewed in two ways (I believe)
OR
Hence, PL5 is keeping elements together by an auto-select mechanism but is enforcing nothing!
Simple and true, also for the keyword list itself, whatever its form.
A two column editor is fairly easy to handle, provided that the columns can be scrolled independently and stretched to full screen or window hight. Building a hierarchical structure from a spaghetti list of keywords should then be easy, provided that the type that’s used is readable
Fitting a two column list into a current DPL sidebar might be challenging, as is full hight size, at least under what seems to be DXO’s current tool size policy. Having an un-dockable list should be possible though.
…context-click on the keyword, rename it and add the missing part, or delete the entry and try again, adding keywords from the list rather than typing them in.
It’s a pity that A:B cannot be replaced by A>B or A|B with automatic (and correct) insertion into the respective hierarchical branch…YET.
Yes, DPL proposes to do the right thing, but we’re free to mess things up. 
Unfortunately, in this case, that isn’t going to work.
Start at this point in Bryan’s example…
What Bryan is trying to do is to separate out mammal and bear.
Invoke the context menu and select Modifier (Edit)…
Change the text…
Press Return to accept the change and…
Oops!
Using my app, here is the keyword manager with a hierarchy A > B > C > D…
You can see that each of the four keywords in the hierarchy have been assigned to one image…
To rename C, go to the manager, right-click on the keyword in the master list and select Renommer le mot-clé (Rename the keyword)
Edit the keyword…
Click on OK and the keyword is changed - in the hierarchy…
… and in the keywords for the image (and any others that also contain it)…
I am convinced that the PL keyword palette is trying to do too much in too little space, leaving the user to figure out what might happen if they try to rename a keyword there.
In fact, whether I use the keyword field or the tree view, renaming one keyword in a hierarchy changes all images, not just the one currently selected.
That’s a sure fire recipe for complaining support calls and annoyed posts here.
Do you know the towers of hanoi? Renaming might need a detour, like using a placeholder name, some reshuffling in the keyword list and then a rename or elimination of the placeholder. The necessary steps depend on the individual situation.
@platypus I knew it was harder than that
in this case the whole keyword needs to be removed
and a reconstruction done from what is already in the database and adding “black” bear.
If I was trying to do anything significant I would not like to be using this system!
I beat you to the Oops but didn’t post because I am frantically trying to get the house back in order for the return of my Wife after a short break to Norfolk with her older Sister and some friends!
Way to much and in fancy blue boxes that are useless for any sort of long editing! A case of “form” over function, looks good but is actually a trial to use.
I’ve just had a bright idea. How about a separate floating keyword manager window? 
It would help but I actually want a simple black on white box floating editing box for all editing situations (presets, file names, keywords etc) and in the case of my keyword situation the original keyword needs to be re-assembled and offered for editing (the computer is supposed to do the work not the user or was that just the ethos of a bygone era!?)
Hi,
In order to move on on other topics, here is a recap of DxO upcoming implementations (already mentionned above)
Then regarding the MWG recommendations mentionned, they are not all up to date and other software do not follow it. The recommendations are for flattering of “mwg-kw:Keywords” tag. We do not support it at all. There is nothing about flattering of “lr:HierarchicalSubject” in MWG recommendations.
Concerning the advanced metadata conflicts resolution, we are going to think about it and see whether or not we can propose something in a near future alongside the previous options mentionned.
We’ll close this topic in order to move on on other subjects.
Best regards
These two points are unclear or even redundant. Can you give us examples of how XMP would look in the four possible cases?
How will DPL deal with the new tag that was recently introduced in Lightroom: <lr:weightedFlatSubject>? As of now, the tag seems to be taken over to XMP written by DPL 5.1.3 and other versions.
