Closed mietcls closed 1 year ago
Putting the old information here, as context:
Person conflict; have two different people been merged?
There are two profiles in use in the Biblio front-office:
These people seem to be merged:
Which is now this person: https://biblio.ugent.be/person/FB24F05A-F0ED-11E1-A9DE-61C894A0A6B4
– But is seems there are two "Bart Claessens": one in RE03 and WE12 (based on their records)
In GISMO we can find two people, one that is probably WE12 (not visible) and one that is RE03 (visible)
It's possible that we added too many IDs to one of those "Bart Claessens". There are 4 Bart Claessens available in our Biblio back-end. We think one of those IDs is supposed to be added to an other profile:
Is this possible?
From our colleagues at GISMO
Echter komen we nu een geval tegen waarbij we onze twijfels hebben, nl Bart Claessens 802000277595 en 801001000369. Als we kijken naar de persoonlijke gegevens van deze 2 personen dan zien we dat zowel geboorteplaats als geboortedatum verschillend zijn… We denken dus dat het hier wel degelijk om 2 verschillende personen gaat, met dezelfde naam weliswaar… Kan het zijn dat jullie deze verkeerdelijk hebben samengevoegd? Of hadden jullie mss meer info? En is het eventueel mogelijk om dit dan terug ongedaan te maken? Zodat wij weten aan wie wij welke publicaties moeten hangen?
Is this more clear now?
@mietcls changed in database
Thank you, communicated
GISMO mention they still see the wrong information for https://biblio.ugent.be/publication/122693 – and ID 801001000369 still appears for this record. Should we reindex or should GISMO still do something? Figuring it out.
Information they get back:
<ns2:name authority="ugent" type="personal">
<ns2:namePart type="given">Bart</ns2:namePart>
<ns2:namePart type="family">Claessens</ns2:namePart>
<ns2:displayForm>Bart Claessens</ns2:displayForm>
<ns2:role>
<ns2:roleTerm authority="marcrelator"
authorityURI=http://id.loc.gov/vocabulary/relatorstype="code">aut</ns2:roleTerm>
<ns2:roleTerm lang="eng" type="text">author</ns2:roleTerm>
</ns2:role>
<ns2:nameIdentifier type="ugent">802000277595</ns2:nameIdentifier>
<ns2:nameIdentifier type="ugent">059714421792</ns2:nameIdentifier>
<ns2:nameIdentifier type="ugent">002001295714</ns2:nameIdentifier>
<ns2:nameIdentifier type="ugent">801001000369</ns2:nameIdentifier>
<ns2:nameIdentifier type="ugent">919020665044</ns2:nameIdentifier>
<ns2:affiliation>WE12</ns2:affiliation>
</ns2:name>
Can records affiliated to the other Bart Claessens (Affiliation: WE12, IDs: 000100162297 + 801001000369) be updated as well? It's not flowing through just yet.
e.g. the new ID added to this Bart (801001000369), is not shown yet here: https://biblio.ugent.be/oai?verb=GetRecord&identifier=365774&metadataPrefix=mods_36
<name type="personal" authority="ugent">
<namePart type="given">Bart</namePart>
<namePart type="family">Claessens</namePart>
<displayForm>Bart Claessens</displayForm>
<role>
<roleTerm authority="marcrelator" authorityURI="http://id.loc.gov/vocabulary/relators" type="code">aut</roleTerm>
<roleTerm type="text" lang="eng">author</roleTerm>
</role>
<nameIdentifier type="ugent">000100162297</nameIdentifier>
<affiliation>UGent</affiliation>
</name>
@miet this pr will fix that https://github.com/ugent-library/biblio-backoffice/pull/1040 the other person had only 2 publications, so I updated these manually
Do we need to reindex or is it okay for GISMO and other places too? Thanks!
Bug / Question
Person conflict; ID has been added to the wrong person.
Fix
Move ID
801001000369
from Bart Claessens with personnel number802000277595
to Bart Claessens with personnel number801001000369
.The rest will be taken care of by the Biblio review team. Assign Miet when you are done please.
Context
There are two "Bart Claessens", one in RE03 and WE12:
These two profiles display the same information in the Biblio front-office:
Current IDs:
One Bart Claessens has too many IDs:
Bart Claessens
wrong
Bart Claessens
Desired situation
Bart Claessens
Question: should be RE03 – can we fix this or is this a GISMO issue?
Bart Claessens
needs to be moved here
Analysis by reviewer: