Wikidata:Property proposal/Place


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

See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  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. Start writing the documentation based on the preload form below and add it in the appropriate section.
Caveat
Do not use the Visual editor, because it will mess up the content of your request (the order of the template parameters will be shuffled and paragraphs are concatenated as one long string of text).

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 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 2022/05.

ParkEdit

Hierarchy of administrative territorial entitiesEdit

contains statistical territorial entityEdit

   Under discussion
Description(list of) statistical territorial entities which are direct subdivisions of another statistical or administrative territorial entity
Representsstatistical territorial entity (Q15042037)
Data typeItem
Domainitem
Allowed valuesinstance of or instance of subclass of statistical territorial entity (Q15042037)
Example 1Baltimore (Q5092)Penn-North (Q18158432)
Example 2Prince George's County (Q26807)Hillcrest Heights (Q753976)
Example 3United States of America (Q30)United States Minor Outlying Islands (Q16645)
Example 4Marmara Region (Q155583)West Marmara Region (statistical) (Q19839480)
Planned useinclude lists of statistical territorial entities in the item for their parent geographies; correct instances of statistical territorial entities listed with the "contains administrative territorial entity" property
Expected completenessalways incomplete
See alsocontains administrative territorial entity (P150) located in the administrative territorial entity (P131) located in the statistical territorial entity (P8138)

MotivationEdit

The intent of this property proposal is to mirror the existing "contains administrative territorial entity" property for statistical territorial entities. The distinction between these types of entities is that statistical territorial entities are subdivisions which have names and boundaries but do not have their own administrative bodies. The existing "located in the statistical territorial entity" property mirrors the "located in the administrative territorial entity," but there is an incongruency in that there is no corresponding "contains" property for the statistical entities. Sometimes this results in them just being grouped in with the administrative entities - like for example, it is not technically accurate that the United States Minor Outlying Islands is listed as an administrative entity contained by the United States on the country item page. The USMOI does not have a government/administration; it is a statistical designation that covers areas not included within the administrative regions. The creation of this property would also make it easier to describe places that are subdivided into "towns" that do not have governments on their own (common for many United States counties for example), or for things like designated sections or neighborhoods of cities which have an official status but do not have a governing body. Middle river exports (talk) 20:48, 8 May 2022 (UTC)

DiscussionEdit

Properties proposed in RfC "Countries, subdivisions, and disputed territories"Edit

recognitionEdit

   Ready Create
Descriptioninternational recognition of the statement (use as qualifier for P31, P17, and P131)
Data typeItem
Example 1Armenia (Q399) instance of (P31) sovereign state (Q3624078) → "international recognition of Armenia"
Example 2Crimea (Q7835) country (P17) Russia (Q159) → "recognition of Crimea as a part of Russia"
Example 3Israel (Q801) instance of (P31) sovereign state (Q3624078)international recognition of Israel (Q6055209)

recognized byEdit

   Ready Create
Data typeItem
Example 1international recognition of Kosovo (Q23052)United States of America (Q30)
Example 2"recognition of Crimea as a part of Russia" → Sudan (Q1049)
Example 3"international recognition of Armenia" → United States of America (Q30)

not recognized byEdit

   Ready Create
Data typeItem
Example 1"international recognition of Armenia" → Pakistan (Q843)
Example 2"recognition of Crimea as a part of Russia" → Italy (Q38)
Example 3international recognition of Kosovo (Q23052)Madagascar (Q1019)

jurisdiction statusEdit

MotivationEdit

