Property talk:P131

From Wikidata
Jump to navigation Jump to search

Documentation

located in the administrative territorial entity
the item is located on the territory of the following administrative entity. Use P276 (location) for specifying the location of non-administrative places and for items about events
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 on terrain feature (P706).
Representsadministrative territorial entity (Q56061)
Data typeItem
Domaingeographical object (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)Washington (Q1223)
Eiffel tower (Q243)7th arrondissement of Paris (Q259463)
Jungfrau (Q15312)Lauterbrunnen (Q64011) and Fieschertal (Q70716)
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 administrative territorial entity (P150) (asymmetric reciprocity).
Tracking: sameno label (Q42533293)
Tracking: usageCategory:Pages using Wikidata property P131 (Q23908987)
See alsolocated on terrain feature (P706), location (P276), located in or next to body of water (P206), contains administrative territorial entity (P150), applies to jurisdiction (P1001), located in present-day administrative territorial entity (P3842)
Lists
Proposal discussionProperty proposal/Archive/2#P131
Current uses6,984,348
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.
List of this constraint violations: Database reports/Constraint violations/P131#Conflicts with P31, search, SPARQL, SPARQL (new)
Conflicts with “instance of (P31): Wikimedia disambiguation page (Q4167410): this property must not be used with the listed properties and values. (Help)
List of this constraint violations: Database reports/Constraint violations/P131#Conflicts with P31, hourly updated report, search, SPARQL, SPARQL (new)
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.
List of this constraint violations: Database reports/Constraint violations/P131#Conflicts with P31, SPARQL, SPARQL (new)
Conflicts with “instance of (P31): business (Q4830453): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P131#Conflicts with P31, search, SPARQL, SPARQL (new)
Conflicts with “headquarters location (P159): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P131#Conflicts with P159, search, SPARQL, SPARQL (new)
Item “instance of (P31): Items with this property should also have “instance of (P31)”. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P131#Item P31, search, SPARQL, SPARQL (new)
Item “country (P17): Items with this property should also have “country (P17)”. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P131#Item P17, search, SPARQL, SPARQL (new)
Value type “administrative territorial entity (Q56061): This property should use items as value that contain property “instance of (P31)”. On these, the value for instance of (P31) should be an item that uses subclass of (P279) with value administrative territorial entity (Q56061) (or a subclass thereof). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P131#Value type Q56061, SPARQL, SPARQL (new)
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.
List of this constraint violations: Database reports/Constraint violations/P131#Target required claim P17, SPARQL, SPARQL (by value), SPARQL (new)
None of Earth (Q2), rural settlement of Russia (Q634099): value must not be any of the specified items. (Help)
List of this constraint violations: Database reports/Constraint violations/P131#none of, hourly updated report, SPARQL, SPARQL (new)
Qualifiers “start time (P580), end time (P582), main regulatory text (P92), object has role (P3831), applies to part (P518), statement disputed by (P1310), reason for deprecation (P2241): this property should be used only with the listed qualifiers. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P131#Allowed qualifiers, SPARQL, SPARQL (new)
Contemporaries:
if [item A] has this property (located in the administrative territorial entity (P131)) linked to [item B],
then [item A] and [item B] have to coincide or coexist at some point of history. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P131#Contemporary, SPARQL (new)
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)

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

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)

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

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)

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)

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)

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)
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 no label (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)
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)

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)

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

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)

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)

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)

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)

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

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)

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 Territory (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)

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

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)

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

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)

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)
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)
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)
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)
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 (Spain) (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)
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)
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 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 object (Q618123) (or subclass of (P279) of).--Asqueladd (talk) 09:22, 21 June 2017 (UTC)
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)
  • 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)
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)
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)

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)

For a case where this would be needed, see: Talk:Q21130185.--Urjanhai (talk) 15:28, 9 July 2017 (UTC)
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)
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)
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 kommune (Q1324436)? We then have two items about a municipality named Trondheim. -- Innocent bystander (talk) 16:56, 9 July 2017 (UTC)
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)
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)
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)
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)
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)
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)
Ping still User:Stryn, User:Zache, User:Susannaanas, User:Raksa123.--Urjanhai (talk) 11:02, 13 July 2017 (UTC)
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)
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)
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)
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)

Incorrect inverse property mentioned[edit]

Should contains 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 (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)

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

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)

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

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)

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)

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)

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)

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)

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

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)

@99of9: probably not (not in itself at least), but do you have a specific example? Cdlt, VIGNERON (talk) 07:50, 7 September 2018 (UTC)
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)
@99of9: maybe location (P276). Could you give an example? Cdlt, VIGNERON (talk) 15:44, 7 September 2018 (UTC)

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)

