Crossref DOI not loading in Zotero

Metadata Retrieval Interfaces for Machines
1

10.1045/may2016-peng is a CrossRef DOI (looking at /10.1045 at hdl dot handle dot net) that returns reasonable-looking responses using content negotiation (citation dot crosscite dot org /docs.html), and yet doesn’t load in Zotero. Context: fairpoints dot social/@donny/109670371550201335

Any idea what’s going wrong?

2

(sorry for lack of clickable links — it seems I can’t post links (?))

3

Hi.

10.1045/may2016-peng is indexed in our APIs, and therefore accessible via content negotiation

You can see it’s metadata record in the REST API here
https://0-api-crossref-org.libus.csd.mu.edu/works/10.1045/may2016-peng

And, I just queried it via content negotiation and got back a formatted citation successfully

Peng, G., Ritchey, N. A., Casey, K. S., Kearns, E. J., Prevette, J. L., Saunders, D., Jones, P., Maycock, T., & Ansari, S. (2016). Scientific Stewardship in the Open Data and Big Data Era — Roles and Responsibilities of Stewards and Other Major Product Stakeholders. In D-Lib Magazine (Vol. 22, Issue 5/6). CNRI Acct. \https://0-doi-org.libus.csd.mu.edu/10.1045/may2016-peng

(I added the \ before the DOI in the citation to prevent it from being automatically previewed and linked)

So, from what I can tell, there’s nothing particular about that item that would prevent it from being imported to Zotero. That suggests a problem on Zotero’s end. Have you tried contacting their support team?

-Shayn

4

That suggests a problem on Zotero’s end. Have you tried contacting their support team?

I have not. It seems likely that their team thought they had successfully implemented DOI lookup for major DOI providers such as Crossref, so this could indicate a gap in Crossref API documentation legibility?

5

I posted to forums dot zotero dot org/discussions but new-member posts are moderated so I can’t provide a link here yet.

6

Hi from the Zotero end – Zotero’s XML parser (on the Unixref XML we’re using) fails because of a very odd (and I think improperly rendered) UTF character (\u0097) that’s in that item’s title. You can see that also in the JSON from the API you posted.

I don’t think that should be there, at least not in that form?

1 Like
7

Thanks for letting us know!

Our xml schema will support any utf-8 characters, so it parsed alright on our end when the publisher submitted the metadata for that item to us. But, you’re right, it probably shouldn’t be there. It was likely a mistake introduced in their typesetting process or another part of their publishing production. I can’t imagine that a “end of guarded area” character should be in the title intentionally.

We can’t update or correct the publisher’s metadata directly, but I can reach out to our contacts at that publisher and ask them to make that correction.

1 Like
8

Thanks Shayn. To close the loop, this issue is not fixed in Zotero and the DOI metadata imports fine.
The issue was that we’re trying to convert several weirdly escaped unicode characters that we occasionally see in publishers’ data at CrossRef back to unicode and that throws an error in this case. We’re now simply stripping characters we can’t properly convert (you can find more details on the Zotero forums & github, but no links allowed for me…)

It would still be good for the publisher to address the issue here (though I know dlib magazine is no longer published :frowning: ): as you can see on the sample citation provided by content negotiation, it’s missing the subtitle delimiter, an em dash between “Era” and “Roles”, that somehow between typeset and metadata submission got turned into the end of guarded area character (which looks the same, FWIW).

1 Like