From my point of view, the property has several possible uses, as you can see from the examples. The three shown options will also be in the foreground for me in the planned use. Since the Winter Olympics were not that long ago, the first use of the new property is to take place in the WikiProject Olympics (Q5497326) and the WikiProject Winter sports (Q7130723).
I've wanted to introduce this feature for a long time, but nothing came of it for various reasons. Part of the reason is that I can imagine that the property is quite controversial and that it is considered “superfluous”. You could certainly come to this conclusion if you look at the first and third example, because I have already found and implemented an implementation there. Nevertheless, I find the implementation with the property which I suggested better. In addition, you could also say in the second example that you could use a different variant there. The teams are integrated via the property participating team (P1923). So, you could also add the players via the property participant (P710) with a few qualifiers, so you don't need a new property. Certainly, you cannot say that this opinion is wrong. With the property participant (P710) you can enter all participants, regardless of whether they are players, coaches, referees or officials. Wait a minute, referees have their own property with referee (P1652) they don't need to be tied in through the poperty participant (P710).
Conclusion: I want to say that I am aware that the property is susceptible to criticism and that the points of criticism are also clear to me. But in my view, the benefits of the property far outweigh these criticisms. Because with this property you create a certain standardization, because you can use this property in different requirement areas where you currently have to fall back on different properties and also detours. --Gymnicus (talk) 12:25, 25 February 2022 (UTC)[reply]
Oppose per "motivation". Such a property would require a precise definition, in particular a domain (i.e. type constraint), so that it does not conflict with the other ways to express participation data. We certainly do not need another redundant form to express the very same information that we already have in items. —MisterSynergy (talk) 13:37, 25 February 2022 (UTC)[reply]
@MisterSynergy: Okay, I wouldn't say redundant now, but rather partially coincident or overlapping. But there are several properties here in Wikidata that are like that. But you also wrote in your comment when such properties can still be useful, namely precisely when their area of application is precisely defined and there are also clear restriction rules. I have already proposed certain restrictions in my proposal. If you want, we can still try to tighten them up if they are too weak for you. --Gymnicus (talk) 15:03, 25 February 2022 (UTC)[reply]
"Partial overlap" is to be avoided. Otherwise we end up in another situation where users tend to add simply both, and data users need to figure out how to query all the different possibilities in order to get reasonable results. There are already way too many of these situations in the field of sports results and participation data. —MisterSynergy (talk) 15:24, 25 February 2022 (UTC)[reply]
@MisterSynergy: I totally understand your concern. You're afraid it might end up like the properties follows (P155), followed by (P156), replaces (P1365), replaced by (P1366). The properties are used in a jumble there and no one really has any idea when what is used and how it is used. I'm no exception, I'll admit that. – However, I don't see this problem with my proposed property. Because, as I said before, it's a good place to work with property constraints and thereby throw up errors that can then be cleaned up by experienced users like me. In addition, with regard to the proposed property, it is not actually in conflict with other properties in actual use. What I want to say is that, as far as I know, there are currently no other implementations by other users where I would like to use the proposed property. Only I have tried implementation forms from time to time, such as with the data objects Liechtenstein at the 2018 Winter Olympics (Q28933423) and 2021 #True Athletes Classics – men's 4 × 400 metres relay (Q107446813). --Gymnicus (talk) 09:02, 16 March 2022 (UTC)[reply]
@MisterSynergy: “Otherwise we end up in another situation where users tend to add simply both [...].” – For this statement, the four qualities were the best example in my opionion. Actually, nobody there really knows when what is used, especially in relation to organizations and states. All four properties are then simply taken. But that's not really the issue here. Nevertheless, I wanted to explain to you how I came up with this. --Gymnicus (talk) 09:44, 16 March 2022 (UTC)[reply]
I had in mind, just from the field of sports and quickly written from memory:
Not all of these are exactly identical, but they are use a lot to introduce redundancy in data items about sport. The issue is not that we do not have suitable properties—we just do not have an idea how to use them properly. It is not helpful to introduce even more potential redundancy. —MisterSynergy (talk) 09:54, 16 March 2022 (UTC)[reply]
@MisterSynergy: I'm happy to try with you to resolve some of the “almost” redundancies using appropriate property constraints. This discussion would certainly be better on your talk page, if you currently have the time and inclination to do so. Perhaps we can then also find a solution for my idea proposed here in this context. Whether it results in the creation of this property remains to be seen. --Gymnicus (talk) 10:12, 16 March 2022 (UTC)[reply]
Because I'm currently trying to document and visualize this season's bobsleigh world cup with its individual races here, the use of the property is primarily planned for this task. After that, I'll try to use the property in the ways as well, as shown in the examples.
I had suggested this trait about nine months ago. The subsequent discussion was then only between me and MisterSynergy, which I would also like to ping hereby. During the time that I was then also blocked for the "Wikidata" namespace, the discussion of MasterRus21thCentury, which I am also pinging here, was ended as not executed.
I am currently in the process of documenting and visualizing both the Skeleton World Cup and the Bobsleigh World Cup this season and their races here in Wikidata. Unfortunately, I am again confronted with the missing property. For that reason I want to try again to propose the trait and maybe this time more people will join the discussion.
Note: The already closed discussion can be seen by going to the subpage of the property proposed here. For reasons of clarity, I decided to leave out the old discussion, at least when integrating the templates. --Gymnicus (talk) 13:04, 16 December 2022 (UTC)[reply]
@MisterSynergy: Yes, it is basic. I just added an example to show another usage of this property. Of course, one can argue about whether it makes sense to propose a property that has already been rejected. But in this case the discussion consisted only of me and you and that's why I see a renewed discussion with more participants as useful. --Gymnicus (talk) 19:40, 16 December 2022 (UTC)[reply]
If we get this restricted to a fairly narrow domain so that it does not conflict/overlap with other properties, as already discussed in the other proposal, I would support this one. —MisterSynergy (talk) 20:04, 16 December 2022 (UTC)[reply]
@MisterSynergy: I don't mind a clear delineation of when to use the property and when not to. Actually, I wanted to ask directly what other restrictions you came up with. But I can now come up with an own idea for a stronger limitation myself. Unfortunately, the current situation is that association football match (Q16466010), handball match (Q20019127) and so on are a direct subclass of sporting event (Q16510064). Here one could perhaps add another intermediate instance for matches in team sports and use this new instance as a constraint instead of sports competition. --Gymnicus (talk) 20:43, 16 December 2022 (UTC)[reply]
Well, what bothers me most right now is that we have very different entities in subject position of the triples. What kinda works is <organization> <deploys (athlete)> <athlete> (with organization being a sports team, sports club, delegation, and so on). Mind that we have always some form of a (sports) organization in subject position. Example #1 and #3 (where the proposed property is used as qualifier, and the mainsnak value has the subject role in triple logic) work like this. In example #2 things are messed up, since an event is in subject position and this should definitely not be possible. It is even difficult to make sense of a statement "<event> <is an entity that saw this athlete deployed> <athlete>"; sounds bad, because it is. Example #4 is in the middle of those other ones; unlike #3, the subject now is the item subject although being used as qualifier, since the mainsnak value is again an event which should not happen. The logic is a difficult to get in this one, to be honest, so it might need to be remodelled as well. —MisterSynergy (talk) 21:31, 16 December 2022 (UTC)[reply]
Thanks for your comment. It is very insightful and also very helpful to me. Unfortunately, I'm having a hard time giving a coherent answer to your comment right now, so I'm splitting my answer. I would just start with example 1. You support the use shown there, as far as I understand it, which makes me very happy.
With regard to the first example, however, I would perhaps suggest some hardening of the constraint. Currently, the property is to be used by sports teams. But that would mean that, for example, you could also enter all the players who once played for the team FC Bayern München (Q97905919) in the data object. I think that's beyond the scope.
You used a good word in your comment though. This is the word “delegation”. The property should be intended precisely for this type of “sports team” and show which athletes participated in the sports competition or in the sports saison for the delegation. But how are delegations represented here in Wikidata? Nation delegations are represented by data objects that ?item wdt:P31/wdt:P279 wdt:Q46135307 meet, and club delegations of a season are represented by data objects that ?item wdt:P31/wdt:P279 wd:Q1539532 meet. Therefore I would suggest the two data objects nation at sport competition (Q46135307) and sports season of a sports club (Q1539532) instead of the data object sports team (Q12973014) as a constraint. --Gymnicus (talk) 20:17, 17 December 2022 (UTC)[reply]
Sounds good overall.
"sports team" is not really well defined indeed, neither in Wikidata nor elsewhere.
Btw. the ill-fated Example #2 above should probably just be removed from the proposal. You could simply remodel it to Example #3 (use the teams in mainsnak with P1923 and then make qualifier use of <deployed athlete>).
I'm still not sure what to do with Example #4, though. How common are these situations at all? It certainly is not something we would do in the data item FC Bayern München (Q97905919).
@MisterSynergy: With a look at the second example, I noticed in your comment that you do not like the use described in the second example and rather reject it. You made that clear in your last comment. I understand your problem with the use a little bit. But it would certainly be good if we could still exchange views on how to show which players were used in the game 2014 FIFA World Cup Final (Q15926885) or the game 2018 IIHF World Championship final (Q53780330), for example. There is currently no way to do this. --Gymnicus (talk) 21:31, 17 December 2022 (UTC)[reply]
In your last comment I skipped the sentence with the remodeling of the second example to the third example. It's possible, that's right. But with this, information or the possibility of reproducing information is also lost, because a qualifier cannot have its own qualifiers, while a “correct” statement can. Gymnicus (talk) 21:36, 17 December 2022 (UTC)[reply]
An alternative would be to qualify the already existing participating team (P1923) claims with <deloyed athlete>, pretty much as in Example #3 of this proposal
The direct approach with participant (P710) has the advantage that you can add more qualifies (e.g. substitutions and so on).
@MisterSynergy: Oh, I picked out the best example right away. In my defense though, the players were only added earlier this month and I hadn't noticed. But of course that doesn't matter. Even that brings me to a question. Why is participant (P710) a better property than the property I suggested? The two triples aren't different, are they? In addition, the problem with participant (P710) is that not only the players listed are participants in the soccer game. Joachim Löw and Alejandro Sabella are also participants in the football game. --Gymnicus (talk) 21:59, 17 December 2022 (UTC)[reply]
Well, this is one of the concerns I had in the very beginning when I commented on the first proposal earlier this year. If you want to link participants (athletes) to an event, you are already covered and there is no need for another, overlapping/competing property. If you can use the more general participant (P710) property to also link coaches (for instance), it is even better than a narrower "deployed athlete" property *for this use case*. You can use a qualifier to state the role which each individual has had in that match. —MisterSynergy (talk) 22:12, 17 December 2022 (UTC)[reply]
Oppose per "motivation". Such a property would require a precise definition, in particular a domain (i.e. type constraint), so that it does not conflict with the other ways to express participation data. We certainly do not need another redundant form to express the very same information that we already have in items. —MisterSynergy (talk) 13:37, 25 February 2022 (UTC)
Not done —MasterRus21thCentury (talk) 11:27, 9 May 2022 (UTC)