I agree with Ysogo: if we use the highest administration unit, lower units are unnecessary. --Yiyi .... (talk!) 10:26, 2 September 2018 (UTC)
@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)
  • Why it so important for Russian community to specify only one, closest to item located in the administrative territorial entity (P131)? Because we have an algorithm which based on this rule and provides full geo-sequences to Wikipedia infoboxes. For example, Beauvais (Q174257), arrondissement of Beauvais (Q534383), Oise (Q12675), Picardy (Q13950), France (Q142) as birthplace of Aristide Bègue (Q4080542). It's weird to specify data in different ways in one database, this is the reason that the algorithm can not work for French personalities. I see this only in France, while Russia, Germany, the United States, Great Britain, everything works and is filled to Wikidata perfectly. As for the cantons, we were previously explained (for example, by Alphos (talkcontribslogs)) that this should be specified not as located in the administrative territorial entity (P131), but as territory overlaps (P3179). IMHO, we also we should think about creating a new property like electoral district (P768), but not for personalities, but for human settlements. Сидик из ПТУ (talk) 09:28, 6 September 2018 (UTC)
    • @Сидик из ПТУ: I understand your needs but couldn't you improve your algorithm ? (the infoboxes on fr.wp works fine even with multiple values) It's a bad idea to always expect one and only one value for a property (in general and for located in the administrative territorial entity (P131) in particular). For instance, for Beauvais (Q174257), I've added qualifiers (because the commune is in the département for a longer time than in the arrondissement), only one value doesn't seem possible (at least I don't see how). For the cantons, globally you're right, some of them must be move to territory overlaps (P3179) (and thank you a lot for moving them!), but maybe not all of them (the situation is very complicated since differents concepts name "canton", since 2014, the canton are only a electoral district but before that they were administrative unit and are perfectly fine in P131, it's even a more précise unit that the arrondissement, sometime more precise than the commune). And I like you idea of a electoral district (P768) but for territories, you should make a proposal to discuss it (I see some possible complication, a place can have like dozens if not hundred of circonscription but it's probably solvable).
      • Why "one and only one value for located in the administrative territorial entity (P131)" possible with any other country, but not with France? Why it can't be like in Chemnitz (Q2795), no label (Q12123651)? This exception only for France is not caused by anything and is not obvious to the casual user. Moreover, even the French cities are not always specified in the way that you are suggested to do. A more consensus option is to add start time (P580)=1795, end time (P582)=1800 for Oise (Q12675) at Beauvais (Q174257). And where is the 'fine infobox' at fr:Julien Absalon? I don't see region, département or country in his birthplace. Сидик из ПТУ (talk) 14:53, 6 September 2018 (UTC)
        • @Сидик из ПТУ: It's maybe possible for France but it's very difficult to determine what is the closest unit, for a long time, the canton was the closest unit but not anymore, now it's the arrondissement. But nobody knows or care about the cantons or arrondissements. That is why we choose to put the departement which is the relevant unit for P131. « end time (P582)=1800 for Oise (Q12675) at Beauvais (Q174257) » is plain wrong, that make absolutely no sense, do you have any source to support that? For Julien Absalon, the community clearly don't want the region (wich one?) or the country, but I could ask if the community would want to add the departement or not (probably not) for this infobox. Meanwhile, you can look at fr:Modèle:Infobox Monument, used on fr:Hôtel de ville de Beauvais for instance, the departement and the country is displayed fine. Cdlt, VIGNERON (talk) 07:38, 7 September 2018 (UTC)
          • OK, maybe French community doesn't want full path for infox's birthplace, but it's consensus for Russian community. You can see that for any other countries periods in P131 means only times when this units were closest. Below you can see my question about what has changed with the role of the cantons in 2014/2015. If only their boundaries have changed, then new ones and old ones must be sent to another property. Сидик из ПТУ (talk) 09:05, 7 September 2018 (UTC)
            • Yes the French community doesn't want administrative units that nobody - even French people - knows. If the Russian community want the full path, just add it! As I showed you with the other infoboxes (where some administrativ units are kind of relevant), this is possible even with multiple values. And no, in 2013-2015 the boudaries change but the role and definition of the concept canton changed too, that why we have two items : canton of France (Q18524218) (since 2015, electoral subdivision only) and canton of France (until 2015) (Q184188) (before 2015, both administrative and electoral subdivision). Cdlt, VIGNERON (talk) 14:49, 7 September 2018 (UTC)
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) View with Reasonator View with SQID, located in the administrative territorial entity (P131) View with Reasonator View with SQID, end time (P582) View with Reasonator View with SQID
     1 SELECT  ?commune ?departement WHERE {
     2   ?commune p:P31 ?communeStatement . # les trucs qui sont potentiellement
     3   ?communeStatement ps:P31 ?type . # ...un des types autorisés ci-dessous
     4   VALUES ?type {
     5     wd:Q484170 # commune française
     6     wd:Q2989454 # commune nouvelle
     7     wd:Q22927616 # commune française à statut particulier
     8   }
     9   FILTER NOT EXISTS {
    10     ?communeStatement pq:P582 [] . # mais alors vraiment des communes pur cru, sans date de fin
    11   }
    12   ?commune p:P131 ?communeArrondissementStatement . # qui sont dans un arrondissement
    13   ?communeArrondissementStatement ps:P131 ?arrondissement .
    14   ?arrondissement wdt:P31 wd:Q194203 .
    15   FILTER NOT EXISTS { # qui y sont pour de vrai
    16     ?communeArrondissementStatement pq:P582 [] .
    17   }
    18   ?arrondissement p:P31 ?arrondissementExistsStatement . # un arrondissement sans date de fin
    19   ?arrondissementExistsStatement ps:P31 wd:Q194203 .
    20   FILTER NOT EXISTS {
    21     ?arrondissementExistsStatement pq:P582 [] .
    22   }
    23   ?arrondissement p:P131 ?arrondissementDepartementStatement . # qui est dans un département
    24   ?arrondissementDepartementStatement ps:P131 ?departement . 
    25   FILTER NOT EXISTS { # mais qui y est sans date de fin
    26     ?arrondissementDepartementStatement pq:P582 [] .
    27   }
    28   ?departement p:P31 ?departementExistsStatement . # un département sans date de fin 
    29   ?departementExistsStatement ps:P31 ?departementType .
    30   FILTER NOT EXISTS {
    31     ?departementExistsStatement pq:P582 [] .
    32   }
    33   VALUES ?departementType {
    34     wd:Q6465 #département de France métropolitaine
    35     wd:Q28332 # département/région ultramarin
    36   }
    37 }
    


