Property talk:P969

From Wikidata
Jump to navigation Jump to search

This property is being considered for deletion. Please share your thoughts on the matter at this property's entry on the Properties for deletion page.


Documentation

located at street address
full street address that the subject is located at. Include building number through to post code. Use also P669 if the street is known as a separate element
Descriptionstreet address of item. Compare with located on street (P669) and its qualifier street number (P670).
Representsstreet address (Q24574749), address (Q319608)
Data typeString
Template parameteraddress in voy:Template:Listing
Domain
According to this template: organisation, place
According to statements in the property:
geographical object (Q618123), geographic location (Q2221906) and occurrence (Q1190554)
When possible, data should only be stored as statements
Allowed valuesfull address (note: this should be moved to the property statements)
ExampleWhite House (Q35525) → 1600 Pennsylvania Avenue, NW Washington, D.C. 20500 U.S.
Bank of England (Q183231) → Threadneedle Street, London, EC2R 8AH
L'Opéra Restaurant (Q3204568) → Palais Garnier, Place Jacques Rouché, 75009 Paris, France
Format and edit filter validationDo not use with persons.
Tracking: sameno label (Q42533409)
Tracking: differencesno label (Q55283138)
Tracking: usageCategory:Pages using Wikidata property P969 (Q20990052)
Tracking: local yes, WD nono label (Q55283137)
See alsolocated on street (P669), street number (P670), conscription number (P4856)
Lists
Proposal discussionProperty proposal/Archive/17#P969
Current uses845,741
Search for values
[create] Create a translatable help page (preferably in English) for this property to be included here
Conflicts with “instance of (P31): human (Q5): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P969#Conflicts with P31, search, SPARQL, SPARQL (new)
Type “geographical object (Q618123), geographic location (Q2221906), occurrence (Q1190554): element must contain property “instance of (P31)” with classes “geographical object (Q618123), geographic location (Q2221906), occurrence (Q1190554)” or their subclasses (defined using subclass of (P279)). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P969#Type Q618123, Q2221906, Q1190554, SPARQL, SPARQL (new)
Conflicts with “instance of (P31): organization (Q43229), business (Q4830453): this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P969#Conflicts with P31, SPARQL, SPARQL (new)


This property is being used by:

fr:Module:Adresse, fr:Modèle:Wikidata list/Monument, fr:Modèle:Wikidata list/Monument/Bac à sable


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

Ambiguity[edit]

This property is ambiguous, and the proposal lacked a detailed description. Any given item can potentially have 100s of addresses. --Danrok (talk) 00:03, 17 October 2013 (UTC)

It also seems to be close to located on street (P669) (the datatype is different though). SPQRobin (talk) 21:51, 18 October 2013 (UTC)
Unclear property definition, why was this property created? Duplicate with located on street (P669) , except String entry possible Michiel1972 (talk) 12:01, 21 October 2013 (UTC)
If I understand Wikidata:Property_proposal/Sister_projects#address_.28en.29 correctly, the idea was to provide both the street name and the street number in this property. In that case, I think it makes sense: In some cases, we do not have an item about the street, and assuming that we want to create one for every street used in this property, that will require much effort, so starting with a copy-paste import of the street + street number is simpler. Even when we can use located on street (P669), I think that this property makes sense for some purposes, as it make it much easier to get the local format right (in some countries, house numbers are shown after the street name, in some other, it is the other way around). So, if this property is supposed to be used for street name + house number, I support keeping it, but the documentation should be made clearer. If this property is intended to be used for the street name only, I would support deleting it, as located on street (P669) is more apprpriate for that. --Zolo (talk) 12:25, 21 October 2013 (UTC)
We already have all tracking features: Just add street number (P670) as qualifier. --Kolja21 (talk) 18:56, 21 October 2013 (UTC)
Sorry, but I really have no idea of what you mean. --Zolo (talk) 19:55, 21 October 2013 (UTC)
Pyfisch wrote: "Maybe we can also use different properties for the street, house number etc." We already have these properties. --Kolja21 (talk) 20:04, 21 October 2013 (UTC)
Street numbers are not a universal concept. In Japan, streets have no name, and addresses are organized by block and group of blocks. Syced (talk) 04:55, 14 May 2015 (UTC)

Information privacy[edit]

  1. "Contact information such as phone numbers, fax numbers and e-mail addresses are not encyclopedic" (en:Wikipedia:What Wikipedia is not).
  2. Happy stalking? --Kolja21 (talk) 00:30, 21 October 2013 (UTC)
