Variables: metadata field trigger another field & fill it with a different value

[jma]

I'm wondering if there is a way to fill a metadata field based upon the value or condition of another metadata field.  And if so, what that syntax might look like.

For purposes of this example, we can use the COUNTRY field {File.MD.Composite\MWG-Country\Country\0} and COUNTRY CODE field {File.MD.XMP::iptcCore\CountryCode\CountryCode\0}

Rather than simply copying the contents from one field to another, I'm wondering when the value in {File.MD.Composite\MWG-Country\Country\0} is "USA", could it then trigger the Country Code metadata field ({File.MD.XMP::iptcCore\CountryCode\CountryCode\0} to be filled with the corresponding ISO code for the USA (which is "840")?

To add one further twist and using the same example, would it be possible to set an additional condition such as having multiple countries (USA, Germany, France...) referenced to their respective ISO/Country Codes (840, 276, 250...)?  Sort of a "look-up table", I guess?

Any thoughts and suggestions are greatly appreciated.

--John

[Mario]

Note: The tag {File.MD.XMP::iptcCore\CountryCode\CountryCode\0} takes a 3-letter country code like USA or DEU, based on the ISO standard 3166. Not a country code number!
There are no checks in IMatch, but when you use numbers, other applications may fail to process the tag.
I would not do this.

You could do a) easily with a Metadata Templates
1. Use the ISO tag as the target.
2. Use a variable like:

Code Select Expand

{File.MD.country|is:USA,840,{File.MD.XMP::iptcCore\CountryCode\CountryCode\0}}This variable checks if county has the value USA and in that case returns 840, else the existing country code.
This way you replace the existing country code tag value only when the country name is USA.

[jma]

Thank you , Mario.

Would there be a way to apply a series (or sequence) of these "variable checks" in order to determine 1) if "USA" return "840" --if not  go to step 2) if "DEU" return "276" --if not go to step 3) if "FRA" return "250"... and so on?

[Mario]

No, such complex nested decision logic would be really hard to implement in variables.
This is more something you would to in an IMatch app or a script. IMatch has a full-fledged REST API, allowing users to write IMatch apps and to access IMatch databases from any modern programming language. See IMatch Developer Center for more info.

But I think the new AutoFill feature I will introduce in IMatch will work nicely for you.
See this community thread and watch the short video to see what it does.

[jma]

Mario: I checked out the video you mentioned and I believe that the new feature you are proposing would be of great use to me (and others I'm sure).   I'll look forward to testing it when it's released.

Thanks as always for your thoughtful responses.

--John

[PandDLong]

I was looking to do something similar and found an approach that should work (with a couple of assumptions):

1. Create your lookup table as a list.  Using your example: "USA840;DEU276;FRA250 ..."

2. You need to get your list loaded into a repeatable tag that isn't used for anything else  (my go to are the Custom x tags in the PLUS XMP group - I assumed "custom 1" below).

3. Assuming this need is universal (or almost) - I would load the tag through the Metadata Template that is run when a file is indexed by iMatch

4. Fill your country code through use of the lookup table in a metadata template - the variable to populate Country Code would be:
{File.MD.PLUS::XMP\Custom1\Custom1\0|foreach:{value|substr:0,3;is:{File.MD.Composite\MWG-Country\Country\0},{value|substr:3,3},}}

5. You could then wipe that lookup table later in the template or leave it for future use should the Country change and you need to do a re-lookup.

The workflow around loading the lookup table into a tag, using it and then wiping/preserving would need to be tuned to your needs but use of the lookup table loaded in a repeatable tag should work. There may be variations on this idea that work as well and may work better for you - particularly if the assumption of 3 letter country abbreviations and 3 digit codes is not true.


Michael