Whereas this one does not :
see the query
The following query uses these:
  • Properties: instance of (P31) View with Reasonator View with SQID, located in the administrative territorial entity (P131) View with Reasonator View with SQID, end time (P582) View with Reasonator View with SQID
     1 SELECT  ?commune ?departement WHERE {
     2   ?commune p:P31 ?communeStatement . # les trucs qui sont potentiellement
     3   ?communeStatement ps:P31 ?type . # ...un des types autorisés ci-dessous
     4   VALUES ?type {
     5     wd:Q484170 # commune française
     6     wd:Q2989454 # commune nouvelle
     7     wd:Q22927616 # commune française à statut particulier
     8   }
     9   FILTER NOT EXISTS {
    10     ?communeStatement pq:P582 [] . # mais alors vraiment des communes pur cru, sans date de fin
    11   }
    12   ?commune p:P131 ?communeDepartementStatement . # qui sont dans un département
    13   ?communeDepartementStatement ps:P131 ?departement . 
    14   FILTER NOT EXISTS { # mais qui y sont sans date de fin
    15     ?communeDepartementStatement pq:P582 [] .
    16   }
    17   ?departement p:P31 ?departementExistsStatement .
    18   FILTER NOT EXISTS {
    19     ?departementExistsStatement pq:P582 [] . # un département sans date de fin 
    20   }
    21   ?departementExistsStatement ps:P31 ?departementType .
    22   VALUES ?departementType {
    23     wd:Q6465 # département de France métropolitaine
    24     wd:Q28332 # ou ultramarin
    25   }
    26 }
    


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)
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)
@Сидик из ПТУ: 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)
Cantons were the closest administrative (not only electoral) unit in France until 2014 (or 2015)? Сидик из ПТУ (talk) 07:23, 7 September 2018 (UTC)
@Сидик из ПТУ: 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)
@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)
@Сидик из ПТУ: 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)
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)
@Сидик из ПТУ: 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)
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)
@Сидик из ПТУ: 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), no label (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)
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 no label (Q12123651) do not intersect in time and at each moment of time are single. Сидик из ПТУ (talk) 10:35, 15 September 2018 (UTC)
@Сидик из ПТУ: 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)
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)
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)

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)

I'd like to second this - not sure why the constraint says these are in conflict. -- Fuzheado (talk) 20:07, 10 September 2018 (UTC)
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)
@ArthurPSmith: We have operating area (P2541) for indicating the operating locations... --Yair rand (talk) 15:52, 17 October 2018 (UTC)