When article metadata is missing

[jvwong]

Background

Issue: No article metadata is associated with a Document

Consequences

• Fail to 'attribute' the authors and journal
• Data integration suffers when pathway data and exports omit article references
• Explore view paper metadata will be emptyish or worse, have,dead links (e.g. Google Scholar, PubMed)
  • Related papers system will be unable to sort articles based on participant queries (INDRA)
• Non starter for 'assistants' based upon automated reading etc...

Reasons for missing metadata

• A. Not in PubMed

  • Prepublication: The metadata exists, but is yet to be deposited by journal. Acceptance-to-publication lag ~4-6 weeks
  • Exclusion: PubMed does not index (e.g. preprints)
  • Nope: Spam

• B. In PubMed

  • Technical glitch: EUTILS service was down or errored when called by Factoid server
  • Clash: There was > 1 result when PubMed EUTILS service was queried (article title)
  • Related: PubMed metadata grows over time as curation occurs (e.g. MeSH headings, reference lists)

Obtaining article metadata

• Manual: Authors enter/edit
• Automated: Software retrieves/replaces existing data

Specification

Details

• Manual retrieval: This covers the (A) 'Prepublication' case

  • Idea is to format the available metadata information consistently (e.g. explore view, homepage gallery), and make it clear which fields are 'stubbed out'; then allow author to add or edit -- at very least journal name, maybe more
  • Where: Call to action; Editor; Submit

• Automated retrieval: This covers the (A) 'Prepublication' and (B) 'Technical glitch', 'Related'

  • Idea is to use existing service to fetch/refresh the metadata from PubMed based on the information provided by authors
  • Possible approaches
    • Cron job: Run the update periodically, optionally filtering some Documents (i.e. articles published a certain time ago)
    • other: Lazy load information when the Document is accessed (e.g. explorer, data export)

Mockup

//TODO

[maxkfranz]

Re. the manual case: The editor is probably a better fit than the CTA for the user entering these details. An author has only one opportunity to address that in the CTA, and it would be blocking -- introducing friction. I think it's better to just let them optionally edit a few details within the editor, if absolutely necessary.

It's better all around to just use the automated approach. If we're concerned about cases where the paper isn't yet in PubMed, it would probably be more effective and easier for users to just automatically pull in the information from Biorxiv if the information is not yet available in Pubmed.

This also relates to a redesign of the CTA, which was omitted from the home page tweaks PR. I think the CTA needs a bit more consideration. The old design is suited for a different flow. Now, the only important thing is that it's quick and simple, with as few necessary user actions as possible. So, for example, the CTA should just open up the editor URL in a new tab after the user clicks the first button (under the title and email text fields). There's no need for a second click.

[jvwong]

automatically pull in the information from Biorxiv if the information is not yet available in Pubmed.

Not sure how many people post to bioRXiv before a journal - maybe lots. bioRxiv doesn't have a web service, so you'd need to go to something like CrossRef, and then we're more or less getting into the search engine game, again.

CTA should just open up the editor URL in a new tab

Yeah that's a good idea now.

[maxkfranz]

If many preprint authors use Biorxiv, then using something like https://www.rxivist.org/docs would be useful.

Allowing for manually editing fields like title, author list, and journal at any time opens up a can of worms. To avoid some of the complications, it should only be allowed when a factoid has missing metadata -- and only before the factoid has been submitted. It should be optional, except in difficult cases like an ambiguous match. The user-entered metadata should also be stored separately from the automatic metadata, as user-entered metadata should only be used as temporary display values.

[jvwong]

Allowing for manually editing fields like title, author list, and journal at any time opens up a can of worms. To avoid some of the complications, it should only be allowed when a factoid has missing metadata -- and only before the factoid has been submitted. It should be optional, except in difficult cases like an ambiguous match. The user-entered metadata should also be stored separately from the automatic metadata, as user-entered metadata should only be used as temporary display values.

So I was thinking of letting the author add a 'journal' name. We stash the author input in Document.provided and use this information to query PubMed (doc.provided.paperId) and author communication (doc.provided.authorEmail). Having a journal would have two benefits, it would allows us to display it, and it would help constrain a PubMed retrieval.

[maxkfranz]

I was thinking along the same lines but with the author list as well. In either case, you need to do fuzzy matching. You can’t guarantee how the user will format the names. E.g.: Mol.Cell or Molecular Cell or Mole. Cell (maybe a typo or a non-official abbreviation) John Doe or J. Doe or Doe, J. Given the complexity (it’s grounding all over again) and the low likelihood of a missing Pubmed match in the long term, I think we should use the user-provided metadata only as temporary display values. Those display values get overridden (but not deleted) by refreshing the Pubmed matches periodically. The main thing is that the author names can be shown beside the title, even for preprint

…

On May 22, 2020, at 19:43, Jeffrey ***@***.***> wrote:  Allowing for manually editing fields like title, author list, and journal at any time opens up a can of worms. To avoid some of the complications, it should only be allowed when a factoid has missing metadata -- and only before the factoid has been submitted. It should be optional, except in difficult cases like an ambiguous match. The user-entered metadata should also be stored separately from the automatic metadata, as user-entered metadata should only be used as temporary display values. So I was thinking of letting the author add a 'journal' name. We stash the author input in Document.provided and use this information to query PubMed (doc.provided.paperId) and author communication (doc.provided.authorEmail). Having a journal would have two benefits, it would allows us to display it, and it would help constrain a PubMed retrieval. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jvwong]

I think the idea of adding the curator name falls under this broad issue.

[jvwong]

@maxkfranz what do you think - showing pre and during editing

[maxkfranz]

(1) Could we show the text box right away, removing the need for the pencil icon?

(2) Re. Orcid, users would probably expect some kind of feedback that the ID took. You'd need some kind of validation. We could start with just the name, and then we could support the Orcid ID in future.

[jvwong]

(1) Could we show the text box right away, removing the need for the pencil icon?

I think I was trying to avoid having a 'submit' button. If you have the text box, what's the best way to indicate it's stored?

(2) Re. Orcid, users would probably expect some kind of feedback that the ID took. You'd need some kind of validation. We could start with just the name, and then we could support the Orcid ID in future.

Sure.

[maxkfranz]

I think I was trying to avoid having a 'submit' button. If you have the text box, what's the best way to indicate it's stored?

We'd need to give the user feedback, like a message under the text box -- e.g.:

We've recorded John Doe as the contributor. Thanks!

In the case of an Orcid:

We've recorded the Orcid profile of John Doe as the contributor. Thanks!

(with a link to the Orcid profile page)