My citation from ORCID is not being processed

[MartinKjunior]

Checks

• I have searched the docs, existing issues, and existing discussions for answers first.

Link to your website repo

https://github.com/MartinKjunior/nimo-website

Version of Lab Website Template you are using

1.3.5

Description

The following profile is not having its only citations processed, can't figure out why: https://orcid.org/my-orcid?orcid=0000-0002-6246-8288 . I'm running Jekyll via Docker (all installed today, default latest versions).
Output:

      Regenerating: 1 file(s) changed at 2025-06-24 14:31:05
                    _data/orcid.yaml


--------------------

Compiling sources
Running google-scholar plugin
    Found 0 google-scholar* data file(s)
Running pubmed plugin
    Found 0 pubmed* data file(s)
Running orcid plugin
    Found 1 orcid* data file(s)
    Processing data file orcid.yaml
Processing entry 1 of 1, orcid: 0000-0002-6246-8288 (from cache)
id: source-work-id:61c2899f-aacd-4c19-82aa-710a1f9c141d
            1 source(s)
Running sources plugin
    Found 1 sources* data file(s)
    Processing data file sources.yaml
Processing entry 1 of 3, id: doi:10.1371/journal.pcbi.1007128
Processing entry 2 of 3, id: doi:10.1016/j.csbj.2020.05.017
Processing entry 3 of 3, id: doi:10.7554/eLife.32822
Merging sources by id
4 total source(s) to cite

--------------------

Generating citations
Processing source 1 of 4, id: source-work-id:61c2899f-aacd-4c19-82aa-710a1f9c141d
    Using Manubot to generate citation## WARNING
Generating csl_item for 'source-work-id:61c2899f-aacd-4c19-82aa-710a1f9c141d' failed due to a NotImplementedError:
Manubot does not know how to generate a csl_item for 'source-work-id:61c2899f-aacd-4c19-82aa-710a1f9c141d'

            ⚠️ WARNING: Couldn't parse Manubot response
Processing source 2 of 4, id: doi:10.1371/journal.pcbi.1007128
    Using Manubot to generate citation (from cache)
Processing source 3 of 4, id: doi:10.1016/j.csbj.2020.05.017
    Using Manubot to generate citation (from cache)
Processing source 4 of 4, id: doi:10.7554/eLife.32822
    Using Manubot to generate citation (from cache)

--------------------

Saving updated citations

--------------------

⚠️ WARNING: 1 warning(s) occurred above
    ⚠️ WARNING: Manubot could not generate citation for source source-work-id:61c2899f-aacd-4c19-82aa-710a1f9c141d (from orcid.yaml with orcid.py)
All done!

--------------------
       Jekyll Feed: Generating feed for posts
                    ...done in 8.270522718 seconds.

      Regenerating: 3 file(s) changed at 2025-06-24 14:31:14
                    _cite/.cache/cache.db
                    _cite/plugins/__pycache__/orcid.cpython-39.pyc
                    _data/citations.yaml
       Jekyll Feed: Generating feed for posts
                    ...done in 4.801139729 seconds.

orcid.yaml

- orcid: 0000-0002-6246-8288 # Martin Kozar

[cgreene]

Adding a cross-reference to the corresponding Manubot issue: manubot/manubot#377

[vincerubinetti]

So to clarify some things first: The template uses Manubot to fill in full citation details from just an id. In this case, the template is asking Manubot to cite the id source-work-id:61c2899f-aacd-4c19-82aa-710a1f9c141d, which it doesn't know how to. Manubot expects to see something like doi:abc/123 or arxiv:123456. Before Manubot though, the template's orcid.py tries to get a list of source (paper) IDs from ORCID.

The tricky part is, ORCID returns lots of fields that could theoretically be used as the "primary" ID to cite in different cases, and ORCID's documentation makes it difficult to know what the intended purposes or expected behaviors of these fields are. This was discussed and investigated at length in #258, which I'm still re-reading.

You commented in the cross-referenced Manubot issue above:

on ORCID, the references that return source-work-id:... are the ones added in by the researcher themselves.

Are you saying that source-work-id:61c2899f-aacd-4c19-82aa-710a1f9c141d is something you manually added to that work, perhaps for your own record keeping purposes? I think we ultimately decided in #258 that if the user manually specifies an ID of some sort in their ORCID source, that should be what the template considers as the "primary" ID to cite.

So if that's the case, I think this would be considered "expected behavior", and you'd want to remove that manual source-work-id, and it should fall back to the DOI.

Otherwise, we can try to revisit the exact ID selection behavior in orcid.py. But I worry that this is a sort of "whack-a-mole" issue, where fixing it for you might cause it to break for someone else. Or more precisely, one user's expected behavior might be another's unexpected behavior.

[MartinKjunior]

I have originally added the citation in myself as I was too late to respond to my supervisor's emails when she was publishing the paper, so I wasn't cited on ORCID in when the paper was published. There were "2 sources" for the citation on ORCID and I removed what looked to be generated by me. That has not fixed this issue. I would like to think that if DOI exists as one of the options, then it should be the default fall-back when everything else fails. I don't know whether Manubot receives all 3 (source..., eid, doi) ids or not. If it does then Manubot could handle that, otherwise it would be useful if orcid.py went through all options and picked the one that works.

