Property talk:P669

From Wikidata
Jump to navigation Jump to search

Documentation

located on street
street, road, or square, where the item is located. To add the number, use Property:P670 "house number" as qualifier. Use property P6375 "street address", if there is no item for the street
Descriptionstreet of the address of a building. To add the number, use house number (P670) "street number" as qualifier. See also P969 (P969).
Representsstreet (Q79007)
Data typeItem
Domain
According to this template: places, more specifically architectural structure (Q811979)
According to statements in the property:
geographical feature (Q618123), work of art (Q838948), occurrence (Q1190554), fictional location (Q3895768), building (Q41176), business (Q4830453), collection (Q2668072), organization (Q43229), physical sign (Q105449313) or periodical (Q1002697)
When possible, data should only be stored as statements
Allowed valuesplaces: streets, town squares, etc. as mentioned in street addresses (note: this should be moved to the property statements)
Usage notesto add a street number, use P670 as qualifier
ExampleWhite House (Q35525)Pennsylvania Avenue (Q1455053)
Beloselsky-Belozersky Palace (Q2477653)Nevsky Prospect (Q382500)
Fontanka river embankment (Q4311132)
Baranagore Ramakrishna Mission Ashrama High School (Q19882251)Gopal Lal Tagore Road (Q70770579)
Tracking: usageCategory:Pages using Wikidata property P669 (Q20990063)
See alsolocation (P276), street address (P6375), house number (P670), room number (P7532), located in the administrative territorial entity (P131)
Lists
Proposal discussionProposal discussion
Current uses
Total272,574
Main statement232,53685.3% of uses
Qualifier40,01714.7% of uses
Reference21<0.1% of uses
Search for values
[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).
List of violations of this constraint: Database reports/Constraint violations/P669#Value type Q83620, Q79007, Q34442, Q269949, Q18948595, Q174782, Q1251403, Q111415237, 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/P669#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/P669#Entity types
This property is being used by:

fr:Module:Adresse


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


Official addresses only ?[edit]

When a building is a the intersection of several streets, should it only have the one that is on the postal address ? I think so, this property should not be a mere restriction of a "located in", otherwise, it would not have much sense. --Zolo (talk) 19:16, 3 July 2013 (UTC)[reply]

How to use[edit]

As this is an "item"-type-property, should one create an item for the street in order to add the address to a building? --  Docu  at 16:36, 4 August 2013 (UTC)[reply]

I tried to do just that. Seems fairly tedious, but possibly doable by bot. --  Docu  at 18:59, 5 August 2013 (UTC)[reply]
Yes, it is tedious (except for Paris, because all streets already have their item ;), but a string type would provide much more limited machine-readability. I guess a bot can do it, but that may not be very easy to do correctly. --Zolo (talk) 17:25, 8 August 2013 (UTC)[reply]

Streets with the same name[edit]

How should we distinguish two streets with the same name in the same administrative unit and the same zip code but in a different village? --Pasleim (talk) 08:09, 8 August 2013 (UTC)[reply]

Normally, they would have different item numbers and different descriptions. --  Docu  at 17:11, 8 August 2013 (UTC)[reply]

Cemeteries have street addresses but not architectural structures[edit]

I am not sure how to resolve the constraint violation that for something to have a street q79007 address then it needs to be of architectural structure. People are adding cemeteries to have the property street. I can also think of something like a park that can have a street address. How should this be resolved?  — billinghurst sDrewth 05:44, 17 October 2013 (UTC)[reply]

I suppose the constraint should be one of: subclass of X - subclass of Y etc., but I do not know if it is possible yet, and I am not sure which subclasses should be acceptable. I suppose there should be something like "subclass of organization", as it seems to make sense to use this property for things like the address of a company headquarters. --Zolo (talk) 06:41, 17 October 2013 (UTC)[reply]
I will leave the maintenance for this section until the matter is resolved.  — billinghurst sDrewth 22:48, 20 October 2013 (UTC)[reply]

Constraint Value type class=Q79007 too narrow ?[edit]

Hi,

Should the constraint be « Value type class = thoroughfare (Q83620) » instead of « Value type class = street (Q79007) » ?

Cdlt, VIGNERON (talk) 13:16, 24 January 2015 (UTC)[reply]

Some countries don't have street names[edit]

Just a reminder that street names are not a universal concept. In Japan, most streets have no name, and addresses are organized by block and group of blocks. See https://en.wikipedia.org/wiki/Japanese_addressing_system Cheers! Syced (talk) 04:58, 14 May 2015 (UTC)[reply]

In such cases you use P969 (P969) --Pasleim (talk) 07:41, 14 May 2015 (UTC)[reply]

Valid qualifiers[edit]

Hi,

On Turgenev Library (Q4465808), I added an old adress and logically, I used start time (P580) and end time (P582) as qualifiers. Afterward, I've seen that it's a constraint violation. So, is it a good or a bad idea? I can see per Wikidata:Database_reports/Constraint_violations/P669#Qualifiers that I'm not the only one, can we add these qualifiers as valid?

@Zolo, Pasleim, Docu:

Cdlt, VIGNERON (talk) 13:18, 9 July 2016 (UTC)[reply]

@VIGNERON:. Agree, and more generally, I am more convinced that it makes sense to restrict qualifiers to a closed list as is done through {{Constraint:Qualifiers}}. Zolo (talk) 10:40, 10 July 2016 (UTC)[reply]

