Property talk:P1120
Documentation
total (cumulative) number of people who died since start as a direct result of an event or cause
List of violations of this constraint: Database reports/Constraint violations/P1120#Units
List of violations of this constraint: Database reports/Constraint violations/P1120#Type Q1190554, Q14136353, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1120#integer, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1120#citation needed
List of violations of this constraint: Database reports/Constraint violations/P1120#allowed qualifiers, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1120#Entity types
List of violations of this constraint: Database reports/Constraint violations/P1120#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1120#Conflicts with P31, SPARQL
|
This property is being used by:
Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
Displays ±1 edit
Why does Q16629249 display "number of deaths 9±1" if the input was plain 9, no uncertainty there? or should there be a special qualifier to set precision? Retired electrician (talk) 22:12, 13 August 2015 (UTC)
- It's a quirk in the entry form. You can either edit it to correct or, on entry, add "+-0" after the number. --- Jura 15:43, 28 September 2015 (UTC)
Number of deaths in specific location edit
Is P1120 also applicable to locations? I'm trying to add the number of deaths for different concentration camps and was wondering if P1120 can be used in this context.--Brackcurly (talk) 18:10, 5 December 2015 (UTC)
unit removals edit
Please can a human check all the entries where units have been removed. Changes such as here need to be resolved so that the data is not corrupted for reusers.
Secondly, why have all the units suddenly been removed? There seems no benefit to doing so, even ignoring cases like above. Thryduulf (talk) 22:22, 12 June 2016 (UTC)
- In cases like this it makes sense to ping the person responsible for the removal of the units. ChristianKl (✉) 16:43, 19 December 2017 (UTC)
- The reasoning is likely that this property P2237 (P2237) "noValue". I think it would make sense to change that to "human". ChristianKl (✉) 16:45, 19 December 2017 (UTC)
number of injured (P1339) required edit
Items like COVID-19 pandemic in New York (Q87414741) include number of deaths (P1120), but, based on the structure we use, shouldn't have number of injured (P1339). Accordingly, I removed "no value"-statements with P1339 that were added there.
Now I noticed that these were actually there because of a constraint here (removed for now).
If it's found that, in general, the constraint could be useful, feel free to revert everything. --- Jura 13:29, 28 March 2020 (UTC)
Need to differentiate cumulative numbers (total since start) from annual frequency edit
The number of deaths 2019 may either be the annual frequency (number per year) during that year, or a cumulatively number, i.e. total number since start of for example a war, a long-term catastrophe or an epidemic until that year. Cumulative numbers are most common, especially in historical catastrophes that lasted several years, but both types of numbers occur for the same item, and it is not clear which type a certain number is. Typically you can guess from if the numbers are small or large. I suggest that P1120 should be cumulative, and a new "death frequency"/"annual deaths"/"deaths per year" property should state numbers per year. This goes for many other quantities, such as number of injured (P1339), number of casualties (P1590), number of cases (P1603) and victim (P8032). They should all be cumulative, and have frequency correspondents. That approach would be easiest for module and template designers. Another option would be to allow a unit such as as "deaths per year", "cases per year" "events per year". A third option would be to require that the user always states nature of statement (P5102) -> either "cumulative" or "annual frequency". Those items then needs to be created. Other types of numbers may also occur, such as cumulative incidence (Q1106825) (incidence proportion, unit: deaths/100 000 capita, cases/capita, crimes/capita, etc), as well as combinations such as cases per capita and year. Tomastvivlaren (talk) 17:21, 13 May 2020 (UTC)
- @Discostu:, @Neo-Jay:, 1Veertje, Jura1 what is the best way to address this? Or where can I discuss this issue? Tomastvivlaren (talk) 17:15, 28 May 2020 (UTC)
- @Tomastvivlaren: You may discuss this issue at Wikidata:Project chat or propose new properties per Wikidata:Property proposal. Sorry for my late reply (I had been unable to access Wikimedia sites since 15 May 2020 due to China's Great Firewall, and my accessibility issue was just fixed). --Neo-Jay (talk) 02:20, 6 June 2020 (UTC)
Point in time required edit
With COVID-19 statistics this parameter is pretty much pointless if you don't have a point in time to go along with it. 1Veertje (talk) 07:51, 14 May 2020 (UTC)
- Maybe something for a
{{Complex contraint}}? The property has other uses than COVID-19. --- Jura 07:54, 14 May 2020 (UTC)
- I agree that a complex constraint could be useful here. It could for example only make point in time (P585) mandatory for objects that are a sub-item of disease outbreak (Q3241045). -- Discostu (talk) 08:38, 14 May 2020 (UTC)
Property constraint should be expanded edit
The property constraint for this property limits its usage to exclusively occurrences at the moment, which excludes deaths tolls associated with item types, e.g. assault rifles in the United States. The property I specifically have in mind for inclusion is https://www.wikidata.org/wiki/Q27150149 as there is a verified number of fatalities that involved the use of Tesla Autopilot. 14:35, 10 July 2022 (UTC) QRep2020 (talk) 14:35, 10 July 2022 (UTC)