Property talk:P356

Documentation

• Start a query
• Current uses
• Statistics by class
• String length
• List of qualifiers
• Count

DOI
serial code used to uniquely identify digital objects like academic papers (use upper case letters only)

Description	DOI (Digital object identifier) reference for scientific publication
Represents	digital object identifier (Q25670)
Has quality	all caps (Q3960579)
Data type	External identifier
Template parameter	en:Template:Cite_journal : |doi=
Domain	scientific publication (note: this should be moved to the property statements)
Allowed values	(?i)10.\d{4,9}/[^\s]+ (Syntax described by Andrew Gilmartin (member of the U.S. Crossref team) for early DOIs (catches approximately 300,000 more DOIs than the "modern Crossref DOI" regular expression). Escape character added to avoid malformed input error.)
Example	Ecological guild evolution and the discovery of the world's smallest vertebrate (Q15567682) → 10.1371/JOURNAL.PONE.0029797 (RDF) Anne Shippen Willing, 1710–1791 (Q84371583) → 10.12987/YALE/9780300197051.003.0010 (RDF)
Commons example	→ 10.1038/S41586-021-04160-4 → 10.2307/3881065
Formatter URL	https://doi.org/$1 https://dx.doi.org/$1 info:doi/$1
Tracking: usage	Category:Pages using Wikidata property P356 (Q98107826)
See also	Handle ID (P1184), DOI prefix (P1662), EIDR content ID (P2704), ACM Digital Library citation ID (P3332), IEEE Xplore document ID (P6480), applicable 'stated in' value (P9073)
Lists	Search Commons for files with property Items with no other external identifier Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Database reports/Constraint violations/P356 Map Random list
Proposal discussion	[not applicable Proposal discussion]
Current uses	Total 36,685,572 Main statement 33,442,405 out of 318,158,353 (11% complete) 91.2% of uses Qualifier 28,775 <0.1% of uses Reference 3,214,392 8.8% of uses
Search for values

Explanations [Edit]

• An extreme example: article "Meat-eating by adult female Sumatran orangutans (Pongo pygmæus abelii)" (Q15082380) => 10.1002/(SICI)1098-2345(1997)43:2<159::AID-AJP5>3.0.CO;2-W

