Open main menu

Property talk:P969

This property is being replacedEdit

See the consensus to delete this property documented at Requests for deletions/Archive/2019.

 

This property was previously considered for deletion but kept.


Documentation

located at street address (DEPRECATED)
use P6375 instead
Descriptionstreet address of item. Compare with located on street (P669) and its qualifier street number (P670).
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), occurrence (Q1190554), organization (Q43229), government agency (Q327333), magazine (Q41298) and work of art (Q838948)
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
WikiMUC (Q24505237) → Angertorstraße 3, 80469 München, Germany
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 at street address (P6375)
Lists
Proposal discussionProposal discussion
Current uses819,987
Search for values
  Item “located at street address (P6375): Items with this property should also have “located at street address (P6375)”. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P969#Item P6375, SPARQL, SPARQL (new)
  Item “country (P17): Items with this property should also have “country (P17)”. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P969#Item P17, search, SPARQL, SPARQL (new)
  Item “located in the administrative territorial entity (P131): Items with this property should also have “located in the administrative territorial entity (P131)”. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P969#Item P131, search, SPARQL, SPARQL (new)
  Item “coordinate location (P625): Items with this property should also have “coordinate location (P625)”. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P969#Item P625, SPARQL, SPARQL (new)
  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)
  Countries with most items lacking P6375
use a tool or make a bot request for an appropriate selection of these items and a new language code. As of Sept 2019, top3 are: France (21517), UK (18901), Romania (10910) (Help)
Violations query: SELECT ?item ?count WHERE { SELECT ?item (COUNT(*) as ?count) WHERE {?p wdt:P969 []; wdt:P17 ?item MINUS { ?p p:P6375 []} } GROUP BY ?item } ORDER BY DESC(?count)
List of this constraint violations: Database reports/Complex constraint violations/P969#Countries with most items lacking P6375
 
This property is being used by:

fr:Module:Adresse, fr:Modèle:Wikidata list/Monument, fr:Modèle:Wikidata list/Monument/Bac à sable, fr:Modèle:Commissions scolaires québécoises


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

AmbiguityEdit

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 privacyEdit

  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 (DEPRECATED) (P969). I originally thought that the street name only should go as located at street address (DEPRECATED) (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 (DEPRECATED) (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 (DEPRECATED) (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 (DEPRECATED) (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 (DEPRECATED) (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 Q480565 or Kaufhaus des Westens (Q686011) have an located at street address (DEPRECATED) (P969)?--Bcoh (talk) 14:07, 14 August 2018 (UTC)

Usage with regard to located on street (P669)Edit

The descriptions for located at street address (DEPRECATED) (P969) are a bit confusing. Should I use located at street address (DEPRECATED) (P969) and located on street (P669) if both are possible (implied by the English description) or should I use located at street address (DEPRECATED) (P969) only if located on street (P669) is not possible (implied by German, French, Dutch)? --HyperGaruda (talk) 06:13, 13 January 2019 (UTC)

move to P6375Edit

I've marked this property as deprecated after the discussion at WD:PFD#P969. There is a new property located at street address (P6375) with the same scope but with datatype monolingual instead of string. It should be possible to move most statements by bots. For the remaining ones I've set up a tool on Toolforge where everybody can contribute to the conversion. As soon as mass conversion starts, the templates on sister projects should be adapted. --Pasleim (talk) 15:48, 17 January 2019 (UTC)

This tool is absolutely amazing. Thank you Pasleim! Deryck Chan (talk) 18:48, 18 January 2019 (UTC)
@Pasleim: Great tool! When trying the tool I get a lot of countries elsewhere, while I would like to do this for the capital city of Belgium that is multilingual, Brussels. It would be handy if it is possible to select the country (P17) in the tool to clean out the whole of Belgium with this tool. If this becomes possible, please let me know.
A second thing I noticed when using the tool here is that it left language of work or name (P407) as qualifier, which is duplicate. Romaine (talk) 09:44, 25 January 2019 (UTC)
Will I need to adapt all my sparql-queries if this move happens ?--OlafJanssen (talk) 14:12, 25 January 2019 (UTC)
yes, all queries using P969 need to be changed to P6375. --Pasleim (talk) 17:00, 25 January 2019 (UTC)
What should I give for result for romanization? I have multiple adresses with romanized japanese name, like Senshu University (Q1062568). --Fralambert (talk) 15:35, 5 February 2019 (UTC)
Maybe Romanization of Japanese (Q192509) or transcription into Japanese (Q7833933). --RolandUnger (talk) 09:41, 9 February 2019 (UTC)
  • As there are still some 800,000 I restored the constraints: I don't think we want this to be added to items that don't match P6375. I also added a suggestion for P6375. --- Jura 12:46, 13 September 2019 (UTC)
    I think that P969 should have also a conflicts-with constraint with P6375. Like last time I looked, there still 700000 items with the two properties. We should look at least the items who share the same result so we can do a lot of cleanning. --Fralambert (talk) 13:14, 14 September 2019 (UTC)
    • That's fairly easy to do once everything is converted. The query on the complex constraint lists how many for each country still need to be looked into. Maybe the users who supported the deletion would want to help. Alternatively, we could change the remaining ones into "und"/"und-Latn". --- Jura 13:25, 14 September 2019 (UTC)
Return to "P969" page.