Wikidata:Property proposal/hierarchy switch

next level in hierarchyEdit

Return to Wikidata:Property proposal/Generic

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

MotivationEdit

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

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

DiscussionEdit

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

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

  Notified participants of WikiProject Ontology

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

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

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