If you want to replace “multi value” with this, then “at least”/“at most” is necessary, it seems to me. But we already have properties for those: “minimum quantity”/“maximum quantity”, used for “range” and “difference within range” (including semantics for half-open ranges, which “multi value” is). So I think using those would be very natural, and we wouldn’t even have to create a new “count” property.

(Under the hood, both SingleValueChecker and MultiValueChecker already use a ValueCountHelper and then check the count, so this would be very easy to implement.)

Note: even if we do remove the “single value” and “multi value” constraint types, we should keep the messages and use them if the allowed range is [1, 1] or [2, ∞), which will probably still be the most common cases.

Even if a property is generally likely to have several values, we still need to find a good way to accommodate multiple values based on different references.

Another usecase to cover could be: "value required constraint": for many political offices, we require P106=politician, but frequently a second occupation should be indicated. (some countries expect their politicians to work otherwise as well).

@Esc3300 I’m not sure what you mean –isn’t that “item requires claim” / “value requires claim”?

I would prefer to keep the existing single value constraint because it's a very common constraint and replacing it wouldn't have any benefits for users (or would it?).

Being able to specify how many values a multi-value constraint should have sounds perfectly reasonable, although looking at the backlinks, it's not used very much. Are there any current places we would use it?

In T172134#3488911, @Lucas_Werkmeister_WMDE wrote:

@Esc3300 I’m not sure what you mean –isn’t that “item requires claim” / “value requires claim”?

This has currently a constraint for P 106=politician, but maybe we should have a 2nd value in P 106 for items with that property.