Wikidata:Property proposal/Place

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

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.

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 steps when creating properties.

  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 2021/03.

Geographic locationEdit

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


   Under discussion
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 2Crimean Peninsula (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

   Under discussion
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

   Under discussion
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


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)

next level in hierarchyEdit

   Ready Create
Descriptionqualifier: indicates the value at the next hierarchy level which is true for this item, when more than one is possible at the next level
Data typeItem
Domainqualifier only in transitive property (Q18647515) with hierarchy (Q188619)
Example 1111
Example 2
Example 3
Planned usefor select only right values in cases like AB → (C and D) where C is right for A but D isn't
See alsoterritory overlaps (P3179)


The question arose here. On the example of geographic hierarchical properties like located in the administrative territorial entity (P131), there are cases when at one level of the hierarchy there are two correct values but only one of them are correct for referencing item from lower hierarchy level. The proposed property will help to make the right choice in the case of such switches. We could do the opposite and indicate for each of the values a list of items corresponding to it from the lower level but in case of Atlanta (Q23556) it will be thousands of streets, non-profit organizations, monuments, schools, cafes etc. So best way to resolve it at the items of monuments or cafes.

I am sure that this can be useful not only for territorial properties like part of (P361). Сидик из ПТУ (talk) 12:40, 28 January 2020 (UTC)3333333333


  •   Support Since geographic relationships are not always one-to-one (given the examples above), located in the administrative territorial entity (P131) needs to be able to be qualified with a specific "parent" administrative territory. For example, after a natural disaster, I need to be able to search for all museums in a specific county. Without having a qualifier like "hierarchy switch", many museums will show up as being in the wrong county. And as Сидик из ПТУ points out, this qualification may also apply to other hierarchical/transitive properties. -- Clifflandis (talk) 14:02, 5 February 2020 (UTC)
  •   Support. --Mitte27 (talk) 06:41, 14 February 2020 (UTC)
  •   Support certainly make sense Ghuron (talk) 06:16, 15 February 2020 (UTC)

Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) Lechatpito (talk) Andrawaag (talk) 14:42, 13 April 2016 (UTC) ChristianKl (talk) 16:22, 6 July 2016 (UTC) Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) Iwan.Aucamp SilentSpike (talk) Tfrancart (talk) Sylvain Leroux TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC) --Tinker Bell 16:48, 23 March 2020 (UTC) SM5POR Mkbergman (talk) 19:17, 10 July 2020 (UTC) Toni 001 (talk) 11:03, 11 July 2020 (UTC) The-erinaceous-one (talk) 22:02, 31 August 2020 (UTC) Cdo256 (talk) 06:26, 8 September 2020 (UTC) Antoine2711 (talk) 17:22, 25 September 2020 (UTC) Rehman 07:15, 12 October 2020 (UTC) Susanna Giaccai (talk) 07:22, 22 October 2020 (UTC) Nomen ad hoc So9q (talk) 10:17, 4 January 2021 (UTC) Simon Cobb (User:Sic19 ; talk page) 18:29, 8 January 2021 (UTC)   Notified participants of WikiProject Ontology

  •   Oppose given the discussion on Wikidata:Project chat and the alternatives explained there. Essentially this qualifier would encourage users to add incorrect statements to the "parent" item. --- Jura 09:39, 15 February 2020 (UTC)
  •   Support This will allow to model the situation en e.g. Georgia, USA as viewed as almost everyone else does it. See also my summary of the discussion in Project chat in Special:Diff/1116318285. --Dipsacus fullonum (talk) 06:58, 16 February 2020 (UTC)
  •   Oppose This propoal assumes that administrative divisions are always organised as a linear hierarchy. Many countries however know branching hierarchies where two or more administrative divisions are subordinated to the same division. In such cases, one can add multiple located in the administrative territorial entity (P131) claims because there are multiple most local admin territories. --Pasleim (talk) 12:30, 16 February 2020 (UTC)
    • So, there will be several (two) administrative divisions for Atlanta (Fulton and DeKalb). Georgia will still not be the most local for Atlanta, nor will Fulton for Patch Works Art & History Center (Q76461608). Сидик из ПТУ (talk) 13:43, 16 February 2020 (UTC)
      • You might want to re-read the discussion on project. BTW territory overlaps (P3179) was made for that. --- Jura 13:51, 17 February 2020 (UTC)
        • As I read Wikidata:Property proposal/territory overlapse that isn't true. P3179 was made to: (quote) representing overlapse between territorial entities arising from distinct classifications. Administrative vs religious is one (as with administrative subdivisions of countries vs dioceses), administrative vs political (as is the case with american special districts), geographical vs administrative (landforms vs countries or cities). (end quote) I note the emphasis on different classification types. In the case Georgia, USA municipality and country belongs to different levels of the same type of classification. The municipalities is considered to be in one or more counties, where the counties isn't considered to be in municipalities. In such cases this proposed hierarchy switch will be best to describe the situation. In other cases like the examples in P:P3179 that property is better. So we need both. --Dipsacus fullonum (talk) 15:52, 17 February 2020 (UTC)
    • This makes sense, if you relax the requirement/assumption that only the "most local" value should go in P131. But it may be tempting for people to delete the "redundant" P131 value if they don't realise why it's there. Ghouston (talk) 08:38, 17 February 2020 (UTC)
  •   Oppose Jura points out above that this qualifier will encourage people to add incorrect assertions. I would go further and say that it is only useful in the case when people have added incorrect assertions. While Atlanta certainly overlaps two counties, it is false to say that it lies either "physically within" or "under the administrative control of" either of them. If we want to be able to identify the containing county of some specific landmark within Atlanta, we can simply assert it directly (without requiring a qualifier), or find some intermediate region such as a neighbourhood. Bovlb (talk) 21:54, 18 February 2020 (UTC)
