Some entity ids are NOT unique

[samuelbeck]

Some entity ids returned by the REST API are not unique. Querying the /api/entities/{entity_id} endpoint returns different results in (at least) the following case:

https://intavia.acdh-dev.oeaw.ac.at/entities/aHR0cDovL3d3dy5pbnRhdmlhLmV1L3Byb3ZpZGVkX3BlcnNvbi8zNzU3

Should return Gustav Klimt but sometimes returns Ales Mikulas (both have the following URI: http://www.intavia.eu/provided_person/3757)

[yoge1]

Hmm, quickly looking at the data in the SPARQL endpoint, I see the URI http://www.intavia.eu/provided_person/3757 only being used for Ales Mikulas, not for Gustav Klimt. Klimt's URI is http://www.intavia.eu/provided_person/30123.

Also, by making the query https://intavia.acdh-dev.oeaw.ac.at/entities/aHR0cDovL3d3dy5pbnRhdmlhLmV1L3Byb3ZpZGVkX3BlcnNvbi8zNzU3, I see it returning only Ales Mikulas (I ran it couple of times).

Are you able to reproduce the bug via a certain use sequence?

What I do know is that if we ingest new versions of source datasets and then run the Prefect flow generating Provided_Person instances, the URIs of the persons can change from the previous state of the knowledge graph (issue: https://github.com/InTaVia/prefect-flows/issues/22). So if this would be the case, then the same URI could be used for Klimt and Mikulas, but not in the same knowledge graph state.

[samuelbeck]

I'm able to reproduce the bug in the following way:

1. Search for Gustav Klimt in the frontend (https://intavia.acdh-dev.oeaw.ac.at/search?q=gustav+klimt)
2. Click on Gustav Klimt to open the detail page -> Gustav Klimt will be shown
3. Delete local storage of the application (tutorial)
4. Reload detail page of Gustav Klimt (https://intavia.acdh-dev.oeaw.ac.at/entities/aHR0cDovL3d3dy5pbnRhdmlhLmV1L3Byb3ZpZGVkX3BlcnNvbi8zNzU3) -> Mikulas Ales will be shown

Maybe either the entity search or entityById endpoint is returning out-of-date data?

[yoge1]

Thanks. I don't have any new insight to offer here, but will report my findings:

• Yesterday, I was able to reproduce the bug by following your sequence, even without deleting local storage (step 3), but didn't have time to further investigate. In Chrome's Incognito mode I couldn't reproduce the bug.

• Now when I followed your sequence, in step 4 I see Gustav Klimt, as it should be, and thus cannot reproduce the bug anymore. Gustav Klimt's detail page URL is (currently) https://intavia.acdh-dev.oeaw.ac.at/entities/aHR0cDovL3d3dy5pbnRhdmlhLmV1L3Byb3ZpZGVkX3BlcnNvbi8zMDEyMw%3D%3D (vs. in your sequence / yesterday it was https://intavia.acdh-dev.oeaw.ac.at/entities/aHR0cDovL3d3dy5pbnRhdmlhLmV1L3Byb3ZpZGVkX3BlcnNvbi8zNzU3). So it seems some endpoint/component might have had out-of-date data.

Is it possible that our browsers' local storage had Gustav Klimt's older ID (if such ID's are stored in local storage)?

[samuelbeck]

Thanks for looking into this! Yes, entities and their IDs are stored in local storage, so that's a possibility.

[yoge1]

Ok, then I think is indeed caused by a new run of the Prefect flow that generates the Provided_Person instances, which doesn't generate persistent identifiers (issue: https://github.com/InTaVia/prefect-flows/issues/22).