Produce specific similarity artifacts for Exomizer using custom counts

monarch-initiative / semsimian

Simple rust implementation of semantic similarity

BSD 3-Clause "New" or "Revised" License

8 stars 5 forks source link

Produce specific similarity artifacts for Exomizer using custom counts #125

Open caufieldjh opened 5 months ago

caufieldjh commented 5 months ago

Based off of #124

Establish a consistent way to count phenotype for MP and ZP
Produce Exomizer similarity artifact for:
- HP v HP
- HP v MP
- HP v ZP
Include some provenance and reproducibility data in the header of each, including semsimian version and the command(s) run to produce the file.

Each will need to incorporate the counts from HPOA (for HP) and Monarch's phenotype files (for MP and ZP) - or in the latter case from wherever Monarch is getting them.

caufieldjh commented 5 months ago

See the gene to phenotype tables here: https://data.monarchinitiative.org/latest/tsv/gene_associations/index.html

These appear to be identical to the owlsim tables already in use by Exomizer (see https://archive.monarchinitiative.org/latest/owlsim/data/Danio_rerio/Dr_gene_phenotype.txt)

justaddcoffee commented 5 months ago

To flesh this out a bit, the plan we discussed I think

start with our existing Jenkinsfile that runs semsimian
make each HP x HP, HP x MP, HP x ZP table separately using:
- HP phenotype counts from HPOA
- MP phenotype counts from IMPC and MGI
- ZP phenotype counts from gene_phenotype.7955.tsv from Monarch data website here I think? - put on KG-Hub s3 bucket somewhere coherent
finish implementing custom IC maps in semsimian

caufieldjh commented 5 months ago

IMPC phenotypes may not already be included in Monarch G2P tables, but Exomizer does use them.

caufieldjh commented 4 months ago

So to get this done, we will need to:

Decouple creation/updating of the IC map and closure map. They are currently stored separately (see https://github.com/monarch-initiative/semsimian/blob/d66e20cc602d5f4eaf86acb742e01264511b21c2/src/lib.rs#L68-L78) but updated at the same time.
Check for whether we have been provided with a custom IC map (as a filepath). If so, don't create a new one, but parse the provided one and use that instead.
Raise error if there is not alignment between the custom IC map and the closures.

caufieldjh commented 4 months ago

See also #47 - but for terms missing from IC map instead of closure map

caufieldjh commented 4 months ago

If the closure map and IC map do not contain each others' keys, raise an error. We will work under the assumption that the user will provide inputs which are in alignment and contain all necessary IDs