Not that P30 matters, but the English label for P30 has just "continent", not "located in continent". --- Jura 11:20, 19 February 2020 (UTC)
The burden of proof (Q1535975) on those who deny the hierarchy (municipality of Georgia (Q76514543)county of Georgia (Q13410428)Georgia (Q1428)). Atlanta seat of Fulton county (but also partly in DeKalb county, how can we say that Atlanta on the same level with counties after this? Are you going to claim that articles County (United States) (Most counties have subdivisions which may include townships, municipalities and unincorporated areasSome municipalities are in multiple counties) and Local government in the United States (Most states and territories have at least two tiers of local government: counties and municipalities) are wrong? Сидик из ПТУ (talk) 12:35, 19 February 2020 (UTC)
Oh, you know — there are many labels and aliases of P131 in many languages have not in but true. And counties perfectly match with Wikidata usage instructions (P2559) of located in the administrative territorial entity (P131) in Atlanta case. Сидик из ПТУ (talk) 12:35, 19 February 2020 (UTC)
I suppose we will keep disagreeing on that. --- Jura 17:31, 19 February 2020 (UTC)
WikiData is not a separate project, the data from it is used in different language sections of Wikipedia, so you should evaluate your proposal to see if the templates created in the language sections will break. Maybe for you this is another abstract question, for me everything looks different. It seems to me that you "disagree" without a proper level of argumentation at a practical level. Carn (talk) 14:19, 20 February 2020 (UTC)
The question is you aren't doing the opposite as you are intending: by adding a complex additional element, you just to make sure that it works for a single outside projects that may not have implemented things correctly. --- Jura 20:19, 3 March 2020 (UTC)
The approach in which some cities of Georgia have in P131 county while others have a state should be attributed to incorrect ones in the first place.
  Support --AleUst (talk) 14:55, 19 February 2020 (UTC)
  Support, administrative territories are quite well represented as an ascending hierarchy, and this correction would make it work even better. Wikisaurus (talk) 16:33, 19 February 2020 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The good point of this debate is the highlights a problem: While I'm sympathetic to the problems faced by ruwiki infobox designers, it mainly illustrates that Wikidata should try to provide a basic infobox and breadcrum navigation as otherwise we keep getting requests from wikis that make use of our data in a somewhat sub-optimal way and attempt to tweak the data to their usecase. We already did that in other fields and should to it for that too. --- Jura 13:37, 21 February 2020 (UTC)

At first, Wikivoyage doesn't use Wikidata for breadcrumb navigation. Secondly, I see Example: Europe > Russia > Southern Russia > North Caucasus > Dagestan where Europe, Southern Russia and North Caucasus are not administrative territorial entity (Q56061) at all. And Russia is not only in Europe too so Europe > Russia > Siberia > Krasnoyarsk Krai > Krasnoyarsk (region) > Krasnoyarsk is simply wrong. Сидик из ПТУ (talk) 13:48, 21 February 2020 (UTC)
I think we understood that earlier in the discussion (please re-read the comment above by DerFussi if you haven't done so), but it's a feature that should be supported directly through Wikidata statements. I think it's useful even for projects/users other than Wikivoyage. --- Jura 13:52, 21 February 2020 (UTC)
OK. In this case, if we somehow build a hierarchy through Russia then we definitely need a switch in order to choose Asia for Krasnoyarsk and Europe for St. Petersburg. Сидик из ПТУ (talk) 13:56, 21 February 2020 (UTC)
  •   Support The best way now. - Kareyac (talk) 11:16, 21 February 2020 (UTC)
  • @Сидик из ПТУ, Clifflandis, Mitte27, Ghuron, Carn, Pasleim: @Bovlb, Kareyac, Jura1, Dipsacus fullonum: @DerFussi, RolandUnger, Ghouston: I have altered the English proposed name per a discussion above; please comment below if that changes your view on this proposal. ArthurPSmith (talk) 18:42, 21 February 2020 (UTC)
    • It was one or more of several values and I suggest leaving this wording just in case. For example, when two of the three values are true. Сидик из ПТУ (talk) 19:17, 21 February 2020 (UTC)
    • My objection was structural, and about the misuse of P131, so I'm afraid your fix doesn't help me. Thanks for trying. Cheers, Bovlb (talk) 16:34, 25 February 2020 (UTC)
  •   Comment I have another suggestion, which would be to use another P131 statement as a qualifier on the P131 statement, instead of defining a new property. Maybe it would be easier to use that trying to remember the name of the obscure property that changes the hierarchy, and it would still be distinguishable from a redundant P131. Ghouston (talk) 22:21, 21 February 2020 (UTC)
    • Yes, I also proposed to do so from the very beginning, however, this requires special documentation so that users understand in which cases such a qualifier is needed and in which it is unwanted. I believe that a special property allows users to better understand what function it performs. Сидик из ПТУ (talk) 08:58, 22 February 2020 (UTC)
  •   Comment how to we determine what the next level of the hierarchy is? Wouldn't it rather be "alternate hierarchy"? --- Jura 09:30, 22 February 2020 (UTC)
    • It must be one or more of the values that are specified in a similar property at the item to which we add the qualifier. Сидик из ПТУ (talk) 10:39, 22 February 2020 (UTC)
      • Yeah, so "alternate hierarchy" fits it better. --- Jura 10:41, 22 February 2020 (UTC)
        • Maybe I do not understand the subtleties of the wording in English but, otherwise, there are no differences from a typical case, county of Georgia (Q13410428) are always the next level of hierarchy for municipality of Georgia (Q76514543). The qualifier allows us to make a choice of several alternative values. Сидик из ПТУ (talk) 10:46, 22 February 2020 (UTC)
          • From the discussion, I get the impression that you assume a pyramidal organization of different government entities and likely an infobox that can't handle alternatives. --- Jura 10:52, 22 February 2020 (UTC)
            • Yes, proposed property is for resolve this. Сидик из ПТУ (talk) 11:45, 22 February 2020 (UTC)
              • Sure, but it's better to fix the infobox than to try to change the underlying data. --- Jura 17:10, 22 February 2020 (UTC)
                • The infobox algorithm just relies on the fact that Wikidata will follow the rule "You only need to add the most local admin territory". The most local admin territories for Atlanta are Fulton and DeKalb and this is in line with the main point of view of most serious sources. Сидик из ПТУ (talk) 17:58, 22 February 2020 (UTC)
  •   Comment If we are going to say (for example) that Atlanta is in both Fulton and DeKalb counties then, yes, we need something like this. But I think that's just bad modeling and a patch to get around it. When geographical entities overlap like this, the city is no more in the county than the county is in the city. I believe that Atlanta, Fulton County, and DeKalb County are each in Georgia; that Atlanta overlaps with Fulton County and DeKalb County; and that any given point in Atlanta is either in Atlanta and in Fulton County, or in Atlanta and in De Kalb County. The fact that a county is somehow "higher-level" than a city does not change this. Five counties of New York State each coincide with boroughs of New York City: this is the one case I know of in the U.S. where counties are proper subsets of cities. Are we really going to say that New York City is in Kings, Queens, New York, Richmond, and Bronx counties rather than vice versa? - Jmabel (talk) 16:20, 22 February 2020 (UTC)
Сидик из ПТУ and I were just discussing New York City over at Property talk:P131#Possible change of usage. Although the two situations aren't legally analogous, I believe they might be ontologically similar enough that a solution that applies to one ought to apply to the other. —Scs (talk) 16:56, 22 February 2020 (UTC)
Yes, we read articles about borough of New York City (Q408804) yesterday[3][4][5], it emphasizes that they are unique to the United States and are parts of the NYC now. Сидик из ПТУ (talk) 17:58, 22 February 2020 (UTC)
@Jmabel:, how would you write the location linearly, e.g., in the infobox for c:Category:Baltimore Block on Commons? The question is whether to put the city or county first, or come up with some other way of writing it. Ghouston (talk) 22:35, 22 February 2020 (UTC)
@Ghouston: By tradition, in the U.S. (with the exception of New York City) we list city before county regardless of containment, but that's a matter of tradition, not data modeling. I think it might make sense to have a query know that as a rule for U.S. places (should be possible to enforce based on "instance of"), rather than to have to say in doesn't really mean in.
By the way, New York is a mess in this respect. Pretty much any New Yorker would say that Morningside Heights is in Manhattan, not that it is in New York County, or that Park Slope is in Brooklyn, not that it is in Kings County. As for Richmond County / Borough of Richmond: almost everyone calls it "Staten Island"; after more than 300 years, the effort to give it an English rather than a Dutch name never really stuck. - Jmabel (talk) 23:44, 22 February 2020 (UTC)
If the query “all cities of the county Fulton” doesn’t return Atlanta then this is a bad base and it doesn’t matter how the data modeling was. If Britannica says in then we follow this as most users who expect that for all the cities of Georgia, a generally accepted order is kept in line with the real situation. As for the local names of the places in New York, I can say the same thing about Moscow, where the districts got their names from the villages, and then these villages ended up in other districts. But it all suggests that New York boroughs are seen as part of the city as a priority and they are named on the English Wikipedia as Manhattan, Brooklyn, Queens, The Bronx and Staten Island. There are not separate articles about Kings or Richmond. Everything is clear here. Сидик из ПТУ (talk) 07:14, 23 February 2020 (UTC)
There's a broader question here, which is: who or what is (or are) the primary user(s) of Wikidata? If it's people browsing our database, as if it were a stylized and highly-structured Wikipedia, then it makes sense to worry about what Britannica says, or what a reasonable New Yorker would say, and to try to have the presented data match that somehow. But if our data is primarily being used by computers running SPARQL queries, or by Wikipedia as it renders infoboxes, then we should favor a data model that fosters clean, consistent, general-purpose SPARQL queries and Lua templates and the like. —Scs (talk) 12:20, 23 February 2020 (UTC)
Dozens of Wikipedia language sections and a number of other Wikimedia projects need a supported hierarchy for a property. Q18008533 is a Lua module and it is popular, this switch will be useful to it, but, of course, it is required to return the correct sequences like Atlanta→Fulton→Georgia. Сидик из ПТУ (talk) 08:50, 24 February 2020 (UTC)
  • I think the point is that you can't write a single SPARQL query; in the general case you have to write a little program, with some loops and if statements, that issues a number of SPARQL queries and makes decisions based on any next level in hierarchy qualifiers it finds. (To be perfectly clear, suppose the question is not, "Show me everything in DeKalb County (Q486398)", but rather, "Show me everything in County X".)
This isn't necessarily a fatal flaw, but it does need to be acknowledged.
Overlaps are obviously a mess. I suspect we can have either a data model that's closer to the "real world" but requires more-complicated algorithms to query, or a "refactored" model that's easy to query because it interposes some extra, artificial, constructed entities (like "portion of Atlanta within DeKalb county"), but not both. —Scs (talk) 12:08, 23 February 2020 (UTC)
Using of "portion of Atlanta within DeKalb county" will make it difficult to work with queries such as "select all Atlanta bus stops". In any case, it’s better to work with real data than to add unobvious database tricks to the imperfection of the world. Alternatives to switch are similar to Procrustean bed (Q10991776). Сидик из ПТУ (talk) 08:50, 24 February 2020 (UTC)
@Сидик из ПТУ: How does an interposed subentity of Atlanta make it harder to find all Atlanta bus stops? —Scs (talk) 13:06, 24 February 2020 (UTC)
At least we need to order unobvious where in Atlanta-DeKalb or Atlanta-Fulton. And queries may be to select all bus stops in the capitals of each state or to select all Gerogia bus stops with their cities or select count of bus stops by city, etc. And what P131 is correct for it? If counties then we lose Atlanta in our hierarchy and can’t easily select this city along with other state capitals. If Atlanta then we lose any effect of this. A completely different conversation that such administrative territorial entity (Q56061) do not actually exist so this may lead to misinformation of the users. Сидик из ПТУ (talk) 13:25, 24 February 2020 (UTC)
This proposed qualifier is another such trick. I think we'd just stick to the initially suggested solution (add both Atlanta and DeKalb county statements to the bus stop item, but the most local entities) queries remain simple. --- Jura 10:26, 24 February 2020 (UTC)
This will make it impossible to build a hierarchy without a strong knowledge base wired into the algorithm and this will be a false statement that destroys the general logic. By the way, the property can be used without minus and queries like "select all bus stops in county" may contain the requirement to display the most local units for this stops (expected only cities). Maybe somebody can add to my query all organisations where next level of P131 contains only one county. Сидик из ПТУ (talk) 10:57, 24 February 2020 (UTC)
Actually, using this qualifier assumes that the qualifier is used in a given level of the hierarchy, thus requiring users to write a program to identify it as Scs mentions. --- Jura 11:02, 24 February 2020 (UTC)
Using P131 assumes that the most local admin territory for the bus stops of Atlanta is Atlanta, not counties. Сидик из ПТУ (talk) 11:08, 24 February 2020 (UTC)
You mean, you assume that. --- Jura 11:08, 24 February 2020 (UTC)
The reverse situation will complicate both the algorithms on Lua and the operation of SPARQL-queries when they need to work with the hierarchy. Сидик из ПТУ (talk) 11:27, 24 February 2020 (UTC)
I guess it's debatable if "wdt:P131*" is more complicated than the program combined with the qualifier query you linked in some diff, but personally, I find more simpler. --- Jura 11:30, 24 February 2020 (UTC)
Without following the rule of "most local admin territory" cheap hierarchy building will not be possible, however this feature is used in various Wikimedia projects very widely, it's much more relevant than the one-off SPARQL-queries for Georgia like was discussed here. The loss of hierarchy will entail the loss of many other opportunities while the qualifier, on the contrary, creates them. Сидик из ПТУ (talk) 11:45, 24 February 2020 (UTC)
Here we identified that there are actually two "most local admin territories" to be considered (unless "part of Atlanta in DeKalb county" is created) and infoboxes can handle this. It is known that the ruwiki one doesn't do that and apparently ruwiki lacks the resources to keep it in shape .. so we keep getting these requests here. --- Jura 11:52, 24 February 2020 (UTC)
There are two "most local admin territories" for Atlanta (Fulton & DeKalb), it matches to sources. There is one "most local admin territory" for Patch Works Art & History Center (Q76461608) (Atlanta). The machine cannot be taught to choose the "most local admin territory" from two or more values without detailed knowledge base. No one will learn the algorithm to select from the list first the city, then the county and finally the state since several thousand such tasks have accumulated over the history of mankind. We suggest improving the functionality, you suggest destroying it. Сидик из ПТУ (talk) 12:11, 24 February 2020 (UTC)
And the creation of artificial concepts that do not exist in the real world, such as "part of Atlanta in DeKalb county" will make work with Atlanta more difficult. It's not valid administrative territorial entity (Q56061), work with similar items in contrast to the documented property will be less handy and, again, will require a solid knowledge base. Сидик из ПТУ (talk) 12:18, 24 February 2020 (UTC)
  • I don't think people are willing to dismiss transitivity so easily -- it's arguable that we do need it and should strive to preserve it. And North Yorkshire (Q23086) is no counterexample -- if anything it's proof that (a) real-world political subdivisions are confusing, irregular, and difficult, and (b) people have been representing them improperly in Wikidata for a while, meaning we really need some cleanup and a proper fix (whatever that may be). In particular, North Yorkshire is a ceremonial county of England (Q180673) and, therefore, not strictly an administrative subdivision. [See Wikipedia Subdivisions of England: "For non-administrative purposes, England is wholly divided into 48 counties, commonly known [...] as ceremonial counties".] But you probably can't use North Yorkshire (Q23086) as part of your primary P131 hierarchy -- it's guaranteed to fail. (Just look at the comment -- right in Q23086's description! -- directing you over to North Yorkshire (Q21241814), which actually is an administrative subdivision, and which does not encompass e.g. Redcar and Cleveland (Q1434448), meaning it'd be much easier to use Q21241814 as part of a proper, nonoverlapping hierarchy.)
Can you say a little more about what you mean when you say "not allowing hierarchies to be done"? The argument for enforcing pure transitivity on P131 is that it makes P131 act like the mathematical operator subset (Q177646), meaning that simple wdt:P131* queries always yield proper results. In this sense saying that Patch Works is in Fulton County, or that Atlanta is in Georgia, is perfectly fine. I think your objection to these relations is that you can't list all cities in Fulton County by doing a simple wdt:P131 wd:Q486633 query, or something, but I'm really not sure.
Have we asked the folks over at WikiProject Country subdivision for their advice on all this? I bet they've put some thought into how best to resolve these situations. [Footnote: I've now asked them.]—Scs (talk) 13:01, 1 March 2020 (UTC)
Firstly, neither I nor Russian Wikipedia in general came up with the use of ceremonial county of England (Q180673) at located in the administrative territorial entity (P131). As I understand it, the British themselves began to fill out the data in this way. I am not opposed to clarifying this issue, although the ceremonial counties have changed the form of government over time and I fully admit that at the moment the phrase "Most ceremonial counties are, therefore, entities comprising local authority areas, as they were from 1889 to 1974" is correct. We can argue about the powers of the Queen of the United Kingdom, Governor General of Canada (Q390776) or Lord Lieutenant (Q914752) but if the existing hierarchies are in most cases useful then I do not see an error in such an interpretation where ceremonial county of England (Q180673) in located in the administrative territorial entity (P131).
Secondly, I think that following the main sources we should consider Atlanta a city in Fulton County (and also in DeKalb County) and make the appropriate statements. I consider it will be a bad decision to be guided in the first place by the rule "is completely in" and state Georgia for Atlanta at P131 with counties for other cities. It will simply be a false statement that the municipality of Atlanta is on the same hierarchy level as the counties. Сидик из ПТУ (talk) 10:38, 2 March 2020 (UTC)
Ah, okay, now I get it: You want P131 to mean "is an administrative subdivision of". That makes sense.
Or, stated another way, P131 represents a direct child relationship, and the proposed new property simply represents a grandchild relationship, for use in cases where we can't properly describe the situation with two ordinary child relationships. (Indeed, we've got some similarly redundant tags for people. Normally we represent human grandchildren as a pair of child (P40) properties, and siblings as two people having the same parent(s), but if we don't have an entity for the parent, we can use kinship to subject (P1039) along with grandchild (Q3603531), sibling (Q31184), etc.) —Scs (talk) 16:36, 2 March 2020 (UTC)
P.S. When I said "you probably can't use Q23086 as part of your primary P131 hierarchy", I was not referring to you or the Russian Wikipedia; I meant "anybody". But the fact that "the British themselves began to fill out the data in this way" doesn't prove much, either -- as JMabel mentioned in another thread, we shouldn't automatically let popular folksonomies drive our more-precise taxonomic work here. 19:18, 2 March 2020 (UTC)
And looking at the real situation, it seems that the warning in the description does not forbid the use of North Yorkshire (Q23086) in the P131 but something like different from (P1889). Сидик из ПТУ (talk) 15:16, 2 March 2020 (UTC)
  •   Comment Scs wrote: (quote) I think the point is that you can't write a single SPARQL query; in the general case you have to write a little program, with some loops and if statements, that issues a number of SPARQL queries and makes decisions based on any next level in hierarchy qualifiers it finds. (To be perfectly clear, suppose the question is not, "Show me everything in DeKalb County (Q486398)", but rather, "Show me everything in County X".) (end quote)
That is not true. Here is single SPARQL query using the proposed query for a search for items in an arbitrary administrative unit:
# SPARQL code to find items in an arbitrary administrative unit, called Q800000000,
# using the proposed qualifier, called P8000
SELECT ?item
  VALUES ?searched_unit { wd:Q800000000 }
    ?item wdt:P131* ?searched_unit .                 # located in the searched unit 
    ?item wdt:P131*/p:P131/pq:P8000 ?other_unit .    # unless next level in hierarchy is a unit
    ?other_unit wdt:P131/^wdt:P131 ?searched_unit .  # at same level in the hierarchy
    FILTER (?other_unit != ?searched_unit)           # and different from the sought unit
Try it! --Dipsacus fullonum (talk) 15:47, 26 February 2020 (UTC)
Thank you. I apologize for my naïveté about the potential power of complex SPARQL queries. —Scs (talk) 11:32, 27 February 2020 (UTC)
  • It's essentially two queries which works here because there are not too many items involved and P8000 doesn't exist. For testing, Sandbox-Item (P369) can be used.
I'm curious to see the version for "all bus stops in Georgia by county". According to an addition on Property talk:P131 this would work for that as well. --- Jura 09:52, 29 February 2020 (UTC)
@Jura1: Here is a version for all bus stops in Georgia by county as requested:
# Find all busstops in Georgia by county
SELECT DISTINCT ?busstop ?county
  ?busstop wdt:P31 wd:Q953806 .       # is busstop
  ?busstop wdt:P131+ ?any_county .    # located in county
  ?any_county wdt:P31 wd:Q13410428 .  # which is a county of Georgia, USA
    ?busstop wdt:P131*/p:P131/pq:P8000 ?switched_county . # the true county if present
    ?switched_county wdt:P31 wd:Q13410428 .               # if it is a county of Georgia, USA
  BIND(COALESCE(?switched_county, ?any_county) AS ?county)
Try it! --Dipsacus fullonum (talk) 12:17, 29 February 2020 (UTC)
  • Does it assume that the qualifier would be placed on a known layer and the layer is always in the same place of the matrix?
Would this work if the county was a French department and the French municipality had a switch to the relevant department?--- Jura 09:56, 1 March 2020 (UTC)
Answer to first question: No. Answer to second question: As I understand English Wikipedia a French municipality (commune) is in only one department. But even if that isn't the case, then the next levels in the French administrative hierarchy are cantons and arrondissements, so a commune should never have the proposed qualifier with a value of a department. Please read the description the proposal ("the value at the next hierarchy level"). But anyway, even with a double incorrect use of the qualifier, the query could be changed to give busstops in France by department, and work. --Dipsacus fullonum (talk) 12:09, 1 March 2020 (UTC)
I don't think the problem at Wikidata_talk:WikiProject_France/Communes#Communes_multi-départementales is solved. --- Jura 13:02, 1 March 2020 (UTC)
I don't understand French, but as I understand the point using machine translation of the discussion, the French communes is always in exactly one department, but which department have changed over time. If that is correct, then this proposed qualifer will not be usable for french communes. Instead the values for P131 somewhere in the property chain should use time qualifers as start time (P580) and end time (P582). If you want help with queries with time qualifiers, please ask in Wikidata:Request a query. --Dipsacus fullonum (talk) 14:17, 1 March 2020 (UTC)
If I recall correctly, there were several problems: one is that they changed over time (not important here), another that that some users include intermediate administrative layers that strech across several departments. It's a similar problem as the Atlanta one, at least if Atlanta had boroughs. --- Jura 20:19, 3 March 2020 (UTC)
Until 2015, France had two parallel hierarchies of administrative-territorial units. One of them consisted only of cantons, and the other was and remains perfectly transitive. To build a second hierarchy according to it, it is enough to simply indicate arrondissement of France (Q194203). Сидик из ПТУ (talk) 10:42, 4 March 2020 (UTC)
I think you could make an argument to add it as a qualifier to those properties, sure. If you wanted to query all of the people born in DeKalb County (Q486398), you could get results of people who were born in Atlanta (Q23556) with a qualifier of next level in hierarchy of DeKalb County (like someone born at Emory University Hospital (Q5373728), which is in Atlanta and DeKalb County). I could also see it being useful for historical cases, where someone was born in a city when it had a different administrative territorial entity in the next level in the hierarchy. The statement would be true, and it would also make querying easier. Clifflandis (talk) 15:06, 27 February 2021 (UTC)
The question is about entries like the place of birth of George Washington: Q23#P19 which is currently given as Westmoreland County (Q494413) and qualified with "Great Britain" and "Colony of Virginia". It's not something I advise on doing, but it seems to be a usecase for this qualifier as well. Apparently, these kind of qualifiers are added by ruwiki users to ensure their infobox can easily find the items. At some point there was a bot adding them, but it was blocked as it was considered not suitable approach. Users still keep adding them manually though. --- Jura 08:14, 28 February 2021 (UTC)
I don't think this proposed hierarchy switch qualifier should be used in cases like Q23#P19. The qualifiers there isn't really necessary since the correct administrative units and country can be found from Westmoreland County (Q494413) together with the time of birth. But if qualifiers are used at Q23#P19 anyway the hierarchy switch would make no sense. In such cases you would need to use located in the administrative territorial entity (P131) as the qualifier. By instead using the hierarchy switch qualifier there would be no indication that the value is an administrative unit and it wouldn't be clear what the qualifier was about. --Dipsacus fullonum (talk) 12:14, 28 February 2021 (UTC)
Is there anything in the proposal that excludes its use? Why not also use P131 as qualifier in the samples of the proposal above? --- Jura 15:15, 28 February 2021 (UTC)
Yes, undefined meaning excludes it use that way. Is there anything in the proposal that justifies its use as qualifier to place of birth (P19)? No! How should a hierarchy switch qualifier to George Washington (Q23) place of birth (P19) Westmoreland County (Q494413) be interpreted? There would no indication about what kind of hierarchy it is refering to. --Dipsacus fullonum (talk) 15:30, 28 February 2021 (UTC)
Actually, "transitive property" excludes it. So location (P276) or located on terrain feature (P706) would be ok, but not P19 [6]. --- Jura 15:44, 28 February 2021 (UTC)
@Jura1: do you think there's enough of a use case to support this qualifier for P131, or do you think it's still inappropriate? I'm curious if the conversation over the last year has shifted your opinion any, or if your concerns still stand. Thanks! Clifflandis (talk) 15:30, 2 March 2021 (UTC)
Russian Wikipedia community opposes the located in the administrative territorial entity (P131) and country (P17) to be added as qualifiers to place of birth (P19) and place of death (P20). The historically correct hierarchy chain for our infoboxes is calculated taking into account the dates of birth and death. So we do not need any qualifiers for Q23#P19. Proposed property needed only for cases like with Atlanta with two next levels in hierarchy at the same time, not for historical cases. Сидик из ПТУ (talk) 09:45, 4 March 2021 (UTC)


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


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)


  •   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)


   Under discussion
