Some qualifiers in Wikidata are non-discriminatory and new statements added by OpenRefine should be merged into existing ones with the same value

[VojtechDostal]

Whenever OpenRefine tries to import a statement into an item but sees an existing statement of the same property and with the same value, it will merge the statements together, leading to eg. one statement with two references. Situation changes when OpenRefine sees the same value, but qualified with a qualifier. It will then create a new statement, because qualifiers are usually discriminatory - they specify the circumstances under which a statement is true.

However, some Wikidata qualifiers are non-discriminatory, they merely specify some aspects of the value itself. For example, reason for preferred rank (https://www.wikidata.org/wiki/Property:P7452) or reason for deprecation (https://www.wikidata.org/wiki/Property:P2241). These should be always kept but new statements with the same value should be imported into them.

Example of erroneous behaviour:
https://www.wikidata.org/w/index.php?title=Q2634996&type=revision&diff=1486438858&oldid=1465342427
Fixed like this: https://www.wikidata.org/w/index.php?title=Q2634996&type=revision&diff=1489850300&oldid=1487541248

[wetneb]

I am classifying this as an enhancement request, because the current logic works as expected, although I totally agree with you that a more granular control of the merging strategy would be extremely useful for a lot of imports.
See this related issue (duplicate?): #2116

[thadguidry]

In Wikidata we have the following2 subclasses that could be used to sub-categorize ? :

• non-restrictive qualifier
• restrictive qualifier

Although I am not 100% sure of who/what maintains the members within each of those above subclasses.
There might be a need to further review the members within this subclass as well:

• Wikidata property used as "depicts" (P180) qualifier on Commons

Getting consensus might be worrisome for a few that are not already members of any one of the restrictive/non-restrictive qualifier subclasses, but still probably approachable.

[wetneb]

This should be in the forthcoming release (3.6). In the meantime, feel free to use our snapshot releases to try it out and tell us if you see ways to improve it.