Wikidata:Property proposal/Place

Property proposal:	Generic	Authority control	Person	Organization
	Creative work	Place	Sports	Sister projects
	Transport	Natural science	Computing	Lexeme

See also

• Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
• Wikidata:Properties for deletion – proposals for the deletion of properties
• Wikidata:External identifiers – statements to add when creating properties for external IDs
• Wikidata:Lexicographical data – information and discussion about lexicographic data on Wikidata

This page is for the proposal of new properties.

Before proposing a property

1. Search if the property already exists.
2. Search if the property has already been proposed.
3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
4. Select the right datatype for the property.
5. Read Wikidata:Creating a property proposal for guidelines you should follow when proposing new property.
6. Start writing the documentation based on the preload form below by editing the two templates at the top of the page to add proposal details.

Creating the property

1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
2. Creation can be done 1 week after the creation of the proposal, by a property creator or an administrator.
3. See property creation policy.

On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/08.

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

This is part of an on-going work to add data from the Norwegian Sentralt Stedsnavnregister to Wikidata. The property proposal Wikidata:Property proposal/Archive/11#Short_name is very similar to this, but describes a short official name. Jeblad (talk) 15:14, 6 July 2013 (UTC)

Also useful for Hungary : eg. for the town Mohács (Q320798), the Hungarian Statistical Office gives the values Mohač and Mohatsch as Nemzetiségi név "nationality/minority name" (name in the language of a minority), determined by the corresponding Minority council (Q2982941) and officially used for instance on place name signs. Data for Hungary from this source and another source are being discussed in French here. Oliv0 (talk) 11:24, 6 August 2013 (UTC)

How is this different from the pending property Official Name? Filceolaire (talk) 12:09, 6 August 2013 (UTC)

No difference for me, I have asked the proponent, Jeblad for his opinion. Oliv0 (talk) 06:37, 7 August 2013 (UTC)

Both are okay in the case of towns in Hungary, although "official name" is generally a bad idea. Ljubinka (discussion) 11:54, 7 August 2013 (UTC)

A named place can have several names, and some of them can have an additional qualifier that they are officially accepted and when they was accepted. A controlled place name is a name that is handled by some official body, it is not necessary official in itself. An "official name" as I see it is a type of controlled place name, that is some official body must make a claim that the name is in fact officially accepted. Jeblad (talk) 17:23, 10 August 2013 (UTC)

 Oppose Use 'Official name' with qualifier 'authority' => 'SSN' or 'Hungarian Statistical Office'. Filceolaire (talk) 15:04, 17 August 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

I expected some kind of generic solution for these kinds of code, but I fail to see any such use here. There are also some other kind of code for other kinds of urban/rural areas, but they are rare as items. Therefor I would like to see a generic solution. A property named something like "Statistics Sweden-code" with all these kinds of codes used as qualifiers. Observe that one item can have more than one kind of code. An urban area can have a history as a "minor urban area" for example, and an "minor urban area", can at the same time be a "fritidshusområde" (Concentration of weekend and holiday homes). The exception here is the ATA-code, which I prefer to name as ATA-code and nothing else, since it is unrelated to Statistics Sweden. -- Lavallen (block) 16:30, 30 April 2013 (UTC)

 Support As long as all of the codes are officially assigned by Statistics Sweden to the item in question, this seems to make sense to me. Only note is that the '-' should be removed from the English-language version of the property label. Joshbaumgartner (talk)

I added a few links to the above proposal. Unfortunatly, most descriptions there are in Swedish. It seems to me that these are several different identifiers used in Sweden by various institutions, rather than one scheme with multiple aspects. I'd tend to create one property for each identifier. --  Docu  at 01:18, 9 May 2013 (UTC)

Good enough!

There is a redirect in sv:Sockenkod describing the Sockenkod/ATA-code. Four digits.

Fritidshusområde (en:Concentrations of weekend and holiday homes) has no article/item for the code. The syntax is four digits.

Arbetsplatsområden has no article/item yet, even less for the code. I will come back in that subject if/when it is needed.

Regarding the "tätortskod". Urban areas who ceased to exist before the codes where introduced have an "X" instead of the first digit. It can be written without an initial letter "T" but I would recomend it. Normaly the number is even.

Småortskod has an "S" followed by four digits, the number is nomally odd. "S" can be excluded but it is not recomended.

Församlingskod has 6 digits, municipality 4 and county 2.

When the districts are introduced in the near future, they will likely be the same as församlingskod, since their geography is identical. I will come back when they need items and a new property. -- Lavallen (block) 12:39, 11 May 2013 (UTC)

And urban areas who ceased to exist before the standard for urban areas was introduced 1960, has "novalue" as urban-area-code. -- Lavallen (block) 12:42, 11 May 2013 (UTC)

County code created as P:P507. More properties are related to this proposal, so it's to early to send it to the archive. -- Lavallen (block) 16:13, 11 May 2013 (UTC)

Municipality code created as P:P525. More to come... -- Lavallen (block) 18:12, 16 May 2013 (UTC)

