-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crossref deposits fail when surname is missing #7528
Comments
Oh, I should note too that is supported in the schema version we're using 4.3.6. Once Crossref will be adding ROR to their schema in early 2022 (I think), we should probably consider just fully updating the schema we write to in our exports to accommodate. |
I've flagged this as a bug and assigned it to the 3.3.0-9 milestone for the problems with the surname field. The preferred name feature should be split to a new issue and only implemented for a future version. |
Just a note that we can't/won't do this. "Surnames" are a western thing and "Family Names" (the term we use) do not exist in all languages/cultures. |
I was going to tackle this today but I don't actually know what a solution would be. Given the following author record with no surname: {
"givenName": "Andrew"
} Would it be best for OJS to deposit the following: <person_name contributor_role="author" sequence="first" language="en">
<given_name>Andrew</given_name>
</person_name> Or -- and I know this is evil but it's Crossref's doing -- the following: <person_name contributor_role="author" sequence="first" language="en">
<given_name>Andrew</given_name>
<surname>-</surname>
</person_name> |
Right, so in the Crossref schema, they made the decision to support single-name deposits as well. But, they just went with the other name field.
This is facet valid and expected in the schema. I know it seems a little weird, but I suspect it's because of the expected placement of a person's name in like... citations. Surname is usually listed first, so that's likely the logic here. In any event the recommendtions is that if we just have a single given name, we write it to Crossref's schema in the surname field. |
Ok that makes sense, thanks. |
See also #6863 |
The Crossref schema has an "anonymous" element (as subelement of contributors) that should be used in such a case. |
Anonymous in the Crossref schema is for an anonymous author, not for situations where one of two name elements is missing. |
@AhemNason This is correct, but not the point. We simply can't deposit (or redeposit) articles that have no author in Crossref, because the anonymous element hasn't been implemented in the OJS CrossrefXMLExport plugin - which in my opinion is wrong. If you wish that I create a new issue for this, let me know. But I think placing a comment here was correct if one starts bug fixing for missing or semi-missing author names. For a large journal that we are currenly migrating over from another host to OJS, there are several (in the range of 100-400) articles that don't have an author, but were registered with Crossref and that we currently can't redeposit so that the DOI points to the OJS site. Whether it makes sense to register articles that don't have an author is not to be discussed here. The DOIs exist for these articles, and they should resolve again. |
@mpbraendle That's correct, but this ticket is about one missing name, not anonymous authors. I mentioned this in another ticket but please see: #5955 filed against the issue of anonymous and corporate names. |
In this case, Crossref's import validation is working as intended. If you were to redeposit these records with the XML generated by OJS, you would be replacing accurate metadata with inaccurate metadata. Until OJS supports anonymous authors, you may consider modifying the XML generated by OJS yourself. Or Crossref may be willing or able to update URLs for these DOIs directly, without requiring a full XML deposit. |
Hi @AhemNason and @NateWr. As Mike said above: "I know it seems a little weird, but I suspect it's [Crossref selecting surname as the default for contributors with a single name] because of the expected placement of a person's name in like... citations." That's exactly right. We're focused on that citation matching, and that's why we decided to use the |
So I came across this in OMP where I have my won Crossref plugin. @NateWr are you thinking of solving this by using the firstname in the
|
Yes, but we do not have a "first name". We have a "given name" and a "family name". If only a "given name" is provided, then we will put that into the only required field in Crossref. |
Here is a contributed pull request for this issue: pkp/crossref-ojs#11 |
@ewhanson can you do the code review on this PR? |
Currently: if family name in submission locale (the data are exported in) is missing, the author full name is exported in the element @AhemNason, the support for alt-name was added here: pkp/ojs@92b3e74. Thus, the author names in other languages are exported in |
I've just realized this Bug in the stable version: #8202. |
… if family name does not exist
PRs: |
@NateWr, could you review the PR? It uses the given name in the submission locale, if family name does not exist. getFullName would first consider the UI locale, which is not correct -- all metadata are exported/registered in the submission locale... |
… if family name does not exist
Looks good to me, @bozana. |
pkp/pkp-lib#7528 Crossref export: use given name in submission locale…
pkp/pkp-lib#7528 Crossref export: use given name in submission locale…
… if family name does not exist
pkp/pkp-lib#7528 Crossref export: use given name in submission locale…
… if family name does not exist
pkp/pkp-lib#7528 Crossref export: use given name in submission locale…
Describe the problem you would like to solve
There are three issues with Crossref deposits that require some reconfiguration of how we map name metadata to their schema.
<surname>
tag to the export XML, which will lead to a validation error on Crossref's end.<alt-name>
element.Describe the solution you'd like
Who is asking for this feature?
Crossref asked specifically about the surname requirement. The other two have come up on the hosting side a number of times.
The text was updated successfully, but these errors were encountered: