participant person, group of people or organization (object) that actively takes/took part in an event or process (subject). Preferably qualify with "object has role" (P3831). Use P1923 for participants that are teams.
Description
person, group of people or organization that actively takes/took part in the event
Contemporaries: if [item A] has this property (participant (P710)) linked to [item B], then [item A] and [item B] have to coincide or coexist at some point of history. (Help)
Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)
Contemporaries: if [item A] has this property (P710) linked to [item B], then [item A] and [item B] have to coincide or coexist at some point of history.
Regarding sporting events, the property can also be equipped with a qualifier to express the round or place that the participant reached. Properties like "champion", "runner-up", etc are used in many infoboxes for sporting events. For the Olympics, there are group items like Canada at the 2012 Summer Olympics (Q140982), so you don't have to list all 11,000+ athletes under one item; in order to be fully accurate, you would arguably need to introduce similar items for events like 2010 FIFA World Cup (Q176883), to list the actual squad members that participated.--Kompakt (talk) 08:15, 30 May 2013 (UTC)[reply]
Comment Maybe it would be better to have only the reverse property, "participated in", otherwise there be too many properties (imagine how many athletes participate in the Olympic games).--Micru (talk) 01:50, 8 July 2013 (UTC)[reply]
I proposed above to have group items for events with a lot of participants, like the Olympics. As a matter of fact, we do have items already, e.g. Canada at the 2008 Summer Olympics (Q140854). So 2008 Summer Olympics (Q8567) would have "participants": Canada at the 2008 Summer Olympics (Q140854)", and within Canada at the 2008 Summer Olympics (Q140854), all members of that team would be listed using has part(s) (P527). Still you're right, this property could have a hundred values in some occasions, so grouping level could be necessary (e.g. "Canadian archers at the 2008 Olympics"). But on a closer look, proposal of creating such a property on the participants' side bears the just same problem: professional sportspeople usually take part in hundreds of events within their career.
But that's not my point. What is the mains idea behind this property? Using a qualifier like "ranking", it will it possible to describe the result of a sports event; we are to tell who won the event, who was second, etc. Taking the example above, we could use this for archery at the 2008 Summer Olympics (Q223519) to tell who got the gold medal, who was second, etc. As mentioned above, this is an infobox property for sport events in wikipedia, but could also be used to create result lists or even complete draws at some later point. All of this would hardly be possible when we have this information distributed at the participants - although you could arguably create queries to fetch such information, I don't think that's the best way to do it. The winner, the runner-up as well as other participants should be stored along with the event itself.
A final remark: that the Olympics are the most complicated case by far. Take an ordinary single-sport event like the Soccer World Cup instead: for 2022 FIFA World Cup (Q284163) you'd use "participant" to list all teams with single items like "Icelandic team at the 2022 FIFA World Cup", and then list all team members within team items using has part(s) (P527). Then none of these properties would have than (roughly) 30 values.--Kompakt (talk) 08:49, 16 July 2013 (UTC)[reply]
If 'participant' is to have qualifiers for the performance achieved (time in a race, points for decathlon etc.) and the ranking (1st, 2nd etc.) then we will need a separate for each competition. For the Olympics the item the whole competition can use participant (P710) to list all the teams with qualifiers for the number of medals each received however you need an item for each heat of each competition if you want to give the time each participant achieved. If you only want to record the times achieved by the finalists then you only need an item for the final but that leaves a lot of people achieving career best performances that don't get recorded here. Eventually, I believe, we will have items for every heat. Filceolaire (talk) 23:51, 18 April 2014 (UTC)[reply]
The case of a naval battle. Two known participants (submarine vs. surface ship). Casualties duly counted and published. What's wrong with listing both "participants" and "number of casualties"? Any workaround, perhaps? Retired electrician (talk) 11:15, 1 December 2021 (UTC)[reply]
The description of winner (P1346) says it should not be used for wars or battles; I'm guessing the same applies for this property. What the alternative would be I don't know; something like conflict (P607) but then the inverse. @Trade: you added the constraint, do you maybe have some input? ―Jochem van Hees (talk) 14:38, 1 December 2021 (UTC)[reply]
A warship's role in a battle is notable, less so for wars. My preference is for it to use participant (P710) rather than conflict (P607) which I'd use for wars, the distinction between tactical and strategic. Both battles and wars don't mention ships in their participant lists, so it seems a good property for a ship. Vicarage (talk) 09:54, 9 September 2022 (UTC)[reply]
As battles use participant (P710) in its sense as belligerent, I think that commanded by (P4791) should be added as a valid qualifier. So the Battle of Trafalgar has participant United Kingdom commanded by Horatio Nelson. Currently Nelson is a direct participant, but the command structure seems better. Vicarage (talk) 13:26, 6 May 2023 (UTC)[reply]
I'm scoping out creating Wikidata items for a series of oral history interviews. I had planned to use Participant with qualifier object has role for interviewer and interviewee - but am getting a constraint error message. Looking at the page for Participant I'm a bit confused as using it with an instance of an interview seems to be listed as possible and as a constraint. Would a more experienced editor be able to advise please? Example: Q118314152. On this item I've added what looks like an alternative with the interviewer and interviewee names in a significant person statement. I'm wondering what the most appropriate option is. Thanks
HelsKRW (talk) 14:11, 12 May 2023 (UTC)[reply]
Thanks @Vicarage I've done a SPARQL query to find some other interviews and they also use participant with qualifier object has role interviewer and interviewee, so it looks as if I'm not the only one who would like to use participant with interview in this way - and it does seem less clumsy than significant person. HelsKRW (talk) 09:29, 15 May 2023 (UTC)[reply]
Thank you @Mormegil. Yes, cast member would not seem appropriate in this case as it is an oral history interview. How does it work to remove interview from the constraint - is that something that a more senior editor would do? I don't want to remove a constraint if I don't have the right to do that! If possible I would prefer to remove the constraint first, rather than create a lot of Qids which contain error messages! HelsKRW (talk) 09:28, 15 May 2023 (UTC)[reply]
It's been a while since it was added, so I don't remember exactly the circumstances of how it came about. But the basic intention behind it was the proximity of talk show, podcast and interview. Participants must not be used for the first things mentioned, which is why I think it makes sense to do this for interviews as well. But then you also have to generalize the two properties P5030 and P371 and I didn't do that. So I understand that it should and has been rolled back. --Gymnicus (talk) 15:52, 17 May 2023 (UTC)[reply]
contemporary constraint The entities Battle of Trafalgar and Horatio Nelson should be contemporary to be linked through participant, but the latest end value of Horatio Nelson is 1805 and the earliest start value of Battle of Trafalgar is 21 October 1805.
Expected behaviour: comparison of dates with different levels of precision should always expand the less qualified date to the start or end of the period depending on the comparison. Vicarage (talk) 11:02, 29 October 2023 (UTC)[reply]
Yeah, that one is the well-known bug in the contemporary constraint implementation, see phab:T168379. But it seems to me the dates in Q706428 can have better precision, I have changed them according to the enwiki article (listed as the reference), so the constraint error went away. --Mormegil (talk) 11:11, 22 November 2023 (UTC)[reply]
Support I think this is definitely needed. Danrok (talk) 23:13, 8 June 2013 (UTC)
Comment Maybe it would be better to have only the reverse property, "participated in", otherwise there be too many properties (imagine how many athletes participate in the Olympic games).--Micru (talk) 01:50, 8 July 2013 (UTC)
