Wikidata:Properties for deletion/P5330

P5330 (P5330)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to migrate data to class of station (P5606) then delete — Martin (MSGJ · talk) 13:18, 11 February 2022 (UTC)[reply]

P5330 (P5330): (delete | history | links | entity usage | logs)

I don't think we need a specialized property than class of station (P5606). GZWDer (talk) 21:46, 8 December 2019 (UTC)[reply]

Delete after data migration. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:05, 10 December 2019 (UTC)[reply]

Keep The general property explicitly says "use subproperties where available" and has constraints that conflict with their use. No apparent benefit to generalisation over specificity so data migration would just be makework. Thryduulf (talk) 14:28, 16 December 2019 (UTC)[reply]

Notified participants of WikiProject Railways Thryduulf (talk) 14:29, 16 December 2019 (UTC)[reply]

Delete I agree with GZWDer and Andy, not need to have a special property and delete after migration. Multichill (talk) 18:48, 16 December 2019 (UTC)[reply]

Delete The specific property (P5330) is largely redundant to the general property (P5606). An argument could be made that the general property should be deleted instead and replaced with specific properties for each network, but here the relationship with the network can be inferred from the station category items, so including the network as part of the property is functionally unnecessary. Jc86035 (talk) 23:13, 16 December 2019 (UTC)[reply]

Delete Per above, unlike station codes and line numbers where both may triage URL schemes, linking to these items for ranking of stations are good enough. --Liuxinyu970226 (talk) 11:26, 17 December 2019 (UTC)[reply]

Additionally, should we redesign the {{Ping project|Railways}} to be {{Ping project|Taxonomy}} like? --Liuxinyu970226 (talk) 11:27, 17 December 2019 (UTC)[reply]

Keep per description of P5606: "Use subproperties where available" Michael FV (talk) 04:03, 9 January 2020 (UTC)[reply]
@Michael FV, Thryduulf: If there's no URL schemes for "subproperties" available, then there are entirely no reason to have subproperties, we can merge them back to this one now. --Liuxinyu970226 (talk) 00:30, 10 January 2020 (UTC)[reply]
@Liuxinyu970226: If you think a property needs to be merged then what you need to do is get consensus to merge it, not nominate it for deletion. My recommendation to keep this stands. Thryduulf (talk) 09:53, 10 January 2020 (UTC)[reply]

@Thryduulf: Hmm, is there be possible to merge two or more properties without deleting? --Liuxinyu970226 (talk) 09:52, 23 October 2020 (UTC)[reply]

Keep clear scope. Enables reports with @Ivan_A._Krestinin:'s Krbot. --- Jura 10:58, 20 January 2020 (UTC)[reply]
Delete replacement available, no need to create any subproperties for anything that don't affect URL schemes. ForIvan_A._Krestinin'sbot, Ithink weshouldasktheproblem viatheirGithub? --117.136.54.109 23:23, 20 January 2020 (UTC)[reply]

Delete As values are only items, merge em back won't hurt anything. --223.104.7.115 22:11, 9 May 2020 (UTC)[reply]

Delete No need to fragment data into multiple properties. --Tinker Bell ★ ♥ 01:53, 25 October 2020 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Implementation notes

@GZWDer: would you be able to help migrate this data? There are 109 statements. Thanks — Martin (MSGJ · talk) 13:21, 11 February 2022 (UTC)[reply]

Done — Martin (MSGJ · talk) 21:07, 15 February 2022 (UTC)[reply]