Property talk:P1329

Documentation

phone number
telephone number in standard format (RFC3966), without 'tel:' prefix

Represents

Data type

Domain

organization (Q43229), human (Q5), telephone number (Q214995), facility (Q13226383), administrative territorial entity (Q56061), broadcasting program (Q11578774), exhibition (Q464980), fair (Q288514), festival (Q132241), fictional entity (Q14897293), mass media (Q11033) or telephone booth (Q1143785)

Allowed values

(?:(?:(?:\ |00|011)[\.\/\-\ \t]*([17]|2(?:[07]|[1-689]\d)|3(?:[0-4679]|[578]\d)|4(?:[013-9]|2\d)|5(?:[1-8]|[09]\d)|6(?:[0-6]|[789]\d)|8(?:[1246]|[035789]\d)|9(?:[0-58]|[679]\d))[\.\/\-\ \t]*|([17])[\.\/\-\ ])?(?:$(\d{1,6})$[\.\/\-\ \t]*)?(?:(\d{1,6})[\.\/\-\ ])?(?:(\d{1,6})[\.\/\-\ ])?(?:(\d{1,6})[\.\/\-\ ])?(?:(\d{1,6})[\.\/\-\ ])?(\d{0,10}?)(\d{1,4} )(?:[\.\/\-;\ \t]*e?xt?[\.\/\-=\ \t]*(\d{1,14}))?)? (detect country codes, detect optional area codes in parentheses, extract all significant groups of digits, enforcing a split on the last group for its last 4 digits, detect and extract extension)

Usage notes

use RFC3966 format - e.g. 1-202-456-1414 https://github.com/googlei18n/libphonenumber or one of its ports is convenient to do automated validation and formatting
specify only one number in value; add another property for each needed number, and specify their usage in a qualifier

Example

White House (Q35525) → 1-202-456-1414 (RDF)
International Civil Aviation Organization (Q125761) → 1-514-954-8219 (RDF)
Baku House-museum of Uzeyir Hajibeyov (Q31301023) → 994-12-595-2558 (RDF)
Baku House-museum of Uzeyir Hajibeyov (Q31301023) → 994-12-595-2534 (RDF)
Chunghwa Postal Museum (Q5116373) → 886-2-2394-5185;ext=852 (RDF)
Squaxin Island Tribe (Q780825) → 1-877-386-3649 (RDF)

Format and edit filter validation

Abuse filter #85

Formatter URL

tel:$1

Tracking: usage

Category:Pages using Wikidata property P1329 (Q26986604)

Single value?

I don't really see why this property should have the constraint single value? There are lots of entities that use several phone numbers (my dad alone has three), so it's weird to limit it to one in Wikidata. @Jura1: You added this it seems, any comment? Jon Harald Søby (talk) 14:59, 18 February 2015 (UTC)[reply]

You might want to remove the "mandatory=true"-part. In general, one should be sufficient.

BTW, I'm not really comfortable with where this property leads us (looking at the "Neiman Marcus" listings with phone numbers). --- Jura 18:52, 18 February 2015 (UTC)[reply]

I agree with you and I am removing this nonsensical "Single value" constraint. -- LaddΩ chat ;) 12:50, 8 March 2016 (UTC)[reply]

extension

The property says the standard format is " 1-111-111-1111" (for American numbers anyway), but what is the standard to include an extension at the end? Amqui (talk) 12:46, 21 September 2016 (UTC)[reply]

@Amqui: I'd suggest that the extension should not be included in this property, but it may be a good idea if we had a qualifier property for it. Can you give more details on where you want to add this data? Danrok (talk) 17:26, 1 October 2016 (UTC)[reply]

@Danrok: It was for the phone number of some military units that I was doing. Amqui (talk) 20:12, 1 October 2016 (UTC)[reply]

I made a proposal below to switch to E.164. libphonenumber, many PBXs, and telephony clients allow for extension to be passed on with e.164 in the following manner 27123456667;ext=12. You can test it at https://libphonenumber.appspot.com/. I would appreciate it if you'd share your thoughts on the proposal, below. -- YaguraStation (talk) 10:40, 25 October 2018 (UTC)[reply]