It would be nice with help to create these:

• Urban area code in Sweden Example: T7524 or 7524 for Kramfors (Q645351) or TX006 or X006 for Alby (Q934689)
• Minor urban area code in Sweden Example: S9729 for Herrskog (Q2417483)
• Civil parish code/ATA-code in Sweden Example: 2482 for Nora socken (Q10601915)
• code for parishes in the Church of Sweden Example: 228202 for Nora-Skogs församling (Q10601889)
• Pastoratkod" (not been able to translate it, it's an administrative level between Parish and Diocese for the Church of Sweden, the Church of Sweden is still not completly separated from the administrative division of the nation, but it will shortly in the future) Example: 100109 for Nora-Skogs församling (Q10601889)
• code for weekend and holiday homes It's a four digit code. I do not have a example here now.

I think all of these will be enough for a while, all of them should be string-properties. -- Lavallen (block) 11:24, 1 August 2013 (UTC)

I created templates for the missing properties. We need them anyway for the talk pages of the respective properties. Could you look for a machine readable source or a webpage where the strings could link too? --Tobias1984 (talk) 12:59, 1 August 2013 (UTC)

Machine readable is hard since SCB likes publishing things as pdfs. Still...

• Urban area code: pdf (Table 1, p.9)
• Minor area code: pdf (Appendix 1, p.64)
• ATA-code: This is actually stored as an rdf which is maintained by the Swedish National Heritage Board.
• Holiday home areas: [1] (Table 1, p.10)
• Ecclesiastical parish code (Church of Sweden)/Församlingskod/LKF-kod: pdf. This is actually made up by the county code (two digits, a numeric alternative to P:P507) + municipal code (two digits, makes up P:P525 together with the county code) + ecclesiastical parish code (two digits).
• Pastoral district code/Pastoratkod/SKP-kod: [2]. This is actually made up by the Diocese code/Stiftskod (two digits) + Rural deanery code/Kontraktskod (two digits) + Pastoral district code (two digits)
  • Based on this I'd also suggest creating the Diocese code (two digits) and Rural deanery code (four digits). Same source as pastoral

/André Costa (WMSE) (talk) 10:04, 7 August 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Is this thread ready for the archive or should I move it to a Sweden task force page? --Tobias1984 (talk) 11:03, 7 August 2013 (UTC)

I am not aware of any Sweden task force-page, but feel free to create one! -- Lavallen^d(block) 11:32, 7 August 2013 (UTC)

Who are Statistics Sweden? Is this the government authority which provides stats, or another organization? Danrok (talk) 12:03, 4 September 2013 (UTC)

Statistics Sweden (Q1472511). The proposal above have been split in several below, some have been created, some are still pending. -- Lavallen^talk(block) 12:06, 4 September 2013 (UTC)

Other than the one for weekend and holiday homes, is this done? If yes, we could archive this --  Docu  at 16:47, 14 September 2013 (UTC)

•  Erledigt, see P975 (P975), P976 (P976), P977 (P977), P978 (P978), P979 (P979), code for weekend and holiday homes (Sweden) (P980).--GZWDer (talk) 10:53, 23 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

 Kommentar waiting for examples. Also, the code doesn't have a wiki-page. That makes me wonder if this meets notability. Please check with Swedish wiki if such a page would be notable and if it is, it would be good to have at least a stub-class article. --Tobias1984 (talk) 13:27, 1 August 2013 (UTC)

I think this should simply be vacation area (Q10499251). —Ruud 13:58, 1 August 2013 (UTC)

Many "minor urban areas" are at the same time "weekend and holiday homes". It's true that there is no parameter in any template for this yet, but it is our ambition to create and use such parameter from now on. An article about "code for weekend and holiday homes" would normally not meet the notability-standards on svwp, but it's ok as an redirect to "weekend and holiday homes". I created this object only to be able to describe this (proposed) property properly. This set of articles have a lower notability than the larger urban areas, but it is our ambition to improve them. There is a large set of values that can be added from Statistics Sweden for this kind of object. -- Lavallen (block) 15:41, 1 August 2013 (UTC)

Added a new example, the parameter fritidshusområdeskod has been introduced to sv:Mall:Ortsfakta Sverige. -- Lavallen (block) 18:09, 2 August 2013 (UTC)

There is also a fourth set of urban areas (Arbetsplatsområde), but I have today not found a single article on svwp about them, and I have doubts that they will come in a close future. We need somebody interested in the subject first. -- Lavallen (block) 15:41, 1 August 2013 (UTC)

For Arbetsplatsområde there is A-region, FA-region and LA-region. /André Costa (WMSE) (talk) 17:11, 7 August 2013 (UTC)

Vet inte hur mycke koll du har men Arbetsplatsområde är (förenklat) SCB's benämning för industriområden utanför tätorter, jag har inte hittat några artiklar på svwp om några exempel på sådana än. De ingår förstås sedan I A/FA resp LA-regioner. Finns det koder för dessa regioner som är lämpliga att föreslå? Annars tror jag de är lämpliga att hantera som en "administrative indelning" ungefär som storstadområden och län. -- Lavallen^talk(block) 19:35, 7 August 2013 (UTC)

