Property talk:P1087

Active discussions


Elo rating
quantitative measure of one's game-playing ability, particularly in classical chess
Type “human (Q5), computer program (Q40056): element must contain property “instance of (P31)” with classes “human (Q5), computer program (Q40056)” or their subclasses (defined using subclass of (P279)). (Help)
List of this constraint violations: Database reports/Constraint violations/P1087#type Q5, Q40056, hourly updated report, SPARQL, SPARQL (new)
Units: “novalue”: value unit must be one of listed. (Help)
List of this constraint violations: Database reports/Constraint violations/P1087#Units, hourly updated report, SPARQL (new)
Item “sex or gender (P21): Items with this property should also have “sex or gender (P21)”. (Help)
Exceptions are possible as rare values may exist. Known exceptions: AlphaGo Zero (Q42259287), AlphaGo Fan (Q42223294), AlphaGo Master (Q29550830)
List of this constraint violations: Database reports/Constraint violations/P1087#Item P21, SPARQL, SPARQL (new)
Range from “1000” to “2900”: values should be in the range from “1000” to “2900”. (Help)
List of this constraint violations: Database reports/Constraint violations/P1087#Range, hourly updated report, SPARQL (new)
Mandatory qualifier “point in time (P585): this property should be used with the listed qualifier. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P1087#mandatory qualifier, SPARQL, SPARQL (new)
No bounds: values can't have any bounds (e.g. 1 not 1±0) (Help)
List of this constraint violations: Database reports/Constraint violations/P1087#No Bounds, hourly updated report, SPARQL, SPARQL (new)
Integer: values should be integers (ie. they shouldn't have a fractional part) (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P1087#integer, SPARQL, SPARQL (new)
Single value: this property generally contains a single value. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P1087#Single value, SPARQL, SPARQL (new)
Pictogram voting comment.svg Non-Deprecated Elo rating after date of death
date of rating > date of death and normal or preferred rank (Help)
Violations query: SELECT DISTINCT ?item { ?item p:P1087 [ pq:P585 ?date; wikibase:rank ?rank ]; wdt:P570 ?dod . FILTER(?rank != wikibase:DeprecatedRank) . FILTER(?date > ?dod) . }
List of this constraint violations: Database reports/Complex constraint violations/P1087#Non-Deprecated Elo rating after date of death
Pictogram voting comment.svg Elo ratings with preferred rank
Elo ratings with preferred rank (Help)
Violations query: SELECT DISTINCT ?item WHERE { ?item p:P1087/wikibase:rank wikibase:PreferredRank }
List of this constraint violations: Database reports/Complex constraint violations/P1087#Elo ratings with preferred rank
Pictogram voting comment.svg Elo ratings without proper source
Elo ratings that do not have either a link to or Particularly, "imported from" is not a proper source. (Help)
Violations query: SELECT ?item ?elo WHERE { ?item p:P1087 ?s . FILTER NOT EXISTS { ?s prov:wasDerivedFrom/(pr:P248|pr:P854) ?refHandle } ?s ps:P1087 ?elo . }
List of this constraint violations: Database reports/Complex constraint violations/P1087#Elo ratings without proper source
Pictogram voting comment.svg Elo ratings without retrieval date (1)
Elo ratings without retrieval date (using (Help)
Violations query: SELECT ?item ?elo WITH { SELECT DISTINCT ?refHandle WHERE { [] p:P1087/prov:wasDerivedFrom ?refHandle . } } AS %subquery WITH { SELECT ?refHandle WHERE { INCLUDE %subquery . ?refHandle pr:P248 [] . MINUS { ?refHandle pr:P813 [] } } } AS %subquery2 WHERE { INCLUDE %subquery2 . ?item p:P1087 [ prov:wasDerivedFrom ?refHandle; ps:P1087 ?elo ] . }
List of this constraint violations: Database reports/Complex constraint violations/P1087#Elo ratings without retrieval date (1)
Pictogram voting comment.svg Elo ratings without retrieval date (2)
Elo ratings without retrieval date (using (Help)
Violations query: SELECT ?item ?elo WITH { SELECT DISTINCT ?refHandle WHERE { [] p:P1087/prov:wasDerivedFrom ?refHandle . } } AS %subquery WITH { SELECT ?refHandle WHERE { INCLUDE %subquery . ?refHandle pr:P854 [] . MINUS { ?refHandle pr:P813 [] } } } AS %subquery2 WHERE { INCLUDE %subquery2 . ?item p:P1087 [ prov:wasDerivedFrom ?refHandle; ps:P1087 ?elo ] . }
List of this constraint violations: Database reports/Complex constraint violations/P1087#Elo ratings without retrieval date (2)


Preferred value: Highest or most recent?Edit

At Samuel Zhukhovitsky (Q2219041), I was wondering which value should get "preferred rank". The most recent or the highest one? --- Jura 11:17, 11 December 2015 (UTC)

  • In the meantime, there are so many values .. I set the most recent one and the highest one to preferred.
    --- Jura 17:09, 23 October 2016 (UTC)
    • Hmm, good question. Probbaly the recent one. But I don't have a strong opinion. --Edgars2007 (talk) 08:41, 24 October 2016 (UTC)
From a practical point of view, it would be better to set the most recent to preferred. The highest value is to some extend stable and could be used in the wikipedias without resorting to wikidata. But I would prefer to use the property without ranks at all and use suitable template programming. Steak (talk) 08:43, 24 October 2016 (UTC)
About use the property without ranks at all part, Steak. I don't think it's a good idea. Then we have (more or less) unstructured data, it probably has many other cons. Pro for having qualifiers - if I want to list chess players by ranking in August 2014, I could do it easily in SPARQL. --Edgars2007 (talk) 15:58, 24 October 2016 (UTC)
Yes, but where do you need a rank to create a list for August 2014? Steak (talk) 16:56, 24 October 2016 (UTC)
I dont see the needs of ranks at all. --Wesalius (talk) 07:14, 26 October 2016 (UTC)
August 2014 list was simply just a (IMHO valid) example of use-case. And as I already said, rank not inclusion will create a big mess. For example, then it will not be clear, does the player has all available data included in item. --Edgars2007 (talk) 11:45, 26 October 2016 (UTC)

@Jura1, Edgars2007, Wesalius, Steak: did this discussion reach any conclusion, and how to we use preferred rank for this property? Is this documented somewhere?

  • There are 455 items using an elo number with preferred rank; at the same time 432 of them have normal rank Elo rating (P1087) claims with with higher Elo numbers and later Elo dates at the same time (i.e. preferred rank neither sits on the latest, nor on the highest Elo number claim).
  • Preferred rank currently sits at July 2018 data, while latest data is from September 2018. IIRC the lag was much larger a while ago. This indicates that preferred rank probably is to be used for latest data, but the update mechanism does not work. Who feels responsible for ranking management of this property?

MisterSynergy (talk) 10:01, 7 September 2018 (UTC)

There was an undiscussed bot run by User:PreferentialBot recently (up to end of August, no preferred ranks were used). I told the operator at User talk:PreferentialBot that this was not ok. Currently I am running a script to undo the rank changes. Current status quo of consensus is that no preferred ranks at all are used. Steak (talk) 10:23, 7 September 2018 (UTC)
Removal of all preferred ranks is finished. Steak (talk) 08:08, 9 September 2018 (UTC)

Rudolf Teschner : ratings after deathEdit

Rudolf Teschner (Q67757) died in 2006. Elo ratings should stop at his death. It must be the same for all dead chess players.Cbigorgne (talk) 21:34, 26 October 2016 (UTC)

Thanks for adressing this topic, this also keeps me thinking. On the one side, the ratings are officially published by FIDE and we only document here the ratings and are strictly speaking not allowed to make any changes to them. On the other hand, a dead person cannot have rating. Teschner is not the only case where I noticed ratings after a person died. So we should find a consensus how we treat such ratings after death. Steak (talk) 11:56, 27 October 2016 (UTC)

If the rating is given by FIDE, then my bot adds it. We can do a cleanup afterwards if the consensus reaches the state that these should not be listed. The amount of work of programming a clause into the bot is the same as programming the cleanup script, so I think it is preferable to let it finish the job (update all players that we have with all ratings that have been published) and then possibly do a cleanup. --Wesalius (talk) 07:55, 29 October 2016 (UTC)

I don't see anybody supporting it. Can you start removing them? It's already beyond 2000 statements. Somehow, this makes one wonder about the usefulness of all others of these bulky statements.
--- Jura 15:22, 30 October 2016 (UTC)
No, I wont start removing them now. There is User:Cbigorgne and you wanting me to remove statements right now, then there is User:Steak saying we should find a consensus and then there is me saying that I dont see a clear argument why wikidata should be in this case an arbiter on which ratings should and shouldnt be posted and that it is preferable to finish the importing before possible cleanup. So I am the supporter you dont see, then there is Steak, which is neutral I guess, and then there is 2 of you against. That is not enough for me to change the workflow. If you disagree, then raise it at WD:PC. --Wesalius (talk) 08:43, 5 November 2016 (UTC)
As there is no consensus for your additions, please stop the bot for now.
--- Jura 08:51, 5 November 2016 (UTC)
At the moment it is more important to add all the Elo ratings to be able to include them into the wikipedias. Cleaning up the whole thing, which might or might not comprise also removing the values after death, should be one of the last steps. Could you please cite a FIDE rule which states that only living people can have an Elo rating? Steak (talk) 08:59, 5 November 2016 (UTC)
From what I see here there is no consensus on not adding those ratings as well, therefore your request for block of my bot is not based on anything but your own opinion on the topic. --Wesalius (talk) 09:05, 5 November 2016 (UTC)
It works the other way round.
--- Jura 09:06, 5 November 2016 (UTC)
You are the one who created this artificial constraint, so you should show a consensus on why this is a constraint in a first place. --Wesalius (talk) 09:15, 5 November 2016 (UTC)
You can remove the constraint, but that doesn't dispense you for building consensus for your additions. As a bot operator, you are expected to at least attempt to fix problems with your data. However, from your comments here and on the admin noticeboard, it seems that you are refusing to do that.
--- Jura 09:26, 5 November 2016 (UTC)
You keep talking about variations of "problems with my data". Just calling something a problem doesnt make it a problem. But I am starting to see discussion with you on this topic rather unproductive. Lets see how admins, who you kindly notified, will act on this before discussing more. --Wesalius (talk) 10:05, 5 November 2016 (UTC)
@Jura1: please tone it down a bit, you're not being productive at all.
Does someone have a source for what happens with the elo rating after dead? Does it go to zero instantly because someone died or does it go down slowly because of the lack of activity? Multichill (talk) 10:14, 5 November 2016 (UTC)

I saw Jura's comment on WD:PC and came to have a look at the problem, but I do not (yet) favor any of the options discussed here as long as I do not understand how both this elo number and FIDE work. It would be nice if someone could introduce this to me and other chess laymen, and address the following points:

  • Why does FIDE publish & calculate ELO number of deceased players? Is this done on purpose or just a mistake?
  • Are these numbers calculated for all deceased players?
  • What are the rankings good for after a player deceased?
  • At which point do they stop to calculate rating?
  • In Rudolf Teschner (Q67757) the elo number does not change at all (if I get it right). Is this the same for all deceased players?

Thanks for any answer in advance, and feel free to complement additional questions if necessary. I will form an opinion based on the answers tomorrow. —MisterSynergy (talk) 10:27, 5 November 2016 (UTC)

Elo ratings change only when a player plays a game; the result then increases or decreases the rating (or keeps it the same). A dead person does not play games, so the rating stays constant. It's the same for inactive players. If a player has rating, does not play for 30 years and then starts again, he will have the same rating as 30 years ago. This is useful, because based on this rating the probabilty of the game result will be evaluated and the rating of the opponent will change accordingly, dependend on the result. Having ratings for dead people is hence not strictly wrong, but not necessary, because he will never ever play again and there is no need to evaluate the result of the game anymore.
Consider also, that living active chess players might be delisted from the Elo list (e.g. Kasparov in 1994 because of a controversy). Following Jura, we should give him a rating because he actually had it at that time (but it was not officially published). But of course, we have to rely on the FIDE, which would suggest not to include it in our data. Steak (talk) 10:53, 5 November 2016 (UTC)
Some answers :
  • FIDE keeps the identity card of seme deceased players because it doesn't always know that they died.
  • The rating is calculated only when someone plays games against rated opponents. The new rating is the last rating plus (or minus) a small variations according to the difference of ratings between the players.
The situation for an inactive player can be compared with dead players.
  • When a player doesn't play a game for a whole year, he is considered inactive. He keeps his rating but doen't appear on the active playrs lists.
  • The ratings are useful if the player resumes playing. FIDE stops calculating ratings when there are no games played but keeps the last value.
  • The inactive players keep their last ratings.Cbigorgne (talk) 11:03, 5 November 2016 (UTC)
Why does the ELO rating not simply come with a point in time qualifier? If you want to get data for only active players then just return values where the point in time is more recent than whatever cutoff date you choose. From what I understand, inactive and deceased players do not loose their rating, it just ceases changing and then gets archived, so it seems wrong to delete data - particularly as it will remain valid for historical purposes. Thryduulf (talk) 11:48, 5 November 2016 (UTC)
It seems that they may lack the information about a person's death and so keep posting regularly ratings, even 10 years past DOD. Maybe someone should just provide them with a feed about deaths recorded in Wikidata.
--- Jura 12:01, 5 November 2016 (UTC)
Okay thanks for all the helpful replies. In case you still need input, here’s mine: add the ratings as published by FIDE as the relevant authority for Elo numbers, but mark them deprecated for points of time after the player’s date of death. Technically there shouldn’t be a rating for deceased players, thus I would expect not to get any of these values if I query for that property. A deprecated rank for technically useless, yet existing data procures exactly that. —MisterSynergy (talk) 07:30, 6 November 2016 (UTC)
  • @MisterSynergy: is this your advice for 1 or 2 statements, or >50 as on: Q4320456#P1087 ? I think it might be a sensible approach for inactive ratings (of living players).
    --- Jura 08:04, 6 November 2016 (UTC)
@Jura1: For any number, even if in some cases tons of deprecated data show up on the item page. It is important that actual data users get meaningful results (via query service or in Wikipedias), but item pages itself are tools to work on the item and in that case it is important that editors can see which data (from reputated sources, as in this case) is at all available for the entity—even if the data is technically incorrect and we know about this. —MisterSynergy (talk) 08:26, 6 November 2016 (UTC)
For sources with lots of defective entries, its generally recommended to use the PrimarySources tool. Defective entries can be rejected there and remain in storage for further research.
--- Jura 00:30, 7 November 2016 (UTC)
I think there's an even bigger problem with the ratings for Rudolf Teschner (Q67757). The reference is faulty and gives "Player not found. Please contact National Chess Federation of the player." ChristianKl (talk) 21:33, 6 November 2016 (UTC)
As far as the data goes, is there a good reason to use "point in time" instead of "start time" and "end time"? ChristianKl (talk) 21:33, 6 November 2016 (UTC)
Rudolf Teschner (Q67757) looks really messy given that the bot doesn't add the ELO entries in chronological order. ChristianKl (talk) 21:33, 6 November 2016 (UTC)
Wikidata is a database, for machines to read. It really doesn't matter in which order statements are added. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:46, 7 November 2016 (UTC)
As far as the general policy goes, it was my understanding that bots that add a lot of data should only be run with consensus. Given that the consensus doesn't seem to exist to add data like the ELO rating of Rudolf Teschner (Q67757), please stop the bot. ChristianKl (talk) 21:33, 6 November 2016 (UTC)
  • #1 is a different problem, to be addressed on Property talk:P1440. It looks as if they removed deceased players.
  • #2 would significantly complicate data usage by users (Wikipedias and external).
  • #3 is a limitation of the data model. Claims have no natural order, thus they appear unordered. The problem was addressed on WD:PC a few days/weeks ago and might be “solved” by a gadget or so (in a way that “chronological” data is displayed in an ordered manner in the frontend).
  • #4 is indeed the case, if deprecated rank is used as discussed. —MisterSynergy (talk) 21:54, 6 November 2016 (UTC)
  1. The database dumps include the data, even though FIDE removes player profile from the web view. If we would add the data only for players that have FIDE ID and at the same time have FIDE profile, we wouldnt have the data for Rudolf Teschner (Q67757) at all (even though he has them in the database).
  2. The reason to use point in time is that FIDE publishes the ratings with equivalent of point in time qualifier: rating of player+month it applies to.
  3. The order in which the data is added (if there are no problems such as interruptions caused by tools server reboot) is to be found at Wikidata:WikiProject_Chess/Import#Order_of_elo_rating_import. The messines which you think that is present is as MisterSynergy pointed out, to be addressed by the gadget.
  4. I will add deprecated rank to statements caught by that constraint violation after the import is done. --Wesalius (talk) 05:34, 7 November 2016 (UTC)
I think you missed the main point of ChristianKl's comment: there is no consensus for your bot run. So please stop it now.
--- Jura 10:22, 7 November 2016 (UTC)
You and ChristianKI agreeing on my bot stopping isnt going to make me stop him. How about I require you to stop bothering me with that request... you are not going to stop, right? Same applies for my bot imports unless the admins act on your block request you filled 2 days ago.
Unless you come up with something new and constructive (not just variations on what you have already said) I am not responding to you. --Wesalius (talk) 11:22, 7 November 2016 (UTC)
Well, at least it came out of this discussion that isn't that data is defective, but the dump you are using. Somehow that makes me wonder if your other contributions are as problematic.
--- Jura 11:30, 7 November 2016 (UTC)
The outcome of this discussion is very different for each of us apparently. You are free to wonder about/call problematic any edits made to an open project such as wikidata. --Wesalius (talk) 11:38, 7 November 2016 (UTC)
It might not be enough to get you to stop it, but that likely will lead to the bot getting banned. ChristianKl (talk) 18:01, 7 November 2016 (UTC)
You are explicit about the order in that document. That doesn't mean it makes any sense to order the data by month. Please order it by year instead.
If FIDE removes the data from the webview, it's because they don't think the data is of public interest. As such it's questionable to import it. It's even more problematic to import it and have the bot claim that the data is backed up by the public webview. ChristianKl (talk) 18:01, 7 November 2016 (UTC)
"it's because they don't think the data is of public interest". Whether they think that or not (and the claim is highly doubtable; there are many other reasons why they might do that), there is no prohibition on us adding data which was published, but is no longer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:46, 7 November 2016 (UTC)
There are people for whom daily weight measures are taken. The fact that the data exist, doesn't mean that such person should get a thousand entries about their weight at different days.
On the data donation policy there's a requirement that data *is* Reliable and Publicly available and not just that it was publically available in the past. The policy goes on to say "Wikidata does not include all data available but just a useful subset." I think it's doubtful that having multiple entries passes the "useful" criteria. For a person like Rudolf Teschner (Q67757) there's no use in having "updates" of the ELO score after they died. Any data user could infer on his own that the score doesn't change after the person died (especially if there's no explicit data about it changing).
That policy also says: "Contact the Wikidata community describing what data you have and would like to include in Wikidata", "Decide with the Wikidata community what data is suitable to import." I don't think there's a decision with the commmunity to include redundent ELO scores of dead people.
There's a prohibition on including data with with faulty references. The data in question isn't at (as the reference suggests) but in a data dump. The data dump doesn't get referenced. The statements contain references that are incorrect and no valid references to back up the claim. ChristianKl (talk) 18:58, 8 November 2016 (UTC)
The page you cite is not a policy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:17, 8 November 2016 (UTC)
The reference is not incorrect, the data is available to anyone, right now, you just have to get to the subpage of - (which I dont find confusing, it is pretty clear to me that if you want to download data dump you head to the download section). So the data *is* publicly available. And players are not getting ratings per day but per month. --Wesalius (talk) 20:43, 8 November 2016 (UTC)
I am going to pass on responding to that "bot getting banned" threat since no admin acted upon it even though their attention to this topic is obvious. And I am not changing the order in which the data is imported just because you think that "it doesnt make any sense", because adapting the order every time you or somebody else changes their mind on the "right order" is bad solution because senseful order is obviously subjective. I encourage you to give your input on the mentioned gadget which will reorder the values in your prefered way. --Wesalius (talk) 19:21, 7 November 2016 (UTC)

Meanwhile I came to the conclusion that it makes most sense to actually include all ratings in wikidata, but to mark those which have been published after a players death as "deprecated". Automatic imports would anyways import them, even if they would be removed now, this cannot be really prevented or would be cumbersome at least, so marking them as deprecated is the best solution in my opinion. Steak (talk) 21:37, 4 September 2018 (UTC)

only chess?Edit

Should this property only be used for chess players or also for other games where Elo ratings exist? --Pasleim (talk) 22:44, 26 December 2017 (UTC)

Sort methodEdit

Currently the long list of Elo ratings at Krikor Mekhitarian (Q1190860) is being sorted alphabetically by month name; this is not very useful. Is there a way to change this property so that it sorts the list chronologically, most recent first? —capmo (talk) 12:10, 27 September 2018 (UTC)

It is not true that it is currently sorted alphabetically. And it is not possible to sort in any order. Steak (talk) 19:39, 20 November 2018 (UTC)
Return to "P1087" page.