Wikidata:Property proposal/Buried in this place

Buried in this place

Originally proposed at Wikidata:Property proposal/Generic

   Not done

Description	People or even non-human animals buried in the specific place. Mainly for graveyard items, as an inverse for Property:P119.
Data type	Item
Domain	item
Allowed values	Wikidata itens only for humans and non-human animals
Example 1	Père Lachaise Cemetery (Q311) → values --> Gustave Doré (Q6682); Jim Morrison (Q44301) etc.
Example 2	Israeli Cemetery of Butantã (Q20056195) → values --> Vladimir Herzog (Q7938366) etc.
Example 3	Jalalpur Sharif (Q3696271) → values --> Bucephalus (Q201598) etc.
See also	Property:P119 and Property:P1791

Motivation

People or even non-human animals buried in a specific place. Mainly for graveyard items as an inverse for Property:P119. It would be good to allow that information directly at the graveyard item, as it may be used inside Wikidata infoboxes. Sturm (talk) 20:25, 10 December 2018 (UTC)

Discussion

•  Oppose. Unnecessary inverses cause duplication, things falling out of sync, extra work to input things, and inaccurate and incomplete data. --Yair rand (talk) 20:36, 10 December 2018 (UTC)

Thank you for your fast response, @Yair rand:. But pls, allow me do argue and ask. There are many inverse properties here inside Wikidata, so, what is your definition of "unnecessary inverses"? Talking about "things falling out of sync, extra work to input things"... well, there is this relevant news on Meta. Finally, the risk of "insert inaccurate and incomplete data" is absolutly the same for most of the properties. Regards, Sturm (talk) 20:46, 10 December 2018 (UTC)

•  Support as this helps to model the inverse relation to place of burial (P119). Ederporto (talk) 20:50, 10 December 2018 (UTC)
•  Support David (talk) 07:15, 11 December 2018 (UTC)
•  Support It would make it possible to then show that information in infoboxes. Mike Peel (talk) 13:57, 11 December 2018 (UTC)
•  Oppose Can we instead of proposing inverses work on getting developer support for Lua to provide easy access to inverses? ArthurPSmith (talk) 17:04, 11 December 2018 (UTC)
•  Oppose. Unnecessary inverse. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:21, 11 December 2018 (UTC)
•  Oppose Unnecessary.--Micru (talk) 11:59, 19 December 2018 (UTC)
•  Weak oppose Inverses of properties that are many-to-one (such as place of burial (P119)) have particular difficulties.

Take the case of Père Lachaise Cemetery (Q311) for instance, which is offered as the property's very first example use. We currently have items for over six thousand people buried there. And Q311 is not alone: tinyurl.com/ybd6x28p. Clearly we don't want to be adding 6000 statements to Q311. But that leads to some awkward consequences, for example (i) the property thus won't in general be suitable for an inverse constraint, nor for automatic filling by bot; (ii) if it were used on Père Lachaise Cemetery (Q311), who would decide which are the handful of values that should be preferred, out of those 6000 potential items? What criteria would be used?

Neither of these issues are insuperable, but are these cans of worms really things that it is worth having to open? Jheald (talk) 13:37, 19 December 2018 (UTC)

@Jheald, Ederporto, Micru, Pigsonthewing, Yair rand, Sturm: Not done Plenty of opposition.ChristianKl ❪✉❫ 16:09, 14 January 2019 (UTC)