Exact numbers can occur not only through counting, but also through definition. For example, as explained by the US National Geodetic Survey, one yard is defined as exactly 0.914 4 meter. One could imagine properties in Wikidata where most of the instances are measured, and have an associated uncertainty, but a few instances are defined, and so are exact. So unless it can be proven that a certain property is always uncertain, or always exact, the property should be designed to accept either the proposed number type, or QuantityValue.

If it isn't possible or practical to make properties take either kind of number, I don't see any choice but to use QuantityValue with amount = lowerBound = upperBound.

@Jc3s5h Quantity values would continue to work as they do now: they would allow exact as well as uncertain values. The new Number type would be more restrictive. Whether Number values (counts) should always be considered exact, or only be considered exact by default, remains to be decided. But for the use case you mention (values that derive from definitions - like yards in meter, miles in kilometers , but also the speed of light in m/s, which is exact per the definition of meter) we need non-integer values, and would use Quantity values with +/-0.

Is it a duplicate of T72341: [Story] Create a new datatype "count" similar to "quantity".?

Yes. Thanks.

See also https://www.wikidata.org/?diff=356831116&oldid=356821963.

I wonder what the complexity of this is -- without being able to read the code.

If it's a simplification of existing code, it might be an interesting volunteer project.

If you announce it now as an upcoming change, it might even be possible to implement it in a fairly short period of time.

Query Service has xsd:integer for these and converting just impacts performance.

With the new behavior of the Quantity type, the difference to Number would still be:

• positive integers only
• no unit (no "dog" as unit for a dog team size)
• default (or force?) to +/- 0 (don't use +/-0 with population numbers!)

As Esc3300 correctly noted, this would allow optimization for the RDF representation:

• we can use xsd:integer instead of xsd:decimal for the literal type
• if we do not allow any precision other than +/-0, we need no "complex value" nodes to represent the value in RDF. A single literal would be sufficient.

Note however that these optimizations are only possible if we introduced a new value type for numbers (different structure), not just a new data type (different interpretation). Changing the structure in JSON and RDF would be a breaking change, and transitioning existing values present in the database would be challenging.