Wikidata:Property proposal/recipient

recipient (aliases: to, intended recipient, receiver, target, beneficiary, awardee)

Originally proposed at Wikidata:Property proposal/Generic

   Not done

Description	person, group, or organization to which the given entity is directed, given, or sent
Represents	addressee (Q28008314) target (Q66254282) beneficiary (Q2596417) award received by (Q66796038)
Data type	Item
Domain	items
Example 1	pitch (Q1063937)recipientcatcher (Q1050571)
Example 2	Orteig Prize (Q1930819)recipientCharles Lindbergh (Q1618)
Example 3	Zimmermann Telegram (Q154091)recipientHeinrich von Eckardt (Q1599502)
Example 4	consumer complaint (Q1473099)recipientconsumer organization (Q1329436)
Example 5	Alaska Purchase (Q309029)instance of (P31)purchasing (Q1369832)of (P642)Alaska (Q797)recipientUnited States of America (Q30)
See also	Possible parent properties: participant (P710) or significant person (P3342) (these do not specify a role without adding a qualifier) Possible sub-properties: addressee (P1817) (currently specific to letters and the like) intended public (P2360) (currently specific to items meant for public consumption) target (P533) (currently specific to attacks) Other similar properties: has goal (P3712) (expresses the intended end state, not the recipient, of an action) towards (P5051), destination point (P1444) (these take a location as object, rather than a person or organization)

Motivation

To express a major thematic relation that is not well addressed by existing properties (as noted in the "See also" field). Swpb (talk) 19:48, 26 December 2019 (UTC)

Discussion

•  Support David (talk) 06:04, 27 December 2019 (UTC)
•  CommentIs it the same as addressee (P1817)?--Midleading (talk) 09:13, 27 December 2019 (UTC)
  • addressee (P1817) at present only covers one of several use cases of the proposed property, but I would not be opposed to a radical expansion of its definition (really, turning it into the proposed property), rather than creating a new property, if folks like that idea. Swpb (talk) 14:31, 27 December 2019 (UTC)
•  Oppose Widen winner (P1346) instead. Nomen ad hoc (talk) 17:30, 27 December 2019 (UTC).
  • That makes no sense. This is for items that are transferred between parties. Winning an event may involve the transfer of a prize to the winner, but often does not. If we were to turn that property into this one, someone would immediately propose a new "winner" property exactly like the old one, and with good reason – these are not at all the same concept. If any property were appropriate to expand into this role, it would be addressee (P1817), certainly not winner (P1346). I gather from Wikidata:Property proposal/general law that your preference is to shoehorn new uses into existing properties whether they fit there or not. In both these cases, not. Swpb (talk) 18:04, 27 December 2019 (UTC)
•  Support but I would also support expanding the definition of addressee (P1817) if that's the consensus here. ArthurPSmith (talk) 21:28, 30 December 2019 (UTC)
•  Oppose I think all usecases are already covered --- Jura 10:15, 20 January 2020 (UTC)
  • Please elaborate by expressing the example statements with existing properties. Without major expansion (e.g. of addressee (P1817) as discussed above), the existing properties simply do not work. Would you allow addressee (P1817) to be changed as described? Swpb (talk) 20:34, 21 January 2020 (UTC)
    • Notably by award received (P166), addressee (P1817) you apparently don't want to see in the "see also" section. I know it makes it more difficult to argue the added value of the property. BTW: first time a proposer deleted valid content from a proposal. --- Jura 20:36, 21 January 2020 (UTC)
      • addressee (P1817) is discussed above; please comment accordingly: would you allow it to be radically expanded for this role? In it's current form, it is explicitly limited to letters and notes. And award received (P166) takes a completely different class as values, namely awards, not people who receive them – its mention was a non-sequitur and presumably an accident. And no, you don't get to edit my proposal; the discussion section is good enough for everyone else, and it will be good enough for you. Swpb (talk) 20:40, 21 January 2020 (UTC)
        • Do you understand that you are proposing an inverse property for award received (P166)? --- Jura 20:48, 21 January 2020 (UTC)
          • 1) I am not, and 2) if I were, that wouldn't be an argument against. That's also a remarkably different argument from your initial one; I certainly hope your personal feelings towards me aren't the real factor here. Swpb (talk) 20:49, 21 January 2020 (UTC)
            • You might want to have a look at the item used as value in the second sample above, notably the statements at Q1618#P166. --- Jura 20:53, 21 January 2020 (UTC)
              • And the four examples that have nothing to do with prizes? Covering a use case is not the same as being limited to that use case; which again, wouldn't be a problem anyway. Swpb (talk) 20:57, 21 January 2020 (UTC)
                • 2 are covered by addressee (P1817). The first by "participant" with object has role. This has the advantage that the pitcher doesn't get omitted. The last one seems to be an error. --- Jura 21:01, 21 January 2020 (UTC)
                  • Ah, so 60% of the examples are not covered by addressee (P1817), unless we expand it! For the third time: are you for that? (Unsurprisingly, I don't find your takes on examples #1 and #5 compelling either, but at least they're valid opinions.) Swpb (talk) 21:05, 21 January 2020 (UTC)
                    • Given that we have 453,654 items with award received (P166), it's likely that 95% of actual Wikidata uses are covered.

BTW, small correction: 1 is covered by P1817. It's unclear how "consumer complaint" recipient "consumer organization" is covered even by this proposal.

Maybe you could explain how the seller and the pitcher is meant to be included. --- Jura 21:13, 21 January 2020 (UTC)

author  TomT0m / talk page Mbch331 (talk) Jobu0101 (talk) Tubezlob (🙋) Flycatchr Koxinga (talk) Fuzheado (talk) Mfchris84 (talk) Manu1400 (talk) Daniel Mietchen (talk) Valentina.Anitnelav (talk) 16:32, 6 January 2021 (UTC) ミラP@Miraclepine 19:01, 1 March 2021 (UTC) Nils Casties (talk) Finnusertop (talk) 11:38, 3 June 2023 (UTC) DrThneed (talk) 06:20, 8 October 2023 (UTC)

Notified participants of WikiProject Award

@GerardM:

•  Comment pinging people who contribute to the inverse award received (P166). --- Jura 20:53, 21 January 2020 (UTC)

There is no use case for it. It increases bloat in Wikidata. For years now we have found that a user interface like Reasonator shows perfectly well all known instances of recipients of an award. It is safe to say that the best remedy for this perceived need is a user interface Consider bloat, there are awards with over 500 recipients.. Additionally you gain a major pain; synchronising and error checking on duplicate entries (they are the same information). Thanks, GerardM (talk) 06:27, 22 January 2020 (UTC)

I don't like to use the same property for diverse purposes (addressee, buyer, winner, target, ...). They will probably raise issues when the property is to be translated into every languages, and introduce unwanted items for property users. Can we discuss each of these usecases separately?--Midleading (talk) 13:42, 26 February 2020 (UTC)

 Support I like the idea of having more general relations to use as a fallback while we're waiting for more specific properties to be added. --Cdo256 (talk) 05:13, 9 September 2020 (UTC)
 Support It makes sense to have a common superproperty for winner (P1346) and addressee (P1817). /ℇsquilo 18:14, 15 August 2022 (UTC)

 Not done Clearly lacking consensus. JesseW (talk) 02:19, 12 March 2021 (UTC)