Wikidata:Property proposal/Mountain chain

Mountain chain

Originally proposed at Wikidata:Property proposal/Place

   Not done

Description	row of mountains within a larger mountain range
Represents	mountain chain (Q22911774)
Data type	Item
Template parameter	Many, including: |mendilerro= in Txantiloi:Geografia fisiko infotaula, Txantiloi:Mendate infotaula, etc. |massif= in Modèle:Infobox Col, Modèle:Infobox Montagne, etc. |Mountain chain= in Template:Infobox mountain, Template:Infobox mountain pass, etc.
Domain	geographical feature (Q618123), in particular mountain (Q8502) and mountain pass (Q133056)
Allowed values	Instance of subclasses of mountain range (Q46831) or of massif (Q1061151)
Example 1	Q12253832 → Zaraia mountain range (Q12269211)
Example 2	Crêt de la Neige (Q1142554) → Monts Jura (Q3323062)
Example 3	Mount Ishizuchi (Q2744214) → Shikoku Mountains (Q1093753)
See also	part of (P361), located in/on physical feature (P706)

Motivation

I have created almost 300 articles on the Basque mountain chains which are linked to a potential of 4200 mountains. A dedicated property is necessary in order to classify mountains with their own mountain chain.

For example, these mountains are in the mountain chain of Zaraia, they do need to be linked to an appropriate property, entity, smaller than the Mountain range. There is no property between mountain range (P4552) and mountain (Q8502). An average mountain range has often up to 10 000 mountains, or even more and more, and there is no step like a mountain chain in between. Furthermore, mountain range (P4552) is full of mountain chains. Zorion (talk) 01:53, 27 February 2019 (UTC)

Discussion

•  Comment I think existing properties are fine for this - between located in/on physical feature (P706) and mountain range (P4552) at least. ArthurPSmith (talk) 19:28, 27 February 2019 (UTC)
•  Oppose use located in/on physical feature (P706) --Pasleim (talk) 12:40, 28 February 2019 (UTC)
•  Oppose. The idea behind mountain range (P4552) was that one would use the most specific available value on items. So this is the property to use everywhere. Thierry Caro (talk) 20:20, 28 February 2019 (UTC)

  Let's make an analogy for the location of a village (Q532), you are suggesting that continent (Q5107) is « the most specific available value on items ». It's a little bit short on that issue. There are many existing properties in between (Country, administration), and how many for a taxon (Q16521) ?

  Let's take Mount Elbert, the highest point of Colorado, for example. It is a part of the Sawatch Range. The Sawatch Range is part of the Southern Rocky Mountains which are, obviously, the part of the Rocky Mountains spanning over 5,000 km. The United States have 73,389 named mountains and you all want one property be linked. One more step is required.

  Indeed I could use located in/on physical feature (P706), but the fact is that every mountain (Q8502) has its own mountain chain (Q22911774) that belongs to a mountain range (P4552). I still do think that this property is necessary for an automatic infobox cause there is an huge gap between mountain and mountain range. --Zorion (talk) 17:25, 2 March 2019 (UTC)

  You should use Sawatch Range as the value for mountain range (P4552) in the given example. Thierry Caro (talk) 00:31, 6 March 2019 (UTC)

  This is what I'm already doing. Ok If I understand you, a mushroom has a scientific classification with a Kingdom, Division, Class, Order, Family, Genus, parent taxon (P171) and a mountain has one property. I got it, I'll deal with it. --Zorion (talk) 14:05, 7 March 2019 (UTC)