Well, I’m not the only one to read it that way…
PL has absolutely no explicit support for working with categories, apart from IPTC - unless you can show me otherwise. From what you are saying, it is assumed by not checking the top level.
That’s fine. I read the document directly. They address what should happen when categories aren’t supported. While they opt to skip providing a specific solution for categories, they suggest how a system that supports categories should work.
Here’s the section again, with some highlighting.
Categories
The perceived motivation for categories is to have nodes in the hierarchy that serve only to help organize the keywords. The applications that support categories (Adobe Lightroom and Photo Mechanic) do so by allowing any node to be called a category instead of a normal keyword. For example, “States” might be called a category. In that case, searching for “States” might not be allowed and metadata embedded in a file might only mention “Places” and “Wyoming”, leaving out “States”.
Note: This MWG guidance will not provide a specific solution for categories, as it seems not worth the effort to introduce this level of complexity for the consumer.
If you mean that PL doesn’t use the word “categories”, then I might agree although I haven’t read all their documentation and don’t know how they might describe this feature.
However, the MWG document defines what they mean by categories and PL provides explicit support for categories as defined by the MGW. I bolded it in context, but I’ll walk you through it.
The MGW defines a “category” to be a node in the hierarchy whose purpose is only to help organize keywords. This is not restricted to the “top level”—any parent keyword can be a category. In PL, you indicate that a parent keyword is a category by not checking the checkbox next to it when a image or set of images is selected.
The way you can tell that PL supports categories as defined by the MGW is by seeing if the functionality of an unchecked parent keyword matches the behavior stated in the MGW: If “States” is called a category (if it is a parent keyword with its checkbox unchecked), then searching for “States” might not be allowed and metadata embedded in a file might only mention “Places” and “Wyoming”, leaving out “States”.
To verify that PL supports categories, create the hierarchy Places > States > Wyoming. For a given image, place checkmarks next to Places and Wyoming, but not States. A search for “States” in PL will not turn up this image.
Next, let’s check what metadata gets written since the MGW describes what is allowed to happen. In PL, to fully comply with the MGW, the “write hierarchies to the dc:subject tag” option should be disabled.
Export the metadata to the XMP file. The dc:subject tags should include only Places and Wyoming as described by the MGW. Tools such as Spotlight will not find the image on a search for “States”, as expected. Any user who chooses to uncheck the checkbox next to States is requesting this behavior. Including States in dc:subject would be an error.
Should you enable the option to write the hierarchies to the dc:subject tag, then you will be able to search for “States” in Spotlight. However, anyone who unchecks parent keywords and enables the option is confused about what they want: they can’t find images tagged with the keyword in PL, but they could find those images with an external search that relies on the dc:subject tag.
Personally, I think a better system would be one where you choose to enable support for categories rather than tell PL what should be written to the dc:subject tag. If enabled, you could uncheck parent keywords and the dc:subject tag would only get the keywords that are checked. If disabled, parent keywords would always be checked and you wouldn’t be able to uncheck them. The dc:subject tag would always get all parent keywords because they are always checked.
A problem with categories as implemented by PL and others, and a problem with the keywording system overall, is that it is a per-file system. Logically, a category should be a global setting for a keyword. However, one image can say that States is a category and the next might say otherwise. There is no mechanism to enforce consistency—this is entirely the user’s burden.
Don’t get me wrong: I’m not a fan of categories. But PL does support categories as defined by the MGW and they operate as the MGW suggests.
And there is the problem. You are trying create a workaround for something that PL doesn’t support. That might work for you but, for everybody else, it is a totally undocumented and, without your workaround, totally unsupported “feature”.
If I take the same naming standard that is found in some of the available keyword lists (like Lightroom’s), then PL shows it like this…
The problem is that the entire indexing and search mechanisms would have to be reworked.
And, in any case, to re-quote the MWG guidance…
Note: This MWG guidance will not provide a specific solution for categories, as it seems not worth the effort to introduce this level of complexity for the consumer.
So, the MWG don’t consider categories worth including in their document and only a limited list of DAMs implement them. They are by no means a “standard”. And they state the same for synonyms.
Only if you follow your own workaround. This should be automatic, not just for those who have read your posts.
This does not prove that PL supports categories, simply that you can limit the parts of a hierarchy that will be recorded.
If we are talking about selecting keywords to include in searches or not, don’t forget the new lr:weightedFlatSubject which only contains the leaf keyword in any hierarchy. PL doesn’t officially support that tag either but you can certainly use your workaround to emulate it.
I’m sorry but, until you can show me where this is covered in the documentation, then it remains that PL supports categories only if you follow your ideas.
The most important consideration in all this discussion has to be cross-DAM compatibility. Writing all keywords from all hierarchies ensures this and PL supports it.
On the other hand, PL’s search doesn’t even support ORing of multiple predicates, something that is far more important in the order of things that need fixing.
Finally, the MWG guidance is fairly explicit when it says…
A Changer …
- MUST write the XMP dc:subject property to store the individual keywords. Hierarchical path elements MUST be flattened, which means that each hierarchy node needs to be stored as a separate keyword entry to XMP dc:subject.
Words are just combinations of characters to which we assign meaning. The MGW document could just as well have used the word “AUDKWBNE” for what they termed “Category”. PL could be said to implement “AUDKWBNE” if “AUDKWBNE” functions as the MGW document describes. Software tools love to change the names they use for certain functionality. I don’t really care what PL calls it or even if they’ve bothered to call it anything.
Here is a screenshot from PL:
Here’s what PL writes to dc:subject in the XMP file:
<dc:subject>
<rdf:Bag>
<rdf:li>A</rdf:li>
<rdf:li>C</rdf:li>
</rdf:Bag>
</dc:subject>
Here’s what Adobe Bridge displays when I select the same image:
I then change it to this in Adobe Bridge:
Adobe Bridge writes:
<dc:subject>
<rdf:Bag>
<rdf:li>C</rdf:li>
</rdf:Bag>
</dc:subject>
And PL now displays:
I don’t know what PL calls this feature or what Adobe Bridge calls its. Both programs appear to be implementing the functionality that the MGW document describes as “AUDKWBNE” … err, “Categories”.
This is irrelevant. They say they aren’t going to bother, but for the programs who do, they describe what the feature would look like.
The statement “Only if you follow your own workaround” makes no sense. If you read exactly what I wrote, I am just describing how PL works. You are reading things into the statement that I didn’t say.
It sounds like you think I said something about PL automatically maintaining parent checkmarks, which I didn’t say. You say “This should be automatic”—which I agree with and having even written a feature request on that topic—and add “not just for those who have read your posts,” which again makes no sense. Reading my posts is not going to make PL automatically assign parent keywords.
And then they make an exception for programs that choose to implement “Categories”. Unlike you, when I refer to the document, I’ve posted both sections, not just the one I like.
We’re not going to see eye-to-eye on this. You believe that PL violates the MGW document; I don’t. But that is my sole point. Don’t conclude from that that I like Categories or that I approve of PL’s implementation.
Not strictly true. You are describing how “you” can make PL implement something it doesn’t officially support. Just because it walks like a duck and quacks like a duck, doesn’t necessarily mean it is a duck.
Except they don’t make an exception. They explicitly state that they will not discuss its implementation in the context of this document.
In fact, categories should only truly be visible as part of the keyword choosing process, so that you can find keywords in a given category easier, just as synonyms allow for referred lookup of alternative words. There is nothing that insists on recording either in the XMP of a file.
In the end, I have written my own DAM, which doesn’t bother with categories, is compatible with all other DAMs in both writing and searching. It also allows me to load alternative dictionaries for those who want lists that are tailored to their speciality.
Diagree.
Read it however you like. I disagree. In the end, it doesn’t matter. The MGW document is 14 years old and the organization doesn’t have a working web site. Things change, and time moves on.
You aren’t the person who gets to decide how categories work. The MGW document says the opposite:
In that case, searching for “States” might not be allowed and metadata embedded in a file might only mention “Places” and “Wyoming”, leaving out “States”.
Software programs can do whatever they want. As I said, it’s not clear anyone is concerned about following the MGW guidelines.
Your claim of compatibility with “all other DAMs” is hyperbole. I could write a DAM that you would not be compatible with. Its not clear if your tool is even compatible with PL or Adobe Bridge, but this forum is about Photolab, not about your tool.
Sorry, I’m done. Feel free to reply if you want to have the last word.