Closed austinmeier closed 8 years ago
I think we can reuse the same yaml pattern file, but use a different csv input file. That way we won't worry about curated rows being overwritten by samara generated rows
Okay, that makes sense. Except I am confused about the logistics of having two different files to apply the pattern to. The output of the apply_pattern.py script is a .owl ontology file. So can I add a flag to use multiple .tsv files as input? (I tried just putting both .tsv files after the -i flag, but got an unrecognized argument error). Better yet, is there a way to specify an existing ontology in which the new terms should be added to? Or every time I add a row to the .tsv input file, I have to regenerate the entire ontology from scratch?
I've added a hierarchy tsv to the apply pattern folder to try some things on.
It's fairly flexible but maybe that doesn't help you.
The way I do it e.g. here https://github.com/cmungall/environmental-conditions/ is to have separate csvs, separate owls, and multiple import statements. Setting this up for the first time can be fairly fiddly - e.g. you'll want to make sure every import is in the catalog
I think I'll leave the upper level classes as manually created through Protege for now, but I'd like the diseases to be automatically added to the correct upper class depending on the classification of the 'causal agent'.
For example: The three plant diseases I have in the test_aps_diseases.tsv are all of different type (viral, bacterial, and fungal). Right now, the apply_pattern.py script simply lumps them all into "plant stress" because that's the term specified in the pattern YAML. Ideally I'd like something to determine if the pathogen specified falls into the upper classes, based on the NCBI hierarchy. This seems like a task a reasoner could do, but the actual process is out of my skill-set. is this achievable? If so, is it something I'd have to change in the .tsv, the YAML, or the apply_pattern.py ?
Yes, it's actually easier than you think
The harder part is setting up an import chain that brings in the the axiomatized aps classes plus your manual grouping classes (plus ncbitaxon_import). I can help with this.
Once you have that, it's all easy. Just select Elk, switch the reasoner on, and go to the inferred view. It should automagically unflatten itself.
For releases, it should be even easier. Doing make
should make a obo and owl file that is pre-reasoned.
I looked at the oops-edit file. I think you should be using OOPS_0000013 (plant disease) instead of OOPS_0000000 (plant stress) in your disease pattern.
Take a look at what I did there: https://github.com/marieALaporte/ontology-of-plant-stress/commit/144d1324a2016064ea0765f7b762f8132b86623a I removed the disease classes from the main file (oops-edit.owl) and imported the owl file generated by the python script (I guessed it is OOPS-temp.owl). I also replaced 'plant stress' by 'plant disease' in the patterns. If you run the reasoner, you'll see that the classes are automatically classified under the categories you have defined. You can use this as an example.
Awesome. Thank you both for the explanation! I have made these changes suggested by MAL, and now need to go about cleaning this repo and renaming some things to make things more clear.
It was mentioned that we could have a separate pattern file for creating the upper classes in the ontology for using the yaml design patterns. @cmungall could you point me to an example, or template I could use to achieve this?