Closed pnrobinson closed 3 months ago
Hi @pnrobinson I think the workflow is OK from the high-level.
The thing regarding removal of HPO from the concept recognizer - that is an example of what I consider as a code smell. It makes CR doing two things: 1) recognize concepts 2) provide HPO. I think CR should only do the 1st thing and we must update the code that used to rely on the 2nd functionality and simply ask for the HPO via the constructor.
I think using the HPO version in CR is OK as long as the CR does not expose it as a property. This should be OK because we should be using just one HPO version during the phenopacket creation anyway.
Last, regarding the HPOA, I haven't got there yet, so I honestly do not know what the best course of action should be. I'll get there eventually and we will work it out. I'm happy to discuss this early this week.
Merging this despite create_hpoa_from_phenopacketsIndividual it is some weird manging bug but we should remove the import * statements now that the API is stable
@ielis Hi Daniel -- can we touch bases on Mon or Tue about this -- I added two functions to streamline processing the template. Everything seems to work but there is one error. One question -- I think you remove the hpo ontology getter from the HpoCr class, which is reasonable, but maybe we can add back a hpo-version function? This would simplify things and the HPO version is arguably an important attribute of the CR.
Here is how the new functions would be used
I hope this is getting to a place where a borader audience can use this tool. Also, for phenopacket store, maybe it is enough to just use a Python script for some of the genes -- I want to use this for all new annotations to the HPO and want to make things as efficient as possible!