Property talk:P6375

From Wikidata
Jump to navigation Jump to search

Documentation

street address
full street address where subject is located. Include building number, city/locality, post code, but not country; use also P669 if the street has its own separate item
Representsstreet address (Q24574749), address (Q319608), street (Q79007)
Data typeMonolingual text
Template parameter|address= in voy:Template:Listing
Domaingeographical feature (Q618123), geographic location (Q2221906), occurrence (Q1190554), organization (Q43229), government agency (Q327333), magazine (Q41298), creative work (Q17537576), collection (Q2668072), community (Q177634), fictional location (Q3895768) or facility (Q13226383)
Allowed valuesfull address (note: this should be moved to the property statements)
Usage notesfull street address where subject is located. Include building number, city/locality, post code, but not country; use also P669 if the street has its own separate item.
ExampleWhite House (Q35525) → 1600 Pennsylvania Avenue NW, Washington, DC 20500
L'Opéra Restaurant (Q3204568) → Palais Garnier, place Jacques-Rouché, 75009 Paris
Baranagore Ramakrishna Mission Ashrama High School (Q19882251) → 37, Gopal Lal Tagore Road, Baranagar, Kolkata - 700036
Tokyo Imperial Palace (Q500681) → 〒100-8111 東京都千代田区千代田1番1号
Reichstag (Q151897) → Platz der Republik 1, 11011 Berlin
Loggia dei Cavalieri (Q5572) → Via Martiri della Libertà, 48, 31100 Treviso TV
Format and edit filter validationDo not use with persons.
Tracking: usageCategory:Pages using Wikidata property P6375 (Q61764320)
See alsolocated on street (P669), house number (P670), conscription number (P4856), postal code (P281), directions (P2795), post office box (P2918), room number (P7532), floor number (P5423), location (P276)
Lists
Living people protection classproperty that may violate privacy (Q44601380)
Proposal discussion[unknown Proposal discussion]
Current uses
Total1,902,362
Main statement1,865,26198% of uses
Qualifier36,7971.9% of uses
Reference304<0.1% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Silas House (Q7514169)
List of violations of this constraint: Database reports/Constraint violations/P6375#Type Q618123, Q2221906, Q1190554, Q43229, Q327333, Q41298, Q17537576, Q2668072, Q177634, Q3895768, Q13226383, SPARQL
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. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Silas House (Q7514169)
List of violations of this constraint: Database reports/Constraint violations/P6375#Conflicts with P31, SPARQL
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/P6375#Scope, SPARQL
Allowed entity types are Wikibase item (Q29934200), Wikibase MediaInfo (Q59712033): the property may only be used on a certain entity type (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/P6375#Entity types
Qualifiers “start time (P580), end time (P582), point in time (P585), reason for preferred rank (P7452), reason for deprecated rank (P2241), object has role (P3831), located on street (P669), house number (P670), end cause (P1534), applies to part (P518), postal code (P281), floor number (P5423), room number (P7532), earliest end date (P8554), statement supported by (P3680), statement disputed by (P1310), together with (P1706), phone number (P1329), location (P276), located in/on physical feature (P706), located on linear feature (P795), located in or next to body of water (P206), post town (P4595), not found in (P9660), writing system (P282), conscription number (P4856), name in kana (P1814), Revised Hepburn romanization (P2125), post office box (P2918)”: 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/P6375#allowed qualifiers, SPARQL
This property is being used by:

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

Include country?[edit]

From the given examples it's still not clear to me whether one should include the country or not when entering an address.
The example Threadneedle Street, London, EC2R 8AH doesn't include the country while Angertorstraße 3, 80469 München, Germany does. And if a country should be specified, is it supposed to be in English or the native language of the country which the address is in?

If there is consensus on these questions I'd like to propose to edit the examples accordingly. --Naseweis520 (talk) 11:01, 20 January 2019 (UTC)[reply]

I've repeated my question in the project chat. --Naseweis520 (talk) 18:26, 24 January 2019 (UTC)[reply]
It seems that in almost all statements the country is not include. In order to achieve consistency, I thus prefer to remove the country from the few statements which have it included. --Pasleim (talk) 09:16, 16 February 2019 (UTC)[reply]
Because there are no inputs from other users, I removed the country names in the examples. --Pasleim (talk) 12:42, 28 February 2019 (UTC)[reply]
This property is stated to be equivalent to http://dati.beniculturali.it/cis/fullAddress, which is meant to contain the country (see the example at http://dati.beniculturali.it/lodview/cis/Address.html). Property:P6375 is also stated to be equivalent to http://www.w3.org/2006/vcard/ns#street-address; however, that appears to be erroneous as the latter is only the street line component of a full address (please see the example at https://www.w3.org/TR/vcard-rdf/#Examples). Therefore, Property:P6375 should include the country to be consistent with http://dati.beniculturali.it/cis/fullAddress, and the http://www.w3.org/2006/vcard/ns#street-address claim should be removed. Perhaps it should be changed to http://www.w3.org/ns/locn#fullAddress? --Alex rosenberg35 (talk) 05:05, 19 June 2019 (UTC)[reply]

QuickStatements[edit]

The old P969 (P969) is still the only option that can be used with adding data to Wikidata through QuickStatements. I haven't found any option how to add the language label with this tool with the street address (P6375). While I think the requirement of a language is at such a good idea, that this can't be easily imported is a bad idea. Therefore I think we need to keep the property P969 (P969) until it is minimal possible to add the language also for street address (P6375). Until this is possible, P969 (P969) can be used to add the address with language of work or name (P407) + the language, a bot can later easily convert this to street address (P6375). Romaine (talk) 09:14, 25 January 2019 (UTC)[reply]

You can add street address (P6375) with QuickStatements, see "Monolingual text" under Help:QuickStatements#Add_simple_statement. --Pasleim (talk) 09:18, 25 January 2019 (UTC)[reply]
Thanks Pasleim! Not sure why I missed that. This works. Romaine (talk) 09:29, 25 January 2019 (UTC)[reply]
Does this work with the CSV import in QS also, as I cannot seem to make it work? Does anyone have an example of a CSV import where this works? Thanks Nickw25 (talk) 10:43, 7 July 2019 (UTC)[reply]
Thank you very much Pasleim for this tip. It was hours of suffering and now I managed to solve my problem! Túllio F (talk) 06:30, 20 March 2024 (UTC)[reply]

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

I already asked this in August 2018 but i never got any feedback. Why is there a conflicts-with constraint (Q21502838) with organization (Q43229) and business (Q4830453)? I think every organization (Q43229) and business (Q4830453) has an street address (P6375). I neither see any reason for this nor is there any discussion in the proposal or the replacement proposal. 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 Spanish Data Protection Agency (Q392528), Local Court Bochum (Q480565) or Kaufhaus des Westens (Q686011) have an street address (P6375)?

Thus I propose removing the conflicts-with constraint (Q21502838) instance of (P31) organization (Q43229) and business (Q4830453).--Bcoh (talk) 20:25, 23 April 2019 (UTC)[reply]

No one opposed, so I removed this constraint. --Bcoh (talk) 09:38, 14 May 2019 (UTC)[reply]

Component parts?[edit]

I know not all countries and places use the same standard addressing scheme.... That said, is there any thought about breaking up this property to include something like?:

  • Building number
  • Street name
  • City
  • Postal code

Atomic Centurion (talk) 18:27, 23 July 2019 (UTC)[reply]

Hello, I ask myself the same question : qualifier house number (P670) ? postal code (P281) ? located in the administrative territorial entity (P131) (and if already in declaration) ? In the examples the address is a single string ("1600 Pennsylvania Avenue, NW Washington, D.C. 20500 (anglais)". Gzen92 [discuter] 08:42, 20 November 2019 (UTC)[reply]

Including post code?[edit]

The English description tells the user to include the post code in the address. That might the convention in some countries, but not in the Netherlands, here the postal code (P281) is usually kept separate. Any suggestion how to update the description? It's already quite long. Maybe trim it and add a usage instruction? Multichill (talk) 10:00, 31 December 2019 (UTC)[reply]

Bilingual City: 2 street names for the same adress/place[edit]

Fribourg/Freiburg (Suisse/Schweiz/Switzerland) is a bilingual city. Therefore a lot of street names exit in French and German. In the German Wikipedia I prefire German street names (for example Chorherrengasse), in a french Wikipedia the french names (for example rue des Chanoines). Both (French + German) are oficial street names. How do you handle cases like this in Wikidata? Matutinho 20:27, 12 June 2020 (UTC)

Just add both language versions. Multichill (talk) 08:57, 13 June 2020 (UTC)[reply]

Sort key[edit]

Would be good to have a qualifier "sort key" for sorting entities in lists by address, e.g. in monuments lists like w:de:Liste der Monuments historiques in Apt. I think it should be multilingual.--Sinuhe20 (talk) 12:58, 15 July 2020 (UTC)[reply]

Removed citation needed constraint[edit]

@Fralambert: you added the citation needed constraint (Q54554025). Every statement should have a reference, what makes this property special? It was always intended for the more controversial statements, see Help:Property constraints portal/Citation needed. Removed it. Multichill (talk) 11:31, 4 October 2020 (UTC)[reply]

@Multichill: It was Trade who added the constraint[1]. I just lowered it to a suggestion level, like official name (P1448) and heritage designation (P1435). Thanks to at least check the historic before making a acusation. --Fralambert (talk) 12:07, 4 October 2020 (UTC)[reply]
It was mostly to prevent people from adding a wrong adress iven how precise his property is. --Trade (talk) 13:24, 4 October 2020 (UTC)[reply]

Conversion[edit]

Please see Property_talk:P969#"und"_or_"und-latn" and comment there. --- Jura 08:03, 9 November 2020 (UTC)[reply]

Property label[edit]

Currently the (English) label is "street address". This is what we already had at P969. However, the value that should be added is actually the street and locality. Many users (possibly including myself) don't or didn't actually do that, possibly due to the label.

We could probably improve that by adding "locality" into the label, e.g. "street address and locality".

Maybe, this would also improve the contrast to "located on street" that takes as value an item with just the street as label. --- Jura 13:11, 9 November 2020 (UTC)[reply]

Constraint type restriction[edit]

@Multichill: why did you delete the element type for the constraint? Don't you think it's good to have theses?! Antoine2711 (talk) 19:47, 27 November 2020 (UTC)[reply]

Because these qualifiers are not valid. You're using them incorrectly on Théâtre de la Ville (Q100959088). Multichill (talk) 20:29, 27 November 2020 (UTC)[reply]
@Multichill: This restriction has only been added recently. And thoses qualifiers have been used before by many people. Why make that incorrect NOW? Because it's very usefull to extract those data. Antoine2711 (talk) 20:57, 27 November 2020 (UTC)[reply]
@Antoine2711: It was always incorrect. Quite unfortunate that people didn't get a constraint violation to warn them. Take for example house number (P670) it clearly says in the description number in the street address. To be used as a qualifier of Property:P669 "located on street", but https://w.wiki/oLj returns a lot of violations. Looks like several incorrect batch imports. Multichill (talk) 21:30, 27 November 2020 (UTC)[reply]
@Multichill: if you look it your way, there is effectively a lot of mistake. From the way I see it, it's more house number (P670) who should be updated. What is the rational behind your exclusion? Is there a place where all of this was discussed/decided? See how many people were wrong like me… postal code (P281) : 18054, house number (P670) : 11326, located on street (P669) : 753. Check by yourself! https://w.wiki/oLm Regards, --Antoine2711 (talk) 21:49, 27 November 2020 (UTC)[reply]
I think it would be good to have (one or several) samples for each country and follow that. Things like https://www.wikidata.org/w/index.php?title=Q100695465&oldid=1301805418#P6375 seem clearly wrong. --- Jura 22:43, 27 November 2020 (UTC)[reply]
@Jura1: Do you think house number (P670), postal code (P281) and located on street (P669) should be allowed? We currently have more than 30K of them… Antoine2711 (talk) 07:42, 2 December 2020 (UTC)[reply]
There more than 1,100,000 statements with this property (many converted from P969). I wonder how many are actually correctly formatted.
I don't see how located on street (P669) would be useful as qualifier to street address (P6375). In the sample above, the string could be deleted and P669 added as main statement.
Do you have valid samples where you think this is needed? Not all editing rules are necessarily enforced by property constraints all the time. --- Jura 08:06, 2 December 2020 (UTC)[reply]
@Multichill: I really think we should allow theses qualifiers. This is clearly a recent change to add qualifiers constraint, but this goes too far. What's your suggestion for the next step? Regards, Antoine2711 (talk) 07:42, 2 December 2020 (UTC)[reply]
To clean up the recent imports automatically that caused the bulk of the constraints. Rest probably needs to be done by hand. Multichill (talk) 12:12, 4 December 2020 (UTC)[reply]

Add constraint type[edit]

@Multichill, Jura1: I STRONGLY think we have to enable the located on street (P669) and the postal code (P281) as constraint for street address (P6375). Because, these information are « trapped » in a text format that is different from country to country. This was OK before the change that added constraint (https://www.wikidata.org/w/index.php?title=Property:P6375&oldid=13054306950). Multichill reverted my correction, saying: « Those should be added as statements, not as qualifiers ». But this can only be done when there is ONE address, and also, it's not logical since those data are BINDED to the address, why put them far away? If we must, let's have a vote on that.

Also, have them as qualifiers makes it VERY easy to be extracted, what would be difficult in a free form text field entered data, which is by definition never clean and conform. Regards, Antoine2711 (talk) 17:20, 8 March 2021 (UTC)[reply]

You should add these as statements, not as qualifier. Nothing is trapped here, you are just trying to insert it in the wrong location. Maybe you have an example of an item where you're struggling so we can help you? Multichill (talk) 17:27, 8 March 2021 (UTC)[reply]
@Multichill: and how do you do that if the item has TWO addresses?! I totally understand what we say when you tell me that I could add them as separate properties. But you put a rank qualifier to bind them is there are more that one address? Also, do you understand that this information will not be close together if they are properties? Regards, Antoine2711 (talk) 18:57, 8 March 2021 (UTC)[reply]
Also, Multichill, on the logic level, it's normal to have a postal code for a building, since it's a physical concept that is inside a postal distribution region. But, a business doesn't have in itself a postal code. It's is ADDRESS that have this property. And it's much more common to see a company moving its offices, opening a new one, closing an old one, than to see a building moving and changing it's postal code… This shows that the concept of postal code is much more binded to the address than to the entity of the page.
While doing my test, I just realised that a person CAN'T have a code postal property. But a person can have an address (presumably its home address?!). So for a person, it would be even more logic to have the postal code as a qualifier. Regards, Antoine2711 (talk) 19:16, 8 March 2021 (UTC)[reply]
To use house number (P670) correctly on Théâtre de la Ville (Q100959088) mentioned earlier, see [2]. --- Jura 19:32, 9 March 2021 (UTC)[reply]
@Jura1: your point is beside what I bring forward. I know what you all wrote here can be done. Yes, you can add house number (P670) to located on street (P669), but why couldn't we add house number (P670) to street address (P6375)? Also, if you have 2 addresses, how can you bind each street address (P6375) values to the correct located on street (P669)? It can't be done without using qualifiers… Regards, Antoine2711 (talk) 23:27, 9 March 2021 (UTC)[reply]
I second the offer by Multichill. --- Jura 06:56, 10 March 2021 (UTC)[reply]

Use only with local languages (or English?)[edit]

As mentioned above, P969 (P969) that should be converted to this still includes some values that are not in the local language written in the default script (samples at Property_talk:P969#"und"_or_"und-latn"). The suggested solution is to use "und-latn" for these. There is now a debate with langcom at Wikidata:Contact_the_development_team#add_monolingual_code_"und-latn" suggesting that we shouldn't include non-local language (or English) texts with this property. As we didn't get any clear advice on what to do with the samples provided, this conversion from P969 somewhat hangs on this. Maybe input from other interested people could help. --- Jura 22:41, 27 November 2020 (UTC)[reply]

Talk page of P969 is now at Property talk:P6375/Archives/P969[edit]

Explains some of the current format/conversion. --- Jura 21:22, 18 December 2020 (UTC)[reply]


Preferred formats per country[edit]

Now that the conversion from P969 is completed, it might be worth trying to determine preferred formats for each country and try to do some cleanup. --- Jura 21:37, 18 December 2020 (UTC)[reply]

Mailing address[edit]

Some places have an address where mail is received that is different from the physical location of the building. How should this be entered? Senator2029 15:05, 12 August 2021 (UTC)[reply]

Reupping this one. Is there any way to include mailing addresses, either with this property or another one? Trivialist (talk) 17:56, 5 June 2022 (UTC)[reply]

should streets and public squares have it?[edit]

At Q438094#P6375 and Q875360#P6375, the items for public squares repeat the label as street address.

As a value for street address (P6375) is is obviously incomplete and the items should probably not have the statements in the first place.

"native label" seems the more suitable property. --- Jura 14:13, 1 January 2022 (UTC)[reply]

Use seems to be primarily in the Netherlands, see [3].
Maybe @Husky, Multichill, Sjoerddebruin, Denengelse: from here want to comment. --- Jura 11:52, 4 January 2022 (UTC)[reply]
Pretty sure this was added on purpose to have an easy way to match postal codes with the full name of the street so please don't mass remove or change it. Multichill (talk) 17:31, 4 January 2022 (UTC)[reply]

value is not indexed for string search[edit]

Please see Wikidata:Report_a_technical_problem/WDQS_and_Search#index_"street_address"_(P6375)_strings. --- Jura 11:58, 4 January 2022 (UTC)[reply]

Apparently, that's a regression from when this had string datatype.
Wikidata:Bot requests#request_to_make_buildings_searchable_by_address_(2022-01-05) should fix some of it. --- Jura 14:17, 6 January 2022 (UTC)[reply]

Is there a bot geocoding values of this field ? Or a tool that allows to do it manually ?[edit]

Is there a bot geocoding values of this field ? Or a tool that allows to do it manually ? Teolemon (talk) 16:05, 14 July 2022 (UTC)[reply]

Record Japanese postal code separately from its address[edit]

SELECT ?anyItemLabel ?anyItem ?address WHERE {
  ?anyItem wdt:P6375 ?address.
  FILTER(STRSTARTS(?address, "〒")).
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ja,en". }
}
Try it!

This query yields Japanese street address, starting with Japanese postal code. Shouldn't these codes be recorded as qualifier of addresses? 2400:4053:9480:7200:D9B3:3F36:A7E8:F65A 03:18, 19 March 2023 (UTC)[reply]

Allowing the duplication of information between P669 located on street and P6375 street address[edit]

  1. The English description says 'use also P669 if the street has its own separate item' - why also and not instead?
  2. On located on street (P669) it says 'Use property P6375 "street address", if there is no item for the street' - which could be read as use that only if there is no street item.

Issues:

  1. String searches are more complicated, some cities may have differents streets having the same street name, then it is difficult to find all items related to one street doing string search
  2. Information duplication may lead to contradicting data
  3. allow using two properties for the same information may lead to seemingly random placement of the information if it is not duplicated on the other property and this in turn
    1. will make queries more complicated
    2. will make simple queries fail to deliver the desired information - maybe unknown to the user of the query
  4. free text
    1. allows users to add street names that are not defined for a place, this is harder to detect than links to wrong street items
    2. allows users to make spelling mistakes in a street name
    3. forces users to select a language, or to repeat the same statement for different languages, while using dedicated items language specific differences are stored elsewhere

GeoGQL (talk) 18:19, 27 April 2023 (UTC)[reply]

@GeoGQL: I totally agree, this property should not be used if there is already located on street (P669) (and if possible, located on street (P669) should be preferred but that's a different matter). Maybe we can add an incompatibility constraint and do a big clean-up (currently 102 264 items use both ! sometimes with multiple values). Pinging top-user of this property: @Pasleim, Fralambert, Higa4, Vanbasten 23, Romaine, Sic19: (also pinging @Mahir256: for the reducing the redundancy). Cheers, VIGNERON (talk) 10:30, 30 October 2023 (UTC)[reply]
I do not read 'Use property P6375 "street address", if there is no item for the street' as that it cane be used only when there is no item for a street.
In English this property has the name 'street address', but in many languages the label says 'address'. In my language the address is much more than just the street (with possible the number). Also, the street address is not only used when there is no Wikidata item for a street, but also used to indicate some details that do not fit with the property street. For example: being at the corner of streets, also for being across the road of number #, also for indicating address details that are more than a house number (like second floor, etc., which can be part of the address!), and many more.
There are also properties that require both a street and a street address.
In my opinion it is not a problem to have both properties used on an item and I see no reason why one of them should be removed. I agree that the address is hard to query and that the use of street should be recommended where possible. I do agree that if there is an item for a street, but this isn't used with street, that such is a problem. Another problem that I think exists is that no address or a street has been added at all. Just speaking about Dutch monuments for example, all of them should have a street, but currently more than 18000 do not have a street, while most of them have an address and most streets in the Netherlands have an item in Wikidata.
Another thing that should have much more the attention is that still too many items have no P31, still too many items have no country, to name two basic properties. Romaine (talk) 12:16, 30 October 2023 (UTC)[reply]
I agree with the points made above by @Romaine. For me, P6375 would be better labelled as "address" or "full address" since that is how it is generally used.
Even if an item that uses P6375 also has P669, house number (P670), floor number (P5423), location (P276), located in the administrative territorial entity (P131), postal code (P281) and country (P17) statements (where applicable) there is still potential to lose information when P6375 is removed. For example, an address may contain several levels of administrative areas such as district and county or a single administrative area that differs from the P131 value.
When we are sure that no information is lost by removing P6375, is it possible to render an address correctly for a specific locality from the component statements? There is much variation in how addresses are written. If so, P6375 can be considered redundant.
Best, Simon Cobb (User:Sic19 ; talk page) 18:05, 30 October 2023 (UTC)[reply]
@Romaine, Sic19: I totally agree that not everything in P6375 can be replaced by other properties, but that beside our point which is: when there is already both properties, it is redundant and only the entity type property should be kept. For instance, the case listed here: https://qlever.cs.uni-freiburg.de/wikidata/IyQqhe (simple crude first query to be improved) where the removal would not result in loos of informations. @Sic19: some infoboxes does render the full adress based on porperties other than P6375, yes.
Not sure why the diversion about P31 and P17, it's kind of true (tho, 96% of items do have a P31 and not all items should have a P31) but unrelated (and if anything, removing redundant data will improve the other data but allow us to focus on actual information).
Cheers, VIGNERON (talk) 08:28, 1 November 2023 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P6375&oldid=2116809053"