Please change the handling of hierarchical keywords

There are two possible core challenges (that I can think of) when using Hierarchical Keywords.

Outside influences.

The possibility that one's chosen Keyword Library is source externally and imported. There may be some sort of industry standard or standards that one has to comply with.

The possibility that whatever one is using the output files, at their destination, will not readily match whatever the destination application expects to see.

Internal influences.

Images might sometimes be shared between catalogues with logically very different purposes where each purpose would seem to benefit from a different Keyword Hierarchy order even if the individual keywords in the hierarchy were broadly the same. 

This might be a notable issue for a library of images that covered several years of images from different sources and varying keywording policies over the years. (But is not limited to that kind of challenge.)

Solutions for such conflicts might be technically complex and/or time consuming.

And then there is the advance of AI with facial recognition, object recognition, etc., and various levels of accuracy to contend with.

368074128197

I hope I have understood "Jedes ist gleich cat" translates as "Any equals cat".

Yes, you did. It's the German interface.

(removed) -> edit

The difference may be: I use the hierarchical keywords more in the way SFA described. ;) Means that I try to get all keywords I need with one entry. So that I can find any of these keywords if I want to.

But I cannot see why this usage should make such a difference...

Kind regards
Ernst

Edit: I just tried once more and found what you found too: hierarchical keywords contain (in Capture One) in every case the complete String with the complete hierarchy - and cannot be found in the way I described. *rats* as Charlie Brown would say.

Did you open a ticket?

Ah - that makes more sense!

😀

Ian

368074128197

. And I still don't know what you mean by "skin keywords" - could you explain?

Sorry my mistake - main keywords not "skin" :D

Cheers Robert

