Open cmungall opened 8 years ago
Current list to be merged:
There are three things in the CO
Trait Method Variable
We can map to TO via their Trait, but method and variable connects to their trait. Shall we define the relationships we propose to create a tree
TO --isa--CO_trait ----isa_method_of--CO_method -----isa_variable_of_method--CO_variable
Since adding CO from multiple species would create redundancy, we suggested appending a prefix 'species common name' to each of the following
CO_trait CO_method CO_variable
On Tue, Jan 5, 2016 at 1:50 PM, Common Reference Ontologies for Plants < notifications@github.com> wrote:
There are three things in the CO
Trait Method Variable
We can map to TO via their Trait, but method and variable connects to their trait. Shall we define the relationships we propose to create a tree
TO --isa--CO_trait ----isa_method_of--CO_method -----isa_variable_of_method--CO_variable
Can you provide specific examples for each of these three is_a relations? BS
Since adding CO from multiple species would create redundancy, we suggested appending a prefix 'species common name' to each of the following
CO_trait CO_method CO_variable
— Reply to this email directly or view it on GitHub https://github.com/Planteome/plant-trait-ontology/issues/374#issuecomment-169094847 .
Current status:
Barry, can you open a new ticket for this, in one of the IBP repositories? is-a may be problematic here but it's not really relevant to this ticket
In fact the actual relationships used are method-of and scale-of; this was all discussed at the meeting and I think is fine for now
we are using 3 relationships: method_of: domain: method ; range: trait scale_of: domain: scale ; range: method variable_of: domain: variable ; range: trait or method or scale (note that for each variable, you will find a link to a trait, a method and a scale using the property variable_of)
On Tue, Jan 5, 2016 at 2:16 PM, Marie-Angélique notifications@github.com wrote:
we are using 3 relationships: method_of: domain: method ; range: trait scale_of: domain: scale ; range: method variable_of: domain: variable ; range: trait or method or scale (note that for each variable, you will find a link to a trait, a method and a scale using the property variable_of)
I think I understand the above more or less. What I would like to see is specific examples of how these relations are used in order to check whether my understanding is correct. (Remember one role of the ontology work is to provide a doorway into your data for outsiders who do not have your initimate knowledge of what you are doing.) BS
Reply to this email directly or view it on GitHub https://github.com/Planteome/plant-trait-ontology/issues/374#issuecomment-169101750 .
Barry
TO: leaf weight CO_Trait: leaf weight --CO_method: dry weight of leaf ----CO_variable: scale-1 --> if the weight is 1-3g ----CO_variable: scale-2--> if the weight is 4-6g ----CO_variable: scale-3--> if the weight is 7-10g ----CO_variable: scale-4--> if the weight is 10-12g ----CO_variable: scale-5--> if the weight is 12-15g
I was thinking that we have an option to limit the mapping to TO <--> CO_trait but in the interest of buy in from the community we may have to bring in all the associated methods and their scorable variables of phenotypes.
When the CO terms from lentils are merged to TO it may look like this. That's why we need to define the relationship_types. Following example of relationship types is meant to start the discussion. They can be renamed. But we need it fast to show at the PAG meeting.
TO: leaf weight --isa--CO_Trait: leaf weight -----isa_method_of-- CO_method: dry weight of leaf -------isa_variable_of_method- CO_variable: scale-1 --> if the weight is 1-3g -------isa_variable_of_method- CO_variable: scale-2--> if the weight is 4-6g -------isa_variable_of_method- CO_variable: scale-3--> if the weight is 7-10g -------isa_variable_of_method- CO_variable: scale-4--> if the weight is 10-12g -------isa_variable_of_method- CO_variable: scale-5--> if the weight is 12-15g
I forgot each of the CO imports would have species name (common name) as prefix to avoid conflicts.
Modifications to requirements coming out of meeting:
we don't want the CO groupings in the merged file. The obo/owl generation script should take the TD5 file plus the separate mapping file (these can be combined into one for TD6) and make a bridge file similar to the one @marieALaporte just created for cassava, but lacking groupings.
For now, planteome-new brings in the version of cassava and lentil that includes the groupings, this is what we will load for the demo
that's fine -pankaj
On 1/5/2016 11:03 AM, Chris Mungall wrote:
In fact the actual relationships used are method-of and scale-of; this was all discussed at the meeting and I think is fine for now
— Reply to this email directly or view it on GitHub https://github.com/Planteome/plant-trait-ontology/issues/374#issuecomment-169098683.
Format: TD5-TSV
All IBP-traits should have a TSV as well as .xls
My script only takes .tsv in TD5 layout.
Any xls to be included in the merged TO must have the tsv. Later we can explore an automated job to convert but for now should be manual
Note: when saving from excel, must use the correct line delimiters
fixes in place:
perl -pie 's@\15@\n@g' FILENAME
suffix must be .tsv
TD5 file must have mapping to TO IDs
(SEE NEXT CHECK - this may not be necessary)
TBD: which column is this?
in lentil it is col9, called TO_ref
in lentil it is col16, and called "Trait Xref"
What is the format? Are we using '(u)'?
Ontology file must be included
This will be a deterministic translation of the TD5 file
Note: it seems in some cases an xref is included, which obviates the need for the previous check?
However, xref does not distinguish between exact and subclass
Ideally the ontology would be in OWL with the correct logical axiom, avoiding the need for a bridge file
The ontology MUST be parseable by the canonical parser for that format (obo or owl)
Each ontology should have a travis job
This should check each commit to make sure the resulting files are still parseable
Each ontology should have a PURL
This can be within the to PURL space, e.g.
/to/ext/ibp-lentil-traits/lentil.owl
Each production-ready ontology should be in planteome.owl
Add the ontology (plus bridging axioms) to the importer
Ontology ID space should be registed
TBD. Should all CO_nnn ontologies be registered with OBO? Note it may be preferable to have a single ID-space, e.g. Bioversity:NN-NNNNN with the first 2 digits being the CO number
This PR adds some CO_nnns to the GO xrefs https://github.com/geneontology/go-site/pull/134 I'm not totally comfortable about GO usurpring OBO here..
https://github.com/geneontology/go-site/pull/134