Property talk:P131

Latest comment: 1 hour ago by Prosperosity in topic Autofix Dunedin and Auckland

Documentation

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 territorial entity (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)
Lists
Proposal discussionProposal discussion
Current uses
Total13,657,816
Main statement13,441,48098.4% of uses
Qualifier216,1941.6% of uses
Reference142<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
  Value Dunedin (Q133073) will be automatically replaced to value Dunedin City (Q32188005) and moved to location (P276) property.
Testing: TODO list
  Value Auckland (Q37100) will be automatically replaced to value Auckland Region (Q726917).
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

I guess, it is bugzilla:58394 --Pasleim (talk) 07:58, 23 January 2014 (UTC)Reply
Alright, so this was already known. Thanks. TCN7JM 13:10, 23 January 2014 (UTC)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

This looks more like grammar than semantic, or am I missing something? -- Lavallen (talk) 17:16, 25 January 2014 (UTC)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

Target edit

Please change "target item must have", "to target item must be an instance of a subclass of administrative territorial entity (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

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

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.
https://tools.wmflabs.org/reasonator/?q=Q621 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
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
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

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

sure. --- Jura 20:14, 24 May 2015 (UTC)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
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
Thank you a lot, with the examples I find it clear. - Fabimaru (talk) 10:06, 30 May 2015 (UTC)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
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
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
Paintings are movable objects. So they are not directly comparable to the samples given by Fabimaru. --- Jura 09:31, 23 September 2015 (UTC)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

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

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

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

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

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

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

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

Looked at Isle of Man (Q9676) and it's incorrectly located in the UK. Multichill (talk) 14:40, 5 May 2017 (UTC)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

It is solved by using appropriate ranks and qualifiers. --Infovarius (talk) 22:31, 14 June 2017 (UTC)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

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

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

For a case where this would be needed, see: Talk:Q21130185.--Urjanhai (talk) 15:28, 9 July 2017 (UTC)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
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
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
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
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
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
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
 
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
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
Ping still User:Stryn, User:Zache, User:Susannaanas, User:Raksa123.--Urjanhai (talk) 11:02, 13 July 2017 (UTC)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
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
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
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

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

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

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

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
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: tinyurl.com/y9ecngfu
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
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

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

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. 92.230.132.107 09:50, 27 June 2018 (UTC)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

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
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
@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
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
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

@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

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 territorial entity (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

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 territorial entity (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 territorial entity (Q56061). In fact, a majority of city items are already subclass of administrative territorial entity (Q56061) without the need of the falsy statement city (Q515) subclass of (P279) administrative territorial entity (Q56061) [3], so the above mentioned numbers need to be corrected. --Pasleim (talk) 18:43, 9 August 2018 (UTC)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

@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
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
@99of9: maybe location (P276). Could you give an example? Cdlt, VIGNERON (talk) 15:44, 7 September 2018 (UTC)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

I agree with Ysogo: if we use the highest administration unit, lower units are unnecessary. --Yiyi .... (talk!) 10:26, 2 September 2018 (UTC)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
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
      }
      FILTER NOT EXISTS {
        ?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 .
      FILTER NOT EXISTS {
        ?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 .
      FILTER NOT EXISTS {
        ?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
      }
      FILTER NOT EXISTS {
        ?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 .
      FILTER NOT EXISTS {
        ?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
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
@Сидик из ПТУ: 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
Cantons were the closest administrative (not only electoral) unit in France until 2014 (or 2015)? Сидик из ПТУ (talk) 07:23, 7 September 2018 (UTC)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
@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
@Сидик из ПТУ: 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
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
@Сидик из ПТУ: 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
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
@Сидик из ПТУ: 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
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
@Сидик из ПТУ: 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
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
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

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

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
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
@ArthurPSmith: We have operating area (P2541) for indicating the operating locations... --Yair rand (talk) 15:52, 17 October 2018 (UTC)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

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
Ok, thank you! (ping to @Braveheart, Mike Peel:). --Syrio posso aiutare? 16:54, 23 November 2018 (UTC)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
@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
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
@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 territorial entity (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
Syrio's view matches my own here. Thanks. Mike Peel (talk) 20:20, 28 November 2018 (UTC)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
For churchy territorial hierarchies please use located in the ecclesiastical territorial entity (P5607) --Pasleim (talk) 14:19, 10 February 2019 (UTC)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.

#defaultView:Table
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

@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

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

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

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

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

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

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
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.
  • 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
  • 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
Removed, constraints are not here to enforce a very narrow minded world view. Multichill (talk) 19:58, 7 November 2019 (UTC)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

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

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: https://w.wiki/EDB. --Pasleim (talk) 20:06, 20 December 2019 (UTC)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

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

@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
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 territorial entity (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
@Сидик из ПТУ: 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
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 territorial entity (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
@Сидик из ПТУ: 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

@Сидик из ПТУ: 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

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
@Сидик из ПТУ: 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
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
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
@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
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
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
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

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 https://en.wikivoyage.org/wiki/Atlanta .
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
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
I think you already express that view there. --- Jura 13:09, 21 February 2020 (UTC)Reply
As for queries this is resolved by Dipsacus fullonum here. Сидик из ПТУ (talk) 13:10, 21 February 2020 (UTC)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
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
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
As for territory overlaps (P3179), read this. Сидик из ПТУ (talk) 17:19, 21 February 2020 (UTC)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
@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
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
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
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
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
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
At first, I dont sure that Neighborhood is a administrative territorial entity (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
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
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


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

Atlanta (Q23556)

either

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

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

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

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

The electoral district should be in electoral district (P768) instead. --Fralambert (talk) 03:08, 22 February 2020 (UTC)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
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
@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
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

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

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 current municipality that did not exist at the time of destroying. Romaine (talk) 09:54, 30 June 2020 (UTC)Reply

Hi Romaine - this is an interesting question for my historical mapping interests. It seems to me that some property of the castle changed when it turned into ruins. This is separate from the admin entity, of course. While I'm sure you don't want to list every admin entity that owned the ruins through the ages, does this constraint prevent the use of start time (P580) and end time (P582) on the values? Jeffme (talk) 21:00, 27 December 2020 (UTC)Reply

P131 = Q30971 edit

How to filter items with any located in the administrative territorial entity (P131) = French Polynesia (Q30971) ?Bouzinac (talk) 15:09, 30 June 2020 (UTC)Reply

SELECT * { ?item p:P131/ps:P131 wd:Q30971 }
Try it!
--Dipsacus fullonum (talk) 15:21, 30 June 2020 (UTC)Reply
Thank you, I've saved your syntax here https://www.wikidata.org/wiki/User:Bouzinac/Fréquentations#Fréquentation/Patronage_of_(x)_airport(s)_in_an_administrative_région ;) Bouzinac (talk) 15:28, 30 June 2020 (UTC)Reply

human settlement (Q486972) as proper value for located in the administrative territorial entity (P131) edit

At first, officially recognized human settlement (Q486972) clearly fits the definitions given in administrative territorial entity (Q56061) (territorial entity for administration purposes, with or without its own local government) and in Wikipedia artile (portion of a country or other region delineated for the purpose of administration). Moreover, in Urban or rural regions section of this article "settlement" and "populated place" are listed as examples of administrative units. It is quite natural that the located in the administrative territorial entity (P131) has such aliases as "is in the town of", "is in the settlement of" and "is in the city of". So, I consider it correct to fill human settlement (Q486972) that have their borders as the most local located in the administrative territorial entity (P131).

The suggestion to use location (P276) looks inappropriate, since villages and cities are much more consistent with the concept of an administrative-territorial unit than with the concept of physical location. For a street in a particular village, it is intuitively required to specify a village as an administrative unit, not a union of villages. Сидик из ПТУ (talk) 08:59, 8 July 2020 (UTC)Reply

@Richard Arthur Norton (1958- ): the consensus is clearly against adding this, so please don't. Multichill (talk) 23:54, 10 February 2024 (UTC)Reply

Why no "end cause" property? edit

If a location changes from 1 administrative entity to another, and thus has a start time (P580) and an end time (P582), why not have an end cause (P1534)? This is currently disallowed by a constraint.

e.g. a neighborhood in a city on Staten Island changes from that city to Staten Island Borough when New York City consolidated in 1898.

Thanks Jeffme (talk) 20:46, 27 December 2020 (UTC)Reply

Multiple entries edit

This property is sometime used with multiple entries. These can be different types of cases:

  • the item subject extends to several territorial units of the same level (e.g. a street in more city districts, or a protected area on the territory of several municipalities) - this needs any special qualifier or any different property: "partly located in the administrative territorial entity"
  • the two entries are of two various types of administrative division, not compatible each to others. The two entries mean the intersection of both units (e.g. part of Vinohrady (Q662985) belonging to Prague 10 (Q2444921) district, or part of Prague 10 (Q2444921) belonging to Vinohrady (Q662985)).
  • one or more of the multiple entries is redundant (not the lowest level of administrative division).

How to distinguish safely and unambiguously the variants 1 and 2? How to prevent and eliminiate the variant 3? --ŠJů (talk) 20:40, 15 July 2021 (UTC)Reply

As User:Arpyia just informed me, all communes in France have these redundant entries, they all have the Canton, the Arrondissement, and the Département. That makes it very hard to use this property for anything. I think the first step could be that we agree that the rule about "only the lowest level" is indeed a rule and has to be followed. Thanks --Reinhard Müller (talk) 12:15, 16 March 2024 (UTC)Reply

Russian descr edit

{{editprotected}}

Please, change

Используй

to

Используйте

. 217.117.125.83 13:08, 25 February 2022 (UTC)Reply

Why? Зачем? RenatUK (talk) 14:01, 26 February 2022 (UTC)Reply
More polite form. 217.117.125.83 08:52, 10 March 2022 (UTC)Reply

@Ymblanter: could you help? Should we fulfill this request?--Estopedist1 (talk) 07:46, 26 August 2022 (UTC)Reply

I do not see the Russian text (I only see Ukrainian on the property page, but no Russian), so it is difficult for me to understand the context, but yes, I think Используйте is generally better (less informal). Ymblanter (talk) 21:14, 26 August 2022 (UTC)Reply
  fulfilled--Estopedist1 (talk) 15:46, 29 August 2022 (UTC)Reply

Difference between P131 and P276 edit

Can someone explain to me the difference between these two? And specifically, which should be used for objects like churches. For example, Q12674693. It is located in town Taujėnai (Q779914) which is not per se an administrative division by itself. The town is located in Taujėnai Eldership (Q12674692) which is turn is located in Ukmergė District Municipality (Q68929) which are administrative divisions. So what's the best treatment:

  • A: set P131 to town Taujėnai (Q779914) [it used to issue a warning that towns are not administrative territories, but not any more]
  • B: set P131 to Taujėnai Eldership (Q12674692) and P276 to Taujėnai Eldership (Q12674692) as the most local administrative entity
  • C: something else?

I would like to add locations to about 1,000 churches so I want to get this right the first time. Thanks, Renata3 (talk) 16:20, 22 April 2022 (UTC)Reply

@Renata3 Hi, normally i will said that you set P131 to Taujėnai Eldership (Q12674692), if the church is indeed in Taujėnai (Q779914), you can add location (P276) to it. Taujėnai should be also set in Taujėnai Eldership in P131, as this is the nearest administrative division. If I could show you a exemple, i will look at Q15838965#P276 Fralambert (talk) 13:43, 23 April 2022 (UTC)Reply
I suggest the distinction should be that located in the administrative territorial entity (P131) should be used for other administrative divisions, so you have a clear nesting chain, and location (P276) is used for other sorts of things (events, organisations, buildings) that are not administrative divisions? So a building like a church should use location (P276) and a painting in the church should also use location (P276). For a church its administrative division is the parish, with a diocese, up the church hierarchy, and using location (P276) would make that clear. Vicarage (talk) 11:22, 19 June 2022 (UTC)Reply
As clear that some villages are in multiple municipalities, like Saint-Thomas-de-Caxton (Q97573325). How you put that the church is in Saint-Barnabé (Q3461843)? Fralambert (talk) 13:31, 19 June 2022 (UTC)Reply

New country constraint fails edit

@Bouzinac, Ivan A. Krestinin: This funky new constraint causes incorrect constraint violation on items like Netherlands (Q55) and England (Q21) (more examples). Multichill (talk) 20:51, 18 September 2023 (UTC)Reply

I am not sure if I correctly input the constraint but the meaning behind is that I don't want to see countries inside items in their P131 : these items should not get P131 = country but P17 = country. I am confused since you speak about Q55 and Q21 but they do not have any P131 statement. Bouzinac💬✒️💛 07:36, 19 September 2023 (UTC)Reply

Encouraging buildings to use location edit

Should we add warning constraints so building (Q41176), or at more detail architectural structure (Q811979) and facility (Q13226383) are encouraged to use location (P276)? The word "administrative" here confuses me. Vicarage (talk) 10:46, 29 December 2023 (UTC)Reply

in the `also known as` edit

Many alternative labels are subproperties of this property. Does it make sense? For instance, X 'is in the city of' Y, X WD:P131 Y, but not the inverse, right? So this should not be a valid label to P131. Arademaker (talk) 17:41, 31 January 2024 (UTC)Reply

Autofix Dunedin and Auckland edit

I've added two entries to the autofix list: Dunedin (Q133073) is not an administrative territory (Dunedin City (Q32188005) is the authority which governs the city and surrounding area), and similarly Auckland (Q37100) is not an administrative area (it is a city within the Auckland Region (Q726917) - as the region is a unitary authority, there is no distinct "Auckland" administrative area). For the latter I haven't included |move_to=P276 as it is likely that features outside of the city itself will have the property (e.g. buildings in other areas of the region). Is this something that needs to be discussed/debated, or is this fine to add? --Prosperosity (talk) 02:41, 20 April 2024 (UTC)Reply

Return to "P131" page.