PreferentialBot

New property to the list

Please add the Elo rating (P1087) property to the list. Thank you --Dodi123 (talk) 13:52, 25 November 2016 (UTC)

Support. This property is updated every month and not always the last one has the preferred level defined. The infobox in Wikipedia in Spanish takes this data from Wikidata and there are problems when the preferred level is not defined correctly. --Metrónomo (talk) 07:39, 10 January 2018 (UTC)

 Done Laboramus (talk) 04:39, 1 September 2018 (UTC)

@Laboramus: Can you please stop the bot and revert all his changes regarding Elo ratings? Now we have the situation that the July 2018 ratings are marked as preferred, where August and September ratings are newer. It has been discussed in the WikiProject Chess that no Elo ratings are marked as preferred! Steak (talk) 18:32, 2 September 2018 (UTC)

@Steak: Could you cite the diff where there were August ratings but the bot chose July ones? That certainly shouldn't happen, that would be a bug. But if August ratings were added after the bot marked July ones as preferred, then whoever adds the ratings should also move the preferred mark. Otherwise, I don't see why preferred mark on latest rating is wrong, could you explain? Laboramus (talk) 20:23, 2 September 2018 (UTC)

Same reason like in the topic below: "To assume that "current" is the same as "preferred" is an error, and only correct if the statement is interpreted in specific contexts." One could also mark the highest rating as preferred, or whatever else. There is simply no reason to mark one rating as preferred. Retrieving the most recent date is to be done by suitable template programming. Steak (talk) 20:39, 2 September 2018 (UTC)

I have removed all preferred ranks. Future changes have to be discussed either on the property talk page or in the Wikiproject Chess. Steak (talk) 08:09, 9 September 2018 (UTC)

Vision of Britain unit ID (P3615)

