Option to create Categories in @Keywords from Group Level elements

[Damit]

I would like to revive this feature request that cannot get any votes (likes) unless it is actually visible and not in the archive.  Please click on the link where Tveloso explains the request quite well.

https://www.photools.com/community/index.php/topic,8438.msg59256.html#msg59256

As Tveloso suggested, it would be great if we at least had an option to have the @keywords category reflect what we have in the Thesaurus as far as structure, where the group level keywords would be present for organizational purposes. I have read at least 3 other comments yearning for such a feature in the discussion forums. I find it very untiddy to have all the sub-elements of the group level keywords listed in the same level as parent keywords. It affects the way I use this program so much that I don't use group keywords just because I have the way they clutter up the @keywords panel.

I know Mario states that it will be a lot of work, but I really think it would be a great improvement to the program. Please "Like" this post to place a vote for this feature request.

[mosdubindi1]

I would support this FR. Group levels serve for organizational purposes in the thesaurus and doing this perfectly. However having no  Group levels visible in @Keywords, we are losing the opportunity to get the same organization in @Keywords category. 
And the bad thing is that there is no suitable workaround apart of Excluding in Flat Keywords, which is not good for another reason.

[Mario]

I know Mario states that it will be a lot of work, but I really think it would be a great improvement to the program. Please "Like" this post to place a vote for this feature request.

@Keywords is a data-driven category, built from the actual keywords in your files. Keywords added in IMatch, keywords added in other applications. It has now knowledge of your thesaurus.

@Keywords usually shows many keywords not in your thesaurus, unless you have worked very controlled and only added keywords actually in your thesaurus. There may be even group levels in @Keywords which are not in your thesaurus (from another application, for example)...

@Keywords is designed to reflect the actual hierarchical keywords in your files. Not somehow mix in virtual levels that only exist in the thesaurus but not in your files.

Implementing what is requested in this FR would involve a lot of work.
After loading keywords for all files in the database, @Keywords would have to lookup each unique keyword in the thesaurus, in order to figure out group levels. Then it would have to convert the missing group levels into separate child categories. From this moment on, @Keywords no longer represents the keywords in your files, but a mix of actual data and information gathered from the thesaurus.
Which has many consequences.
For example, every change you make in your thesaurus has to be re-applied by IMatch to @Keywords. Somehow.

And that's just the start. @Keywords would need to get new logic that makes the virtual thesaurus child categories special, e.g. not allowing users to assign files to them, prevent drag & drop, copy & paste, aliasing and whatnot. Even considering all the changes required will take several days. This stuff is complicated. And optimized to the hilt for performance and parallelism.

The idea of group levels in the thesaurus is to give you some additional organization feature for keywords inside the thesaurus. Group levels never become part of the keywords added to your files - which is the point.

The idea of @Keywords is to automatically organize your files by the actual keywords they contain.
Not to somehow mimic the thesaurus.

[hluxem]

I have only been using categories so far and just started using keywords for pictures I tag with animals. The reason I used categories before is that you don't have to write them back to files when you reorganize the structure. 

First, I thought this FR really makes sense. But after using the thesaurus and the @keyword category for a little bit, I'm with Tveloso.

Given that what I was requesting can be achieved simply by not setting Group Levels, I think I might just do that...(and also set those Levels to not map to the flat Keywords).

The question really becomes why would you not want to write back the full hierarchy to the hierarchical keyword?

Heiner 

[Damit]

I have only been using categories so far and just started using keywords for pictures I tag with animals. The reason I used categories before is that you don't have to write them back to files when you reorganize the structure.

First, I thought this FR really makes sense. But after using the thesaurus and the @keyword category for a little bit, I'm with Tveloso.

Given that what I was requesting can be achieved simply by not setting Group Levels, I think I might just do that...(and also set those Levels to not map to the flat Keywords).

The question really becomes why would you not want to write back the full hierarchy to the hierarchical keyword?

Heiner

As someone who tried the "exlude" option in the thesaurus, this would be a bad idea.  Mario may come in an explain, but when you reimport it can really screw up you whole keyword structure and cause a whole litany of problems.

The idea of group levels in the thesaurus is to give you some additional organization feature for keywords inside the thesaurus. Group levels never become part of the keywords added to your files - which is the point.

The idea of @Keywords is to automatically organize your files by the actual keywords they contain.
Not to somehow mimic the thesaurus.

From your manual, bold emphasis added: "The @Keywords category is a convenient way to work with keywords stored in the metadata of your files. In addition to the Keywords Panel and the Metadata Panel the @Keywords hierarchy allows you to add and remove keywords."

