Wikidata:Property proposal/peak bagging classification

peak bagging classification edit

Originally proposed at Wikidata:Property proposal/Natural science

Done: peak bagging classification (P8450) (Talk and documentation)

Description	recognised peak bagging classification of a mountain or hill
Represents	<new parent "peak bagging classification" item>
Data type	Item
Domain	mountain (Q8502), hill (Q54050), summit (Q207326)
Allowed values	<new parent "peak bagging classification" item>
Example 1	Mount Everest (Q513) → eight-thousander (Q185552)
Example 2	Ben Nevis (Q104674) → Munro (Q1320721)
Example 3	Mount Kilimanjaro (Q7296) → ultra-prominent peak (Q3116906)
Example 4	Scafell Pike (Q1146222) → Wainwright (Q62082131)
Planned use	tidy up existing use of P31 to classify peaks, tidy up peak classification items themselves

Motivation edit

Following a project chat discussion (Wikidata:Project_chat/Archive/2020/07) I'm proposing a property to link hills/mountains to their applicable peak bagging classification items (eight-thousander (Q185552), Munro (Q1320721), etc.) in order to move these values out of instance of (P31). This also enables better handling of cases where peaks have been classified/declassified as a specific type at different points in time. You can also see that these classification items are modelled in a variety of ways currently and this should help to homogenise that.

Reading up on w:List of mountain lists and looking at some hill bagging websites, I think we want to avoid a property which links a hill/mountain to any arbitrary list because there's just too many possible ways to list them. That approach would also, in effect, open the gates for Wikidata to link all items to lists on which they reside (the same issue, just too much scope for data that can be arbitrarily generated).

So this property is taking the approach suggested by PKM (talk • contribs • logs) and linking to peak classification items (which we will create a parent item for if nobody can suggest a better modelling for all this). This way only recognised classifications should exist, because there is no structural need for non-widely recognised classification items that anybody can arbitrarily make up. I've opted not to limit this to just UK classifications because there isn't really a centralised classification system which a property like that would imply (plus we can capture other recognised classifications elsewhere). SilentSpike (talk) 21:11, 8 July 2020 (UTC)[reply]

Discussion edit

@Oravrattas, Jura1, PKM, Andrew Gray: Pinging participants of the original project chat discussion. I'm still not sure if this is the ideal way to do this, but the only other options I can think of are a generic property for lists (way too broad in scope) or a property on the list/classification item which provides a query to obtain all items that apply (has potential, but I think too many edge cases). --SilentSpike (talk) 21:18, 8 July 2020 (UTC)[reply]

Support I think this is the best option (and vastly better than using instance of (P31). - PKM (talk) 21:19, 8 July 2020 (UTC)[reply]
Support Standardising on a single approach is always good, and all of the existing methods have drawbacks. --Oravrattas (talk) 05:54, 9 July 2020 (UTC)[reply]
Support - agree with all the reasoning here. Andrew Gray (talk) 20:45, 9 July 2020 (UTC)[reply]

@SilentSpike, Oravrattas, Jura1, PKM, Andrew Gray:

Done peak bagging classification (P8450) Pamputt (talk) 08:15, 17 July 2020 (UTC)[reply]