Open main menu

Wikidata:Property proposal/station category

station categoryEdit

Originally proposed at Wikidata:Property proposal/Transportation

Descriptioncategory of a railway station, assigned by its operator; for example DB Station&Service (Germany), Rete Ferroviaria Italiana (Italy) and National Rail (Great Britain) all assign each of their stations to a category. For example, each Italian station is classified as platinum, gold, silver or bronze; in Germany, the categories are numbered 1 to 7; and so on. "Issued by" should be a mandatory statement.
Data typeItem
Template parameter"DfT category" in en:template:Infobox GB station; "Category" in en:Template:Infobox station
Domainrailway stations (possibly bus and metro stations as well)
Example 1Casteldebole railway station (Q3969301)bronze
Example 2Welwyn Garden City railway station (Q2723798)C1
Example 3Lichtenfels station (Q324749)3
Sourceen:German railway station categories, en:United Kingdom railway station categories
Robot and gadget jobs
See alsoDeutsche Bahn station category (P5105), United Kingdom Department for Transport railway station category (P5330)


To provide railway stations with a unique property concerning their official classification, subsuming the current Deutsche Bahn station category (P5105) and United Kingdom Department for Transport railway station category (P5330) (and avoiding proliferation of similar properties for other railway systems). Fabio Bettani (talk) 13:03, 4 July 2018 (UTC)


  •   Support Because of totalitarianism and the new datatype (Difference from existing properties) David (talk) 14:42, 4 July 2018 (UTC)
  •   Oppose I don't see any advantage in replacing the existing properties; and the datatype for this one should be 'item'. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:57, 4 July 2018 (UTC)
    • You're right: I changed the datatype to item. The advantage would not be to replace the existing properties, but to prevent dozens of new property requests for every country in the world with a station category system in place. Currently, just the UK and Germany are supported by existing properties. As Wikidata grows, we would end up having a dozen similar properties: one for station categories in Italy, one for station categories in Israel, one for station categories in Japan, and so on. It looks like bad practice to me: one property for every country would be enough. Or am I missing a point? --Fabio Bettani (talk) 10:21, 5 July 2018 (UTC)
  •   Support I think this makes sense - as item valued, you can attach the national category definitions to the target items, so it would work for any such system, I think this is a good general approach. ArthurPSmith (talk) 14:07, 5 July 2018 (UTC)
  •   Comment it seems to make maintenance more complicated (complex constraints are needed for values). For searching, maybe this could be a parent property of the others. For a mere observers point of view, I think the field already suffered from attempts to make things work across different countries: see Wikidata:Properties_for_deletion#Property:P1103.
    What do proponents of the current properties think?
    - Deutsche Bahn station category (P5105): @Entbert, Pintoch:@Liuxinyu970226, Thryduulf, Nortix08:
    - United Kingdom Department for Transport railway station category (P5330) @Thryduulf, Danrok, Joshbaumgartner:.
    --- Jura 04:56, 8 July 2018 (UTC)
  • While I could support idea, I   Oppose normal string values, since that makes nonsense on nearly all wikis, it should either be item, or external-id. --Liuxinyu970226 (talk) 04:58, 8 July 2018 (UTC)
    As now datatype changed to item,   Support. --Liuxinyu970226 (talk) 08:47, 5 August 2018 (UTC)
    •   Question as an item datatype, does this now mean that the details will be built into the value item now instead of needing complex qualifiers to use correctly? Josh Baumgartner (talk) 02:45, 15 September 2018 (UTC)
  •   Comment This would make constraints more complicated as permitted values differ between systems (and there is a many:1 relationship between systems and countries, e.g. the UK property only covers Network Rail (Q1501071) stations, not London Underground (Q20075), NI Railways (Q1937120), etc) and possibly between organisations (it's plausible that e.g. operators and regulators may have different categorisation systems for the same stations). If this is used though then it absolutely should use item datatype. The issue with number of platform tracks (P1103) though is not simply with trying to make it work in multiple countries, but a lack of a clear definition of what is being counted and different definitions being used in different languages. This is something to be aware of - with the current properties it's clear what categorisation system is being used. With a combined property I think there would need to be a structure that identifies both the categorisation system and the value. Thryduulf (talk) 10:31, 8 July 2018 (UTC)
  •   Support For larger systems (with a lot of WD station items) special property (United Kingdom Department for Transport railway station category (P5330) or Deutsche Bahn station category (P5105)) is better, but still having general property is a good idea. Datatype Item is a good choice.--Jklamo (talk) 16:41, 1 August 2018 (UTC)

@Fabio Bettani, ديفيد عادل وهبة خليل 2, Pigsonthewing: @Jura1, Liuxinyu970226, Thryduulf, Jklamo:   Done - however, I have not created any of the necessary items, nor added the associated example statements (which would require those category items) so there's still work to be done here! ArthurPSmith (talk)

  • From the discussion, it doesn't seem entirely clear if this should be a parent property or replace the existing ones. What's the outcome?
    --- Jura 19:18, 9 August 2018 (UTC)
  • I'm very surprised this has been created when most (all?) of the supporting infrastructure in terms of items and their constraints are undefined. Without them it isn't possible to answer the points brought up in this discussion. Thryduulf (talk) 15:54, 10 August 2018 (UTC)