Property talk:P1279
Documentation
percent change in the consumer price index (CPI)
List of violations of this constraint: Database reports/Constraint violations/P1279#Single value, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1279#citation needed
List of violations of this constraint: Database reports/Constraint violations/P1279#single best value, SPARQL
|
This property is being used by:
Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
Allowed values edit
Allowed values shouldn't be percentage over time (e.g. percentage per year) instead of simply percentage? --Malore (talk) 11:51, 27 March 2018 (UTC)
Add to economy of topic items edit
This property is currently stored in country items. As country items tend to get overly large and uneditable, I'd move this this property to economy of topic items.
All countries have such items, see lists/economics_by_country. Thanks to the constraints on P8744 economy of topic items are also in fairly good shape.
For the sample on the property (Austria), that would be economy of Austria (Q8085).
- Infoboxes on country items could still read the values with the recently created economy of topic (P8744).
- In SPARQL query, using
wdt:P8744/wdt:P1279instead ofwdt:P1279would give users the same result.
The change was recently tested with total reserves (P2134) and went fairly smoothly. Item sizes of countries were reduced by 25,000 to 130,000 Bytes.
@F-prettyland, 123: who added some of the data. --- Jura 07:31, 21 November 2020 (UTC)
In my view, the best solution would be an item "inflation rate of administrative territorial entity x" (see Q56061: administrative territorial entity) where all inflation rates (each year) would be stored. We would need an additional property "inflation of topic" for adding this new item in economy of country x. This way we would have items with maybe 100 inflation datas per item. This way we could store data that changes yearly for lots of this kind of properties. The next improvement would be a way for Lua to find on the spot the most recent data. I don´t know if rank does this task. I think, this way the server load for getting this kind of data would be the lowest. The next improvement would be additional informations in this item for a bot to learn how and where to find this information in external websites and when and how to update the data. We would need new properties for this task. This way we would alway have the most recent data of this kind in Wikipedia Infoboxes. --Goldzahn (talk) 13:45, 9 November 2021 (UTC)
- Maybe .. but the size of (e.g) economy of Austria (Q8085) is less an issue as it has just 6 incoming links while the country has >186809, i.e. it wont get loaded (or edited) for completely unrelated purposes.
- I think it could easily include annual data for most current properties.
- If you have an idea how to feed them, you could make a request at Wikidata:Bot requests (if you don't want to add it yourself).
- Setting preferred rank for most recent data allows to retrieve that more easily. --- Jura 13:56, 9 November 2021 (UTC)
- Bots adding this kind of data is something Iḿ thinking about for years. Since it is not done for Wikipedia Infoboxes, this data is always several years old. About rank: I know "rank", but I do not know if rank reduces the amount of data Lua code has to work on. I mean, if Lua has to look into all statemets about inflation to find the ranked one, it doesnt reduce Lua time. About realization: My problem with finding my own solution is that this is a job that has to be done like for ever. The solution must be a bot that is operated by Wikidata and not by a user. Is there such a bot? --Goldzahn (talk) 18:28, 9 November 2021 (UTC)