Sometimes, we need information about an address. This is provided is many Wikipedia and Wikivoyage templates. We should probably discourage the use of this property on items about people though. --Zolo (talk) 12:14, 21 October 2013 (UTC)
Wikidata is not only for Wikipedia. Exact address is highly relevant for all language editions of Wikivoyage, for instance. Syced (talk) 04:50, 14 May 2015 (UTC)

What can we do for multi language of this?[edit]

I am trying to add the street address of japanese articles. I am thinking of adding japanese address then english address for this property. Then add a qualifier like language or site. What do you think? --Napoleon.tan (talk) 03:17, 21 March 2014 (UTC)

My opinion is that this property should use the local language (or local languages). Or more specifically, what you should write on the envelope to get it delivered. Use located on street (P669) and street number (P670) for multilinguage use. /ℇsquilo 20:46, 21 March 2014 (UTC)
@Esquilo: Well, at least one same place in Switzerland can have address-related texts in at least German and French, so I would support converting this property to a monolingual text datatype. --Liuxinyu970226 (talk) 01:26, 14 May 2018 (UTC)

In Thailand outside the mayor cities, the postal addresses have nothing to do with the streets, as they are of the structure "plot number", "village number", "subdistrict", "district", "province", so P669/P670 are no help in making the addresses readable to any users outside the country. Wikivoyage seems to use this property with a qualifier, at least that's what a Wikivoyage user added to several venues on Ko Lanta, e.g. Pimalai Resort & Spa (Q53672435). But if we do addresses in different languages, how to mark those in the native language(s) compared with translations/transcriptions? Using the rank? Ahoerstemeier (talk) 23:08, 9 August 2018 (UTC)

@Ahoerstemeier: But then how do you resolve what Chinese users wanna see? As a former zhwiki user, I have to tell you that in zhwiki, we generally translate the foreign language addresses to Chinese (unless if that's a part of cite XXX templates and can only shown as-is due to somewhat huge technical difficults). --Liuxinyu970226 (talk) 01:57, 11 November 2018 (UTC)

Kleinmachnow (Q104192)[edit]

On my talk page, I had a question about the use of this property on Kleinmachnow (Q104192) by @Gbeckmann: Apparently they had inserted it on an item for a municipality to indicate the office of municipal administration ("I inserted this property with regard to a possible usage of the adress (of municipality) in Infobox Gemeinde in Deutschland."). It seems to me that an item about an administrative area can't be "located on street address". Which is why I had removed it from the showcase item Kleinmachnow (Q104192). --- Jura 04:47, 5 May 2015 (UTC)

Relation to street number (P670)[edit]

The relation to street number (P670) is not clear for located at street address (P969). I originally thought that the street name only should go as located at street address (P969) and that the street number should be a qualifier with street number (P670) below the property, but some items I have seen use both streetname and number on the street as the value for the proprety located at street address (P969). I suppose that is the way to do it? I have seen a case where also the postal code (P281) was a qualifier under located at street address (P969), but that to me seems wrong. Examples:

Finn Årup Nielsen (fnielsen) (talk) 21:40, 14 October 2015 (UTC)

In my view street number (P670) is primarily intended with located on street (P669). I'm not sure what to use located at street address (P969) for, if we can link a street item directly with p669. In addition, headquarters location (P159) seems a little redundant to 669? --VicVal (talk) 14:02, 31 October 2015 (UTC)
I added a sample to P969. The difference between P969 and the pair P669/P670 is in the data-format. The later works well for the Netherlands and Paris, where every street already has an item. --- Jura 14:31, 31 October 2015 (UTC)

Does this address include the country?[edit]

It is unclear to me whether this address should include the country or not. The given examples even contradict each other on this point, unless stating the country is optional. I believe it should be stated in the definition of the item whether the address should include the country or not. If it is deliberately unclear, undefined or optional whether the country should be stated or not, I believe this should be stated too. --Jhertel (talk) 21:16, 11 August 2018 (UTC)

conflicts-with constraint (Q21502838) instance of (P31) organization (Q43229) and business (Q4830453)[edit]

Why is there a conflicts-with constraint (Q21502838) with organization (Q43229) and business (Q4830453)? I think every organization (Q43229) and business (Q4830453) has an located at street address (P969). I neither see any reason for this nor is there any discussion in the proposal or here. Even two of the examples are in conflict with the property:

  1. Bank of England (Q183231) is an organization (Q43229)
  2. L'Opéra Restaurant (Q3204568) is a business (Q4830453)

Why shouldn't no label (Q480565) or Kaufhaus des Westens (Q686011) have an located at street address (P969)?--Bcoh (talk) 14:07, 14 August 2018 (UTC)