Note that various numbers (e.g. in Canada) just use the letter 'X' to note the dial extension (seen in various ads); the E.164 extension syntax (with the semicolon and equl sign) is very uncommon and not user friendly (in addition this is a generic extension mechanism for adding various qualifiers, or constraints such as domains of use, that we don't want to support here in Wikidata, but as separate regular Wikidata qualifiers). The actual common terms of these extensions could be "post" / "poste", "desk", "bureau", "service", "room" / "pièce" / "chambre", "floor" / "étage", "block"/ "bloc" : these number are used as short synonyms for actual names of the target, that avoids a central operator to look for an index of services, or a current register of customers (e.g. in a hotel)... Also frequently, these extensions are not stable and may change every day without notice (nothing indicated in yellow pages), they have a short lifetime of usage and may be remapped (and it's also difficult to assert they are still correct). So these extensions should probably be avoided (unless they are used in advertizing and listed in yellow pages and operated by an automated PABX with a stable list of extensions they can handle directly.

May be these dial extensions should be a separate qualifier too in Wikidata; how to use them, i.e. the procedure that may require waiting hangup, then wait some seconds or for a mandatory message, or press '*' to skip directly to the service before dialing this extension or pronouncing it vocally (either directly to a bot, or to a desk operator that will reroute your call manually if the target is available to handle your call) is very specific to each target. Basically, using these extensions means that a direct dial with the number number does not work: the extension may be lost and not presented by the target PABX before actual hangup. Verdy p (talk) 08:56, 10 November 2020 (UTC)[reply]

"This property's value should not be present on any other item" ???

As some institutions have more them one phone number, some institutions share the same number. Especially if they below to the same group. Rodrigo Tetsuo Argenton (talk) 01:01, 13 June 2018 (UTC)[reply]

I've removed the 'distinct values constraint' here again, it makes no sense. Many items can share the same phone number. Husky (talk) 23:14, 4 September 2018 (UTC)[reply]

Phone number not matching the regex

I was adding the following phone number of Portugal and I got this message:

"The value for phone number ( 351214450049) should match the regex \ ([17]|[2345689]\d{1,2})(-\d{1,14}) ."

351 is the country code for Portugal, 214450049 is the phone number. Also, it's frequent to use spaces, e.g, 351 214 450 049. This number number is used in Q10388081. --Flávio Nuno Neves Rodrigues (talk) 17:13, 8 October 2018 (UTC)[reply]

The regex doesn't make sense in my regard as well. Next to the issues brought up by User:Flávio Nuno Neves Rodrigues, every country has special numbers, service numbers, N11 codes under which different organisations can be reached. -- YaguraStation (talk) 20:26, 16 October 2018 (UTC)[reply]

This case is now handled correctly by the current improved regexp, which can detect and distinghish the country code (see below for the long comments describing it with a link to a test tool). Verdy p (talk) 09:11, 10 November 2020 (UTC)[reply]

PROPOSAL: Change to E.164 entirely

So the regex is broken, doesn't even match for rfc3966, and additionally there is User:Tpt and User:TptBot changing regex-parsing numbers to an US format. Now, most PBXs and telephony clients allow for E.164. E.164 allows for emergency numbers, service numbers, extensions, N11, etc. There are plenty of libraries and resources for it. And it meets Google libphonenumber. Why don't we simply switch to it? CC: User:Flávio_Nuno_Neves_Rodrigues, User:Amqui, User:Danrok -- YaguraStation (talk) 09:49, 25 October 2018 (UTC)[reply]

Thank you for this proposal. Currently I am using the rfc3966 libphonenumber formatter to "normalize" phone numbers in order to do operations like efficiently track for duplicates. It allowed me to find a user pushing wrong phone numbers, probably for phishing. But indeed there is no unique rule for where "-" should be inserted. So switching to E.164 looks like a good idea to me even if it is a bit less human readable. Tpt (talk) 10:37, 25 October 2018 (UTC)[reply]

I can only support this. I work excactly in this business (Skype for Business-Engineer) and E.164 is the standard and it shouldn't be too much of a problem, to put every number in this format. Other formats, like here with dashes, are country specific and in every country the dashes would need to be in different places. Per example in switzerland you would never write dashes in between, you would use most likely spaces (p.e. 41 52 200 44 66) or a slash (052/200 44 66). Best regards Fundriver (talk) 12:32, 22 April 2019 (UTC)[reply]

Right; the current regex is broken, unusable for completely normal real-world phone numbers (look around). So, what now? We might start with loosening the regex a bit, so that we stop warning everyone trying to insert a correct number. And then let’s talk about the proper format? Even the current documentation is useless: RFC3966 means nothing, it even allows local numbers, not to mention visual separators we probably (?) don’t want here. --Mormegil (talk) 16:50, 25 March 2020 (UTC)[reply]

This case is now handled correctly by the current improved regexp, which can detect and distinghish the country code (see below for the long comments describing it with a link to a test tool). Verdy p (talk) 09:11, 10 November 2020 (UTC)[reply]

Citation

Given the personal nature of this property i'll like to add a 'citation needed' constraint. Trade (talk) 20:59, 14 May 2019 (UTC)[reply]

Acceptable format for entry – more help needed

Trying to enter a phone number is very difficult because of the formatting constraints. Apparently, just entering the digits (the most simple method) is unacceptable. An unknown pattern of digits and other symbols must be entered, but both examples shown are basic North American numbers. What do I do with 44(0)7807 386366 ? I'm beginning not to care. Senator2029 23:16, 10 March 2020 (UTC)[reply]

Do not use "(0)" in the number (in most countries including UK): it is not an area code but a dial prefix to be used only for calls from UK. It has to be suppressed from International calls, but note that some countries use the "0" as part of their numbering plan (e.g. in Italy for land line numbers all starting by "0" regional code, as opposed to mobile numbers starting by another non-"0" digit): this "0" must still be dialed after the country code. If you call UK with that "0", the call may not be routed correctly by international service providers.

As well, the national "0" prefix may be replaced by the caller by another prefix, specific to the country or operator used by the caller (e.g. to select a carrier: this is not possible for international calls after the country code; instead this replacement takes places on the leading " " which may translate as "011" in North America, or "00" in most other countries, or other prefixes for the default carrier or to make an external code to connect to the public network; this " " could also be replaced by a short number of a selected operator, such as "16xx" in France, or by a normal long phone number, or by a special value-added number: you compose the target country code, area code and local number after this custom prefix).

So the correct format is 44 7807 386366. We don't want interregional dial prefixes that are country-specific or operator-specific.

Finally, do not surround the country code (after or including the leading " ") in parentheses. Using a phone number starting by " " means that this phone number is internationally routable (its absence may mean that this is a national phone number only, except in North America and Russia, where the " " is implied only when the leading digit is "1" or "7", but this may cause problems for the detection of short numbers used in other countries; for now this tolerance for "1" and "7" is temporary but it may be dropped in the future to avoid breaking the specification of national short numbers, such as the "112" emergency call number in Europe, North Africa and Western Asia). Verdy p (talk) 09:23, 10 November 2020 (UTC)[reply]

After many searches and tests, I improved the regexp (see the URL in reference for further tests of formats : https://regex101.com/r/4wY5xA/64)

Here the PCRE regexp in expanded form (same as option regexp "x", which allows embedding non-significant whitespaces/newlines, and comments in (?#...)) which also uses non-capturing groups in (?:...) instead of just (...) for captured groups:

^(?:
  (?:
    (?: \  | 00 | 011 ) [\.\/\-\ \t]* (?# international dialing code prefix, ' ' is preferred)
    (?# capture group 1: country code after the required international dialing code prefix)
    ( [17]
    | 2(?: [07] | [1-689]\d )
    | 3(?: [0-4679] | [578]\d )
    | 4(?: [013-9] | 2\d )
    | 5(?: [1-8] | [09]\d )
    | 6(?: [0-6] | [789]\d )
    | 8(?: [1246] | [035789]\d )
    | 9(?: [0-58] | [679]\d )
    )
    [\.\/\-\ \t]*
  | (?# capture group 2: single-digit country code without international dialing code)
    ([17])
    [\.\/\-\ \t] (?# a separator is required for disambiguation)
  )?
  (?# capture group 3: area code between parentheses, optional)
  (?: \((\d{1,4})\) [\.\/\-\ \t]* )?
  (?# capture groups 4-7: leading groups of digits, optional)
  (?: (\d{1,6}) [\.\/\-\ ] )?
  (?: (\d{1,6}) [\.\/\-\ ] )?
  (?: (\d{1,6}) [\.\/\-\ ] )?
  (?: (\d{1,6}) [\.\/\-\ ] )?
  (?# capture group 8: start of the last group of digits, may be empty, not greedy to exclude the next group)
  (\d{0,10}?)
  (?# capture group 9: up to 4 digits at end of the last group of digits, required)
  (\d{1,4} )
  (?:
    [\.\/\-;\ \t]*e?xt?[\.\/\-=\ \t]* 
    (?# capture group 10: extension code, optional)
    (\d{1,14})
  )?
)?$

This new regexp could be used to revalidate and normalize numbers. It also attempts to detect and validate numbers in local format (short numbers that cannot have any country code), and the 10 capture groups now correctly match just the digits:

See [ https://regex101.com/r/4wY5xA/64 ] for tests (the regexp is in expanded form where whitespaces and comments are inserted).
capture group 1 is the country code (validated with the correct length of 1,2,3 digits, not starting by "0") when it follows an international dial code (" ", "00" or "011" are detected; international dial codes used from outside Europe "00" and USA "011" are not detected, such as "810" in Russia);
capture group 2 is the country code (detected only for country codes "1" in North America, and "7" in Russia), but only when it is followed by at least one separator;
capture group 3 is the regional/area code (detected only when it is surrounded by parentheses), for use in domestic calls from countries which still use them (including USA, Japan or Russia, but no longer most countries in Western Europe); they are in a separate group to allow preserving the parentheses surrounding area codes.
capture groups 4 to 7 are leading groups of digits (each group can have up to 6 digits), each separated by one character (" ", "-", "." or "/"), they may be empty; they are returned in separate groups only to allow capturing all digits and not any group separator, so that you can renormalize the separators (e.g. normalize to "-" in North America, or to " " in Europe)
capture group 8 is the start of the last group of digits (excluding the last 4 digits, see below), with up to 10 digits;
capture group 9 is the end of the last group of digits (up to 4 digits, restricted by privacy rules in various countries); if there's no privacy restriction (e.g. in short numbers like "10 12" where "10" and "12" would be in separate capture groups 8 and 9) these can be appended to digits in capture group 8;
capture group 10 contains the digits of the extension (prefixed by "x" or "ext", with insignificant case, possibly surrounded by other separators in " ", "-", ".", "/", or by separators in ";" or "=" for the RFC format).

Valid internationally callable E.164 numbers must have digits in capture group 1 or 2, not both (beware of capture group 2, don't automate the conversion)

All valid numbers should have a non-empty capture group 9 (including local-only "short" numbers, valid only in the same operator network, or for all operators in the same country if their supprot is legally required). Short numbers may be detected by the fact the capture group 3 (local-area digits) and the capture group 4 (1st group of local digits) are both empty (the actual digits are in capture groups 8 and 9, or just capture groupe 9 if there's no separator like in "112" or "911").

The capture group 10 for extension is most often empty (except for special calls, e.g. rerouted on social numbers, like Tencent in China, which uses long extensions often with 6 digits; other social networks may map there their own user id's via a shared "gateway" called from a unique number in the standard number plans for relevant countries: for such numbers there's generally no need to perform an international call as you may replace the gateway number for a more local one with reduced fees). But extensions are sometimes used locally in some companies in their PABX, and they can be dialed directly without waiting for a reply.

Now when I run the SPARQL check, most invalid entries are really in invalid format (for example, multiple phone numbers were packed into the same property value).

There's no attempt to filter the leading "0" in area codes (or in the first group of the national number, because this does not apply to all countries, notably in UK where the "0" is significant); however, given that country codes are now correctly detected, you can use it to reformat and renormalize the numbers (stripping the unneeded "0", selecting the separator between groups). Note: you should avoid changing the grouping, preserve at least one separator: the groupings are depending on types of numbers in the 1st local group (e.g. toll free, or value-added numbers) or for mnemonic reasons.

There's still no support for special codes like "P" or "," (pauses after hangup time), "*" prefix used via vocal bots after hangup in calls, or extra instructions in commas like: say "name" (I suppose this could be specified by additional qualifiers for call instructions.

Note that the E.164 canonical format (" CCNNNN..." without any separator) is not applicable to all phone numbers, only for number that are internationally callable without any other call procedure; notably it does not apply to emergency phone numbers using short numbers (like "112" in Europe and many other countries, or "911" in US) or valued-added or toll-free national numbers, as it may be used only on geographic numbers, mobile numbers, and Internet numbers (possibly with directly dialable extensions).

Note as well that not all extensions are directly dialable (this requires a PABX and capable internetworking across operators permitting the transmission of additional digits); I should probably add the "*" as the common prefix for vocal bots, and pauses after hangup (sometimes needed to hear a message before we can press "*" and dial other codes, if these can be automated). If a manual procedure is required, this should be in a separate qualifier.

Verdy p (talk) 02:13, 15 April 2020 (UTC)[reply]

Extension format

This is an extension of a discussion on User:Tpt talk page

The English description of the property is stating that telephone number in standard format (RFC3966), without 'tel:' prefix. This RFC3966 enforces that the phone number extension is encoded with the ;ext=. However, the current validation regex by verdy_p uses the ext. syntax. I would be in favor of using the ;ext= to follow the RFC3966 that is implemented in a lot of phone number formatting toolkits. What do you think about it? – The preceding unsigned comment was added by Tpt (talk • contribs).

When the property was established nobody thought of applying the RFC 3966. Entering phone numbers in Wikivoyage articles was a long-term process. Numbers were entered in a human-readable manner which differs from the RFC one.

Surely, the RFC format is the better one but it cannot be understood by "normal" humans who enter data manually. It seems that Wikidata is not able to convert the non-compliant numbers to compliant ones. --RolandUnger (talk) 07:09, 16 October 2020 (UTC)[reply]

I did NOT change the format used for the phone extension dial; it it still in the last capture group and still using the format with an "X" or "EXT" separator (as it was before) with possible spaces or dot separators before or after it, before the last digits. It has NEVER used the RFC extension mechanism which is used for another purpose: adding an unordered set of properties (key=value pairs) to transform it into an encapsulation format. Such mechanism is too generic for Wikidata as we can't validate it. However the Regexp above is now documented (before it was not) and it is clearly indicating how to capture the number groups and their role (capte group 10 contains all digits of the extension).

For Wikidata the RFC extension mechanism with properties should clearly not be used at all; it is too much flexible. But for the basic dial extension digits, the format remains fixed and still does not need a separate property and we certainly don't want the encapsulation mechanism from RFC3966 (which is optional and in fact already deprecated; note that this RFC is not part of any BCP and there are other competing RFC's, that are also restricting or even forbiding the use of this optional part which has only been informative and not prescriptive!).

The only real standard is ITU E.164. But the RFC3966 is wrong and not part of any BCP, its encapsulation mechanism is contradicted in other RFCs that restrict or forbid its use (it may be used only as a transport mechanism for plain-text only unstructured containers, but Wikidata is not unstructured). I think that the new addition to the RFC3966 is wrong.

Instead we should specific additional but separate properties (which can also be used a qualifiers). We already use qualifiers for some of the extensions Instead we should specific additional but separate properties (which can also be used a qualifiers). We already use separate qualifiers for some of the possible extensions (that could potentially be specified using the generic encapsulation syntax from RFC3966, but each one having its own datatype and restrictions that we cannot validate in a single regexp). Verdy p (talk) 12:58, 16 October 2020 (UTC)[reply]

Note: adding the RFC syntax (only for the dial extension, and not all the generic scheme described in the RFC but rejected in other RFC, scu has those for VoIP, SIP, or AT-commands used by modems) is not complicate, this is a minor change as it just consists in accepting the ';' and '=' separator around "ext" (instead of just spaces, dots or hyphens, the slash was also already present).

Above we can just replace [\.\/\-\ \t]*e?xt?[\.\/\-\ \t]* by [\.\/\-;\ \t]*e?xt?[\.\/\-=\ \t]*

This still does not change the capture groups described above, and the parsing will return the same results.

Verdy p (talk) 14:24, 16 October 2020 (UTC)[reply]

Thank you Verdy_p and RolandUnger. Indeed, the RFC formats has a lot of limitations. Maybe we could find a better and more readable format instead? Do you have any idea about it? I do not know much about phone numbers. If this format is easy to implement, I could run again my bot to harmonize phone numbers against it. Tpt (talk) 13:07, 17 October 2020 (UTC)[reply]

Read the section above that describes everything, including the content of each capture group, and the link to the test regexp site that contains various test case (I added recently new test cases for the ";ext=" format.

There's also a simple human description if the format (less technical) but that describes the principles of the format and some hints.

We cannot describe it fully in Wikidata properties without falling down to tricky technical details, that's why there's the section above.

I made these changes and fully documented it above with appropriate description of what it does currently. I did not break any existing rules but now many more phone VALID numbers are checked correctly and no longer rejected, and more phone numbers that are really INVALID are signaled.

What I did not implement is a set of rules per country, I partly validated the country dial codes to better filter those that are really valid and improve the support of E.164 (full support of the indicated RFC is not possible and in fact the RFC goals go beyond what Wikidata wants to validate, and we need limits to avoid abuses with tricky syntaxes thaty could be harmful and dangerous for privacy, so many possible extensions allowed in the RFC are rejected, as well this is not the only RFC that uses E.164 numbers, if you consider those additional RFC's made for SIP, VoIP, and new phone-like services on the web and many newer protocols, often proprietary and not developed or endorsed by an ITU standard).

So this regexp has limits. My goal was only to reduce the number of false rejections and improve the detection of invalid numbers. There are still many in the Wikidata base, but much less than those that were present before (and thanks to my edits, many users are now correcting their formats, and statistics continue to get better (while they were constantly worsening before).

Now what you can do is to use this regexp and change the format for numbers that now validate correctly, to use the RFC format for extensions. The capture groups contain everything you need to normalize these numbers (note that I do not capture the type of separators used: some countries have preferences for a space, others for hyphens, and you should avoid removing all separators completely and keep the grouping as they are because they are mnemonic and useful for many users even if they are ignored when dialing with the exception of parentheses for countries/networks with local dial rules in the same zone and to the same operator). Verdy p (talk) 20:34, 17 October 2020 (UTC)[reply]

Why does the formatting matter?

When a person calls a phone number, they only use numbers not - (). Those symbols are used only to break up a larger number into easier to remember fragments. So why all the fuss about the format and the broken method being used for the constraint? Senator2029 05:36, 18 January 2023 (UTC)[reply]

Wikidata usage instructions should be updated

Here's how I would make it look like:

English en: remove specify only one number in value; add another property for each needed number, and specify their usage in a qualifier, because I'm pretty sure there should only be one value per language; and replace use RFC3966 format - e.g. 1-202-456-1414 https://github.com/googlei18n/libphonenumber or one of its ports is convenient to do automated validation and formatting with the following:
- It is recommended to use https://libphonenumber.appspot.com/ (https://github.com/google/libphonenumber.git) to do automated validation and formatting. For example, White House Switchboard number would be formatted in "International format" as " 1 202-456-1414". Specify only one number in a value; add another value for each number, and specify details in qualifiers.
Other languages: not sure how machine translators do against Simplified Chinese zh-hans (or Traditional Chinese zh-hant, or any Chinese zh) or Hungarian hu, but Polish pl is my native language, so I can provide a proper translation for that:
- Zalecane jest użycie https://libphonenumber.appspot.com/ (https://github.com/google/libphonenumber.git) [str. ang.jęz.] do automatycznej weryfikacji i formatowania. Na przykład numer do Centrali Białego Domu zostałby sformatowany w "International format" [Międzynarodowy format] jako " 1 202-456-1414". Podaj tylko jeden numer w wartości; dodaj kolejną wartość dla każdego numeru, i dodaj szczegóły we właściwościach.

Thank you, 83.28.217.24 21:20, 31 July 2024 (UTC)[reply]

Property talk:P1329

Contents

Documentation

Single value?

extension

"This property's value should not be present on any other item" ???

Phone number not matching the regex

PROPOSAL: Change to E.164 entirely

Citation

Acceptable format for entry – more help needed

Extension format

Why does the formatting matter?

Wikidata usage instructions should be updated

Navigation menu

Property talk:P1329

Documentation

Single value?

extension

"This property's value should not be present on any other item" ???

Phone number not matching the regex

PROPOSAL: Change to E.164 entirely

Citation

Acceptable format for entry – more help needed

Extension format

Why does the formatting matter?

Wikidata usage instructions should be updated

Navigation menu

Search