These proposed properties are part of a broader proposal at Wikidata:Requests for comment/Countries, subdivisions, and disputed territories. Please comment there. --Yair rand (talk) 07:24, 8 April 2019 (UTC)

  •   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)
    @ديفيد عادل وهبة خليل 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)
    @Yair rand: Another interesting thing is that, how the second and third proposals are not covered-able by statement supported by (P3680) and statement disputed by (P1310). --Liuxinyu970226 (talk) 04:22, 17 May 2019 (UTC)
  • Interesting proposal. I do see plenty of advantages. --- Jura 19:29, 13 April 2019 (UTC)
  •   Support This will give lot of important information! -Theklan (talk) 14:55, 22 May 2019 (UTC)
  •   Support NMaia (talk) 22:31, 22 May 2019 (UTC)
  •   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)
  •   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)
  •   Oppose in current form of proposals.   Support the "recognized by" property if both the domain and value type constraint are changed to state (Q7275). Qualifier statement is subject of (P805) can then be used with the new "recognized by" property with a value type of international recognition of a country (Q19602404). Dhx1 (talk) 13:17, 8 October 2019 (UTC)
  •   Support Iwan.Aucamp (talk) 23:10, 8 October 2019 (UTC)
  •   Oppose in current form, and   Support in the form presented by Dhx1 TiagoLubiana (talk) 15:41, 8 March 2020 (UTC)
  •   Oppose--Dispe (talk) 12:45, 1 May 2020 (UTC)
  •   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)
  •   Support seems useful for items about countries. --IWI (talk) 00:09, 24 August 2020 (UTC)
  •   Support «recognized by» and «not recognized by».   Oppose the other two: «jurisdiction status» is nature of statement (P5102), «recognition» is statement is subject of (P805). --Tinker Bell 05:24, 13 February 2021 (UTC)
  •   Support recognition, recognized by and not recognized by.   Weak oppose jurisdiction status. Ari T. Benchaim (talk) 01:35, 19 June 2021 (UTC)

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)

StreetEdit

Body of waterEdit

Geographic locationEdit

subpopulationEdit

   Ready Create
Descriptionpartial population according to some criteria
Representssubpopulation (Q2311577)
Data typeNumber (not available yet)
Domainplace
Allowed valuesinteger
Example 1Pristina (Q25270) → 426; point in time (P585) → 1961; ethnic group (P172)Macedonians (Q2436423)
Example 2See below for alternatives
Example 3MISSING

MotivationEdit

This is a proposed solution of Wikidata:Project_chat#Something_wrong_here?. Previous proposals:

I think this is better than the following alternatives:

For qualifiers:

-- GZWDer (talk) 22:39, 21 March 2020 (UTC)

DiscussionEdit

  •   Support --SilentSpike (talk) 22:45, 21 March 2020 (UTC)
  •   Weak support I guess this is ok, but I'm a little sad we can't use population (P1082) with qualifiers. I understand the reasoning, but it seems to me it applies to many other cases too, and maybe our data consumers should get a little smarter about checking for qualifiers. ArthurPSmith (talk) 18:24, 23 March 2020 (UTC)
  •   Question Could you include a qualifier to determine how the subcategory is done? e.g. criterion used (P1013)=eye color. Supposedly, people could add multiple sub-populations for the same date that aren't meant to add up. BTW, we already have male population (P1540) and female population (P1539). --- Jura 18:51, 26 March 2020 (UTC)
