fixes #1

There is an invalid trailing comma after the last item in each of the JSON files.

• db=pubmed: https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=28507505&retmode=json
• db=pmc: https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pmc&id=5410569&retmode=json

Sounds good - updated to use undefined.

Updated to process the identifiers in a single loop.

The code in the PR is more explicit, by comparing those values to what's expected based on the uid.

Instead of looping through several times, it could perhaps build an object containing the articleid keys and values in a single step.

It's tricky, because the pmcid, pmc, pmid and pubmed articleid values are different in eSummary responses when the db is either "pubmed" or "pmc".

I've had another look, and it might be safe to say that if there's a "pubmed" articleid (only present in "pubmed" responses) then use that, otherwise if there's a "pmcid" articleid (present in both responses, but only with a useful value in "pmc" responses), then use that.

As well as adding a DOI value from the articleids array, this improves handling of PMID and PMCID values and URL generation from those IDs.

Fixes #21

Because a DOI is often used to identify a citation, it would be useful to have the DOI included in the data parsed from the eSummary results.

Code

const fetch = require('node-fetch')
const { toCSL } = require('astrocite-eutils')

fetch('https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=28507505&retmode=json')
  .then(response => response.json())
  .then(toCSL)
  .then(items => items[0].DOI)

Expected behavior:

Output: 10.3389/fnmol.2017.00112

Actual behavior:

Output: undefined

When transforming the authors array, if the author's authtype equals CollectiveName, return just a literal name string.

Fixes #18

Using eFetch XML rather than eSummary JSON as the source data would be the ideal solution, but that would be a bigger change so I haven't attempted it here.

This treats eSummary entry fields that were mapped to CSL "title" or "container-title" fields as HTML, and runs them through the decode method of he to decode any HTML entities.

fixes #17

I'm using the oidc-client library to authenticate users, and after successfully authenticating a user with ORCID it makes a cross-domain request to fetch the user's profile information.

Unfortunately an OPTIONS request to https://sandbox.orcid.org/oauth/userinfo fails: the request has the Access-Control-Request-Headers: authorization header but the response has only access-control-allow-headers: X-Requested-With,Origin,Content-Type,Accept,x-csrf-token - authorization is missing from the allowed headers.

Would it be possible to add authorization to the list of allowed headers?

When an author has authType "CollectiveName", the name should be treated as a literal string.

Code

const fetch = require('node-fetch')
const { toCSL } = require('astrocite-eutils')

fetch('https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=21255862&retmode=json')
  .then(response => response.json())
  .then(toCSL)
  .then(items => items[0].author)

"authors": [
    {
        "name": "Lister AM",
        "authtype": "Author",
    },
    {
        "name": "Climate Change Research Group.",
        "authtype": "CollectiveName",
    }
],

Expected behavior:

[Object {family: "Lister", given: "AM"}, Object {literal: "Climate Change Research Group."}]

Actual behavior:

[Object {family: "Lister", given: "AM"}, Object {family: "Climate", given: "Change"}]

Here's an example of a journal title containing an ampersand:

"fulljournalname": "Trends in ecology & evolution"

According to the PubMed DTD, markup can be b, i, sup, sub and u.

<!ENTITY % text "#PCDATA | b | i | sup | sub | u" >

It seems that string fields in JSON returned from the eSummary API contain markup that's HTML-encoded.

e.g. https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=28507505&retmode=json

This is unexpected but I imagine unlikely to change, unless it's a new bug, so fields like title and containerTitle need to go through a step where named HTML entities are converted to Unicode characters.

Code

const fetch = require('node-fetch')
const { toCSL } = require('astrocite-eutils')

fetch('https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=28507505&retmode=json')
  .then(response => response.json())
  .then(toCSL)
  .then(items => items[0].title)

Expected behavior:

The article title contains HTML markup.

Protein-Protein Interaction Among the FoxP Family Members and their Regulation of Two Target Genes, <i>VLDLR</i> and <i>CNTNAP2</i> in the Zebra Finch Song System.

Actual behavior:

The article title contains HTML-encoded markup.

Protein-Protein Interaction Among the FoxP Family Members and their Regulation of Two Target Genes, <i>VLDLR</i> and <i>CNTNAP2</i> in the Zebra Finch Song System.

