Open main menu

Property talk:P1107



to be used as a qualifier, value must be between 0 and 1
Descriptionused as a qualifier.
Representsproportion (Q2631509)
Data typeQuantity
Domainqualifier for properties, any time of item (note: this should be moved to the property statements)
Allowed valuesnumber between 0 and 1 (note: this should be moved to the property statements)
Allowed unitsnot applicable
According to this template: company X is 40 % owned by Y, Earth atmosphere is composed of 80% dinitrogen and 20% dioxygen
According to statements in the property:
mayonnaise (Q167893) → 0.7
When possible, data should only be stored as statements
Proposal discussionProposal discussion
Current uses5,264
  Range from “0” to “1”: values should be in the range from “0” to “1”. (Help)
List of this constraint violations: Database reports/Constraint violations/P1107#Range, hourly updated report
  Scope is as qualifiers (Q54828449): the property must be used by specified way only (Help)
List of this constraint violations: Database reports/Constraint violations/P1107#scope, hourly updated report
  Units: “novalue”: value unit must be one of listed. (Help)
List of this constraint violations: Database reports/Constraint violations/P1107#Units, hourly updated report

Property allows values from 0 to 1, constraint violation from “now” to “+∞”Edit

Why? I'm missing something?--Malore (talk) 09:34, 6 April 2018 (UTC)

Units constraint violation shows 0 violations, but they existsEdit

Materne Confilux (Q16663722) has a unit value of percentage (Q11229), but units constraint violations shows 0 violations. Why?--Malore (talk) 09:38, 6 April 2018 (UTC)


No value units is outdated, percentage (Q11229)) is routinely used as unit, app. one third of usage (see User:Laboramus/Units/P1107), I guess mostly in "ownership" properties like owned by (P127), owner of (P1830) or subsidiary (P355), where no unit handling is impractical. I think it is time to allow percentage (Q11229) as unit or split the property.--Jklamo (talk) 23:21, 21 December 2018 (UTC)

You can't allow any unit in this case, because the values can be in range 0–1. Using fraction instead of a percent is not impractical, it's just that people don't read documentation; changing percents to fractions is a primary school knowledge... This situation should be fixed using a bot or maybe {{Autofix}} could be used here? Wostr (talk) 23:38, 21 December 2018 (UTC)
The problem is that "percentage" unit implies a range from 0 to 100 for such ratio property, but the current ratio is restricted to allow only values between 0 and 1. The "percentage" is then misleading.
The other problem is that such "percentage" (or "%" alias) depends on a base (percentage of what?) which is not specified by the ratio alone. So this ratio property, even if it restricted to range 0 to 1 instead of 0 to 100, should neceassarily have an additional qualifier to specify this base, or "percentage" ("%") alone is not sufficient and we should then use another property than this unspecified "ratio" (P1107), such as "weigth ratio", "surface ratio", "volume ratio".
And another problem is that ratios are not necessary bounded to an interval (e.g. a "progress ratio" may be infinite, or negative).
Some ratios are not easy expressible as quotients but expressed traditionally using a logarithmic scale (typically in decibels, or in magnitude/bels) where its precision can be correctly specified (the precision is also logarithmic, and not linear like simple quotients).
My opinion is that P1107 is NOT a valid qualifier, but can only be used as a base virtual qualifier that MUST be derived: and each derivation can then specify its valid value range (not just 0 to 1). And the current range restriction on P1107 is also invalid and should be removed, migrated to derived properties usable as qualifiers. And P1107 should then be INVALID as a standalone qualifier (we'll then have to use derived properties based on P1107). The only applicable restriction for P1107 is that its given value must be numeric, or have some specific enumerated values like "unknown/undetermined" or "NaN" when its associated precision cannot be infered from the given numeric value.
Some ratios may also be set within an interval instead of a median value and a precision: we would need "min ratio" and "max ratio" instead, themselves also necessarily derived: as this would complicate the hierarchy of properties, I think it is just simpler to specify separate properties and require that P1107 must be used on an entity along with another property specifying the ratio base, and the ratio precision:
  • "ratio min" and "ratio max" would then be the only two derivations of this P1107,
  • an entity would be qualified either with P1107, or either with with "ratio min" and/or "ratio max" (a P1107 qualifier being normally incompatible with the two others for the same entity declaration),
  • and used preferably (mandatorily?) with a "ratio unit" (which correctly specifies the valid ranges accepted for the value given to P1107 or the other two "ratio min" and "ratio max" derived properties, and which gives a meaning to the precision given and on the method of computing the ratio: linear, logarithmic; possibly other methods like Gaussian or Poisson, based on some "average" metric, or metric computed on a 80%/20% probabily split, or on a predetermined number of samples for statistic estimations, and a "standard deviation").
  • Some "ratios" don't have precise values but are qualitative (e.g. observations of effects), such as magnitude scales: the unit is then based on a specific standard or method used to give an estimated scale (e.g. magnitudes for earthquakes, or storms, based on physical damages, or costs for emergency efforts or for recovery; or estimations of risks in financial applications, such as notation scores). In such ases they are known only by qualitative quantifiers (such as "insignificant/almost never, very low/rare, low, below normal, normal, above normal, high, very high/frequent, almost always") but their associated numeric value is not significant (only their relative order is known, you can't compute an average between two of these values, it's impossible to aggregate them in summations).
So I don't see how we can really fix this P1107, which has false positives in almost all uses cases: it is not correctly specified, unverifiable, there are exceptions every time, and it's too ambiguous. I suggest deprecating P1107 as a valid qualifier, making it only a base property for other properties, and removing completely its current restrictions on allowed values. Verdy p (talk) 16:02, 1 March 2019 (UTC)
Return to "P1107" page.