Wikidata:Property proposal/classifications
Classifications
[edit]- Motivation
I decide to make today this big property proposal, but I should do it since June but I already say tomorrow... Thanks to Molarus and a group of different users coming from different Wikipedias, the algorithm Module:Cycling race is developed since December, and able to work on around 20 Wikipedias, even if we always need help to make translations in other languages (candidates ?). We have now around 3500 lines of code that correspond to nine functions. The last function, again on development, is Template:Cycling race/stageinfobox (Q27093254). The concept is always the same : one line of code in the article permits to display a complete table, and this line can/should works in around twenty langages. The global is to spend less time with datas to spend more time to write text or to create more articles. It is the first time that it is possible to do this, and it works very well.
Today, I launch this property proposal because I need additional properties to be able to do all the classifications. For this, I verify the different types of classifications in 1960, 1970, 1980, 1990, 2000 and 2010 for the Tour de France, the Giro d'Italia and the Vuelta a Espana. ProCyclingStats and different websites or newspaper gives us the results for different classifications, we have properties for these databases. We are already able to do very good work for single days race, see fr:Amstel Gold Race 1980. I give example about old races to show it is possible to work with all races. For races as fr:Tour de France 1980, we are not able to work with other classifications because we don't have these properties.
Now, I will give you the work that was already done for classifications : general classification of race participants (P2321) permits us to develop Template:Cycling race/generalclassification (Q24788750), stage classification (P2417) Template:Cycling race/stageclassification (Q24788814) for classic stages and Template:Cycling race/teamtimetrialclassification (Q26776118) when it is a time trial, so where teams are classified. We have developed the idea where the classifications must be on the page of the item of the race, and where it is very easy to prepare an article and translate it. We plan to create the functions points classification, sprintsclassification, mountainclassification, youthclassification, teamclassification, teamclassificationbypoints... and we hope the more users will come to translate few lines, use them in their Wikipedias, and enter datas when it is necessary. Jérémy-Günther-Heinz Jähnick (talk) 13:46, 3 November 2016 (UTC)
- Discussion
- * can this be done just with qualifiers on general classification of race participants (P2321) rather than this long list of new properties? Also it would be nice to see real concrete examples (your "See belows" don't point to anything concrete) so those not familiar with cycling races can understand a little better what this is about... ArthurPSmith (talk) 20:30, 4 November 2016 (UTC)
- No, it is not possible to do this way, because we cannot have qualifiers of qualifiers (it is even a problem for the moment to do startlists with finishing places, jerseys, and directeurs sportifs). To give you an example of classification, you can follow this link that concern the 2016 Eneco Tour, Stage 7 (Q26846397). You even have a classification for the stage classification (P2417). The article fr:Eneco Tour 2016 was made with Wikidata, but if you look at fr:Eneco Tour 2015, you will see we have other classifications to do with Wikidata and these classifications are different from the general classification. Not only the system is different (we can have points instead of time, we can have teams instead cyclists) but the order of cyclists is also different. Moreover, the property is called general classification, not points classification or other. I decide to made an unique proposal, but I could do one proposal by month, it would have been the same but it would have take more time. You will find another example about the Tour de France 2016. The idea is to have functions about classifications to centralise them and save time. Jérémy-Günther-Heinz Jähnick (talk) 16:35, 5 November 2016 (UTC)
- Please provide specific examples. ChristianKl (talk) 22:58, 16 November 2016 (UTC)
- Two alternatives which could also be applied to other sports and which wouldn't have the risk to cause performance problems (imagine 200 cyclists * 5 classifications and each claim with qualifier and reference):
- Create for each classification and stage an own item. We then only need an appropriate property to link from a stage item to its classification items.
- Store only the winner of each classification on Wikidata and store the complete classifications for all stages as a table in the Data-namespace on Commons. (data namespace isn't yet deployed but it will come soon and with a spreadsheet-like user interface it will certainly make editing of tabular-like data easier than on Wikidata.) --Pasleim (talk) 10:20, 29 November 2016 (UTC)
I Support the creation of these new functions. It will be a lot easier to hold small wikis as da.wiki, updated with these classifications with data from Wikidata. --Hejsa (talk) 16:04, 21 December 2016 (UTC)
I also thought like ArthurPSmith because I also prefer to keep the properties "slim", but Jeremy is right, it is not possible to do qualifier of qualifier. So we don't really have another choice to centralize this information. Psemdel (talk) 22:01, 21 December 2016 (UTC)
- I also Support the creation of these new functions. Kind regards from the Faroese Wikipedia EileenSanda (talk) 00:10, 24 December 2016 (UTC)
- I'm agree ! Anthony59999 (talk) 20:43, 25 December 2016 (UTC)
@Jérémy-Günther-Heinz Jähnick: Before you ask further people to vote on this proposal [1] [2] [3], could you please comment on my two alternatives suggestions above? I wrote down these alternatives because I really think you will run into performance problems with these nine properties since Wikidatat isn't designed to store hundereds of claims on a single item. --Pasleim (talk) 22:07, 25 December 2016 (UTC)
- Easy, we already have one item by stage if we have a stage race. It is compulsory to display the list of stages, see fr:Tour de France 1980. Datas are established on at least 26 items (in reality it is very more, because teams and nationalities are stored in cyclists' items, idem for the country and the official name of a team...). For all the biggest stage races, we generally have a maximum of five secundary classifications, see fr:1re étape du Tour de France 2015 or fr:20e étape du Tour de France 2014. Intermediar classifications will be stored on other items, we already have properties to do this. It concern only the three major races, so it is not a problem, moreover we have more workforce for these three races. We will never find these nine properties on a single race, there are changes between races, and even following the time. Another fact is users generally fill the classifications until the 10th, so I can't imagine we have to store hundreds of claims on a single item. For the major part of our users, the major classification will always be the general classification, not these secundary classifications. If they choose to spend time to make bigger classifications, they will do this only for general classification, and only for the general classification at the end of the race, as fr:Flèche wallonne 1980. It is just a question of time and workforce. And they add datas on Wikidata because they are able to reuse them in their Wikipedias very easily. For the major part of races, see fr:UCI Europe Tour 2016, we have only one or two user that do for a given race all the work, so it is better when the system is very easy. For an article such as fr:Tour de Wallonie 2016, a good example of classic stage race, we will have only one number of item for all the final classifications, and this will permit to users that don't speek French or English or that use another alphabet to understand on Wikidata what is this precise classification, because we have a kit to translate (we keep the problem for the intermediar classifications of the three bigger races, but not all the Wikipedias do articles about stages, maybe a day). Jérémy-Günther-Heinz Jähnick (talk) 10:58, 26 December 2016 (UTC) PS : there is no interest (and no projects) to display the complete classifications, and I think if I do it I will have problems on some Wikipedias. I already think at the idea to store PDF of all classifications on Wikimedia Commons (it is possible, more sure than the UCI website, and on some race we have complete and detailed documentation), but I already think that one or two users will come and say "classifications are not published under a free licence" (I see this year a scan of a list of participating riders disappear by the intervention of Rama for "obvious privacy reasons", yes, it is not a joke).
- What an easy system is depends always on the use case. If you plan to store only the results up to the 10th without references this might be the easiest system. However, if a user wants to go further, wants to have a reference for each statement and wants to have complete classifications, this won't be anymore an easy system. Try for example to open Q21558717 and you see how difficult it can be to edit large items. You might also want to read the recent comments by User:Daniel Kinzler (WMDE) on phabricator:T151334. --Pasleim (talk) 11:14, 29 December 2016 (UTC)
- In facts, my system doen't impeach an user to create one separeted item, uses points classifications for example and makes a big classification. The reality is it will not arrive as I say, and even if it arrives, we will have first problems on Wikipedias because there is a limit of 500 function expensives. We already have problem for a race with five stages. This is why I see the probability of an user making big classifications is very low. And for the moment, the problem is to obtain the raise of this limit. Jérémy-Günther-Heinz Jähnick (talk) 18:30, 29 December 2016 (UTC)
- What an easy system is depends always on the use case. If you plan to store only the results up to the 10th without references this might be the easiest system. However, if a user wants to go further, wants to have a reference for each statement and wants to have complete classifications, this won't be anymore an easy system. Try for example to open Q21558717 and you see how difficult it can be to edit large items. You might also want to read the recent comments by User:Daniel Kinzler (WMDE) on phabricator:T151334. --Pasleim (talk) 11:14, 29 December 2016 (UTC)
- Easy, we already have one item by stage if we have a stage race. It is compulsory to display the list of stages, see fr:Tour de France 1980. Datas are established on at least 26 items (in reality it is very more, because teams and nationalities are stored in cyclists' items, idem for the country and the official name of a team...). For all the biggest stage races, we generally have a maximum of five secundary classifications, see fr:1re étape du Tour de France 2015 or fr:20e étape du Tour de France 2014. Intermediar classifications will be stored on other items, we already have properties to do this. It concern only the three major races, so it is not a problem, moreover we have more workforce for these three races. We will never find these nine properties on a single race, there are changes between races, and even following the time. Another fact is users generally fill the classifications until the 10th, so I can't imagine we have to store hundreds of claims on a single item. For the major part of our users, the major classification will always be the general classification, not these secundary classifications. If they choose to spend time to make bigger classifications, they will do this only for general classification, and only for the general classification at the end of the race, as fr:Flèche wallonne 1980. It is just a question of time and workforce. And they add datas on Wikidata because they are able to reuse them in their Wikipedias very easily. For the major part of races, see fr:UCI Europe Tour 2016, we have only one or two user that do for a given race all the work, so it is better when the system is very easy. For an article such as fr:Tour de Wallonie 2016, a good example of classic stage race, we will have only one number of item for all the final classifications, and this will permit to users that don't speek French or English or that use another alphabet to understand on Wikidata what is this precise classification, because we have a kit to translate (we keep the problem for the intermediar classifications of the three bigger races, but not all the Wikipedias do articles about stages, maybe a day). Jérémy-Günther-Heinz Jähnick (talk) 10:58, 26 December 2016 (UTC) PS : there is no interest (and no projects) to display the complete classifications, and I think if I do it I will have problems on some Wikipedias. I already think at the idea to store PDF of all classifications on Wikimedia Commons (it is possible, more sure than the UCI website, and on some race we have complete and detailed documentation), but I already think that one or two users will come and say "classifications are not published under a free licence" (I see this year a scan of a list of participating riders disappear by the intervention of Rama for "obvious privacy reasons", yes, it is not a joke).
Support I've been waiting for this property to all the classifications. It will be very helpful to stage and general classification. Thanks! Douglasfugazi (talk) 16:56, 26 December 2016 (UTC)
Oppose this has been sitting in proposal stage for almost 2 months now without anybody taking care to properly fill out the documentation for each; this makes it impossible for a property creator to do their job if this preparatory work hasn't been done. Please look at other property proposals that are currently open and fix all the attributes in the documentation template - there should be no "See below" or "for example", they should be explicitly given. Allowed values should be a class (human (Q5) I assume), not a person with "for example". Etc. I have stated opposition to these proposals here; if these problems are fixed I may change that vote. ArthurPSmith (talk) 19:35, 26 December 2016 (UTC)
- Yes, it is a very good idea. I start the work this morning and will continue this afternoon. Jérémy-Günther-Heinz Jähnick (talk) 10:13, 27 December 2016 (UTC)
- ok, that's somewhat improved (for the ones that have been changed) but the examples are still not right - for example on "points classification" I would expect an example that uses the new property - either 'Person A' -points classification- 'value A' or if it's intended as a qualifier, 'Person A' -other property- 'value A' -points classification- 'value B'. ArthurPSmith (talk) 14:29, 27 December 2016 (UTC)
- Done, you are free to make improvements. Note that all classifications are very similar. At a property of classification, we associate a cyclist, and at this cyclist we give different qualifiers. The first, compulsory, is the rank, other are related to time, points, speed, and we can give a team if the cyclist run for a different team, or add a jersey if it is necessary. Jérémy-Günther-Heinz Jähnick (talk) 19:01, 27 December 2016 (UTC)
- @ArthurPSmith, Jérémy-Günther-Heinz Jähnick: I just splited the proposal in 9 different proposals. --Fralambert (talk) 17:07, 1 January 2017 (UTC)
- Done, you are free to make improvements. Note that all classifications are very similar. At a property of classification, we associate a cyclist, and at this cyclist we give different qualifiers. The first, compulsory, is the rank, other are related to time, points, speed, and we can give a team if the cyclist run for a different team, or add a jersey if it is necessary. Jérémy-Günther-Heinz Jähnick (talk) 19:01, 27 December 2016 (UTC)
- ok, that's somewhat improved (for the ones that have been changed) but the examples are still not right - for example on "points classification" I would expect an example that uses the new property - either 'Person A' -points classification- 'value A' or if it's intended as a qualifier, 'Person A' -other property- 'value A' -points classification- 'value B'. ArthurPSmith (talk) 14:29, 27 December 2016 (UTC)
- Yes, it is a very good idea. I start the work this morning and will continue this afternoon. Jérémy-Günther-Heinz Jähnick (talk) 10:13, 27 December 2016 (UTC)
- I created an example with qualifiers over at https://test.wikidata.org/wiki/Q55267 . The names for the properties are likely not ideal, but I don't understand why such a qualifier solution wouldn't work for this use-case. ChristianKl (talk) 08:31, 3 April 2017 (UTC)
- ChristianKl's typical example works for me, and it probably works fine for defining something like TdF's King of the Mountain (Polka dot jersey (Q11636369)) which would presumably be a specific and notable example of such a classification. — billinghurst sDrewth 03:55, 24 April 2017 (UTC)
- Support We really need these properties to complete the templates for bicycle races. Most stage races have a classification for stages, general, points, mountains, young rider and teams. Right now there are implemented stage, general, points and teams (both time and points), but those for mountains and young riders are missing, and that really puts a hold on adding results to races, as it is annoying to not being able to add all classification results at the same time. For example I have to consider if I will have to add the results for young rides and mountains manually in wikitables on my local wiki, or if I will just let the data be missing until the properties hopefully surfaces later. I don't see any of those alternatives as any good. Also, the nice thing about the WD-generated tables is that they will be available in all languages at the same time. For the other more rarely used classifications that have been proposed I also support them, but it is not so urgent to add them, and they will be used by fewer users (I beleive). Bergenga (talk) 22:28, 22 May 2017 (UTC)
- Fully support - MegaRaptor, 23 May 2017 (UTC)