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

Possible idea for handling legacy sampleID<->determination #663

Open
kyule opened this issue Dec 12, 2024 · 0 comments
Open

Possible idea for handling legacy sampleID<->determination #663

kyule opened this issue Dec 12, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@kyule
Copy link
Member

kyule commented Dec 12, 2024

I could harvest them all and manually change just the occurrence relationship to something like "mayContain" "may originateFrom" or just "associatedWith" whatever makes the most sense for the problem samples and have the harvester only change relationships that were created by itself.

And then add relationships between the samples arising from the same parent (which I'd like to do anyways)
It doesn't solve the issue of duplicate records BUT it at least signals to the CMs that if someone is asking for a specific taxon you have to send both slides/vials to ensure they get it.

It would be a step in the right direction that I could implement without any major overhauls

And is forward compatible with when they start publishing the data correctly and the fact that the contractors were inconsistent, etc. without just shutting down reharvesting for the bad samples.

@kyule kyule added the enhancement New feature or request label Dec 12, 2024
@kyule kyule self-assigned this Dec 12, 2024
@kyule kyule changed the title Idea for handling legacy sampleID<->determination Possible idea for handling legacy sampleID<->determination Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant