Property talk:P159

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

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:

• http://ru.wikipedia.org/w/index.php?title=Yahoo!&diff=54285975&oldid=54279641&diffonly=1

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

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

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

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

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

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

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

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

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

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:

• For a university and its campus, I'd probably create separate items that are instances of university campus (Q30785519), then link them with part of (P361) and has part(s) (P527) to University of Valencia (Q383568). I don't think headquarters location (P159) is the right property for describing university campus locations. Daask (talk) 13:02, 27 December 2020 (UTC)Reply

• Daask (talk) 13:02, 27 December 2020(UTC)

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:

⟨ University of Valencia (Q383568)      ⟩ headquarters location (P159)   ⟨ Valencia (Q8818)      ⟩
location (P276)   ⟨ Universitat de València doctorate (Q11911331)      ⟩
object of statement has role (P3831)   ⟨ seat (Q470540)      ⟩

⟨ University of Valencia (Q383568)      ⟩ headquarters location (P159)   ⟨ Burjassot (Q55688)      ⟩
location (P276)   ⟨ campus Burjassot/Paterna (Q104523102)      ⟩
object of statement has role (P3831)   ⟨ university campus (Q30785519)      ⟩

⟨ University of Valencia (Q383568)      ⟩ headquarters location (P159)   ⟨ Valencia (Q8818)      ⟩
location (P276)   ⟨ Campus de Blasco Ibáñez (Q104523211)      ⟩
object of statement has role (P3831)   ⟨ university campus (Q30785519)      ⟩

Example of sport club:

⟨ FC Barcelona (Q7156)      ⟩ headquarters location (P159)   ⟨ Sant Joan Despí (Q15640)      ⟩
location (P276)   ⟨ Ciutat Esportiva Joan Gamper (Q1094423)      ⟩
object of statement has role (P3831)   ⟨ sports complex (Q7579839)      ⟩
coordinate location (P625)   ⟨ 41°22'33"N, 2°3'8"E ⟩

⟨ FC Barcelona (Q7156)      ⟩ headquarters location (P159)   ⟨ Barcelona (Q1492)      ⟩
object of statement has role (P3831)   ⟨ seat (Q470540)      ⟩
coordinate location (P625)   ⟨ 41°22'48"N, 2°7'12"E ⟩
street address (P6375)   ⟨ Arístides Maillol s/n, 08028 ⟩

Example of social society (several HQ changes):

⟨ Q11914618      ⟩ headquarters location (P159)   ⟨ Vila de Gràcia (Q2741611)      ⟩
object of statement has role (P3831)   ⟨ seat (Q470540)      ⟩
series ordinal (P1545)   ⟨ 1 ⟩
start time (P580)   ⟨ 1901 ⟩
end time (P582)   ⟨ 1936 ⟩
subject named as (P1810)   ⟨ Can Garcia ⟩
street address (P6375)   ⟨ Carrer Bonavista, Barcelona ⟩
coordinate location (P625)   ⟨ 41°23'57.92352"N, 2°9'32.36029"E ⟩

⟨ Q11914618      ⟩ headquarters location (P159)   ⟨ Vila de Gràcia (Q2741611)      ⟩
object of statement has role (P3831)   ⟨ seat (Q470540)      ⟩
series ordinal (P1545)   ⟨ 2 ⟩
start time (P580)   ⟨ 1944 ⟩
end time (P582)   ⟨ 1950 ⟩
subject named as (P1810)   ⟨ Can Passa ⟩
street address (P6375)   ⟨ Francisco Giner, 32, 08012 ⟩
coordinate location (P625)   ⟨ 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

• How does this copy-pasted discussion apply to this property? What definition of "headquarters" are you using? --- Jura 12:01, 5 May 2021 (UTC)Reply

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

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

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

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