Property talk:P968

From Wikidata
Jump to navigation Jump to search

Documentation

Representsemail address (Q1273217)
Data typeURL
Domainorganization (Q43229), software (Q7397), facility (Q13226383), festival (Q132241), human (Q5), fictional character (Q95074), exhibition (Q464980), fair (Q288514), social media account (Q102345381), periodical (Q1002697), event (Q1656682), publication (Q732577) or record label (Q18127)
Allowed values(?!.*\/.*)mailto:\S+@\S+\.[\-\w]{1,13}
ExampleArchaeological Museum of Palencia (Q549696) → mailto:museo.palencia@jcyl.es
Wikimedia Indonesia‎ (Q13098516) → mailto:info@wikimedia.or.id
State Historical Museum of Pará (Q10333512) → mailto:museuhistoricodopara@yahoo.com.br
High Commission of New Zealand, Suva (Q76385535) → mailto:nzhc@unwired.com.fj
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: usageCategory:Pages using Wikidata property P968 (Q118220854)
See alsoURL (P2699), error-report URL or e-mail (P10923), email unsubscribe URL or email (P11221)
Lists
  • Items with the most statements of this property
  • Count of items by number of statements (chart)
  • Count of items by number of sitelinks (chart)
  • Items with the most identifier properties
  • Items with no other statements
  • Most recently created items
  • Items with novalue claims
  • Items with unknown value claims
  • Usage history (total)
  • Chart by item creation date
  • Map of people by place values:
  • January 1st dates
  • Database reports/Constraint violations/P968
  • Map
  • Random list
  • Living people protection classproperty that may violate privacy (Q44601380)
    Proposal discussionProposal discussion
    Current uses
    Total269,467
    Main statement269,16499.9% of uses
    Qualifier2770.1% of uses
    Reference26<0.1% of uses
    Search for values
    [create Create a translatable help page (preferably in English) for this property to be included here]
    Format “mailto:\S+@\S+\.[\-\w]{1,13}: value must be formatted using this pattern (PCRE syntax). (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/P968#Format, SPARQL
    Item “instance of (P31): Items with this property should also have “instance of (P31)”. (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/P968#Item P31, SPARQL
    Citation needed: the property must have at least one reference (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/P968#citation needed
    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/P968#Scope, SPARQL
    Allowed entity types are Wikibase item (Q29934200): 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/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)[reply]

    I added "mailto:" to the pattern. --- Jura 10:49, 25 August 2015 (UTC)[reply]

    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)[reply]

    Interestingly, the number reduces as items get deleted for lack of notability. --- Jura 06:02, 3 September 2015 (UTC)[reply]
    ✓ fixed --- Jura 06:00, 26 September 2015 (UTC)[reply]
    @Jura1: Well that's a shame, we add Twitter accounts for people but not email accounts? Thibaut120094 (talk) 15:14, 26 September 2015 (UTC)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]

    Change datatype and formatting[edit]

    {{Editrequest}} I propose to:

    1. change back the data type from URL to string
    2. change the regex removing the initial "mailto:"
    3. add formatter URL (P1630) with "mailto:$1"
    4. 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)[reply]

    +1--Trockennasenaffe (talk) 09:43, 22 December 2016 (UTC)[reply]
     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)[reply]
    @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)[reply]

    Let's go on here: Wikidata:Requests for comment/Changes in email property --★ → Airon 90 13:03, 27 October 2018 (UTC)[reply]

    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)[reply]

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    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)[reply]

    Of course, it is useful for people too. --Infovarius (talk) 09:04, 22 August 2017 (UTC)[reply]
    Yes but with respect of privacy: no personal emails, yes institutional emails --★ → Airon 90 10:21, 22 August 2017 (UTC)[reply]
    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)[reply]
    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)[reply]
    I'm not contesting that people have email address, phone numbers etc.
    --- Jura 08:47, 23 August 2017 (UTC)[reply]
    @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)[reply]
    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)[reply]
    Why can email addresses be allowed in PubMed?--GZWDer (talk) 07:40, 6 September 2017 (UTC)[reply]

    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)[reply]

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    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)[reply]

    @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)[reply]
    • 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)[reply]
      • @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
        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". }
        }
        
        Try it!

    This should really be an identifier rather than a normal property[edit]

    Who can alter this? --Liuxinyu970226 (talk) 08:28, 23 February 2019 (UTC)[reply]

    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)[reply]

    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)[reply]

    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)[reply]

    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>`

    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)[reply]

    @CoderThomasB, GZWDer: Indeed, having the same issue. A better warning text is needed.--U. M. Owen (talk) 10:34, 28 September 2023 (UTC)[reply]