Is propogating keywords additive or does it replace the info of the verson?

[Damit]

If you designate keywords to be propagated from a master to a version, would the keywords that previously were assigned to the file be replaced, with those not existing in the master removed from the version, or does this process only add the keywords from the master to the version, leaving keywords that do not reside in the same fields existing (which I hope is the case)?

Also, I am not seeing @keywords or @builder in the lists of categories I can select when propagating categories. Any ideas why this may be happening?

I assume that using categories, specifically @keywords, would allow a more granular selection of keywords to be propagated between versions, where once the @keyword category is propagated, the keyword would be added to the version, as well, during write-back, correct?

[Mario]

Also, I am not seeing @keywords or @builder in the lists of categories I can select when propagating categories. Any ideas why this may be happening?

That's just logical.
@Keywords is build dynamically from the keywords in your files, right?
And @Builder contains a temporary result from you combining multiple categories via Boolean logic.
Propagating them makes just no sense.
After propagation your versions will show up in the corresponding @Keywords categories automatically, based on the keywords they have received from their master file.

Propagating always copies the data from the master to the versions. No merging/mixing/propagating individual keywords. Else it would be documented in the help: File Relations: Versioning
Propagation is complex enough as it is, without giving users control over individual keywords to propagate.
You can so some of this using the propagation enhancements in IMatch 2023 I have just explained the other day.

As a general assumption: if it is not documented/explained in the help, it does not exist or work.

[Damit]

That's just logical.
@Keywords is build dynamically from the keywords in your files, right?
And @Builder contains a temporary result from you combining multiple categories via Boolean logic.
Propagating them makes just no sense.

Thank you for clarifying but it is a bit confusing because in your examples found here File Relations: Versioning Help, you display both @Keywords & @builder as categories that could be propagated. Has this changed? I do think that it would be a good addition to allow people to be more granular with their Keyword choices, but I am already devising ways to work around this "limitation." I will check out your link to new features, I do try to read the forum on at least a weekly basis to keep myself informed.

Propagating always copies the data from the master to the versions. No merging/mixing/propagating individual keywords. Else it would be documented in the help: File Relations: Versioning

Thanks! However, lets say you are propagating an XMP value already populated in the version, such as title or creator?  I assume, based on your previous answer on keywords, that the value from the master would replace that in the version?

It seems as where the field is blank, IMatch would just add the value, correct?

But what if a value already exists, does IMatch do the same, just overwrite the previous value of the version? As far as keywords, to make sure I understand correctly, the keywords of the Master will replace those that previously existed in the version? That would be problematic because the version may have keywords that apply just to it, such as an edit that was converted to Black & White from color. The master would have the keyword color and the version should have B&W and Monotone. This is one instance where I have not found a workaround. If the keywords are replaced, then the B&W image would be stripped of that designation and it would be replaced by "color."

Propagation is complex enough as it is, without giving users control over individual keywords to propagate.
You can so some of this using the propagation enhancements in IMatch 2023 I have just explained the other day.

Thanks for the link.  The OP is describing exactly the circumstance I am toiling over. In fact, I would assume that the "editing information and technique used" information would be housed in keywords, so I believe moviemaker445 is requesting the same thing as I.

As a general assumption: if it is not documented/explained in the help, it does not exist or work.

Understood, but considering I may have missed something, as I often do, or perhaps the information is not where I would expect it, I ask just in case. There have been times I thought IMatch could not do something based on how I read the instructions only later to find out in another post I read that it, in fact, could. I always live by "assume as little as possible" mantra. Because you never know what you don't know.

[Mario]

I shall update the screen shot for the IMatch 2023 edition of the help, thanks.
I try to keep the help up-to-date, but there are almost 1,300 (!) screen shots in the help system and sometimes one slip's my attention when I change features in IMatch.

In the version where these screen shots were taken, @Keywords and @Builder were shown, but could not be enabled. This confused some users, which caused support tickets, which caused me to hide these categories and then I've forgot to update the screen shot. Can happen.

I assume, based on your previous answer on keywords, that the value from the master would replace that in the version?

Yes.
You can try that out in a few seconds yourself. Give your version a title different than the master, then write back the master. If you propagate the title, the version will receive the title from the master and it will show in the Metadata Panel.

It seems as where the field is blank, IMatch would just add the value, correct?

Not add. Set. Adding would mean to add to the existing values, but IMatch replaces them. No merging, combining, appending during propagation.

But what if a value already exists

See above.

If the keywords are replaced, then the B&W image would be stripped of that designation and it would be replaced by "color."

Yes. If you use keywords which are linked to a specific appearance or similar attributes of the version file, don't propagate keywords. Set them individually.

If you want different data in tag X for master and version, don't propagate tag X.

[Damit]

No worries about the outdated screen shot, but hopefully it explains my confusion. I am glad I could aid in pointing out outdated information.

Thanks for clarifying all above. You are right, I could have just tested it out. But sometimes I just want to confirm (though I must admit, I did not try it). Yes, I understand that I would not want to propagate the tag, I just feel that making keywords as a whole, a tag, even though it really is one, causes problems. If I could just omit one hierarchical branch of my keywords, specifically the How branch, all problems would be avoided. I believe I am not alone in this regard.

It is ambiguous if the feature from the thread you linked, that you are considering adding to 2023 will allow one to do just this. I am excited for the new version. The change in the Thesaurus functionality is a game changer, now if this was also added it would be amazing as well.

[Mario]

I have added two more choices to the list of metadata propagation items:

1. Don't copy XMP keywords
2. Merge XMP keywords

Both address XMP-dc:subject (flat keywords) and XMP-lr:hierarchicalSubject (hierarchical keywords).

A user can now do a simple "Copy ALL XMP Data" and then combine this with one of the new options. They are mutually exclusive, of course.

If "All XMP data" is combined with "Don't copy XMP keywords", the versions retain whatever keywords they have.
Similar to "Don't copy orientation" or "Don't copy Crop".

If "All XMP data" is combined with "Merge Keywords", keywords are copied from the master to versions but versions retain their keywords. Duplicates are automatically detected and trimmed.

This makes the whole propagation process even more flexible, making it easy to either maintain entirely separate sets of keywords for master and versions or adding 'extra' keywords to versions in addition to the keywords inherited from the master.