ISSN journal resource not found

Metadata Retrieval
, ,
4

Hi @Dave ,

Thanks for your questions/observations. See my responses below.

  1. The /works?filter=issn:{issn} is a filter on works, so it will give an overview of publications in that journal and does not contain the same metadata as /journals/{issn}. Therefore it is not an viable alternative for /journals/{issn}.

That may be so, but you can request the works on the journal route, the results are identical, so this:

https://api.crossref.org/works?filter=issn:15565068 and this: https://api.crossref.org/journals/1556-5068/works do provide the same results

  1. Applying /journals/1556-5068 in the API, the resulting dois-by-issued-year may not be entirely accurate as to my surprise they contain future years i.e. 2024, 2077, 2103 and 2104.

Yes, that’s true. Ahead of print articles do often have a publication date in the future, so I assume many of the 2024 dates are accurate, but 2077, 2103, and 2104 are typos in the metadata registered by SSRN. All DOI metadata is provided to us by our publisher members. Crossref does not update, edit, or correct publisher-provided metadata directly. Thus, SSRN would need to correct any potential problems in the metadata records.

  1. The number of dois is about 50% of what SSRN claims on their website https://www.ssrn.com/ i.e. 1,236,509 research papers. So either a vast number of articles is not in CrossRef yet, or are not counted because they may not have a DOI.

We do require that members register all content from the time of joining going forward, but it is not required that our members register legacy content that was published prior to joining Crossref. We do incentivize registration of legacy/back content (we offer an 85% discount on those back content registrations), but not all members elect to register all legacy/back content.

  1. The results from https://api.crossref.org/works?facet=issn:*&rows=0 will list the journals ISSNs as https://id.crossref.org/issn/1556-5068 . The Status code of these https requests is 503 (Service unavailable).

Thanks for flagging this! We’re working on it. Joe Wass on our technical team provided specifics on this over in this community forum post. I’m copying that message below so it is in this thread as well.

Firstly, this is something we’re well aware of, and working to improve (though I can’t give an ETA). You’re not the first to notice this. Second, although we are working on an improvement, technically it should not be a problem.

Our id.crossref.org URIs were used to allow us to use RDF URI references as identifiers for all items, allowing us to expose data in RDF format, enabling Content Negotiation on our metadata. RDF does not require that a URIs actually resolves as URLs, simply that they exist. We use these identifiers for items we have no API for, but still want to identify (such as ISSN or author names).

We do not run any APIs or services on that domain, it’s just a placeholder. The HTTP 503 literally means “there’s no service here!”.

(Note that id.crossref.org URIs are not blank nodes, as they are referenced in multiple RDF documents.)

So, whilst the behaviour technically correct, it is a little confusing. I’ll be sure to update this ticket when we have something to share.

Joe
Crossref

Our best,
Isaac

1 Like