POC Technical Issues Page
This page provides a record of the technical issues and software needs of the POC. When requesting new software, please provide an example of why the software is needed. Also provide the date that the request was first made. If the problem has been solved (either by creation of new software, or through some other means, please provide information on the solution here.
Problem: Loading has_part relations in the Plant Ontology File
Original request: This became a problem with with the January 2011 release, as the has_part relation had to be stripped out.
The Problem:
-The has_part relation causes a 'circularity or cycle' when loading the Ontology file into the database (not onto the browser as we originally thought?).
-Note: Our collaborators (eg; SGN), who uses a Chado schema, also have to remove them (LC).
-What exactly is causing the problem with loading? Is it actually the has_part relations themselves? (note: removing them allows the file to be loaded with no problems)
Questions:
- Do the problems arise when we have reciprocal part_of and has_part relations (or reciprocal part_of and develops_from relations) ?
For example, embryo sac egg cell is part_of egg apparatus and egg apparatus has_part embryo sac egg cell.
- JP: In general, which relations are treated as "reciprocally coupled"? Does this differ amongst different reasoners?
-Example: Does the OBO-Edit reasoner recognize these as "reciprocally coupled"? (Is the OE reasoner on when these are being added?)
- Uberon has a similar situation with mammary gland secretes milk and milk secreted_by mammary gland. Does that cause a problem?
- Also, PO has reciprocal disjoint_from relations, and they don't seem to cause a problem
- Question for JE: Are the disjoints being stripped from the live plant_ontology.obo file? They do not show up in the AmiGO browser either.
- (JE) I am not taking them explicitly out, but there is no trace of them in the database. Not sure why.
Definition of has_part relation vs the part_of relation:
*definition of has_part:
"In GO: The relationship A has_part B means that A necessarily (always) has B as a part";
i.e., if A exists then B also exists as a part of A. If A does not exist, B may or may not exist.
For example, ‘cell envelope’ has_part ‘plasma membrane’ means that a cell envelope always has a plasma membrane as a part but a plasma membrane may exist without being a part of a cell envelope. "
(Reference: The Gene Ontology Consortium The Gene Ontology in 2010: extensions and refinements. Nucl. Acids Res. 38, D331-335 (2010)).
You can also see the example on their site:
This is also defined on the GO Extended Relations Page
* def'n of Part-of:
- PJ raised the point (by email) that the developers guide on the PO website: [1] defines the
part_of relation as follows:
"This relationship is used in the plant structure ontology to indicate a subpart/part relationship within a tissue or organ."
for example: Ectocarp is part-of pericarp, which in turn is part-of fruit
[relationship type - part of] PO id: part_of name: part of definition: It indicates a subpart/part relationship within a tissue or organ.
Used in a non-restrictive manner, i.e., the parent may or may not have the child as a part, and the child may or may not be a part of the parent. Therefore, a child is sometimes part of its parent and not necessarily always part of a parent term.
We should be using the definitions based on RO. Think of them this way:
A part_of B can be read "Every A is part of some B."
A has_part B can be read "Every B has as a part some B."
A pair of classes may have either one of these relations or both. Having one does not imply the other.
Example- why it is needed:
Below is an example of how the has_part relation would be used in the PO to deal with the parts of the sporangium wall:
The sporangium wall is basically the same throughout vascular plants, so this proposal creates a new general term "microsporangium wall". The part_of children are part of microsporangium wall (sort of like the part_of children of leaf). Anther wall has_part sporangium wall, since an anther is composed of multiple sporangia. In the current version of the PO, parts of the microsporangium wall are parts of the anther wall, but that only works for angiosperms.
Note: With this approach, we not only need the software to be able to handle the relations, we need a way to assure that annotations move through has_part relations
Possible Solutions:
3-16-11 test RW: Removed the has_part relations from the reciprocal has_part and part_of relations from about 15 terms in the plant_anatomy.obo file.
JE loaded the file into the database and the onto the AmiGO browser with no problems.
3-17-11: RW removed the following relations from the developers' version of plant_ontology.obo and put it on SVN (version#1050):
Removed has_part (left in reciprocal part_of) relations from:
abscission zone > protective layer, separation layer
basal endosperm transfer layer > basal endosperm transfer cell
egg apparatus > embryo sac egg cell, synergid
Leaf stomatal complex > leaf guard cell, leaf stomatal pore
phyllome stomatal complex > phyllome guard cell, phyllome stomatal pore
Shoot apex > shoot apical meristem, leaf primordium
stomatal complex > guard cell, stomatal pore
Removed develops_from relations from (left in reciprocal has_part):
megaspore > tetrad of megaspores
microspore > tetrad of microspores
- Note: We will need to check into which way would have been better biologically.
- From BS (by email): Please make sure that if you delete these assertions, then you keep them at least as comments.
The following has_part relations are still in the file:
collective organ part structure > cardinal organ part
collective plant structure > plant organ
coma > seed trichome
embryo axis > hypocotyl, root meristem
first order inflorescence axis > peduncle
fused collective tepal structure > fused tepal
inflorescence > flower
infructescence > fruit
meristem > meristematic cell
second order inflorescence > flower, second order inflorescence axis
second order infructescence > fruit, second order infructescence axis
tetrad of megaspores > megaspore
tetrad of microspores > microspore
theca > pollen sac
3-17-11 test:
- JE loaded the modified plant_ontology.obo from the SVN (version#1050) onto the beta browser and LC loaded onto the dev browser. It works fine on both sites.
dev: inflorescence has_part flower
- Still need to determine if this fix works for Chado users. LC will send the modified version to Naama and Lucas and ask them to test it.
We will try to load the file that has has_part relations but no reciprocal has_part/part_of relations into the beta browser with annotations, to see if that works. Also need to try loading a file into the dev browser with a pair of reciprocal relations to see if it works without annotations.
Possible solutions discussed at the meeting on 3-17-11/action items for being able load the file with has_part relations
1. Confirm that the reciprocal part_of and has_part relations were what was actually cause the problem with loading the obo file onto our browser. To do this, we should: a) Try loading the file without the reciprocal relations but with some has_part relations onto the beta browser with annotations (this will require that I edit a version of the live file, since the annotation files currently match the live file), b) try loading a version of the file that has maybe one or two reciprocal relations, but no annotations on to the dev browser (to see if the reciprocal relations cause a problem when there are no annotations).
2. If the reciprocal relations are causing the problem, we can deal with them in one of two ways: a) remove all reciprocal relations from the ontology file, that is, only use part_of or has_part, but not both, or b) include reciprocal relations when they are appropriate, but write a script that searches the files for reciprocal relations and removes the has_part relation from classes that have both.
Treating different relations differently when dealing with annotations
Original request: March 9, 2011, but has been discussed earlier.
- Under the current rules, all relations are treated equally, so all annotations get passed up from any child to its parent, regardless of the relation.
This works fine for is_a and part_of, but is problem for other relations.
has_part:
- Annotations should pass from parent to child, in the opposite direction of the arrow (through has_part backwards, that is).
- Furthermore, they should only pass through has_part relations when the instance for which the annotation was created comes from a taxon in which the parent term is part_of the child term.
For example:
In theca has_part pollen sac, theca is the child, and pollen sac is the parent.
Annotation should never go from theca to pollen sac. Annotations should go from pollen sac to theca, but only if they come from an angiosperms.
In order for this to work, the conditions under which annotations should pass through will have to be specified every time a has_part relation is added to the ontology. That means that any class in the PO that has a has_part tag will have to have additional tags specifying the conditions under which annotation should pass through the has_part relation. We would have to create a custom tag for this, perhaps a custom relation, that is conditional. Something along the lines of: if taxon_id=xxxx then treat parent term as part_of child term.
Option: Should we just have the annotation not move through the has_part relations?
What are the implications of this?
develops_from: Annotations should not pass through the develops from relation. For example, leaf develops_from leaf meristem. If a gene is expressed in a leaf, this does not mean it is expressed in the leaf meristem that it developed from.
Alternative solutions to using has_parts
We did not discuss these possible solutions at the meeting. See above for actions to be taken.
1. Have all of the parts of a structure be only part of the most general class, then write a script so annotations to any part_of child of that class also go to the correct specific is_a child (as describe above for leaf). This would allow us to use the current software such as Amigo and Chado, but would require additional software and possibly special coding in the obo file for all terms that need special treatment.
2. Have specific part of children for all of the specific is_a children. This would not require any changes to the existing software or new scripts. However, it would quickly lead to term inflation. Also, it would not be biologically accurate, since the is_a children would be based largely on the taxon in which they occur, not on real differences in the structure.
3. Use the PO as an uber-ontology for plants, then create taxon-specific sub-ontologies that cross-reference the main ontology. This would create a similar number of terms as solution number 2, but they would not all be in one ontology, so it may be more manageable. Would create problems in syncing the ontologies, and could make cross-species comparisons more difficult. Of course, even within a single taxon (like angiosperms) there may be a need to use the has_part relation (like inflorescence has_part flower).
Need: Script or an Algorithm for Assigning Annotations
Original request: March 1, 2011
Example: For gathering annotations from parts of leaf to either vascular leaf or non-vascular leaf
Why this is needed:
At the POC_Conf._Call_3-1-11 we agreed that in general, it is better to have the part_of children of leaf only be part of the general term leaf, rather than create new terms for vascular parts of and non-vascular parts of. Terms that only occur in one or the other (like leaf endodermis or costa) will only be the child of the appropriate term.
If someone puts an annotation on leaf epidermis for rice, it will be collected by leaf, but not by vascular leaf, even though it should also be on vascular leaf.
Solutions:
- We will suggest to users that in cases like this, they annotate to both leaf epidermis and vascular leaf.
- Also, we will need to write an algorithm or script that will automatically add the annotations to vascular leaf, in case the curators miss it.
- It should search for annotations for parts of leaf, then check the taxon ID, and then add the appropriate annotation to either vascular leaf or non-vascular leaf.
- This will assure that annotations end up on the correct terms, but reduce term inflation.
It is likely that the same issue will come up for other classes, as we add terms and annotations for more taxa.
Linking images to PO
Original request: March 9, 2011, but this has been discussed on and off since 2010, including at the POC meeting at the NYBG in Nov. 2010.
Need to register Plantsystematics.org in the GO dbxref database so we can create shortcut links to their pages.
Problem with OWL File Generation
-OBO to OWL file generator is creating OWL file without the term definitions. Needed for interaction with SSWAP services.
-- We currently create the OWL file manually using OBO-Edit. This works as long as we only do it (and remember to do it) when we have a release.
-- Trying to create an automated way to do this I turned to using go2fmt.pl to do it.
Both of the above methods result in a valid OWL file, but valuable info such as the definitions is lost.
- I found a paper that says they have a method to do a OBO 2 OWL -> OWL 2 OBO round trip with no loss of info, but can not find the actual program to do this. Paper:ftp://ftp.cs.utexas.edu/pub/techreports/tr06-47.pdf
Register OBO_SF_PO in Go.xrf_abbs
We have a number of xrefs to OBO_SF_PO, which refer to the SourceForge tracker items associated with terms.
