Wikidata:Property proposal/Match Score
Match score
[edit]Originally proposed at Wikidata:Property proposal/Sports
Description | Result of a sporting match |
---|---|
Data type | Monolingual text |
Domain | at 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 values | Monolingual 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 1 | 6-3, 4-6, 7-5 -> a "normal" tennis result |
Example 2 | 6-3, 7-6(4) -> a tie-break result |
Example 3 | 6-3, 6(4)-7, 6-0 -> a losing tie-break result |
Example 4 | w/o -> default win |
Example 5 | 6-4, 4-1 ret. -> retirement of the opponent regardless of reason (injury, disqualification,...) |
Planned use | 1) Creation of list of tournament winners, e.g. [1]; 2) Creation of list of tournament wins by player, e.g. [2] |
Expected completeness | eventually complete (Q21873974) |
Robot and gadget jobs | Bots 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).
Notified participants of WikiProject Sport results
Notified participants of WikiProject Tennis --Mad melone (talk) 06:07, 3 August 2018 (UTC)
Additional @Pigsonthewing, Jc86035, Unnited meta: due to your earlier contributions to the discussion.--Mad melone (talk) 07:24, 5 August 2018 (UTC)
Discussion
[edit]- Oppose as proposed. The examples need to be items on Wikidata; and the example values should, probably, be items - monolingual text for such cases is not structured data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:11, 2 August 2018 (UTC)
- 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)
- @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)
- 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)
- 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)
MisterSynergyJust so that I understand: you propose a structure like the following:
- A. Kerber vs S. Williams Wimbledon Women's Singles Final 2018
- instance of (P31) -> tennis match (Q47459169)
- part of (P361) -> 2018 Wimbledon Championships – women's singles (Q30098268)
- participant (P710) -> Angelique Kerber (Q77178)
- participant (P710) -> Serena Williams (Q11459)
- set score (to be created) -> 6-3 (Q56044542)
- set score (to be created) -> 6-3 (Q56044542)
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)
- 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
or2
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)- @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)
- 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)
- @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)
- 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)- 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)
- 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…
- @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)
- 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)
- @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)
InfoPlease abort in favor of Wikidata:Property proposal/set score--Mad melone (talk) 12:02, 14 August 2018 (UTC)
- marking as withdrawn − Pintoch (talk) 14:54, 7 November 2018 (UTC)