Property talk:P1107

Documentation

• Start a query
• Properties using this qualifier (statistics)
• Count

proportion
to be used as a qualifier, value must be between 0 and 1

Description	used as a qualifier.
Represents	proportion (Q2631509)
Data type	Quantity
Domain	qualifier for properties, any time of item (note: this should be moved to the property statements)
Allowed values	According to this template: number between 0 and 1 According to statements in the property: 0 ≤ 𝓧 ≤ 1 When possible, data should only be stored as statements
Allowed units	not applicable
Example	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 Foxconn (Q463094) → 0.0296 When possible, data should only be stored as statements
See also	fineness (P7379)
Lists	Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Chart by item creation date Minimum and maximum Items with highest numeric value Items with lowest numeric value User:Laboramus/Units/P1107 (Units used) Database reports/Constraint violations/P1107
Proposal discussion	Proposal discussion
Current uses	Total 23,293 Main statement 4 <0.1% of uses Qualifier 23,284 >99.9% of uses Reference 5 <0.1% of uses

[create Create a translatable help page (preferably in English) for this property to be included here]

Range from “0” to “1”: values should be in the range from “0” to “1”. (Help)

List of violations of this constraint: Database reports/Constraint violations/P1107#Range, hourly updated report

Scope is as qualifier (Q54828449): the property must be used by specified way only (Help)

List of violations of this constraint: Database reports/Constraint violations/P1107#Scope, hourly updated report, SPARQL

Units: “novalue”: value unit must be one of listed. (Help)

List of violations of this constraint: Database reports/Constraint violations/P1107#Units, hourly updated report

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1107#Entity types

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

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

Units constraint violation shows 0 violations, but they exists

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

Units

No value units is outdated, percent (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 has subsidiary (P355), where no unit handling is impractical. I think it is time to allow percent (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)

How is the situation ? Do such properties exist ? If not, why ? Mr Tortue (talk) 01:25, 5 August 2022 (UTC)

Units (mass / vol ratio)

These are necessary "units" but I'm sure more exist. This does not endorse the unit "percent". If you cannot give a good argument or better solution I'll change the constraint to allow Mass ratio and Volume ratio. --SCIdude (talk) 18:24, 6 August 2020 (UTC)

Proportion of what?

We should be clear that, in any statement like Aterritory overlaps (P3179)B with a qualifier proportion (P1107) = p (or any other statement where it might be ambiguous), that:

• the proportion p is the proportion of the subject of the statement, ie the proportion of A that the statement applies to, not the proportion of B.

-- Jheald (talk) 13:21, 4 April 2021 (UTC)

Maximum & minimum ratio

I would like to express maximum and minimum percentage in order to describe instances of Protected designation of origin (Q13439060). For example, a Q42867236 should be made of a maximum of 80% of Grenache (Q390242), and a minimum of 15% of Syrah (Q332720) or Mourvèdre (Q161864). This property does not allow values like "0.8+" or "0.15-", which could address my need. Do you think of any way of expressing this? Many thanks! Dipsode87 (talk) 14:47, 22 February 2023 (UTC)

Quantities have an upper and lower bound, but you can only enter values as an average value, and an error interval. E.g. 10+/-2 for a value between 8 and 12 or 0.5+/-0.1 for a value between 0.4 and 0.6. Infrastruktur (talk) 15:02, 22 February 2023 (UTC)