Retrieve subjects and subject from journals and works

Dear all
is there a good way to retrieve subjects (set for journals) and subject (set for works)? I am aiming to set and submit subjects myself, but first I’d like to see an existing (kind of) taxonomy. Crossref does not follow a Dewey Classification or something similar, don’t they?
A query like api. crossref. org/ works?select=subject seems to retrieve an uncomplete picture.

best
Klaus

Hi Klaus,

We don’t actually accept subjects (or keywords) in the metadata that members supply while registering their DOIs.

The subjects that you see in the API were added basically as an experiment, based on the Scopus ASJC subject codes. They’re one of the few things in the API metadata records that’s added by Crossref directly, rather than coming from the publisher/member.

Those subjects are of limited use, because they only apply to journals which are indexed by Scopus. They tend to cause a lot of confusion as well, because they only pertain to the subject of the journal as a whole, which often doesn’t align well with the subject of a given article.

We are planning to remove them in a future update to the REST API, though I don’t have a timeframe for that change.

So, that’s all to say, you don’t need to worry about which subjects to put in your metadata deposits, because our schema doesn’t allow for that.

Best,
Shayn

1 Like

Dear @Shayn
Thank you very much for the clarification. Once the <subject> is removed it will certainly be removed from the documentation, too, as this drew my attention to the issue.
At Crossref, could you please find out if it is a bug that empty/NULL <subject> fields are filled with “Pharmacology” or to just timely remove them form all our records: /journals/1424-3636.
All the best
Klaus

Hi Klaus,

Yes, the documentation will be updated when the subjects are removed.

That ‘Pharmacology’ subject value for “MedienPädagogik: Zeitschrift für Theorie und Praxis der Medienbildung” looks like a bug that pertains just to your journal.

Works from other journals, which aren’t indexed in Scopus, simply don’t have ‘subject’ fields at all. That would be the expected behavior.

I’ll report the bug to our technical team, so they can both verify that the misplaced subject only pertains to the one journal and see what’s involved in reindexing to correct it.

Thanks for bringing this to our attention.

-Shayn

Dear @Shayn
thanks for the update. The problem or bug relates to all submissions within our prefix ‘10.21240’
Best
Klaus

Thanks, Klaus.

I’ve summarized the issue for our technical team here

If you want to leave a comment or any additional details on that ticket, you can do so by creating a free gitlab account and logging in.

1 Like

Dear @Shayn
yesterday, the issue on Gitlab was closed. As I understood, it was learned that there is some error in Crossref’s data architecture. But the actual false data was or could not be corrected.
How do we proceed? I hope that you understand that this solution is by far not satisfactory for me.
All the best
Klaus

Hi Klaus.

Yes, as Dominika mentioned in her comment, removing or correcting subject data turns out to be much more complicated than it sounds, due to the way the subjects are populated from Scopus into our indices.

Essentially, at some point in the past Scopus must have made some kind of error and added those journals into their database with the incorrect subject codes, so we indexed them incorrectly at that point. Scopus has since corrected that error and removed those journals. But, due to the way that the REST API’s indexing process was originally designed, we don’t have a way to remove them without completely rebuilding a significant part of its architecture. And that’s unfortunately going to take awhile.

The ticket was closed because it was redefined as a research and documentation task. They’ll be documenting this problem on a list of known issues and then opening up a new ticket for the work required to actually address it. We’re in the process of moving our project management platform from Github to JIRA, so when the new ticket is opened up in JIRA, I’ll reply here with that link.

I’m sorry I don’t have a more satisfying or thorough resolution for you at this point.

2 Likes

Dear @Shayn
thanks for your reply and for the useful clarification.
I feel it is good to be part of this process. I also feel that the public use of the <subject> field should be a matter of common rethinking. If we would agree to use, let’s say SCOPUS’ classification of subjects, then we could all enrich our data - also for public use. That way also non-SCOPUS listed members could deliver in the same logic. Additionally, DOAJ and others do not use much of the subject level data (no Dewey classification or anything). OpenAlex on the other hand, meanwhile introduced <concepts>, which is more equvalent to keywords.
I would suggest to spark a discussion on how CrossRef and their members could systematically contribute to that: some way between subjects and keywords.
All the best
Klaus

1 Like

I’m reviving this problem because it was never corrected and is completely wrong - even for content that is created for the first time under a new prefix this week. We’ve started a new journal in cryptography and so far we have assigned precisely one DOI to the journal itself in the last week. It already has “subjects” that are completely bogus. The data can be seen at this url but our journal has nothing to do with medicine or environmental science. I understand your hesitation to accept subject (topic) data from publishers, because they can use it to spam your index. On the other hand, it’s really bad to assign wrong subjects and not allow publishers the ability to suppress it. It appears to have no value whatsoever, so you should probably suppress it in the output.

1 Like

We agree that the current implementation is problematic and needs to change, and we’re actively working on deprecating subject code assignment. Please stay tuned for an announcement in the next few weeks.

1 Like