Skip to content
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

Automatic choice of identifier can cause an librarything ID to overwrite an ISNI ID #7072

Closed
onnotasler opened this issue Oct 11, 2022 · 2 comments · Fixed by #7182
Closed
Labels
Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] Needs: Triage This issue needs triage. The team needs to decide who should own it, what to do, by when. [managed] Type: Bug Something isn't working. [managed]

Comments

@onnotasler
Copy link
Collaborator

If one edits an author, one can choose between several identifiers. ISNI and Wikidata are automatically selected, when the appropriate data is put into the form.

Sometimes, librarything identifiers are falsely detected as ISNI identifiers. In those cases, one has to select the identifier after putting the data in, otherwise an existing ISNI will be overwritten.

Evidence / Screenshot (if possible)

Screenshot_20221011_161601

Relevant url?

https://openlibrary.org/authors/OL7504499A/

Steps to Reproduce

  1. I added identifiers to author Diandra Linnemann (it also happened with other author's).
  2. After I selected the identifier librarything and put the data in, the selection switched to ISNI.

(This also happens with other author's, and it might also happen with certain VIAF IDs. - so far, I can only recall cases where it was caused by librarything.)

  • Actual: The librarything identifier is saved as ISNI.
  • Expected: The librarything identifier is saved as as librarything identifier.

Details

  • Logged in (Y/N)?
    Y

  • Browser type/version?
    Firefox 104.0.2

  • Operating system?
    Suse Tumbleweed

  • Environment (prod/dev/local)? prod
    prod

Proposal & Constraints

As far as I am aware, ISNI always starts with a number whereas librarything always starts with a letter. Perhaps this difference can be used to tell both apart. An other option would be to deactivate the automatic selection completely.

Related files

#6423
#853
#856
#2744

Stakeholders

@onnotasler onnotasler added Needs: Lead Needs: Triage This issue needs triage. The team needs to decide who should own it, what to do, by when. [managed] Type: Bug Something isn't working. [managed] labels Oct 11, 2022
@mekarpeles mekarpeles added Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] and removed Needs: Lead labels Nov 14, 2022
@davidscotson
Copy link
Collaborator

I noticed a similar bug while fixing some wikidata ids that didn't look like wikidata ids.

Anne Frank, OL446842A, had a wikidata id that looked like an Amazon ID: B000AQ51EY

When fixing this manually, I noticed that if you select Amazon ID from the menu, then paste in that Amazon ID, the identifier type gets switched to Wikidata automatically (presumably due to the Q followed by numbers in the middle of the Amazon ID), which is probably how the mistake happened in the first place:

https://openlibrary.org/authors/OL446842A/Anne_Frank?_compare=Compare&b=14&a=13&m=diff

@davidscotson
Copy link
Collaborator

Code seems to be here:

selectIdentifierByInputValue: function() {

So tightening the regex for wikidata to match only if the Q is only preceded by whitespace characters and only followed by numbers then whitespace could help.

And the insi check could be changed to match 16 digits or 15 digits and an X, according to the wikidata regex matcher:

https://www.wikidata.org/wiki/Property:P213#P8966

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Lead: @cdrini Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed] Needs: Triage This issue needs triage. The team needs to decide who should own it, what to do, by when. [managed] Type: Bug Something isn't working. [managed]
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants