Property talk:P131

Latest comment: 2 months ago by Bouzinac in topic New country constraint fails


located in the administrative territorial entity
the item is located on the territory of the following administrative entity. Use P276 for specifying locations that are non-administrative places and for items about events. Use P1382 if the item falls only partially into the administrative entity.
DescriptionThe item is located on the territory of the following administrative unit (upper level administrative subdivision). For non-administrative locations (such as unincorporated area (Q269528)), rather use location (P276) or located in/on physical feature (P706).
Representsadministrative division (Q56061)
Data typeItem
Domaingeographical feature (Q618123) (note: this should be moved to the property statements)
Usage notesYou only need to add the most local admin territory, but check that item also has a P131, with the next level, and so on.
ExampleSeattle (Q5083)King County (Q108861)
Eiffel Tower (Q243)7th arrondissement of Paris (Q259463)
Jungfrau (Q15312)Lauterbrunnen (Q64011)
Fieschertal (Q70716)
University District (Q2001177)Seattle (Q5083)
Robot and gadget jobsDeltaBot does the following jobs: Consistency should be checked - if the linked object is of type administrative subdivision, it should link back using contains the administrative territorial entity (P150) (asymmetric reciprocity).
Tracking: sameno label (Q42533293)
Tracking: usageCategory:Pages using Wikidata property P131 (Q23908987)
See alsolocated in/on physical feature (P706), location (P276), located in or next to body of water (P206), contains the administrative territorial entity (P150), applies to jurisdiction (P1001), located in the present-day administrative territorial entity (P3842), school district (P5353), located in the ecclesiastical territorial entity (P5607), headquarters location (P159), located on street (P669), contains settlement (P1383), located in statistical territorial entity (P8138), associated electoral district (P7938), country (P17), located in protected area (P3018), associated cadastral district (P10254)
Proposal discussionProposal discussion
Current uses
Main statement13,012,65598.4% of uses
Qualifier207,1611.6% of uses
Reference99<0.1% of uses
Search for values
Explanations [Edit]
Conflicts with “instance of (P31): human (Q5): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P131#Conflicts with P31, search, SPARQL
Conflicts with “instance of (P31): Wikimedia disambiguation page (Q4167410): this property must not be used with the listed properties and values. (Help)
List of violations of this constraint: Database reports/Constraint violations/P131#Conflicts with P31, hourly updated report, search, SPARQL
Conflicts with “instance of (P31): Wikimedia category (Q4167836), Wikimedia template (Q11266439), Wikimedia module (Q15184295): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P131#Conflicts with P31, SPARQL
Item “instance of (P31): Items with this property should also have “instance of (P31)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P131#Item P31, search, SPARQL
Item “country (P17): Items with this property should also have “country (P17)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P131#Item P17, search, SPARQL
None of Earth (Q2), rural settlement in Russia (Q634099): value must not be any of the specified items.
Replacement property:
Replacement values: (Help)
List of violations of this constraint: Database reports/Constraint violations/P131#none of, hourly updated report, SPARQL
Property “country (P17)” declared by target items of “located in the administrative territorial entity (P131): If [item A] has this property with value [item B], [item B] is required to have property “country (P17)”. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: undersea landform (Q55182671)
List of violations of this constraint: Database reports/Constraint violations/P131#Target required claim P17, SPARQL, SPARQL (by value)
Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P131#Scope, SPARQL
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P131#Entity types
  Value Hokkaido (Q35581) will be automatically replaced to value Hokkaido (Q1037393).
Testing: TODO list
  Value Kanto (Q1657833) will be automatically replaced to value Kanto (Q1657833) and moved to location (P276) property.
Testing: TODO list
  Value Johto (Q607459) will be automatically replaced to value Johto (Q607459) and moved to location (P276) property.
Testing: TODO list
  Value Hoenn (Q872285) will be automatically replaced to value Hoenn (Q872285) and moved to location (P276) property.
Testing: TODO list
  Value Sinnoh (Q603624) will be automatically replaced to value Sinnoh (Q603624) and moved to location (P276) property.
Testing: TODO list
  Value Hisui (Q108151641) will be automatically replaced to value Hisui (Q108151641) and moved to location (P276) property.
Testing: TODO list
  Value Unova (Q4843341) will be automatically replaced to value Unova (Q4843341) and moved to location (P276) property.
Testing: TODO list
  Value Kalos (Q15132899) will be automatically replaced to value Kalos (Q15132899) and moved to location (P276) property.
Testing: TODO list
  Value Alola (Q25594375) will be automatically replaced to value Alola (Q25594375) and moved to location (P276) property.
Testing: TODO list
  Value Galar (Q61951161) will be automatically replaced to value Galar (Q61951161) and moved to location (P276) property.
Testing: TODO list
  Value Paldea (Q113403829) will be automatically replaced to value Paldea (Q113403829) and moved to location (P276) property.
Testing: TODO list
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Archive edit

Older discussions archived under Property talk:P131/Archive.

Something's broken edit

Whenever I try to add more than two claims with this property, I get this error. Refreshing the page causes the property to work normally. Although I can obviously easily work around this, it's a quite annoying issue. Anyone know what causes this? TCN7JM 05:03, 23 January 2014 (UTC)Reply[reply]

I guess, it is bugzilla:58394 --Pasleim (talk) 07:58, 23 January 2014 (UTC)Reply[reply]
Alright, so this was already known. Thanks. TCN7JM 13:10, 23 January 2014 (UTC)Reply[reply]

administrative unit edit

Regarding "unit"

Regarding "division"

  • "division" is also problematic, as there is division (Q5284423).
  • could refer to a system/hierarchy, as explained above

Maybe it is better to have:

  • P131 - is in the administrative entity
  • P132 - type of administrative entity
  • P150 - contains administrative entity

since that is more consistent in the use of the noun. Androoox (talk) 11:53, 25 January 2014 (UTC)Reply[reply]

This looks more like grammar than semantic, or am I missing something? -- Lavallen (talk) 17:16, 25 January 2014 (UTC)Reply[reply]

is in the administrative-territorial entity edit

The current English label is "is in the administrative-territorial entity". Probably a lot of discussion happened but this label just makes me cry. It seems to be a label designed by a committee. Isn't something more elegant possible? Multichill (talk) 15:29, 17 February 2014 (UTC)Reply[reply]

Target edit

Please change "target item must have", "to target item must be an instance of a subclass of administrative division (Q56061)", i.e. claim[31:(tree[56061][][279])]. There are more than 1 million items in that "instance of/subclass of" tree. "Type of" is badly maintained. Tamawashi (talk) 15:00, 5 July 2014 (UTC)Reply[reply]

How to separate different-level administrative units edit

A lot of location are part of several administrative units. For instance Versailles is situated in the region of Île-de-France, in the département of Yvelines and in the arrondissement of Versailles; and it is part of the kantons of North, North-West and South Versailles. At least it is not easy to ask electronically in which département or arrondissement because there is no type given. If you ask in a wiki for {{#property:P131}} then you will get département of Yvelines, kanton of Versailles-Nord, kanton of Versailles-Nord-Ouest, kanton of Versailles-Sud, département of Seine-et-Oise which is not useful. --RolandUnger (talk) 06:42, 6 November 2014 (UTC)Reply[reply]

The item you mention seems to be misusing "canton" values, as its not situated in one of the cantons. Generally, one would only add administrative divisions that include the item. For subdivisions, there is another property. shows you in which department/region/country/continent/planet Versailles (Q621) is located. To do the same at Wikipedia, you will need to wait for queries. --- Jura 06:51, 6 November 2014 (UTC)Reply[reply]
This is currently not possible to show "department: Yvelines" in a Wikipedia infobox, but it will be once bugzilla:47930 is solved (the type of administrative division should be provided in the item's instance of (P31) or P132 (P132)).
By the way statements like "Versailles: P131: canton de Versailles Nord" appear to be based on the naive assumption that there is a neat and tidy commune < canton < arrondissement hierachy even though the canton de Versailles-Nord is located Versailles, not the other way around... But I think this is a separate, and structurally more complex, isssue. --Zolo (talk) 09:43, 6 November 2014 (UTC)Reply[reply]
I agree, let's think about the administrative organization of every country and let's create a detailed model of use for every single one.
I added some instructions here for Spain. Please, feel free to improve them and to add your countries' ones. --abián 12:39, 12 September 2016 (UTC)Reply[reply]

Which items should have this property? edit

In the Help here and here, I can only find examples of a territorial entity inside another territorial entity. So now I wonder if it is appropriate to add the Property "located in the administrative territorial entity (P131)" to an item such as a museum, an airport or a building (which I did, but it's better to stop now than later if I am wrong). - Fabimaru (talk) 20:06, 24 May 2015 (UTC)Reply[reply]

sure. --- Jura 20:14, 24 May 2015 (UTC)Reply[reply]
Jura: Do you mean "sure it is appropriate for a museum"? If it is the case I will modify the help page. - Fabimaru (talk) 20:17, 29 May 2015 (UTC)Reply[reply]
Some of the properties listed in the first one in the "location" section can apply to any item that has a location. Not that it's not included in the more specific "Administrative territorial entity" one. That list can only hold one example anyways. We can add one to Property:P131 instead. The Russian Infobox monument template seems to make use of the property. --- Jura 20:50, 29 May 2015 (UTC)Reply[reply]
Thank you a lot, with the examples I find it clear. - Fabimaru (talk) 10:06, 30 May 2015 (UTC)Reply[reply]
But now the next step is that the property is added to a painting which is in a museum which is in a part of Madrid. Wouldn't it be enough that the painting is in the Prado? If properties are transitive, then an engine would be able to confer that (as the Prado is in that district) the painting is as well (when it is not temporarily in an exhibition elsewhere, or in restoration, or in a depot).
I do not understand what Jura means with 'some of the properties listed in the first one in the "location" section'. Does s/he mean the example Eiffel Tower (Q243)Paris (Q90) in the blue property description, or the property constraint about geographic location (Q2221906)? The constraint says that the item has to be a location, while the description says that the domain should be geographical feature (Q618123), which is a subclass of geographic location (Q2221906). Both mean that this property should be used only on items which are a location, not in items which have a location, like Jura seems to think. Of course we can change the domain and constraint if we wish to, but perhaps there should be some more discussion first. Bever (talk) 23:20, 8 June 2015 (UTC)Reply[reply]
The value (the item the property links to) for P131 should always be an administrative territorial entity but the subject (the page that uses the property) can be anything that "is in that administrative territorial entity". Personally I would say "the painting is in the Prado" and "the Prado is in Madrid" but not "the painting is in Madrid". Joe Filceolaire (talk) 19:18, 22 September 2015 (UTC)Reply[reply]
But if "the painting is in Prado" and ("Prado is in Madrid" & "Prado is in the neighbour city of Dirdam") but the painting is only in "Prado, Madrid" and not in "Prado, Dirdam"? -- Innocent bystander (talk) 09:02, 23 September 2015 (UTC)Reply[reply]
Paintings are movable objects. So they are not directly comparable to the samples given by Fabimaru. --- Jura 09:31, 23 September 2015 (UTC)Reply[reply]
Also non-movable objects can have such problems. P131 is not as transitive as it looks. It is only in a very narrow range of administrative units such hierarchy is simple where I live. In fact, it is only the relation Municipality->County who is transitive, and always have been. -- Innocent bystander (talk) 12:52, 23 September 2015 (UTC)Reply[reply]

Too strict categories edit

I want to use the category: Budapest XIII. kerület (XIIIth district) generally. There are pervously created categories that are too strict; e.g. a simple street of this district or schools in the district. How can I create the gerenral category? Jzana (talk) 13:48, 7 July 2015 (UTC)Reply[reply]

I'm not sure if I understand your question, but the sample at Q141747#P131 for a street in Paris illustrates that the street can be in "Paris" and one or several "arrondissements". If one isn't sure about the arrondissement, one can just add it to "Paris" to begin with.
If items (we don't use categories here) for districts of Budapest are missing (check Special:WhatLinksHere/Q851110, use Special:NewItem. --- Jura 14:00, 7 July 2015 (UTC)Reply[reply]

Administrative subdivisions of England edit

I've been trying to work out what should be the main types of item included in the P131 hierarchy for England -- ie what type of items in England would it be best to allow to be the objects of a P131 statement.

In particular:

  • Is it best that only areas with a real administrative significance are included in the P131 backbone -- ie to leave out of the structure areas with an exclusively statistical purpose like some NUTS areas?
  • What to do with traditional English counties, that many people would consider as the most important division that a place was part of, even though they now have little administative significance, and (in a few instances) do not nest cleanly, either above or below, into the current structure of principal administration?

Further discussion at:

Jheald (talk) 22:15, 27 October 2015 (UTC)Reply[reply]

Events edit

Just to be sure: P131 should not be applied to indicate the location of an event, right? Michiel1972 (talk) 08:31, 27 August 2016 (UTC)Reply[reply]

In most cases location (P276) is probably more suitable, but located in the administrative territorial entity (P131) is not incorrect and should not be removed. Multichill (talk) 08:37, 27 August 2016 (UTC)Reply[reply]
I suggest to use only location (P276) for events and to move located in the administrative territorial entity (P131) claims to location (P276) claims. --Pasleim (talk) 08:43, 29 August 2016 (UTC)Reply[reply]

located in present-day administrative territorial entity edit

Given that there is now a constraint on P131 that the things it connects should be "contemporary", ie both should have coexisted at some point in time, avoiding anachronism, I have proposed a new property "located in present-day administrative territorial entity", to relate historical administrative units to those in the present. Jheald (talk) 08:47, 21 February 2017 (UTC)Reply[reply]

UK overseas territories edit

I've been wondering how to handle these. It's fairly easy to say that (eg) Stanley (Q12245) : located in the administrative territorial entity (P131) : Falkland Islands (Q9648). But what should we do for Falkland Islands (Q9648) itself? Some BOTs have located in the administrative territorial entity (P131): British overseas territories (Q46395), which doesn't make much sense - there isn't a geographical entity called "British Overseas Territory" that they're part of. Likewise, we probably shouldn't use located in the administrative territorial entity (P131):United Kingdom (Q145) (as is the case for Gibraltar (Q1410)) because they're not really part of it in that way. Thoughts? Andrew Gray (talk) 22:13, 4 May 2017 (UTC)Reply[reply]

Looked at Isle of Man (Q9676) and it's incorrectly located in the UK. Multichill (talk) 14:40, 5 May 2017 (UTC)Reply[reply]

Old / past tense edit

This is for the present administrative entities, as the name suggests. I would have expected another for older / defunct / past administrative entities? eg Amlwch Community (Q24717063) 's present administrative entities can / should only be Ynys Mon. The old administrative entity was Gwynedd. The new<Wikidata:Property proposal/located in present-day administrative territorial entity> would be better called <Wikidata:Property proposal/historically located in the past administrative territorial entity> ie one for the past and one for the present. The problem with mixing them up on just one can be seen here (under Gwynedd) where we find that Amlwch is located in two counties! Llywelyn2000 (talk) 09:03, 14 June 2017 (UTC)Reply[reply]

It is solved by using appropriate ranks and qualifiers. --Infovarius (talk) 22:31, 14 June 2017 (UTC)Reply[reply]

Why conflicts only with instance of (P31) business (Q4830453) and not something broader? edit

After my mass addition of locations from GRID quite a few people complained that I should have used headquarters location (P159) instead. I used P159 only for companies because I was aware of the constraint on this page, and used P131 for the rest by default (most of them are organizations, but not all: see the constraints violations report).

Strakhov, Pigsonthewing and I were wondering why the constraint is specifically for companies, and not something broader like organization (Q43229)? Should we update the constraint and maybe migrate existing claims on the relevant items to P159? (Pinging ArthurPSmith for the GRID import, Infovarius and Asqueladd who reverted some of my edits.) − Pintoch (talk) 22:48, 20 June 2017 (UTC)Reply[reply]

In my opinion all organizations (legal entities) should have P159 (and suitable qualifiers) and not only companies. Problem is that for many organizations items about legal entities and its main building are mixed into one item.--Jklamo (talk) 23:04, 20 June 2017 (UTC)Reply[reply]
You may then turn into the problem that a City, Municipality or Parish also can be an organization. Some of the services I buy from my municipality, I could also buy from private companies. The VAT-number of my municipality is SE212000242901. A strange thing is that its seat is located in itself... -- Innocent bystander (talk) 08:25, 21 June 2017 (UTC)Reply[reply]
That conflates the place with the organisation that runs the place. The need separate items; as we have for Birmingham (Q2256) and Birmingham City Council (Q4916650), for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:48, 21 June 2017 (UTC)Reply[reply]
A Swedish Municipal Council has the same relation to the Municipality as the General assembly of General Electric has to General Electric. The Municipal Council in Sweden can therefor in legal terms not fully be described as an organization. It is the Municipality who has the VAT-number(s), not the Council. A committee of the council gives instructions and oversight the work of the white-collar workers I buy services from. But the white-collar workers are not a part of the Council. -- Innocent bystander (talk) 10:27, 21 June 2017 (UTC)Reply[reply]
Innocent bystander. I find this issue fascinating and much underdeveloped in Wikidata. In Spain for example, I think the ayuntamiento (Q22996476) (broader than the elected body town council members (Q26237665)) is the pertinent juridical person (Q155076) and organization (as subclass of public law corporation (Q20014246) and representative of the local entity municipality of Spain (Q2074737).--Asqueladd (talk) 11:35, 21 June 2017 (UTC)Reply[reply]
What is the lowest administrative division depends on what you are administrating. The cultural heritage sites are organised by Civil parishes. Censuses by District and local autonomy by Municipalities. The police has today County as the lowest level. The Municipalities can thereafter divide their work in smaller entities. But my municipality is already so small that it instead cooperate with its neighbours when it comes to such things as firefighting and tourist information. Business development is today transferred from the Counties to the County Councils. (And the County Councils is not a Council, it is a higher level Municipality, sometimes called Regions.) Health care is the main issue for the County councils/Regions. Some of these has a elected body and a board, some not. A County has a board and a Governor. But the Governor is installed by the national Government, not by local elections. Civil parishes used to have (a sort of) council, but not today. Parishes still have Councils, but they are today only related to the Lutheran church, nothing else. -- Innocent bystander (talk) 16:02, 21 June 2017 (UTC)Reply[reply]
It's obvious to me it's a silly self-limitation that it should be opened to subclass of organization (and at the very very very least as compromise temporal option including (but not limited to) subclass of (P279) of non-profit organization (Q43229) such as voluntary association (Q48204) and foundation (Q157031) aside from the "profit"-driven business (Q4830453)). We should work with the ontology of the legal form of organization (Q43229) in par with country-regulation. Similarly (although OT, working in it can give us a clear picture of casuistry (Q845694)) the subclass of (P279)-business (Q4830453) constraint should also equally be opened to subclass of (P279) of juridical person (Q155076) in the legal form (P1454) property, too. In short: The constraints should be ultimately limited to: an item with a headquarters location (P159) statement has to be a instance of (P31) of organization (Q43229) (or subclass of (P279) of) & an item with a located in the administrative territorial entity (P131) statement has to be a instance of (P31) of geographical feature (Q618123) (or subclass of (P279) of).--Asqueladd (talk) 09:22, 21 June 2017 (UTC)Reply[reply]
And take for instance Caja Madrid (Q1026056). Originally a savings bank (Q157963) it became a foundation (Q157031) in 2012 after a banking crisis. Since foundation (Q157031) is not a subclass of (P279) of business (Q4830453), should it have both statements located in the administrative territorial entity (P131) and headquarters location (P159)? Granted at some point authority control will bissect it into separate items, but I guess approaching a foundation (Q157031) and a business (Q4830453) in such a disparate way is not the way to go.--Asqueladd (talk) 10:19, 21 June 2017 (UTC)Reply[reply]
  • personally I think this discussion and attempt at enforcing different geographic location constraints based on P31 values here is futile. Some companies are very geographically limited - a specific local restaurant, hotel, bank, factory, etc. The same goes for many things we classify as "organizations" - specific schools and colleges, research institutes, hospitals, observatories, government facilities etc. etc. Location is a key property of many organizations that helps distinguish them from other entities that can have very similar names (how many "St. Mary's Hospital"'s are there?) These definitely should have coordinate location (P625) directly on the item, as there is one physical location they exist at and it allows somebody near that place to see - look, this institute, this restaurant, etc. is near me! For these I would also argue located in the administrative territorial entity (P131) is right - it tells you the city and helps with that disambiguation. But for many other organizations - including multinational corporations, international associations, intergovernmental bodies, etc. located in the administrative territorial entity (P131) doesn't make a whole lot of sense, but there (usually) is some location that makes sense as a headquarters location (P159). So - why not be flexible here? Unless somebody can come up with clearer criteria than have been proposed so far for distinguishing the one set of organizations from the other? ArthurPSmith (talk) 14:56, 21 June 2017 (UTC)Reply[reply]
Even in each particular case it can be difficult to decide. What if some research institute builds second building quite far from original place? Should we use 2 coordinates or already headquarters location (P159)? What if some university places itself in some large area, may be not simply connected? Can we use some bigger located in the administrative territorial entity (P131)? --Infovarius (talk) 13:00, 23 June 2017 (UTC)Reply[reply]
OK, thanks a lot to you all… I agree constraints might not be a good solution for a subtle problem like this one. − Pintoch (talk) 15:25, 23 June 2017 (UTC)Reply[reply]

Former administrative units edit

Is there any means to give for some currently existing object or some currently existing administrarive unit (eg. a village) the information that it is situated in the area of some former administrative unit (eg. "former municipality of Finland")? I am not very acquinted with the whole structure of wikidata and I will have no time to get acquinted with it in near future, so I ask it here instead of trying to find the answer myself.--Urjanhai (talk) 15:23, 9 July 2017 (UTC)Reply[reply]

For a case where this would be needed, see: Talk:Q21130185.--Urjanhai (talk) 15:28, 9 July 2017 (UTC)Reply[reply]
I don't quite get the purpose of Q21130185 as any village was sometimes in the past in a former administrative unit.
For a place, you can include former administrative units, either with P131 (sample: Q270#P131, current has "preferred" rank ) or, if it's only approximate, territory overlaps (P3179). The later is hardly used as of today (12 uses).
--- Jura 15:50, 9 July 2017 (UTC)Reply[reply]
Yes, only recently founded villages can not be located in a former administrative unit. In Järna (Q1456393) you see that Järna has been located in Södertälje Municipality since 1971. Before that it was located in "Järna Municipality." All Swedish municipalites were reorganised in the 1970's so all Swedish villages older than 50 years has been located in more than one municipality in it's lifetime.
The more tricky things comes when you have to handle former Finnish Municipalities who today are located in Russia. When they existed, they were a part of Finland, they were never a part of USSR, since they were dissolved when the peace tract was signed. The area of those former municipalities are today located in some Russian administrative units. We have some property to describe that, but I do not remember which. -- Innocent bystander (talk) 16:01, 9 July 2017 (UTC)Reply[reply]
Another problem is when items are described both as a municipality and a populated place. Many articles on Wikipedia has this problem. They describe both a Municipality and a Populated place with the same name. Based on the item, it looks like Töysä (Q6168) is such an example. But when I machine-translate the beginning of the Finnish article, it looks like it is only about the municipality.
An example of an article with large such problems is Trondheim (Q25804). The item describes it as a municipality (and a city). But what then about Trondheim municipality (Q1324436)? We then have two items about a municipality named Trondheim. -- Innocent bystander (talk) 16:56, 9 July 2017 (UTC)Reply[reply]
fi:Töysä is indeed a former municipality, now there is fi:Töysän kirkonkylä which is a village, part of fi:Alavus. Stryn (talk) 17:26, 9 July 2017 (UTC)Reply[reply]
Thanks, this was helpful. The purpose for this is same as in the swedish case: To give the location in an understandable manner the former municipality is usually more informative than the current alone. In Sweden the municipality system was transoformed in a one big rteform in 1970's, in Finland the same is now happening in small bits but where changes have been made, the result will be the same: to give the location in an understandable manner, you usually need the former municipality as well because very often only the name of the current municipality tells little more than nothing about the more exact location.--Urjanhai (talk) 17:08, 9 July 2017 (UTC)Reply[reply]
About other details (case Töysä) those more acquinted with both wikidata and the finnish conditions should be consulted, eg. User:Stryn, User:Susannaanas, User:Zache. Probably in articles about municipalities some attributes or whatever should be removed.--Urjanhai (talk) 17:12, 9 July 2017 (UTC)Reply[reply]
But if the wikidata item about municipality of fi:Töysä should not handle the populated place, then there is fi:Töysän kirkonkylä which seems to be about the populated place (= fi:Taajama, sv:Tätort) which as a real world statistical object has been given the name "Töysän kirkonkylä" (which would translate as "Töysä kyrkby" in swedish) according to the naming conventions used to name the statistical populated places in the official sources). (see fi:Luokka:Suomen taajamat) --Urjanhai (talk) 17:26, 9 July 2017 (UTC)Reply[reply]
Wikidatian at work!
We can often not do very much about that Wikipedia articles mix municipalities and populated places. We can put articles about "only the populated place of Trondheilm" in one item, "the municipality of Trondheim" in one item and the "mixed articles" in one item. But my experience is that users tends to merge such work sooner or later. It soon becomes a work of Sisyphos! We have split the subjects Swedish municipalities and populated places in Sweden well in svwiki, but have not always done so in other nations. Now the Lsjbot-project has made a mess of everything... I have tried to split up "Malmö tätort" from "Malmö kommun", but people keeps adding such things as coat of arms, sister citys and mayors to the tätort-item just because they think it is the right thing to do. -- Innocent bystander (talk) 08:21, 10 July 2017 (UTC)Reply[reply]
I guess that one part of the problem is that users may not always be aware well enough what actually is the meaning of the concept "populated place" in wikidata even if they are aware about the basic categories at least in their own wiki. In fi-wiki at least the distinction is maintained carefully in the article space and categorioes (at least concerning Finland, an probably also Sweden) but wikidata users from other countries or even the same country may not always be fully aware of the exact meaning of such concepts as "populated place" or its counterparts in different langugeses (actually I do not know myself, what would be a correct translation in Finnish for it) and what content in eachh wiki goes under what wikidata concept. This could perhaps be helped by Wikiprojects dedicated to clean up certain sets of articles in wikidata like "populated places in Finland" or "Municipalities in Finland" etc. At the same time experienced users could get acquinted with wikidata and its possibilities.--Urjanhai (talk) 10:58, 13 July 2017 (UTC)Reply[reply]
Ping still User:Stryn, User:Zache, User:Susannaanas, User:Raksa123.--Urjanhai (talk) 11:02, 13 July 2017 (UTC)Reply[reply]
Töysän kirkonkylä is a populated place/human settlement, urban area (taajama/tätort) and probably unofficial village. Töysä(n kunta) is a former municipality, but should not be considered as human settlement. Töysä(n kunta) is also said to be "former municipal village of Finland" ("village situated in a former municipality in Finland"?) which does not make any sense. There should be created a new property, perhaps "Populated places in the former municipality of Töysä" which would be applied to Töysän kirkonkylä. It would be best to use these concepts right first in Wikipedia. For example fi:Loviisa handles mostly things located in the administrative center fi:Loviisan keskustaajama which quite well overlaps the city's administrative area before the latest municipal merger. Raksa123 (talk) 12:01, 13 July 2017 (UTC)Reply[reply]
To describe that "Töysän kirkonkylä" was located in "Töysän kunta" until 2013, you can add "P131:Töysan kunta" with the qualifier "end date:2013-01-01" (or 2012-12-31 if that fit better). -- Innocent bystander (talk) 12:51, 13 July 2017 (UTC)Reply[reply]
Yes, that is how I have dealt with the municipal mergers in Finland. I would also set the "deprecated rank" for the former municipality and "normal rank" for the current one. See Q14116178 for example. ––Apalsola tc 13:23, 21 July 2017 (UTC)Reply[reply]
But still the property " Suomen entisen kunnan kylä (Q21130185) " [1] seems to to be a total misconseption that shuold be corrected. It is NOT a "historiallinen hallinnollinen alue" ("a historical administrative unit") but instead it simply means that a currently existing village in Finland in the the current area of some municipality happens to be situated in the area of some former muicipality that currently has ceased to exist. So the village itself is NOT a historical adminisdtrative unit but the former municipality is a historical administrative unit (and besides, often a toponym taht is still used actively). To avoid misconseptions this should be corrected. Is it the only way to removee the whole property as irrelevant? That this property has been created in wikidata with a misunderstood meaning probaly is simply due to some random error in translation. The correct translation for Fi:Luokka Suomen entisten kuntien kylät wuold be simply "Villages of finland by former municipality". This DOES NOT make the villages "historical administrative units" because it is the former municipalities that are "historical administrative units", not the villages. (Excliuding the areas ceded to soviet union after World War II, where indeed both the municipalities and villages really are "former administrative units".)--Urjanhai (talk) 10:56, 10 August 2018 (UTC)Reply[reply]

Incorrect inverse property mentioned edit

Should contains the administrative territorial entity (P150) be really the inverse property to located in the administrative territorial entity (P131)? located in the administrative territorial entity (P131) should links to objects - houses, structures, natural features etc. For administrative subdivisions of administrative units, has part(s) (P527) and part of (P361) should be appropriate properties. Btw, the real inverse property to located in the administrative territorial entity (P131) is missing: we need a property for list of objects located in the territorial unit and a property for a number of objects located in the territorial unit (number of houses, number of adresses etc.). --ŠJů (talk) 13:35, 31 August 2017 (UTC)Reply[reply]

has part(s) (P527) and part of (P361) are a little to generic to be useful here. -- Innocent bystander (talk) 15:52, 31 August 2017 (UTC)Reply[reply]

Hierarchical ambiguity edit

The instructions above state "You only need to add the most local admin territory". In a strict hierarchical pyramid, specifying the most local territory clearly identifies all higher levels: an item is in ward A, and we know ward A is in municipality B is in county C is in province D is in region E. But what if municipality B extends into both county C and county C1? By specifying the ward for an item, then we cannot say which county the item is in. For example, Old West Salem City Hall (Q175747) has the statement located in the administrative territorial entity (P131):Salem (Q43919). But Salem (Q43919) in turn is in both Marion County (Q484408) and Polk County (Q495393): so which county is Old West Salem City Hall (Q175747) in? (IRL it's in Polk County.) Is there a recommended method to resolve this ambiguity? — Ipoellet (talk) 05:46, 3 January 2018 (UTC)Reply[reply]

But I think that is quite a dangerous approach, because it means that if eg somebody uses P131* for one of the smaller territories, following up the ambiguous chain may lead to some answers that are completely false.
An alternative might be to forbid use of P131 in such ways, and instead use territory overlaps (P3179) for the relationship; giving a located in the administrative territorial entity (P131) to a higher level, that was unambiguous.
So eg forbid Stockton-on-Tees (Q894094) (en:Borough of Stockton-on-Tees) located in the administrative territorial entity (P131) County Durham (Q23082) and North Yorkshire (Q23086), and only accept Stockton-on-Tees (Q894094) located in the administrative territorial entity (P131) North East England (Q47983)
But one would need to then also supply P131s at the next lower level down, so that a query eg for all parishes in North Yorkshire still gave a full list.
It would also mean that Stockton-on-Tees wouldn't appear at all in a search for boroughs in County Durham or North Yorkshire (as opposed to appearing twice, as it does at the moment).
It would be good to get wider input on this, but I'm not sure if there's an appropriate active WikiProject to ping. Jheald (talk) 02:38, 19 February 2018 (UTC)Reply[reply]
A parallel approach with some similar effects would be to add a single value constraint to P131.
Compared to the above, that would allow multiple values of P131 distinguished by applies to part (P518) -- but only as subsidiary statements, ranking below a single preferred P131, that all the parts were part of.
Unfortunately, a current query finds 270,000 items with more than one P131:
Would be good to know how many of those are/aren't because the two items are vertically related in the same hierarchy, but I haven't been able to get a query to do that within the time limit. Jheald (talk) 14:56, 19 February 2018 (UTC)Reply[reply]
I suppose many of these cases are because P131 is changeable along the time, so items contain whole timeline of hierarchy. --Infovarius (talk) 00:24, 21 February 2018 (UTC)Reply[reply]

Usable for School Districts edit

I'd like to import High School infobox, especially the fact that a given school belongs to a school district. Is that the right property to describe that, or is a specific property needed ? Teolemon (talk) 12:56, 13 May 2018 (UTC)Reply[reply]

ATE located in two different higher level ATE edit

User:Jmabel wrote in project chat [2] that Klondike Gold Rush National Historical Park (Q1774856) is located in two US states. If one only wants to name one higher level entity, it would be USA. The park is an object managed by federal institutions. 09:50, 27 June 2018 (UTC)Reply[reply]

Why require country too? edit

Whenever I add a P131 to an item, a warning tells me:

An entity with located in the administrative territorial entity should also have a statement country.

What is the point of that? The location I entered already has a country, so adding a country to the item would be duplicating information.

Or are there cases where the country is different from the country of the current P131?

Cheers! Syced (talk) 11:08, 20 July 2018 (UTC)Reply[reply]

If you removed the country from your item because the parent had it, you would probably remove it from the parent because the grandparent had it. A lot of queries are by country alone, and do not want to have to travel a long way up a tree to find the country. --99of9 (talk) 12:34, 17 August 2018 (UTC)Reply[reply]
The country must be in the furthest ancestor, repeating it in all children is a huge waste of time, as well as a source of inconsistencies. SPARQL is designed to go "up the tree", and very efficient at that. The community has already spoken, actually:
Anyone please remove that counter-productive rule, thanks! :-) Syced (talk) 07:41, 31 March 2019 (UTC)Reply[reply]
@Syced: your "valid" query lists items multiple times - just check how many results you get if you add the DISTINCT keyword. The reason why we encourage to add country (P17) in addition to located in the administrative territorial entity (P131) is that it is more efficient than having to follow a chain of located in the administrative territorial entity (P131). This does not affect much simple queries like yours, but in more complex scenarios this can be life-saving. It also helps when retrieving info from sister projects. − Pintoch (talk) 13:18, 31 March 2019 (UTC)Reply[reply]
Oops, I had forgotten the DISTINCT keyword indeed, you are right! But I stand by my position that redundancy is bad. Nobody would go around adding "instance of animal" to all humans because it makes their query a bit simpler (you get the idea). Syced (talk) 13:31, 31 March 2019 (UTC)Reply[reply]
I think you argued the same for P17 in the past and then when asked to provide a working query you realized that it might only work in a Wikibase with fewer items. --- Jura 13:45, 31 March 2019 (UTC)Reply[reply]

@Syced, 99of9, Pintoch, Jura1: This redundancy is simply unsystematic. If the state is to be listed in such a redundant way, then all other levels of administrative division that any filter might need for something would have to be listed similarly separately – municipality, city, district, region, state, land, province etc. The main sense of this "universal" property P131 is that all levels of territorial division can be chained and do not have to be stated redundantly.

An another problem is that we do not yet have a sufficiently effective tool (commonly usable query) in Wikidata or subsequent sister projects that can quickly extract a certain higher level of administrative unit from the chain for any item using a simple function. This problem should be addressed very urgently if Wikidata is to have a system and not just be a chaotic collection of random data. Maybe "virtual properties" (properties which would be not filled directly but computed or mirrored from other properties) would be a fitting solution for this problem as well as for many similar problems (e.g. automatic mirroring of reciprocal properties etc.). I imagine inbuilt functions/queries that could be called in a similar way as regular filled-in properties. Unfortunately, in the 9 years of Wikidata existence, we have not moved very far, and several basic conceptual issues have not yet been resolved. For the future, it should be possible to calculate the affiliation of a certain point to its administrative and geographical units (of various types) defaultly from coordinates, but Wikidata is not yet able to work with spatial data (and who knows whether they will ever be able to). --ŠJů (talk) 11:24, 13 August 2021 (UTC)Reply[reply]

City: ATE or not ATE edit

We have one of the fundamental constraints that value-type constraint (Q21510865) should be instance of (Q21503252) of administrative division (Q56061). And we have ~300000 objects which P131 in some city (Q515). Or even more:

#Number of objects inside any class of cities
SELECT (COUNT(?item) AS ?count) WHERE {
  ?item wdt:P131* ?city.
  ?city wdt:P31/wdt:P279* wd:Q515.
Try it!

And now we have an initiative of removing city (Q515) from ATE class tree! This means that we have these 2,3 mln constraint violations. The problem. --Infovarius (talk) 16:42, 9 August 2018 (UTC)Reply[reply]

I strongly advice not to use city (Q515) at all. "City" is a term with a changing meaning from country to country and from culture to culture. It is also factual wrong to say that each city is a administrative division (Q56061). It is better to use more specific and better defined subclasses of city (Q515), e.g. city of Switzerland (Q54935504) or city in the state of New York (Q15063611). Depending on the jurisdiction, such subclasses can then be subclasses of administrative division (Q56061). In fact, a majority of city items are already subclass of administrative division (Q56061) without the need of the falsy statement city (Q515) subclass of (P279) administrative division (Q56061) [3], so the above mentioned numbers need to be corrected. --Pasleim (talk) 18:43, 9 August 2018 (UTC)Reply[reply]

is a suburb an administrative territorial entity? edit

Let's say the administration is actually done at a level above that (the municipality/council/city/etc), but the suburb is a well defined object that stuff gets administered to on the basis that it is a suburb (e.g. each suburb gets a postcode, a library, and a train station), does that count as an administrative territorial entity? --99of9 (talk) 12:39, 17 August 2018 (UTC)Reply[reply]

@99of9: probably not (not in itself at least), but do you have a specific example? Cdlt, VIGNERON (talk) 07:50, 7 September 2018 (UTC)Reply[reply]
Ok thanks. So what is the best property to relate an object to the suburb it is in? --99of9 (talk) 09:19, 7 September 2018 (UTC)Reply[reply]
@99of9: maybe location (P276). Could you give an example? Cdlt, VIGNERON (talk) 15:44, 7 September 2018 (UTC)Reply[reply]

Harmonize the defintion of the property in different languages. edit

Currently there are at least 2 languages (italian and russian, as far as I understand) that specifiy that ONLY the most higher (i.e. datalied) administration unit should be used (i.e., If I say that P131 is Paris, I should not add any of "Ile de France", "France", "Europe"). This specification has a clear sense to avoid stating in P131 something which is obvious and can be determined by the attributes of "Paris". I suggest to add the explicit specification of the mentioned "ONLY" in as much languages as possible.--Ysogo (talk) 10:11, 2 September 2018 (UTC)Reply[reply]

I agree with Ysogo: if we use the highest administration unit, lower units are unnecessary. --Yiyi .... (talk!) 10:26, 2 September 2018 (UTC)Reply[reply]
@Ysogo, Yiyi: interresting but I'm not sure if it's a good idea. The smallest units are also the most prone to change and may be quite unstable. They also could be unknown.
In France, we decided to put all the commune in both the arrondissement and the département, the département is more stable (few change since 1790 while there was a lot of changes for the arrondissements), more well-known (most French citizen are not even really aware that the arrondissement exists). And there is the problem of the cantons who where administration unit before 2015 but not anymore (and canton could be smaller or bigger than the communes, it depends). There is also the problem of the history, different value can have different start time (P580) and end time (P582) that can't be infered.
I agree that "Paris", "Ile de France", "France", "Europe" is bad but in some cases, several value can be useful or even necessary. We should find a wording less restrictive than "only the highest level", maybe "preferably the most precise level" ("high" is strange too by the way, for me the highest level is the biggest, eg. the country not the smallest).
Notification for @Сидик из ПТУ: too.
Cdlt, VIGNERON (talk) 08:50, 6 September 2018 (UTC)Reply[reply]
  • Why it so important for Russian community to specify only one, closest to item located in the administrative territorial entity (P131)? Because we have an algorithm which based on this rule and provides full geo-sequences to Wikipedia infoboxes. For example, Beauvais (Q174257), arrondissement of Beauvais (Q534383), Oise (Q12675), Picardy (Q13950), France (Q142) as birthplace of Aristide Bègue (Q4080542). It's weird to specify data in different ways in one database, this is the reason that the algorithm can not work for French personalities. I see this only in France, while Russia, Germany, the United States, Great Britain, everything works and is filled to Wikidata perfectly. As for the cantons, we were previously explained (for example, by Alphos) that this should be specified not as located in the administrative territorial entity (P131), but as territory overlaps (P3179). IMHO, we also we should think about creating a new property like electoral district (P768), but not for personalities, but for human settlements. Сидик из ПТУ (talk) 09:28, 6 September 2018 (UTC)Reply[reply]
    • @Сидик из ПТУ: I understand your needs but couldn't you improve your algorithm ? (the infoboxes on fr.wp works fine even with multiple values) It's a bad idea to always expect one and only one value for a property (in general and for located in the administrative territorial entity (P131) in particular). For instance, for Beauvais (Q174257), I've added qualifiers (because the commune is in the département for a longer time than in the arrondissement), only one value doesn't seem possible (at least I don't see how). For the cantons, globally you're right, some of them must be move to territory overlaps (P3179) (and thank you a lot for moving them!), but maybe not all of them (the situation is very complicated since differents concepts name "canton", since 2014, the canton are only a electoral district but before that they were administrative unit and are perfectly fine in P131, it's even a more précise unit that the arrondissement, sometime more precise than the commune). And I like you idea of a electoral district (P768) but for territories, you should make a proposal to discuss it (I see some possible complication, a place can have like dozens if not hundred of circonscription but it's probably solvable).
      • Why "one and only one value for located in the administrative territorial entity (P131)" possible with any other country, but not with France? Why it can't be like in Chemnitz (Q2795), Mytchenkivska silska rada (Q12123651)? This exception only for France is not caused by anything and is not obvious to the casual user. Moreover, even the French cities are not always specified in the way that you are suggested to do. A more consensus option is to add start time (P580)=1795, end time (P582)=1800 for Oise (Q12675) at Beauvais (Q174257). And where is the 'fine infobox' at fr:Julien Absalon? I don't see region, département or country in his birthplace. Сидик из ПТУ (talk) 14:53, 6 September 2018 (UTC)Reply[reply]
        • @Сидик из ПТУ: It's maybe possible for France but it's very difficult to determine what is the closest unit, for a long time, the canton was the closest unit but not anymore, now it's the arrondissement. But nobody knows or care about the cantons or arrondissements. That is why we choose to put the departement which is the relevant unit for P131. « end time (P582)=1800 for Oise (Q12675) at Beauvais (Q174257) » is plain wrong, that make absolutely no sense, do you have any source to support that? For Julien Absalon, the community clearly don't want the region (wich one?) or the country, but I could ask if the community would want to add the departement or not (probably not) for this infobox. Meanwhile, you can look at fr:Modèle:Infobox Monument, used on fr:Hôtel de ville de Beauvais for instance, the departement and the country is displayed fine. Cdlt, VIGNERON (talk) 07:38, 7 September 2018 (UTC)Reply[reply]
          • OK, maybe French community doesn't want full path for infox's birthplace, but it's consensus for Russian community. You can see that for any other countries periods in P131 means only times when this units were closest. Below you can see my question about what has changed with the role of the cantons in 2014/2015. If only their boundaries have changed, then new ones and old ones must be sent to another property. Сидик из ПТУ (talk) 09:05, 7 September 2018 (UTC)Reply[reply]
            • Yes the French community doesn't want administrative units that nobody - even French people - knows. If the Russian community want the full path, just add it! As I showed you with the other infoboxes (where some administrativ units are kind of relevant), this is possible even with multiple values. And no, in 2013-2015 the boudaries change but the role and definition of the concept canton changed too, that why we have two items : canton of France (Q18524218) (since 2015, electoral subdivision only) and canton of France (until 2015) (Q184188) (before 2015, both administrative and electoral subdivision). Cdlt, VIGNERON (talk) 14:49, 7 September 2018 (UTC)Reply[reply]
It's worse than all you can imagine : in France, two communes may share cantons. That is a part of commune 1 and a part of commune 2 constitute one canton, and the rest of communes 1 and 2 constitute parts or wholes of other cantons. That is the case for Cannes (Q39984), Le Cannet (Q207967), canton of Cannes-1 (Q16627298), canton of Cannes-2 (Q16627301), canton of Le Cannet (Q1306533).
This is one case off the top of my head, but there are a large bunch of others. I could mention Aix-en-Province, which comprises its two cantons in their entirety ; or Reims-8 where two separate parts of the commune of Reims are constitutive of the same canton ; I'm sure with a little time I could find two communes that split two cantons with each other ; the fact is, there is no simple way to normalize the complexity of everything that went wrong in the ugly reality of the electoral and administrative subdivisions of France. On behalf of every frenchman, I apologise. The least hard way to do for now - while making the database still accessible through manageable/comprehensible requests - is by listing the arrondissement, which is reasonably stable. It does not however do much for the communes in COM/TOM, but then again neither does listing the canton ; for those, listing the corresponding COM/TOM is the only way to go. But it poses additional problems : this (abridged) query for extant communes with the corresponding extant départements tends to time out :
see the query
The following query uses these:
  • Properties: instance of (P31)     , located in the administrative territorial entity (P131)     , end time (P582)     
    SELECT  ?commune ?departement WHERE {
      ?commune p:P31 ?communeStatement . # les trucs qui sont potentiellement
      ?communeStatement ps:P31 ?type . # ...un des types autorisés ci-dessous
      VALUES ?type {
        wd:Q484170 # commune française
        wd:Q2989454 # commune nouvelle
        wd:Q22927616 # commune française à statut particulier
        ?communeStatement pq:P582 [] . # mais alors vraiment des communes pur cru, sans date de fin
      ?commune p:P131 ?communeArrondissementStatement . # qui sont dans un arrondissement
      ?communeArrondissementStatement ps:P131 ?arrondissement .
      ?arrondissement wdt:P31 wd:Q194203 .
      FILTER NOT EXISTS { # qui y sont pour de vrai
        ?communeArrondissementStatement pq:P582 [] .
      ?arrondissement p:P31 ?arrondissementExistsStatement . # un arrondissement sans date de fin
      ?arrondissementExistsStatement ps:P31 wd:Q194203 .
        ?arrondissementExistsStatement pq:P582 [] .
      ?arrondissement p:P131 ?arrondissementDepartementStatement . # qui est dans un département
      ?arrondissementDepartementStatement ps:P131 ?departement . 
      FILTER NOT EXISTS { # mais qui y est sans date de fin
        ?arrondissementDepartementStatement pq:P582 [] .
      ?departement p:P31 ?departementExistsStatement . # un département sans date de fin 
      ?departementExistsStatement ps:P31 ?departementType .
        ?departementExistsStatement pq:P582 [] .
      VALUES ?departementType {
        wd:Q6465 #département de France métropolitaine
        wd:Q28332 # département/région ultramarin
Whereas this one does not :
see the query
The following query uses these:
  • Properties: instance of (P31)     , located in the administrative territorial entity (P131)     , end time (P582)     
    SELECT  ?commune ?departement WHERE {
      ?commune p:P31 ?communeStatement . # les trucs qui sont potentiellement
      ?communeStatement ps:P31 ?type . # ...un des types autorisés ci-dessous
      VALUES ?type {
        wd:Q484170 # commune française
        wd:Q2989454 # commune nouvelle
        wd:Q22927616 # commune française à statut particulier
        ?communeStatement pq:P582 [] . # mais alors vraiment des communes pur cru, sans date de fin
      ?commune p:P131 ?communeDepartementStatement . # qui sont dans un département
      ?communeDepartementStatement ps:P131 ?departement . 
      FILTER NOT EXISTS { # mais qui y sont sans date de fin
        ?communeDepartementStatement pq:P582 [] .
      ?departement p:P31 ?departementExistsStatement .
        ?departementExistsStatement pq:P582 [] . # un département sans date de fin 
      ?departementExistsStatement ps:P31 ?departementType .
      VALUES ?departementType {
        wd:Q6465 # département de France métropolitaine
        wd:Q28332 # ou ultramarin
You'll notice it offers more information, runs in about 8 to 10 seconds instead of 20 to 30 (when it doesn't time out), which means it can let us run more complex queries, not to mention request more properties on the same objects as it already does. And it actually lets us runs them, which matters.
Therefore, it was decided that, in order to get to use the data we put in Wikidata, we would add the départements to the communes. It made sense then, and it still does now. You have to keep in mind France has about 36000 communes ; and requesting them all at once can make things go incredibly slow ; adding checks for recent changes (such as new statuses, lost or changed statuses, which occurred in the last eight years), make the requests even more complex ; and the SPARQL endpoint is even less keen on letting us do that. Removing the possibility of requesting the département directly is essentially negating the possibility of using the dataset we've put so much effort in building.
I was working on a nomenclature that would work for the current time and the past few decades (we've had some changes in our legislation recently) a few months back, but my health declined and I've been unable to concentrate on it ; I'd like to point out that having to fix stuff like this did take some of the time and patience I would have otherwise used in finishing that nomenclature : a few random edits like this one are pointless and unjustified, they break uniformity and as such allow for incomplete datasets to be returned by otherwise reasonable queries. I don't pretend to understand how oblasts work, and have worked over the years - but I sure don't pretend to edit their items either. And until you do have a solid grasp of the administrative and non-administrative subdivisions of France and how they interweave, I ask you to stop trying to edit items pertaining to them : cantons aren't administrative subdivisions, for instance.
We lacked territory overlaps (P3179), and I was working on a bot to actually make the transfer of statements from one property to the other, but as I said, my health isn't what I'd like it to be - but please don't make me clean data once more, it's long and tedious, and I'd rather not have to do it again. If you read (some) French, I can give you a link to my blog post on cleanup of cantons on Wikidata, I hope it'll be interesting.
Alphos (talk) 23:02, 6 September 2018 (UTC)Reply[reply]
If we throw out cantons from P131 to P3179 or new electoral property, what problem will remain? Can an arrondissement be in two departments at the same time? Even so, we have an example of North Yorkshire (Q23086), which is partially located in North East England (Q47983), and in Yorkshire and the Humber (Q48063), but human settlements of North Yorkshire (Q23086) don't have multiple P131 (Hambleton (Q1572719), Kirton in Lindsey (Q2338783)). Without the cantons in P131 what need is there to be wiser with France?Сидик из ПТУ (talk) 06:04, 7 September 2018 (UTC)Reply[reply]
@Сидик из ПТУ: if you throw out *all* cantons from P131 to P3179, then you don't respect the rule of "only the closest unit"! Before 2014, cantons are the closest administrative unit in France. Cdlt, VIGNERON (talk) 07:14, 7 September 2018 (UTC)Reply[reply]
Cantons were the closest administrative (not only electoral) unit in France until 2014 (or 2015)? Сидик из ПТУ (talk) 07:23, 7 September 2018 (UTC)Reply[reply]
@Сидик из ПТУ: yes, they were. It's a bit complicated as cantons are not always supra-commmunal, sometimes they are sub-comunnal but still it was an an administrative unit. Cdlt, VIGNERON (talk) 14:36, 7 September 2018 (UTC)Reply[reply]
@VIGNERON: Then why did not you finally return all the cantons to located in the administrative territorial entity (P131) in Beauvais (Q174257)?Сидик из ПТУ (talk) 06:20, 9 September 2018 (UTC)Reply[reply]
@Сидик из ПТУ: because it's very very very complicated (something much more complicated than North Yorkshire (Q23086)). Here (like always for big cities), cantons are subcommunal and fractional, it's not Beauvais who is located in the canton, it's more the cantons who are located in Beauvais. And because I don't know which canton was created where and when (plus, at least 3 cantons miss an item) and finally, I can't find reliable references so I prefer not to add mistake. And all that as someone who know well how administrative unit works in France, imagine for someone who don't know the system in France. Cdlt, VIGNERON (talk) 08:15, 9 September 2018 (UTC)Reply[reply]
It makes us think that the cantons (until 2015, after 2015) can not be regarded as a standard P131-value and should be indicated like postal codes.Сидик из ПТУ (talk) 10:31, 9 September 2018 (UTC)Reply[reply]
@Сидик из ПТУ: yes, that's why you can't use "only the highest level", not for France at least. Cdlt, VIGNERON (talk) 11:06, 9 September 2018 (UTC)Reply[reply]
This is not the reason for a complete mess in P131 for French towns. I repeat, if the cantons are thrown out of P131, then there should be only arrondissements.Сидик из ПТУ (talk) 13:16, 9 September 2018 (UTC)Reply[reply]
@Сидик из ПТУ: no, you are illogical, you can't want "only the highest level" and at the same time want to thrown out the cantons who were the highest level. Besides, "only the highest level" doesn't mean at all "only one value". For the examples you cited « Why it can't be like in Chemnitz (Q2795), Mytchenkivska silska rada (Q12123651)? » these two items do have several values. PS: we don't have items about "towns" in France for Wikidata (or very few and we don't use them), the commune is the most precise and relevant level for France. Cdlt, VIGNERON (talk) 09:41, 15 September 2018 (UTC)Reply[reply]
If the cantons are for P131 then they should be there. If they are not there, then they are not for this. Then we have to work on the usual pattern and the closest P131 it's the arrondissements. "Several values" in Chemnitz (Q2795) and Mytchenkivska silska rada (Q12123651) do not intersect in time and at each moment of time are single. Сидик из ПТУ (talk) 10:35, 15 September 2018 (UTC)Reply[reply]
@Сидик из ПТУ: I'm a bit tired... did you even take a look at how cantons work? We explained you - multiple times - that old canton are administrative unit, no new ones. And a commune can be located in several cantons, so you can't choose "only one highest value", it's just not possible. Cheers, VIGNERON (talk) 10:33, 16 September 2018 (UTC)Reply[reply]
I see that we are walking in a circle… So, either we specify all pre-2015 cantons (one, three, seven, etc.) in P131 for each commune as at Shreveport (Q80517) or we recognize that pre-2015 cantons are not suitable for P131 and work without them, but with arrondissements as the closest suitable for P131 level. It is much more illogical to indicate in the P131 all levels up to the region because of problems with pre-2015 cantons. Look, if there were never cantons, for France, like any other country, only arrondissements would be indicated and we would not have discussed anything here. Сидик из ПТУ (talk) 15:26, 16 September 2018 (UTC)Reply[reply]
Actually cantons were alternate subdivisions of French arrondissements (themselves subdivisions of departments), orthogonal to their divisions into communes (municipalities), until 2015. Since 2015 the cantons are NO longer administrative divisions, but only electoral divisions of departments (no longer of arrondissements).
But still the new electoral cantons can contain municipalities, or part of municipalities, or both, jsut like it was before 2015 (the administrative arrondissements are no longer used to group the new electoral cantons, even if since the reform of cantons for the departemental elections, various departments have restructured adminsitratively their arrondissements: this restructuration of arrondissements was at prefectoral level, a national structure, but had no effect on how departmental and municipal councils work or manage/subdivide their territory, or how they cooperate; but cantons used now only for the departmental elections are only managed at departmental level; and not all France is covered by cantons because there's no departmental council everywhere, notably not in Paris, Lyon and in the Metropole of Lyon, whose elected council has other kinds of electoral "circonscriptions", made instead of municipal arrondissements and/or municipalities).
The departemental arrondissements are slowly disappearing, their administrative role is now very marginal, it's just a helper to locate municipalities and control them by prefectures. Note also that there's not necessarily a single prefecture by department: the prefecture of Rhone is still the same for the new department of Rhone (convered by its departmental council), and it still has two arrondissements in that prefecture: the arrondissement of Lyon covers the metropole, the arrondissement of Villefranche-sur-Saône covers the new department of Rhone. You can see that now arrondissements are actually no longer administrative subdivisions of departments, but only administrative subdivisions of prefectures (for part of their daily job of controlling the municipalities, or for hosting at least one local bureau per arrondissement for residents needing to contact the prefectures for some of their national procedures they can't do online or in their municipalties) and none of them are in charge of managing the new cantons (no citizen has direct relations with cantons, they only know the departemental deputee they elected there, but the elected deputee do not represent their canton but the whole department and citizens can only contact the departmental council for their legal procedures, or start an action to a departmental administrative court, there's no canton-level court since more than one century)!
To be clear: the cantons since 2015 are clearly not the same kind as cantons before 2015, one kind disappeared completely to be replaced by the other kind, and none of them have kept their territory, even if some new cantons share the same name as older ones. Verdy p (talk) 00:34, 10 September 2018 (UTC)Reply[reply]

why is the declaration of P131 (administrative location) incompatible with the declaration of P159 (headquarters location) ? edit

I don't understand why on any data entity, the declaration of « located in the administrative territorial entity (P131) » (a parent territory containing the entity geographically) with is incompatible with the declaration of « headquarters location (P159) » (the seat is usually, but not necessarily, within the territory of the entity, i.e. a child of the entity, not always within it as it is frequently just a single building or room located elsewhere).

See the query SPARQL query here (adjust the value after "LIMIT" in the query to show more if needed): all these many declarations are definitely NOT errors.

You can see that frequently the seat and the administrative location (taken geographically) is the same, but when they are not, there's no necessarily any relation between the two locations of the seat (P159) and the (one or more) locations of the administrative locations (the seat may not even be any where in these locations). This applies to declarations made for entities like administrative/territorial entities (several distinct entities may be within the same or different locations, but still have the same shared seat in one of these locations, or even somewhere else!), or organizations (e.g. professional sport clubs and leagues).

Disconnect completely the declared seat/headquarters from administrative locations of the entity; the seat will have its own separate administrative location by its own declaration, and even if they may be pointing exactly the same target item as locations, they may be specify disconnected locations (one is not required to contain the other). P131 is purely geographic, while P159 gives a business dependency (and what P159 indicates may not even have any actual geographic location, it could be a virtual business existing only on markets, quoted somewhere, with activity somewhere else, and with an official contact or fiscal address located elsewhere, or could be the name of one bureau within a larger organization with multiple establishments).

Even administrative territorial divisions do not necessarily haver their official headquarters located inside the territory they manage, or inside the parent division containing that territory.

This restriction against declarations of P131+P159 for the same item is simply always wrong: : there are about 15000 items correctly specifying the two declarations, which are orthogonal/independant and I see absolutely no usage of this restriction that it would help to fix, and no way to reduce the scope of this restriction, that should be removed, it's just a pollution. Verdy p (talk) 16:40, 4 September 2018 (UTC)Reply[reply]

I'd like to second this - not sure why the constraint says these are in conflict. -- Fuzheado (talk) 20:07, 10 September 2018 (UTC)Reply[reply]
See the discussion on P159 regarding organizations - however, I don't think it's quite so clear-cut: some organizations have dispersed operations so that P131 isn't appropriate, but some are quite localized and I think P131 would be fine. ArthurPSmith (talk) 19:13, 11 September 2018 (UTC)Reply[reply]
@ArthurPSmith: We have operating area (P2541) for indicating the operating locations... --Yair rand (talk) 15:52, 17 October 2018 (UTC)Reply[reply]

Do hamlets count as administrative territorial entities? edit

Hello! I've been working lately on italian churches, and so far I've compiled P131 using not the municipality (comune) but the specific hamlet (frazione) inside the municipality where the church is located (this way, in the infobox on Commons, I had that the church is located in hamlet->municipality->province->region->country, for example commons:Category:Chiesa dell'Immacolata (Piazzo)). A few days ago I've been told this is wrong, and P131 should be only the municipality, whereas hamlets should go in P:P276; then, on Commons this was contradicted.

So the question is: can I put hamlets in P131? If not, where do I put them? And since we're here, what about city quarters? --Syrio posso aiutare? 11:55, 23 November 2018 (UTC)Reply[reply]

As long as the frazione (Q1134686) is a proper administrative subdivision with a clearly defined territory, and the relevant instance of (P31) frazione (Q1134686) is connected to a higher level administrative division (for example: any instance of (P31)commune of Italy (Q747074)) through located in the administrative territorial entity (P131), I don't see the problem with using any instance of (P31) frazione (Q1134686) as target for located in the administrative territorial entity (P131).--Asqueladd (talk) 15:13, 23 November 2018 (UTC)Reply[reply]
Ok, thank you! (ping to @Braveheart, Mike Peel:). --Syrio posso aiutare? 16:54, 23 November 2018 (UTC)Reply[reply]
Sorry, that ping didn't work. When the hamlet has no administrative body, how is it an administrative entity? Do we need a new property to identify the actual political entity an item is located in? Braveheart (talk) 13:37, 27 November 2018 (UTC)Reply[reply]
@Braveheart: Generally, we can use location (P276) if the village or hamlet is not a administrative entity. Like I done for Church of St Edward (Q15838965). --Fralambert (talk) 02:08, 28 November 2018 (UTC)Reply[reply]
Yes, that's what I suggested to User:Syrio, but apparently that's not case with Italian hamlets? I'm confused. Braveheart (talk) 09:17, 28 November 2018 (UTC)Reply[reply]
@Asqueladd:'s answer above says "[...] the frazione (Q1134686) is a proper administrative subdivision [...]"; as I understood it (but I may well be wrong), the property can be used for a hamlet because it is an official subdivision of an another administrative entity, even if it doesn't have an administrative body. In the property page, actually, it says Wikidata item of this property (P1629) is administrative division (Q56061), which is a "territorial entity for administration purposes, with or without its own local government" (and frazione (Q1134686) is said to be a subclass of (P279) of that). --Syrio posso aiutare? 11:41, 28 November 2018 (UTC)Reply[reply]
Syrio's view matches my own here. Thanks. Mike Peel (talk) 20:20, 28 November 2018 (UTC)Reply[reply]
Not sure I fully understood. I have a similar case with German church districts. This is a completly separate political hierachy to German governmental districts with very differnt borders. Can I use P131 outside of governmental (Countries/States/Districts/Municipalities) for other organizational territorial hierachies (Churches, Sports, etc)? Thanks for clarifying.--Aeroid (talk) 14:04, 10 February 2019 (UTC)Reply[reply]
For churchy territorial hierarchies please use located in the ecclesiastical territorial entity (P5607) --Pasleim (talk) 14:19, 10 February 2019 (UTC)Reply[reply]

Setting more precise administrative entities from addresses edit

There are a lot of cases where this property refers to a large administrative unit when I think a smaller, more precise one would be appropriate. As an experiment, I used the following query to find a bunch of entities which currently have their location set to a US state, but which have an address property that lists a city name which is within that state. To avoid timeouts, I limited the query in several ways:

  • it searches a single US state, which is specified in the initial BINDs (I've tested with Oregon and Illinois);
  • it only looks for institutions of higher education;
  • and it only considers the deprecated P969 address property, not its replacement, P6375.

The query finds the correct object representing the city and returns that, so if you can run SPARQL delete/insert queries across wikidata, you could mechanically set more specific locations for all entities across the US.

Extending it to work outside the US requires knowing how addresses are formatted in a given place. Conveniently, US addresses are fairly uniform in how city+state are written.

SELECT ?entity ?entityLabel ?cityLabel ?city WHERE {
  # pick a US state and its two-letter USPS abbreviation
  BIND (wd:Q824 AS ?state).
  BIND ("OR" AS ?abbrev).

  # I limited to higher-education institutions, but this
  # probably applies to any entity, if you can wait a while
  ?entity (wdt:P31/wdt:P279*) wd:Q38723.

  # find entities that are located in the state, but not in
  # a specific city or other administrative subunit
  ?entity wdt:P131 ?state.

  # get the deprecated street address: I found this correlated
  # well with having a non-specific P131
  ?entity wdt:P969 ?address.

  # dig the name of the city out of the address (it's the part
  # before the state abbreviation, and after a comma) and turn
  # it into an English label
  BIND (strlang(strafter(strbefore(?address, concat(", ", ?abbrev, ", ")), ", "), "en") AS ?cityL)

  # find US cities in the selected state
  ?city wdt:P31 wd:Q1093829.
  ?city wdt:P131+ ?state.

  # pick out a city with the given label
  ?city rdfs:label ?cityL.

  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }

--JameySharp (talk) 18:33, 10 February 2019 (UTC)Reply[reply]

@JameySharp: Very nice. I've gone through a lot of these (couldn't get the query for California to run, though). --Yair rand (talk) 07:14, 3 April 2019 (UTC)Reply[reply]

constraint notice at euthanasia (Q100159) edit

Hi! I added the property at the two images from euthanasia (Q100159). How such constraint failures can be avoided? Regards
no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn talk contribs 00:57, 28 July 2019 (UTC)Reply[reply]

I changed to property location (P276). There still is an alert! Please inverstigate. Thanks in advance! Regards
no bias — קיין אומוויסנדיקע פּרעפֿערענצן — keyn umvisndike preferentsn talk contribs 13:28, 28 July 2019 (UTC)Reply[reply]

Sovereign state as administrative territorial entity? edit

Values of this property are supposed to be administrative territorial entities. While administrative entity is generally understood to be a subnational entity (see comment on similar issue here), currently this property is also used for many top level country subdivisions where its value is a sovereign state, e.g. see England (Q21), Quebec (Q176), Nara Prefecture (Q131287). What does this mean? I wonder if this is a result yet anoter discrepancy in property label translations, so that in some language its more generic than in English (something like "political territorial entity" rather than "administrative territorial entity"). Or is/was there a property constraint which made users "fix" its false positives in this manner? In these cases sovereign state is also given as country (P17) value anyway. I'd assume that such odd uses of P131 can be simply removed. 2001:7D0:81F7:B580:15BB:926D:3861:5285 06:43, 4 August 2019 (UTC)Reply[reply]

I will repeat my understanding of this. It is assumed that the property should report to which the specified entity is administratively subordinate. Subordination directly to the state is a special case of administrative subordination, country (P17) does not in itself affirm this, as the party is equally filled for all levels. If located in the administrative territorial entity (P131) is absent in the item, we cannot understand, they forgot to indicate a superior entity to it or it does not obey administratively anything. Сидик из ПТУ (talk) 07:31, 4 August 2019 (UTC)Reply[reply]
Label of this property however doesn't refer to "administrative subordination", it only indicates that one object is located in another and latter is an administrative territorial entity (concept that generally refers to subnational entity). 2001:7D0:81F7:B580:15BB:926D:3861:5285 07:47, 4 August 2019 (UTC)Reply[reply]
Geographic location and political association for Puerto Rico are different. Yes, associated as a territory to the US but not geographically in the US. So how do we correctly indicate on English Wikipedia that the Arecibo Observatory is in "Arecibo, Puerto Rico"? While Puerto Rico's political status is associated to the U.S., locations that are located in Puerto Rico are not in the U.S. If in doubt see the Arecibo Obsevatory on Britannica Encyclopedia. Please help. The infobox of the Arecibo Observatory is correct on Commons but NOT correct on the infobox on English Wikipedia and no one seems to give a... The infobox should not show "Arecibo, US". (And since I started asking about this I've been getting lots of spammy vandalism on my page like someone doesn't even like me asking) Please help.--The Eloquent Peasant (talk) 21:03, 24 November 2019 (UTC)Reply[reply]

Can we drop the Conflicts with “instance of (P31): organization (Q43229)” constraint edit

This is discussed, in part, above at Why conflicts only with instance of (P31) business (Q4830453) and not something broader?. Many organisations (and subclasses thereof) are unambiguously located within an administrative territorial entity. Why, then, are we prohibiting them from being marked up with this property? I propose we remove the constraint and, wikipedia being what it is, will do so in the next few days unless there's consensus here that the constraint should stay. (I accept that some organisations are not unambiguously located within an administrative territorial entity and so will be better handled using headquarters location (P159) & other properties; that should not prevent us from using P131 for orgs where it is appropriate). --Tagishsimon (talk) 02:26, 6 November 2019 (UTC)Reply[reply]

Organization is a legal entity, thus is not located in the administrative territorial entity (P131), just its headquarters is located somewhere, so headquarters location (P159) is only correct way to record this. Using P131 is unclear and inaccurate, also discouraging users from accurate P159 (which is used in multiple organization infoboxes). Please keep the constraint.--Jklamo (talk) 09:20, 6 November 2019 (UTC)Reply[reply]
I'm sorry Jklamo, but you're categorically wrong on a couple of points & I reject the entirety of your argument:
  • Organization is a legal entity, thus is not located in the administrative territorial entity - If you want to get all legal, organisations tend to have company or charity registrations which absolutely locate them, for legal purposes, as being within a territorial entity.
  • So (P159) is only correct way to record this - is wrong. P131 clearly can be used. Doubtless P159 should also be used.
  • Using P131 is unclear and inaccurate - is nonsense. P131 is no less or more unclear or inaccurate than any location value.
  • also discouraging users from accurate P159 - P159 needs to look after itself. There's not a shred of logic in cannabalising P131 in order to save P159.
  • Nor is there any logic to cannabalising P131 because infoboxes depend on P159. That's the tail wagging the dog.
We have any number of organisations that are based within a single administrative entity. The P159 "solution" requires that we have two items for each - one for organisation, one for its building. That's not going to happen; and/or, because of the scale, that should not prevent us placing the cojoined single item into a P131.
We have any number of organisations that are based within a single administrative entity, but we cannot use a simple P131 query to look at them, but must use hideous inefficient P276/P131 circumlutions (presuming we have a P276)
The bottom line, still, is that many organisations are, in the real world, unambiguously located within administrative territorial entities; and this unexplained and unjustified constraint dissuades us from specifying this information in our Item records; and meaningfully impacts on our ability to produce reports.
  • And the only illusary "benefit" is to force users to create redundant items (Berwick High School is headquartered at Berwick High School). --Tagishsimon (talk) 21:23, 6 November 2019 (UTC)Reply[reply]
  • Conflating organisation and building into one item can work in some cases but certainly doesn't work in all cases. A school can own multiple buildings, a museum can have different heritage designations for collection and building etc. If our goal is to create a structured database we use a model which is applicable to all cases, if we just want to quickly gather a mass of data conflated items do the job. --Pasleim (talk) 08:55, 7 November 2019 (UTC)Reply[reply]
  • I think we occasionally see WikiProjects fail when they try to follow a structure and granularity made for other, dedicated systems. This leads to too many items that are not really suitable to be edited in a multi-contributor setting. We could obviously list every bikeshed for every school just to be sure these are detailed, but neither this nor specifying every "Delaware" as headquarter location is going to be of much practical use except maybe for those trying to implement a dedicated system elsewhere and trying to coerce volunteers to do editing fit for their system. --- Jura 11:55, 7 November 2019 (UTC)Reply[reply]
Removed, constraints are not here to enforce a very narrow minded world view. Multichill (talk) 19:58, 7 November 2019 (UTC)Reply[reply]
Look at any historical Atlas or map of the United States and you won't see Puerto Rico or the Virgin Islands or Guam on the map even they are called "US Territories". You should be aware of the way wikidata location properties are transcluding across wikis. --(User talk:The Eloquent Peasant) 22:17, 24 November 2019 (UTC)Reply[reply]

Inheritance/Hierarchy not working during queries? edit

Hi folks! Following up on a conversation with Dcflyer, I noticed that inheritance for P131 doesn't seem to "cascade up" when using the WDQS. For example, I did a query of museums in Los Angeles County, which shows the two museums tagged with Los Angeles County. Next I did a query of museums in California, where I used "Located in the administrative territory entity", or any "subclass of" "California", and I expected to see those two Los Angeles County museums show up, but they didn't. I double-checked based on the instructions ("You only need to add the most local admin territory, but check that item also has a P131, with the next level, and so on. (English)") and Los Angeles County has the correct located in the administrative territorial entity (P131) of California. The location hierarchy is showing up correctly in Resonator, but it doesn't seem to work in WDQS. I looked through this Help page on modelling hierarchy of classes, which seems to suggest that "subclass of" should work... so yeah, I'm not sure where I'm making the mistake. As a test I also tried "part of" instead of "subclass of" but it still won't pull in those two Los Angeles County museums. Is "subclass of" the wrong thing to use during queries to make sure that the inheritance works? Any help is very appreciated! Clifflandis (talk) 15:14, 18 December 2019 (UTC)Reply[reply]

Los Angeles County is not a subclass of California thus a query with subclass of (P279) will not work. But in the same way as Getty Villa (Q180401) is located in Los Angeles County, Los Angeles County is located in California. That means you only have to follow the located in the administrative territorial entity (P131) path. In theory, the query looks like [4], unfortunately it seems to time out quite often. A faster but slightly less precise query is the following one: --Pasleim (talk) 20:06, 20 December 2019 (UTC)Reply[reply]
Thanks Pasleim, that helps explain things a lot -- I'm not very familiar with how the located in the administrative territorial entity (P131) paths work, so I'm going to have to dig into that. Thanks for pointing me in the right direction! Clifflandis (talk) 17:03, 14 January 2020 (UTC)Reply[reply]

Best practice for representing cities/towns in multiple counties? edit

Hi folks! I'm trying to figure out the best practice for representing cities and towns that exist in multiple counties. Pulling examples from the List of Municipalities in Georgia (US State), Atlanta (Q23556) is in both Fulton and DeKalb counties, Allentown (Q2670381) is in Bleckley, Laurens, Twiggs, and Wilkinson counties, and Braselton (Q899020) is in Barrow, Gwinnett, Hall, and Jackson counties. I've been representing these by just adding all the counties to the located in the administrative territorial entity (P131) property, but I didn't know if that's best practice (or if there's consensus yet on how to do this). Here's my problem: If I want to use the query service to find the county for all non-profit organizations in Atlanta, and "the most local admin territory" is the city of Atlanta, would it even be possible to find the county without also tagging the county in the organizations' records (if that makes sense)? Thanks! Clifflandis (talk) 18:02, 14 January 2020 (UTC)Reply[reply]

@Clifflandis: This is a interesting question. Maybe the solution is to create a item for the part of Atlanta in Fulton County and one for the part in DeKalb County? --Fralambert (talk) 01:20, 15 January 2020 (UTC)Reply[reply]
It can be used with statement is subject of (P805) in Atlanta (Q23556) but I think this items will be useless because no one uses "part of Atlanta in Fulton County" outside Wikidata and it isn't actually administrative division (Q56061). Perhaps, only in cases of such switches we can use located in the administrative territorial entity (P131) as a qualifier for located in the administrative territorial entity (P131) of non-profit organization (example).Сидик из ПТУ (talk) 12:38, 15 January 2020 (UTC)Reply[reply]
@Сидик из ПТУ: Okay, so if I understand you correctly then an example would be "Georgia Arts Council" located in the administrative territorial entity "Atlanta", which is then qualified with located in the administrative territorial entity "Fulton County". What would be the impact of having two "top level" P131s, one for Atlanta, and one for Fulton County? I notice that P131 isn't limited to a single instance, unlike coordinate location (P625) and other properties. Does having two (or more) P131s break things? Should P131 be changed to only allow a single instance? Thanks for your help with this! Clifflandis (talk) 13:22, 15 January 2020 (UTC)Reply[reply]
As we can see in documentation, You only need to add the most local admin territory. Equivalent indication of both entities in located in the administrative territorial entity (P131) will be misleading since a similar approach on the example of Atlanta is used to indicate belonging to several equivalent administrative division (Q56061) (counties). It should be immediately clear where the item belongs to several entities at the same time (like Atlanta to Fulton and DeKalb counties), and where the switch for the hierarchy needed (like for "Georgia Arts Council" to achieve right county via Atlanta). Сидик из ПТУ (talk) 13:36, 15 January 2020 (UTC)Reply[reply]
@Сидик из ПТУ: thanks for taking the time to explain. I read the documentation, but it's so brief that I didn't know how to address situations like this, hence my questions. I'll keep an eye out to make sure that if I run across items that have multiple P131s, that those P131s should all be on the "same level" in the hierarchy. Moving forward I'll add counties as P131 qualifiers to city/town P131s when needed. Cheers! Clifflandis (talk) 15:38, 15 January 2020 (UTC)Reply[reply]

@Сидик из ПТУ: For Patch Works Art & History Center (Q76461608) in the located in the administrative territorial entity (P131) field I added a qualifier of P131:Fulton County (Q486633), but it's giving me an "allowed qualifiers constraint" warning. Would it be possible to add P131 to the list of acceptable qualifiers for P131? Thanks! Clifflandis (talk) 17:47, 17 January 2020 (UTC)Reply[reply]

I added. Ideally, we can create a more general property for switches (case to choose at the next hierarchy level). Сидик из ПТУ (talk) 22:19, 17 January 2020 (UTC)Reply[reply]
@Сидик из ПТУ: It looks like your edit has been reverted. Should I wait until there's some sort of consensus or a broader solution? I don't want to make a bunch of corrections if this is going to be controversial or mess things up for other folks. Thanks! Clifflandis (talk) 20:17, 27 January 2020 (UTC)Reply[reply]
Let's ask Esquilo. Esquilo, do you read this discussion? Anyway, I can make request for new universal hierarchy switch property. Сидик из ПТУ (talk) 21:31, 27 January 2020 (UTC)Reply[reply]
A property should not be a qualifier to itself. applies to part (P518) should cover such cases if needed at all. For example Märket (Q163395) is split between two countries and three municipalities. /ℇsquilo 06:23, 28 January 2020 (UTC)Reply[reply]
@Esquilo:, @Сидик из ПТУ:, @Yair rand:, @Fralambert: since there's no discussion (and therefore no objection) to creating Wikidata:Property proposal/hierarchy switch after two weeks, should I go ahead and change it to status=ready, or should I cross-post it somewhere to attract more attention? Thanks! Clifflandis (talk) 13:28, 12 February 2020 (UTC)Reply[reply]
I think status can be changed only by user with some flags so best way is to attract more attention. Сидик из ПТУ (talk) 13:32, 12 February 2020 (UTC)Reply[reply]
I have neither objected or supported because I don't understand the proposal. But if it works, then ok. /ℇsquilo 14:07, 12 February 2020 (UTC)Reply[reply]
Okay, I brought it up on Project Chat to try to build a discussion and/or consensus. Clifflandis (talk) 14:21, 12 February 2020 (UTC)Reply[reply]

Possible change of usage edit

Please see Wikidata:Property_proposal/hierarchy_switch.

The proposed qualifier would change the use of this property to include values of administrative territorial entities where the entity is only partially located (e.g. Atlanta is located in the state of Georgia would include two counties (some areas are outside Atlanta) instead of just "Georgia" or "Metro Georgia". Going forward, one couldn't rely anymore on P131 being accurate. This can break breadcrum navigation similar to the one on .
Also, path queries with wdt:P131* on places located within Atlanta wont be able to determine accurately the county of a place without more complex qualifier lookup. --- Jura 12:17, 21 February 2020 (UTC)Reply[reply]
The proposed property is fully consistent with the logic described in Wikidata usage instructions (P2559) of located in the administrative territorial entity (P131). Most local admin territories for municipality of Georgia (Q76514543) are county of Georgia (Q13410428). This view is consensus approved in 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). Georgia is not the most local admin territory for Atlanta, it's false. Сидик из ПТУ (talk) 13:04, 21 February 2020 (UTC)Reply[reply]
I think you already express that view there. --- Jura 13:09, 21 February 2020 (UTC)Reply[reply]
As for queries this is resolved by Dipsacus fullonum here. Сидик из ПТУ (talk) 13:10, 21 February 2020 (UTC)Reply[reply]
You say as if now templates can "determine accurately" geo-chain based on WikiData. As I now from Wikipedia side - it isn't true. So we need proposed switch to be more accurate with the data we have.Carn (talk) 15:22, 21 February 2020 (UTC)Reply[reply]
I'd expect a combination of territory overlaps (P3179) for the counties it is partially in and located in the administrative territorial entity (P131) for the closest administrative entity that entirely contains it (in the case of Atlanta, that would be Georgia). Atlanta is no more in DeKalb County than DeKalb County is in Atlanta. - Jmabel (talk) 16:53, 21 February 2020 (UTC)Reply[reply]
Britannica says that Atlanta seat of Fulton county (but also partly in DeKalb county. The converse is not based on reliable sources. Сидик из ПТУ (talk) 17:15, 21 February 2020 (UTC)Reply[reply]
As for territory overlaps (P3179), read this. Сидик из ПТУ (talk) 17:19, 21 February 2020 (UTC)Reply[reply]
Jmabel, if Atlanta isn't in DeKalb County, then please explain why it is categorized in w:Category:Cities in DeKalb County, Georgia at enwiki. --Dipsacus fullonum (talk) 17:24, 21 February 2020 (UTC)Reply[reply]
@Dipsacus fullonum: Because the Wikipedia (and Commons) category systems are folksonomies, loose hierarchies intended to help humans find things. As I understand it, Wikidata intends far more rigorous modeling than that, in particular something capable of supporting programmatic queries. If not, then it is hard to understand why Wikidata should exist at all. - Jmabel (talk) 16:08, 22 February 2020 (UTC)Reply[reply]
In any case, Wikidata is not intended to create a new worldview. Most local admin territories for municipality of Georgia (Q76514543) are county of Georgia (Q13410428) and we should store this data, not invent false statements to decorate the base. Сидик из ПТУ (talk) 18:13, 22 February 2020 (UTC)Reply[reply]
I think we all agree that it's partially in that county, we just disagree with we should use P131 for this. Wasn't Wikidata created as categories at Wikipedia were found to be limited. Anyways, please support or oppose the proposal based on your POV/usecases/vision of how complex queries should be to get basic information. --- Jura 17:29, 21 February 2020 (UTC)Reply[reply]
How do we handle New York City (Q60)? It's in five counties, if I remember correctly. —Scs (talk) 18:13, 21 February 2020 (UTC)Reply[reply]
New York City is uniquely partitioned into five counties, referred to at the city government level as boroughs. That is for New York City we can say that his boroughs is in it, but Atlanta does not. Most local admin territories for Atlanta are Fulton and DeKalb, not Georgia. Сидик из ПТУ (talk) 18:24, 21 February 2020 (UTC)Reply[reply]
By "uniquely" do you mean "New York City is unique in having boroughs" or "The counties that make up New York's five boroughs do not extend outside New York City"?
According to w:Neighborhoods in Atlanta, Atlanta does have officially-defined neighborhoods (and a level of "Neighborhood planning unit" above them). I haven't yet determined whether there's a set of neighborhoods that completely and nonoverlappingly covers the city -- and that don't overlap counties. But if there is, it seems to me we could make use of them as part of the solution to this problem. —Scs (talk) 18:38, 21 February 2020 (UTC)Reply[reply]
At first, I dont sure that Neighborhood is a administrative division (Q56061). Secondly, we still should specify most local admin territory for Atlanta (Q23556) in located in the administrative territorial entity (P131) and there are Fulton County (Q486633) and DeKalb County (Q486398), anyway. Third, we have Redcar and Cleveland (Q1434448) case which located in North Yorkshire (Q23086) (North Yorkshire (Q23086) has two right values in located in the administrative territorial entity (P131) where only one of them is correct for Redcar and Cleveland (Q1434448)). Сидик из ПТУ (talk) 18:51, 21 February 2020 (UTC)Reply[reply]
And all the same, all these Neighborhoods should have Atlanta (Q23556) at located in the administrative territorial entity (P131) and we still need to determine which counties of Georgia should be selected at the next level (Neighborhoods in Atlanta (Q6988066)Atlanta (Q23556)Fulton County (Q486633) and DeKalb County (Q486398)Georgia (Q1428)).Сидик из ПТУ (talk) 18:57, 21 February 2020 (UTC)Reply[reply]
As for NY, according to a Wikipedia article (another), in 1898 it really found himself in a unique case for the USA, when counties became parts of the city and not vice versa. Сидик из ПТУ (talk) 19:01, 21 February 2020 (UTC)Reply[reply]
  • If we are talking about a particular geographic point, perhaps expressed as a GPS coordinate, then it seems to me that a chain like point -> Atlanta -> Fulton county -> Georgia ... is valid. This doesn't say that the whole of Atlanta is in Fulton county, but this particular point is. If the "point" is instead a larger area, like a park, that's partly in Atlanta and partly not, I wouldn't know how to describe it. Ghouston (talk) 01:21, 22 February 2020 (UTC)Reply[reply]
    • Most likely the right approach will be "Most local admin territories of every points of area". Anyway it should be selected as "parks of Atlanta". Сидик из ПТУ (talk) 09:13, 22 February 2020 (UTC)Reply[reply]
  • For those who haven't done so, would you also comment in the discussion at Wikidata:Property_proposal/hierarchy_switch? @Scs, Jmabel: --- Jura 08:11, 22 February 2020 (UTC)Reply[reply]

Samples\Versions Current with new qualifier "next hierarchy" Current (ruwiki infobox assumption) theoretical

Atlanta (Q23556)


Patch Works Art & History Center (Q76461608)
Query all bus stops in DeKalb County ?item wdt:P131* wd:Q486398 program/multiple queries with pq:
solution with MINUS.
not possible? ?item wdt:P131* wd:Q486398
Query all bus stops in Atlanta ?item wdt:P131* wd:Q23556 ?item wdt:P131* wd:Q23556 ?item wdt:P131* wd:Q23556 ?item wdt:P131* wd:Q23556
Query all cities in Fulton County ?item (wdt:P131*|wdt:P3179) wd:Q486633 ; wdt:P31 wd:Q1093829 ?item wdt:P131* wd:Q486633 ; wdt:P31 wd:Q1093829 ?item wdt:P131* wd:Q486633 ; wdt:P31 wd:Q1093829
Query all bus stops by county of Georgia ?item wdt:P131+ ?county . ?county wdt:P31/wdt:P279* wd:Q13410428 solution with MINUS (? sample missing, timeout likely)

--- Jura 25 February 2020 (UTC

  • I’ll notice that the column called "Current" suggests a violation of the rule "You only need to add the most local admin territory" that is prescribed in Wikidata usage instructions (P2559) so for both examples of this column we can't get hierarchies and recognize the most local admin territory easily without special knowledge base. Сидик из ПТУ (talk) 16:08, 25 February 2020 (UTC)Reply[reply]
    • I think it's rather that the current ruwiki infobox makes incorrect assumptions, leading to recurring problems between ruwiki users and Wikidata contributors. --- Jura 08:55, 26 February 2020 (UTC)Reply[reply]
    • You're right, the rule "You only need to add the most local admin territory" has exceptions in the case of overlapping territories. I think the exception can be pretty concisely stated, though, based on looking at whether the parent territory (a) doesn't have its own P131, or (equivalently?) (b) does have two or more P3179's. And a bot could check for those, and kick out lists of entities that (like Q76461608) need to be explicitly tagged with both their parent and grandparent territories. (And in some cases, the presence of smaller administrative subdomains -- that is, beneath the overlapping one -- significantly reduces the number of entities actually needing "grandparent" P131's.) —Scs (talk) 14:47, 26 February 2020 (UTC)Reply[reply]
      • These exceptions are needless and only harm. Even the simplest queries like "all cities of county" will not work with this approach. Bot can of course do this, but this makes no sense other than ruining the data. Сидик из ПТУ (talk) 16:12, 26 February 2020 (UTC)Reply[reply]
        • Scs actually it works with the query added above. I'm not sure why Сидик из ПТУ keeps saying the opposite. --- Jura 16:48, 27 February 2020 (UTC)Reply[reply]
          • It works, but not as easily as when the hierarchy is respected and the correct next level is indicated for each item. Сидик из ПТУ (talk) 13:41, 28 February 2020 (UTC)Reply[reply]
  • It is misinformation that a query with the proposed qualifer requires "program/multiple queries with pq:". It can be done with one query. --Dipsacus fullonum (talk) 16:21, 25 February 2020 (UTC)Reply[reply]

Jura again gives misinformation in table above. Even after Jura requested and I made a query to find busstops in Georgia by county, Jura writes "sample missing" in the table. Jura also writes "timeout likely" without any reason. --Dipsacus fullonum (talk) 12:55, 1 March 2020 (UTC)Reply[reply]

As mentioned on your talk page, the sample is still missing. I add that comment to an entry by Сидик из ПТУ. Feel free to accuse people of misinformation if you can't understand the information or struggle to provide the requested sample. --- Jura 20:27, 3 March 2020 (UTC)Reply[reply]
The important point is if the query can be done with SPARQL or not, so when Jura writes "sample missing" it is likely to be understood as "sample for the functionality missing", not "sample using the exact proposed SPARQL keywords missing". But Jura is wrong about that the sample is still missing, as Сидик из ПТУ posted a link to a sample using "MINUS" more than two days ago in Special:Diff/1126838952. It is not for busstops but for organisations, but could be changed to query for busstops by changing exactly one item ID in the code, so I cannot not see why it shouldn't be regarded as a valid sample for the "MINUS" method. --Dipsacus fullonum (talk) 01:22, 4 March 2020 (UTC)Reply[reply]
I also resolved this request by changing bus stops to organizations for clarity and usin P131 as qualifier. So we have at least two ways for working with the proposed qualifier. Сидик из ПТУ (talk) 13:04, 1 March 2020 (UTC)Reply[reply]

Electoral districts edit

For quite a while I've thought that places in Australia (or maybe just Tasmania) probably shouldn't be using electoral districts in P131. E.g., Ross (Q1002974). What do you think? Ghouston (talk) 01:57, 22 February 2020 (UTC)Reply[reply]

The electoral district should be in electoral district (P768) instead. --Fralambert (talk) 03:08, 22 February 2020 (UTC)Reply[reply]
That's only valid on people. The Australian electoral districts are potentially a bit tedious, because boundaries tend to change frequently, go through the middle of towns, etc., as required to get roughly the right population in each one. Ghouston (talk) 03:38, 22 February 2020 (UTC)Reply[reply]
My fault. One seat electoral districts tend to change often of limit with time. But I am pretty sure that electoral district sould be not a result in P131, they are not "administrative" at the fist place. But they are often delimited by administrative borders. [8] --Fralambert (talk) 04:17, 22 February 2020 (UTC)Reply[reply]
@Ghouston: Hi, associated electoral district (P7938) was created today (see Trois-Rivières (Q44012) and Yamachiche (Q3571405)). So I Imagine that you can move the Australian electoral districts now ;). --Fralambert (talk) 12:41, 27 February 2020 (UTC)Reply[reply]
It should be in another property hierarchy Wikidata:Property proposal/located in the constituency. For example, we already have located in the ecclesiastical territorial entity (P5607). I would also like to have separate properties for statistical territorial entity (Q15042037) and military district (Q580112). Сидик из ПТУ (talk) 09:05, 22 February 2020 (UTC)Reply[reply]
  • Thanks for the new property, I guess that answers this question. Ghouston (talk) 12:46, 27 February 2020 (UTC)Reply[reply]

clinical trial (Q30612) edit

P131 doesn't seem useful on these. I'm not entirely sure what alternative to suggest. "location"? --- Jura 19:34, 3 June 2020 (UTC)Reply[reply]

Problematic contemporary constraint edit

Having contemporary constraint (Q25796498) as property constraint (P2302) is problematic, because remains of buildings are located in nowadays municipalities/etc. Example: a medieval castle was destroyed hundreds of years ago, while the archaeological remains are located in the