@Joanna sorry I forgot the essence of this topic, namely, selection or assignment I got the extra keys because I had selected/assigned “mammal” which automatically selected/assigned “animal” and as a consequence the more “rounded” hierarchical keys were created and the extra ‘dc’ keys along with them.
Removing the selection yielded
<dc:subject>
<rdf:Bag>
<rdf:li>bear</rdf:li>
</rdf:Bag>
</dc:subject>
<crd:CameraProfile>Camera Standard</crd:CameraProfile>
<crd:LookName/>
<exifEX:LensModel>OLYMPUS M.12-200mm F3.5-6.3</exifEX:LensModel>
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
A very slimline, non-compliant set of keywords!
@amikhnev I have real problems with this statement ““Animal” in that case is some sort of category that helps to find the required keyword.” I “hate” the fact that Photo Supreme appears to be “obsessed” with the notion of Category and inserts “Miscellaneous” as the first keyword as a “Category”.
Arguably every keyword in an hierarchy is a (sub-)category until you arrive at the final keyword and that may actually be another (sub-)category where you have just stopped with the granularity of the classification!
While I understand what you say and that could be the reason that the current search works the way that it works when an hierarchical keyword is added. But regardless of the selection/assignments made by the user an hierarchical key exists and will be placed into the ‘hr’ fields with all the keywords in place, including the keywords not marked as selected (assigned) by the user.
This selection will influence the presentation of the keywords in the UI including showing the selections already made, and the contents of the metadata that will be written back to the image (if “allowed”/forced by the user) and the metadata that will be placed in the exported file and, currently, the results of any search, the reason for this topic.
I am no metadata expert but if the keyword will inevitably find its way into the metadata because it has been explicitly assigned or because it is part of a larger hierarchical keyword and therefore implicitly assigned, I personally believe it should be found in a search otherwise the search is being selective and distorting (not) the truth!
However, the default for Win 10 (at least on my machine) is that only “black bear” will be assigned. If I then assign “bear” DxPL will the automatically assign all keywords in the hierarchy. In addition, if all have been de-selected then assigning “black bear” will actually assign all in the hierarchy automatically (which I believe if the default for the Mac version of the product)!?
So I tested the following by selecting and deselecting keywords (but my first attempt at inserting a table was crushed by the post software being used)!
animals X X X X
mammals X X - - X
bear X X X X - -
black bear X X X X - X X X
which should look like
and I exported for each option in the above table and the results are as follows for PL5.3.1:-
The same combinations for PL5.1.4 results in the following;
The problem is assignment will not only condition the response to a search (wrongly in my opinion because it should include implicit assignment as well as explicit assignment) but also the metadata (keywords) output to exported JPGs and available to be written back to the image metadata etc…
If the design of the ‘ItemsKeywords’ structure was ‘ItemId’, ‘KeywordId’ and ‘Assigned’ @Musashi instead of just ‘ItemId’ and ‘Keywordid’ then every ‘Keyword’ for an image (which are stored in the ‘Items’ table in the database) could then be entered into the ‘ItemsKeywords’ database table when they immediately become candidates for searching.
So we would go from 1 entry in the default case on Win 10 (for “black bear”) to 4 entries, one for each of the keywords with each of the entries for “animals”, “mammals” and “bear” having a ‘N’ or ‘0’ (or whatever) in the ‘Assigned’ field and the entry for “black bear” would have a ‘Y’ or ‘1’ (or whatever) in the assigned field.
The UI and the metadata insertion code would now use the ‘Assigned’ field rather than the physical presence of an entry in the ‘ItemsKeywords’ table to do their respective tasks.
But now a search would retrieve all the keywords associated with the image, both implicitly and explicitly assigned. If users wanted to retain the existing way of working there could be (at least) two ways of handling that:-
-
In the search return all keywords in the count field (and pointers to the images) and add an additional entry for those explicitly assigned (selected) in the line below.
-
Add an additional selection box in the search to return only assigned keywords.
But surely that is the job of any software that subsequently encounters the image, now or in the future.
Limiting the potential for future searches is “short-sighted”, it is the job of any software that encounters that image to offer the ability to allow you to search on “animals” (broad though that category may be) but give you the option to never put such a search into the software because that item is “merely” a category with way to many entries but that is where AND (and OR!?) searches come into play.
“Tailoring” keywords is a “slippery slope”, better to have too much data and software that allows you to navigate that, than to throw data away (once it has been removed it can never easily be replaced automatically - not entirely true because software with dictionaries etc. can find the missing data and restore it).
The problem with PL5, in my opinion, is that it currently restricts the search potential by virtue of the explicit assignment! There should be no such restriction, other than my “desire” to enter “animals” into a PL5 search or not, for both explicitly (currently available) and implicitly (currently missing) assigned keywords @sgospodarenko !