Wikidata:Property proposal/dedicated object
dedicated object
[edit]Originally proposed at Wikidata:Property proposal/Person
Description | Property for people to whom certain objects have been dedicated. This property refers to the Wikidata item of the respective object. |
---|---|
Data type | Item |
Domain | human (Q5) |
Allowed values | commemorative plaque (Q721747), Stolperstein (Q26703203) ... |
Example | Leo Drabent (Q1818538) → Stolperstein dedicated to Leo Drabent (Q52786303) |
Planned use | Add this property to all items of humans with dedicates objekts linked per commemorates (P547). |
Robot and gadget jobs | Bots can add this property to affected items. |
Motivation
About 3000 Wikidata objects contain the property commemorates (P547) pointing to about 2400 distinct target objects. Current status: To obtain information about commemorative plaque (Q721747), Stolperstein (Q26703203)... dedicated to a specific person, a database query is required - and sufficient knowledge about the linking properties too.
This may do the job for Wikidata insiders. Visitors who found the item of a person and simply want to receive information can not see any data about the dedicated object - not even its existence. Just because they are at the wrong end of the link.
The proposed property is this missing link back, providing easy access and more usability. Quarz 20:25, 15 May 2018 (UTC)
Discussion
- Support as inverse property to commemorates (P547) —MisterSynergy (talk) 20:43, 15 May 2018 (UTC)
- Support --Godewind (talk) 05:16, 16 May 2018 (UTC)
- Comment There's always the "What links here" link in the left-hand menu bar if you don't want to do a specific query. But I'm concerned here that this will lead to overwhelming numbers (hundreds?) of entries for people like Washington, Nelson, Columbus, etc. The reverse direction here is generally better and while we do have some inverses, we have recently been generally discouraging the creation of more - Wikidata really is a database not intended so much for visitors to "receive information... at the wrong end of the link" - you can build fancy UI's on top of it that do all that stuff. Maybe we could get our developers to improve the main Wikibase UI to make this stuff easier too (after all Reasonator and SQUID do it quite nicely). Anyway, I don't think this is a good justification for needing this inverse, and I'm concerned as I said about certain entries being overwhelmed by this property. ArthurPSmith (talk) 20:15, 16 May 2018 (UTC)
- I find the “What links here” function pretty useless for this purpose, as it just links every backlink regardless of the property used. With this query we can estimate how many uses of the proposed property we need to expect in the current state. There are three items with more than 10 such backlinks, with 74 for Taras Shevchenko (Q134958) being the highest value (mind Reasonator and SQUID links for this item). I can’t really estimate how these numbers develop, but at this point it does not seem to overwhelm items. —MisterSynergy (talk) 05:49, 17 May 2018 (UTC)
- Oppose this can be dervied from commemorates (P547) and is therefore redundant. Inverse properties cause many problemes, for example that user have to enter all data twice and maintainer get much more workload because most user will forget to enter the data twice. It can also dismantle items, e.g. there are more than 5000 Lenin monuments in Russia. If the main motivation to create an inverse property is to display more information for visitors, we should ask the developement to have a new section on an item page which shows derived statements. I have once created a user script (User:Pasleim/relateditems.js) which displays inverse claims, but it is a bit rusty. --Pasleim (talk) 12:50, 17 May 2018 (UTC)
- Redundancy is systematically inevitable for the Wikidata data model for cross-linking unless a software solution is available for everyone. This redundancy is mandatory for some properties, as you know. User scripts can be a solution for some insiders, but not for visitors. Your script shows that the solution to the problem of large numbers lies in a server-side limitation of the displayed related items, no matter from which source (inverse property or query) the entries originate. Your script allows 100 displayed items per package. This number is currently not met by commemorates (P547) in relation to humans in any single case (see query above at MisterSynergy).
Please do not confuse commemorates (P547) and named after (P138). Lenin monuments (your example) appear at P138. The query for P138 (tinyurl.com/ycxzmpf7) shows about 20 times the number of people with up to 784 backlinks per individual.
Your concern for the maintenance effort is understandable in view of located in the administrative territorial entity (P131) and the like. However, the situation with the proposed property is completely different. With the small number of affected items the effort remains manageable. I would even be able to do that.
With "we should ask the development" the solution (which makes sense to me!) lies in terms of whether and when in the dark. The proposed property brings the solution immediately. The property can be deleted when the software solution is ready.--Quarz 15:25, 18 May 2018 (UTC)
- Redundancy is systematically inevitable for the Wikidata data model for cross-linking unless a software solution is available for everyone. This redundancy is mandatory for some properties, as you know. User scripts can be a solution for some insiders, but not for visitors. Your script shows that the solution to the problem of large numbers lies in a server-side limitation of the displayed related items, no matter from which source (inverse property or query) the entries originate. Your script allows 100 displayed items per package. This number is currently not met by commemorates (P547) in relation to humans in any single case (see query above at MisterSynergy).
- Oppose as an unnecessary inverse of an existing property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:16, 18 May 2018 (UTC)
- I was pointed at this discussion from here. Would those commenting here be able to say whether this property would be useful for linking CWGC casualties (with articles) to the memorials they are commemorated on? Or should that only work one way? If only one way, could someone show me how to correctly link Alfred Cheetham (Q487478) and Bobby Atherton (Q4934724) to the memorial they are commemorated on (Tower Hill Memorial (Q2911428)). An earlier attempt at this sort of things was at Parliamentary War Memorial (Q17514021) - see the list of people I added under 'commemorates'. However, a memorial like Thiepval Memorial (Q1861419) would be a case where it is unlikely that we would want to list all the many tens of thousands commemorated there, but we would want to link in some way those commemorated there who have Wikidata entries (probably around 25 or so). Any advice gratefully received. I believe I may have discussed this on Wikidata earlier, but can't remember where - @Pigsonthewing: Andy might remember. Carcharoth (talk) 17:14, 22 May 2018 (UTC)
- Oppose Visitors can already find the information via Reasonator and SQID. ChristianKl ❪✉❫ 15:00, 24 May 2018 (UTC)
- Weak oppose. The inverse property is useful but this one isn't. Creating this new property would lead to excessively long lists of commemorative objects on famous people's items. Deryck Chan (talk) 13:18, 20 June 2018 (UTC)
- marking as Not done given the lack of consensus − Pintoch (talk) 15:46, 20 June 2018 (UTC)