My fault. SCB har alldeles för många småindelningar =). Jo dessa regioner har vad jag minns också koder. Info borde finnas på A, FA, LA. /André Costa (WMSE) (talk) 03:38, 8 August 2013 (UTC)

Det här är väl också begrepp som vi inte har egna artiklar om än. De är dock värda att skapa object runt, oavsett hur det blir med artiklarna. -- Lavallen^talk(block) 06:20, 8 August 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Brazil uses a specific type of postal code system, which warrants its own property. Pikolas (talk) 06:03, 20 August 2013 (UTC)

 Oppose Create an unique property for all postal codes of all countries. Snipre (talk) 11:33, 24 August 2013 (UTC)

 Kommentar Why you can't use the postal code (P281) property, which allows the usage of country specific formatting? --A.Bernhard (talk) 16:42, 4 October 2013 (UTC)

• ... and use a qualifier to link to CEP so I  Oppose this property. Macadamia1472 (talk) 08:53, 16 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Added the template above. --  Docu  at 08:56, 1 September 2013 (UTC)

 Kommentar What is this code ? Where is it used ? Which organization or administration is responsible for it ? Please provide some information when proposing a property. Snipre (talk) 10:00, 1 September 2013 (UTC)

Well, I generally do and most of the time users of these properties seem satisfied. If you don't intend to use properties, I suppose it might be a bit more difficult, but one doesn't need to feel compelled to comment on properties for fields one wont ever be active in.

To answer your question: the sample is from the main numeric code used for cantons. It seems to be derived from the way cantons are listed in the constitution and, as such, it rarely changes. --  Docu  at 09:29, 7 September 2013 (UTC)

I'm not sure. In Switzerland we got the BFS-Nr. (https://en.wikipedia.org/wiki/Community_Identification_Number#Switzerland) and the cantons do also have such a number, described here. One for statistical purpose and one for other things. So there's a property here in Wikidata which is called Swiss municipality code (P771). Isn't it just the same? --A.Bernhard (talk) 18:02, 9 September 2013 (UTC)

Okay I checked it, you said 10 is for Fribourg and that's exactly the same number as the Statistik Schweiz has published here. So I think it's really the Swiss municipality code (P771). --A.Bernhard (talk) 18:07, 9 September 2013 (UTC)

I think they use different identifiers for different levels, similar as the Swedish ones. --  Docu  at 05:43, 10 September 2013 (UTC)

@Docu. Please provide information: main numeric code used for cantons. What is this "main numeric code" ? I am swiss and I never heard about that code so I just want to know what is your source. Swiss people use abbreviation for canton no number so if this code exists it is very confidential and instead of using a code used in some technical documents I will propose to mention the abbreviation of each canton which are widely used. Snipre (talk) 19:51, 9 September 2013 (UTC)

If you propose a property for the abbreviation, I'd support it. --  Docu  at 05:43, 10 September 2013 (UTC)

The number for each canton discussed here is simply a rank (="Rang einer Reihenfolge") derived from some ordering of all the 26 cantons. Whenever you see a list of all 26 cantons of Switzerland, it might be ordered this way: The first 3 cantons are the three large cities who joined the confederation in the early years; the other 23 cantons are ordered by their year when the joined to Switzerland (Confederatio Helvetica), see also [3]. Since some cantons joined in the same year, it is a little more tricky to remember the right order. --Zuphilip (talk) 10:25, 10 September 2013 (UTC)

Checking various language versions of Wikipedia, the same seems to be listed at de:Gemeindenummer#Nummernbereiche. --  Docu  at 19:27, 11 September 2013 (UTC)

 Oppose The numeric code for Swiss cantons isn't unique and not common used except of the Bundesamt für Statistik. We also got ISO 3166-2 code (P300) to define official abbreviations for swiss cantons and licence plate code (P395). --A.Bernhard (talk) 16:47, 4 October 2013 (UTC)

 Support ISO 3166-2 code (P300) for canton abbreviation. Snipre (talk) 18:25, 5 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

• Formatted the above template --  Docu  at 09:34, 7 September 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Land	Reference office	Format	Example	Kommentar
Russland	сама база	\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d	Voyevolikhan (Q4114311) => 17040200112117600008474	Example
Schweden	http://www.viss.lansstyrelsen.se/	\d\d\d\d\d\d-\d\d\d\d\d\d	Orlången (Q3424558) => 656833-162888	Example
Frankreich	[4]	\[A-Z]\[A-Z]\d\d	La Loire => GT28	Example
Europa	?	\[A-Z]\[A-Z]\[A-Z]\[A-Z]\d\d	La Loire => FRGT28	Example
Example	Example	Example	Example	Example
Example	Example	Example	Example	Example
Example	Example	Example	Example	Example

