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):
- Capture One v12: shows everything above the selected keyword.
- Lightroom Classic 11.4: adds parent automatically, if child is ambiguous.
- PhotoLab: we’ll see what we’ll get out of what @Musashi wrote.
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
- While entering an hierarchical keyword my brain faded and I entered the keyword as animal|mammal:bear|black bear how on this or any planet am I supposed to fix this with the PL5 keyword interface @sgospodarenko
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
- I originally assumed that the keyword display was used to assign keywords to an image and arguably that is true so when this is done
it can be viewed in two ways (I believe)
- I am selecting keywords from an hierarchy to be included in the assigned elements from that chosen hierarchy and PL5 aids that principle by virtue of the automatic selection of all items in the hierarchy above the selected item
OR
- You are actually “just” selecting a keyword for inclusion in the image that happens to be from the same or a different hierarchy or a simple keyword. The applied logic from PL5 is a knee-jerk reaction to the assignment at a given point in the hierarchy (unless it was put there on Win 10 PL5 where it will remain alone").
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.
1 Like
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.
1 Like
@Musashi Before we move on can I clarify what I understand from the items mentioned, I was just starting to write this when @platypus made the following post.
or how do these points map onto the following;
-
The Pre-PL5.2.0 “animals”, “mammals”, “bear” and “black bear” versus the post PL5.2.0 (Win 10 numbering) of “black bear” in the ‘dc’ data fields. My “guess” would be this is covered by 1 in your list?
-
A selectable alternative to the Win 10 default option of just assigning the last (“leaf”) keyword when an hierarchical keyword has been input to allow all the keywords in the hierarchy to be assigned which produces a Capture One “alike” combination of ‘hr’ keyword combinations. This I have as item 2 in the list?
-
This presumes that the PL5.3.0 implementation of the original PL4 DOP strategy, but now with the greatly increased metadata payload, is retained intact with no change, e.g. to allow the user to select
1 - AS(OFF) and expect the metadata to come from the image (the pre PL5.3.0 only “option”) or
2 - AS(OFF) but expect the metadata to come from the DOP (since PL5.3.0 the only “option”)
i.e. effectively changing the priority for the source of metadata from the image metadata to the DOP metadata, regardless of the date/timestamps of either, when AS(OFF) - please see PL5.3.0 Re-instating the previous Features of PL5 with AS(OFF)?
-
No mention of the most important change, namely the preservation of the users meta data intact for export (at least) by preserving the input or providing an export option or whatever your designers provide that is superior to either of these two options.
Please do and sooner rather than later, its omission is just that - an omission, but thank you for acknowledging this issue.
In the meantime, I have realised (but not yet tested) that PL5 is probably “cheating” and assuming that any change in the image date/timestamps actually signals a change in metadata without actually testing for any specific change and then “raising the flag”, the ‘S’ icon. When a change is made to the metadata in PL5 that may or may not be a real change to the metadata but I see no reason why a change should not be assumed and the ‘S’ raised as an alert rather than leaving the user to remember what they did days or weeks before. we use computers for a reason - they are supposed to do the heavy lifting what is the use of a database that is not actually useful to the user as well as DxO!
- Thank you, this is essential (see below)
- The following leaves me confused as to exactly what you mean. Are you referring to the fact that “animals|mammals||bear|black bear” would have the following
‘dc’ = “animals”, “mammals”, “bear” and “black bear” or just “black bear” as discussed above
'hr" = “animals”, “mammals”, “bear”, “black bear” and “animals|mammals|bear|black bear” as a minimum
versus
'hr" = “animals” and “animals|mammals|bear|black bear” as a minimum
with additional keywords assigned, the ‘hr’ fields would contain additional components of hierarchical elements as a result of the assignments described in my 2 above.
While others suppliers may/may not do something does not make them right or wrong, if in discussions with more learned DxPL users than me it appears that including all the flattened keywords in the ‘hr’ fields is deemed “good”, the actual code to include them is “trivial” but many users might object so another option would be useful.
If DxO is “paranoid” about including options then consider what alternatives may be appropriate but please don’t restrict the potential of the product because of a fear of making it “complicated” that is what documentation and the forum is for, please don’t “spoil the ship for a ha’pworth (halfpenny’s worth) of tar”, i.e. cutting corners is ultimately a waste!
It has taken some of us a lot of effort to get this far, so much so that I will be greatly reducing the time I spend testing and dedicated to the forum going forward.
Does this mean that the selection UI behaviour will change?
The tree view
At the moment, selecting a leaf node, in the tree view, automatically selects the full hierarchy, but you can still deselect any of the parent nodes.
The keywords text field
At the moment, typing in a hierarchy such as Animal > Mammal > Bear > Black Bear only selects the Black Bear leaf node.
Are you planning on unifying that behaviour, so that both inputs do the same?
This cannot be a “preference” as, to omit all keywords mentioned in the hierarchies effectively disables searching in any other software that relies on the dc:subject tag.
This might sound fine but it limits which other DAMs can interact with images keyworded in PL.
Agreed they are not “up to date” but, still they form a strong, well-defined basis for universally communicable metadata.
Whether we use lr:HierarchicalSubject or mwg-kw:Keywords, which is a structure that contains any hierarchies, is irrelevant. The principle is that all keywords mentioned in any hierarchies (in either of those tags) should be flattened into dc:subject.
Not doing so means that it excludes any other DAM, that doesn’t use the lr:hierarchicalSubject tag as a basis for searching, can never be compatible with PL.
Please don’t do that. Several of us have spent a great deal of time and effort trying to work out why PL doesn’t play nicely with other software, going right back to the beta for PL5. So far it seems that the DxO stance is “we don’t care about compatibility, as long as it works within PL5”. If this really is the attitude, it is going to put off an awful lot of people from using the PL DAM if they already use an alternative. I, for one, will not be either using or recommending the PL5 DAM, as my own software is 100% reliable and compatible and I really don’t want PL5 messing up any of my metadata.
Speaking of not wanting PL5 to alter my keywords, even as a side effect of writing other metadata, Can we please have a means of totally disabling any PL5 influence on how keywords get written out to both original and exported files?
2 Likes
This is one of the strangest statements I have received on the subject of DAM since the PL5 beta. Many here have pointed out all the bugs and non-standard implementations very often over the last year.
I haven’t posted anything about it since the end of the beta, as I felt the topic was in good hands with Joanna and all the other contributors.
In the press, the introduction of the DAM was generally seen positively, even if some of the editors only tested superficially. But if nothing is improved, I can already predict that this will not reflect well on DXO.
Special thanks to all the members are spending a lot of time in testing, writing long articles and so on 
1 Like
The following is an attempt to Pseudo-Code the logic for creating the ‘dc’ and ‘hr’ keywords from the entries in the DxPL database @Joanna. It is pesudo Pseudo code, i.e. a made up version so that I can try to understand the logic behind using the database and populating the various fields.
The sad thing is how easy it is to vary the logic to accommodate the options rather than implementing a “one size fits all” that risks being a “one size that pleases no-one”!
Such a wasted opportunity @Musashi!
There is also at least one error in my comparison table for Capture One so I will attempt to check the entries but my Wife has Covid after a coach holiday last week and I am likely to go down with it sooner rather than later and increased brain fade will result (comments like “it can’t fade much more are not welcome” true or not)!?
This post should be allowed to continue, I think it has almost run its course but does not need to be closed @Musashi
Access 'Items'
*
** Locate any keywords for an 'Items' entry via the 'ItemsKeyword' structure
*
** A keyword can fall into one of the following categories:-
** A keyword found from 'ItemsKeywords', i.e. an assigned keyword
** which may be:-
** A simple keyword, designated by a 'ParentId' of NULL
** An hierarchical keyword, the "leaf" of an hierarchical keyword (which may be an element of a larger hierarchical keyword)
** and then via the 'Keywords' Table accessed using the 'KeywordId' from 'ItemsKeywords'
** An hierarchical keyword found by a 'ParentId' pointer from another keyword and containing a 'ParentId'
** An hierarchical keyword found by a 'ParentId' pointer from another keyword and containing a 'ParentId' = NULL - i.e. the head of the hierachical keyword
*
ACCESS 'ItemsKeywords' VIA the 'ItemId' value from 'Items'
*
** Start reconstructing any hierarchical keywords and populating the 'dc' and 'hr' fields appropriately
*
*
** P R O C E S S E A C H A S S I G N E D K E Y W O R D
*
*
FOR EACH entry in 'ItemsKeyword' associated with the 'ItemId' THEN
*
** Taking each ASSIGNED keyword in turn (currently EVERY item in 'ItemsKeywords')
*
** Locate the entry in the 'Keywords' Table
*
ACCESS 'Keywords' using the 'KeywordId' value from 'ItemsKeywords' (NOTFOUND = 'Unexpected ERROR')
*
** Determine keyword type by it's context, i.e. by the 'ParentId' setting etc.
*
IF 'ParentId' = 'NULL' THEN
*
** P R O C E S S A S I M P L E K E Y W O R D
*
ADD 'Value' from 'Keywords' TO 'dc Keywords'
*
** Consider whether it is correct to include that keyword in the 'hr' fields as DxPL and others do currently?
*
(Unconditional):
ADD 'Value' from 'Keywords' TO 'hr Keywords' <--------------------@Joanna
(end Unconditional)
ELSE
*
** 'ParentId' Not NULL so part of an hierarchical keyword (in this case the "leaf" keyword
*
** P R O C E S S A L E A F H I E R A R C H I C A L K E Y W O R D E L E M E N T
*
** Start a new hierarchical keyword reconstruction from last to first, e.g. |D
*
SET 'Hierachical Keyword' = 'Value' from 'Keywords'
ADD | TO front of 'Hierarchical keyword'
** This is the "leaf" keyword in the hierarchy, e.g. D in A|B|C|D (A>B>C>D) or an assigned sub-element hierarchy
** The leaf will arguably ALWAYS be considered for the 'dc' keywords even for DxO PL5.2.0 option
*
(Unconditional):
ADD 'Value' from 'Keywords' TO 'dc Keywords'
(end Unconditional)
[*
** Optionally add 'Value' from 'Keywords' to 'hr' Keywords'!? <------@Joanna
*
(Conditional):
ADD ''Value' from 'Keywords' TO 'hr Keywords'
(End-Conditional)]
*
** Using the 'ParentId' access the linked keyword in the 'Keywords' Table
*
FOR each entry in 'Keywords' Table found using the 'ParentId' from a 'Keywords' Table entry
ACCESS 'Keywords' VIA 'ParentId' of 'Keywords' Table entry
IF 'ParentId' = NULL Then
*
** This is the head keyword of the hierarchical keyword
*
** P R O C E S S H E A D O F A N H I E R A C H I C A L K E Y W O R D
*
** Add keyword to the front of a reconstruction of the hierarchical keyword from leaf to top, i.e. in front of the previous keyword
*
ADD 'Value' from 'Keywords' TO front of 'Hierarchical keyword'
*
** Reconstruction of hierarchical keyword is now complete and the head node should be added to the 'hr' keywords <-----@Joanna
*
(Unconditional):
ADD 'Hierarchical keyword' TO 'hr Keywords'
(end Unconditional)
*
* Optionally add the keyword to the 'dc' keys this is different between pre PL5.2.0 & post PL5.2.0
*
(Conditional):
ADD 'Value' from 'Keywords' TO 'dc Keywords'
(End Conditional)
*
** Add Keyword to 'hr Keywords', typically done with the head of an hierarchical keyword <------@Joanna
*
(Unconditional):
ADD 'Value' from 'Keywords' TO 'hr Keywords'
(end Unconditional)
ELSE
*
** This is an itermediate hierarchical keyword
*
** P R O C E S S I N T E R M E D I A T E H I E R A R C H I C A L K E Y W O R D
*
ADD 'Value' from 'Keywords' TO front of 'Hierarchical keyword'
ADD | TO front of 'Hierarchical keyword'
*
* Optionally add the keyword to the 'dc' keys - this is different between pre PL5.2.0 & post PL5.2.0
*
(Conditional):
ADD 'Value' from 'Keywords' TO 'dc Keys'
(End Conditional)
[*
** Add 'Value' from 'Keywords' to 'hr' Keywords', typically done with the head of an hierarchical keyword
** but not necessarily with other keywords
*
(Conditional):
ADD 'Value' from 'Keywords' TO 'hr Keywords' <------@Joanna
(end Conditional)]
END-IF
REPEAT-FOR UNTIL 'ParentId = NULL'
END-IF
REPEAT-FOR UNTIL 'NOTFOUND' IN 'ItemsKeywords'
*
** Arguably the 'dc' keywords & 'hr' keywords need duplicate entries resolved (de-duping), I believe <-------@Joanna
*
Wrong :- Pseudo code V02.txt (5.0 KB)
Hopefully better!?:- Pseudo code V03.txt (5.1 KB)
The [ ] are me being “over-enthusiastic” and including simple keyword elements where they are not required, i.e. keyword elements from an ‘hr’ keyword in the ‘hr’ fields when only the head of the hierarchy should be included but I included the places where that could be done and then enclosed the items with the […].
The biggest issue is all the packages (except Photo mechanic and non-hr aware products) include simple keywords in the ‘hr’ fields.
However, not doing that would mean that my Scenario 4 test, i.e. “animal”, “mammal”, “bear”, “animal|mammal|bear” input, would have the same keyword assignments as a simple "animal|mammal|bear’ input! @Joanna ?
The problem with the current DxPL handling of simple keywords, i.e. putting them into the ‘hr’ fields, is the result if the ‘dc’ entries are deleted by a non-hierarchical product (Zoner, ExifPro, ACDSee etc.) which will leave the (orphaned) ‘hr’ entries intact.
PL5 treats the remaining (orphaned) ‘hr’ entries as acceptable and will simply repopulate the ‘dc’ fields on output.
Now you see it, now you don’t, now you do again!
PS:-
The (Conditional): would be an IF <option - x > SET THEN … or IF <option - x > SET THEN …ELSE …END-IF but I wanted to keep the Pseudo code a little cleaner for review purposes.
The (Unconditional): could all be made (Conditional): but use internal option settings to control the behaviour!?
Errata: There was an error throughput V02, I used ‘KeywordId’ instead of ‘Value’ from ‘Keywords’ on every occasion - sorry!
Dear testers,
Thank you again for your deep involvement and feedback on this topic which is indeed a rare and valuable thing.
All these information has given us a deep insight into how this feature can be used and some specific and (let’s say “advanced”) needs.
We’re sorry that we cannot give an answer to all your questions for now and implement the suggested adaptations, but we’ll keep track of this and be assured they’ll serve as a strong basis for future improvements.
Currently, our main efforts are bent toward more problematic technical debts and issues, besides all the new features that we’re preparing and anticipating for major versions to come.
It’s always a difficult tradeoff between what we want to achieve, and what can humanly and technically be done.
We know that some implementations and decisions made in the past years can seem off to you now, but there were reasons for such tracks at that time, whether good or bad (and you also know that what becomes bad ideas at the end, always start as good and enthusiastic ones).
That’s also where the discussion with all of you are of great value and challenge us to make better product, improving the product part by part.
It’s a long process, that’s also why some features are not evolving as fast as we’d all like, and we’re already pleased to have answered a big chunk of your initial needs.
We’ll keep on working in that direction, so let’s keep the adventure going! 
Best regards,
Captain PO