Basically I thought it was developed to help you edit and modify your keywords easily. To accomplish the above it would be much easier to work with these keywords in a format the at is organized and a hierarchy that reflects that which you see in the keyword panel and the thesaurus. By not displaying groups, even as place-markers that cannot be checked themselves, it would facilitate this process greatly.  Just because something is difficult, does not mean it is not worth the effort.

[Jingo]

Maybe I'm missing something - but I tend to do things that keep it all simple and this has worked for me at least for a long time.  Curious why others need more in @Keywords...

My workflow goes something like this:
  1 - Import images into IMatch
  2 - Use the KEYWORDS Panel to add keywords - this is done by:
          a) Searching for a keyword in the search box using typeahead to find keyword
          b) Using the thesaurus to find a keyword and checking it off to add
          c) Adding a NEW keyword by using the search box to do a partial type ahead (ie: bird) then arrow down and right arrow
              on (Animals|Bird) to add a new keyword (Yay! A new bird!!)
  3 - Write the keywords back to the Files (I like to ensure the metadata in the files are available to other software and galleries).

Every so often when I have added a new keyword, I rebuild my Thesaurus from the Keywords to ensure it has these new items for future keywording.

I'm curious why this type of workflow isn't sufficient for using keywords instead of categories in IMatch?  What does the "Top Level" of "WHAT" really offer in terms of keywording for my example (Animals|Bird|Great Blue Heron  vs  WHAT|Animals|Bird|Great Blue Heron)?  I can easily find with a simple search of Heron?

Thx - Andy.

[sinus]

...

I'm curious why this type of workflow isn't sufficient for using keywords instead of categories in IMatch?  What does the "Top Level" of "WHAT" really offer in terms of keywording for my example (Animals|Bird|Great Blue Heron  vs  WHAT|Animals|Bird|Great Blue Heron)?  I can easily find with a simple search of Heron?

Thx - Andy.

I am not sure, if I understand all this stuff completely.
And, Andy, yep, you can easily find with a simple search of Heron, I am sure.

I personally used Top Level keys only for one thing:
To not forget a step. For something else I see no sense for me.

I used to have 3-10 persons, who worked with me as photographers, secrectary and so on.
Most of them you had to explain step by step, what keywords they must put into a file.

I had a system (and have still), e.g. where we clicked on a keyword, how many people are on the photo.
Another, is it the whole person or only the face.
Then, in what kind of job is the photo, like  "management" or "worker" or "art" and so on.

It was easy to forget simply a step. 
Hence I created leaf keywords like 1, 2, 3 and so on and all of us had to add all numbers. 

Adding stuff to a photo is one thing. 
But you have to (if it is important) check also, if all is ok.
BTW, also small things, like using the first or second name for persons. 
Should we use plural or singular and so on. 

But I am completely with you: if you are sure, you have all relevant keys in the keys, then you will find the photo by simply search for one, two keys. 
If not, well, if you are alone, does it really matter? 

[Jingo]

Thx Markus - I'm just wondering what the benefits are and perhaps what I'm missing.  Being a lone wolf operator of my IMatch system makes things simpler of course - it is only me that needs to remember what to do... and, I try really hard to complete the entire process within a week of a photoshoot (importing, culling, editing, cataloging).. sometimes this works, sometimes this takes a bit longer or steps on a subsequent photo outing.

Enjoy the day!

[sinus]

...

I'm curious why this type of workflow isn't sufficient for using keywords instead of categories in IMatch?  What does the "Top Level" of "WHAT" really offer in terms of keywording for my example (Animals|Bird|Great Blue Heron  vs  WHAT|Animals|Bird|Great Blue Heron)?  I can easily find with a simple search of Heron?

Thx - Andy.

I am also not sure, at the moment. Times, that I really knew good this stuff, are quite a long time gone. 

If I remember correct, in your example

WHAT|Animals|Bird|Great Blue Heron  
Animals|Bird|Great Blue Heron 

WHAT was for me, that I or other persons did not forget this step (I used numbers instead of What and so on).
But I wanted not have WHAT in my flat keywords, hence I choosed preferences, that this level was not in the flat keys.

I mean, usually you would not search vor WHAT, I guess. 
Hence it is not really necessary.

I had e.g. also a lead key "color" with then some main colors like red, blue and so on.  
Here also, I want not color in my flat keys and choosed, that IMatch did not used this first level (I think, there is such option to choose). 

And btw, technical stuff made a lot of things obsolet, like colors and also persons are nowadays quite easy to fill with keywords. 
Hence the whole keywording and also locations and other metadata ... hmmm, who knows, what will photographer do in 10 years? I guess, they enter not more a long of thing, because a lot will be automated. Maybe also something for KI, I guess.