The simple way to isolate words from strings in a search is to add a space before the word, after the word or both. Note that this will work in the full search tool when the appropriate search operator (contains, does not contain, etc., is used.

Many full words (that someone is likely to use) are unique enough for them to be viable without this requirement, but some letter (or number) strings can be so common that they may be problematic at times.

In some cases it may be worth using two (or more) search parameters with the usage indicator being set to either AND (for example where two spellings two words need to be present for the search) or  OR, where either search term is correct and a should be selected.

The internal search tends to flatten any hierarchy and simply select based on what is found. Hierarchies created for different purposes or derived from different sources may not share exactly the same hierarchy levels or terminology.

Users need to decide whether they can work with the discrepancy by employing smart filtering or would prefer to re-work the keyword library to normalize the results.

Management of keyword libraries (with one eye on how keywords might be used by anyone working with exported images) is probably a little more onerous for catalogue users than for session users.

I agree there is a case for a tick box to permit case-insensitive searches but the concept of case sensitivity as a filter in its own right is important and should not be eliminated.

To my thinking the power of hierarchical keywords is not so much about a single hierarchy being a complete search solution but that using a single part of a hierarchy (to the right of the hierarchy structure in many languages, will auto-populate everything to the left of it. (Assuming that such a result is required. If not one needs the option to use the word isolation. Or even as part of a different hierarchy in order to also populate the metadata with the higher level keywords from both hierarchies if that is a requirement.

368681203358 - Apologies. I must have misunderstood you. And I still don't know what you mean by "skin keywords" - could you explain?

Ian

Thanks for the suggestion, 386192846717.

It doesn't get it right, though. 

I hope I have understood "Jedes ist gleich cat" translates as "Any equals cat". I actually have 408 images in the catalog with the keyword Animal>cat (some of which have further stages such as Animal>cat>sand cat). I also have 11 just with the keyword cat (from before I started using hierarchical keywords).

• If I search Keywords equals cat, I get no hits at all.
  
• If I search for Any equals cat I just get the 11 that are not hierarchical.
  
• If I search for Keywords contains cat, I get 998 images that include as you can see an oystercatcher, cats, caterpillars, and so on.
  
  
  

So I think your suggestion doesn't work with hierarchical keywords, and it only reliably finds keyworded images if you search for Any rather than Keywords

Ian

368074128197- Nobody says you should read out the database. I wrote it in response to 370130744837 message about how I do with the stars and color marks.
I think enough people have written why what Capture One does is wrong with keywords.
And that is just a small step. Only when this is implemented will it make sense to talk about other design errors. You can't see them all if you have a database with 10-20000 images. 

Cheers
Robert

368074128197

What I am most keen to have is better searching of the keywords. For example I would like to be able to search for "cat" without also finding images of cathedrals and caterpillars.

This function is implemented, I think:

This will find all "cat" for you, but no catapillar, catalog or other words with "cat" in.the string.

Kind regards
Ernst

If you have:

A > B > C

and

D > B > E

that is two keywords B that are different because they are in different branches, C1 makes a TOTAL MESS. A 'flattened' B appears and you can't tell whether is A > B or D > B.

If other DAM software applications don't flatten hierarchies there's a reason.

Not to say that resyncing metadata to other DAMs makes B to appear from nothing, and if you didn't have a B flat keyword it's because you didn't want it.

368681203358 - I'm not sure what you mean by skin keywords, nor why it is wrong. And I certainly don't want to have to do things like reading the database, adding values to XMP files, and so on. 

What I am most keen to have is better searching of the keywords. For example I would like to be able to search for "cat" without also finding images of cathedrals and caterpillars. So simple things like being able to search for whole words only and to match case to distinguish kite (the toy) from Kite (the word) would make my life a lot easier.

Ian

Which also means that I cannot set ratings or colours from C1. It's really, really annoying.

Unfortunately, that is true.
I therefore have a different procedure, which is unfortunately also somewhat more complicated. C1 cannot modify the metadata. I set ratings and color markings in C1. Then I close the application and use my own script to read the database and write the appropriate values into the XMP files using ExifTool. Then I start C1 and read in the metadata for the affected images again. It is a longer process but the metadata (XMP) remains clean

and I want to be able to find the photo if I search for Red Kite, or for bird of prey.

This is absolutely no problem with the procedure I have described.
The way C1 writes it now, there are 3 skin keywords in your structure, which is wrong. It's still just "red kite"

Robert

I'm not sure about that. If I have a photograph of a Red Kite, for instance, I will keyword it as 

bird>bird of prey>Red Kite

and I want to be able to find the photo if I search for Red Kite, or for bird of prey.

Ian

I second this request (I've posted something about that years ago, before this forum section existed). It's not only a problem of performance, but of mess. If the keyword is A->B->C, the only keyword that should be associated is C. This is how other applications work (e.g. PhotoSupreme, but also LightRoom a few years ago). The point is that because of this behaviour I can't export XMP from C1, otherwise the keyword set get polluted. Which also means that I cannot set ratings or colours from C1. It's really, really annoying.

„The result was that they agreed to it, but due to limited resources they were not able to implement it.“

Same here some years ago. „Not possible because of limited ressources …“

Kind regards Ernst

The problem is the complete DAM structure. In modern development, one then goes one small step to the next. Each of these steps may bring very small improvement at first, but there is no other way. I had already analyzed many things together with Microsoft years ago and passed them on to Capture One (Phase One). The result was that they agreed to it, but due to limited resources they were not able to implement it. So it goes to cut the whole thing in kline slices. Development just has to want it and get serious about it.

Robert

I don't use catalogs and my sessions do not offer any sort of heavy numbers of records requiring KW complexity index maintenance ... but once established there does not seem to be any performance degradation.

I am not yet convinced that assumption of perceived performance degradation can always be connected to single factors or user observations - though I would very much like to accept user observations as absolute fact!

There is a case for testing and assessment by the development team  - and publication of the results and recommendations.

User tester results could be valuable in such situations - and would be more useful if they were the results of some pre-developed and published test plan OR some sort of avoidance of that plan in comparative testing.

his would significant improve C1 DAM speed 

Maybe.

Why not?

The low hanging fruits for performance improvements have alread been harvested. I don't see much appetite on C1 side to really care about major performance improvements which would probably require some sort of refactoring, too costly at the current assumed company state of harvesting money from the market. I wish you were right though.

| maybe compatibility with a specific other Adobe product

Nope. Adobe uses

  <lightroom:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>MLevel1|Level2|Level3</rdf:li>
    </rdf:Bag>
   </lightroom:hierarchicalSubject>

nothing else.

| I believe neither C1

Why not? I believe, this would significant improve C1 DAM speed and we are in "Improve Capture One Pro" section :D

In addition, the XMP files are unnecessarily inflated. 

In my tests with Photomechanic Plus as a catalog application in combination with C1, when syncronizing metadata and hierarchical keywords via xmp files from C1 to PM+ I noticed this too, and it created a keyword mess in PM+.

But there is probably a reason why C1 does it this way, maybe compatibility with a specific other Adobe product, as they have these redundant information in the tag

   <lightroom:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>Level1</rdf:li>
     <rdf:li>Level1|Level2</rdf:li>
     <rdf:li>MLevel1|Level2|Level3</rdf:li>
    </rdf:Bag>
   </lightroom:hierarchicalSubject>

I believe neither C1 nor PM will change here anything, so syncing hierarchical keywords from C1 to PM+ is not a good idea, which is a pity as the keyword tool in C1 is much better than in PM+ (for my taste).