Hi,
I think that that kind of edition cause problem. We are pretty sure that there will be update in demographics mesurements taken on these Sweden communities. To priorise a value in the 1970s block actualisation in, by example, automated infobox models like
fr:Module:Infobox/Localité.
Topic on User talk:Laboramus
I just cancelled another edition of that kind. Can you please stop your bot doing that ?
Another example : Two days ago, I actualised the population of Q2232307. Today, the 1970 population is still priorised.
@Simon Villeneuve I'm not sure I understand, why it is a problem? Is the bot marking the wrong statement? The edits looks correct to me, please explain. For Q2232307, it looks like you have updated the number but not the preferred status. If you add a new number, you should also move the preferred status for it (manually, bot would not touch items that already have preferred statements).
Hi,
That's the problem. The majority of Wikidata users dont touch the status. They just add values. The actions of your bot fix the prefered value in time. Doing so, the value will not be updated with more recent values, added by humans or bots.
I discussed this on the French village pump : Wikidata:Bistro#PreferentialBot.
@Simon_Villeneuve
Well, the bot does not touch statements having preferred values, since I don't want the robot to override human decision. Preferred value may not be the latest, for some reason for example. So if people add new data - be it after bot edit or after human edit - they have to move preferred item. I don't think I can trust bot to do it, it's a bit dangerous. So we need to educate people about it. The bot (or query) certainly can find suspect entities where the preferred data not the last one.
Hi,
If I understand you well, a bot can pu a preferred value, but not change it after it have done so ? It's worst that I thought.
My opinion is that the bot must not put a preferred status on a "chronodegradable" entry at all. In the case I put in example above, the date of the preferred population value is 1970. It was clear that this value would change, and it will change again in the future (census usually are done every 5 to 10 years).
There's millions of localities. We can't think that all of the population of them will be entered by a human, and change the status of 2 values is to long to think that "education" will be successfull.
I think your opinion is wrong. Preferred status exists exactly for such occasions - to mark latest/best available value. The fact that the data is going to change does not mean it shouldn't have preferred item - on the contrary, exactly because it's going to change it should have one. Many numbers change with time, and preferred status should change when data changes. It's just part of proper data maintenance. Not having preferred one does not allow to easily see which figure is the best available data.
You can also set the preferred item manually and then the bot will not touch it.
If the data will be edited automatically, then the code that makes the edits should ensure to move the preferred status accordingly. It's not hard to do and once it's done it would apply to all millions of localities it edits, even easier than manual editing.
Ok. I understand just now that I speak to only one person here. Can you please stop to use 2 accounts in this discussion ?
I think you delude yourself. Up to now, I see that users put data without touching the status of it (most of them don't know this option exist). Here's a proof of what I said : https://www.wikidata.org/w/index.php?title=Q43049&diff=220919994&oldid=220915967
Yes, some users need to be educated. But what you propose is essentially stop using preferred status for what it was meant for and make all these data un-queryable. I don't think it's a good solution. We could make a bot that checks such cases and asks people to edit correctly, but I don't think stop using preferred status completely is better.
I don't understand why you say "make these data un-queryable". All the template I've seen on Wikipedia can easely filtrate good temporal values with functions like numval
, chronological
and inverted
.
All the template I've seen priorise preferred status. This is good when, by example, we have many birth or death dates/places for a personnality and that we know that these will not change with time. You say to me that when value change with time, the preferred status must be move. I say that wikidaters don't work like that. You say we must educate them, I say putting preferred status in these cases need more time for no real gain compared to the non-actualisation of preferred status by the community.
Our discussion is at a dead end. I think we must discuss this elsewhere to have others PoV.
Templates are not only things that use data. For example, there is SPARQL usage. And filtering data for one item is different from querying millions of items.
Almost all data that uses preferred status also changes with time - because preferred status is being used to specify the value currently best, and when there's such value in most cases that means it can change, be it population, area, head of government, spouse, etc. All that can change with time.
Putting preferred status has the gain that allows to know best current value among set of values. If somebody doesn't care about it, then it's no worse than before, if however they care then it allows to get the best one.
I disagree again. If somebody doesn't care, it's worse than before because the preferred value isn't the good one anymore. IMHO, no preferred value is better than a inappropriate preferred value.
Where do you think we can have other PoV to help us ? It seems there is 2 main places : Wikidata:Requests for comment and Wikidata:Project chat. The first one seems to be more appropriate.