Property talk:P968
This property was previously considered for deletion but kept. |
Documentation
email address, prefixed with mailto:
mailto:\S+@\S+\.[\-\w]{1,13}
”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P968#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P968#Item P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P968#citation needed
List of violations of this constraint: Database reports/Constraint violations/P968#allowed qualifiers, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P968#Type Q43229, Q7397, Q13226383, Q132241, Q5, Q95074, Q464980, Q288514, Q102345381, Q1002697, Q1656682, Q732577, Q18127, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P968#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P968#Entity types
Pattern ^mailto:\/\/([-\w\.]+@([-\w]+\.)+[\w\.]+)[^\w]*$ will be automatically replaced to mailto:\1. Testing: TODO list |
Pattern ^(https|Https|HTTPS|http|Http|HTTP):\/\/:?(\S+@\S+\.[\-\w]{1,10})[^\w]*$ will be automatically replaced to mailto:\2. Testing: TODO list |
Pattern ^(mailto:[-\w\.]+@([-\w]+\.)+[\w\.]+)[\/,\.:][^\w]*$ will be automatically replaced to \1. Testing: TODO list |
This property is being used by:
Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
|
Data format[edit]
Currently, the property is set to the data type URL, even though the property discussion had advised to use IRI. In practice, this means that email addresses can only be entered in mailto: format, and all uses of the property so far are listed as constraint violations. --Daniel Mietchen (talk) 23:29, 1 August 2015 (UTC)
- I added "mailto:" to the pattern. --- Jura 10:49, 25 August 2015 (UTC)
Scope[edit]
Currently, this property is used for a series of personal email addresses. As the property isn't meant to be used for persons, these would need to be removed. --- Jura 07:19, 28 August 2015 (UTC)
- Interestingly, the number reduces as items get deleted for lack of notability. --- Jura 06:02, 3 September 2015 (UTC)
- fixed --- Jura 06:00, 26 September 2015 (UTC)
- @Jura1: Well that's a shame, we add Twitter accounts for people but not email accounts? Thibaut120094 (talk) 15:14, 26 September 2015 (UTC)
- Twitter is for output, email addresses end up being used for spamming .. Besides, I'm not sure if people would agree to have their address listed here. --- Jura 11:43, 27 September 2015 (UTC)
- @Jura1: Can you point to information about Wikidata being only for "broadcast information"? Because it isn't applied consistently, e.g. phone number (P1329). And email addresses of officials doesn't seem productive. Dispenser (talk) 21:45, 21 May 2016 (UTC)
- Is Wikidata? I don't know. Both properties tend to attract lots of trash. If you don't maintain it, it's bound to go that way. Both properties have been made for Wikivoyage which has anything but entries about people.
--- Jura 05:23, 22 May 2016 (UTC)
- Is Wikidata? I don't know. Both properties tend to attract lots of trash. If you don't maintain it, it's bound to go that way. Both properties have been made for Wikivoyage which has anything but entries about people.
- @Jura1: Can you point to information about Wikidata being only for "broadcast information"? Because it isn't applied consistently, e.g. phone number (P1329). And email addresses of officials doesn't seem productive. Dispenser (talk) 21:45, 21 May 2016 (UTC)
- Twitter is for output, email addresses end up being used for spamming .. Besides, I'm not sure if people would agree to have their address listed here. --- Jura 11:43, 27 September 2015 (UTC)
- @Jura1: Well that's a shame, we add Twitter accounts for people but not email accounts? Thibaut120094 (talk) 15:14, 26 September 2015 (UTC)
Change datatype and formatting[edit]
{{Editrequest}}
I propose to:
- change back the data type from URL to string
- change the regex removing the initial "mailto:"
- add formatter URL (P1630) with "mailto:$1"
- change all data from "mailto:email@domain.xxx" to "email@domain.xxx"
The reason is that this property can't be used correctly in it.voy as we want to show the email with a link to mailto: URI and you can't do [mailto:EMAILADDRESS EMAILADDRESS] right now. Filceolaire and Pyfisch proposed this change but the first one died. I'd like to know why they proposed to change the datatype --★ → Airon 90 15:46, 1 September 2016 (UTC)
- +1--Trockennasenaffe (talk) 09:43, 22 December 2016 (UTC)
- Comment This is a breaking change for data consumers and needs greater discussion and announcement. The first step also involves the developers and
I believe it can be done after the fourth one(not truth). Matěj Suchánek (talk) 07:21, 19 May 2017 (UTC)
- @Matěj Suchánek: Ok, how can I start such discussion? I want to do this kind of work --★ → Airon 90 10:22, 22 August 2017 (UTC)
Let's go on here: Wikidata:Requests for comment/Changes in email property --★ → Airon 90 13:03, 27 October 2018 (UTC)
Re-raising[edit]
@Filceolaire, Pyfisch, Trockennasenaffe, Matěj Suchánek, Airon90, Daniel Mietchen:@Jura, putnik, MisterSynergy, Toni 001, Dhx1: Revisiting this, I've found the requirement for a mailto: prefix can trip people up (especially submitting via quickstatemesnt, APIs and similar external tools. This is espercially since people are used to omitting prefixes for other identifiers (e.g. ORCID iD (P496) doesn't require "http://orcid.org/" to be included at the start). I realise the last vote at this RfC didn't reach quorum, but would it be possible to re-raise the issue? T.Shafee(evo&evo) (talk) 10:49, 10 October 2020 (UTC)
- I wouldn't change this property anymore. If the "mailto:" scheme prefix is removed all other wikis have to update their infoboxes. Ideally we would have a helpful abuse filter to suggest adding the "mailto:" scheme, but I assume the scheme check is built-in and executed before the abuse filter is run? --Pyfisch (talk) 12:40, 10 October 2020 (UTC)
- That's a great pity. I've found it easily causes errors from other tools that input to wikidata (e.g. quickstatements, or the API clients in python and R). It means input tools have to have additional custom checks for inputs to this function to check for the mailto: prefix and add it if absent. T.Shafee(evo&evo) (talk) 11:14, 18 October 2020 (UTC)
- Also note that on wikidata, if the mailto: prefix isn't included, the error message given is the rather cryptic: Could not save due to an error. This URL misses a scheme like "https://":. T.Shafee(evo&evo) (talk) 11:28, 20 October 2020 (UTC)
- I support this change (or a change to external-id if that is required for the formatter URL to work). --99of9 (talk) 12:08, 20 October 2020 (UTC)
Uses for people?[edit]
Although this property is originally intended to be used for Wikivoyage listing, PubMed and many database do include plenty of e-mail data of authors. This may be another way to identify authors (as no two people may share one same private e-mail address). I propose to remove the conflict of constraint about people. Thought?--GZWDer (talk) 20:19, 20 August 2017 (UTC)
- Of course, it is useful for people too. --Infovarius (talk) 09:04, 22 August 2017 (UTC)
- Yes but with respect of privacy: no personal emails, yes institutional emails --★ → Airon 90 10:21, 22 August 2017 (UTC)
- What anti-spam measures do you suggest? It seems fairly rare these days that people add links to email addresses and most official website indicate some preferred way of contact.
--- Jura 07:28, 23 August 2017 (UTC)- If available, why not adding data to the items? I think about politicians: usually they have their own official email address --★ → Airon 90 08:44, 23 August 2017 (UTC)
- I'm not contesting that people have email address, phone numbers etc.
--- Jura 08:47, 23 August 2017 (UTC)- @Airon90: However the email addresses listed in PubMed, like this one, are clearly researchers' personal emails. If they're allowed in PubMed, I don't think why it can not be allowed here.--GZWDer (talk) 17:34, 25 August 2017 (UTC)
- This was created for Wikivoyages' needs, not sure if they would still need it. Can you respond to my question?
--- Jura 05:47, 6 September 2017 (UTC)- Why can email addresses be allowed in PubMed?--GZWDer (talk) 07:40, 6 September 2017 (UTC)
- This was created for Wikivoyages' needs, not sure if they would still need it. Can you respond to my question?
- @Airon90: However the email addresses listed in PubMed, like this one, are clearly researchers' personal emails. If they're allowed in PubMed, I don't think why it can not be allowed here.--GZWDer (talk) 17:34, 25 August 2017 (UTC)
- I'm not contesting that people have email address, phone numbers etc.
- If available, why not adding data to the items? I think about politicians: usually they have their own official email address --★ → Airon 90 08:44, 23 August 2017 (UTC)
In our items for faculty of our university, their work email address is always given on their web pages, and we have been including it in the items that we create for them. These are not personal/home emails, so I don't see why such email addresses wouldn't be useful and appropriate to include. UWashPrincipalCataloger (talk) 18:29, 8 February 2021 (UTC)
- Template:UWashPrincipalCataloger I'd agree that there's a difference between a professional email versus personal email. These are cases where that data is being made deliberately public in journal articles and faculty webpages in line with academic responsibility to be contactable, as opposed to someone's personal contact being outed. The main edgecase is that some people use a non-institutional account for their contact email address on publications (example) so it's not possible to just screen emails by domain. T.Shafee(evo&evo) (talk) 03:54, 9 February 2021 (UTC)
- Above it was suggested we should do as pubmed does, what do you think of this? BTW, I'm curious what UWash email administrators think of it. --- Jura 06:26, 9 February 2021 (UTC)
- I can't say what UWash email administrators think, but I can say that the email system here has robust spam detection and each user on it has the ability to set filters to eliminate unwanted email. As a public research university, I would think that email addresses here are considered public information and are openly posted on both individual faculty web pages and in the university directory at https://www.washington.edu/home/peopledir/. UWashPrincipalCataloger (talk) 15:19, 9 February 2021 (UTC)
- My instinct is that for cases like this on, the author has specifically made that particular email address open data (at the very least for the use case of academic-related contact). That's partly why I think it'd be more reasonable to add the qualifier to the publication's P50 statement (Q37945441) rather than as a main statement to the person (Q90220463). T.Shafee(evo&evo) (talk) 07:19, 9 February 2021 (UTC)
- I support allowing emails to be listed for instances of human (Q5). However, if other editors are concerned about privacy, we could have a hard requirement for a citation, eg. a bot that removes all email properties lacking a reference. If people are listing a public email on their website, why not include it here? Daask (talk) 01:36, 10 February 2021 (UTC)
- We always already include a reference source (usually reference URL for the professor's webpage) for an email address, so I'm perfectly happy to support Daask's suggestion. UWashPrincipalCataloger (talk) 02:21, 10 February 2021 (UTC)
- This conversation stalled a bit, but I think it's also worth having similar requirements for then an email address is the qualifier for a P50 on a an academic paper. T.Shafee(evo&evo) (talk) 04:59, 23 February 2022 (UTC)
- We always already include a reference source (usually reference URL for the professor's webpage) for an email address, so I'm perfectly happy to support Daask's suggestion. UWashPrincipalCataloger (talk) 02:21, 10 February 2021 (UTC)
- I support allowing emails to be listed for instances of human (Q5). However, if other editors are concerned about privacy, we could have a hard requirement for a citation, eg. a bot that removes all email properties lacking a reference. If people are listing a public email on their website, why not include it here? Daask (talk) 01:36, 10 February 2021 (UTC)
- My instinct is that for cases like this on, the author has specifically made that particular email address open data (at the very least for the use case of academic-related contact). That's partly why I think it'd be more reasonable to add the qualifier to the publication's P50 statement (Q37945441) rather than as a main statement to the person (Q90220463). T.Shafee(evo&evo) (talk) 07:19, 9 February 2021 (UTC)
- I can't say what UWash email administrators think, but I can say that the email system here has robust spam detection and each user on it has the ability to set filters to eliminate unwanted email. As a public research university, I would think that email addresses here are considered public information and are openly posted on both individual faculty web pages and in the university directory at https://www.washington.edu/home/peopledir/. UWashPrincipalCataloger (talk) 15:19, 9 February 2021 (UTC)
- Above it was suggested we should do as pubmed does, what do you think of this? BTW, I'm curious what UWash email administrators think of it. --- Jura 06:26, 9 February 2021 (UTC)
Uses for Journals or Publications[edit]
I would like to see the constraints broadened to allow usage of this property on Journals and Publications. Example of one for contacting editorial staff for a Scientific Journal: https://uwpress.wisc.edu/journals/journals/er.html ERjournal@sebs.rutgers.edu Thadguidry (talk) 17:09, 23 July 2018 (UTC)
- @Thadguidry: I agree. I think it should also be used as a qualifier for corresponding authors on publications (example). T.Shafee(evo&evo) (talk) 10:41, 10 October 2020 (UTC)
- For journals: sounds good. Somehow the type constraint got deleted, borked. I restored it. I'm not sure about the qualifier .. --- Jura 11:02, 10 October 2020 (UTC)
- @Jura1:It still looks borked, no? I don't see periodical (Q1002697) or publication (Q732577) (I think publication should be the one allowed, we did this on Schema.org since most publications have organizations that run them, so this encompasses the widest logical class to constrain to) But neither is showing up in the constraint query results Try it!
SELECT ?Property_ ?Property_Label ?Property_Description ?class_ ?class_Label ?relation_ ?relation_Label WHERE { wd:P968 p:P2302 ?constraint_statement . ?constraint_statement ps:P2302 wd:Q21503250 . OPTIONAL {?constraint_statement pq:P2308 ?class_ .} OPTIONAL {?constraint_statement pq:P2309 ?relation_ .} SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". } }
- @Jura1:It still looks borked, no? I don't see periodical (Q1002697) or publication (Q732577) (I think publication should be the one allowed, we did this on Schema.org since most publications have organizations that run them, so this encompasses the widest logical class to constrain to) But neither is showing up in the constraint query results
This should really be an identifier rather than a normal property[edit]
Who can alter this? --Liuxinyu970226 (talk) 08:28, 23 February 2019 (UTC)
- @Liuxinyu970226: Email addresses already are identifiers in practice. If you are having some query problems can you explain the difficulty that you are having or perhaps elaborate on the WD mailing list about your issue? --Thadguidry (talk) 14:49, 10 October 2020 (UTC)
Citation[edit]
Given the personal nature of this property i'll like to add a 'citation needed' constraint. Trade (talk) 20:59, 14 May 2019 (UTC)
Geographical location on type constraint and not Geographical object?[edit]
I am seeing a lot of constraint violations that seem unnecessary, like Cemeteries and Heritage sites (ex. Oakland Cemetery (Q2008469) ) that want to use this property email address (P968). I am not best qualified to look deeply into it, but I suspect there's some easy fix in the classification or relationship between geographic location (Q2221906) and geographical feature (Q618123) (which seems to has characteristic (P1552) geographic location (Q2221906)? Or maybe not, and the easier fix is just also allow geographical feature (Q618123) as well in the Type constraint? --Thadguidry (talk) 14:49, 10 October 2020 (UTC)
I think we should allow intended public (P2360) as a valid qualifier for email address (P968). FWIW, the Free Software Directory has a text entry box for that… See there for more details. Genium. 20:49, Dec 3, 2020 (UTC+02:00)
Removing property scope constraint as main value[edit]
Email currently has a property scope constraint (Q53869507) of as main value (Q54828448). However, it's useful e.g. as a qualifier for the corresponding author of a journal article. I've therefore removed the contraint or the moment (unless there's a better way to flag an exception). T.Shafee(evo&evo) (talk) 05:08, 8 February 2021 (UTC)
- How to solve the spam problem discussed earlier? The property isn't meant to be used for humans. --- Jura 09:45, 8 February 2021 (UTC)
- @Jura1: Is there a way to include an exceptions list in the property constraint (P2302)s in the current system? Perhaps something like having an additional qualifier of excluding (P1011) = author (Q482980). Or, an equivalent of subject type constraint (Q21503250) but for use as a qualifier. It otherwise seems wasteful to create a separate property for 'author correspondence email address'. T.Shafee(evo&evo) (talk) 03:37, 9 February 2021 (UTC)
The statement wdt:P1628 <http://www.w3.org/2006/vcard/ns#Email> is wrong[edit]
vcard:Email is a class.
Should be changed to `wd:P968 wdt:P1628 <http://www.w3.org/2006/vcard/ns#email>`
- Changed and also added equivalent http://www.w3.org/2006/vcard/ns#hasEmail . --Dhx1 (talk) 11:16, 1 July 2022 (UTC)
Confusing warning when not using mailto:[edit]
When someone tries to enter an email address without the 'mailto:' it shows them this error:
"Could not save due to an error. This URL misses a scheme like "https://": example@example.org"
The warning suggests that you need to add 'https://' when you need to add 'mailto:' instead. Could this be changed? CoderThomasB (talk) 03:59, 15 November 2022 (UTC)
- @CoderThomasB, GZWDer: Indeed, having the same issue. A better warning text is needed.--U. M. Owen (talk) 10:34, 28 September 2023 (UTC)
- Properties for deletion
- All Properties
- Properties with url-datatype
- Properties used on 100000+ items
- Properties with format constraints
- Properties with conflicts with constraints
- Properties with constraints on items using them
- Properties with citation needed constraints
- Properties with qualifiers constraints
- Properties with constraints on type
- Properties with scope constraints
- Properties with entity type constraints