Please don't do this for Vision of Britain unit ID (P3615), and reverse it for examples where you have done it. It's more useful to be able to pick up both IDs with a simple search. (Almost all information under P3615 is historical, so it's not so useful to prefer "current" values). Jheald (talk) 11:53, 6 November 2017 (UTC)

 Done Laboramus (talk) 04:40, 1 September 2018 (UTC)

This is wrong

This change [1] is simply wrong. These entries are equally important, and that something has changed does not imply that something has become preferred. These kind of changes will although make it necessary to stop using the «preferred» statements aka the «best» statements, which was my reason to argue against this rank value back in 2012. Jeblad (talk) 08:11, 13 June 2018 (UTC)

@Jeblad: could you explain a bit more about it - why is it wrong? I understand that the ship belonged to one country and now it belongs to another. The current value would be preferred. If you are opposed to existence of preferred rank in general, it's ok, but since the rank does exist, it is being used to designate current values. Could you explain why it is wrong in this particular case? It is certainly possible to tweak the bot if it mishandles some use cases, but I'd like to know reasons. Laboramus (talk) 05:02, 1 September 2018 (UTC)

To assume that "current" (or rather last entry) is the same as "preferred" is an error, and only correct if the statement is interpreted in specific contexts. In this case current ownership. This is not how this should be done at Wikipedia, as this entry should cover the history of ownership. An ordering of statements does not make one of them preferred, and it is wrong to use preferred unless only a single entry should be used. This is exactly what I told the rest of the devs at WMDE how this would be done, people would interpret "current" as "best", and thus why it would be wrong to add the feature. After the discussion about this on this project I have oriented the community at nowiki that Wikidata does it this way, and told them it is not likely they will change how they do it, and told them they should stop using "preferred" altogether. Some templates still does, especially all infoboxes that use the parser functions, and should be fixed.

In general; it is wrong to use "preferred" in all cases where the choice of whats preferred comes from some kind of ordering of the statements. There should instead be a set of filter functions for those cases, and for time-ordered statements there should be a function get-current-statement. The only case where it makes sense to have a "preferred" is when you have a list of unordered statements, and one and only one of the statements would be valid and preferred in all contexts. (Note that "preferred" and "deprecated" are not inverses, and that "deprecated" is a somewhat simpler problem. Ie valid in all contexts vs valid in some context. Still that is also an interpretation that might not hold.) Jeblad (talk) 11:42, 1 September 2018 (UTC)

@Jeblad: I am not sure why you feel that using preferred is wrong when it comes from ordering - you stated it, but I still didn't see an argument as to why this is your position and what it makes worse as opposed to my position. As I can see, with current setup you can easily do both current and previous ownership, so I am not sure why it is a problem for you. Maybe if you describe specific issues in more detail, I could give some advice on how to handle them.

Maybe there could be a different design where there's "a set of filter functions" and so on, but that's not how Wikidata or the query engine works right now (and I am not sure it even can work efficiently that way, in any case it would require substantial work to create an RFC about it, design it, and implement it, and it hasn't happened yet). Right now there's preferred status which is very useful exactly for ordered, time series, etc., data, and I am not sure why we would abandon it. I am not sure what is the basis of your claim that only unordered statements can have preferred status, but I think this is not correct, as preferred status is very useful for many properties such as population, income, position, chairmanship, membership, etc. where it allows do easily distinguish historical data from current actual data. I appreciate that you disagree with existence of preferred status and its current usage, but I think you are wrong on this. You of course are certainly welcome to design a different model of how Wikidata should work, and if there would be wide consensus for the change, I'd certainly change the bot. But I do not think this is the situation now? At least, in the discussion you quoted you seem to be the only one holding such a position. Also, if you discuss my bot, I'd certainly welcome a ping, that would allow me to notice the discussion and participate in it while it's active.

I agree with the sentiment that if there would be two statuses - "best" and "current", then it would probably be more precise. But right now we do not have two statuses, we have only one. And this one is very useful the way it works now - try to compare queries returning current population of Oslo or current sitting US president with and without such usage, and now imagine we have to deal with several such clauses to combine various data (such as the famous "biggest city having female mayor" query). Try to rewrite such query without using preferred status (or its analogue) and see how complicated it becomes. You seem to be rejecting the concept of the "current" status outright, which I think it not right and I certainly disagree with you on that. Laboramus (talk) 20:50, 2 September 2018 (UTC)

Well, I did oppose the implementation of "preferred" when it was implemented and the problems I described has emerged. If you can order a set of statements, that is what you do when you tag the current one and call it "preferred", then you have at least two possible "preferred". One on ascending order and one on descending order. The context says which one of them is the correct one. Often there are several possible orderings of statements, giving even more alternatives for "preferred".

Whats happening now is that external projects code around use of "preferred", or actually tries to avoid use of "best statements", as it does not give the correct answer. This works for modules, but not for unconverted templates.

Sorry, but planning for and implementing for a single use case is not wise. It is more commonly known as a bug. Jeblad (talk) 21:45, 2 September 2018 (UTC)

I have the same issue at Elizabeth Hocking (Q56424744), where the bot is edit-warring with me Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:56, 1 September 2018 (UTC)

@Pigsonthewing: Not sure I get this - are you saying Elizabeth Hocking's family name is not "Hocking" or that family name should not have preferences at all, i.e. if someone changed their family name over the course of their lives, we should have no way to determine which one is the current one they are using? I can exclude specific items from the bot list if necessary but I am not sure why Elizabeth Hocking (Q56424744) is wrong. Laboramus (talk) 20:27, 2 September 2018 (UTC)

Whether or not Hocking is the right family name is not so important, but this is a good example anyhow. Someone sets an unordered item as preferred because they have unique knowledge that it is somehow the right statement, and then the bot starts edit warring. Because the set is unordered use of "preferred" is acceptable, but as soon as users starts adding qualifiers making the set sortable, thus ordering the set, then "preferable" does not make sense anymore. It is although possible to have a qualifier for preferrable saying why something should be preferred, like "subject prefer this family name". This does not create the same problem because there can be several such qualifiers. Jeblad (talk) 22:20, 2 September 2018 (UTC)

"Preferred" does not man "current". We already have a way to "to determine which one is the current one they are using" (though not in this case, as Hocking has been dead for many years) - start and end dates. If you wont desist in these actions - I note that bot approval for the task was a long time ago and had no substantive discussion - then I will raise the matter for community discussion, on 'project chat'. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:44, 3 September 2018 (UTC)

Your edits with this bot is still wrong, and it will newer be right. Current entry is NOT the same as preferred entry. Jeblad (talk) 21:16, 18 April 2019 (UTC)

Population

Hi, items such as Q2351309 have population numbers for different years. Can you set the most up-to-date number as preferred? (Or are you actually doing this already?) Thank you very much --Vojtěch Dostál (talk) 15:36, 12 September 2018 (UTC)

It does but only if there's no other preferred value. Laboramus (talk) 07:01, 29 October 2018 (UTC)

I just stumbled upon the same problem when uploading new population figures with quickstatements: Not only my own updates, but many other entries do not show up in normal queries due to outdated rankings:

SELECT 
 ?item
 ?itemLabel 
 (MAX(?pref_pop_date) as ?max_date_with_preferred_rank)
 (MAX(?norm_pop_date) as ?max_date_with_normal_rank)
WHERE 
{
 ?item p:P31 [ps:P31 wd:Q6256] # Select all countries

OPTIONAL { # Select population dates with preferred rank
 ?item p:P1082 ?pref_pop. 
 ?pref_pop wikibase:rank wikibase:PreferredRank.
 ?pref_pop pq:P585 ?pref_pop_date.
}
OPTIONAL { # Select population dates with normal rank
 ?item p:P1082 ?norm_pop. 
 ?norm_pop wikibase:rank wikibase:NormalRank.
 ?norm_pop pq:P585 ?norm_pop_date.
}
SERVICE wikibase:label {bd:serviceParam wikibase:language "en".}
}
GROUP BY ?item ?itemLabel
HAVING (
  (MAX(?pref_pop_date) < MAX(?norm_pop_date)) # There's data with normal rank available with a point in time later than the one with preferred rank
  || ((COUNT(?norm_pop_date) > 1) && !(BOUND(?max_date_with_preferred_rank)))) # There's more than one point in time, but none is flagged as preferred 
ORDER BY ?itemLabel

Try it!

Was this behaviour (ignoring entries with existing preferred rank) discussed anywhere before? I see how this could be reasonable for many properties, but not for population: I couldn't find any instance where older population data was actually preferable compared to newer data. So I think it would be great if PreferentialBot could update those entries as well. --Tkarcher (talk) 13:14, 8 April 2019 (UTC)

character identifier IMDb format ("ch")

a bot has updated the IMDb redirection to send 'ch' id's to archive.org,

to that end

1. the rank needs to be put back to normal.

2. reason for deprecation (P_2241) needs to be removed.

3. former IMDb character page (Q_44374960) needs to be removed

50.254.21.213 17:11, 6 October 2018 (UTC)

Michele Hunziker

please don't give preferences for actual husband, otherwise the others are not shown in infoboxes. --Les Meloures (talk) 17:13, 9 October 2018 (UTC)

Why not? Actual husband certainly has different status than past husbands. Maybe the infobox should be changed to show past values? Laboramus (talk)

New property to the list - nominal GDP P2131

Hi, could you please add the nominal GDP property to the list of the operated statements? Cheers! Datawiki30 (talk) 14:29, 24 October 2018 (UTC)

@Datawiki30:  Done Laboramus (talk) 07:09, 29 October 2018 (UTC)

Thank you! Datawiki30 (talk) 12:44, 29 October 2018 (UTC)

patronage

Hi, could you please add patronage (P3872) to the list of the operated statements? Thanks.--Jklamo (talk) 09:13, 19 December 2018 (UTC)

Time zone

Please see Wikidata:Bot_requests#Marking_as_preferred_the_current_time_zone_in_Property:P421 by User:Antenor81 --- Jura 11:03, 23 December 2018 (UTC)

Located in the administrative territorial entity

Hello Laboramus, could you add support for located in the administrative territorial entity (P131) please? Thanks. Ayack (talk) 06:23, 22 June 2019 (UTC)

It used to support it, but unfortunately I had to disable it due to too many entries the bot couldn't handle (see https://www.wikidata.org/wiki/User:PreferentialBot/Log/P131). I'll check if that's still the case, maybe I could re-enable it. Laboramus (talk) 21:09, 23 June 2019 (UTC)

setting rank in economic properties

Hello.

Is this bot able to set rank of the newest claims in properties like total reserves (P2134)? (For eg i mean setting rank for total reserves (P2134) at point in time (P585) 2017 in Chile (Q298) to preferred)
What input data would it need?--813gan (talk) 23:00, 10 July 2019 (UTC)

Add visitors per year (P1174)?

Hello,
could you add visitors per year (P1174) to the list of properties the bot is working on? Thanks in advance, --Marsupium (talk) 16:26, 1 October 2019 (UTC)

Add headquarters location (P159)

Items with headquarters location (P159) could greatly benefit from this bot.--Pere prlpz (talk) 20:24, 29 January 2021 (UTC)