Wikidata:Property proposal/head coach of

From Wikidata
Jump to navigation Jump to search

head coach of[edit]

Originally proposed at Wikidata:Property proposal/Sports

   Not done
Descriptionsports teams or clubs that the subject currently coaches or formerly coached
Representscoach (Q41583)
Data typeÉlément-invalid datatype (not in Module:i18n/datatype)
Template parameter"carrière entraîneur" in fr:Template:Infobox Footballeur, "managerclubX" in en:Template:Infobox_football_biography, "trainervereine" (or "trainer_tabelle") in de:Template:Infobox Fußballspieler, etc.
DomainPerson
Allowed valuesOrganisation
ExampleAlex Ferguson (Q44980)Manchester United F.C. (Q18656), Alex Ferguson (Q44980)Scotland national football team (Q34044)
Didier Deschamps (Q508711)Olympique de Marseille (Q132885), Didier Deschamps (Q508711)France national football team (Q47774)
Planned useimport corresponding data from Wikipedia footballer infoboxes (as I've done last few months with member of sports team (P54))
Robot and gadget jobsB0ttle (talkcontribslogs), my bot
See alsothe same as member of sports team (P54), but for coaches and managers
Motivation

Hi. I explained what I want to do in Wikidata:Project_chat#how_to_tag_that_someone_has_worked_as_a_coach.2Fmanager_for_a_football_club.2Fteam. To describe coach career in Wikidata, there is no evident existing property (occupation (P106), member of sports team (P54) and employer (P108) each have their default). So Danrok (talkcontribslogs) invited me to ask the creation of a dedicated property. H4stings (talk) 09:07, 13 July 2016 (UTC)

Up: I am still interested. Face-smile.svg I wait for the conclusion of this page to start my work. Either this new property creation is validated, and I will use it tens of thousands of times. Or it is not granted, in this case I think I will use the member of sports team (P54) property with subject has role (P2868):association football manager (Q628099) as qualifier. H4stings (talk) 08:07, 18 September 2016 (UTC) & 15:37, 20 September 2016 (UTC)

Discussion
I don't see why the information has to be stored on the page of the manager. What's wrong with storing it at the club level? You can still write access the information via a query for an infobox. ChristianKl (talk) 19:31, 20 July 2016 (UTC)
@ChristianKl: there is no obligation, but it sounds simpler to me. Almost every manager is an old footballer, and we already store the player career data in the wikidata player element (with member of sports team (P54)). And in any Wikipedia page, both information (player and manager career data) appears in the infobox of the human being, not in the club one. --H4stings (talk) 07:59, 21 July 2016 (UTC)
When it comes to the term head coach it's not immediately clear that humans can't have head coaches like humans have teachers. This might be confusing for new users. If you want to model the side from the human than I think "hold position" already does the job. ChristianKl (talk) 08:06, 21 July 2016 (UTC)
  • Symbol support vote.svg Support. I guess there are enough people concerned for this to be useful. Thierry Caro (talk) 08:56, 12 August 2016 (UTC)
  • Symbol oppose vote.svg Oppose. I agree with Pigsonthewing, use position held (P39). Sjoerd de Bruin (talk) 07:33, 23 August 2016 (UTC)
  • Symbol support vote.svg Support. I believe that using position held (P39) would be unnecessarily cumbersome as it would require one to use modifiers every single time to show which teams the individual has coached/managed. Furthermore, I have yet to see any explanation as to why P39 is good enough. Indeed, that property appears to be political in scope. Perhaps someone can give me some reasons for why I should use P39. If we have no problem using member of sports team (P54) to list the teams an individual has played for, why is there a problem with storing managerial information on the page of the manager? Many sportspeople are far more famous as a manager than as a player, and it would be good for us to be able to document the organizations that they represented in that role. In a nutshell, I think it would be very helpful for those of us who edit sports items if we had this property. Lepricavark (talk) 11:19, 23 August 2016 (UTC)
  • Symbol support vote.svg Support. Very few items about coaches use P39, it's ambiguous for most editors and you can't think of it while editing. If we have member of sports team (P54), than we must have this one too and keep P39 for politicians or other jobs.Ionutzmovie (talk) 21:18, 6 September 2016 (UTC)
    • That "you can't think of it while editing" is not a good reason to create a property; the more overlapping properties we create, the harder it will be to figure out which to use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:04, 20 September 2016 (UTC)
  • Symbol oppose vote.svg Oppose Maybe the other way around.
    --- Jura 16:25, 19 September 2016 (UTC)
  • Symbol oppose vote.svg Oppose. I've reread this discussion and agree with Andy that position held (P39) does the intended job here. Thryduulf (talk) 14:47, 4 November 2016 (UTC)
  • Symbol support vote.svg Support. We have it in most Wikipedias, and if we put it in Wikidata we can automatically add to templates without using position held (P39), that would be good for presidents of sport teams, but not for a trainer, who can be in more that one team every year. The list of position held (P39) would be too long because most formats in Templates are using this for politicians, with different formatting. At the same time, one coach of any sport team could also be in a political charge during his life, and it would lead to misunderstood. -Theklan (talk) 22:57, 5 December 2016 (UTC)
  • Symbol support vote.svg Support To make it easier for Wikipedia to load this data via a template. ChristianKl (talk) 14:18, 24 January 2017 (UTC)
  • @Thryduulf, Jura1, Sjoerddebruin, Pigsonthewing, Ionutzmovie, H4stings: Given that a majority supports the creation of this property I'm leaning towards creating it. Doesn anybody object? ChristianKl (talk) 19:17, 30 May 2017 (UTC)
    • Four people at least object, above. Please consider our reasons for doing so, not merely the numbers. As a supporter of the proposal, you're also involved. 19:57, 30 May 2017 (UTC)Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits
  • Symbol oppose vote.svg Oppose position held (P39) seems adequate to me. If we have "head coach of" will we have similar properties for every other type of coach, trainer, etc. etc.? This seems way too specific and the information can be fully represented with existing properties. ArthurPSmith (talk) 19:20, 31 May 2017 (UTC)
  • Symbol support vote.svg Support having a separated property is important as it will simplify querying it (e.g no need to query also qualifiers - from both Lua template and SPARQL perspective) in case of different P39 meanings (politican + sport person), and will prevent confusion. Eran (talk) 21:19, 5 June 2017 (UTC)
  • @Sjoerddebruin, ArthurPSmith, Thryduulf, Jura1, Pigsonthewing: Given that there are 7 support votes and only 5 oppose votes, I lean towards creating this porperty. Does anybody object? ChristianKl (talk) 10:01, 25 June 2017 (UTC)
  • Symbol oppose vote.svg Oppose per ArthurPSmith's suggestion. Mahir256 (talk) 20:45, 26 June 2017 (UTC)
  • BA candidate.svg Weak oppose until someone shows why position held (P39) wouldn't make sense. d1g (talk) 19:31, 15 July 2017 (UTC)
  • Symbol support vote.svg Support I think a dedicated property is best here because it has benefits in terms of consistency and ease of maintenance:
    • There are multiple suggestions here for how the data can be stored. That is likely to lead to some people doing it one way and other people doing it another way because it's not obvious which way is the best way. That makes our data inconsistent and therefore less useful.
    • These statements would be the inverse of head coach (P286). Having dedicated inverse properties makes the constraints easier because it's a simple symmetric constraint. These will even be shown in the interface soon (or right now, if you enable the gadget in your preferences) and we might even get a button in the future to make it easier to fix the constraint violations (phab:T167700). The suggestions here would require complex constraints and it's not clear if or when they will be supported.
  • - Nikki (talk) 13:49, 16 July 2017 (UTC)
We hadn't many inverse statements for professions (except for presidents).
We have "CEO:" P169 property, but not "CEO of" (we have "position held" + "organization")
@Nikki: then we should create "CEO of" - why do we need to make every relation symmetric? d1g (talk) 15:55, 16 July 2017 (UTC)
I don't like that we have to add statements in both directions, but until the developers decide to improve things, people will continue needing them for things like infoboxes. If we're going to have them, we want it to be as consistent and easy to maintain as possible. For the reasons I wrote above, I think a dedicated property is the best way to do that in this case. What's best in other cases, such as CEOs, might be different. - Nikki (talk) 16:41, 16 July 2017 (UTC)
We should include "from related entities" in API
Many-many things aren't possible in Wikidata:Infobox Tutorial as of now. We can explode properties in a programmatic manner, there is no reason to accept every "inverted" statement manually except when this is done for performance reasons.
There is no difference between coaching as full time job and CEO - what makes us to use reverse properties for coaches, but not for CEO? d1g (talk) 17:21, 16 July 2017 (UTC)
  • Symbol oppose vote.svg Oppose. Inverse of a property that never should have existed in the first place. --Yair rand (talk) 21:04, 14 August 2017 (UTC)
  • Pictogram voting comment.svg Comment. I'm closing this. It has been going on for more than a year now. I support the proposal but there is too much opposition for it to be successful eventually. Thierry Caro (talk) 11:36, 26 August 2017 (UTC)