Also literate population (P6499) and literacy rate (P6897). --- Jura 19:00, 26 March 2020 (UTC)
  • how about renaming it to "population by ethnic group" Germartin1 (talk) 13:48, 23 May 2020 (UTC)
    •   Support for "population by ethnic group". This could also used for the race data provided by the US Census Bureau and will probably help a lot to import the US census data coming next year. Yellowcard (talk) 14:11, 26 July 2020 (UTC)
    •   Support I agree that "population by ethnic group" would be the most practically useful property as it woul allow us to easily import and store census data from any country.--Kiril Simeonovski (talk) 13:26, 28 July 2020 (UTC)
  • I don't feel qualified to comment on the technicalities, but I very much would support some easier way to be able to represent the racial/ethnic demographics of an entity. {{u|Sdkb}}talk 13:34, 6 August 2020 (UTC)
    Also,   Question: How would this work for entities that aren't regions? E.g. if I want to specify the percentage of female students, first generation students, or international students at MIT? {{u|Sdkb}}talk 20:06, 15 September 2020 (UTC)
  • It looks like the discussion on this has ceased, and there's no explicit objections, and some support. This is probably ready... JesseW (talk) 14:27, 28 March 2021 (UTC)
    • There are still open questions. Obviously   Strong oppose until this is sorted out. --- Jura 16:23, 28 March 2021 (UTC)
      • Sorry, I missed that you had commented on this; I wouldn't have spoken up if I'd noticed. JesseW (talk) 16:28, 28 March 2021 (UTC)
        • It seems as if you don't read (or understand) the discussions. --- Jura 16:39, 28 March 2021 (UTC)
          • It seems as if you can't let your attacks stop. Drop it, please. JesseW (talk) 16:56, 28 March 2021 (UTC)
          • Why did you ignore the alternative proposal by three other users? --- Jura 17:00, 28 March 2021 (UTC)
            • I have already said that your hostile tone, personal attacks and assumption of my bad faith make it impossible for me to participate in discussions with you. I will not be continuing to do so here. JesseW (talk) 17:36, 28 March 2021 (UTC)
              • I don't assume anything. I just observe you marking a proposal as "ready" while there are still open points and proposed change of label. This is comment on your conduct, not an attack on your person. --- Jura 17:59, 28 March 2021 (UTC)
  •   Oppose While this data would be very useful, Wikidata isn't very good for storing numerical data. population (P1082) is an edge case yet acceptable, male population (P1540) and female population (P1539) is already a bit over the top. With different criterion used (P1013) that can be used to define population, this is really beginning to cause serious mess in some items. Vojtěch Dostál (talk) 08:33, 4 June 2021 (UTC)
    @Vojtěch Dostál: The demographic breakdown of places or other entities is certainly important information about them. I'm not wedded to having to represent that information here (it hasn't worked so well for COVID-19), but if not here, I'd want it to be somewhere on Wikimedia. What's your proposed alternative? {{u|Sdkb}}talk 04:36, 7 June 2021 (UTC)
    @Sdkb: The best option we currently have is Tabular data on Commons. Vojtěch Dostál (talk) 05:43, 7 June 2021 (UTC)
  •   Support as "population by ethnic group" Germartin1 (talk) 23:21, 3 December 2021 (UTC)

I'm concerned that the number of claims for subpopulation statements will become huge and difficult to keep track of from a UI and data-consumer perspective.

I'd like to suggest this alternative data model: Wikidata:Requests for comment/Population data model

Let me know what you think on that RFC Lectrician1 (talk) 20:26, 17 January 2022 (UTC)

  •   Oppose Even if there is a clear user case, some items about cities and countries are already overloaded with population (P1082) statements. In combination with a large number of aliases for popular items, this causes technical problems when using these items. We need to find some more suitable way to record this type of data (maybe Tabular data on Commons mentioned above by Vojtěch).--Jklamo (talk) 16:28, 13 April 2022 (UTC)
  Oppose I think we should stick with my data model instead and propose "population" and "number of parts" properties. Lectrician1 (talk) 19:27, 13 April 2022 (UTC)

Divided into cadastral areasEdit

   Ready Create

MotivationEdit

Municipalities in some countries are divided to administrative parts and cadastral areas (CA). Sometimes are these diivisions equal, but sometimes not. There exists contains administrative territorial entity (P150) for first type, and its opposite located in the administrative territorial entity (P131). Now we need opposite for associated cadastral district (P10254).

Example: Municipality Boršov nad Vltavou (Q894336) have two cadastral areas and four parts:

But there are also municipalities with many parts and only one CA, municipalities, where most parts are equals with CA, but in some CA exists more parts or municipalities, where is CA without settlement on it - this is why is not good to use contains settlement (P1383)

There is also possibility to use located in the administrative territorial entity (P131) with qualifiers, but this would make many queries and templates more complicated. There are situations, when municipality Foo have part Foo and CA Foo, but on CA Foo is also part Bar

As you can see, there is too much confusing Foos

