Wikidata:Property proposal/Place: Difference between revisions

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/11.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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

 Oppose per Filceolaire --Pasleim (talk) 18:03, 29 October 2013 (UTC)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

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

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

 Comment 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)[reply]

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

 Oppose use P281 --Pasleim (talk) 18:54, 29 October 2013 (UTC)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

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

 Comment 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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

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 [1]. 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)[reply]

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

 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)[reply]

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

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

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

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

  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)[reply]

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

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

 Comment 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)[reply]

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

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

• 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)[reply]
•  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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

•  Support Fully documented property. Mange01 (talk) 20:16, 13 March 2013 (UTC)[reply]
•  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)[reply]
  • Actually, in some countries it is verifiable, because the government has specified them. --Rschen7754 22:26, 22 July 2013 (UTC)[reply]
•  Comment 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)[reply]

 Comment 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)[reply]

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

• 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)[reply]

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

 Comment 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)[reply]

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

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

 Comment - 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)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

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)[reply]
•  Support Can be used in several infoboxes.--Ahonc (talk) 12:50, 28 June 2013 (UTC)[reply]
•  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)[reply]
•  Oppose not a good idea to promote. --Rschen7754 20:53, 2 July 2013 (UTC)[reply]
  • Could you explain in details that you mean? — Ivan A. Krestinin (talk) 21:14, 2 July 2013 (UTC)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
          • Sorry, I do not understand your idea. — Ivan A. Krestinin (talk) 17:50, 3 July 2013 (UTC)[reply]
            • 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)[reply]
              • 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)[reply]
                • Are you sure? Even if you use P625 as the qualifier of terminus (P559)? --Rschen7754 22:58, 3 July 2013 (UTC)[reply]
                  • 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)[reply]
                    • What are the terminii? --Rschen7754 01:06, 4 July 2013 (UTC)[reply]
                      • European Square (Q2997168), Bessarabska Square (Q2667365).--Ahonc (talk) 11:06, 4 July 2013 (UTC)[reply]
                        • Okay, it's been added. --Rschen7754 18:57, 4 July 2013 (UTC)[reply]
                          • 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)[reply]
•  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)[reply]
•  Oppose Linear feature can be point out with a qualifier. --Fralambert (talk) 13:49, 7 July 2013 (UTC)[reply]

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

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

  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)[reply]

•  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)[reply]
  • 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)[reply]
•  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)[reply]
•  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)[reply]

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

  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)[reply]

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

  @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)[reply]

• 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)[reply]
•  Support required for infobox. --  Docu  at 01:45, 7 September 2013 (UTC)[reply]
•  Comment 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)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

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)[reply]

 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)[reply]

 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)[reply]

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

 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)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

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)[reply]

•  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)[reply]

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)[reply]

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)[reply]

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)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

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

 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)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

 Comment - 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)[reply]

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

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

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

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

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

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

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

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

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)[reply]

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)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

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

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

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

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

 Oppose untill consensus is reached at Wikidata:Properties_for_deletions#Bahnhofscode_.28P296.29 --Pasleim (talk) 21:56, 29 October 2013 (UTC)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

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

 Oppose. Use <str>subclass of (P279)</str>station code (P296) 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)[reply]

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

Sorry. I meant P296 not P279. 86.6.107.229 20:31, 6 November 2013 (UTC)[reply]

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

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

 Oppose until consensus is reached at Wikidata:Properties_for_deletions#Bahnhofscode_.28P296.29 --Pasleim (talk) 21:58, 29 October 2013 (UTC)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

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)[reply]

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

 Oppose until consensus is reached at Wikidata:Properties_for_deletions#Bahnhofscode_.28P296.29 --Pasleim (talk) 22:00, 29 October 2013 (UTC)[reply]

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

The ID "Property proposal" is unknown to the system. Please use a valid entity ID.

Discussion

Motivation: Wikidata:Country_subdivision_task_force/Austria. Zuphilip (talk) 13:23, 2 November 2013 (UTC)[reply]

Huch, it is already there Austrian municipality key (P964). Why haven't I found it? Well, I will add some more aliases and discuss some changes of the constraints there.... Sorry! --Zuphilip (talk) 13:55, 2 November 2013 (UTC)[reply]