Wikidata

Wikidata:Property proposal/average yearly temperature

< Wikidata:Property proposal

average yearly temperature edit

Originally proposed at Wikidata:Property proposal/Natural science

   Not done
Descriptiontemperature calculated by averaging the minimum and maximum daily temperatures over 30 years in a certain place
Data typeQuantity
Domaininstances of geographic region (Q82794) and instances of, recursively, its subclasses
Allowed valuesfrom -400 (minimum using degree Fahrenheit (Q42289), near to the absolute zero (Q81182)) to 350 (maximum using kelvin (Q11579), perhaps could be reached inside a volcano)
Allowed unitsthe same as temperature (P2076), that is, degree Celsius (Q25267), kelvin (Q11579) and degree Fahrenheit (Q42289)
ExampleZaragoza (Q10305) → 15.5 °C (according to aemet.es, the Agencia Estatal de Meteorología (Q2826727))
Planned usefirstly, importing data for some Spanish municipalities from the Agencia Estatal de Meteorología (Q2826727)
Robot and gadget jobscreating and regularly updating a world map (Q653848) that represents how these values are distributed across the planet
See alsotemperature (P2076), Köppen climate classification (P2564)
Motivation

Wikidata is lacking in climate data, and the average yearly temperature is a particularly relevant measurement. abián 15:57, 28 August 2016 (UTC)[reply]

Discussion
I think that we have a problem.
  1. If we only create a property for the average monthly temperature, we won't be able to get the average yearly temperature if we don't have well-defined data of all months. In some cases, we know the average yearly temperature but not the average monthly one.
  2. If we only create a property for the average yearly temperature, we'll never be able to know the average monthly temperature.
  3. If we create both properties, we should never use both for the same Wikidata item. This situation could be controlled using a {{Constraint:Conflicts with}}.
There isn't a perfect solution. If we usually know the average monthly temperature, I would say 1. If we usually know the average yearly temperature but hardly ever the average monthly one, I would say 2. And, if there's no a "usual" situation, I would say 3. If I would have to choose right now, without being able to talk or to find out about this, I would choose 3. --abián 20:37, 28 August 2016 (UTC)[reply]
  • Average monthly temperatures are way more informative than plain yearly average. Whether we create a specific property for this or not, we should think about how bring here monthly averages too, creating a coherent model including the later ones too.
1) Having a specific property for yearly averages and using generic temperature (P2076) 'qualified' with determination method (P459) for the monthly ones would be pretty awkward.
2) Having "average yearly temperature" and "average monthly temperature" using somehow the month as qualifier would make a little more sense. I don't know.
3) Having "average yearly temperature", "average january temperature", and "average february temperature" and... -> no.
Regardless all that, qualifiers as start time (P580) or end time (P582) should be added too. Strakhov (talk) 20:09, 28 August 2016 (UTC)[reply]
Option 2 makes much sense. :-) --abián 20:49, 28 August 2016 (UTC)[reply]
month of the year (P2922) would work as the qualifier in this scenario. Thryduulf (talk) 22:11, 28 August 2016 (UTC)[reply]
We'd need "average maximum temp." and "average minimum temp." too. Recently we approved precipitation height (P3036), but it seems pretty weird, as it represents a point in time, not an average. How about "average montly precipitation height" and "average yearly precipitation height"? Seriously, I think we need to apply here a more holistic view, not proposing one by one. Strakhov (talk) 17:09, 30 August 2016 (UTC)[reply]
  •   Comment would it be possible to consider instead a property that provides a database of temperatures for the location so that whatever monthly or yearly averages are wanted can be computed from it? It might have to be a URL to a dataset...? ArthurPSmith (talk) 19:19, 30 August 2016 (UTC)[reply]
    The average yearly temperatures in a certain decade are fixed values, they won't change. However, external links will probably do, sooner or later. And, as only linking an external database wouldn't be enough to retrieve data from the Wikimedia projects, I think that it's better to directly save these data in Wikidata. --abián 09:16, 2 September 2016 (UTC)[reply]
  • Well, sometimes old values do change thanks to reanalyses - or at least in certain datasets they wouldn't be perfectly fixed. In any case, what I think would be best here would be to be able to store the full dataset, say as a CSV file, in Wikimedia Commons. However, Commons doesn't allow CSV or other dataset files at the moment. If we store monthly averages directly in wikidata, then you have 12 statements per year - for some locations there are 150 years or so of data (perhaps more in England?) so you could have 1800 temperature statements on a location item in wikidata under this approach. That doesn't seem like a good idea to me. ArthurPSmith (talk) 15:41, 21 September 2016 (UTC)[reply]

If I'm not wrong, these are the possible Wikidata properties concerning average temperatures and their dependencies.

 

These dependencies can be applied, mutatis mutandis, to any kind of average climate data (average rainfall, average relative humidity, average number of frosty days, etc.).

Having read all comments, having done some research, and knowing that these data:

  • have an absolutely different availability depending on the relevance of the place, on the country and on the antiquity;
  • should always be used with qualifiers start time (P580) and end time (P582);
  • should always have a direct reference;
  • are historical and should never change since they are added to Wikidata;

... I propose that we exceptionally assume some degree of duplication with them and that we allow to store multiple declarations using these properties even for the cases that some of them could be derived from others.

For the case of monthly data, declarations should also necessarily have the qualifier month of the year (P2922).

In conclusion, concerning this property, "average yearly temperature", I still think that creating it would be a good idea. --abián 12:25, 2 September 2016 (UTC)[reply]

  Comment How many dimensions data should have when we call it "tabular"? Geographic dimension represented using items.
Census data have 3 dimensions right now: location, point in time, sex.
It is possible to get 50+ dimensions from census information, we need only selection of dimensions on Wikidata, not complete 1-to-1 dumps.
  Comment If we use .csv / .tabs on commons, then I would like to have a property about "tabular data available on commons"; and with qualifier about topic ("Climate data"). d1g (talk) 03:19, 14 January 2017 (UTC)[reply]
That is far too generic. It would be like having a property called "string" that we use for all strings. - Nikki (talk) 18:19, 31 January 2017 (UTC)[reply]
  •   Comment this is my first time at the property proposals page, so I'm going to keep things to a comment for now. I was just editing Q21726404, and I was looking for a property for annual temperature. There are tons of bot-generated pages on the Swedish Wikipedia, for example the bot generated page for the item I just mentioned. The bot found structured data to make that page, so I feel that Wikidata could have a viable property for this. Icebob99 (talk) 14:53, 16 February 2017 (UTC)[reply]


Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/average_yearly_temperature&oldid=531679231"