Wikidata:Property proposal/set score
Jump to navigation
Jump to search
Set score[edit]
Originally proposed at Wikidata:Property proposal/Sports
Not done
| Description | Result of a set as part of a sports match |
|---|---|
| Data type | Item |
| Domain | any type of sports for which the result is presentedin sets, e.g. tennis match (Q47459169), but also possible equivalents for sports like table tennis (Q3930), badminton (Q7291), squash (Q133201) and alike |
| Allowed values | Q-Items representing match results, e.g. 6-3 (Q56044542) as an instance of tennis result (Q55925693) with values from 6-0, 6-1,...7-5 and potential tie-break results such as 7-6(0), 7-6(1),... each for winning and losing sets. These are abviously examples for tennis, but could easily be expanded to other sports with other scoring rules. |
| 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]
(Setze deine Begründung für diese Eigenschaft hier her) Mad melone (talk) 12:01, 14 August 2018 (UTC)
Discussion[edit]
Please see discussion of Wikidata:Property proposal/Match Score which is not to be aborted. Especially, a structure of a tennis match result could look as follows:
- 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)
After all the discussion already having taken place, I hope for a quick approval. Kind regards, --Mad melone (talk) 12:01, 14 August 2018 (UTC)
- I agree that this property should exist, but I still don't think that we need items for each combination of scores. Number datatype should be fine (e.g. statement set score → "6" with qualifiers series ordinal (P1545) → "1", participant (P710) → Serena Williams (Q11459); @MisterSynergy: was this what you meant by "quantity-based approach"?). Jc86035 (talk) 14:15, 14 August 2018 (UTC)
- I would be fine with your suggested approach.--Mad melone (talk) 09:54, 15 August 2018 (UTC)
- Yes, this is what I meant with "quantity-based approach"; see my comment below as well. —MisterSynergy (talk) 13:25, 15 August 2018 (UTC)
To clarify, the original proposal is
| [set score] |
| ||||||||||
| add value | |||||||||||
whereas my preferred approach would be
| [set score] |
| |||||||||||||||||||||||||||
| add value | ||||||||||||||||||||||||||||
Jc86035 (talk) 11:26, 15 August 2018 (UTC) Confirmed--Mad melone (talk) 12:06, 15 August 2018 (UTC)
- Thanks, but I am not convinced. Compared to the item-based approach outlined above, this one doubles the amount of required claims and the amount of required qualifiers per claim. Scores do not necessarily need to be well sorted, which makes it difficult to get at first glance whether everything is okay with this result or not (men’s matches would often require ten set score claims). I also think that it might be more difficult to ensure data quality with constraints, compared with an item-based approach of finitely many set score items. Mind that this proposal is not limited to tennis matches, so it is difficult to define a useful range constraint for the properties.
Nevertheless, I think we should have such a property, thus I support this proposal and the discussion to find the best solution. —MisterSynergy (talk) 13:25, 15 August 2018 (UTC)- For clarity purposes: I am also pro item based approach, but would be able to live with the quantity based approach - seems to me easier to maintain and populate. Still, I just want to have this property to build some cool stuff in Wikipedia.--Mad melone (talk) 15:15, 15 August 2018 (UTC)
- @Mad melone, MisterSynergy: So how would the score items indicate the number of points in each set? Do we need another property for this or would number of points/goals/set scored (P1351) be used? Jc86035 (talk) 17:24, 15 August 2018 (UTC)
- I am not sure whether I understand the question, but I would create items for each possible set score (which is not that many, at least not for tennis), once for winning a set and once for losing a set, and then proceed as shown in my example above. However, I also understand that the quantity based approach is a lot more flexible when it comes to covering various sports with various possible score lines (including e.g. volleyball where the fifth set has less points than the first four sets...). So my mind is not yet made up and I am really looking on further outside views.--Mad melone (talk) 17:54, 15 August 2018 (UTC)
- I would aim for sports-specific set score items, in order to keep this maintainable. This means that 6-3 (Q56044542) would be used for tennis only, but volleyball would get its own "6-3" item (imagine that was possible, which it actually isn’t AFAIK). The advantage would be that all types of sports would follow the same model, but using their own set of items. In a tennis-related lua module, one could possibly hard-code all tennis-related set score items into the code, making expensive lookups unnecessary. —MisterSynergy (talk) 18:45, 15 August 2018 (UTC)
- I had a couple of additional thoughts on this. If you want to hard-code a lua module with all possible scores, that could be difficult. Reason is that once in a while there will be "new" results, especially regarding possible "retired" results which can happen at any point during a set, e.g. because of injury, or regarding relatively high scores in a tiebreak or a deciding last set during the grand slams (except US Open) which will be played out until one player leads by two games and no tiebreak being played. If this can be fixed very quickly, then I am onboard, but I would hate to see a good solution fail because some LUA code is not being well maintained.--Mad melone (talk) 20:30, 21 August 2018 (UTC)
- I would aim for sports-specific set score items, in order to keep this maintainable. This means that 6-3 (Q56044542) would be used for tennis only, but volleyball would get its own "6-3" item (imagine that was possible, which it actually isn’t AFAIK). The advantage would be that all types of sports would follow the same model, but using their own set of items. In a tennis-related lua module, one could possibly hard-code all tennis-related set score items into the code, making expensive lookups unnecessary. —MisterSynergy (talk) 18:45, 15 August 2018 (UTC)
- Jc86035, I will look for a solution later. —MisterSynergy (talk) 18:45, 15 August 2018 (UTC)
- I am not sure whether I understand the question, but I would create items for each possible set score (which is not that many, at least not for tennis), once for winning a set and once for losing a set, and then proceed as shown in my example above. However, I also understand that the quantity based approach is a lot more flexible when it comes to covering various sports with various possible score lines (including e.g. volleyball where the fifth set has less points than the first four sets...). So my mind is not yet made up and I am really looking on further outside views.--Mad melone (talk) 17:54, 15 August 2018 (UTC)
- @Mad melone, MisterSynergy: So how would the score items indicate the number of points in each set? Do we need another property for this or would number of points/goals/set scored (P1351) be used? Jc86035 (talk) 17:24, 15 August 2018 (UTC)
- For clarity purposes: I am also pro item based approach, but would be able to live with the quantity based approach - seems to me easier to maintain and populate. Still, I just want to have this property to build some cool stuff in Wikipedia.--Mad melone (talk) 15:15, 15 August 2018 (UTC)
Any update here?--Mad melone (talk) 11:26, 18 August 2018 (UTC)
- What is needed to get a consensus and move ahead?--Mad melone (talk) 20:54, 31 August 2018 (UTC)
- There is Topic:Uj1vlssgzgys5alb on your talk page, where you indicating that you’re trying to get full tennis results in Wikidata. Well, great idea but very difficult. The seed property proposal is also motivated by this, but I am not sure whether we are anywhere close to a workable solution. In some sense this property proposal implies to create an item for each tennis match and for each players that ever participated at one of the big tennis tours. I think that quite some of such data would theoretically fit into this project, but there are potentially really large amounts of items to be created. Are you aware of that? —MisterSynergy (talk) 21:11, 31 August 2018 (UTC) I still support this property proposal.
- I am aware of this and I would be happy to support any other way of representing set results within Wikidata--Mad melone (talk) 13:01, 8 September 2018 (UTC)
- There is Topic:Uj1vlssgzgys5alb on your talk page, where you indicating that you’re trying to get full tennis results in Wikidata. Well, great idea but very difficult. The seed property proposal is also motivated by this, but I am not sure whether we are anywhere close to a workable solution. In some sense this property proposal implies to create an item for each tennis match and for each players that ever participated at one of the big tennis tours. I think that quite some of such data would theoretically fit into this project, but there are potentially really large amounts of items to be created. Are you aware of that? —MisterSynergy (talk) 21:11, 31 August 2018 (UTC) I still support this property proposal.
Comment Wikidata:Property_proposal/Seed was created (though no idea what this meant]). Stryn (talk) 12:48, 16 October 2018 (UTC)- I support creating this property and using quantities instead of items. Stryn (talk) 12:48, 16 October 2018 (UTC)
Not done the discussion has stalled for a few months and there does not seem to be a consensus about how to store this information. Feel free to reopen (or create a new proposal) if new solutions arise. − Pintoch (talk) 20:41, 6 March 2019 (UTC)
