Wikidata

Wikidata:Property proposal/Match Score

< Wikidata:Property proposal

Match score edit

Originally proposed at Wikidata:Property proposal/Sports

   Withdrawn
DescriptionResult of a sporting match
Data typeMonolingual text
Domainat least tennis match (Q47459169), potentially sports competition (Q13406554), association football match (Q16466010) or any other match type where the score is presented in multiple sets etc., e.g. table tennis (Q3930), badminton (Q7291), squash (Q133201)...
Allowed valuesMonolingual text where points/goal scored by (P1363) is not sufficient, for tennis e.g. 6-3, 7-6(4), the latter indicating a 7 to 4 win in a tie-break
Example 16-3, 4-6, 7-5 -> a "normal" tennis result
Example 26-3, 7-6(4) -> a tie-break result
Example 36-3, 6(4)-7, 6-0 -> a losing tie-break result
Example 4w/o -> default win
Example 56-4, 4-1 ret. -> retirement of the opponent regardless of reason (injury, disqualification,...)
Planned use1) Creation of list of tournament winners, e.g. [1]; 2) Creation of list of tournament wins by player, e.g. [2]
Expected completenesseventually complete (Q21873974)
Robot and gadget jobsBots could harvest the information either from itftennis.com or from the wiki templates

Motivation edit

As per discussion Wikidata:Project chat#Sports tournament results by player/team: especially for racket sports, the use of points/goal scored by (P1363) with various qualifiers is not a very suitable way for sports with multiple sets as the final result. Also, there are too many possible results to create a Q-ID for each one of them (which would be possible with bot support, I suppose - then we should change this proposal).  – The preceding unsigned comment was added by Mad melone (talk • contribs) at 15:38, 2 August 2018‎ (UTC).[reply]

  Notified participants of WikiProject Sport results

  Notified participants of WikiProject Tennis --Mad melone (talk) 06:07, 3 August 2018 (UTC)[reply]

Additional @Pigsonthewing, Jc86035, Unnited meta: due to your earlier contributions to the discussion.--Mad melone (talk) 07:24, 5 August 2018 (UTC)[reply]

Discussion edit

Thanks for the input and that was one of my concerns as well. Would you support the proposal if we followed the approach of having Q-IDs for every possible result? This could look like this: I could rename the proposed property to "Tennis Match Result" with the corresponding tennis result (Q55925693) and a sample of 6-4, 3-6, 6-7(7), 7-6(3), 70-68 (Q55925830) (which of course is the result of the infamous Isner–Mahut match at the 2010 Wimbledon Championships (Q30801). I would ask someone to bot-create all the possible results (at least for best-of-three matches for now, because that will be 99% of the needed results, only men's grand slam results would be best-of-five) and then we could start creating match results and the corresponding lists. Is this fine with you/everyone else?--Mad melone (talk) 06:05, 3 August 2018 (UTC)[reply]
    • @Pigsonthewing, Mad melone: I think the simplest option is to enter the score in text, for now. You would have to have thousands of permutations for tie breaks and walkovers, and at the end of the day the actual data (including each individual point of each game) should ideally be hosted on Commons. Furthermore, if you really did want this to be structured, you would have to have specific properties on each match item for the games won in each set, and at that point it would probably be better to just put that data into the individual items. (A "set score" property combined with series ordinal (P1545) would probably work to some extent, with a "tie break score" as qualifier, but this would be very tedious to input manually.) Jc86035 (talk) 07:53, 5 August 2018 (UTC)[reply]
  InfoIf we consider best-of-three matches only (which would cover 98% of our cases) and limit ourselves to a maximum score of 8-6 in a potential tiebreak, then we would have roughly 4,500 (exactly 4,563 from 13 options per set with 13² = 169 options for straight set wins and 2*13³ = 4,394 options for a three-set win). This could easily be created by a bot within minutes and every other required result could be added manually.
      • I am actually leaning towards POTW's idea of items, but I am seeking more approval before I change the proposal accordingly. However, I would like to get started implementing this rather sooner than later. --Mad melone (talk) 09:45, 5 August 2018 (UTC)[reply]
  • Per others: this should be done well-structured, not text-based, and preferably set-based instead of match-based. Items for all possible set scores (not match scores) should be doable, and then the result could be added with an item-type "set score" property (to be created) and qualifiers as suggested by User:Jc86035. —MisterSynergy (talk) 22:22, 7 August 2018 (UTC)[reply]

MisterSynergyJust so that I understand: you propose a structure like the following:

I think this is the best solution so far, as this could be used in both player's and tournament's lists and could in addition be the potential solution to create complete tournament draws in WD. If you agree, what is the best idea to go forward? Change this proposal or abort this proposal and start a new one?--Mad melone (talk) 15:41, 10 August 2018 (UTC)[reply]

Yes like this with regards to the set score representation. However, the results (P2501) qualifiers do not work like this, please use ranking (P1352) qualifiers with values 1 or 2 instead. You can open a new property proposal at Wikidata:Property proposal/set score mentioning this one, which might be closed as not done if necessary. —MisterSynergy (talk) 16:00, 10 August 2018 (UTC)[reply]
@MisterSynergy, Mad melone: For the value of the "set score" property I would prefer numeric values with qualifiers (e.g. set score → "6" with qualifiers series ordinal (P1545) → "1", participant (P710) → Serena Williams (Q11459)). This avoids the parsing of superfluous items and avoids any confusion with regards to who won the set. Jc86035 (talk) 18:00, 11 August 2018 (UTC)[reply]
Seems overkill to me, to be quite honest. However, I would like to seek a good compromise before creating the potential new proposal, so any additional input is welcome.--Mad melone (talk) 20:36, 11 August 2018 (UTC)[reply]
@Mad melone: It's not really overkill. Semantically, the label of an item means nothing, so you would still need some way of representing with another property that the set's winner won six games, so then you'd have to create two properties where one would suffice; and interpretation of the data would then also require the match winner to be looked up and three to five extra items (for each score) to be interpreted. Jc86035 (talk) 10:59, 12 August 2018 (UTC)[reply]
Difficult problem indeed, I am not sure at this point which one would work better. I think that anyone using such data on a larger scale would hard-code the set score items into their code anyway (e.g. a Wikipedia lua module), so that they probably won’t be interpreted each time. Having two symmetrical items 6-3 and 3-6 would simplify things a lot, as the order of the players would only have to be defined once per match, not per set. Still, one had to define "player 1" and "player 2" somehow… Nevertheless, my feeling is that an item-based approach would be easier to query…
On the other hand, how would a quantity-based approach look like? Could you provide an example, please? Thanks, MisterSynergy (talk) 16:25, 12 August 2018 (UTC)[reply]
My proposal was actually to have a "3-6" item as well. Player 1 and Player 2 can be defined easily: Player 1 is the winner and player 2 is the loser. Please see my earlier example where both players are defined as particpants with a qualifier regarding their success. So it would always be clear if I have a "6-3" for set 1, a "3-6" for set 2 and a "6-4" for set three how the actual result will look like. Winner of the set is always the person with more points. Also, I strongly advise for a scoreline like "7-6(4)" for a tie-break win and not have a special score set for the tiebreak. This notation is standard and also distinct.--Mad melone (talk) 17:39, 12 August 2018 (UTC)[reply]

  InfoPlease abort in favor of Wikidata:Property proposal/set score--Mad melone (talk) 12:02, 14 August 2018 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Match_Score&oldid=784008148"