Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
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.
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 2023/02.
Comment What's "de jure, de facto"? Should have both de jure and de facto items? Or a new item called this should be created? --Liuxinyu970226 (talk) 11:20, 11 April 2019 (UTC)Reply[reply]
@ديفيد عادل وهبة خليل 2, Liuxinyu970226: I had hoped for discussion on this to be kept on the page for the RfC itself, if everyone's okay with that. (@Liuxinyu970226, as explained on the RfC, the proposal is for a new item labelled "de jure, de facto" to be created, which would be for those which are both de jure and de facto authorities over disputed territories.) --Yair rand (talk) 18:46, 11 April 2019 (UTC)Reply[reply]
Comment I think we should sort out the relation to existing properties before creating this. Per RFC (and later linked from one of the properties), this should also replace existing ones. It's not clear why though. --- Jura 18:10, 1 July 2019 (UTC)Reply[reply]
Support I would like to add the ISO 2 Code of the country it is recognized by, this would help massively with subsequent data integration instead of just showing the country names (they are always spelled differently across data sources, whereas standardized ISO codes simplifies data integration) --- AddNPBot 11:12, 16 July 2019 (UTC)Reply[reply]
Support for “recognized by”, “not recognized by”, “jurisdiction status”. Oppose for “recognition”. Already statement is subject of (P805) can be used. --Wdpp (talk) 18:28, 7 August 2020 (UTC)Reply[reply]
Support seems useful for items about countries. --IWI (talk) 00:09, 24 August 2020 (UTC)Reply[reply]
Support recognition, recognized by and not recognized by. Weak oppose jurisdiction status. Ari T. Benchaim(talk) 01:35, 19 June 2021 (UTC)Reply[reply]
So, this page was specifically not supposed to be the discussion area for the proposals, as mentioned. (See also the lack of a "discussion" section on this page.) The actual proposal is described on the linked RFC page, and is not described on this page. Many of the comments above do not seem to be regarding the actual proposed properties as described in the RFC. The proposal and discussion area are at Wikidata:Requests for comment/Countries, subdivisions, and disputed territories. This page exists to be a pointer to there. --Yair rand (talk) 04:28, 20 July 2021 (UTC)Reply[reply]
@Yair rand: Hi - it's been over 2 years since this proposal and RFC were started; there have been a few comments on the RFC since you last commented here, can you respond and perhaps we can settle where to go from here now? Another editor had marked these as ready but I am not sure on that (but they could be!) ArthurPSmith (talk) 18:29, 17 June 2022 (UTC)Reply[reply]
After a member of the WikiProject Human rights had asked me today how to model that citizens of certain countries don't have certain rights, I created the proposal (not) officially recognized by . I embarrassingly missed that this proposal already existed ... however seeing that 1) this proposal has been met with opposition because it suggests "recognition" which can just be modeled with statement is subject of (P805) and "jurisdiction status" ... which can also just be modeled with nature of statement (P5102) & statement disputed by (P1310) and 2) that this proposal has apparently been abandoned it's probably good that I created a new proposal.
So please check out my proposal (not) officially recognized by ... I also have examples for human rights, animal rights, religions and atrocities and suggestions for some property constraints :)
Turkish Statistical Institute (TÜİK) is the Turkish government agency responsible for producing official statistics on demographics data related to Turkey. It would be beneficial for Wikidata users to have an identifier pointing to populated places in Turkey, regarding population data. --Superyetkin (talk) 14:06, 1 May 2022 (UTC)Reply[reply]
@Superyetkin: this request is incomplete. Please fill out the full template and add examples. Multichill (talk) 15:31, 1 May 2022 (UTC)Reply[reply]
Examples are available in the source file. Thanks. --Superyetkin (talk) 15:59, 1 May 2022 (UTC)Reply[reply]
@Superyetkin: If you don't bother to fill out the template, we won't bother creating the property and just close it as incomplete. Please put in some effort. Multichill (talk) 16:01, 1 May 2022 (UTC)Reply[reply]
Oppose in the absence of examples for those of us who are not tr-N. Mahir256 (talk) 19:31, 1 May 2022 (UTC)Reply[reply]
@Superyetkin: You should provide real examples. Examples must link to any Wikidata subject (in this case, items). The xlsx you provide doesn't have links to Wikidata items, and it is written in Turkish, a lot of us are unable to understand that language in order to vote. --Tinker Bell★♥ 05:05, 2 May 2022 (UTC)Reply[reply]
Support There are 18217 villages, 32131 neighborhoods, 1366 municipalities, 981 districts in Turkey, and the en:Turkish Statistical Institute (TUIK) announces the population data for these settlements on 1 February every year. It is very difficult to manually enter the population value of more than 50 thousand settlements into wikidata every year and repeat it every year. If we match the TUIK ID number with the Wikidata item number, a bot can easily import the population data from an excel list into wikidata. --Sadrettin (talk) 16:24, 8 May 2022 (UTC)Reply[reply]
There would have to be a way to distinguish between different units with the same ID - for example searching for the instance of mahalle (Q17051044) with value "2" would probably find Q6653955, when it refers to Q97229878 for that unit type. If every item has the correct P31, an item could be updated from village in Turkey (Q1529096) to mahalle (Q17051044) without updating the ID (perhaps because it isn't known yet) and population would be added to the wrong item. Q3604202 (talk) 12:02, 21 May 2022 (UTC)Reply[reply]
There are no two different characteristics of settlements in Turkey. A place is either a village or a neighborhood. There is no village named "Kabasakal" (Q6653955) in Çukurova district. There is only a neighborhood called "Kabasakal". The Turkish Statistical Institute announces the population values of the "Kabasakal" neighborhood every year. Tuik ID-Wikidata ID pairings are made by checking one by one. As in the example on the right, one-to-one control is made over the excel list.--Sadrettin (talk) 17:44, 23 May 2022 (UTC)Reply[reply]
The status of a place can change over time, and Wikidata keeps historical statistics and identifiers, and statistics are available from when it was. It's less of an issue if current status and identifier have "preferred" rank and start dates, and former status and identifier have end dates, but that isn't guaranteed to happen, and would only be possible if the identifiers were available at the same time as the status change. Queries would be easier with separate identifiers, and another reason to create separate properties is that if links become available that use these identifiers, they would probably require a different formatter URL (P1630) for each type. Q3604202 (talk) 23:37, 31 May 2022 (UTC)Reply[reply]
Support The concerns are irrelevant. It'll be beneficial for tr.wikipedia. There are many villages, neighborhoods and municipalities in Turkey. Therefore if we don't use it, we'll be exposed to a huge workload which discourage people to update these articles.--Sabri76 (talk) 21:35, 8 May 2022 (UTC)Reply[reply]
Support I think it will be useful for en.wikipedia ×Elvorixtalk 17:08, 20 May 2022 (UTC)Reply[reply]
Comment @Sabri76: Can you explain why "the concerns are irrelevant"? It seems to me that Q3604202's comment above clearly shows that this as proposed is not an external ID, since the same identifier number can refer to two or more different entities. Separate properties should be proposed for each administrative level. Since "neighborhoods" are the most numerous according to Sadrettin's statistics, we could start with that, and make this proposal "Tüik number for a neighborhood" for example. ArthurPSmith (talk) 16:18, 23 May 2022 (UTC)Reply[reply]
Strong oppose (Edited to remove this if datatype is string ArthurPSmith (talk) 20:57, 7 June 2022 (UTC)) Unless this limited to one settlement type and different id's are proposed for the others. This will not work as an external id within Wikidata if the same number can be assigned to multiple entities. ArthurPSmith (talk) 13:37, 25 May 2022 (UTC)Reply[reply]
Each settlement has only 1 attribute and 1 number. --Sadrettin (talk) 17:39, 25 May 2022 (UTC)Reply[reply]
@Sadrettin: That's not the issue. The issue is that two (or up to five or six) Wikidata items will have the same number, if there is only the one property. That breaks the basic logic of external identifiers to identify things. ArthurPSmith (talk) 17:55, 26 May 2022 (UTC)Reply[reply]
Support It will be very good solution for population datas. -- Zafer (talk) 10:19, 29 May 2022 (UTC)Reply[reply]
Support it would be very useful for the Turkish Wiki. It sipmlifies many processes. Nevmit (talk) 23:52, 4 June 2022 (UTC)Reply[reply]
@Superyetkin, Multichill, Mahir256, Tinker Bell, Q3604202, Sadrettin: @Sabri76, Vikipolimer, Elvorix, Jelican9: @Maurice Flesier, Zafer, Nevmit, Kadı: I have changed the datatype to string, since (A) there seems to be strong support for this to be created, but (B) it does not qualify as an external-id due to the duplication of use of the same number for different entities, and (C) there is no formatter URL here anyway. If supporters are ok with this then I would consider this to be ready for creation. If you really want this as an external-id datatype then it needs to be split into separate proposals for each level as discussed above. ArthurPSmith (talk) 15:02, 6 June 2022 (UTC)Reply[reply]
I am okay with the string data type. Thanks. --Superyetkin (talk) 15:08, 6 June 2022 (UTC)Reply[reply]
User:ArthurPSmith I don't get it. At any point in time one Wikidata item matches one Tüik number. Over time things change like mergers and split up so multiple id's will be on one item and multiple items will have the same id, of course all qualified with start and end time. Isn't that how a lot of external identifiers work? What I just described also applies to for example CBS municipality code (P382). How is this different? Multichill (talk) 15:20, 6 June 2022 (UTC)Reply[reply]
@Multichill: No, one number can correspond to up to 6 WIkidata items at the same time - see the example stated above by Q3604202 "For example 2056 in the example is the identifier for Bayraklı (Q812591), but also refers to Esendere (Q1367550), Kutuören (Q6448671) and Aydoğdu (Q4830384), depending on whether it is the district of Turkey (Q1147395), municipality (Q2460358), mahalle (Q17051044) or town municipality of Turkey (Q815324)/village in Turkey (Q1529096)" - ArthurPSmith (talk) 15:36, 6 June 2022 (UTC)Reply[reply]
String datatype is ok, this proposal can be marked as ready. --Tinker Bell★♥ 20:21, 6 June 2022 (UTC)Reply[reply]
Strong oppose Can someone explain why this should be a single property? It appears to be a set of identifiers, the spreadsheet even separates them into separate sheets. Combining them into a single property for the sake of it and using the string type because it's no longer representing an identifier does not seem like the right way to store the data. - Nikki (talk) 11:35, 18 June 2022 (UTC)Reply[reply]
Comment I'm tired of the bureaucratic processes of Wikidata. I will no longer comment. My only goal was to quickly add population values to the pages of 50 thousand settlements in Turkey. Wikidata lost a volunteer. Sadrettin (talk) 19:17, 4 August 2022 (UTC)Reply[reply]
Splitting into one property per subdivision level seems the best to me. --GrandEscogriffe (talk) 18:40, 15 February 2023 (UTC)Reply[reply]
there are about 17000 localities in Austria - everything that has a locality number in Austria (P8384). I hope I can do about 2 to 3 percent of Austria within the next month
It should be used in both directions, from the municipality to the localities in blocked form like in Q695443#P10254 and from the hamlets etc. to the locality like in Q92267797#P10254. I want to create this section de:Hengsberg#Ortschaften with wikidata. --Maincomb (talk) 22:43, 9 September 2022 (UTC)Reply[reply]
Comment I would be happier if the proposal only went one clear way. Note that we already have located in the statistical territorial entity (P8138), which can be used for items which are not administrative entities; or location (P276) which could be used with a suitable object has role (P3831) qualifier. I would be more happy to see either of those patterns used instead of the present proposal; particularly if the proposal is going to keep the current extremely vague proposed label, which looks doomed to be a confuser for significant place (P7153). Jheald (talk) 16:02, 12 September 2022 (UTC)Reply[reply]
In Austria, there are three types of localities (in our language: Ortschaft (Q11183787)): localities, that are represented by Ortschaft (Q11183787), localities, that are represented by locality (Q3257686) and localities, that are not represented in wikidata by now. All three types are called de:Ortschaft, the first ones are maintained by municipalities, the second ones are maintained by the federal Statistical Office of Austria and the third are maintained by the postal service of Austria. One may say administrative localities, statistical localities and postal localities, but these are not terms used in Austria, all is just called "Ortschaft". Here in Wikidata, somebody translated locality number in Austria (P8384) with "locality number" and so we (mis-)use "locality" for all objects with this "locality number" instead of Ortschaft (Q11183787), that is now used for localities maintained by municipalities.
A locality (the type maintained by the federal Statistical Office of Austria) is a cultural, economic, residential, historic, administrative and political unit and the Statistical Office sets a statistical view on it. So it is not a statistical entity, but there are data about it. (Localities can extend across municipality boundaries, change their name, united ... so it in not fully usable as statistical entity.)
So all this would be mixed up. It will be easy to make mistakes and it will be hard to find them. What is about maintenance, when one cannot see what to do? And most important: I want to use this list within articles as shown in sl:Zgornji_Osek,_Avstrija#Naselja_v_občini (bulleted list below "Naselji Zgornji Osek so:"). So I want to keep it simple like with associated cadastral district (P10254), where it is clear what to put in and what will come out.
identifier of plot or particular area of land in the cadastre of a town or other locality. If available, use more specific unique identifier properties for the value.
associated cadastral district (P10254): cadastral district in which a place is located or is part of. Use only if distinct from administrative entities (P131) in predefined countries
Czech cadastral area ID (P7526): identifier for a cadastral area in the Czech Republic, conferred by 'Český úřad zeměměřický a katastrální'
cadastral municipality ID in Austria (P8322): identifier for cadastral municipalities of Austria (Katastralgemeinde-Nummer); format: 5 digits; different from "Austrian municipality key" (P964)
Also, there is Wikidata:Property proposal/Finnish real property ID that provides a countrywide unique identifier. In general, if an identifier for a country or larger area can be done, I think that would be preferable (Add your motivation for this property here.) --- Jura 12:21, 8 February 2022 (UTC)Reply[reply]
Thanks for the sample, I added it above. --- Jura 10:15, 9 February 2022 (UTC)Reply[reply]
Support I like this property. Regarding the aliases to be added after creation, I would like to point out that there are different names for them in Germany. In the Wikipedia articles of the German examples, the "Parzellennummer" is mentioned. At least in Saxony it is called Flurstücksnummer. As an example, I would cite the German-language article Weißes Schloss, where the Flurstücksnummer of the former castle is mentioned. --Gymnicus (talk) 07:56, 15 February 2022 (UTC)Reply[reply]
Thanks for the additional sample. Also, I completed the terminology at Q108102235 accordingly. --- Jura 15:07, 15 February 2022 (UTC)Reply[reply]
Oppose It is not a universal concept, it varies for each state. Since we don't know the administrative entity to which it relates (district, city, region, etc.), linking to a number is imprecise; the identifier should contain all the information. Please see the questions this has raised on Wikidata:Property proposal/cadastral plot in France. — Baidax💬 18:40, 6 March 2022 (UTC)Reply[reply]
This isn't meant to be a unique identifier (contrary your non-official Etalab one), so it has string datatype, similar to house number (P670). Maybe you have an alternative proposal for samples 1 and 2 (both from France). --- Jura 18:56, 6 March 2022 (UTC)Reply[reply]
@Jura: A street number is used as a qualifier with a specified street item. Here, the information of the administrative entity to which the number relates is missing. It is therefore both a mixture of legal systems and a lack of precision. — Baidax💬 19:54, 6 March 2022 (UTC)Reply[reply]
As one may notice in the samples, the cadastral reference is sometimes included to describe a given concept.
What alternative do you propose for the samples given above? --- Jura 19:59, 6 March 2022 (UTC)Reply[reply]
@Jura: Since the jurisdictions are not the same, perhaps there should be a distinction by state? There are probably some that should exist with full IDs. Or it should be put as a qualifier for one of the existing properties (but that would be clumsy). — Baidax💬 20:15, 6 March 2022 (UTC)Reply[reply]
If there is a better solution, I'd be all for it, but I suppose I'd have to see a working alternative samples to tell.
Comment I like the idea but cadastre is complicated and it needs more thinking (for instance the first examples feels wrong Cordouan Lighthouse (Q199234) is BW 1 not 1, the BW prefix for the cadastral division (Q18346622) is needed as there is several "1" for each commune and not all country have commune nor equivalent ; hence the diference between terms like "cadastral plot reference" and "cadastral number"). PS: what are we doing about cadastral municipality ID in Austria (P8322)? Cheers, VIGNERON (talk) 20:54, 6 March 2022 (UTC)Reply[reply]
It's something that should be included in one way or the other. Depending on how much interest there is, a property for Cadastre of Quebec (Q60852524) could be created, similar to the one for Finland. A separate property for the lot/block/etc system used at various places could be interesting as well.
For either, I don't think we had much demand yet. This proposal mainly aims to cover information already included in Wikipedia and Commons, which generally doesn't attempt to include "unique" identification. --- Jura 11:03, 13 March 2022 (UTC)Reply[reply]
Comment As the cadastral plot reference system of each country and its jurisdiction differs, implementing a unified cadastral plot reference system through a single property is no adequate solution. I support the idea of cadastral plot references as Wikidata properties in general but strongly advocate for seperating properties based on their applicapable jurisdiction, e.g. an Austrian cadastral plot reference, a Finish cadastral plot reference, a German cadastral plot reference etc. Here in Germany, the cadastral plot reference system is based on the Gemarkunglocated in the administrative territorial entity (P131), the Flur (no property or item as of now) and the Flurstückland lot (Q683595). The system applies to all 16 states of Germany. A Flurstück is either designated as a positive integer, e.g. Flurstück 1 or as a positive rational number, e.g. Flurstück 1/10 (read Flurstück Eins aus Zehn; plot one out of ten). A Flur is always a positive integer, e.g. Flur 1. Designating an individual object requires all three identification markers, since Flur and Flurstück are no unique identifiers. Multiple Flurstücke constitute a single Flur. For example Flur 1, Flurstück 1/10 could exist in Berlin, Munich or elsewhere in Germany, hence knowledge about the administrative unit is mandatory. Regards, Christoph Braun (talk) 14:18, 28 January 2023 (UTC)Reply[reply]
The median household income is a very good indicator for the characteristics of the social standard and the standard of living of a city or county, especially if compared to the number of the state or whole country. It is reasonable information besides the mean per capita income and the mean household income, as those arithmetial average numbers can be influenced by individuals with very high income, which is not the case if a median is used.
For many countries, this data is retrieved by government-run programs with a very reliable data base, such as the 5-year American Community Survey that analyzes every eighth individual in a given 5-year timespan. The data of the 2016-2020 survey was recently published and can be used for Wikidata, and with having the data on Wikidata, we can use them in the Wikipedia articles.
Important: We already have median income (P3529). This property has an issue, as its title suggests to refer to the median income per individual, whereas the description rather refers to the median household income (and suggesting that both numbers can be mixed, which I do not consider very reasonable, as there's an obvious difference between the median per capita income and the median household income). As the median income (P3529) is currently used only 50 times, I would like to analyze each usage of that property once this proposal was realized, so after that we will have proper statements clearly either referring to the median per capita income or the median household income. Thanks, Yellowcard (talk) 06:38, 27 April 2022 (UTC)Reply[reply]
@ArthurPSmith: That could be an alternative. I think it is two different approaches, what are the pros and cons for using the same property for different kind of data compared to using two different properties? Regards, Yellowcard (talk) 06:21, 29 April 2022 (UTC)Reply[reply]
Further thinking about this, I believe that there will be the permanent uncertainty whether the data refers to median income per person, per household, per family, unless clearly defined in the property description. Not everyone adding statements will use the clarifying qualifier. Therefore, if there are no big disadvantages of using two separated properties, I still vote for this proposal, but of course I stay open for other approaches. Yellowcard (talk) 07:15, 29 April 2022 (UTC)Reply[reply]
As a non-WD-speaker I'm wondering whether the use of a qualifier could be obligatory? --G-41614 (talk) 13:29, 3 May 2022 (UTC)Reply[reply]
@G-41614 We could use constraints, but this would not prevent anybody technically from adding statements without this qualifier. There would be a symbol popping up and the item would show up in daily "Constraint Violation Reports", but realistically no one is capable to fix this issue if someone adds lots of data without this specifying qualifier.
On the other hand, I do not really see a disadvantage of a new property, so we clearly have "median income per person" and "median income per household", without any risk of confusion. Best regards, Yellowcard (talk) 06:24, 4 May 2022 (UTC)Reply[reply]
I Support this property as is. If we store a lot of values like this because we want to have yearly values storing them in their own property is cheaper than using a qualifer for it. ChristianKl ❪✉❫ 11:22, 5 December 2022 (UTC)Reply[reply]
Copernicus Emergency Management Service activation ID[edit]
On hold
Description
Identifiers for Copernicus Emergency Management Service (CEMS) rapid mapping activations.
The CEMS tracks the extent and evolution of an ongoing disaster, such as a wildfire or a cyclone, which in some cases has prompted the creation of a Wikipedia article as well as the corresponding Wikidata item. The CEMS website is a useful source for anyone interested in a deeper understanding of the subject. Sabbut (talk) 20:28, 14 August 2022 (UTC)Reply[reply]
This ID will link up wikidata with the factpages about oil and gas fields in the north sea, and by so doing it can also be used by the linked wikipedia articles about them. There's aren't many IDs but the items are all notable. Infrastruktur (talk) 20:06, 5 February 2023 (UTC)Reply[reply]
"Satellite image" and "satellite picture" are currently aliases of aerial view (P8592). Yet satellite views and aerial views are two clearly disjoined classes of pictures, as shown by their disjoined Commons categories: satellite pictures and aerial photographs.
A picture taken from outer space is obviously not taken from "the air", and there are also typical differences in outlook: satellite views tend to have a more vertical angle and aerial views a more oblique one (when satellite views are oblique they can include a cross-section of the atmosphere which makes them even more different from aerial views). While some large objects may only have a satellite picture, and some small objects only an aerial one, there is a range of object size (mountains, cities, big buildings...) where both are relevant and clearly distinct, like Uludağ (Q925688) where I hav uploaded an actual aerial view different from the satellite view in the exemple above.
So many (but far from all) of uses of aerial view (P8592) will have to be moved to the new property, and some of these replaced by actual aerial views. --GrandEscogriffe (talk) 18:00, 15 February 2023 (UTC)Reply[reply]
Note: underlines "_" are changed to dashes "-" in the URLs when a venue is corrected/updated (e.g. if you want to correct its website or address, but adding or editing concerts doesn't interfere on them since they're added separately). –Guttitto (talk) 20:57, 20 January 2023 (UTC)Reply[reply]
Weak oppose I'm in principle not opposed to new external IDs in the cultural sector. However, in this particular case, I browsed the database and I was unable to search and find venues (what did I miss?). This external ID is unlikely to be adopted if other users have the same experience as I. Fjjulien (talk) 23:34, 2 February 2023 (UTC)Reply[reply]
Support valuable website (more soprintendenze should have a similar one!); I confirm I didn't receive the first ping. --Epìdosis 09:45, 6 February 2023 (UTC)Reply[reply]
Support and I agree it's a pity that it seems not possible to use the same ID with two different formatter URLs. --Epìdosis 15:17, 3 February 2023 (UTC)Reply[reply]
Support All David (talk) 07:26, 8 April 2019 (UTC)
Comment What's "de jure, de facto"? Should have both de jure and de facto items? Or a new item called this should be created? --Liuxinyu970226 (talk) 11:20, 11 April 2019 (UTC)
Oppose in current form of proposals. 
Weak oppose jurisdiction status. Ari T. Benchaim (talk) 01:35, 19 June 2021 (UTC)
Done --Superyetkin (talk) 12:43, 3 May 2022 (UTC)
Strong oppose
Like Jelican9 (talk) 17:08, 6 June 2022 (UTC)
Comment I'm tired of the bureaucratic processes of Wikidata. I will no longer comment. My only goal was to quickly add population values to the pages of 50 thousand settlements in Turkey. Wikidata lost a volunteer. Sadrettin (talk) 19:17, 4 August 2022 (UTC)
![[3]](https://fr.wikipedia.org/wiki/Fichier:La_madeleine_en_dessin_03956.jpg){kind=link}
