Property talk:P159

From Wikidata
Jump to navigation Jump to search

Documentation

headquarters location
city or town where an organization's headquarters is or has been situated. Use P276 qualifier for specific building
DescriptionLocation of an organization's head office - headquarters (Q7540126) For administrative territorial entities use capital (P36).
Representsheadquarters (Q7540126), siège social réel (Q7533476), seat (Q470540), episcopal see (Q866196), titular see (Q15217609)
Data typeItem
Template parameter|headquarters= in en:template:Infobox organization
Domainorganization (Q43229), fictional organization (Q14623646), newspaper (Q11032), administrative territorial entity (Q56061), periodical (Q1002697), fictional company (Q5446565), website (Q35127), company (Q783794), government agency (Q327333), governing body (Q895526), brand (Q431289), presidential transition (Q104921473), project (Q170584), festival (Q132241), district (Q149621), campaign (Q6056746), event (Q1656682), competition (Q841654), urban area (Q702492), business (Q4830453), former entity (Q15893266) or defunct organization (Q55097243)
Allowed valuesgeographic location (Q2221906) (note: this should be moved to the property statements)
ExampleOrganization of the Petroleum Exporting Countries (Q7795) → Vienna (Q1741)
Wikimedia Foundation (Q180) → San Francisco (Q62)
Shell (Q154950) → London (Q84)
Santos Futebol Clube (Q7420622) → João Pessoa (Q167436)
Baranagore Ramakrishna Mission Ashrama High School (Q19882251) → Belur Math (Q816234)
Social Democratic Party of Germany (Q49768) → Berlin (Q64)
SourceOfficial website or reliable third party sources (note: this information should be moved to a property statement; use property source website for the property (P1896))
Tracking: sameno label (Q42533318)
Tracking: differencesno label (Q55283116)
Tracking: usageCategory:Pages using Wikidata property P159 (Q23908995)
Tracking: local yes, WD nono label (Q32765319)
See alsolocation of formation (P740), location (P276), occupant (P466), work location (P937), capital (P36)
Lists
Proposal discussionProposal discussion
Current uses
Total632,296
Main statement630,50799.7% of uses
Qualifier1,7590.3% of uses
Reference30<0.1% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
Type “organization (Q43229), fictional organization (Q14623646), newspaper (Q11032), administrative territorial entity (Q56061), periodical (Q1002697), fictional company (Q5446565), website (Q35127), company (Q783794), government agency (Q327333), governing body (Q895526), brand (Q431289), presidential transition (Q104921473), project (Q170584), festival (Q132241), district (Q149621), campaign (Q6056746), event (Q1656682), competition (Q841654), urban area (Q702492), business (Q4830453), former entity (Q15893266), defunct organization (Q55097243)”: item must contain property “instance of (P31)” with classes “organization (Q43229), fictional organization (Q14623646), newspaper (Q11032), administrative territorial entity (Q56061), periodical (Q1002697), fictional company (Q5446565), website (Q35127), company (Q783794), government agency (Q327333), governing body (Q895526), brand (Q431289), presidential transition (Q104921473), project (Q170584), festival (Q132241), district (Q149621), campaign (Q6056746), event (Q1656682), competition (Q841654), urban area (Q702492), business (Q4830453), former entity (Q15893266), defunct organization (Q55097243)” or their subclasses (defined using subclass of (P279)). (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P159#Type Q43229, Q14623646, Q11032, Q56061, Q1002697, Q5446565, Q35127, Q783794, Q327333, Q895526, Q431289, Q104921473, Q170584, Q132241, Q149621, Q6056746, Q1656682, Q841654, Q702492, Q4830453, Q15893266, Q55097243, SPARQL
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P159#Value type Q618123, Q3895768, Q42889, Q15642541, Q484652, SPARQL
Qualifiers “postal code (P281), located on street (P669), house number (P670), located in the administrative territorial entity (P131), country (P17), location (P276), coordinate location (P625), start time (P580), end time (P582), street address (P6375), point in time (P585), located in/on physical feature (P706), Google Maps Customer ID (P3749), conscription number (P4856), floor number (P5423), valid in period (P1264), reason for deprecated rank (P2241), applies to jurisdiction (P1001), has cause (P828), post office box (P2918), latest date (P1326), earliest date (P1319), series ordinal (P1545), reason for preferred rank (P7452), end cause (P1534), latest start date (P8555), earliest end date (P8554), object of statement has role (P3831), subject named as (P1810), image (P18), has characteristic (P1552), nature of statement (P5102), Unique Property Reference Number (P8399), has facility (P912), room number (P7532), located in statistical territorial entity (P8138), OpenStreetMap way ID (P10689), provisional house number (P6529), applies to name of subject (P5168), Google Knowledge Graph ID (P2671), post town (P4595), statement supported by (P3680), OpenStreetMap node ID (P11693), OpenStreetMap relation ID (P402), object named as (P1932), ‎latest end date (P12506), phone number (P1329)”: this property should be used only with the listed qualifiers. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P159#allowed qualifiers, SPARQL
Contemporaries:
if [item A] has this property (headquarters location (P159)) 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. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P159#Contemporary, SPARQL
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
List of violations of this constraint: Database reports/Constraint violations/P159#Entity types, hourly updated report
Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P159#Scope, SPARQL
This property is being used by:

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

Suggested use

[edit]

Use the most specific location known, such as the building item, otherwise use the street or city (town, village, or other administrative division item). Danrok (talk) 00:43, 27 February 2013 (UTC)[reply]

Can this be opened up to buildings (as opposed to entire cities) that had notably been headquarters for a given organization? See Q1969696 for an example of what I mean. Shawn in Montreal (talk) 01:22, 27 February 2013 (UTC)[reply]
That situation applies to many properties. As far as I know we should list all past and present items. We should be seeing "qualifiers" at some point which allows further detail to be given. See here: Qualifiers. Danrok (talk) 01:43, 27 February 2013 (UTC)[reply]
Is my revision to the description okay, then? Shawn in Montreal (talk) 01:46, 27 February 2013 (UTC)[reply]
Yes. I am also wondering if it is possible for an organization to have more than one current HQ. But have found an example so far. Danrok (talk) 01:53, 27 February 2013 (UTC)[reply]
Look no further than my goofy town. Several of Canada's chartered banks have retained a legal HQ in Montreal, while having moved their "operational HQ" to the bustling city of Toronto, decades ago... Shawn in Montreal (talk) 01:55, 27 February 2013 (UTC)[reply]

Suggested improvement

[edit]

It should be split into something like "Headquarter location (city)", "Headquarter location (province/state)", "Headquarter location (country)", and even "Headquarter location (building)" or "Headquarter location (address)". The reason can be seen in this edit in ru.wp's Yahoo! page that I edited earlier:

I changed the headquarter city from Sunnyville to this P159, while keeping the "California" state, "USA" country, and the country flag intact; but let say in the future the headquarter moved to another country, say Moscow, Russia, then when Yahoo's Wikidata property is update, the infobox would show as Moscow, California, USA. Bennylin (talk) 11:42, 28 March 2013 (UTC)[reply]

+1. Right now this property is used for cities and buildings. There should be a property: "Location of a company" (= headquarter) and "Main building(s) of a company". --Kolja21 (talk) 11:27, 5 April 2013 (UTC)[reply]
 Oppose The value should be the most specific possible, and the other things (e.g. city where a building is), should be derived in a query by following the chain. Superm401 - Talk 18:35, 8 April 2013 (UTC)[reply]
 Oppose As said, just enter the most specific location item available. Ideally that would be the building, failing that the street may have an it's own wikipedia article. Most probably we can create items for some streets/buildings, even if there is no wikipedia article. Danrok (talk) 02:13, 19 May 2013 (UTC)[reply]
Policy is here Wikidata:Notability. Seems to me that we can create items for pretty much any street or building. Danrok (talk) 02:16, 19 May 2013 (UTC)[reply]
 Oppose. If the building or the street already has an article (60 Wall Street (Q247887), Wall Street (Q11690), K Street (Q6342989)) then by all means link to that. Otherwise the local administrative unit is appropriate. Although we cannot, at the moment, link from an infobox to the larger admin units associated with the unit shown on the wikidata page, this functionality will be added in the next few months. In the mean time policy is to just link to the most local item. Filceolaire (talk) 22:21, 19 August 2013 (UTC)[reply]

Use with streets ?

[edit]

Addresses of buildings are generally provided though located on street (P669) or P969 (P969). What should we do when we want to provide the address of the headquarter, use headquarters location (P159), the same way as located on street (P669), with a house number (P670) qualifier ? --Zolo (talk) 16:00, 6 March 2015 (UTC)[reply]

Typing error

[edit]

(P159) has a typing error: Organsisationszentrale --Ziltoidium (talk) 06:08, 10 November 2015 (UTC)[reply]


Sample to add

[edit]

Currently there is no sample for organizations that are only active at a single location. Supposedly these would use the property as well.
--- Jura 15:14, 8 January 2016 (UTC)[reply]

✓ Done. I also added a sample with company, dropped a redundant one and moved the whole to statements.
--- Jura 10:20, 9 January 2016 (UTC)[reply]

Using with P131 at universities

[edit]

It's arguable but what if university consists of one building (or several but situated at one region)? Why not to show that it is situated in some region? If not, how to reflect this otherwise? --Infovarius (talk) 10:35, 30 May 2018 (UTC)[reply]

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

[edit]

Cross-reference: see Property talk:P131#why is the declaration of P131 (administrative location) incompatible with the declaration of P159 (headquarters location) ?. This restriction against located in the administrative territorial entity (P131)+headquarters location (P159) on the same item is simply wrong: there are about 15000 items correctly specifying the two declarations, which are orthogonal/independant. Verdy p (talk) 00:00, 10 September 2018 (UTC)[reply]

I guess this constraint was added to ensure that organizations only use headquarters location (P159) and not located in the administrative territorial entity (P131). @Jklamo: --Pasleim (talk) 11:25, 10 September 2018 (UTC)[reply]
Yes. Organization/company is legal entity, thus is not located in the administrative territorial entity (P131), just its headquarters is located somewhere, so headquarters location (P159) is only correct way to record this.--Jklamo (talk) 22:06, 16 September 2018 (UTC)[reply]
Made it a suggested constraint because this made people mess up items. Multichill (talk) 16:26, 8 June 2019 (UTC)[reply]
Many organizations also have a very specific location that is even in their name. New York City Council will always in New York. Although in theory this is fine -- somewhere in hierarchy the city will be there. In practice it makes queries hard. Also note that this is just plain wrong because country (P17) is still recommended. I see no difference here. A city has the same relation as country to institutions. This is just not how you build databases in practice. In theory you could build a relative database with no repetitions. In practice you always have repetitions, because it is not practical to always fetch 12 tables to get that one thing you always need. --Nux (talk) 22:25, 25 January 2020 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I agree with Nux, if country (P17) is allowed, and even recommended, then located in the administrative territorial entity (P131) should have the same status. I find this property useful and meaningful especially to represent the administrative territorial entity (Q56061) responsible for registering the incorporation of the organization. I would welcome a different property to represent this information. (I think I've seen such proposals. Can anyone link to a relevant discussion?) Daask (talk) 13:48, 25 September 2022 (UTC) After reviewing this discussion and Property talk:P131#why is the declaration of P131 (administrative location) incompatible with the declaration of P159 (headquarters location) ?, it seems to me that there is consensus to remove this constraint, so I'm going to be bold and do it. Feel free to continue discussing. Daask (talk) 13:48, 25 September 2022 (UTC)[reply]

Hello, this is a mistake. An organization is not a physical entity, that's why it can't have a location. There are multiple ways an organization can be related to places, headquarters is one of them. Arpyia (talk) 17:53, 25 September 2022 (UTC)[reply]

allowed qualifiers constraint ISO 3116-2

[edit]

Wouldn't it be good to have "ISO 3116-2" (P300) as an allowed qualifier for headquarter? --Newt713 (talk) 20:17, 18 September 2019 (UTC)[reply]

property description and the documentation on this talk page

[edit]

The current property description is

specific location where an organization's headquarters is or has been situated. Inverse property of "occupant" (P466).

which indicates that it should be a building, structure (man-made or natural), or other self-contained physical location. This is, anything that can one can be an occupant of, as clearly stated in the description. But the examples given in the documentation are all geographic locations. Is a company an occupant of San Francisco? Is a city a specific location? What about a state or region? Perhaps this discontinuity comes from Wikipedia's use of the term "based in" to mean "headquarters in" (en:Category:Companies based in Miami) or Commons use of headquarters is a subcategory of office building (commons:Category:Headquarters). Senator2029 17:51, 2 July 2020 (UTC)[reply]

Clarified. See also P159 note at Wikidata:WikiProject Companies/Properties. --Jklamo (talk) 13:35, 29 August 2020 (UTC)[reply]

Allow new qualifier.

[edit]

I added object of statement has role (P3831) as a allowed qualifier of P159, in order to indicate which kind of headquarter is. For instance, siège social réel (Q7533476), seat (Q470540), university campus (Q30785519), distribution center (Q1229659) or whatever else. You can see two real cases in this university and its campus or this club with HQ in no specific P276 and the sports complex (not the home venue (P115)) with a specific item. Thanks, Amadalvarez (talk) 18:53, 27 December 2020 (UTC)[reply]

Ontology to hold a multi-value and its qualifiers

[edit]

This entry describe the way to build a correct qualifiers set for P159, specially when it is multivalue, to hold different venues of an organisation. It comes from a discussion of Wikidata:Property proposal/corporate domicile that, finally, was withdrawn in favor to use P159 with this structure.

Copied from the mentioned discussion:

Basically it consists to have one headquarters location (P159) for each HQ (not branch office (Q1880737) nor those cover by has subsidiary (P355)) gathering all the information as qualifiers as described in Wikidata:WikiProject Companies/Properties. It, optionally, may include location (P276) when it has a "HQ building", that may have their own properties for some or all of the qualifiers that describe HQ, making unnecessary them, in this case. In addition, to assign the type of HQ it is (corporate, operational, campus, etc.) I use object of statement has role (P3831) as a qualifier of each entry of P159. You can see two real cases in this university and its campus or this club with HQ in no specific P276 and the sports complex (not the home venue (P115)) with a specific item. Your comments will be wellcome. Thanks, Amadalvarez (talk) 12:24, 27 December 2020 (UTC)[reply]
  •  Comment @Amadalvarez: I think you have come up with a good solution for the issue described on this page of how to model different types of corporate headquarters. Nice work. I still think it's worthwhile to have separate properties rather than the qualifier for headquarters location (P159). In the meantime, I think your solution is acceptable.
  • Regarding your examples:
Thanks, @Daask: for your answer. In the campus case, I avoid to use P527 because it's a multi-use property and we may have conflicts with some other use/meaning. In the university it use to contain the faculties, it is, the studies concept, not physical location of them that may be or not included within a campus. To me, campus is the space, the continent of faculties, libraries, residence, etc.Thanks, again. Amadalvarez (talk) 17:22, 27 December 2020 (UTC)[reply]

End of discussion copied here

Example of university campus:
Example of sport club:
⟨ FC Barcelona (Q7156)  View with Reasonator View with SQID ⟩ headquarters location (P159) View with SQID ⟨ Barcelona (Q1492)  View with Reasonator View with SQID ⟩
object of statement has role (P3831) View with SQID ⟨ seat (Q470540)  View with Reasonator View with SQID ⟩
coordinate location (P625) View with SQID ⟨ 41°22'48"N, 2°7'12"E ⟩
street address (P6375) View with SQID ⟨ Arístides Maillol s/n, 08028 ⟩
Example of social society (several HQ changes):
⟨ Q11914618  View with Reasonator View with SQID ⟩ headquarters location (P159) View with SQID ⟨ Vila de Gràcia (Q2741611)  View with Reasonator View with SQID ⟩
object of statement has role (P3831) View with SQID ⟨ seat (Q470540)  View with Reasonator View with SQID ⟩
series ordinal (P1545) View with SQID ⟨ 1 ⟩
start time (P580) View with SQID ⟨ 1901 ⟩
end time (P582) View with SQID ⟨ 1936 ⟩
subject named as (P1810) View with SQID ⟨ Can Garcia ⟩
street address (P6375) View with SQID ⟨ Carrer Bonavista, Barcelona ⟩
coordinate location (P625) View with SQID ⟨ 41°23'57.92352"N, 2°9'32.36029"E ⟩
⟨ Q11914618  View with Reasonator View with SQID ⟩ headquarters location (P159) View with SQID ⟨ Vila de Gràcia (Q2741611)  View with Reasonator View with SQID ⟩
object of statement has role (P3831) View with SQID ⟨ seat (Q470540)  View with Reasonator View with SQID ⟩
series ordinal (P1545) View with SQID ⟨ 2 ⟩
start time (P580) View with SQID ⟨ 1944 ⟩
end time (P582) View with SQID ⟨ 1950 ⟩
subject named as (P1810) View with SQID ⟨ Can Passa ⟩
street address (P6375) View with SQID ⟨ Francisco Giner, 32, 08012 ⟩
coordinate location (P625) View with SQID ⟨ 41°22'48"N, 2°7'12"E ⟩

In these cases, the HQ is not on a representative building (P276), but has a nickname (P1810)

Thanks to @Susannaanas, Daask, JesseW:. Amadalvarez (talk) 19:39, 24 March 2021 (UTC)[reply]

Redundant qualifiers

[edit]

Daask returned located in the administrative territorial entity (P131) and country (P17) qualifiers for Winnipeg (Q2135) statement and called my edit "Unexplained removal of content". I find adding these qualifiers unexplained, redundant and dead end. For example, Moscow (Q649) stated as headquarters location (P159) for Sukhoi Design Bureau (Q387017) but in 1991 it changes country (P17) from Soviet Union (Q15180) to Russia (Q159). Respectively, should we gave two headquarters location (P159) statements with different country (P17) qualifiers here? No, located in the administrative territorial entity (P131) and country (P17) statements for Moscow (Q649) should be given only at Moscow (Q649) item. It's enough. Otherwise, we should add qualifiers like continent (P30) and flag image (P41) to country (P17) statement of Centre for Mennonite Brethren Studies (Q106474063) and qualifiers like date of birth (P569) and occupation (P106) to all spouse (P26) statements. Сидик из ПТУ (talk) 08:11, 31 January 2022 (UTC)[reply]

I don't suggest that these qualifiers be required. I realize that if the country changed during the existence of the item in question then it may be ambiguous, and should probably be omitted. However, I believe these qualifiers are useful for headquarters location (P159) so that a complete mailing address can be created using solely from the property and its qualifiers without needing to perform a query on Winnipeg (Q2135) to determine its associated province and country. I think it's preferable that these qualifiers be included on most values of headquarters location (P159). Daask (talk) 12:26, 2 February 2022 (UTC)[reply]
Help me understand the use case here. Why is it important to get a complete mailing address from a single P159 statement? Ghuron (talk) 17:34, 2 February 2022 (UTC)[reply]
@Ghuron: Let's imagine that I want coordinate location information, perhaps because I am mapping the locations of nonprofits headquartered in Moscow, or perhaps just because I am writing a script to add a coordinate location (P625) qualifier to all properties headquarters location (P159). There isn't enough information to determine the location with just the label of the value of headquarters location (P159) and a street address (P6375) qualifier. As Сидик из ПТУ observes, it can be obtained from the properties of the headquarters location (P159) value, but why not include it as a qualifier to headquarters location (P159) as well? It eliminates the need for further queries, and makes the data more readable for humans as well. Daask (talk) 19:51, 3 February 2022 (UTC)[reply]
a) For Moscow, this is still guaranteed to not work, that is, the algorithm, whatever it may be, cannot rely on it. Thereafter, we get a more dirty and overloaded algorithm. b) Many places can have not one, but several hierarchically arranged and inconstant in time administrative territorial entity (Q56061), that is, we still cannot build the correct sequence for the address from the plain qualifiers. For example, Buxton (Q5003259) → Buxton with Lamas (Q5003287) → Broadland (Q2116353) → Norfolk (Q23109) → East of England (Q48006) → England (Q21) → United Kingdom (Q145) or somethink like Kitikmeot Region (Q1457954) → Nunavut (Q2023). c) This can be declared "useful" for almost any qualifier of any property, starting with the example of a spouse (P26) and its date of birth (P569) above and so on. Сидик из ПТУ (talk) 20:22, 3 February 2022 (UTC)[reply]
A basic principle for databases is to avoid redundancy, because a) they waste space, and b) they inevitably lead to inconsistency at some point (someone adds, modifies or deletes data at one place but forgets to do so at the other one). And SPARQL makes it quite easy to query all entities headquartered in Moscow: 
SELECT ?item ?itemLabel WHERE {
	?item wdt:P159/wdt:P131* wd:Q649.
	SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!
—Tacsipacsi (talk) 16:42, 5 February 2022 (UTC)[reply]
@Tacsipacsi: My use case is not to list all entities headquartered in Moscow, but to produce a mailing address for all entities headquartered in Moscow. Daask (talk) 15:26, 6 February 2022 (UTC)[reply]
We in Russia love to rename the streets (Q1644209#P138), cities (Q891#P138)… How do you propose to respond to these changes and store archive mailing addresses? It is obvious that the most reasonable thing would be to store the history of located in the administrative territorial entity (P131) and names centrally for each house, street, city, etc. Сидик из ПТУ (talk) 13:01, 11 February 2022 (UTC)[reply]
@Сидик из ПТУ: Renaming streets and cities is not in question in this conversation, as the statement is Centre for Mennonite Brethren Studies (Q106474063)headquarters location (P159)Winnipeg (Q2135) whatever name Winnipeg (Q2135) is given. So far in this conversation, no one has questioned the use of street address (P6375) as a qualifier for headquarters location (P159), which would be affected by street renaming but can't be readily replaced with a name-agnostic version for streets that aren't on Wikidata and thus can't use located on street (P669).
This conversation is solely about the use of located in the administrative territorial entity (P131) and country (P17) as qualifiers for headquarters location (P159). Admittedly, they may change over time, but in many areas they are highly stable. I think it should be a matter of editorial discretion whether they are omitted or included, and I don't think they should be removed automatically or wantonly. Daask (talk) 17:48, 3 August 2024 (UTC)[reply]

Constraints in conflict regarding postal code property

[edit]

In regards to postal code (P281), it is an allowed qualifiers constraint (Q21510851), but yet it is also conflicts-with constraint (Q21502838). Is this a problem that needs to be fixed? Senator2029 21:11, 27 October 2022 (UTC)[reply]

I don’t think so. According to the description of conflicts-with constraint (Q21502838), it defines that an item must not have a given statement – however, qualifiers are not statements. The conflicts-with constraint (Q21502838) expresses that something is either an organization, and then it has a headquarters location, or it’s a location itself, and then it may have a postal code. Organizations themselves don’t have postal codes, only locations owned or used by them. —Tacsipacsi (talk) 00:30, 28 October 2022 (UTC)[reply]

Conflict with P276 (location)

[edit]

There is a conflicts-with constraint (Q21502838) with location (P276), however, it is rather common for an organization to have different officially registered headquarters and as well as other relevant premises, such as client-facing offices. Tdombos (talk) 14:58, 21 February 2023 (UTC)[reply]

Removed them. No consensus to have these and source of counter productive edits. Multichill (talk) 14:19, 24 December 2023 (UTC)[reply]

Inverse property

[edit]

The inverse property is a Wikidata item (Q107586854), not a property. Cannot be used. PePeEfe (talk) 09:19, 15 September 2023 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P159&oldid=2269593816"