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.
website issues- link from downlooad page goes to index page. Need a direct link to the live tag.
Need new DBxRef Links:
- Link to ISBN#s- OpenISBN or page with list of ISBN refs PO_references
- PO_references page for POC curators or something similar
- Need to fix dbxref for Fragaria
(LC 2-18-12)
Database structure
From Chris Mungall:
It makes things a little easier if the directory is laid out consistently with other ontologies. Perhaps
ontology/
>po-edit.obo
>po.obo # derived
>po.owl # derived
>...
(RW 3-7-12)
AmiGo 2 Wishlist:
More reasons to switch to AmiGO 2
Recent email from CM:
Note that AmiGO1 will give curious answers to gene expression queries if you leave in has_part. AmiGO2 will handle cycles and answering questions appropriately.
(RW05-03-12)
Idea for PO Graphical Viewer
suggested at wood ontology meeting 2-6-12:
Customize the graph- for example, make the part_of relation a dotted line to differentiate it from the is_a relation
Idea for advanced filter
suggested at wood ontology meeting 2-6-12:
Would be good to be able to filter by relation type
Redirect from search to GO
How is the best way to redirect users to terms that are in GO? For example; casparian strip or pit membranes?
We need a means of redirection from the search- could we have a list of GO terms specific to the PO that the browser could redirect to?
(LC Feb 2012)
sort the child terms numerically
It would be great if the tree would sort the child terms numerically, rather than alphabetically by term name. This came up in the discussion of the seed trichome dev stage terms POC_Conf._Call_11-29-11. Then we would not have to prefix the names with numbers or letters.
Link on Homepage to Source Forge tracker
submitted 9-28-11- LC Now that people need to login to SF to submit a request, this link needs to be fixed. Currently take you to a dead-end if you are not already logged in. Current link: [1]. I suggest we create an intermediary wiki page with some explanation
Color coding the Anatomy and Development terms differently?
This was a suggestion raised by PJ a the NYBG meeting Sept 2011 Saturday_Sept_10th,_2011 during the discussion of the cross-ontology relations.
add more details....
filter translation
Date: 9-13-11
This was sent as a feedback response on the web page- went to Po-internal. refer_to_url: http://www.plantontology.org/index.html
subject: filter translation
comments: It would help to have a link to what the filters mean from all pages where one can set the filters. A click on the help box seemed to missing this information, or require reading pages of stuff to find out it wasn't there. For example - most folks will not know that MGCSC refers to the maize mutant stock collection at Illinois.
name: Mary Schaeffer
email: schaefferm@missouri.edu
organization: MaizeGDB
Download annotations from the PO website
-Currently, when you are on the PO page and want to save the list of associations, the only format available is RDF-XML.
-Could we also have the ability to download as csv or txt, so it could be imported into excel? That would be of use to many users. or tab delimited!
for example: embryo axis
New images needed for browser
JE: I noticed in the server logs that errors are being created because we are missing images for participates_in and adjacent_to. Can someone create these for me to add to the browser?
We now have icons for all relations. Remove this item? (RW05-03-12)
Translations
New subsets for Spanish and Japanese synonyms are ready to be added to the PO, with the scope exact synonym. All plant anatomy terms now have Spanish synonyms, and most have Japanese synonyms. Spanish and Japanese synonyms will not be incorporated into the live version of the PO for this release, but will be available to users on request.
Just need the script to insert them, will include in the next release
Need script for inserting the translations as synonyms into the obo file
Also, it would be helpful to be able to generate a list of the new terms whenever we are ready for a new release.
It should contain the ID, English name, foreign name, and definition. There would be blank spaces under the foreign name for any new term. If we also could make it flag terms whose names have changed since the last release, that would be great.
Version information
(posted 11-14-11)
We have been numbering releases sequentially (e.g., 1 -16)
CM suggests another system:
Many people use YYYY-MM-DD
See http://www.obofoundry.org/id-policy.shtml
This has the advantage of making automated releases easier - just use the date and don't worry about what the previous version# is. Oort should do this for you.
It's up to you how you do it. You could have names like apple, except cute plants rather than cute animals.
If you are using incremental versions, I recommend a minor-major system with a dash separator. E.g. 1-16.
If you are manually assigning releases then you can add this to the data-version tag in the obo, where it will propagate to versionInfo in OWL
Plant Ontology Web site issues:
Please go to: Plant Ontology Web Site Update: 2012
Tutorials and Demos out-of-date
Tutorials The ppt tutorials on this page are severely outdated!
and this one is as well: POC Demo
Problem on the dev browser- can't filter by the new 'plant anatomy' name
Looked at filtering problem on dev browser. It does not seem to be related to differences in capitalization or word form, as these also exist on the live browser, with no problem. JE is looking into it.
Problems displaying AmiGO Browser in Internet Explorer:
PJ sent a note out by email that some users are having problems displaying AmiGO Browser in Internet Explorer: IE views are not similar to the ones in Firefox.
-See the comment at:link "On my computer, this displays correctly in FireFox 3.6.13, but not Internet Explorer 8.0.6' on this page."
- RW confirmed it: "The Amigo browser tree view does not display correctly in Internet Explorer on my PC either. All of the terms at one level of the tree are displayed on one line, instead of in a hierarchy. I'm sure I've griped about this before, but don't know if I have a written record. It works fine on Safari and Firefox on my Mac."
JE looked into this and it seems to be just with the newest version of the IE. We will put a note on our browser site: "Best viewed using Firefox" or something to that effect.
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: [2] 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
POC meeting, Webex Conference Call; Date: Thursday Mar 17th, 2011 1 (PDT)
In attendance: Laurel Cooper (OSU), Ramona Walls (NYBG), Justin Preece (OSU), Pankaj Jaiswal (OSU), Dennis Stevenson (NYBG), Chris Mungall (Lawrence Berkeley National Lab)
Absent: Marie Alejandra Gandolfo; (Cornell University, Barry Smith (University at Buffalo, NY)
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.
If PO is going to modify the Amigo code to treat different relations differently, CM suggested that we first switch to the newest version of Amigo. That way, any changes we make could be shared with other users in the community.
GO consortium is working on new software that uses Java on top of OWL (not sure it that is exactly what he said). Also moving toward greater interoperability of OBO and OWL, so it may not be necessary to switch to OWL at this point.
Alternative solutions to using has_parts
1. Have all of the part_of shildren 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.
This is probably not feasible at this time.
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.
There was general opposition to this approach, particularly for terms with many part_of children, because of the resulting term inflation.
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).
We did not discuss this possibility.
Treating different relations differently when dealing with annotations
Recent email from CM:
Note that AmiGO1 will give curious answers to gene expression queries if you leave in has_part. AmiGO2 will handle cycles and answering questions appropriately. (RW05-03-12)
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?
At a minimum, annotations should not pass forward through has_part relations. Possible solution is to have two versions of PO Amigo (similar to what GO does). One with all of the relations visible, for those who want to explore the ontology and definitions, and one with has_part and develops_from relations stripped out, to be used for gene expression queries.
It may be possible to create a schema to assign the annotations to the correct terms, similar to the one described below for parts of leaf, using the only_in taxon relation. This would only work when the has_part relation is specific to a larger taxon. Would not work for something like inflorescence has_part flower, which is highly variable among close relatives. We will probably not be able to implement this solution in the short term.
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.
Did not discuss this at length. Best solution is probably to modify the code (in Amigo or elsewhere) to not allow annotations to pass through develops_from relation. Alternative is to use two versions of Amigo, as described above.
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.
We can implement this by using the "only_in_taxon" relation. For example, we would add the relations vascular leaf only_in_taxon vascular plants and non-vascular leaf only_in_taxon bryophytes. Then we would have a script that looked at all annotations for the part_of children of leaf, determine if the taxon id is for vascular plants or bryophytes, and then move the annotation to either vascular leaf or non-vascular leaf.
CM asked us to send him a sample file with a few only_in_taxon relations, so he can send us an example of how the script would work.
In order to add these relations, we will need to:
-Create PO slim for plant taxonomy, based on NCBI ontology. Include all plant species currently in GO?
-Create union classes for Bryophytes, pteridophytes, others
-Import or mireot PO plant taxonomy slim into PO
-Add the relations
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
CM said not to use that software, because it is out of date. He sent a link to the correct code: http://code.google.com/p/oboformat/
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.
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.