Organizations with addresses[edit]

"Entities using the located on street property should be instances of one of the following classes (or of one of their subclasses), but Q18626137 currently isn't: * geographical object * work of art * occurrence * fictional location * building * business * collection" - Why should all the works of art have street addresses but organizations only if they're businesses? So, Wikimedia Foundation shouldn't have one? Come on, that's just silly. --Ehitaja (talk) 10:09, 30 December 2019 (UTC)[reply]

Voie ou rue?[edit]

Voie n'est-il pas un nom peu commun pour ce type de propriété? Je comprends que rue soit dans les alias de la propriété, mais je pense qu'il est plus commun et qu'il serait plus évident pour les francophones de comprendre ce dont il retourne si on utilisait ce mot plutôt que voie. Ne devrions-nous pas interchanger voie et rue dans cet élément? Dirac (talk) 14:33, 8 December 2020 (UTC)[reply]

Devant l'absence de commentaire, je vais procéder. Dirac (talk) 02:39, 15 December 2020 (UTC)[reply]
@Dirac: rue est peut-être plus commun (et encore, il faudrait le prouver) mais il est trop spécifique, toutes les voies ne sont pas des rues. Pour plus d'avis, je notifie @Pymouss: qui vient d'annuler la modification et @Chabe01: qui est le contributeur francophone ayant le plus utilisé cette propriété. Cdlt, VIGNERON (talk) 21:03, 15 December 2020 (UTC)[reply]
@Dirac, VIGNERON: Effectivement, l'appellation "rue" me semble source d'ambiguïté et, si "voie" n'est pas parfait, au moins cette dénomination me semble plus large et assez souvent utilisée sur divers formulaires courants dans la vie quotidienne pour définir cette propriété. Pymouss (talk) 21:09, 15 December 2020 (UTC)[reply]
@VIGNERON, Pymouss: Ah! merci pour vos réponses. Je comprends le raisonnement. Y a-t-il un mécanisme qui nous permettrait d'avoir cet échange avant que je procède au changement? J'avais d'abord tenté d'initié la conversation ici, mais manifestement ça n'a pas fonctionné. J'interpelle les contributeurs directement en plus d'ajouter un sujet dans la discussion ? Dirac (talk) 21:28, 15 December 2020 (UTC)[reply]
@Dirac: oui les pages de discussion sont assez peu fréquentées, la notification est une bonne solution y attirer du monde. J'utilise souvent l'outil externe NavelGazer pour savoir qui utilise principalement cette propriété (et donc qui est concernée par une changement sur ladite propriété). Cdlt, VIGNERON (talk) 21:45, 15 December 2020 (UTC)[reply]

Changing of label[edit]

The label for this property has been "street" since 2013 and later change to "located on street" ever since. Of course this includes alleys, lanes, parkways, paths, squares etc. User:ŠJů added square to some labels in some languages. This is not an improvement and just makes the label longer. I will remove it again. If you think the longer label is better, please establish clear consensus before changing it. Multichill (talk) 21:48, 26 February 2022 (UTC)[reply]

As the description states that this property is intended for all types of similar address data, the label should match. While alleys, lanes and paths as named linear traffic routes can be considered as street types, squares represents the second main type of this adress entry. --ŠJů (talk) 22:37, 26 February 2022 (UTC)[reply]
The purpose of this property was extented also to squares since 2016-06-11 in de: and en: by Srittau, since 2016-08-20 in it: by Gio.B.R., since 2017-09-24 in cs: and eo: by Venca24, since 2017-11-10 in ka: by David1010, since 2017-12-26 in it: by Αππο, since 2018-08-18 in hsb: by J budissin, since 2019-02-07 in be-tarask: by Taravyvan Adijene, since 2020-09-30 in es: by Olea, and so far there have been no objections to this extension. In most of these languages, "street or square" seems to be reasonably concise specification. Of course, it would be desirable to gradually reflect this change to all languages, and I considered it an old consensus that the label should be concise and in line with the description. Maybe, in some languages or countries, the word "street" or its local equivalent can be felt as a common term covering also squares, but in some languages or countries may not. In any case, the process of extending the meaning/purpose of the property to squares seems still consensually accepted, but not yet finished. --ŠJů (talk) 23:32, 26 February 2022 (UTC)[reply]
I agree with @Multichill that the former label was better, of course it includes other objects, streets in a wider sense. Vojtěch Dostál (talk) 09:37, 30 March 2022 (UTC)[reply]
I agree with @Multichill and @Vojtěch Dostál, street is broader, in Czech RUIAN – Václavské náměstí (Wenceslaus square) is street – https://vdp.cuzk.cz/vdp/ruian/ulice/477265. --Frettie (talk) 10:01, 30 March 2022 (UTC)[reply]

P3831 as qualifier[edit]

For many items the postal address differs from the actual location. For this reason, I propose to allow object has role (P3831)address (Q319608) as qualifier. MB-one (talk) 10:01, 16 April 2023 (UTC)[reply]

@MB-one Actual location is for physical objects like buildings while postal address is for institutions, isn't it? So they can't really be both on a single item except for a few exceptions. Vojtěch Dostál (talk) 10:08, 16 April 2023 (UTC)[reply]
In theory, you are correct. In practice, I've seen the related institution's postal address' street used as values for located on street (P669). MB-one (talk) 10:22, 16 April 2023 (UTC)[reply]