On cs.wiki there is template {{Části obce}}, which lists for every municipality its parts using located in the administrative territorial entity (P131) and contains settlement (P1383). But CA are now connected with its municipality only by backlinks and cannot be listed with this template.

So i think, the best solution is to create new property for this

Tobias1984 Vojtěch Dostál YjM Jklamo Walter Klosse Sintakso Matěj Suchánek JAn Dudík Skim Frettie Jura1913 Mormegil Jedudedek marv1N Sapfan Daniel Baránek Draceane Michal Josef Špaček (WMCZ) The photonaut Hartasek Zelenymuzik Gumruch Shadster DenisaCZ M.Rejha Janek Jan Kameníček Eva Vele Linda.jansova Lukša Packa   Notified participants of WikiProject Czech Republic @Maincomb, Emu, Arbnos, MasterRus21thCentury:JAn Dudík (talk) 09:36, 8 February 2022 (UTC)

DiscussionEdit

I just modified Boršov nad Vltavou (Q894336), because associated cadastral district (P10254) can be used in both directions. Is this what you need? Second, the template cs:Šablona:Části obce mentioned above does not exist. --Maincomb (talk) 17:03, 8 February 2022 (UTC)
@Maincomb: Correct link is cs:template:Části české obce. I'll think about your usage, I'm afraid, these should be some issues with it. JAn Dudík (talk) 19:54, 8 February 2022 (UTC)

cadastral plot referenceEdit

   Under discussion
Descriptionidentifier 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.
Representsno label (Q108102235)
Data typeString
Allowed valuesper numbering used in a given cadastre. Generally unique within a cadastral district on a given point in time.
Example 1Cordouan Lighthouse (Q199234) → 1 [1]
Example 2Ancien cimetière de l'église de la Madeleine (Q26419561) → 109 [2]
Example 3Q1520341 → 679 [3]
Example 4Q26836639 → 476 [4]
Example 5Eggendorf Kapelle GstNr 870 (Q37813246) → 870 [5]
Example 6Aspersdorf Presshaus GstNr 12 (Q37789735) → 12 [6]
Example 7Weißes Schloss (Q47015213) → 208 [7]
Expected completenessalways incomplete (Q21873886)
See also

MotivationEdit

We had this as Wikidata:Property proposal/numéro de parcelle before, but somehow I struggled with finding a good translation to English. In the meantime, we have associated cadastral district (P10254) which uses the same terminology (in English). Hope it's better now.

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)

--- Jura 12:21, 8 February 2022 (UTC)

DiscussionEdit

  •   Support In Austria, it is called "Grundstücksnummer" ("Gst. Nr.") and already used sometimes, like in Eggendorf Kapelle GstNr 870 (Q37813246). --Maincomb (talk) 15:37, 8 February 2022 (UTC)
    • Thanks for the sample, I added it above. --- Jura 10:15, 9 February 2022 (UTC)
  •   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)
    • Thanks for the additional sample. Also, I completed the terminology at Q108102235 accordingly. --- Jura 15:07, 15 February 2022 (UTC)
  •   SupportMasterRus21thCentury (talk) 12:54, 1 March 2022 (UTC)
  •   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)
    This isn't meant to be a unique identifier (contrary your non-official Etalab one), so it has string datatype, similar to street number (P670). Maybe you have an alternative proposal for samples 1 and 2 (both from France). --- Jura 18:56, 6 March 2022 (UTC)
    @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)
    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)
    @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)
    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.
    I don't think this needs to have the precision of an identifier. If something like Finnish real property ID (P10364) is available, use that. --- Jura 21:00, 6 March 2022 (UTC)
  •   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)
  •   Comment I feel that we are lackin something to made a useful cadastral refrence. Like for Magrath Mansion (Q38528516) The lot description is Lot 1, Block 9, Plan 1621197 under the PBL cadastral system of Alberta, or for St. John's the Baptist Ukrainian Orthodox Church of Egremont (Q44665716) the description if a part of Section 1, Township 59, Range 22, West of the Fourth Meridian. At other place like Qubvec. this could be far more simplier, like for Maison Jean-Joseph-Girouard (Q26458540) the lot description is Cadastre of Quebec (Q60852524) : Lot 1 555 658. How should we this different cadastres? --Fralambert (talk) 23:01, 6 March 2022 (UTC)
    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)