•  Oppose, see Wikidata:Property proposal/Place#State Water Register Code (Russia)/ код ГВР discussion. — Ivan A. Krestinin (talk) 15:45, 29 July 2013 (UTC)

City / Stadt / Ville

Elevation / Höhe ü. NN / Altitude

• Description: Elevation
• Datatype:
• Links: How high a place is.
• Infobox parameter example:
• Comments: Reedy (talk) 02:11, 5 February 2013 (UTC)

  Isn't this info going to be part of the Geodata stuff? --Yair rand (talk) 02:39, 5 February 2013 (UTC)

  Yes and no. Here we will to distinguish

  1. official elevation (not ever clear what this is, but that goes into the geodata - coordinate)
  2. lowest elevation
  3. highest elevation
  4. arguable: elevation of town hall
  5. arguable: elevation of railway station
  6. arguable: elevation of post office
  7. arguable: elevation of whatsoever

  where the one or more or all of last six are possibly the same as #1. --Matthiasb (talk) 13:42, 7 March 2013 (UTC)

  Further we need to pay attention which elevation reference system is used. --Matthiasb (talk) 14:07, 7 March 2013 (UTC)

  What is Geodata? --NaBUru38 (talk) 20:10, 27 March 2013 (UTC)

 Kommentar Elevations are usually given in each countries favored map projection and "zero elevation datum". To keep the coherency of the data we would need all measurements according to a global standard or have some way of converting local standards. --Tobias1984 (talk) 21:17, 16 April 2013 (UTC)

 Kommentar Or this could be defined with qualifiers. Joshbaumgartner (talk)

• See #Elevation / Höhe / Altitude. Kaligula (talk) 18:06, 5 May 2013 (UTC)

Roads / Straßen / routes

Existing road length / Straßenlänge im Betrieb / longueur de la route en service

• Description: length of the completed or existing part of the road / Länge des fertiggestellten Teils der Straße
• Datatype: number value
• Links:
• Infobox parameter example: w:de:Vorlage:Infobox hochrangige Straße (Betrieblänge)
• Comments: unit in kilometer per default --Daniel749 talk 09:21, 23 February 2013 (UTC)
•  Oppose. Use Length (datatype number with dimension) with qualifier 'point in time' for the date that length applies or will apply for planned/underconstruction routes. Filceolaire (talk) 20:39, 9 October 2013 (UTC)

Primary destinations

• Description: Primary destinations that the route serves. Ssually cities and large towns, to which, as a result of their size, a high volume of traffic is expected to go
• Datatype: Item
• Domain: Places (roades)
• Allowed values: Only places in AUS, GBR, IRL, MYS, NZL, IND, according to restrictions given in w:en:Template:Infobox road.
• Source:
• Infobox parameter: w:en:Template:Infobox road (destinations)
• Comments: Allowed in road infoboxes for countries AUS, GBR, IRL, MYS, NZL, IND. Danrok (talk) 18:36, 25 February 2013 (UTC)

The reason that this isn't allowed for the U.S. is because this parameter was abused, with people adding their favorite towns with no regard for selectivity. Is there some sort of mechanism to prevent this from happening here? --Rschen7754 23:37, 25 February 2013 (UTC)

I think that, in time, there will be need for plenty of controls on wikidata on just about all properties, and that controls should be easier to code and implement on wikidata due to its more structured form. My understanding is that this an essential part of this project - to improve control and management of information and statistics. Danrok (talk) 00:50, 26 February 2013 (UTC)

•  Support Fully documented property. Mange01 (talk) 20:16, 13 March 2013 (UTC)
•  Support What constitutes a primary destination will remain a topic of dispute, but standards can be decided on. They will have to reflect the type of route, length of route, etc., but the community can develop those parameters over time as the property is put into use. Joshbaumgartner (talk)
• Oppose because this property will be unverifiable. I see no indication that this property would be verifiable with the documentation on en:T:Infobox road. --Izno (talk) 22:09, 22 July 2013 (UTC)
  • Actually, in some countries it is verifiable, because the government has specified them. --Rschen7754 22:26, 22 July 2013 (UTC)
•  Kommentar Would have to be careful in reminding people that it is only for roads i.e. not the Top 10 destinations of LAX. Macadamia1472 (talk) 06:05, 14 October 2013 (UTC)

Railway line / /

 Kommentar Does this relate to railway line in the sense of a portion of track within the network or does it mean a train service running on this portion? In german, "Eisenbahnstrecke" und "Eisenbahnlinie" are two different things. Ridership numbers, rolling stock and depot are typical info about a service, while electrification or gauge describe the track portion. There is no 1:1 relation between the two and it might be reasonable to treat them as a separate type of objects. --Rudolph Buch (talk) 10:56, 10 April 2013 (UTC)

infrastructure and service should be split. - Gonioul (talk) 16:10, 16 August 2013 (UTC)

Daily Ridership / /

