This indicates three standalone keywords with no hierarchical relationship and should produce…
<dc:subject>
<rdf:Bag>
<rdf:li>animal</rdf:li>
<rdf:li>mammal</rdf:li>
<rdf:li>bear</rdf:li>
</rdf:Bag>
</dc:subject>
This either indicates one keyword animal|mammal|bear
or it can indicate an implicit hierarchy, depending on the software. I have seen it wrongly interpreted as…
<dc:subject>
<rdf:Bag>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which is horrendously wrong in so many ways. Or 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|mammal|bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which can be acceptable but doesn’t fully transmit the nature of the hierarchy for the upper nodes.
… suffers from the same problem of possible differing interpretations as found in Photo 2, just with another level.
This is simply a mess and a disaster waiting to happen. Essentially, the “natural” way to interpret this would be…
<dc:subject>
<rdf:Bag>
<rdf:li>animal</rdf:li>
<rdf:li>mammal</rdf:li>
<rdf:li>bear</rdf:li>
<rdf:li>animal|mammal|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>
… that assumes that animal|mammal|bear
is a standalone keyword that just happens to contain pipe symbols. I presume the inclusion of the “combined” keyword is an attempt to convey hierarchical structure within the confines of the dc:subject
tag - something which should be a definite no-no.
The big problem with allowing all these non-standard variations to be entered in an app is that it is then up to each app to decide how to write them to the file’s metadata. Which subsequently means that every other app has to know about all possible variants and take an “educated” guess as to which one was intended.
On the other hand, if all DAM writers not only properly adhered to MWG standards but enforced them at the point of entry, we wouldn’t be in the par-less mess we find ourselves in today.
At which point I am going to blow my own trumpet again in stating that my app (unfortunately Mac only) does adhere to those standards and I haven’t yet found another app that misinterprets the metadata I write.
The key to the integrity that my app ensures is that the management of keywords and the construction of hierarchies is taken care of in a separate “Keyword Manager” popup window, which provides the only means of constructing hierarchies, it being impossible to imply a hierarchy just by entering a delimited list of words in the keywords entry field. The keywords entry field provides a chooser, populated from the dictionary that is managed by the Keyword Manager, so that it is more difficult to mis-spell a word or choose one from the wrong hierarchy. This dictionary is then used in the construction of the metadata that gets written into the XMP.
What DxO have done is to try and emulate other software in putting both keyword assignment and organisation in an impossibly small tool palette - something which can actively dissuade folks from properly organising a “dictionary” or “thesaurus” in the first place. Have you tried dragging a keyword to be a child of another?
Then you have the problem of being forced to see multiple versions of the same keyword in the entry field if you happen to need the same keyword from more than one hierarchy, with the only way of determining which is which being to hover over the tokens in anticipation of a tooltip to elucidate.
And, in closing this overly long post, we still haven’t got to the limitations the current DxO hierarchical structures place on any chance of a search that can do more than simple AND conditions - but I’ll leave that for another rant