Median household incomeEdit

   Under discussion
DescriptionMedian of the household income (cumulated salaries etc.) of a specific place, such as city, state, country.
Representshousehold income (Q1591167)
Data typeQuantity
Domainitem
Allowed values>$0
Allowed unitscurrency units (usually US-Dollars or local currency)
Example 1United States of America (Q30) → $64,994
Example 2California (Q99) → $78,672
Example 3Detroit (Q12439) → $32,498
Robot and gadget jobsI will add the data for the median household income for all cities, counties and states in the USA if item is created, using QuickStatements.
See alsomedian income (P3529) (see description below)

MotivationEdit

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)

DiscussionEdit

  •   Comment It sounds like it would be much better to fix up median income (P3529) - and individual vs household values could be distinguished with a qualifier such as applies to part (P518) household (Q259059). ArthurPSmith (talk) 14:59, 28 April 2022 (UTC)
    @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)
    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)
    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)
    @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)

Number of housing unitsEdit

   Ready Create
DescriptionNumber of housing units (dwellings) in a specific place (such as city, county, state, country etc.)
Representsapartment (Q188507)
Data typeQuantity
Domainitem
Allowed values>0
Allowed unitsnumber without unit
Example 1United States of America (Q30) → 140,498,736
Example 2Kings County (Q11980692) → 1,077,654
Example 3Florida (Q812) → 9,865,350
Sourceavailable for different countries, usually derived from a census, example for USA: [8]
See also
  • number of houses (P4080) is quite similar, but refers to actual houses. One house can contain more than one housing/dwelling.
  • number of households (P1538) is also similar, but there is not one household per housing. There is some wrong data with this property (also caused by myself) that I would like to clean up based on this proposed property (see also motivation text below).

MotivationEdit

In the available data about the United States, in previous census there was a mix between number of housings and number of households. With this new created property, I would like to clean up the wrong data and have the target that we have data about the number of houses, number of dwellings and number of households for each place in the United States (as far as covered by the official census). There will be new reliable data every 10 years, so no data spam, the data is quite static. Yellowcard (talk) 14:38, 27 April 2022 (UTC)

DiscussionEdit

  Strong support This is a siutable property to characterize a populated place in relation to its social structure (inhabitants <-> number of housings). Stefan (talk) 22:26, 27 April 2022 (UTC)

  •   Comment "housings" is the wrong word for this, as a noun "housing" mainly refers to the enclosure for a piece of equipment, not a dwelling place. "Number of dwelling places" might be the right term, if that matches what you are trying to describe here. ArthurPSmith (talk) 15:01, 28 April 2022 (UTC) "Number of housing units" would also work. ArthurPSmith (talk) 15:02, 28 April 2022 (UTC)
    I have checked this, and indeed the United States Census Bureau used "number of housings" in the 2010 publications and has changed the term towards "number of housing units". "Dwellings" does not seem to be used by the USCB, for whatever reason. We can of course find a better term, and as I am not a native speaker, I will let this decision up to you. I would be totally fine with "number of dwellings" or "number of housing units". Regards, Yellowcard (talk) 06:27, 29 April 2022 (UTC)
    I changed this proposal to "number of housing units" for now, but we can use "number of dwelling places" or anything similar as well. Yellowcard (talk) 06:30, 29 April 2022 (UTC)
      Strong support On account of arguments made. --G-41614 (talk) 13:27, 3 May 2022 (UTC)

  Support as Yellowcard has explained the differences and rationale to me. Makes sense to me, as does their plan for making everything work correctly. Huntster (t @ c) 08:40, 5 May 2022 (UTC)

NeighborhoodEdit

Outer spaceEdit

Please visit Wikidata:WikiProject Space for more information. To notify participants use {{Ping project|Space}}

OtherEdit