⚠️ Dependabot is rebasing this PR ⚠️

If you make any changes to it yourself then they will take precedence over the rebase.

Bumps eslint-utils from 1.4.0 to 1.4.2. <details> <summary>Commits</summary>

• 4e1bc07 1.4.2
• e4cb014 🐛 add null test
• 230a4e2 1.4.1
• 08158db 🐛 fix getStaticValue security issue
• 587cca2 🐛 fix getStringIfConstant to handle literals correctly
• c119e83 🐛 fix getStaticValue to handle bigint correctly
• See full diff in compare view </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Is a mapping available anywhere from this tool's output format to the standard fields of CSL JSON?

I see, thanks for the explanation. I'd added both astrocite and this library to a comparison and hadn't spotted that both were using the same parser.

If there's any difference in the final output I might still look at a map to CSL, partly to ease comparison.

Is a mapping available anywhere from this tool's output format to the standard fields of CSL JSON?

Please merge this - the test framework shouldn't be part of the dependencies when installing this package.

Add ISBN, ISSN, PMCID and PMID to BibTeX -> CSL field mapping

[x] There is an associated issue. [x] Code is up-to-date with the master branch [x] You've successfully run npm test locally [x] There are new or updated unit tests validating the change

refs #12

It would be useful for someone to either look through the list of CSL fields and see which other fields might need to be added here (I can think of at least PMID and ISSN), or allow this Map to be extended by a parser option.

https://www.acm.org/publications/authors/bibtex-formatting has an example BibTeX file containing these extra fields:

@article{Abril:2007:PHD:1188913.1188915,
author = {Abril, Patricia S. and Plant, Robert},
title = {The Patent Holder's Dilemma: Buy, Sell, or Troll?},
journal = {Commun. ACM},
issue_date = {January 2007},
volume = {50},
number = {1},
month = jan,
year = {2007},
issn = {0001-0782},
pages = {36--44},
numpages = {9},
url = {https://doi.org/10.1145/1188913.1188915},
doi = {10.1145/1188913.1188915},
acmid = {1188915},
publisher = {ACM},
address = {New York, NY, USA},
}

When parsing a BibTeX item, only the standard BibTeX fields (those listed in the FIELD_MAP Map) are preserved. This loses useful information such as the DOI, ISSN and URL.

Would it be possible to either add an option to include non-standard fields in the mapping or allow the FIELD_MAP to be extended as a parse option?

url and doi are both mentioned in the verbatimProperties array so are already parsed correctly, but are then dropped during the field mapping.

Code

const {
    parse
} = require('astrocite-bibtex');

const data = `@article{Verkhratsky2019Evolution,
	journal = {Advances in experimental medicine and biology},
        doi = {10.1007/978-981-13-9913-8_2},
        url = {https://link.springer.com/chapter/10.1007%2F978-981-13-9913-8_2},
	issn = {0065-2598},
	pmid = {31583583},
	address = {United States},
	title = {Evolution of Neuroglia},
	volume = {1175},
	author = {Verkhratsky, Alexei and Ho, Margaret S and Parpura, Vladimir},
	pages = {15--44},
	date = {2019},
	year = {2019},
}`;

const item = parse(data);

console.log(item);

Expected behavior:

[
  {
    id: 'Verkhratsky2019Evolution',
    type: 'article',
    'container-title': 'Advances in experimental medicine and biology',
    'publisher-place': 'United States',
    title: 'Evolution of Neuroglia',
    volume: '1175',
    author: [ [Object], [Object], [Object] ],
    page: '15–44',
    issued: { 'date-parts': [Array] },
    URL: 'https://link.springer.com/chapter/10.1007%2F978-981-13-9913-8_2',
    DOI: '10.1007/978-981-13-9913-8_2',
    ISSN: '0065-2598',
    PMID: '31583583'
  }
]

Actual behavior:

[
  {
    id: 'Verkhratsky2019Evolution',
    type: 'article',
    'container-title': 'Advances in experimental medicine and biology',
    'publisher-place': 'United States',
    title: 'Evolution of Neuroglia',
    volume: '1175',
    author: [ [Object], [Object], [Object] ],
    page: '15–44',
    issued: { 'date-parts': [Array] }
  }
]```

If you're able to find documentation negating that, I'd be happy to look into adjusting the parser.

I found this in the RIS specification:

How to handle long fields

If the information following any one tag is more than 70 characters long, it is allowable (though not necessary) to insert a carriage return/line feed at the end of 70 characters, and continue on the next line.

Did this file get generated from some other application?

I'm testing with BibTeX files generated by https://lens.org but there are some other issues with abstracts (e.g. XML markup) in the files that suggest it's still a work-in-progress.

Feel free to close this if newlines in RIS fields aren't valid - it feels like that would be reasonable, as otherwise the contents of the text could accidentally start a new field.

I'm not 100% sure whether newlines are valid within RIS fields, and it's not too hard to run a filter to remove them before passing the data to astrocite if needed, but I ran into this issue and thought it might be something that should be handled by the parser.

Code

import { parse } from 'astrocite-ris'

const item = parse(`
TY  - JOUR
AB  - Brazilian Amazon forests contain a large stock of carbon that could be released into the atmosphere as a result of land use and cover change. To quantify the carbon stocks, Brazil has forest inventory plots from different sources, but they are unstandardized and not always available to the scientific community. Considering the Brazilian Amazon extension, the use of remote sensing, combined with forest inventory plots, is one of the best options to estimate forest aboveground biomass (AGB). Nevertheless, the combination of limited forest inventory data and different remote sensing products has resulted in significant differences in the spatial distribution of AGB estimates. This study evaluates the spatial coverage of AGB data (forest inventory plots, AGB maps and remote sensing products) in undisturbed forests in the Brazilian Amazon. Additionally, we analyze the interconnection between these data and AGB stakeholders producing the information. Specifically, we provide the first benchmark of the existing field plots in terms of their size, frequency, and spatial distribution.
We synthesized the coverage of forest inventory plots, AGB maps and airborne light detection and ranging (LiDAR) transects of the Brazilian Amazon. Although several extensive forest inventories have been implemented, these AGB data cover a small fraction of this region (e.g., central Amazon remains largely uncovered). Although the use of new technology such as airborne LiDAR cover a significant extension of AGB surveys, these data and forest plots represent only 1% of the entire forest area of the Brazilian Amazon.
Considering that several institutions involved in forest inventories of the Brazilian Amazon have different goals, protocols, and time frames for forest surveys, forest inventory data of the Brazilian Amazon remain unstandardized. Research funding agencies have a very important role in establishing a clear sharing policy to make data free and open as well as in harmonizing the collection procedure. Nevertheless, the use of old and new forest inventory plots combined with airborne LiDAR data and satellite images will likely reduce the uncertainty of the AGB distribution of the Brazilian Amazon.
AU  - Tejada, Graciela
AU  - Görgens, Eric Bastos
AU  - Espírito-Santo, Fernando Del Bon
AU  - Cantinho, Roberta Zecchini
AU  - Ometto, Jean Pierre
CY  - United Kingdom
DA  - 2019/09/03
DO  - 10.1186/s13021-019-0126-8
ID  - 035-899-051-865-265
IS  - 1
JF  - Carbon balance and management
KW  - Aboveground biomass
KW  - Amazon
KW  - Carbon
KW  - REDD+
KW  - Remote sensing
KW  - Tropical rain forest
PB  - BioMed Central
PY  - 2019
SN  - 17500680
SP  - 11
TI  - Evaluating spatial coverage of data on the aboveground biomass in undisturbed forests in the Brazilian Amazon.
UR  - https://lens.org/035-899-051-865-265
VL  - 14
ER  -
`)

Expected behavior:

A parsed item, with an abstract containing newlines.

Actual behavior:

SyntaxError: Expected "ER", "\n", "\r\n", or [A-Z0-9] but "t" found.

Actually I just noticed that only HtmlEditor uses the debounce, so maybe if you used Editor directly and called parse and serialize in your code that would solve the problem?

The value set for __defaultContentType is meant to be application/octet-stream.

Bumps @jats4r/dtds from 0.0.4 to 0.0.5. <details> <summary>Commits</summary>

• 189d89c 0.0.5
• 1ed0adf Remove the doctype from the catalog file
• See full diff in compare view </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>