For me  most important is to find images. With help of keywords and other metadata and filenames, this is really not a problem, luckily. 


 

[Damit]

I'm curious why this type of workflow isn't sufficient for using keywords instead of categories in IMatch?  What does the "Top Level" of "WHAT" really offer in terms of keywording for my example (Animals|Bird|Great Blue Heron  vs  WHAT|Animals|Bird|Great Blue Heron)?  I can easily find with a simple search of Heron?

Well, the reason What is a keyword and not a group is solely from my use of IMatch and the inability to use groups in @Keywords.  "What" is really a group for organizing what things.  Animals, Birds are in the hierarchy so they can be written out to flat and pictures of Blue Herons will be found with a keyword search of Animals or Birds.  That is why I use a hierarchy, but I would like some level not to be written to flat.  Unfortunately, you cannot do that in IMatch because if you use the exclude option it will mess up your database on re-import. If I could see the groups in @Keywords they would be much more apt for organizing and moving because they would reflect the structure/hierarchy of your keywords and not make a mess of keywords listed in the top level when they may be 3-5 levels down. I could then covert organizing terms that really don't have to be written to flat from being keywords to groups.

[Mario]

Genera rule: there are n + 1 keywording schemas for n users

If you're a hobbyist, you can do everything you want. My suggestion is to keep it simple.
While group level keywords (on the top level only) may help organize keywords better in in the thesaurus, they are not added to the actual keyword in the file. And if they are not added to the actual keyword in the file, do you need them, really?

Using to-level WHAT, WHERE, WHO etc. keywords but not making them group levels ensures that what you see in the thesaurus are the keywords in the file, and @Keywords also matches what you see in the thesaurus and actual keywords.

I have hidden the exclude in flat keywords option behind the Expert Mode setting for the next release, after learning that a user has shot himself into the foot big time by not realizing what this option actually does or when it should be used.

Offering advanced features like group level keywords in the thesaurus is good, when they are used for what they are intended. The thesaurus help topic explains what these features do, when they might be useful, when not to use them etc. The rest is up to the user.

[Mario]

use of IMatch and the inability to use groups in @Keywords. 

That's not an inability, that's just how @Keywords is designed to work. Group level keywords in the thesaurus don't become part of the actual keywords in your files. You don't see them in the Keywords Panel. You don't see them in other applications. And you don't see them in @Keywords. That's the sole purpose of group level keywords. If you anticipated a different result, sorry.

[Damit]

I have hidden the exclude in flat keywords option behind the Expert Mode setting for the next release, after learning that a user has shot himself into the foot big time by not realizing what this option actually does or when it should be used.

That is a good idea! I already warned someone else not to use them on another thread. I don't think they realized the mess it would create either. BTW, when did you include that warning with the yellow exclamation point about the "exclude" option? I did not notice it until recently.

That's not an inability, that's just how @Keywords is designed to work. Group level keywords in the thesaurus don't become part of the actual keywords in your files. You don't see them in the Keywords Panel. You don't see them in other applications. And you don't see them in @Keywords. That's the sole purpose of group level keywords. If you anticipated a different result, sorry.

Please don't take offense. By inability I meant that I am not able to get IMatch to do it, not that there was a bug/defect/flaw in IMatch. I understand that you have conceptualized and implemented @Keywords to only show actual keywords, not groups, so I cannot get IMatch to show them. I now realize that is what I was doing when I tried to create the second @Keyword category previously, to try to get my own @Keyword category that actually displayed groups up and running. I still wonder if that is possible, to create a data driven category that displays keywords and groups. As a workaround I am just inputting keywords that I would like to be groups in all caps. I can then export them and reimport them to IMatch as text to convert them into groups using the import options rather easily in the future.

I really don't understand when you say you cannot see groups in the keyword panel when I see them in the Hierarchical Thesaurus section of the panel. I also see groups in all other programs I use.  They don't have an @Keywords category (which is why I purchase your program as well), but they do display and allow you to use groups to organize, which I thought was the main purpose of @Keywords. I did anticipate @Keywords to display groups, but no need to apologize. Obviously, you have the right to do what you want, and I am sure you have very good reasoning behind your decisions. I was just making a suggestion, echoing that which I have read from other on this board. I do find it curious that you did not pass judgement on this feature request previously, but this time around you seem much more opposed to it.

It is funny because I was actually going to feature request having the database reflect changes in the Thesaurus last year but did not after reading many posts by you, inferring to me that you wanted to keep them separate and that those changes should be done using the @Keyword panel. Luckily something must have changed your mind and you brought it into IMatch 2023, which is the only reason I upgraded. It is a marvelous feature that has brought great benefit to my workflow.