Format “(10\.[0-9]{4,}(?:\.[0-9]+)*/(?:(?!["&'])\S)+)|”: 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). Known exceptions: Q39347033, Q42684434, Q56806485, Q58222124, Q58850552, Q62139877, Q63646670, Q63648939, Q63862260, Q63862333, Q63862605, Q63862850, Q63862938, Q63863048, Q63863087, Q63863120, Q63863193, Q63863366, Q63871923, Q63871975, Q63872021, Q63872050, Q63872069, Q96085069, Q107814480, Q108532806, Q64683462, Q112031173
List of violations of this constraint: Database reports/Constraint violations/P356#Format, SPARQL

Single value: this property generally contains a single value. (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/P356#Single value, SPARQL

Distinct values: this property likely contains a value that is different from all other items. (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/P356#Unique value, SPARQL (every item), SPARQL (by value)

Qualifiers “object named as (P1932), reason for deprecated rank (P2241), online access status (P6954), issued by (P2378), reason for preferred rank (P7452), fee (P2555), edition number (P393), has characteristic (P1552), object of statement has role (P3831)”: this property should be used only with the listed qualifiers. (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/P356#allowed qualifiers, SPARQL

Conflicts with “instance of (P31): Wikimedia template (Q11266439), human (Q5), Wikimedia category (Q4167836)”: this property must not be used with the listed properties and values. (Help)

List of violations of this constraint: Database reports/Constraint violations/P356#Conflicts with P31, hourly updated report, SPARQL

Conflicts with “occupation (P106)”: this property must not be used with the listed properties and values. (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/P356#Conflicts with P106, search, SPARQL

Conflicts with “subclass of (P279)”: this property must not be used with the listed properties and values. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: IEEE 754-2008 revision (Q951059), IEEE 754-1985: IEEE Standard for Binary Floating-Point Arithmetic (Q14954905)
List of violations of this constraint: Database reports/Constraint violations/P356#Conflicts with P279, search, SPARQL

Format “(?i)((?!\b(%)).)*”: 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/P356#Format, SPARQL

Format “(?i)((?!\b(&)).)*”: 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). Known exceptions: A biomimetic study of the explosive discharge of the bombardier beetle (Q56806485), Computing urban mobile landscapes through monitoring population density based on cell-phone chatting (Q58850552), On the relationship between energy efficiency and complexity: insight on the causality chain (Q62139877)
List of violations of this constraint: Database reports/Constraint violations/P356#Format, SPARQL

Format “[^–]*”: 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/P356#Format, 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/P356#Entity types

Scope is as main value (Q54828448), as reference (Q54828450), 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/P356#Scope, SPARQL

Conflicts with “ISNI (P213)”: this property must not be used with the listed properties and values. (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/P356#Conflicts with P213, search, SPARQL

Format “^(?!10\.5555).*”: 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/P356#Format, SPARQL

Pattern ^10\.5281/zenodo\.268334$ will be automatically replaced to 10.5281/ZENODO.844869. Testing: TODO list

The property value will be transformed to uppercase automatically. Testing: TODO list

Pattern ^10\.1037//(.+)$ will be automatically replaced to 10.1037/\1. Testing: TODO list

Pattern ^(10\.\d+)\.(/.+)$ will be automatically replaced to \1\2. Testing: TODO list

Pattern ^10\.10\.(.+)$ will be automatically replaced to 10.\1. Testing: TODO list

Pattern ^10\.231/JIM(.+)$ will be automatically replaced to 10.2310/JIM\1. Testing: TODO list

Pattern ^(doi|DOI):(10\.(.+))$ will be automatically replaced to \2. Testing: TODO list

Pattern ^(https?://[^/]+\.(com|net|edu|uk|ch|fi|de|it|ie|nl|arxiv.org|aisnet.org|dyne.org|australianhumanitiesreview.org)/.+)$ will be automatically replaced to \1 and moved to full work available at URL (P953) property. Testing: TODO list

Pattern ^10\.11501/(\d+)$ will be automatically replaced to \1 and moved to NDL Persistent ID (P9836) property. Testing: TODO list

This property is being used by: hu:Sablon:Könyv infobox en:Template:Cite Q, en:Template:Academic-written review/testcases, en:Template:Academic peer reviewed, en:Template:Academic-written review ilo:Plantilia:Cite Q ja:Template:Cite Q hi:साँचा:सन्दर्भ विकिडाटा sl:Predloga:Navedi Q nn:Mal:Kjelde på Wikidata cy:Nodyn:Cite Q d:Template:Cite Q, d:Template:List of scholarly articles/Row da:Skabelon:Cite Q v:en:Template:Cite Q bs:Šablon:Academic-written review hy:Կաղապար:Տեղեկաքարտ Պարբերական tum:Template:Academic peer reviewed gl:Modelo:Academic-written review, gl:Modelo:Academic-written review/uso cs:Šablona:Cite Q Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Constraints

@Laddo: Can you take another look at the format constraint? All of the statements still violate it. -Tobias1984 (talk) 10:26, 25 August 2014 (UTC)

@Tobias1984: Seems that I broke it last April! Let's see like that... LaddΩ chat ;) 22:06, 25 August 2014 (UTC)

@Laddo: Works again! Thanks a lot! Tobias1984 (talk) 18:49, 26 August 2014 (UTC)

Allowed values

I just changed the format constraint to just two characters for the suffix, since such examples do exist. The DOI Handbook speaks of "a character string of any length chosen by the registrant", but I have not yet seen a suffix of less than two characters. --Daniel Mietchen (talk) 16:13, 16 August 2016 (UTC)

Canonicalizing DOIs

Officially, the DOI is a case-insensitive format; 10.1000/abc and 10.1000/ABC refer to the same thing. This is problematic for Wikidata, however, since Wikidata and the Wikidata Query Service would consider those two things to be separate. This is why in the constraint violation report, most of the "single value" violations are just entries that have the same DOI twice, but with different capitalizations. To make things more consistent, I propose:

1. All letters in DOIs should be lowercase.
2. This should be enforced by a bot.
3. Tools that work with DOIs should convert the letters in DOIs into lowercase upon input and output.

By standardizing around this, it makes DOI retrieval easier; we don't have to wonder if a DOI will be likethis or LikeThis. Thoughts? Harej (talk) 00:44, 15 January 2017 (UTC)

I agree entirely. A lowercase requirement should also be added to the format as a regular expression (P1793) statement and to the property proposal template above. --Daniel Mietchen (talk) 23:19, 15 January 2017 (UTC)

In general I agree, however I want to point out that according to the DOI Handbook "All DOI names are converted to upper case upon registration, which is a common practice for making any kind of service case insensitive.". The upper case formatting is also the common way of displaying DOIs as used by DataCite and their tools (e.g. cirneco). So I think we should follow those common practices and make rule 1: "All letters in DOIs should be uppercase." and rule 3: "Tools that work with DOIs should convert the letters in DOIs into uppercase upon input and output.". I hope this helps. --Frog23 (talk) 08:24, 16 January 2017 (UTC)

+1 Snipre (talk) 08:58, 16 January 2017 (UTC)

Converting to a canonical format is something that I can support. I read "All DOI names are converted to upper case upon registration" pointed to by Frog23, section 2.4 Case sensivity. On the other hand I see Elsevier, Wiley and Science (e.g., [1] and [2], [3]) using lowercase. So it is better to use lowercase? Copy-paste would be easier. Note that it is only ASCII [a-z] characters where case insensivity applies. non-ASCII case distinguishing should still be possible. — Finn Årup Nielsen (fnielsen) (talk) 11:11, 16 January 2017 (UTC)

That is what the DOI handbook says, Frog23, but I haven't seen many all-caps DOIs in practice; it's been either lowercase or camelcase. I am fine with all-uppercase if that's what everyone else agrees to. Harej (talk) 15:46, 16 January 2017 (UTC)

It seems that @Magnus Manske:'s sourcemd is using uppercase. — Finn Årup Nielsen (fnielsen) (talk) 20:14, 16 January 2017 (UTC)

And yet Crossref seem to normalize to lowercase. (Also, as Daniel Mietchen pointed out on Twitter, URLs in general are normalized to lowercase.) Harej (talk) 20:40, 16 January 2017 (UTC)

Can confirm that SourceMD converts to uppercase. Best that I can tell, most journal article items on Wikidata come from SourceMD. Between that, the DOI specification, and the recommendation of DataCite, I am leaning toward normalizing with uppercase letters. Harej (talk) 21:26, 16 January 2017 (UTC)

I changed SourceMD to uppercase after reading this thread, forgot to mention it here. --Magnus Manske (talk) 09:52, 17 January 2017 (UTC)

If there is no further discussion over the next few days, I will go ahead with standardizing around uppercase letters. Harej (talk) 05:26, 18 January 2017 (UTC)

Harej I changed my bot to make DOI uppercase Gstupp (talk) 01:44, 29 January 2017 (UTC)

@Harej, Gstupp: Please wait a moment. For a possible use of Wikidata items as source for {{cite journal}} (or equivalents in other languages) it would be perfect, if the DOIs are not changed from the form on the publisher's page. Your effort to normalize the DOIs according the specification is praisable, but for backwards compatibility I think we should stick to the form used by the publisher, even if it's formally wrong.--Kopiersperre (talk) 17:49, 20 February 2017 (UTC)

Both crossref.org and doi.org redirect searches for 10.1002/ASI.23162 from the uppercase to the lowercase version. Are there any valid examples where this redirection does not happen? LeadSongDog (talk) 18:43, 14 June 2017 (UTC)

The two DOI registration agencies Crossref and DataCite updated their DOI display guidelines in 2017 [4] and [5]. There is no requirement to display DOIs in uppercase or lowercase, but the common practice is increasingly to user lowercase.

Adding DOIs for institutions from GRID

I am going to import FundRef identifiers, stated as DOIs with the appropriate DOI prefix (10.13039) from the GRID dataset. All items that have a GRID ID (P2427) and no DOI (P356) will receive a DOI (P356) if there is a unique FundRef id for that GRID id in the latest dump. The statements will have a reference, which will be the DOI of the dataset they come from. Let me know if you have any concerns. − Pintoch (talk) 19:49, 1 February 2017 (UTC)

Pintoch, I am not sure I follow. Are these DOIs for organizations? Aren't they typically assigned to documents? Harej (talk) 00:53, 2 February 2017 (UTC)

DOIs can be assigned to many sorts of things, including institutions. Here is an example: https://doi.org/10.13039/501100004071 is the FundRef DOI for Khon Kaen University (Q368329). − Pintoch (talk) 08:07, 2 February 2017 (UTC)

Fixing a DOI in many references

Is it okay to use {{Autofix}} to change the DOI in a widely used reference? − Pintoch (talk) 09:02, 26 August 2017 (UTC)

I don't think it should be done in general, but in this specific case you already replaced everything imported from one publication with that of another publication and the first publication was withdrawn. So effectively all references point to the wrong publication.
--- Jura 11:09, 26 August 2017 (UTC)

Yes, many apologies for that. I can also change the DOIs myself if that is better. − Pintoch (talk) 11:23, 26 August 2017 (UTC)

EIDR

The EIDR P2704 resolver is no general DOI resolver, e.g., https://ui.eidr.org/view/content?id=10.1000/182 fails, but https://ui.eidr.org/view/content?id=10.5240/BE8E-B5BA-E323-D321-EFA7-9 in their own 10.5240 registry works. Please remove EIDR from the P356 formatter URLs. –2.247.247.18 04:15, 18 September 2017 (UTC)

{{Edit request}} –89.15.239.137 21:56, 30 September 2017 (UTC)

It's currently not active. The regex should limit the scope.
--- Jura 17:08, 30 January 2018 (UTC)

Fixed URI

The URI for a RDF record is still "http://dx.doi.org/<some record>". You can verify that by running curl --location --header "Accept: text/turtle" https://doi.org/10.1371/JOURNAL.PONE.0029797 | grep 10.1371. The formatter URI for RDF resource (P1921) sets the URI (wdtn:P356) and should like to the URI. This is just like Wikidata where we use https everywhere, but in the rdf use http for the URI. See Property_talk:P1921#Incorrect_URI's for background info. Multichill (talk) 13:38, 8 September 2018 (UTC)

DOI Format error is from original (and it works)

I think there's an applicable discussion on this, but I won't intrude. The DOI 10.1666/PLEO0022-3360(2007)081[0797:BPASAF]2.0.CO;2 manages to work from Bizarre Permian ammonoid subfamily Aulacogastrioceratinae from southeast China (Q57268695). I get a format constraint, but I don't know what to do. Trilotat (talk) 00:49, 13 October 2018 (UTC)

This DOI is valid also according to Wikidata, it just looks weird. I think it comes from an earlier attempt for article IDs Vladimir Alexiev (talk) 11:57, 13 February 2022 (UTC)

unhelpful duplicates

The distinct values constraint is flagging Factors in the prevention of wound dehiscence during pneumatic retinopexy (Q43570596) and Factors in the prevention of wound dehiscence during pneumatic retinopexy (Q43570600), because it seems the DOI is based on a page number and these two short "articles" are on the same page. I guess there may be quite a few of these cases, but I don't see that there's anything that can be done about them. They will just clog up the constraint failures list, which would otherwise be useful for finding items that should be merged. Any ideas? Ghouston (talk) 04:33, 12 February 2019 (UTC)

What to do if DOI doesn't exist at doi.org?

How to address when a DOI is wrong (doesn't exist) and I'm unable to find the right DOI? In this case, PubMED points to it.

• EDITORIAL RETRACTION: MiR-181c Regulates Human Embryonic Stem Cell (Q48783702)

Thanks, Trilotat (talk) 15:11, 22 February 2019 (UTC)

I would add the PubMed ID as a source and mark the claim as deprecated. − Pintoch (talk) 15:26, 22 February 2019 (UTC)

@Pintoch: Sorry to be thick-headed, but can you demonstrate at Q48783702? I started to do it, but the only option to mark that deprecated DOI was reason for deprecated rank (P2241) which appears to require a QID. The PubMED ID also points to a bad DOI, so I'm not sure where to go with this. Merci. Trilotat (talk) 16:05, 22 February 2019 (UTC)

@Trilotat: Done! You might find Help:Ranking useful. Note that there is a difference between marking a claim as deprecated and adding a reason for deprecation as qualifier (it is a good idea to add reason for deprecated rank (P2241), but that by itself is not going to change the rank of the statement.) The problem with the current claim ranks is that they are not very visible in the interface, see https://phabricator.wikimedia.org/T206392 for some discussion about that. − Pintoch (talk) 16:36, 22 February 2019 (UTC)

@Pintoch: Thanks! I think I understand the ranking. I have a question about how to apply it in the special case of retracted paper (Q45182324) if you want to pop over there to take a look. Trilotat (talk) 18:42, 22 February 2019 (UTC)

@Trilotat: I have made the edit that I suggested on Q48783702, what else do you want me to do? I do not have any edit to suggest on retracted paper (Q45182324). − Pintoch (talk) 18:54, 22 February 2019 (UTC)

@Pintoch: Nothing else, thanks. I was just noting that I had a question over at the talk page for Q45182324 where I wondering if it was necessary to bump up "retracted paper" over "scholarly article" within P31. I don't expect you to answer. I was was just sharing that I had that question there since you educated me about ranking. Trilotat (talk) 18:58, 22 February 2019 (UTC)

@Trilotat: ok thanks, I had not realized you were talking about the talk page of that item, sorry. − Pintoch (talk) 19:05, 22 February 2019 (UTC)

How to address a DOI that redirects to a different DOI?

@Pintoch: I understand that articles should normally have only one DOI. I have found that some items have a DOI that redirect to a different DOI, e.g. Q51394575. I marked as deprecated the DOI that redirects to the other DOI.

1. Am I correct to leave the "redirecting" DOI so to avoid someone adding another version of this same article based on that redirecting DOI?

2. Is deprecation the right way to distinguish? I didn't add a reference to the "redirecting" one since I wasn't sure what to use.

Thanks again. Trilotat (talk) 15:55, 26 February 2019 (UTC)

Hi Trilotat - to me, it looks right, but I have not worked much with publication items: you might want to ask Fnielsen, Daniel Mietchen or Egon_Willighagen who are more knowledgeable on this. (Does the sourcemd tool detect DOIs that are marked as deprecated and avoids creating a new item in that sort of case?) − Pintoch (talk) 17:23, 26 February 2019 (UTC)

Pulling in Magnus Manske... --Egon Willighagen (talk) 19:50, 26 February 2019 (UTC)

Fnielsen, Daniel Mietchen or Egon_Willighagen, I think SourceMD should NOT create a duplicate item if the DOI exists in deprecated form. I've created a proposal on Magnus Manske's BitBucket to resolve the issue at [6]. Do you think I've stated the issue effectively there? Trilotat (talk) 13:09, 1 March 2019 (UTC)

CiteseerX DOI parameters

I see a constraint violation on a recently updated reference I made on outer shell (Q61976836) where you can see the `doi=` parameter in the url for that reference. Is this violation expected? Thadguidry (talk) 23:39, 5 March 2019 (UTC)

I think the DOI is wrong. I followed the link and got an error page. Trilotat (talk) 00:39, 6 March 2019 (UTC)

@Thadguidry: CiteSeerX "dois" are completely different from actual DOIs. It's just an unfortunate use of the same terminology. No CiteSeerX doi should be used with DOI (P356). − Pintoch (talk) 08:57, 6 March 2019 (UTC)

@Pintoch: Ah, thanks, Antonin, I didn't know that. We'll, at least now we have this info recorded here to alert others that might come looking like I did. Thadguidry (talk) 14:19, 6 March 2019 (UTC)

Right! Use CiteSeerX article ID (former scheme) (P3784) for such Vladimir Alexiev (talk) 11:42, 13 February 2022 (UTC)

Dashes in DOI

Several items had DOIs such as 10.1088/1674–4527/19/4/53 with a dash "–" instead of "-", and the links weren't working. I searched for the prefix "10.1088/1674–4527" to correct them (around 170 items, all in the range Q68000000 to just above Q69000000), but there are probably similar errors with different prefixes. The query service isn't working for this, probably as there so many items with DOIs; is there a way of finding them, and are both types of dash used in DOIs? Peter James (talk) 21:59, 23 April 2020 (UTC)

It could be added to the regular expression constraint that checks for lower case letters. It should then be something like [^a-z–]*, and the description would be something like "do not use lowercase letter or long dash". Ghouston (talk) 00:29, 24 April 2020 (UTC)

@Peter James: Yeah, WDQS doesn't really work for this, though you might be able to do it if this is just one journal and you can add a triple requiring the item to be published in that journal, for instance. What I've resorted to in this sort of case though is getting some sort of dump - there was a tool for this in wmflabs but I can't find it just now. Or the full RDF dumps could be used I guess, but they're pretty unwieldy. ArthurPSmith (talk) 14:21, 27 April 2020 (UTC)

Krbot would probably find them. --- Jura 14:33, 27 April 2020 (UTC)

@Ghouston: I modified the constraint as you suggested. @Jura1: If you check the constraint page you'll notice that Krbot hasn't successfully updated the page since February; in fact it's been a bit of a bot fight: KRbot2 crashes, Deltabot replaces the page with a bad subset of the violations, and Krbot has recently been subbing in the last good KRbot2 page from February 16 - way out of date! ArthurPSmith (talk) 14:43, 27 April 2020 (UTC)

• I see you removed the qualifier it doesn't handle .. let's see how it goes. --- Jura 14:50, 27 April 2020 (UTC)

Sci-Hub (Q21980377) formatter URLs are rejected by spam filter

third-party formatter URL (P3303) values from Sci-Hub (Q21980377) are rejected by the spam filter. I cannot talk about the URLs here because of the spam filter, however they can be constructed by adding /$1 to the official website (P856) of Sci-Hub (Q21980377). These are valid formatter URLs for DOIs. How to add them? --Haansn08 (talk) 00:37, 3 October 2020 (UTC)

Constraints

Current constraints don't like the look of https://doi.org/10.5753/webmedia_estendido.2019.8152, but it works and is listed as a valid DOI. Used in Libreflix: A Peer-to-Peer On-demand Video Platform for Free Streaming (Q104760640) NMaia (talk) 15:12, 9 January 2021 (UTC)

@NMaia: DOI's are case-insensitive, but Wikidata external id's need to be unique to be useful; we uppercase all DOI entries to help with this issue. A bot will probably take care of this for you, but if you replace the webmedia_estendido with WEBMEDIA_ESTENDIDO it should be fine. ArthurPSmith (talk) 15:46, 11 January 2021 (UTC)

@ArthurPSmith: Thanks! I tried doing that but it still seems to violate constraints. NMaia (talk) 03:38, 12 January 2021 (UTC)

@NMaia: Oh, you also left in the https://doi.org/ prefix - as with most other Wikidata ID's, that part is not actually part of the ID as recorded here. ArthurPSmith (talk) 15:14, 12 January 2021 (UTC) (PS I fixed it!)

15138 wrong values

Currently we have huge number of wrong DOI values. Lets start fix process. The most popular error is identifiers with CLICA prefix (see Q46070240 as example). I did not find any way to convert such identifiers to some valid ID. I plan to delete all 3224 identifiers of this type. Do we have better ideas maybe? — Ivan A. Krestinin (talk) 21:09, 9 June 2021 (UTC)

I deleted the most of wrong DOI values and fixed others. Now we have zero format violations. — Ivan A. Krestinin (talk) 08:04, 17 July 2021 (UTC)

@Ivan A. Krestinin:, could you detail what you did? As I recall some things needing fixing were nontrivial (i.e. had to be looked up in a table rather than auto-fixed in some way). Though maybe that wasn't for the format violation cases. Anyway, thanks for doing this, but I would be interested in hearing exactly what you did. ArthurPSmith (talk) 00:27, 20 July 2021 (UTC)

8329 values was deleted, sample edit: [7]. 2063 values was fixed, sample edit: [8]. 205 values was converted from short form to full DOI, sample: [9]. Others was fixed or removed using {{Autofix}}-es and manually. Fixing all such issues was preparing stage for another big task: detecting and merging 26649 duplicates, sample: [10]. — Ivan A. Krestinin (talk) 22:39, 20 July 2021 (UTC)

Also I run another code validation job. It detected and deleted 79763 wrong codes. Some examples: [11], [12]. This job removed many DOI codes conflicts. After this many items become free for merge. Total merged items count is 50327 now. Some merge examples: Q92928238, Q83964408. — Ivan A. Krestinin (talk) 21:11, 24 November 2021 (UTC)

Formatting query from a newbie

Hi, I'm a newish Wikidata editor and am having trouble with DOI formatting. Whether I enter https://doi.org/10.31389/lseppr.25 or 10.31389/lseppr.25 I'm getting an error message - The value for DOI (https://doi.org/10.31389/lseppr.25) should match the regex (10\.[0-9]{4,}(?:\.[0-9]+)*/(?:(?!["&'])\S)+)| and The value for DOI (10.31389/lseppr.25) should match the regex [^a-z]*. https://www.wikidata.org/wiki/Q108901210 Both entries give a resolvable clickable link, but I'm struggling to resolve the error message. Could anyone offer advice, Thanks HelsKRW (talk) 11:08, 18 October 2021 (UTC)

Hi, just use upper case and remove "https://doi.org/" prefix: [13]. Or do not wary about this) Bot will fix such simple issues. — Ivan A. Krestinin (talk) 16:12, 18 October 2021 (UTC)

Thank you for your help - much appreciated. HelsKRW (talk) 08:33, 19 October 2021 (UTC)

Working DOI results in a format constraint violation

The following doi 10.1046/j.0956-540x.2001.01382.x results in constraint violation, but it works. Might someone update the constraints to allow for it? Trilotat (talk) 00:34, 27 October 2021 (UTC)

• Hi, use upper case: 10.1046/J.0956-540X.2001.01382.X — Ivan A. Krestinin (talk) 16:52, 27 October 2021 (UTC)
• @Trilotat: DOI's are case-insensitive, but SPARQL is not, so for exact-matching queries in Wikidata we default to upper-case (I believe there's a bot that enforces this after some period of time). ArthurPSmith (talk) 17:06, 27 October 2021 (UTC)

Querys

Without an author, just an author string Back ache (talk) 21:13, 6 February 2024 (UTC)