Property talk:P1087

Documentation

• Start a query
• Current uses
• Statistics by class
• Units
• Scale of values
• List of qualifiers
• Count

Elo rating
quantitative measure of one's game-playing ability, particularly in classical chess

Represents	Elo rating system (Q105955)
Data type	Quantity
Template parameter	de:Vorlage:Elo-Punkte
Domain	human (Q5) or computer program (Q40056)
Allowed values	1,000 ≤ 𝓧 ≤ 2,900
Allowed units	not applicable
Example	Magnus Carlsen (Q106807) → 2,887 Judit Polgár (Q183250) → 2,675
Tracking: usage	Category:Pages using Wikidata property P1087 (Q23909052)
Lists	Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Minimum and maximum Items with highest numeric value Items with lowest numeric value Map of people by place values: place of birth educated at work location residence place of death place of burial January 1st dates People with date of birth on January 1 People with date of death on January 1 People with both dates on January 1 Database reports/Complex constraint violations/P1087 Database reports/Humans with missing claims/P1087 Database reports/Constraint violations/P1087 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 3,037,696 Main statement 3,037,693 >99.9% of uses Qualifier 3 <0.1% of uses

[create Create a translatable help page (preferably in English) for this property to be included here]

Type “human (Q5), computer program (Q40056)”: item must contain property “instance of (P31)” with classes “human (Q5), computer program (Q40056)” or their subclasses (defined using subclass of (P279)). (Help)

List of violations of this constraint: Database reports/Constraint violations/P1087#Type Q5, Q40056, hourly updated report, SPARQL

Units: “novalue”: value unit must be one of listed. (Help)

List of violations of this constraint: Database reports/Constraint violations/P1087#Units, hourly updated report

Range from “1000” to “2900”: values should be in the range from “1000” to “2900”. (Help)

List of violations of this constraint: Database reports/Constraint violations/P1087#Range, hourly updated report

Required qualifier “point in time (P585)”: this property should be used with the listed qualifier. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1087#mandatory qualifier, SPARQL

Item “sport (P641): chess (Q718), correspondence chess (Q1128406)”: Items with this property should also have “sport (P641): chess (Q718), correspondence chess (Q1128406)”. (Help)

List of violations of this constraint: Database reports/Constraint violations/P1087#Item P641, hourly updated report

No bounds: values can't have any bounds (e.g. 1 not 1±0) (Help)

List of violations of this constraint: Database reports/Constraint violations/P1087#No Bounds, hourly updated report, SPARQL

Integer: values should be integers (ie. they shouldn't have a fractional part) (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1087#integer, SPARQL

Single value: this property generally contains a single value. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1087#Single value, SPARQL

Scope is as main value (Q54828448): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1087#Scope, SPARQL

Citation needed: the property must have at least one reference (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1087#citation needed

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1087#Entity types

Qualifiers “point in time (P585), reason for deprecated rank (P2241)”: this property should be used only with the listed qualifiers. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1087#allowed qualifiers, SPARQL

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

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

Elo ratings without proper source
Elo ratings that do not have either a link to ratings.fide.com or olimpbase.org. 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

Elo ratings without retrieval date (1)
Elo ratings without retrieval date (using ratings.fide.com) (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)

Elo ratings without retrieval date (2)
Elo ratings without retrieval date (using olimpbase.org) (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)

Elo ratings with wrong date precision
Elo ratings with a date qualifier that has not month precision (Help)
Violations query: SELECT DISTINCT ?item ?date { ?item p:P1087 ?p1087_statement . ?p1087_statement pqv:P585 ?datenode . ?datenode wikibase:timeValue ?date . ?datenode wikibase:timePrecision ?precision . FILTER( ?precision != "10"^^xsd:integer ) }
List of this constraint violations: Database reports/Complex constraint violations/P1087#Elo ratings with wrong date precision

Discussion

Preferred value: Highest or most recent?

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)

Frankly, I can't see that there's any consensus for not including a preferred status. IMHO, the most recent rating (including its date, of course) should be set to preferred as it best reflects up-to-date information about the players. Asav (talk) 08:18, 27 May 2020 (UTC)

I ran into this problem trying to actually use the data to answer a question. From that perspective, getting dozens of results for every person was somewhat surprising. What's even more surprising is the unilateral decision to actively remove ranks when just about everybody here and in other discussions is in favor of using ranks in some form.

Prefered rank should be afforded to the latest available score. I can see how the maximum would also make sense, and I wonder if using the latest would lead to some distortion if, for example, professional people retire and their score slowly drops as they only play casually, no longer train, etc. What tips the balance is that using latest data is more in line with usual practices, it is entomologically ontologically closer to correctness, as well, being single value for which the statement is actually true today: the maximum score answers a slightly different question, and one could think about a property to capture that value. As a practical matter, getting a maximum through the query service is easier than getting a latest value.

Considering the technical problems that go along with the growth in data both at WD as well as any data processing on the consumer side, I would also suggest to avoid redundant data where the value does not change, and to qualify such values with the dates in question. As a side benefit, this would eliminate the trouble concerning dead players, as far as I can see. --Matthias Winkelmann (talk) 10:16, 18 November 2020 (UTC)

Rudolf Teschner : ratings after death

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 ratings.fide.com (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 ratings.fide.com - https://ratings.fide.com/download.phtml (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?

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 method

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)

Using P580 and P582

Having scrolled the rather long list of Elo points on Q28150053, where all the statements record the same value, would it make sense to allow for start time (P580) and end time (P582) as qualifiers so as to get rid of a few dozens of statements? --Jahl de Vautban (talk) 21:27, 18 January 2024 (UTC)

Preferred values

I would like to ask, why are no preferred used? Using the latest value as the preferred one would also facilitate getting this value for infoboxes in various projects Konstantina07 (talk) 12:43, 22 February 2024 (UTC)