Wikidata:Property proposal/Best result in tournament

From Wikidata
Jump to navigation Jump to search

[edit]

Return to Wikidata:Property proposal/Sports

   Under discussion
Descriptionbest achievement in a sports competition
Representstennis player (Q10833314)
Data typeItem
Template parameteren:Template:Infobox_tennis_biography
*AustralianOpenresult
*FrenchOpenresult
*Wimbledonresult
*USOpenresult
Domainhuman (Q5)
Allowed valuesAustralian Open, Wimbledon Championships, French Open, US Open
Example 1Jeļena Ostapenko (Q5551564)Australian Open (Q60874)
Example 2Jarkko Nieminen (Q10270)US Open (Q123577)
  • sport (P641): tennis doubles (Q18123885)
  • point in time (P585): 2008
  • results (P2501): quarter-final (Q51590545)
  • Example 3Marta Kostyuk (Q28535267)Australian Open (Q60874)
  • sport (P641): tennis singles (Q18123880)
  • point in time (P585): 2018
  • results (P2501): Third round (to be created)
  • Planned useadd it to all tennis player articles who have competed in grand slam tournaments

    Motivation[edit]

    Really useful to store info of success in grand slam tennis tournaments on Wikidata instead of updating it to every Wikipedias. Stryn (talk) 13:49, 16 October 2018 (UTC)

    Discussion[edit]

    From my experience in the field of sports results, this does not look like a good idea for several reasons:

    • results (P2501) and sport (P641) are not supposed to be used like that; use stage reached (P2443) and preferrably competition class (P2094) (alternatively sports discipline competed in (P2416)) instead.
    • The meaning of point in time (P585) is not clear either; does it apply to the point when the result was achieved (your intention, as far as I can tell), or when it is valid?
    • It really looks difficult to maintain in good shape
    • Furthermore, superseded data would have to be deprecated or removed or updated, but preferrably we do not need to do this at all; at least not at such a scale.
    • Alternative suggestion: add all participation information with participant of (P1344) and event items (like 2018 Wimbledon Championships – Women's Singles (Q30098268), add appropriate qualifiers (stage reached (P2443) and/or ranking (P1352)). Most other data like point in time (P585), competition class (P2094) (which you meant with “sport” above) and the connection to 2018 Wimbledon Championships (Q30085309) via part of (P361) belong to the event item.
      • Some more theoretical background: the main question here is how and where to aggregate data. This proposal aims to store already aggregated data in Wikidata, so that the users do not have to (and cannot) aggregate by themselves. However, it is much more efficient to store un-aggregated original data (as suggested by me), and let the user do the aggregation. This allows users to retrieve different aggregation from the same data set; here, for instance, one could ask for "number of wins per Grand Slam tournament", "list of Grand Slam wins", or even things like "number of Grand Slam semi-final appearances" and so on, all from the same set of claims. If one stores already aggregated data in Wikidata, each of those would have to have its own property, which isn’t really practical of course. For that reason, it is in most situations preferrable not to store aggregated data in Wikidata; things like "number of X" (equivalent to COUNT() in SPARQL), "total prize money won" (SUM()), "best of Y" (MAX()) or "list of Z" (GROUP_CONCAT()), and so on should be done by the users, if ever possible. Which definitely is the case here, as the number of Grand Slam participations per player (or even tennis tournament participations) is relatively low even for longer professional careers.
    • A Wikipedia template would then have to loop over all participation data to figure out the best results. If SPARQL from Lua was available this would be easier to do, but right now we don’t have it.

    MisterSynergy (talk) 18:33, 16 October 2018 (UTC)

    • Symbol support vote.svg Support David (talk) 07:04, 17 October 2018 (UTC)
    • I agree with User:MisterSynergy that this looks like a property that should be created by querying other data, not having a property in its own right. I lean to oppose, but would like to see some replies to MisterSynergy's points. MartinPoulter (talk) 14:47, 22 October 2018 (UTC)