Wikidata

Wikidata:Property proposal/hierarchy switch

< Wikidata:Property proposal

next level in hierarchy edit

Originally proposed at Wikidata:Property proposal/Generic

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 Wikidata property (Q18647515) with hierarchy (Q188619)
Example 1111
Example 2
Example 3
Planned usefor select only right values in cases like A → B → (C and D) where C is right for A but D isn't
See alsoterritory overlaps (P3179)

Motivation edit

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[reply]

Discussion edit

  WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

    • 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)[reply]
  •   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)[reply]
Not that P30 matters, but the English label for P30 has just "continent", not "located in continent". --- Jura 11:20, 19 February 2020 (UTC)[reply]
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 areas… Some 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)[reply]
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)[reply]
I suppose we will keep disagreeing on that. --- Jura 17:31, 19 February 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
  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)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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)[reply]

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)[reply]
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)[reply]
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)[reply]
Сидик из ПТУ 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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
@Сидик из ПТУ: How does an interposed subentity of Atlanta make it harder to find all Atlanta bus stops? —Scs (talk) 13:06, 24 February 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
You mean, you assume that. --- Jura 11:08, 24 February 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
Ah, okay, now I get it: You want P131 to mean "is an administrative subdivision of". That makes sense.
Or, stated another way, P131 represents a direct child relationship, and the proposed new property simply represents a grandchild relationship, for use in cases where we can't properly describe the situation with two ordinary child relationships. (Indeed, we've got some similarly redundant tags for people. Normally we represent human grandchildren as a pair of child (P40) properties, and siblings as two people having the same parent(s), but if we don't have an entity for the parent, we can use kinship to subject (P1039) along with grandchild (Q3603531), sibling (Q31184), etc.) —Scs (talk) 16:36, 2 March 2020 (UTC)[reply]
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)[reply]
  •   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)[reply]
Thank you. I apologize for my naïveté about the potential power of complex SPARQL queries. —Scs (talk) 11:32, 27 February 2020 (UTC)[reply]
  • 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)[reply]
@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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I think you could make an argument to add it as a qualifier to those properties, sure. If you wanted to query all of the people born in DeKalb County (Q486398), you could get results of people who were born in Atlanta (Q23556) with a qualifier of next level in hierarchy of DeKalb County (like someone born at Emory University Hospital (Q5373728), which is in Atlanta and DeKalb County). I could also see it being useful for historical cases, where someone was born in a city when it had a different administrative territorial entity in the next level in the hierarchy. The statement would be true, and it would also make querying easier. Clifflandis (talk) 15:06, 27 February 2021 (UTC)[reply]
The question is about entries like the place of birth of George Washington: Q23#P19 which is currently given as Westmoreland County (Q494413) and qualified with "Great Britain" and "Colony of Virginia". It's not something I advise on doing, but it seems to be a usecase for this qualifier as well. Apparently, these kind of qualifiers are added by ruwiki users to ensure their infobox can easily find the items. At some point there was a bot adding them, but it was blocked as it was considered not suitable approach. Users still keep adding them manually though. --- Jura 08:14, 28 February 2021 (UTC)[reply]
I don't think this proposed hierarchy switch qualifier should be used in cases like Q23#P19. The qualifiers there isn't really necessary since the correct administrative units and country can be found from Westmoreland County (Q494413) together with the time of birth. But if qualifiers are used at Q23#P19 anyway the hierarchy switch would make no sense. In such cases you would need to use located in the administrative territorial entity (P131) as the qualifier. By instead using the hierarchy switch qualifier there would be no indication that the value is an administrative unit and it wouldn't be clear what the qualifier was about. --Dipsacus fullonum (talk) 12:14, 28 February 2021 (UTC)[reply]
Is there anything in the proposal that excludes its use? Why not also use P131 as qualifier in the samples of the proposal above? --- Jura 15:15, 28 February 2021 (UTC)[reply]
Yes, undefined meaning excludes it use that way. Is there anything in the proposal that justifies its use as qualifier to place of birth (P19)? No! How should a hierarchy switch qualifier to George Washington (Q23) place of birth (P19) Westmoreland County (Q494413) be interpreted? There would no indication about what kind of hierarchy it is refering to. --Dipsacus fullonum (talk) 15:30, 28 February 2021 (UTC)[reply]
Actually, "transitive property" excludes it. So location (P276) or located in/on physical feature (P706) would be ok, but not P19 [6]. --- Jura 15:44, 28 February 2021 (UTC)[reply]
@Jura1: do you think there's enough of a use case to support this qualifier for P131, or do you think it's still inappropriate? I'm curious if the conversation over the last year has shifted your opinion any, or if your concerns still stand. Thanks! Clifflandis (talk) 15:30, 2 March 2021 (UTC)[reply]
Russian Wikipedia community opposes the located in the administrative territorial entity (P131) and country (P17) to be added as qualifiers to place of birth (P19) and place of death (P20). The historically correct hierarchy chain for our infoboxes is calculated taking into account the dates of birth and death. So we do not need any qualifiers for Q23#P19. Proposed property needed only for cases like with Atlanta with two next levels in hierarchy at the same time, not for historical cases. Сидик из ПТУ (talk) 09:45, 4 March 2021 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/hierarchy_switch&oldid=1554461445"