• Description: Number of people who ride the said line
• Datatype: Number (Integer)
• Links:
• Infobox parameter example:
• Comments:

 Support but should merely be 'ridership'. Qualifiers can be used to identify the specifics, as some may publish daily ridership, others may be monthly, etc. Joshbaumgartner (talk) 04:32, 9 May 2013 (UTC)

 Support --B.Zsolt (talk) 12:31, 23 August 2013 (UTC)

 Kommentar Is there a way to create or source directly comparable statistics for all lines? Where the same method is used to come up with the figure. Danrok (talk) 02:37, 27 August 2013 (UTC)

•  Kommentar I agree but I am sure there is some standard (probably annual ridership / 365 as this would take into account seasonal variation.)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

 Kommentar - I think it is typical for every country to have railway districts that differ from other subdivisions. You could change the property so it works for every country. Would something like "is in railway district"? The railway districts can be sorted using "subclass of". --Tobias1984 (talk) 15:45, 28 July 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

•  Support as a nominator. Even if we will support the whole shape of such objects in future its good to have such data separately. uk: Підтримую як номінатор. Навіть якщо у майбутньому ми будемо підтримувати повні форми таких об'єктів все одно добре мати ці дані окремо. --Base (talk) 12:43, 28 June 2013 (UTC)
•  Support Can be used in several infoboxes.--Ahonc (talk) 12:50, 28 June 2013 (UTC)
•  Support. Maybe create two properties: "Coordinates of beginning of the street / Координаты начала улицы" and "Springhead coordinates / Координаты истока"? This simplifies property naming, data extraction and validation. — Ivan A. Krestinin (talk) 20:32, 2 July 2013 (UTC)
•  Oppose not a good idea to promote. --Rschen7754 20:53, 2 July 2013 (UTC)
  • Could you explain in details that you mean? — Ivan A. Krestinin (talk) 21:14, 2 July 2013 (UTC)
    • We do not want to encourage using point objects to accurately represent linear objects. Also, I don't see why we couldn't just use a qualifier with the existing terminus (P559), regardless. --Rschen7754 21:50, 2 July 2013 (UTC)
      • Discussed property does not represent the object. It represent only one important point of the object. If you need all object`s point please propose new property. terminus (P559) can not be used with rivers, it is named "конечная остановка", that mean "end station", but river have no "end" and have no "stations". There are athother problems in qualifier way too. — Ivan A. Krestinin (talk) 04:00, 3 July 2013 (UTC)
        • Then there's the headwater property that has been proposed, and one could certainly create one for the mouth too. --Rschen7754 04:47, 3 July 2013 (UTC)
          • Sorry, I do not understand your idea. — Ivan A. Krestinin (talk) 17:50, 3 July 2013 (UTC)
            • There is already a headwaters property proposed on this page, why not use that and have a qualifier? --Rschen7754 19:47, 3 July 2013 (UTC)
              • Well, but if we will use qualifiers, item will have at least two coordinate values, however, coordinate location (P625) should have single value.--Ahonc (talk) 22:51, 3 July 2013 (UTC)
                • Are you sure? Even if you use P625 as the qualifier of terminus (P559)? --Rschen7754 22:58, 3 July 2013 (UTC)
                  • I do not understand too. Can you add for example coordinates of beginning and ending for the main street of Kiev Khreshchatyk (Q1076911)? It begins at 50° 27′ 8″ N, 30° 31′ 38″ E and ends at 50° 26′ 33″ N, 30° 31′ 13″ E.--Ahonc (talk) 00:30, 4 July 2013 (UTC)
                    • What are the terminii? --Rschen7754 01:06, 4 July 2013 (UTC)
                      • European Square (Q2997168), Bessarabska Square (Q2667365).--Ahonc (talk) 11:06, 4 July 2013 (UTC)
                        • Okay, it's been added. --Rschen7754 18:57, 4 July 2013 (UTC)
                          • And how can I know from what you added what point is actually start point and what is the end? It's important data for streets since it says where the building №1 and it's extremely important for rivers to know where is the source and where is the mouth. But that's not all. Khreshchatyk it's ok - it's a main street that starts and ends in squares that are definitely notable. But e.g. Hertsena Street (Q4471893) starts from Yuriia Illienka Street (Q4473151) but ends just in end of it's buildings. This poit has coordinates but sure there no article => item like "End of Hertsena Street"; The water artery of Ukraine Dnieper (Q40855) has it's mouth is Dnieper-Bug Estuary (Q2618618), Black Sea (Q166) but it's source is unnotable Axeninskyi Mokh Swamp. How would you place you're terminii in these cases (which are not rare ones, actually). Also there is a practical moment - we have easily parsable end's and begin's coordinates in infoboxes to perform import but not terminii; also i'm not sure it's easy to put data from qualifier to infobox. --Base (talk) 13:25, 7 July 2013 (UTC)
•  Oppose per Rschen7754. Coordinates really shouldn't represent linear objects like this. We should either do something with terminus (P559) or try something with KML data. TCN7JM 23:12, 2 July 2013 (UTC)
•  Oppose Linear feature can be point out with a qualifier. --Fralambert (talk) 13:49, 7 July 2013 (UTC)

  With a qualifier of what? --Base (talk) 14:03, 7 July 2013 (UTC)

  A qualifier of the position of the point on coordinate location (P625). --Fralambert (talk) 16:45, 7 July 2013 (UTC)

  What reason is to use qualifiers in situation where data can be presented without qualifiers? Currently coordinate location (P625) is used for {{coord|...|display=title}}. Multiple coords will generate errors because only one coords can be shown in title. — Ivan A. Krestinin (talk) 18:05, 7 July 2013 (UTC)

•  Oppose We should have a special datatype for linear features (and for area features). Until we have that we can leave the coordinates out or use a point coordinate for the middle of the item. Filceolaire (talk) 16:06, 10 July 2013 (UTC)
  • Why river can not have three properties: "object shape", "springhead coordinates", "mouth coordinates"? Another question: have "special data type" ability to mark some points of the shape as mouth and springhead? — Ivan A. Krestinin (talk) 18:22, 11 July 2013 (UTC)
•  Support as End coordinates // Координаты конца. Is, and if is, why is, previous commenter sure that 1) such datatype will appear in the project in reasonable time and 2) we shall be able to use it conviniently for extracting beginning and ending coordinates? These properties are used in poscards and infoboxes now in RuWiki at least. But other opposing commenters who are talking about mergeing the sense to terminus (P559) are more notable. We can name the discussed property into sth more general like "end of linear object". But of course we can't use here Item-typed property, it must be Coord-typed per Krestinin. Ignatus (talk) 19:07, 11 July 2013 (UTC)
•  Oppose, at least with this datatype. It might make sense at some point to create this property with the linear geocoords datatype, though. --Yair rand (talk) 11:24, 17 July 2013 (UTC)

  Why linear? In infoboxes we use geocoordinates. See for example here.--Ahonc (talk) 23:27, 17 July 2013 (UTC)

  I agree that just pair of coordinates is required for some infoboxes i.e. for river (Q4022) with one for spring (Q124714) and the second for river mouth (Q1233637) as in example here. I put some comment about it in Property talk:P403 and was redirected here. Paweł Ziemian (talk) 19:54, 2 August 2013 (UTC)

•  Support Good idea, why we must use single point? Streets, rivers need two: start and finish. ShinePhantom (talk) 08:12, 26 August 2013 (UTC)

  @ShinePhantom: Because for the strange reason coordinates of the end was declined :'(. This decline of connected proposal is the weirdest thing i ever seen at WD.--Base (talk) 17:09, 24 October 2013 (UTC)

• support for streets, but please consider a fallback solution for circular roads. oppose beginning for rivers and other natural features. Too few reliable sources, too much guesswork and original research involved. Which definition of the Amazon should I use (with the Marañón, with the Ucayali, or from their confluence)? How can I pinpoint the beginning of a river on googlemaps? Even if the place is available in high-res (quite rarely), the stream is hidden under the trees. And if it's visible, is it this stream or that stream? Retired electrician (talk) 13:25, 26 August 2013 (UTC)
•  Support required for infobox. --  Docu  at 01:45, 7 September 2013 (UTC)
•  Kommentar To my knowledge I think it is hard to unambiguously define the start of a river i.e where streams become tributaries and where tributaries become rivers. Macadamia1472 (talk) 06:12, 14 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

•  Support as inverse property for mouth of the watercourse (P403). — Ivan A. Krestinin (talk) 08:18, 18 July 2013 (UTC)
•  Oppose unless it is changed to a more general property such as "Flows into" so it can be used for rivers flowing into lakes and seas as well as those flowing into larger rivers. Allowed values should be instance of (P31) body of water (Q15324) and subclasses of that (not just watercourse (Q355304)) Filceolaire (talk) 19:11, 18 July 2013 (UTC)
•  Strong support per Ivan A. Krestinin. This property would be very useful. --Jakob (Scream about the things I've broken) 16:57, 12 October 2013 (UTC)

 Erledigt --Danrok (talk) 18:59, 22 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

I am open to other suggested ways of representing such data, but this is the most generic and useful way I can think of at the moment. Aude (talk) 22:10, 1 August 2013 (UTC)

•  Kommentar This information can be useful, but how can we reliably source the information and keep it up to date? Also, this information may not be useful in some countries because wheelchair access is a legal requirement for many types of building. Danrok (talk) 20:20, 3 August 2013 (UTC)
•  Oppose This is not a characteristic of a place Snipre (talk) 21:33, 7 August 2013 (UTC)
  •  Oppose. Use 'facilities' instead. Filceolaire (talk) 23:39, 21 September 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Suprised that something like this hasn't been discussed yet. I support it, even if it technically can be found in the coordinate-datatype. -- Lavallen^talk(block) 19:40, 10 August 2013 (UTC)

 Oppose It would also be better to wait for the right datatype to appear, so we know what were dealing with and can try out different approaches in the sandbox. String is definitely not appropriate for this. Also we don't know how physical units are going to be attached to the number-datatype. To keep internal coherency of the data all entries in US-measurement systems should be forbidden because that usually means they were already converted and rounded once (all surveys work with SI-system), which increases the error when converting and rounding back to SI-system. --Tobias1984 (talk) 13:47, 11 August 2013 (UTC)

 Support. Datatype should be "Number (with dimension)". Where the source only gives the height in feet we should record that because that is what the source says. Filceolaire (talk) 20:05, 15 August 2013 (UTC)

•  Support as is. Can be converted later if ever. --  Docu  at 10:46, 24 August 2013 (UTC)

 Oppose You loose information if you enter elevation now. There's no float datatype at the moment, so wait a few weeks and then I'll give my Pro to this! --A.Bernhard (talk) 16:32, 4 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Some Wikimedia projects show a map of each place, in particular the Wikivoyages (example, see the map in the infobox). The zoom level has to be specified manually, which is a pain to synchronize between all Wikimedia projects that use them. Wikidata is the obvious place to share this data. Maybe "diameter" is a better name than "scale". Scale can not be calculated from superficy, as some places with strange shapes require a large scale even though their superficy is small (example: rivers). Nicolas1981 (talk) 06:32, 5 September 2013 (UTC)

•  Support looks like well known parameter of coord template. But it is better make it part of geo-coord data type. Maybe better contact to developers? — Ivan A. Krestinin (talk) 20:11, 5 September 2013 (UTC)

The coordinates-datatypes contains latitude, longitude altitude precision and a globe-parameter today. m:Wikidata/Data model talks about a dimension-parameter who will describe the size of the object. Maybe we should ask how these parameters are supposed to be used! -- Lavallen^talk(block) 06:53, 7 September 2013 (UTC)

Thanks for finding this! The "dimension" parameter in datatype_geocoords seems to be what we need: "rough diameter of the object in meter, used for selecting the scale of the map and for uncertainty of an area". Nicolas1981 (talk) 03:26, 9 September 2013 (UTC)

I Template:Weakly oppose this property as I believe it would be more logical to place the scale in the geocoords data type. Macadamia1472 (talk) 09:16, 16 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Border crossings should be listed into XXX border items. Милан Јелисавчић (talk) 12:45, 18 September 2013 (UTC)

 Weak support This could cause style issues with borders that have many crossings i.e. US-Mexico. Alternatively,and without creating a new property, each individual border crossing could have the claim: <"">is a <border crossing>[of: (...) ] i.e. using qualifiers. Macadamia1472 (talk) 08:36, 13 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

we already have MusicBrainz artist ID (P434), MusicBrainz work ID (P435), MusicBrainz release group ID (P436). this is an entity in musicbrainz representing a location. it is connected to artists, releases and labels. i think we should also support that Shisma (talk) 13:46, 19 September 2013 (UTC)

 Support I can make User:MineoBot import the data into WD. --Mineo (talk) 19:40, 18 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

This property will be placed in all Settlement Infoboxes on Philippine administrative units . PSGC is present at the German Wikipedia on Philippine administrative units. (Sample) Exec8 (talk) 21:45, 23 September 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

The relations here are sometimes so complex that it would simplify if it could be described by the help of a separate property. Today, we in Sweden for example have two paralell systems depending on what kind of court case is regarded, and historically has it been even more complex. Some courts did not take care or onwership of real estates, while other didn't take care of taxation-cases. Lavallen (talk) 13:37, 27 September 2013 (UTC)

Do you seem to think that this would duplicate a relation already existing? I can't think of one off the top of my head, but you must have some relation in mind... --Izno (talk) 00:50, 28 September 2013 (UTC)

Older statistics describes Swedish older relations (19th century) like a Municipality "is in" Jurisdiction, and Jurisidiction "is in" County, but that is a very simplified description. If it would have been simple relations, I guess it would have been possible to use located in the administrative territorial entity (P131) or "part of", but I fail to describe it with those properties. -- Lavallen (talk) 06:36, 28 September 2013 (UTC)

If a place is in three different jurisdictions, depending on the type of case, then this property will have three values each with a qualifier giving the type:

Jurisdiction:

Court A - instance of:tax court

Court B - instance of:family court

Court C - instance of:appeal court

I think that works. Filceolaire (talk) 18:52, 9 October 2013 (UTC)

I have a problem with the name. Shouldn't it be "Is in jurisdiction of" Filceolaire (talk) 18:52, 9 October 2013 (UTC)

"Is in/located in" makes it looks only depending on geography, "belongs to" is maybe better? -- Lavallen (talk) 16:08, 13 October 2013 (UTC)

'belongs to' is too broad and could lead to misuse as owner i.e. <Mona Lisa> belongs to <The Luvre> or <Puerto Rico> belongs to <United States of America> Macadamia1472 (talk) 07:07, 14 October 2013 (UTC)

'belongs to Jurisdiction' of course! -- Lavallen (talk) 06:52, 15 October 2013 (UTC)

I think it makes a lot of sense to have a "(belongs to) jurisdiction" property, but I would not restrict it to court jurisdictions. I have long wanted such a property, e.g. to mark Governor of California (Q887010) > California, Same-sex marriage in New York (Q17483) > New York, Judiciary of Oklahoma (Q6303138) > Oklahoma, 2013 Virginia gubernatorial election (Q7934697) > Virginia, Landtag of Bavaria (Q641439) > Bavaria. It's like country (P17) not limited to sovereign states, or like located in the administrative territorial entity (P131). While those can also be added to the mentioned items, "jurisdiction" would only be used for the exact jurisdiction it is linked to, so it would give precise information. SPQRobin (talk) 20:54, 18 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

 Kommentar - Qualifier for location of intersection would be useful. We might have this already, I'm not sure. --Jakob (Scream about the things I've broken) 00:48, 8 October 2013 (UTC)

 Support per nom. Joshbaumgartner (talk) 11:26, 12 October 2013 (UTC)

 Kommentar When/where do you think this information would be used? Macadamia1472 (talk) 08:41, 13 October 2013 (UTC)

What is "notable"? --Rschen7754 19:29, 12 October 2013 (UTC)

 Oppose until we have a definition of notable. --Rschen7754 21:53, 18 October 2013 (UTC)

Notable means it has its own item already. --Jakob (Scream about the things I've broken) 21:50, 22 October 2013 (UTC)

What would you do for something like w:en:Interstate 5 in California, however? --Rschen7754 21:57, 23 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Useful for sports related topics. --putnik 22:00, 13 October 2013 (UTC)

 Kommentar I think this should be assigned to the country, e.g. American Samoa (Q16641) with any date qualifiers. --Danrok (talk) 12:42, 15 October 2013 (UTC)

Fixed. --putnik 14:35, 15 October 2013 (UTC)

 Support Definitely notable. Macadamia1472 (talk) 09:32, 16 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Motivation. GZWDer (talk) 10:14, 18 October 2013 (UTC)

I don't know how it works in other languages, but in the Russian language demonyms for the nation, men and women are different. Which of them offered to write, only for nation? --putnik 11:20, 18 October 2013 (UTC)

Yes, this is a very complicated area. It sounds more like something Wiktionary would handle.  Oppose creating this property, at least while Wiktionary support isn't up yet. --Yair rand (talk) 20:30, 22 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

This is not the same as Wikidata:Property_proposal/Place#MusicBrainz_area_ID. Area IDs basically are for settlements (villages/towns) and everything larger than that. Places however are for... places where some musical performance happens (concert halls, studios): we currently have 2 type of them, studios and venues. Places can be linked to releases (= albums) and recordings (= songs as they appear on albums). We currently have relationships along the lines of 'mastered at', 'mixed at' and 'recorded at'. Mineo (talk) 19:51, 18 October 2013 (UTC)

What would be the purpose of storing this ID? --Danrok (talk) 18:50, 22 October 2013 (UTC)

The same purpose as all the other MusicBrainz IDs: linking to a website that provides detailed structured and machine readable information about places where musical events (concerts, studio recordings, etc.) happened. The Abbey Road Studios mentioned above have a (still growing, places have only been available in MusicBrainz for 10 days) list of performances. That's a really popular example but we also have smaller/less popular places like the St. Mary Magdalene Church in Wroclaw at [5] or the Kabarett im Hofgarten in Aschaffenburg at [6]. A map of all the currently existing places with coordinates is available at [7]. AFAIK Wikidata doesn't even have properties for mixing/mastering/recording location (yet?) --Mineo (talk) 08:57, 24 October 2013 (UTC)

 Support--Shisma (talk) 12:38, 24 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Migrate data in Property:P296. See Wikidata:Properties for deletion. Liangent (talk) 21:20, 18 October 2013 (UTC)

 Oppose. Use subclass of (P279) with qualifier instance of (P31):'MTR station code'. Filceolaire (talk) 22:25, 18 October 2013 (UTC)

 Support, How can subclass of (P279) hold string?--GZWDer (talk) 04:31, 19 October 2013 (UTC)

 Support A.Bernhard (talk) 05:07, 24 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Migrate data in Property:P296. See Wikidata:Properties for deletion. Liangent (talk) 21:33, 18 October 2013 (UTC)

 Oppose. Use subclass of (P279) with qualifier instance of (P31):'TMIS station code'. This way all stations can import their station code from property P279 with the qualifiers adding precision where required, rather than each railway having to have a different infobox. Filceolaire (talk) 22:31, 18 October 2013 (UTC)

I'm puzzled about how you see that working out. This is numerical data. --Izno (talk) 02:14, 19 October 2013 (UTC)

 Support --A.Bernhard (talk) 02:51, 19 October 2013 (UTC)

 Support--GZWDer (talk) 04:31, 19 October 2013 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Migrate data in Property:P296. See Wikidata:Properties for deletion and above: this is another coding schema used in the same railway system. Liangent (talk) 08:12, 19 October 2013 (UTC)

 Support --A.Bernhard (talk) 09:10, 23 October 2013 (UTC)