Descriptionpreposition commonly used in this language to this place
Data typeMonolingual text
Domainhuman settlement (Q486972)
Allowed valuesen/à/au/aux/in/in the/[other preposition existing in languages]
Example 1Arles (Q48292) → en [fr]
Example 2Cuba (Q241) → à [fr]
Example 3Portugal (Q45) → au [fr]
Example 4Marquesas Islands (Q172697) → aux [fr]
Example 5United States of America (Q30) → in the [en]
Expected completenessalways incomplete (Q21873886)


In itself, few interest, but this property would greatly help build and write automated French sentences/descriptions for Qid like "église en Arles" / "aéroport aux États-Unis" / "cathédrale au Wisconsin", etc Bouzinac (talk) 21:32, 14 May 2020 (UTC)


Benoît Prieur
Ash Crow
Thierry Caro
Nomen ad hoc
Marianne Casamance
Nattes à chat
Pierre André
Mathieu Kappler
  Notified participants of WikiProject France

  •   Oppose This may be better placed on lexemes (senses of lexemes?) for those place names. Mahir256 (talk) 04:44, 15 May 2020 (UTC)
    Can you mix lexemes and Qid inside a sparql ? How to show in a sparql both and People's Republic of China (Q148) ? Beyond countries, has all cities/departement a lexeme ? Bouzinac (talk) 05:53, 15 May 2020 (UTC)
    @Bouzinac: This SPARQL query gets all countries with their French lexemes in Wikidata so far. It would be great to add more lexemes of course! ArthurPSmith (talk) 18:10, 15 May 2020 (UTC)
    Hi ArthurPSmith (talkcontribslogs), thanks, looks promising. How would you add P5185 to this list ? If okay, then i'll switch this proposal to lexemes. Well, there would be different french prépositions : du/de la/des/d' <> en/à/au/aux ... ==> Ambassade de l'Argentine en France Bouzinac . I somehow need to store these rules to help automate french descriptions [1](talk) 19:20, 15 May 2020 (UTC)
  • Many Thanks! Bouzinac (talk) 19:20, 15 May 2020 (UTC)
  •   Comment Can be relevant for other languages than French (a rare example for Czech - "v Česku"/"na Slovensku"). Which would probably help Abstract Wikipedia generate content. --Matěj Suchánek (talk) 11:45, 4 September 2020 (UTC)
  •   Comment @Bouzinac, Mahir256, Matěj Suchánek: we could call it "preposition for locative" (Q202142) and use for which the usage rules have been defined on property talk. Initially this may just be French, Czech. Even in English, it could be convenient to store "in the" ←→ "in" somewhere. --- Jura 03:50, 5 September 2020 (UTC)
    Do you think monolingual text is appropriate? Shouldn't it be wikibase-form? --Matěj Suchánek (talk) 09:34, 5 September 2020 (UTC)
    • I hadn't commented on that aspect, as I'm not really convinced by either approach. Obviously, somehow anything should also be available on L-entities, but for French, it would mean that many place names would need to be created as lexemes merely to store this (which isn't a problem as such).
    • In the meantime, it occured to me that we could store it directly as form, e.g. [7]. This would also simplify translations to languages like Latin or Polish where there is a distinct form for locative. --- Jura 09:47, 5 September 2020 (UTC)
      I meant that items would link to forms, instead of text (as promoted by the examples above). But obviously, I missed the point that a preposition itself might not be very useful without the form of the word (considering in other languages). --Matěj Suchánek (talk) 09:55, 5 September 2020 (UTC)
      • Good point, that would be a option #4. I experimented with generational suffix (P8017) doing that. I found adding values isn't easy (was that with QS?) --- Jura 10:03, 5 September 2020 (UTC)
So, you would have a multilingual property, say,
  •   Support every time I need to add "the" to country names, I think we should have some explicit solution for this. My order of preference is:
a. approach #3 (additional forms on the lexeme for the country name, requires no new property)
b. approach #2 (a statement on the lexeme of the country name, probably with form-datatype)
c. approach #4 (a form-datatype property on items for countries, similar to generational suffix (P8017)))
d. approach #1 (a monolingual string property on items for countries)
Preferred property label is "preposition for locative" for (b, c, d).
As we don't have multi-lingual datatype, I didn't add that, but several statements with monolingual-datatype make it multilingual.
Any solution is better than the status quo. @Bouzinac, Mahir256, Matěj Suchánek:. --- Jura 14:04, 20 September 2020 (UTC)
d. (#1) is least preferred by me as well. I'd happy if there was a disscusion with Wikidata community / lex. data sub-community about the rest. --Matěj Suchánek (talk) 11:35, 29 September 2020 (UTC)
  •   Oppose the idea is great but the proposal is badly written. It would be better on Lexemes (and yes, on Senses of Lexemes) and for all languages (no reason to limit to French). But indeed there is a need that is worth solving. PS: as always for natural languages, rules are quite complicated ; for instance, with your first example: « en Arles » is common but considered as archaic and/or regional (and dependant of the context, is it Arles as the city strico sensu or Arles more lato sensu? in the second case « en » is more common/acceptable), « à Arles » is perfectly correct. PPS: maybe this is something more suited for the future Wiki of functions. Cheers, VIGNERON (talk) 09:25, 4 November 2020 (UTC)
    Semblerait effectivement que "à Arles" soit correct[1].--Bouzinac💬✒️💛 19:57, 2 January 2021 (UTC)
  •   Oppose I support using lexemes for place names. Finnish language uses conjugations and postpositions to express locative. Conjugations to/from would also be needed, for example. – Susanna Ånäs (Susannaanas) (talk) 14:09, 2 January 2021 (UTC)

map at URLEdit

   Under discussion
Descriptiona URL that links to a map of the place, building, road, transit system, etc. described by the item
Representsmap (Q4006)
Data typeURL
Domainitem; location (Q17334923)
Allowed valueshttps?://.+
Example 1Denny Hall (Q28449746)!/den
Example 2University of Washington (Q219563)
Example 3University of Washington (Q219563)
Example 4Headquarters of the United Nations (Q11297)
Example 5Microsoft Redmond Campus (Q6331329)
Example 6Microsoft Redmond Campus (Q6331329)
Example 7Thailand (Q869)
Example 8Amazonia (Q2841453)
Example 9Olympus Mons (Q520)
Example 10Yosemite National Park (Q180402)
Example 11Yosemite Valley (Q1996389)
Example 12New York City Subway (Q7733)
Planned useWe are creating items for University of Washington buildings and will add this property to link to maps of the building on campus.
See also


There is no property to provide a link to a map depicting a location (building, university campus, corporate body, jurisdiction, geographic feature, transit system, etc.). We are creating items for buildings on the University of Washington campus and would like to link to campus maps that show the location of the building. Having a map URL property will be useful to add to many other items in Wikidata. UWashPrincipalCataloger (talk) 16:11, 13 August 2020 (UTC)


  •   Support But if this is not approved, described at URL (P973) with a suitable qualifier might work. We do have some pretty specific URL properties though (for example terms of service URL (P7014), privacy policy URL (P7101), calendar feed URL (P6818) user manual URL (P2078), etc.) so this one seems ok to me. ArthurPSmith (talk) 18:21, 20 August 2020 (UTC)
  • I modeled this proposal on the existing property streaming media URL (P963). I have been using described at URL (P973) for maps, since I couldn't find anything better, but it really seemed insufficient to me, because it is so general and one expects something more than a map when you use "described at". UWashPrincipalCataloger (talk) 18:48, 20 August 2020 (UTC)
  •   Support ChristianKl❫ 00:24, 30 December 2020 (UTC)
  •   Oppose Some of these examples seem questionable; for example, the links to random images on blogs with no license or attribution info available. Perhaps a map URL property with strict constraints could make sense (e.g. must be an official source), but as proposed, I don't think this should be approved. For the proposer's use case, I think described at URL (P973) would work just fine. --IagoQnsi (talk) 20:45, 4 January 2021 (UTC)
    • I disagree that described at URL (P973) is the best property to use for this. The subject is depicted geospatially, not described, at the URL. And there is the existing parallel property streaming media URL (P963) as precedent for this proposal. UWashPrincipalCataloger (talk) 05:58, 18 January 2021 (UTC)
      • The property streaming media URL (P963) is limited to the official link of a streaming media source. This proposal, however, seems to include maps from a variety of sources, many of which are unattributed and of unknown copyright status. I can see the value in linking to interactive maps on external sites, as we can't easily provide that ourselves; perhaps an "interactive map URL" property would make sense. But static images and PDFs should go on Wikimedia Commons, where they can be vetted for licensing status and where they can be easily reused by other Wikimedia projects. --IagoQnsi (talk) 16:50, 18 January 2021 (UTC)
  •   Support Has a court ever found that linking even to copyrighted material posted on a website constitutes copyright infringement? If that is the case, then described at URL (P973) and other properties linking to non-Wiki sites could theoretically run into the same issue. I don't believe that argument is sound. This property would be useful for linking to maps of things. I'd be okay with limiting to a few sources but I don't think it's necessary. described at URL (P973) is inappropriate for most maps because they are depictions, and usually not descriptions. Linking to something and uploading it to Commons are very different things so I don't think uploading a copy of every map someone may want to link to is a useful alternative. --Crystal Clements, University of Washington Libraries (talk)
  •   Support Pteropotamus (talk) 10:15, 1 March 2021 (UTC)
  •   Support per ArthurPSmith above. Prburley (talk) 13:45, 1 March 2021 (UTC)
  •   Comment I think we already had this, but maybe not? From the samples given, I suppose any location could be linked to any map, isn't it? I don't think this is intended, but what part of the proposal is meant to prevent it? I complete "see also" with other available solutions. --- Jura 15:13, 1 March 2021 (UTC)

Database of Umgebinde houses in Bohemian Switzerland IDEdit

   On hold
Descriptionidentifier for records in the Database of Umgebinde houses in Bohemian Switzerland
Data typeExternal identifier
DomainUpper Lusatian house (Q1362233)
Allowed values[a-z0-9_-]
Example 1Kopec 18 (Q33249924)stare-krecany-podstavkovy-dum-cp-18
Example 2Q61970865ruzova-podstavkovy-dum-cp-e48
Example 3Q31031548jetrichovice-podstavkovy-dum-cp-10-1
Number of IDs in source1508
Expected completenesseventually complete (Q21873974)
Formatter URL$1


Tobias1984 Vojtěch Dostál YjM Wesalius 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)   Notified participants of WikiProject Czech Republic @Conny, ‎RoesslerP, WikiAnika:
The largest database of Umgebinde houses in the Czech Republic, including houses in 9 municipalities. Jedudedek (talk) 20:40, 31 August 2020 (UTC)


  •   Support JAn Dudík (talk) 20:46, 31 August 2020 (UTC)
  •   Question Is the formatting URL really permanent? Are the IDs permanent? Is there some chance that the "database" will survive next 5 years? --YjM | dc 21:50, 31 August 2020 (UTC)
    Databáze byla dokončena v roce 2004, tedy před 16 lety (viz zde kapitolu Podstávkové domy Českého Švýcarska). Nevím, jak dlouho je přístupná na webu, ale určitě již několik let. Jestli si dobře pamatuju, tak jsem na ní narazil nejpozději v květnu 2014, tedy před více jak šesti lety. Jinak České Švýcarsko o.p.s. byla založena roku 2001 a myslím, že (nejen) instituce které za ní stojí, dávají slušný předpoklad dlouhého fungování. Jedudedek (talk) 23:14, 31 August 2020 (UTC)
    @Jedudedek: YjM se spíše ptá na to, zda se odkazy příliš nemění, tzn. zda se příliš často jednotlivé záznamy nepřejmenovávají Vojtěch Dostál (talk) 05:53, 1 September 2020 (UTC)
    Pravda, na tuhle část otázky jsem neodpověděl. Adresy jsou stejné co pamatuju. Podle mě je sice ten jejich systém pojmenování po obci, namísto po části obce (viz příklad č. 3, což je ve skutečnosti Vysoká Lípa 10) zvolenej trochu nešťastně. Ale že by to po těch letech předělávali si nemyslím. Jedudedek (talk) 06:30, 1 September 2020 (UTC)
  •   Support Conny (talk) 11:21, 1 September 2020 (UTC).
  •   Comment the website is currently down. Does it happen often? Pamputt (talk) 06:01, 23 September 2020 (UTC)
    I have been working with the database for more than 5 years and there has never been a problem with it. I sent them a question. I'll see what he answers me. Jedudedek (talk) 21:16, 24 September 2020 (UTC)
  •   Comment… becomes https://ops.ceskesvycarsko.czcs/cile…. de or en ? Cordially. —Eihel (talk) 18:54, 29 September 2020 (UTC)

KinoWiki IDEdit

   Ready Create
Descriptionpage on the German KinoWiki, a website about old and new cinema buildings in Germany
Data typeExternal identifier
Domainmovie theater (Q41253)
Example 1Filmbühne (Q98950086)[8]
Example 2Filmtheater (Q50843749)[9]
Example 3Mephisto (Q50843391)[10]
External linksUse in sister projects: [ar][de][en][es][fr][he][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][commons][species][wd].
Planned useconverting the 1500 extant links on Wikidata (to from described at URL (P973) to this new property, later creating new Wikidata items
Number of IDs in sourcethousands
Expected completenesseventually complete (Q21873974)
Formatter URL$1
Robot and gadget jobsconverting the 1500 extant links on Wikidata from P973 to this new property
See alsoCinema Treasures ID (P4129), Kinoliste ID (P4981), Carthalia ID (P5652)


Wikidata is strong on cinema buildings (with the CinemaTreasures property mainly for the US and a couple of other properties), and there are already 1500 links (see ) from Wikidata to the German KinoWiki. IMHO it is the number one site for information mainly about closed, demolished and obscure cinemas in Germany. Especially noteworthy is that countless historic cinema address books have been mined for address and ownership information which is given for each cinema. The KinoWiki is a private site that has changed its servers, I think, twice in its history, so it would be a great help to have a link formatter instead of having to change all those links (and maybe again...). At the moment, all those links are dead (since the old server seems to have stopped working as of today), but most can be fixed by just changing to the new URL. That said, the new site is at this very moment still unstable, spam-ridden and has had a major problem with importing pages with Umlaut in the title (naturally, quite a lot with those German names), so hundereds of pages there will need to be moved (I already did this for a few, being a a user on this Wiki, and after that our links work again). Also, the images there don't work yet. I am confident that the site owner will be able to sort out these problems soon, as he has always done in the past. This property proposal may seem a bit premature (as these bugs are not sorted out yet), but I want to prevent all those links on Wikidata to be deleted as dead links, since it was a such lot of work (mostly mine) to match our items with the KinoWiki. --Anvilaquarius (talk) 17:10, 7 September 2020 (UTC)


  •   Support and   Wait I think the links should be saved and transferred to the new domain, but lets wait until the new server is stable and up and running with images and all. --Hannes Röst (talk)

ValterVB LydiaPintscher Ermanon Cbrown1023 Discoveranjali Mushroom Queryzo Danrok Rogi Mbch331 Jura Jobu0101 Jklamo Jon Harald Søby putnik ohmyerica AmaryllisGardener FShbib Andreasmperu Li Song Tiot Harshrathod50 U+1F350 Bodhisattwa Shisma Wolverène Tris T7 Antoine2711 Hrk6626 TheFireBender V!v£ l@ Rosière WatchMeWiki! CptViraj ʂɤɲ Trivialist Franzsimon 2le2im-bdc Sotiale Wallacegromit1, mostly focus on media historiography and works from the Global South Floyd-out M2k~dewiki Rockpeterson Mathieu Kappler Sidohayder   Notified participants of WikiProject Movies --- Jura 09:59, 18 December 2020 (UTC)

  •   Support Until the server issues are sorted out, we could point to archived versions of the pages. Trivialist (talk) 11:02, 18 December 2020 (UTC)
  •   Support Wallacegromit1 (talk) 18:56, 18 December 2020 (UTC)
@Hannes Röst, Trivialist, Wallacegromit1: do you need to wait longer ? Are there still server issues? Pamputt (talk) 18:05, 28 December 2020 (UTC)
The links in the examples go to a "Database error" page. UWashPrincipalCataloger (talk) 08:50, 21 February 2021 (UTC) IDEdit

   Under discussion
Descriptionidentifier for a memorial on
Data typeExternal identifier
Domainwar memorial (Q575759)
Allowed values\d{1,4}
Example 1war memorial of Fontainebleau (Q94999919)1780
Example 2War memorial of Levallois-Perret (Q96602263)999
Example 3war memorial of Pont-de-Vaux (Q90853317)763
Number of IDs in source2695
Expected completenesseventually complete (Q21873974)
Formatter URL$1.html
See alsoMonument aux morts ID (P6238); MémorialGenWeb monument ID (P8157)


Many war memorials in France still do not have enough information on Wikidata. This website certainly does not have the largest database of inventoried war memorials but offers a detailed bibliography for each of them as well as information that cannot be found on the websites of the other two existing properties. This proposal is very similar to the one below. This identifier would thus make it possible to better centralize information about war memorials in France and could be part of the project proposal that I am setting out here. However, the website uses Adobe Flash, which is a drawback especially when a lot of browsers will remove its support soon. Baidax (talk) 22:00, 16 September 2020 (UTC)


Benoît Prieur
Ash Crow
Thierry Caro
Nomen ad hoc
Marianne Casamance
Nattes à chat
Pierre André
Mathieu Kappler
  Notified participants of WikiProject France Baidax (talk) 22:03, 16 September 2020 (UTC)

ISOF PlaceEdit

   Under discussion
DescriptionPlace name register of Swedish places created by ISOF
RepresentsSwedish Institute for Language and Folklore (Q7654721)
Data typeExternal identifier
Domainsocken (Q1523821)
Example 1Söderala parish (Q10688474)parish-id=176
Example 2Gävleborg County (Q103699)county-id=20
Example 3Algutsrum Hundred (Q4724394)district-id=154
Example 4Sala Silver Mine (Q3314828)place-names/1771147 also same as Hembygdsportalen ID (P6192)171278
SourceWebrest API PlaceNameService see also Notebook
Planned useWikipedia articles and connect with other external identifiers
Number of IDs in source2 million objects
Expected completenessas many as possible at least as many asSwedish place name register SOFI (P5536)
Formatter URL$1 this project is in Beta so its not stable yet so this will be updated
See alsoSwedish place name register SOFI (P5536) old version


A new application is developed and they will change id. We have the old application in Swedish place name register SOFI (P5536) but as they will run both applications in parallell and that they change the structure we propose to create a new property for the new application: Hopefully this new application can be an authority for Swedish places - Salgo60 (talk) 11:59, 11 November 2020 (UTC)


  Comment I believe we should have a property for the new ISOF places, it looks like they can give a lot of background information. However, the ID's in the examples seem conflated with what a URL formatter should do, and when looking at the ID's in their system, they are not named like that at all. So this would be a new ID constructed by us rather than any official ISOF ID. However, in your notebook it seems to be a so far unnamed column with a unique identifier. If that would become something referenceable then I would like us to adjust the proposal and move forward, but as it is right now I would oppose and instead suggest to split this into separate properties for each of the types (parish, county, district, place) so that we could use their native ID. Ainali (talk) 16:26, 11 November 2020 (UTC)

Ainali What we suggest above is an unique pattern I will double check that with the developer but I feel splitting the property will add no added value. E.g. property Uppsala University Alvin ID (P6821) see also T225522 has nearly the same pattern that I feel makes sense... e.h.
I hope Alvin move direction also support "things" like Alvin-taxon:nnnn, Alvin-parish, Alvin-museum.....
What I miss at ISOF is that they dont display this key in the user interface as Alvin does.... my understanding is that ISOF has plans for an identifier fields but we have seen no specifications for that object... changing value is no major problem as we did that with Hembygdsportalen ID (P6192) they changed last year plattform and did the bad decision to also change all "Persistent" Identifiers
- Salgo60 (talk) 20:34, 11 November 2020 (UTC)
Hmm. This is not how that property was presented when approved, and it has deviated from that approval without any discussion on the discussion page. Perhaps that one need a cleanup as well? Ainali (talk) 20:56, 11 November 2020 (UTC)
@Ainali: do what you want... I feel the problem is the lack of dialogue WD <-> Alvin I have since 2019 been trying to get a meeting with Alvin people see T226099 and also I hope to get some commitments from them. I have met Per Cullhed twice at other events and spoken with wadskog 20200914 on the phone but we havnt been sitting down and share future plans and issues. I feel Alvin dont have a linked data vision and they have no interest in better connect with Wikidata/Wikipedia. I am also interested in to get them better support typed species see T236310 - Salgo60 (talk) 21:47, 13 November 2020 (UTC)
Another approach that we could move forward with immediately would be to switch this to not be of the type external-id (since this is several different external-id's) and instead use URL, which seems to be what this really is. Ainali (talk) 21:16, 11 November 2020 (UTC)
URLs is a bad pattern I think we should try follow the DRY pattern and have in the argument something connected to a "thing" and things that can differ in the formatting URL... we have seen before problems with "moving" applications at SOFI that never was fixed see T200979. Below I do a draft of a checklist what we(Wikidata) want from an external identifier - Salgo60 (talk) 21:47, 13 November 2020 (UTC)

adjacent toEdit

   Under discussion


We already have a few specific properties for adjacency, but instead of creating a new property for every different type of item that adjacency applies to, this would be a general property for all types for which there is not already a more specific one in existence (see the three related, specific properties linked above). Exact context of adjacency would depend on the exact type of item it is applied to, so no need for elaborate constraints on this property. It would become the parent property for the three properties already extant. Josh Baumgartner (talk) 10:32, 19 November 2020 (UTC)


  •   Comment I think we already had similar proposals, e.g. Wikidata:Property proposal/monument in the near. --- Jura 12:42, 20 November 2020 (UTC)
    • Thanks for bringing that one up. Adjacency cannot be calculated by coordinates and indicates a particular relationship between two entities, so while I understand the discussion there, it is not particularly relevant to this one. Josh Baumgartner (talk) 12:25, 21 November 2020 (UTC)
Mona Lisa (Q12418) being otherwise located in a relative adjacent location of Jupiter Hurling Thunderbolts at the Vices (Q18573249) ?
  • If items have a physical contact point connects with (P2789) is our property that specifies that relationship. ChristianKl❫ 18:20, 20 November 2020 (UTC)
    • Thanks for pointing that one out, it would probably do nicely for example 1. Not so sure it would work for 2, 3 & 4. Josh Baumgartner (talk) 12:25, 21 November 2020 (UTC)
      • Can you explain why you think this example works better for those examples (I'm not familiar with those examples)? What's the shared point in contact? ChristianKl❫ 20:44, 21 November 2020 (UTC)

OSM objectEdit

   Under discussion
Descriptionway or node in Open Street Map for the item, generally linking back to Wikidata. If possible, use "OpenStreetMap relation ID" (P402).
RepresentsOpenStreetMap (Q936)
Data typeString
Domainexisting items for geographical objects
Allowed values(way|node)/\d+
Example 1MISSING
Example 2MISSING
Example 3MISSING
Formatter URL$1
See also
Distinct values constraintyes


Currently we have mainly OpenStreetMap relation ID (P402) to link to OSM. This as relations are seen as a sufficiently stable to link them with an external-id property.

OSM links to Wikidata also from ways and nodes. We avoided creating a external-identifier properties for them as they are seen as less stable.

The result is that many objects are present in both Wikidata and OSM, but can't be queried from Wikidata directly.

An alternate way is proposed here: instead of an external identifier property, a string datatype property is proposed. Further, to ensure a reasonable stability, the OSM object would generally link to the Wikidata item. When using the value, one should ensure that this is the case (Add your motivation for this property here.) --- Jura 12:06, 17 December 2020 (UTC)


  • The ID is not stable. See Wikidata:Property proposal/OSM node ID.--GZWDer (talk) 16:58, 17 December 2020 (UTC)
    • That is an argument we also had about OSM relations for which we finally kept an external-id property. The question is now if the above proposal addresses it in an appropriate manner for nodes and ways. Afterall, we do link plenty of non-WMF wikis with properties by pagetitle. --- Jura 17:43, 17 December 2020 (UTC)
  • The link between them already exists, but from OSM -> Wikidata. They can be queried from Overpass Turbo (Q62057787) or Sophox (Q55840137), which is enough. NMaia (talk) 00:36, 18 December 2020 (UTC)
    • BTW, Wikidata:OpenStreetMap mentions one of OSM query tools in past tense due to some problem. --- Jura 06:58, 18 December 2020 (UTC)
  • Yeah, as mentioned, OSM does link to Wikidata (and has some query functions). We also had this argument to delete OpenStreetMap relation ID (P402), but decided that we should link to OSM as well. This way, Wikidata Query Service (WQS) and other ways Wikidata provides data can provide them. --- Jura 06:58, 18 December 2020 (UTC)
  •   Weak support. Creating relations for the sole purpose of linking from Wikidata is tiresome. As for stability… well-tagged stuff (what we want to reference) don't generally go away, but may get merged and change ID. --Artoria2e5 (talk) 23:58, 16 February 2021 (UTC)
  •   Oppose Not as stable as relations; linkage already exists from OSM to Wikidata and thus can be queried from Overpass. NMaia (talk) 00:09, 17 February 2021 (UTC)
    • @NMaia: Stability can be achieved in other ways (see above). That Wikidata items can be queried on other websites is never a reason to not add information to Wikidata. The presence of relations is just to much random that we could rely on that only. --- Jura 00:14, 17 February 2021 (UTC)

Oklahoma's NRHP IDEdit

Descriptionidentifier for a structure or a building listed in the National Register of Historic Places in the Oklahoma's National Register of Historic Places database
RepresentsOklahoma's National Register of Historic Places (Q105502546)
Data typeExternal identifier
Domaingeographic location (Q2221906)
Allowed valuesexternal-id
Example 1Harris Palace Store (Q105502650)SG100004399
Example 2Perkins Downtown Historic District (Q105502670)1578
Example 3Perry Armory (Q19987512)88001362
External linksUse in sister projects: [ar][de][en][es][fr][he][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][commons][species][wd].
Planned useTemplate:Buildings links (Q25751684)
Expected completenesseventually complete (Q21873974)
Formatter URL$1
See alsoNRHP reference number (P649), The Encyclopedia of Oklahoma History and Culture ID (P7723)


This new Wikidata property for authority control for cultural heritage (Q18618628) would help improve our coverage of the history of Oklahoma (Q4572407). Most of the time, the values would be strictly equal to those of NRHP reference number (P649), but then not all the time, as examples show. Thierry Caro (talk) 11:44, 15 February 2021 (UTC)


Akuckartz Beat Estermann Vladimir Alexiev Ilya Sadads Astinson Strakhov Zeromonk Spinster Wittylama Daniel Mietchen Susannaanas Sic19 Jason.nlw Carlojoseph14 YULdigitalpreservation MB-one Ouvrard MartinPoulter Missvain VIGNERON Ainali Birk Weiberg Pmt Mauricio V. Genta Smallison ProtoplasmaKid 2le2im-bdc Rodrigo Tetsuo Argenton Ivanhercaz VisbyStar Patafisik Beireke1 Vahur Puik Ettorerizza Sp!ros Alexmar983 Epìdosis Buccalon Mrtngrsbch Eothan Giaccai NAH User:Fralambert Ipoellet Valeriummaximum Hannes Röst Ahc84 AmarilisMGC Trivialist   Notified participants of WikiProject Cultural heritage. Thierry Caro Fuzheado   Notified participants of WikiProject United States. Thierry Caro (talk) 11:44, 15 February 2021 (UTC)

  Support --Fralambert (talk) 12:47, 15 February 2021 (UTC)

AIATSIS Place Thesaurus IDEdit

   Ready Create
Descriptionidentifier for a place in the AIATSIS Place Thesaurus
RepresentsAIATSIS Place Thesaurus (Q105550536)
Data typeExternal identifier
Domainitem; geographic location (Q2221906), toponym (Q7884789), place name (Q10816094)
Allowed values[1-9]\d*
Example 1Blue Mountains (Q667529)3596
Example 2Bondi Bay (Q21922547)4738
Example 3Papua New Guinea (Q691)38
Example 4Mount Ernest Island (Q21906437)128
Example 5Murray River (Q183078)20
Example 6Adelaide (Q5112)2279
Example 7New England (Q1467315)3406
Example 8Torres Strait Islands (Q1059258)50
Example 9Tasmania (Q34366)7
Planned usewill add to items as encountered
Expected completenessalways incomplete (Q21873886)
Formatter URL$1&n=1&s=5&t=2


The AIATSIS Place Thesaurus of the Australian Institute of Aboriginal and Torres Strait Islander Studies (Q781523) contains headings for place names, using the Indigenous place name first wherever possible. Adding this property to Wikidata will be a useful addition for Australian places in particular. UWashPrincipalCataloger (talk) 21:23, 17 February 2021 (UTC)


district heating gridEdit

   Under discussion
Descriptiondistrict heating (or cooling) grid of region/locality connecting producers and residential or commercial consumers in the area
Representsdistrict heating (Q278784)
Data typeItem
Example 1Vienna (Q1741)Q105687065: district heating system in Vienna, Austria
Example 2Paris (Q90)Q105687036: district heating system in Paris, France
Example 3Ivry-sur-Seine (Q193877)Q105687036: district heating system in Paris, France
Example 4Berlin (Q64)Q105687045: district heating system in Berlin, Germany
Planned useadd from w:District_heating#National_variation


It seems we have plenty of information about transportation infrastructure, but lack data on more basic parts of infrastructure, such as the above. Generally, there would be one value per neighborhood or region. This should simplify finding a relevant grid for a given location (Add your motivation for this property here.) --- Jura 21:46, 23 February 2021 (UTC)

Rehman ArthurPSmith Katjos Te750iv Jklamo Dhx1 Scott Davis Andber08 Gnoeee   Notified participants of WikiProject Energy --- Jura 21:47, 23 February 2021 (UTC)


  •   Comment Thinking ahead to the concept of a water, electricity, gas, telecommunications, etc grid/network--perhaps a more generic "area serviced by infrastructure network" property could be proposed? Similar to the idea of highway system (P16) which is used for linking roads to road networks. --Dhx1 (talk) 23:05, 23 February 2021 (UTC)
    • Is there an advantage in combining them and making it multi-valued, with or without highway system (P16)? --- Jura 23:20, 23 February 2021 (UTC)
    • If not, I'd keep them separate: modeling challenges might differ. BTW, for several aspects of telecom networks properties are already available. --- Jura 09:38, 26 February 2021 (UTC)

GB1900 IDEdit

   Under discussion
DescriptionIdentifier for a place in the GB1900 project transcription of the Ordnance Survey six-inch-to-one-mile map, 1888-1913
RepresentsGB1900 dataset (Q105554422)
Data typeExternal identifier
Domaingeographic location (Q2221906)
Allowed values[0-9a-f]{24}
Example 1Palace of Westminster (Q62408)57e3dd302c66dca408000096 (as "HOUSES OF PARLIAMENT")
Example 2Chelsea (Q743535)57f17b952c66dca32201b66d
Example 3Thorney House (Q26458246)58e7cb752c66dcf8fa0b4ada
Expected completenessalways incomplete (Q21873886)
Applicable "stated in"-valueGB1900 dataset (Q105554422)

Source informationEdit

The GB1900 project (Q105554350) was a mass-participation community transcription project that between September 2016 and January 2018 transcribed every text string that appears on the 6-inches-to-the-mile (ie 1:10560) series of maps made by the Ordnance Survey (Q548721) between 1888 and 1913. Every string was attached to a geo-coordinate, corresponding to the bottom-left of the first letter of its first word. (See [11] for more information).

The output of the project is available from in three forms:

  • Full final raw dump (CC0) -- 2666342 location rows, 8043679 transcription rows
  • Complete gazetteer (CC-BY-SA) -- 2552460 location + transcription rows
  • Abridged gazetteer (CC-BY-SA) -- 1174450 location + transcription rows

Note that the files are in 16-bit unicode, so to use 'grep' on eg a standard cygwin install something may be needed like

grep -Pa `echo -n "58e7cb752c66dcf8fa0b4ada" | iconv -f utf-8 -t utf-16le | hexdump -e '/1 "x%02x"' | sed 's/x/\\\\x/g'` gb1900_transcriptions.csv

Also be aware that the coordinates in the 'locations' file in the raw dump are stored as hexadecimal strings in Well Known Binary (WKB) format -- see Simple Features (Q365034) (Thanks to Nikki on the wikimaps telegram group for identifying this format for me, with Stefano not far behind).

The "complete gazetteer" includes reconciliation of about 1.5% of the original transcriptions, where these were in disagreement; and also added (modern) parish and (modern) local authority fields. The "abridged gazetteer" excludes a large numbers of frequently repeating labels, such as "F.P." for footpath, but "still contains many transcriptions which are not necessarily place-names".


The GB1900 ID would be a slightly unusual external-id for wikidata for several reasons:

  1. there is at the moment no site that accepts the IDs as part of a url, so no url-formatter is possible. (In the above I have linked directly to the coordinates given in the data files).
  2. the coordinates do not quite represent the coordinates of the actual object, but instead that of the start of its label
  3. the files come with no information as to what sort of thing the coordinates are for.

(This last is slightly surprising, because given the location and the character-string for each label, it might be not be thought too difficult a machine-learning proposition to identify the font-size and style the label was in, and at least extract that. But it seems this has not been done, or not been possible. On the first point, paper [12] (2019) describes a site that will accept the identifiers, including a pre-beta screenshot (figure 7). This is still intended, according to the Vision of Britain team, however as of 2021 it has not yet been possible to put that part of the site into production availability, "but the tech people are making progress".)

Nevertheless in my view this would be a useful dataset to be able to match into, for at least two reasons. In particular it may have been used in various external geotagging projects to eg provide ready coordinates for places ending in the word 'Castle' or some such similar word. Also such matching would provide useful sanity-checking for our own coordinates, even though it should be kept in mind that GB1900 coordinates do not exactly represent the location of the underlying place.

Proposed Use-styleEdit

I would propose to add the property, for items that can be matched into the dataset, with qualifiers named as (P1810) to give the GB1900 preferred name for the place, and coordinate location (P625) to give the GB1900 coordinates for the place, if the name and coordinates can be found in the CC0 "raw dump" files.

I would not propose that coordinates from GB1900 be used in a main coordinate location (P625) statement, as in general they will not (quite) match the location of the actual place. Therefore IMO it is better to give them as a P625 qualifier. This is also will also prove a convenient place to see the places on the underlying OS 1900 maps, which are available on the National Library of Scotland website, via geohack.

Despite the complications, I do think this will be a useful property to have, and a useful dataset to be able to reference into. Jheald (talk) 19:31, 1 March 2021 (UTC)


  • Proposed. Jheald (talk) 19:31, 1 March 2021 (UTC)
  •   Support Very interesting idea. PKM (talk) 20:07, 1 March 2021 (UTC)
  • Suggest contact National Library of Scotland to see if they would be interested in applying the machine learning appraoch mentioned by Jheald - ColinStuartGreenstreet (talk) 20:46, 1 March 2021 (UTC)
Good suggestion. But we can probably get quite a long way matching smaller-scale items to GB1900 hits -- eg listed buildings, scheduled monuments, heritage sites, etc -- even without any 'type' information, given the rough coordinates and that the names will be reasonably unique. It may become a bit trickier for items on the scale of villages and towns, to be sure that we're distinguishing which GB1900 label corresponds to the settlement, to the parish, to the constituency etc. But my feeling would be to start matching what we can, and then talk to the NLS, once we already have some matches to show for ourselves. Jheald (talk) 21:12, 1 March 2021 (UTC)
  •   Support The use of this dataset in other projects e.g. Viae Regiae, is going to make matching it to Wikidata items increasingly useful.DrThneed (talk) 22:46, 1 March 2021 (UTC)

named place on mapEdit


1576 Saxton map of Essex. It names a large number of places.

In March 2021 WikiProject EMEW's partners, the Viae Regiae (Q105547906) project, will start a major drive to transcribe and identify all the places and placenames on several series of 16th and 17th century maps, like the 1576 Saxton map of Essex to the right. (They will actually be using a higher-resolution copy, which we will be uploading).

As can be seen from the map, the number of places on it is very large; the process may generate of the order of 1000 located places per map, which we will be recording as Structured Data statements on Commons.

It would be good to have a property other than depicts (P180) to record this information. In the map to the right, the appropriate value of depicts (P180) = Essex (Q23240). The settlements of West Ham, Leyton, and Wanstead only appear as 3 small places out of a thousand, close to the border with Middlesex. For user convenience, efficiency of querying, and clarity, it is useful not to overload the main depicts (P180) statement with this information, and still less use main subject (P921) but to keep it segregated and record it separately with a different property -- the relationships are of a different nature. We shall also be exploring whether it is possible to emit the information again in a IIIF manifest, a test of the ability of Structured Data on Commons to support annotation at scale.

The statements will be accompanied by the qualifiers stated as (P1932), to record the name as given on the map, and relative position within image (P2677) to record where on the map the image locates the place.

A question still to be evaluated is whether SDC and the SDC user interface will be able to cope well with such a large number of statements, all of the same kind. The technical view on the phabricator ticket raised by the WikiProject on this point (phab:T275286) seems to be "try it and see". But it may be that when there are a very large number of statements of a particular kind, it would be advantageous to put them in a collapse-box. This would be another reason to keep the principal depicts (P180) statements separate from the statements for named places, so they would remain visible.

However the main purpose of this property proposal is simply to have a property other than depicts (P180) to start trying to record this information.


  • Proposed. Jheald (talk) 22:27, 1 March 2021 (UTC)
  •   Support I support using a property separate to depicts for this, as a mark on a map seems to me a very different thing to what would normally be implied by a depicts statement. The benefit of this proposal would cut both ways, so it would keep these map markings out of the way of the main depicts statements, but also make it easy for people who want to find all the maps with a particular place on. DrThneed (talk) 22:45, 1 March 2021 (UTC)
  •   Don't ping me   Support NMaia (talk) 03:13, 2 March 2021 (UTC)
  •   Support - PKM (talk) 04:23, 2 March 2021 (UTC)
Wikimaps facebook group notified of property proposal: link
  •   Comment Interesting use of Wikidata. Personally, I'd try to do it on Wikidata (not SDC), but even here the number of statements might eventually become problematic through the GUI.
    What happens when the place name cane be deciphered, but not matched (exactly or at all) to an item? Should the value be the name and the qualifier the mapping to a Wikidata about the place? --- Jura 16:42, 2 March 2021 (UTC)
Another alternative could be to record it directly as a Lexeme form. This has the advantage that place can be determined in a clearly separate step. --- Jura 16:52, 2 March 2021 (UTC)
@Jura1: Useful Qs. If the place cannot be identified, or has no wikidata item, we can use ?map "named place on map" <somevalue> / "stated as" ?name_on_map in the usual way.
Putting the identified place on the main statement, rather than on a qualifier, seemed the right way to go, to make it a couple of lines easier to write queries like "which of these maps include this place" (even though they may name it differently -- spelling was very variable in this period).
The reason to go for Commons and SDC, in the first instance, was to be able to hang the position qualifier off the statement, which may be specific to a particular digitisation of the map. But you'll notice that the property proposal specifies for use on files or items, and we're thinking about how high up the individual copy -> edition -> work hierarchy it might be useful also to record this information. Jheald (talk) 18:53, 2 March 2021 (UTC)
@Jura1: re-pinging, because I think I didn't get it right before (forgot the '1' on your username). Jheald (talk) 21:47, 2 March 2021 (UTC)
  • Instead of "try it and see" with SDC, you could just check any image with a large number of statements and see how it loads (or doesn't). I vaguely recall that already 20 was slow. In either place, you probably need to edit it with some other tool.
About the comparison qualifier vs. main statement: a point to consider is also that place names that can refer to several places (maybe less a problem for maps than place names in works in general).
@Susannaanas: might be interested. --- Jura 13:52, 5 March 2021 (UTC)
@Jura1: On the ticket (phab:T275286) Lucas looks at c:File:Nature Timespiral.png, which currently has the largest number of SDC statements of any file on Commons, and finds it all seems to work. Jheald (talk) 16:22, 5 March 2021 (UTC)
Good for him. Might just be my browser. --- Jura 17:24, 5 March 2021 (UTC)
  •   Comment Sorry for taking the time to follow up. I think this is an interesting approach. I wonder if there are properties for annotations that could be put together with this, or whether it is a good idea to keep the place candidates separated from the start. I am not well enough up-to-date on annotation-related properties, but I am sure if you and the team have thought about this and ended up in this solution, it should be good enough. Could you sketch out a sample annotation with stated as (P1932) and relative position within image (P2677)? I also think that maps could be stored in Wikidata, and the annotations would refer to a map original rather than an image copy. But it seems you have both options. – Susanna Ånäs (Susannaanas) (talk) 14:20, 5 March 2021 (UTC)
  • I am confused however, that they should be recorded as items. In that case I would also suggest using lexemes instead. – Susanna Ånäs (Susannaanas) (talk) 14:27, 5 March 2021 (UTC)
@Jura1, Susannaanas: so a couple of examples for this map, with qualifiers:
File:Essexiae... "named place on map" West Ham (Q939617) / relative position within image (P2677) = "pct:15.2,85.0,0.5,1.0" / stated as (P1932) = "W Ham"
File:Essexiae... "named place on map" Barking (Q377720) / relative position within image (P2677) = "pct:20.5,84.7,1.4,1.3" / stated as (P1932) = "BARKINGE"
For me the lexeme idea doesn't work at all. The names on the map are strings, not forms of dictionary words. Creating Lexeme items for these particular spellings would have no particular value. It is useful to be able to retrieve the strings as strings in a query, and that can be done.
Secondly, use of {{P|2677}. For this image P2677 makes sense, as places are recorded using glyphs of different sizes. (See here for the project's current rough typology, which is likely to evolve.) Specifying the bounding box allows a crop just of the glyph to be retrieved easily. If the information were available, one might additionally specify region within image (P8276) to specify a polygon around the glyph. That information is not currently planned to be retrieved, but might be extracted at a future stage by machine learning methods.
For other maps it might make sense to record the position of just a point on the map rather than a box or a polygon. Unfortunately there appears to be no property to do that at present.
The design is essentially identical to how annotations are expected to be stored on Commons. (At least it seems so, depending whether anybody has done thought on this). cf eg the use of relative position within image (P2677) on File:ISSSpaceFoodOnATray.jpg
As to why target the files on Commons first, (i) if it breaks things, we don't want to break wikidata. Breaking presentation of Commons SDC is expendable, because nobody uses it for anything. Breaking wikidata is not; and (ii) as already stated, the glyphs are small objects. If the image (P18) value is changed to a new improved different digitisation, that is cropped even slightly differently, none of the boxes will fit found the glyphs any more. Therefore it makes more sense, at least to start with, to put the information on the SDC of the image. But we are thinking about what also to store on wikidata -- User:PKM in particular, who is developing the data model for the wikidata items for the maps (see Wikidata:WP EMEW/Sources).
Hope this helps to clarift our thinking a little bit. Jheald (talk) 16:16, 5 March 2021 (UTC)
  Support I think I must have misunderstood a little, and this looks much more straightforward than what I first thought. So the values are geographic places, not place names or candidates for places or place names. I can see value in it being a separate property. – Susanna Ånäs (Susannaanas) (talk) 16:55, 5 March 2021 (UTC)

inhabitants of topicEdit


Aliases: residents of topic | human population of topic | demonym for topic

This property would provide a way to link directly from the item for a place to the item for the inhabitants of that place. This is similar to the existing properties demographics of topic (P9241), history of topic (P2184), economy of topic (P8744), and geography of topic (P2633). UWashPrincipalCataloger (talk) 22:31, 2 March 2021 (UTC)



Outer spaceEdit

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

planetary coordinates locationEdit

   Under discussion
Descriptioncoordinates of a location on an astronomical body other than Earth: a bot will set the globe based on the value of "located on astronomical location" (P376) statement. For coordinates on Earth, use P625. For celestial coordinates, see the property talk page
Data typeGeographic coordinates
Domainlocations on planets, their satellites, other astronomical bodies
Example 1Mare Tranquillitatis (Q320936) → 8°30'N, 31°24'E, globe: Moon (Q405)
Example 2Cleopatra (Q2545681) → 65°48'0"N, 7°6'0"E, globe: Venus (Q313)
Example 3Ptolemaeus (Q2886300) → 45°52'48"S, 202°24'0"E, globe: Mars (Q111)
Example 4Rimbaud (Q25908367) → 63°36'0"S, 148°49'48"W, globe: Mercury (Q308)
Example 5Aellopus Saxum (Q89208827) → 25°26'24"N, 335°40'12"E, globe: 101955 Bennu (Q11558) [currently appearing as located on Earth]
Example 6Strix Saxum (Q87349551) → 13°24'0"N, 88°15'36"E, globe: 101955 Bennu (Q11558) [currently appearing as located on Earth]
Planned usearrange for conversion of 7233 statements (see below)
See also


It's still unclear why this should be mixed into WGS84 coordinates from Earth. Avoids users getting random locations when query earth P625 data without checking globe:
7233 of 8,264,173 statements are not about Earth.
Should we use the label "planetary coordinates" even if it's also used for (e.g.) lunar coordinates? (Add your motivation for this property here.) --- Jura 08:56, 10 October 2020 (UTC)

Some questions from discussion below
  1. what to do with celestial coordinates? (currently covered by separate properties, no development planned to include them in datatype)
  2. change usage of globe parameter (currently generally planet/body)
  3. make separate properties for other astronomical bodies that are frequently used (e.g. Moon)

--- Jura 09:31, 25 October 2020 (UTC)

Paperoastro Sarilho1 Ysogo Cekli829 Manlleus Meodudlye, with only limited amount of time to spend in the foreseable future. mikeu Jc3s5h VIGNERON Harlock81 Ptolusque J. N. Squire Tom.Reding Mike Peel Shisma Athulvis Romuald 2 Simon Villeneuve Wallacegromit1 - generally like to add ground and space observatory instrument data Path slopu cdo256 Jura1 Kepler-1229b  Notified participants of WikiProject Astronomy please help complete the proposal --- Jura 08:56, 10 October 2020 (UTC)

Cekli Adert Mu301 FabC Romain2boss Shisma AlienAnnie Tris T7 Aluxosm Rjelves Wallacegromit1 Kees08 Jura Huntster Josecurioso  Notified participants of WikiProject Space --- Jura 06:15, 11 October 2020 (UTC)


  •   Comment see previous numerous discussions, in particular: Wikidata_talk:WikiProject_Astronomy#coordinate_locations_other_than_Earth (and also on Property_talk:P625). There is a lot of serious questions and problems to be solved before being able to create a new property so   Oppose for now. Cheers, VIGNERON (talk) 09:31, 10 October 2020 (UTC)
    • To speed it up, can you list the ones that still need to be addressed? --- Jura 09:37, 10 October 2020 (UTC)
      • Sure. Amongst many other point already raised (see the links): Why do we even need a new property? The current model doesn't seems broken (and if it ain’t broke, don’t fix it). What would be the the default globe for this property? (is it even possible to have a default globe other than Earth? and is there any chance that phab:T56097 would be solved soon? @Lydia Pintscher (WMDE): for these two points). Should we prefer planetocentric or planetographic coordinates? (difficult but probably worth to have one system only) What about celestial coordinates? Why planetary and not astronomical in the label? Any suggestions on constraints? Cheers, VIGNERON (talk) 10:06, 10 October 2020 (UTC)
        • I unfortunately don't know enough about the subject area to confidently spec out how the current datatype should be extended (or not depending on a few factors). If someone has time to sit down with me and talk it through for 30 mins we could make progress. Since I am not entirely sure how the end result should look like I can't yet tell how hard it would be.
        • I would also be interested in understanding roughly how many statements we're talking about that this would cover. --Lydia Pintscher (WMDE) (talk) 16:19, 13 October 2020 (UTC)
      • Ok, thanks for detailing the "lot of serious questions and problems". --- Jura 10:09, 10 October 2020 (UTC)
        • "Planeary" suggests coordinates with an origin at (or close to) the center of mass of the planet, and which move and rotate with the planet. "Celestial coordinates" would be the location of the planet in space, and the origin of such a system would usually be the center of mass of the solar system, or the center of mass of the Earth. "Astronomical" has a meaning when expressing latitude and longitude on Earth that might not apply to other bodies. Jc3s5h (talk) 13:58, 10 October 2020 (UTC)
  •   Question for the last step above ("notify users of Earth coordinates that they can simplify their queries/code"), do we have samples of uses that can be simplified, or all they all just hoping not to get locations on Mars, i.e. incorrectly not checking globe for Q2 or the absence of P376? --- Jura 10:07, 10 October 2020 (UTC)
  •   Question To make sure this covers all non-Earth current usecases of P625, please mention any samples this may have difficulties to cover (not sure if there could be any). Obviously, it doesn't aim to cover anything we can't currently do with P625. --- Jura 10:34, 10 October 2020 (UTC)
  • I think I might be more comfortable with a specific property for each "planet" we need them for. Maybe a generic property will eventually prove necessary, but there's only a handful right now that I think are relevant, right? There's no meaning to such coordinates on any of the gas giant planets (or the Sun, for instance). So - Mercury, Venus, Moon, Mars, maybe some moons of Jupiter and Saturn, and Pluto for now? No more than a dozen of them I expect. And the vast majority of interest at the moment I suspect are either Moon or Mars, so how about just 2 properties for those two to start with? ArthurPSmith (talk) 15:21, 12 October 2020 (UTC)
    • That could be an (additional) option. Currently that are just 40 globes, but most are from three (Moon, Mars, Venus). I added som stats above.
      If we leave in the others, the problem would still be that we have random non-Earth coordinates mixed into Earth ones. --- Jura 19:29, 12 October 2020 (UTC)
    • I suppose the underlying reasoning for having one property per planet is that rendering on maps is likely on a per planet basis too. --- Jura 19:42, 12 October 2020 (UTC)
  •   Oppose Unless we start having disputes about meridian lines again, I think coordinate location (P625) presents a reasonable solution for all planets at the moment, and creating new properties wouldn't improve the situation. I've been bold and changed phab:T56097 to 'high' priority, since being able to specify the planet in the UI seems rather important! Thanks. Mike Peel (talk)
    • Maybe in another 8 years, we can merge the properties back together. More seriously, I don't think the ticket solves much in relation to this proposal. --- Jura 19:32, 12 October 2020 (UTC)
  •   Comment maybe a question to ask would be if there is any advantage of including 8 non-Earth coordinates in 8000 Earth coordinates with the same property. --- Jura 11:30, 13 October 2020 (UTC)
  •   Support I didn't think of the asteroids we have geographic details for now too - Ceres, Eros, etc. Ok, I think that's a sufficient quantity that at least a temporary dedicated property for this is a good idea. How about calling it "off-Earth coordinate location" with a usage instruction that makes it clear the API needs to be queried to set and see the globe involved. ArthurPSmith (talk) 19:29, 13 October 2020 (UTC)
  •   Oppose hesitantly. The motivation as it stands is too weak. I doubt it will give structural clarity, and I think improving documentation is a better first step. "getting random locations" is merely a misunderstanding. IMHO the way of Wikidata is to have general properties and the combination of qualifiers and subject needs to be observed. I tried to come up with an equivalent example by saying "when getting a list of date of birth (P569) the results are not what I want. Some people are dead and there are horses in the list, I also didn't expect the Gregorian Calendar." The birthday example actually was brought up in 2013 together with coordinates. I don't think consensus changed for any of them. why this should be mixed Is the fact there are only a few horses a reason to de-generalize the property? this makes sense seems to be the implicit argument for the change. Assuming this to simplify queries is short-sighted. The bigger problem I see is if data is incorrectly entered into the database. Making a new property does not guarantee that there will be no instances where the coordinate location (P625) is mistakenly used for the wrong Globe (set or not set). Changing the way it has been defined for many years is more likely not changing the use unless it's strongly enforced. what are the ideas there? notify users of Earth coordinates I don't see the reason for them to change anything if it's working. But if you have a way to detect usage, why not contact those who query the property incorrectly? Jagulin (talk) 06:10, 14 October 2020 (UTC)
    • @Jagulin: I think people end up hard coding exceptions in all sorts of code to exclude non-Earth coordinates. P625 broke at WMF sites not too long ago, see phab:T210617 and if even WMF can't handle it correctly .. If we have a coordinates datatype for properties, this is to actually create several properties with the same datatype. The question is still if there are any cases where it's an advantage to have WGS84 and (e.g.) lunar coordinates in the same property. BTW, we also have birthday (P3150). --- Jura 06:23, 14 October 2020 (UTC)
  • I think that P625 shoud have a reference frame Q184876 which would be more useful than "globe" in that it specifies the definition of an origin that is used. See the reports of the IAU working group for an authoritative view on extraterrestrial body coordinates.[13] --Mu301 (talk) 13:29, 14 October 2020 (UTC)
    • @Mu301: Isn't this sometimes done with a qualifier? Should we use the globe that way with this new property? --- Jura 06:27, 15 October 2020 (UTC)
    • I agree that a qualifier is a better way to do it. We already have that datatype. --Artoria2e5 (talk) 00:02, 17 February 2021 (UTC)
      • Okay, as a further extension: the geo URI thing has a crs param to do the reference frame and a fixed format for it. We can possibly map to it with determination method (P459), but that sounds very vague. --Artoria2e5 (talk) 04:28, 17 February 2021 (UTC)
  •   Comment I expanded the description of the property above. --- Jura 06:27, 15 October 2020 (UTC)
  •   Comment I don't understand the opposition here. This proposed property would be immediately used thousands of times - much more than many other properties we've created. And it would alleviate an obvious source of confusion with the existing property. As only roughly 1/3 or less of the usage would refer to any single celestial globe, it would be very different from the current property where 99.9% of usage is for Earth. Reuse would be easier; constraints would be simpler, etc. ArthurPSmith (talk) 16:35, 15 October 2020 (UTC)
    • @Mike Peel: can you clarify? --- Jura 05:10, 16 October 2020 (UTC)
      • @ArthurPSmith, Jura1: I think a new property should add something valuable to the way we store data here - e.g., so we can store data that we couldn't fit in before, we can store it via a different data format, or so that qualifiers can be added to the data. In this case, we can already store the information, it would still be in the same coordinate format with a new property, and we can already specify the globe it applies to (but not in a convenient way - which is what I think the problem is). So I can't see the benefit of creating new properties here, it just means that reusers of the data (e.g., in infoboxes) have to add more checks to find the right property to use, rather than just checking which globe the property applies to. Thanks. Mike Peel (talk) 19:33, 16 October 2020 (UTC)
        • @Mike Peel: So you use a different infobox on Earth and non-Earth locations - and the Earth infoboxes which would be at least 99.9% of cases then don't have to worry about globe. Surely that's simpler? ArthurPSmith (talk) 19:44, 16 October 2020 (UTC)
          • @ArthurPSmith: Commons uses commons:Template:Wikidata Infobox for all topics. Surely that's simpler? Thanks. Mike Peel (talk) 19:46, 16 October 2020 (UTC)
            • @Mike Peel: Which doesn't appear to function for non-Earth locations right now? At least I don't see anything useful there for commons:Category:Olympus Mons for example? And is adding one more property to the hundreds that infobox supports such a burden? ArthurPSmith (talk) 19:54, 16 October 2020 (UTC)
              • @ArthurPSmith: Hmm, I need to debug that, thanks for pointing out the problem. Performance has become an issue with the template this year, since it loads a lot of properties and data, so adding more properties would cause more problems. Thanks. Mike Peel (talk) 20:14, 16 October 2020 (UTC)
            • @Mike Peel: Wouldn't c:Template:Wikidata Infobox be simplified if one neededn't check for a Q2-globe each time P625 is loaded? --- Jura 09:45, 17 October 2020 (UTC)
  • @Mike Peel: the above would be the code made redundant. --- Jura 04:49, 18 October 2020 (UTC)
  •   Oppose I prefer the uniform way in which coordinates on any body (and potentially in any coordinate system on any body) can be expressed with one property. See how the "coordinate system" / "body" is embedded in the value, with the default being a particular system on Earth:
  • select * where {
      values ?item { wd:Q1726 wd:Q487895 }
      ?item wdt:P625 ?coords .
    Try it!
  • I'd be confused as user and tool writer if I had to remember to use a different property when switching from Earth to another object (or to another reference system on Earth). Toni 001 (talk) 17:23, 19 October 2020 (UTC)
    • Oddly, we couldn't yet identify such a tool on WMF sites, but see above for several cases of the opposite (tool writers assume all coordinates are on Earth). Besides, you already have to (see celestial coordinates mentioned above). --- Jura 09:21, 20 October 2020 (UTC)/09:31, 25 October 2020 (UTC)
  • I'm not an expert, but I just read chapter 10, "Physical Ephemerides of Solar System Bodies" in Explanatory Supplement to the Astronomical Almanac 3rd ed. (Q20668025). This gives detailed information on the coordinate systems for the Sun, all the planets, Ceres, and Pluto. I don't know how one goes about defining the prime meridian for a body like the Sun or Neptune, but astronomers do. For most dwarf planets, asteroids, and natural satellites, the radii are listed but other information that would be needed for a coordinate system is omitted (and is probably undefined for all but the largest asteroids), so for our purposes I think we can ignore most dwarf planets, natural satellites, and asteroids.
For each body, there are two kinds of coordinate systems, planetocentric coordinates and planetographic coordinates. Only for planetographic, a reference ellipsoid is defined to approximate the surface of the body. Both systems use the same north pole, equator, and prime meridian, but differ in how latitude is defined. In planetocentric, latitude is the equatorial plane and a line segment from the center of mass to the position of interest. For planetographic coordinates, latitude is the angle between the equatorial plane and a line segment that begins where the line segment passes through the equatorial plane, is normal to the ellipsoid, and ends where the line segment passes through the point of interest.
Planetocentric coordinates are used for general purposes. Planetographic coordinates are used for cartographic (that is, mapping) purposes. If I understand correctly, on Earth planetocentric coordinates are called astronomical, geographic, or terrestrial coordinates while planetographic coordinates are called geodetic coordinates. (See p. 22 and glossary of Explanatory Supplement to the Astronomical Almanac 3rd ed. Jc3s5h (talk) 15:19, 24 October 2020 (UTC)
  •   Comment Query Service supports globe for distance calculations. Supposedly it has some assumption about which type of coordinates is being used by default.
    Beyond that, we could try to use a better "globe" than the planet/astronomical body. --- Jura 09:31, 25 October 2020 (UTC)
  •   Comment About qualifiers used with non-Earth globes in P625: I only found a few items that repeated the globe with located on astronomical body (P376) there. This in addition to located on astronomical body (P376) used as statement. I removed those (sample). --- Jura 20:32, 25 October 2020 (UTC)
  •   Comment Planetographic coordinate systems have similar stuffs for every planets: range between -180 to 180 and -90 to 90 and similar units. Why do not create a property of geographic coordinates for every planet? --Paperoastro (talk) 22:02, 25 October 2020 (UTC)
    We should not use anything called geographic coordinates for anything other than earth because the prefix "geo'" means "Relating to the earth." Jc3s5h (talk) 00:24, 27 October 2020 (UTC)
  •   Comment additional problems we identified at Modify a query to cast the same globe:
    1. wikibase:around requires wikibase:globe to be set (it can't be a variable).
    2. wikibase:radius assumes Q2, i.e. distances are calculated as on Earth.
So even WQS doesn't support the globe parameter very well and including random non-Earth coordinates in P625 isn't really an advantage. --- Jura 07:45, 5 November 2020 (UTC)
I would prefer different properties for each globe, to simplify queries and constraints. If we want to use P625, is it possible to add a qualifier to distinguish different globes? --Paperoastro (talk) 17:10, 10 November 2020 (UTC)