Property talk:P6375/Archives/P969

From Wikidata
Jump to navigation Jump to search

This property is being replaced[edit]

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

{{Property documentation
|id = P969
|description            ={{TranslateThis
  | en = street address of item.  Compare with {{P|P669}} and its qualifier {{p|670}}.
}}
|infobox parameter      = ''address'' in [[:voy:Template:Listing]]
|domain                 ={{TranslateThis
  | en = organisation, place
}}
|allowed values         ={{TranslateThis
  | en = full address
}}
|filter                 ={{TranslateThis
  | en = Do not use with persons.
}}
}}

{{Complex constraint
|label=Countries with most items lacking P6375
|description=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) 
|sparql=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)
}}
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.)

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

It also seems to be close to located on street (P669) (the datatype is different though). SPQRobin (talk) 21:51, 18 October 2013 (UTC)[reply]
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)[reply]
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)[reply]
We already have all tracking features: Just add house number (P670) as qualifier. --Kolja21 (talk) 18:56, 21 October 2013 (UTC)[reply]
Sorry, but I really have no idea of what you mean. --Zolo (talk) 19:55, 21 October 2013 (UTC)[reply]
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)[reply]
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)[reply]

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

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

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 house number (P670) for multilinguage use. /ℇsquilo 20:46, 21 March 2014 (UTC)[reply]
@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)[reply]

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

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

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

Relation to house number (P670)[edit]

The relation to house number (P670) is not clear for P969 (P969). I originally thought that the street name only should go as P969 (P969) and that the street number should be a qualifier with house 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 P969 (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 P969 (P969), but that to me seems wrong. Examples:

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

In my view house number (P670) is primarily intended with located on street (P669). I'm not sure what to use P969 (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)[reply]
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)[reply]

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

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 P969 (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 Local Court Bochum (Q480565) or Kaufhaus des Westens (Q686011) have an P969 (P969)?--Bcoh (talk) 14:07, 14 August 2018 (UTC)[reply]

Usage with regard to located on street (P669)[edit]

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

move to P6375[edit]

I've marked this property as deprecated after the discussion at WD:PFD#P969. There is a new property 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)[reply]

This tool is absolutely amazing. Thank you Pasleim! Deryck Chan (talk) 18:48, 18 January 2019 (UTC)[reply]
@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)[reply]
Will I need to adapt all my sparql-queries if this move happens ?--OlafJanssen (talk) 14:12, 25 January 2019 (UTC)[reply]
yes, all queries using P969 need to be changed to P6375. --Pasleim (talk) 17:00, 25 January 2019 (UTC)[reply]
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)[reply]
Maybe romanization of Japanese (Q192509) or transcription into Japanese (Q7833933). --RolandUnger (talk) 09:41, 9 February 2019 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    • 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)[reply]

Move remainings ones to P6375 with language "und"[edit]

After 18 months, there are about 1,000,000 uses of p6375 and just some 30,000 uses of this left.

To avoid keeping two properties any longer, I think the remaining ones should be converted to language "und". --- Jura 06:29, 16 July 2020 (UTC)[reply]

Many links are qualifiers to headquarters location (P159) statements—in these cases, I think the language could be guessed, e.g. from the P159 statement itself. I hope there’s a bot that can do this; let’s wait with the und-migration until then, probably the remaining ones will be of a manually manageable number. —Tacsipacsi (talk) 10:54, 16 July 2020 (UTC)[reply]
Interesting point about P159. However, they don't seem to be that concentrated ([1]).
Various bots have already worked on and what's left is what they couldn't tackle.
If we don't want to have two properties for more years, I think these should be dealt with now. Manual adjustments can still be done once it's at P6375. --- Jura 11:54, 16 July 2020 (UTC)[reply]
I don’t know what bots worked on this transition, but couldn’t be that their authors simply didn’t think of this? I agree that this migrations should be finally finished, but the more data the result contains, the better, so language information should be added wherever possible.
Thanks for the query! I’m disappointed with these low figures; this may be because I checked the top of the backlink list, and older items tend to be more developed. By the way, not only country (P17) statements of the item using this qualifier can be taken into account, but also P17 qualifiers and P17 statements of the object of the P159 statement: 
SELECT ?c (COUNT(DISTINCT ?item) AS ?count) (SAMPLE(?item) as ?sample)
{
    {
        SELECT ?item ?c {
            ?item p:P159 / pq:P969 [] ; wdt:P17 ?c
        }
    }
    UNION
    {
        SELECT ?item ?c {
            ?item p:P159 ?stmt .
            ?stmt pq:P969 [] ; pq:P17 ?c
        }
    }
    UNION
    {
        SELECT ?item ?c {
            ?item p:P159 ?stmt .
            ?stmt pq:P969 [] .
            ?stmt ps:P159 / wdt:P17 ?c
        }
    }
}
GROUP BY ?c
ORDER BY DESC(?count)
Try it!
– although this still doesn’t return very large figures. —Tacsipacsi (talk) 23:14, 16 July 2020 (UTC)[reply]

"und" or "und-latn"[edit]

@ChristianKl: sure. Samples from

--- Jura 10:12, 9 November 2020 (UTC)[reply]

I thought a bit more about the property. It seems we decided we want to deprecate the property. As such, new usages should be done with street address (P6375) which uses items. ChristianKl ❪✉❫ 11:25, 10 November 2020 (UTC)[reply]
It's actually using "monolingual text", not items. Thus the question. --- Jura 11:04, 21 November 2020 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P6375/Archives/P969&oldid=1565996763"