CSL-JSON for /works

[Philipp Zumstein]

The ORCID API already supports CSL-JSON with the response content type application/vnd.citationstyles.csl+json for an individual work with a putcode, see https://pub.orcid.org/v2.0/#!/Public_API_v2.0/viewWork . However, the same response content type is not supported for the list of all works https://pub.orcid.org/v2.0/#!/Public_API_v2.0/viewWorks . Can CSL-JSON been added there as well?

Thank you and best regards,

Philipp

[r.bla...@orcid.org]

Hi Philip,

We are not likely to add support for further JSON additions as it is unsustainable for us to maintain. We do however have a conversion utility here:  https://github.com/ORCID/orcid-conversion-lib. Would that help you out all?

Regards

Rob Blackburn

[Philipp Zumstein]

Hi Rob,

thank you for the answer. However, I cannot completely follow your strategy here: You are supporting CSL-JSON for one call "GET /v2.0/{orcid}/work/{putCode}" but not for another call "GET /v2.0/{orcid}/works". I would imagine that supporting the second call is easy, if you already are supporting the first one, and will not change much in your maintaing work. (Just do the same as you would do for the first one and put the result in a list.) Or do you have plans to get rid of CSL-JSON completely?

Sure, there can also be conversion afterwards, like with the utility you linked and which is great that you provide that. However, does this mean, that you want to support natively in the API only your own format(s)? I would see here some advantages if you also support one or several well-known and used metadata formats. This makes it much easier to connect with other tools and especially might prevent to write mappings all over again and again.

Hope it is okay to rant a little here. Let me know whether there are other points which I don't see here, or if I am maybe wrong about some things.

Best regards,

Philipp

--
You received this message because you are subscribed to the Google Groups "ORCID API Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to orcid-api-use...@googlegroups.com.
To post to this group, send email to orcid-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/orcid-api-users.
For more options, visit https://groups.google.com/d/optout.

[Demeranville, Tom]

Hi Philipp,

I'm sorry to say that we don't return lists of works that include co-authors for performance reasons.

We struggled in the past with hyperauthor metadata hammering our servers.  Some physicists for example can have 100s of work metadata entries, each with 1000s of authors.   This information would be in the metadata and also the attached citation, making it twice as large again.  Eventually we had to remove the author lists from the the work-summary elements when returning the list or risk timing out responses.  As you know, CSL requires this author list, so returning it from the summary endpoint is not possible.

For info, our existing CSL content type processing does two things.  First it looks at the Bibtex (if present) and parses that into CSL.  If that's not available, it makes a sparser version as best it can from ORCID work metadata.  Originally, it was envisaged that the CSL content type would attempt to retrieve the authoritative CSL content type from the DOI providers if the work contained a DOI.  This is because ORCID work metadata does not contain all the fields required to make a complete citation (for example, we don't have page numbers).  However, we found that this had a negative impact on response times, so we decided against resolving CSL metadata from DOI providers.  

If you want the absolute best quality data for your import, the best idea is to fetch the summaries, and for each work check for a DOI.  If there's a DOI then resolve the CSL metadata from the DOI provider (the "application/vnd.citationstyles.csl+json" content type is supported  at http://data.crossref.org/ and http://data.datacite.org/), otherwise resolve the metadata from us.  This is what the orcid-js library does to build reference lists.

I hope that explains things a bit,

Tom Demeranville

Technology Advocate

ORCID Inc

https://orcid.org/0000-0003-0902-4386

[Philipp Zumstein]

Hi Tom,

thank you for your explaniation. I can understand that the number of authors could become a problem with huge collaboration, as you describe it. As you might already have seen, I changed the application such that after the /works endpoint also for interested individual publication the /work endpoint with CSL-JSON is asked. That seems to work fine.

Thank you for the other informaiton as well, this is interesting to know.

Best regards,

Philipp