008 bytes, 385 and 521 map into bf:intendedAudience, although the way this is implemented the only 385 $a, $b values that are supported are the ones listed in the BKS 008/22, which map to codes in ID, which maps back into an 008 byte.
https://id.loc.gov/vocabulary/maudience
Terms/codes that don't exist, such as 385 $aAgriculturalists$2lcsh, the way that m2bf2 deals with this is it dumps the $2, doesn't match to the id vocab so when it roundtrips back into MARC it turns into a 521 note, no $2 source.
A fix is to just copy the $2 logic from the 65x subjects so source.Source.code or source.Source.about{scheme uri} or source.resource{scheme uri}. 385 w/o a $2 would convert into 521 notes. In WC there are 2.1k distinct 385$a values and 31 distinct 385$2 values but mostly the same concepts in different languages.
I haven't analyzed $m$n but those don't look like they would be affected....
008 bytes, 385 and 521 map into bf:intendedAudience, although the way this is implemented the only 385 $a, $b values that are supported are the ones listed in the BKS 008/22, which map to codes in ID, which maps back into an 008 byte. https://id.loc.gov/vocabulary/maudience
Terms/codes that don't exist, such as 385 $aAgriculturalists$2lcsh, the way that m2bf2 deals with this is it dumps the $2, doesn't match to the id vocab so when it roundtrips back into MARC it turns into a 521 note, no $2 source.
A fix is to just copy the $2 logic from the 65x subjects so source.Source.code or source.Source.about{scheme uri} or source.resource{scheme uri}. 385 w/o a $2 would convert into 521 notes. In WC there are 2.1k distinct 385$a values and 31 distinct 385$2 values but mostly the same concepts in different languages.
I haven't analyzed $m$n but those don't look like they would be affected....