[vincerubinetti]

I would like to think that if DOI exists as one of the options, then it should be the default fall-back when everything else fails.

To emphasize:

one user's expected behavior might be another's unexpected behavior.

If the source-work-id is something the ORCID user has carefully set manually, they probably want to know (with a critical error) when it's not working rather than silently falling back to something else (buried in long gh-actions workflow logs that no one reads when successful). This would be consistent with how the template's cite process throws a critical error when one of the source id's you've manually put in sources.yaml can't be cited for some reason.

But, the "if" in the previous paragraph is still a big "if". I'm going to try experimenting with my own ORCID, adding manual ids, to see if I can personally verify where the field comes from.

[GuillaumeBroggi]

To add to this issue, I am facing something similar with publications added to my profile by my university's research portal.

In that case, the first ID returned with the ORCID request is the ID generated by the aforementioned research portal, e.g.:

{'external-id': [{'external-id-type': 'source-work-id',
    'external-id-value': 'efdf6e68-c69b-499a-bc3b-33be5bc322bf',
    'external-id-normalized': {'value': 'efdf6e68-c69b-499a-bc3b-33be5bc322bf',
     'transient': True},
    'external-id-normalized-error': None,
    'external-id-url': None,
    'external-id-relationship': 'self'},
   {'external-id-type': 'eid',
    'external-id-value': '2-s2.0-85213700240',
    'external-id-normalized': {'value': '2-s2.0-85213700240',
     'transient': True},
    'external-id-normalized-error': None,
    'external-id-url': None,
    'external-id-relationship': 'self'},
   {'external-id-type': 'doi',
    'external-id-value': '10.1002/pc.29448',
    'external-id-normalized': {'value': '10.1002/pc.29448', 'transient': True},
    'external-id-normalized-error': None,
    'external-id-url': None,
    'external-id-relationship': 'self'}]}

This ID is not recognized by Manubot (as expected), and I prefer not to edit manually each entry of my ORCID. Thus, I edited orcid.py to prioritize DOI.

[vincerubinetti]

@GuillaumeBroggi Thank you for sharing. Would you mind sharing your modifications to orcid.py? I'm curious what you chose to do, and I think the exact logic matters a lot here since it will be used by many people under a wide variety of circumstances.

@andrewsu Since you and I discussed much of the same things in #258, do you have any vote on what the exact logic should be here?

I plan to dedicate time this week to this issue.

[GuillaumeBroggi]

I defined a pick_best_id function as follows (there is probably a more elegant solution):

def pick_best_id(ids):
    """
    pick the best id from a list of ids returned by the orcid api
    - prefer doi ids
    - prefer ids with a "self", "version-of", or "part-of" relationship
    - return first id if no other ids match
    - if no ids, return None
    """
    for id in ids:
        if get_safe(id, "external-id-type", "") == "doi":
            return id
    for id in ids:
        if get_safe(id, "external-id-relationship", "") in (
            "self",
            "version-of",
            "part-of",
        ):
            return id
    return ids[0] if ids else None

It looks first for a DOI, then reverts to the default behavior if no DOI is provided. Maybe a more robust approach could check identifiers according to an (ordered) list defined in the config.

[vincerubinetti]

I have an updated version of the script that I think will work for a broader set of use cases and be more flexible for those with different needs. See #330

@MartinKjunior, running it on your ORCID, the first source, instead of throwing an error, returns doi:10.1038/s41598-022-23826-1, which I think is what you are desiring.

@GuillaumeBroggi, running it on your ORCID returns doi:10.1016/j.compositesa.2024.108529 isbn:978-2-912985-01-9 doi:10.1002/pc.28171 doi:10.1016/j.compositesa.2023.107520 ........., which includes isbn: type IDs, but see the commented out lines in #330 where you could easily reject any ID that isn't a DOI.

@andrewsu, running it on your ORCID, the Design and application of a knowledge network for automatic prioritization of drug mechanisms paper you talk about in #258 still returns the preferred doi:10.1093/bioinformatics/btac205 source. However, if you were to select an ID type that Manubot can't cite as the preferred source, instead of failing critically (which you may want to know about) or using the citation details directly from ORCID instead of Manubot, it will continue down the list of IDs until it finds one that Manubot can cite. This may or may not be the desired behavior.

@cgreene, testing it on your ORCID in greenelab/greenelab.com#158 yields very little change, considering how many papers you have. It just adds a few.

Given all these test cases, I'm feeling pretty good about these changes.

[GuillaumeBroggi]

@vincerubinetti Thanks for the update. I just deployed it to our website, and noticed the issue described in #332:

get_safe always returns an empty string, even if _id is None after filtering. Consequently, a filtered-out citation will be processed as not citable by manubot, given the current logic, and result in an entry in citations.yaml. This behavior seems wrong.