Property talk:P670
Documentation
number in the street address. To be used as a qualifier of Property:P669 "located on street"
| Description | street number, qualifier for property located on street (P669) "street". | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Represents | house number (Q18915527), house number (Q1413235) | ||||||||||||
| Data type | String | ||||||||||||
| Domain | According to this template:
places, more specifically architectural structure (Q811979)
According to statements in the property:
When possible, data should only be stored as statementsarchitectural structure (Q811979) | ||||||||||||
| Allowed values | (((지하|B) )?\d{1,5}(-\d{1,5})?\.?|\d{1,5}(((-\d{1,5})?([a-zA-Z]|bis|ter)?)|(\/\d{1,5}))?) | ||||||||||||
| Example | According to this template:
According to statements in the property:
When possible, data should only be stored as statementsWhite House (Q35525) → 1600 Baranagore Ramakrishna Mission Ashrama High School (Q19882251) → 37 | ||||||||||||
| Robot and gadget jobs | DeltaBot does the following jobs: | ||||||||||||
| See also | series ordinal (P1545), located on street (P669), conscription number (P4856), floor number (P5423), room number (P7532), street key (P1945) | ||||||||||||
| Lists |
| ||||||||||||
| Proposal discussion | Proposal discussion | ||||||||||||
| Current uses |
| ||||||||||||
| Search for values |
List of violations of this constraint: Database reports/Constraint violations/P670#Scope, SPARQL
^(((지하|B) )?\d{1,5}(-\d{1,5})?\.?|\d{1,5}(((-\d{1,5})?([a-zA-Z]|[а-яА-Я]|bis|ter)?)|(\/\d{1,5}))?)$”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P670#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P670#Type Q811979, SPARQL
Can by a future mandatory complex constraint (Help)
Violations query:
SELECT ?item ?value WHERE { { ?item p:P670 [ ps:P670 ?value] . } UNION { ?statement1 pq:P670 ?value. } UNION { ?ref pr:P670 ?value . ?statement2 prov:wasDerivedFrom ?ref. } . FILTER(REGEX(STR(?value), "^([\\d\\-a-zA-Z\\/ ,à\\.&)]+)$" ) = false). FILTER (STRLEN(?value) < 2) }List of this constraint violations: Database reports/Complex constraint violations/P670#Check very short strings
Broaden scope ? edit
Should the scope be broaden to mean number in the sense of numeric ID that can be stored in a string-type property ? That would seem rather natural in French (because we commonly use the word "numéro"), but that sounds a bit more confusing in English, as I do not think we should ever use this property for number in the sense of numeric quantity. --Zolo (talk) 19:25, 3 July 2013 (UTC)
- For me, it depends if we use this property as qualifier or not. If it is not used as qualifier, than a suggest to remain 'street number'. --Nightwish62 (talk) 19:50, 3 July 2013 (UTC)
Constraints edit
Currently, there are two constraints for this property. One demands the obsolete P107 (P107) to be geographical feature (Q618123). That one should be "type of building (Q41176)", I guess (or are there any other types of architectural structure (Q811979)s that have street numbers?). The other one restricts the format to be purely numeric. But in reality, a street address may consist of multiple street numbers, like 44–46 or 44/46, and at least in Germany, it's also common to add a letter suffix to one building's street number, like 44a and 44b, and as I just read in de:Hausnummer, also formats like 44/1 or 44½ or 12bis are used or have been used. I guess, the format should be more flexible here, or am I getting something completely wrong? --YMS (talk) 13:01, 3 December 2013 (UTC)
- I think you are right, but I don't know what to do with the format number violation. Perhaps, something like "should start with a number and not be too long" if you know how to express that ? --Zolo (talk) 14:14, 3 December 2013 (UTC)
- That should be something like "\d.{0,5}" (or, I'm not sure whether it would have to be "\d.{0,5}$" for that, though probably not). It would also be possible to have something like "\d+(–|-|/|½|\w+)?\d*" to cover all formats I've named, but surely that's not complete, and the expression would probably get quite complex some time. --YMS (talk) 14:56, 3 December 2013 (UTC)
- I have changed the format to "\d.{0,5}", it can be removed later if that proves unmanageable. As for the instance of architectural structure (Q811979), thinking about it, maybe it would also make sense to use this property for organizations, to indicate the address of the address of the headquarters ? Or maybe we should use headquarters location (P159), but I am not sure it is as convenient to reuse (because it we do not know beforehand that the value is the street and not, say, the city) --Zolo (talk) 15:09, 3 December 2013 (UTC)
- I have came across various house numbers with a - in it. This should be added too. Romaine (talk) 14:56, 12 July 2019 (UTC)
- I have changed the format to "\d.{0,5}", it can be removed later if that proves unmanageable. As for the instance of architectural structure (Q811979), thinking about it, maybe it would also make sense to use this property for organizations, to indicate the address of the address of the headquarters ? Or maybe we should use headquarters location (P159), but I am not sure it is as convenient to reuse (because it we do not know beforehand that the value is the street and not, say, the city) --Zolo (talk) 15:09, 3 December 2013 (UTC)
- That should be something like "\d.{0,5}" (or, I'm not sure whether it would have to be "\d.{0,5}$" for that, though probably not). It would also be possible to have something like "\d+(–|-|/|½|\w+)?\d*" to cover all formats I've named, but surely that's not complete, and the expression would probably get quite complex some time. --YMS (talk) 14:56, 3 December 2013 (UTC)
In Utah and Idaho in the United States, street numbers often have North/South/East/West as part of the street address, i.e., "102 N" or "3400 E". I'm not sure of the way to express that constraint. 23:19, 8 January 2020 (UTC)
Hyphens or dashes for address ranges? edit
Some usages seem to use hyphens, and some dashes (en or em), for buildings that occupy multiple street addresses (e.g. "23-25 High Street"). Should one or other be preferred, or is it up to data consumers to sort it out? Sam Wilson 04:26, 3 June 2022 (UTC)
I think either en or em dashes would be fine and preferable to hyphens if only because house numbers/street addresses can have hyphens in them. Though it might even make sense to create multiple street address statements depending on the nature of the building (would people mail to the units individually, or are they inseparable?) Middle river exports (talk) 17:01, 28 August 2022 (UTC)
- @Samwilson, Middle river exports: Even though en-dashes (–) are the typographically correct choice, I would go with hyphens. The OpenStreetMap Wiki uses hyphens, and searching for a hyphen on taginfo gives a lot more results than searching for an en-dash. On Wikidata, 1300 house number ranges use hyphens, compared to only 74 house number ranges with en-dashes:
- Try it!
SELECT ?item ?num WHERE { ?item p:P669 ?street. ?street pq:P670 ?num. FILTER REGEX(?num, "^[1-9]+–[1-9]+$") }
- Typing hyphens is easier than typing en-dashes on pretty much every keyboard. Dexxor (talk) 10:07, 29 August 2022 (UTC)
- I tend to use semicolons on OpenStreetMap for grouping addresses together and hyphens for addresses that actually have hyphens in them. Using semicolons in this way is kind of unconventional outside of OSM though so I don't think it's a great reference point here. Further, the data model of OSM is kind of limited in that you only get one value input per "property." If it would be easier than using em dash, using multiple statements might be appropriate for indicating this on Wikidata. (I am not sure if existing properties are good for this yet, if not, there could be something like "from address" and "to address" qualifier properties. GIS databases and the like already include fields like this to indicate ranges on street segments, so there would be some flexibility in how these could be used.) Middle river exports (talk) 10:17, 29 August 2022 (UTC)
- Yes, I think you're right, hyphens are the way to go. I like the idea of separate properties, although there might also be an issue for some places that are odd- or even-only, e.g. 18-22 Lorem Street is actually only addresses 18,20, and 22. So maybe some interpolation property could be useful. Although, having the correspondence between Wikidata and OSM (i.e. here to the housenumber tag) is super useful. Sam Wilson 03:24, 31 August 2022 (UTC)
- I tend to use semicolons on OpenStreetMap for grouping addresses together and hyphens for addresses that actually have hyphens in them. Using semicolons in this way is kind of unconventional outside of OSM though so I don't think it's a great reference point here. Further, the data model of OSM is kind of limited in that you only get one value input per "property." If it would be easier than using em dash, using multiple statements might be appropriate for indicating this on Wikidata. (I am not sure if existing properties are good for this yet, if not, there could be something like "from address" and "to address" qualifier properties. GIS databases and the like already include fields like this to indicate ranges on street segments, so there would be some flexibility in how these could be used.) Middle river exports (talk) 10:17, 29 August 2022 (UTC)