Wikidata:Property proposal/place on the route
place on the route edit
Originally proposed at Wikidata:Property proposal/Transportation
| Description | object, station, facility, city, natural formation or other place on a road, track, route, line, watercourse, utility line or other linear route |
|---|---|
| Data type | Item |
| Domain | item, classes: linear construction (Q1826691), transport service itinerary (Q1067164), watercourse (Q355304), itinerary (Q1322323) |
| Allowed values | instance of (Q21503252) and geographical feature (Q618123) (not only physical subjects, but also abstract such as borders etc.) |
| Example 1 | Yodo Line (Q899418) → Matsumaru Station (Q4388383) |
| Example 2 | River Nene (Q19722) → Nene Viaduct (Q17553973) |
| Example 3 | East Coast Main Line (Q672271) → Nene Viaduct (Q17553973) |
| Example 4 | railway line Vrané nad Vltavou - Čerčany (Q14550947) → Jílovský tunel I (Q99373464) (linear reference (P6710) = 21.255 kilometre (Q828224)) |
| Example 5 | road III/3907 (Q112046162) → level crossing P3848 in Studenec (Q110300328) (bridge number (P9759) = 3907-1) |
| Example 6 | Vltava (Q131574) → Old Town Weir (Q112685500) (distance from river mouth (P2148) = 53.1 kilometre (Q828224)) |
| Example 7 | Volga (Q626) → Yaroslavl (Q2423), Samara (Q894), Volgograd (Q914)… |
| Robot and gadget jobs | trasform current has part(s) (P527) statements in linear items where the values are not subsections of the same type as the item but rather structures, devices or places (e.g. stations, bridges, junctions, crossings, check points, signal boxes, confluences, islands, tunnels, weirs, dams, fords, ferries, ports etc.) Various entries from infoboxes can be also imported. |
| See also | lake on watercourse (P469) |
Motivation edit
The property has part(s) (P527) is often overused or misused for statements for which it is not appropriate. For some cases, it does not allow for consistent use: for example, an overpass is a part of the road or railway line that runs above it, but not a part of the road/track/river that runs below it. An island, bridge or ferry is not part of a river but is located on the river. The proposed property is more universal - it allows not only parts of the linear structure, but also related places and structures on it and around it (cities and and villages on the river etc.).
While has part(s) (P527) should remain uncluttered and really contain only parts of the item (e.g. subroute of a route), this property is designed in such a way that it is possible to insert a large number of various values into it, and output scripts and templates are expected to be able to filter and sort its contents. Hopefully, the Wikidata editing interface will also allow this in the future.
A generally unsettled problem here on wikidata is complementary and inverse statements. This property is designed as universal complementary counterpart of more various properties, but allows them all to be included in the context of a single line.
Feel free to improve this proposal. --ŠJů (talk) 15:28, 19 August 2023 (UTC)
Discussion edit
Oppose too many values, located on linear feature (P795) should be used in inverse.--GZWDer (talk) 16:17, 19 August 2023 (UTC)
- And also carries (P2505), crosses (P177), located in or next to body of water (P206), connecting line (P81), located on street (P669) and many others. A script that would linearly list the objects on the route in the context of their relative order from so many different properties would be disproportionately complex and unreliable. We are addressing the overused and abused property has part(s) (P527) here, which is used for purposes for which users lack a suitable property. However, the fundamental problem here is the completely inconsistent and unbalanced approach to inverse properties. Some of them are used routinely and successfully, the emergence of others is blocked, even if they are needed. We list the start and end points as properties of the track (river, route…), but we don't list the intermediate points on the track, because instead the track will be a property of those points? Isn't it more systematic to describe a track with a sequence of points in one place than to define a part in one direction, a part inversely? A complete list makes it possible to better reflect the mutual position of those points. --ŠJů (talk) 18:43, 19 August 2023 (UTC)
Not done - not created per lack of support. Regards, ZI Jony (Talk) 11:43, 20 January 2024 (UTC)
