Difference between revisions of "POC Conf. Call 6-28-11"

From Plant Ontology Wiki
Jump to navigationJump to search
Line 35: Line 35:
 
RW also updated the file at http://plantontology.org/docs/dbxref/PO_DBXref.txt.
 
RW also updated the file at http://plantontology.org/docs/dbxref/PO_DBXref.txt.
  
===Action items===
+
===Action items:===
  
 
'''Do we need to do anything else to get the new xrefs to link automatically?'''
 
'''Do we need to do anything else to get the new xrefs to link automatically?'''

Revision as of 18:36, 24 June 2011

POC meeting, Webex Conference Call; Date: Tuesday June 21st, 2011 10am (PDT)

In attendance:

POC members:

Absent:

Collaborators:


Acceptance of the minutes from the POC_Conf._Call_6-7-11?


Tech issues

New xref in database

A stanza for our SF tracker has been added to GO.xrf_abbs (thanks to Becky Foulger):

abbreviation: OBO_SF_PO

database: Source Forge OBO Plant Ontology (PO) term request tracker

object: Term request

example_id: OBO_SF_PO:3184921

generic_url: http://sourceforge.net/tracker/?func=browse&group_id=76834&atid=835555

url_syntax: https://sourceforge.net/tracker/index.php?func=detail&aid=[example_id]&group_id=76834&atid=835555

url_example: https://sourceforge.net/tracker/index.php?func=detail&aid=3184921&group_id=76834&atid=835555


RW also updated the file at http://plantontology.org/docs/dbxref/PO_DBXref.txt.

Action items:

Do we need to do anything else to get the new xrefs to link automatically?

Concern from TAIR over how annotations move through relations

Excerpts rom Tanya's message:

We're working on integrating the new relationships that PO is using into our local system and were wondering about handling annotation count propagation over some of these relationships.

For example, anther wall endothecium and anther wall middle layer are adjacent. When you look for annotations to anther wall endothecium, one also retrieves annotations to anther wall middle layer: http://plantontology.org/amigo/go.cgi?view=assoc&search_constraint=terms&query=PO:0020002 Somehow, this does not seem like the expected (or desired) result.

I was wondering if you would consider producing a file of the PO that does not contain the 'trickier to count' new relationships?

Action items

Do we want to create a file without has_part, develops_from, derives_from, and adjacent_to?

Items arising from previous meetings:

Children of Leaf- feedback from TAIR:

The following is a summary from the email correspondence, from Tanya Berardini:

  • TAIR strongly supports creating specific vascular and non-vascular children for leaf apex and similar terms that are part_of leaf, like those describing the leaf apex in rosette leaves and cauline leaves.
  • TAIR proposes we create more specific terms for the is_a children of vascular leaf, like cauline leaf. For example, 'cauline leaf margin' and 'rosette leaf margin'.
  • TAIR suggests creating the terms which already have annotations attached to them, like 'vascular leaf margin' (current Arabidopsis, rice, maize annotations to 'leaf margin') and adding other terms upon request by annotators or users.

Their Reasons:

  • Much easier for annotators to choose the specific term they need as opposed to having to remember to co-annotate or having a script go in after and clean up
  • Benefits for the researcher who is looking for very specific information
  • The added granularity of these terms will be a benefit when people want to describe structures such as the leaf apex in rosette leaves and cauline leaves.
  • They are not worried about term inflation
  • A researcher browsing through the ontology would not know to look at annotations to see that there are combinations of annotations that give the 'same' result ('leaf apex' + 'rosette leaf')
  • The current functionality of AmiGO does not allow a search for gene products annotated to Term A AND Term B.
  • The the combinatorial solution work will not work if a gene is expressed only in the 'leaf margin of cauline leaves' and in the 'leaf apex of rosette leaves'. How do we know which 'part' goes with which 'leaf'?
  • Unless the co-annotations are captured in a single line in the gaf file (possible with column 16), this could lead to misinformation.

Questions and suggestions from last week's meeting:

-We could create specific child terms, but at what level should we stop?

-Users could post-compose terms, but then, those terms ultimately would need to go into the PO so that future work could reference the definitions, so it doesn't save much over precomposing the terms (but it does provide a guide for when to stop adding term: you stop at what the users need.

-There is an issue of training. Annotators will have to be taught to annotate to the part of the leaf and the type of leaf. The same applies of other types of plant structures as well.

-We could use a script to move annotation from the parts of leaf to the appropriate type of leaf, but this effectively creates another line in the annotation file, and does not solve the problem of how to associate two different annotations (like the annotation to leaf margin with the annotation to rosette leaf). To do this, we need to have the information in the same row of the annotation file.

-Does the GAF format allow us to put the PO id for the type of leaf in column 16? If we put the PO id in column 16, will that create an annotation to that term? Probably we will still have to make a separate line for that annotation. See: GO annotation file GAF 2.0 format guide.

-Rather than setting a strict policy about when to inflate or not, we should probably consider it on a case by case basis. We could start by adding pre-composed terms for those structures that already have annotations associated with them (see below), then asking TAIR and other users to use column 16 to post-compose any other term they might need. They can also use column 16 to associate a structure with a growth or developmental stage. See below for more details.

-We should set up a meeting with TAIR to explain to them why we don't want to add all of the specific children, and to work them on a solution. It is important that we have the script for transferring annotation up and running, and that we test out how we can use column 16 for associating leaf types before we meet with them.

-Need to consider how this will affect the processing of the annotation files that happens with each release.


Other related suggestions:

1. Make rosette leaf and cauline leaf is_a children of leaf, rather than is_a children of vascular leaf. Then we could make children vascular rosette leaf and vascular cauline leaf. Do we need these parent terms if rosette leaf and cauline leaf only occur in vascular leaves? (RW: We should create a SF tracker for this.) Also, we need to work on the definitions of rosette leaf and cauline leaf. Should link them to growth stages, because (at least in Arabidopsis and other Brassicaceae) they are the same leaves at different times.

2. Move all leaf parts (be they part_of vascular leaf, part_of non-vascular leaf or part_of leaf) to be part_of leaf, so that users could find all of the parts in one place. This might also force them to make the second annotation to the type of leaf. PJ suggested that we could use disjoint_from relation. For example: have leaf vascular system be a part_of leaf (instead of part_of vascular leaf) then make it disjoint_from non-vascular leaf. This would prevent curators form making an association to the wrong type of leaf. Problem with this is that we intentionally omit information that we know to be true (e.g., we would leave out leaf vascular system part_of vascular leaf). That is not necessarily bad, but we need to have a good reason for it.

3. Add disjoint_from relations between vascular leaf and non-vascular leaf. In OWL you have to do that, because if you don't assert it, OWL assumes they are not disjoint.

4. We have both non-vascular leaf meristematic apical cell and vascular leaf meristematic apical cell. We should merge those with leaf apical cell if we are going to be strict about not making any specific part_of children of different leaf types.

Proposed solutions:

All: Create specific children for all of the parts of leaf, for each type of leaf. This is pretty much what we did for tuber, although it only has 2 is_a descendents and 8 part_of descendents. There are 15 is_a descendents of leaf (juvenile leaf, transition leaf, adult leaf, transition leaf, non-vascular leaf, vascular leaf, simple leaf, compound leaf, rosette leaf, cauline leaf, cigar leaf, embyro leaf, leaf spine, cotyledon, and flag leaf) and about 30 part_of descendents (not counting those that are only part of vascular or non-vascular leaf), so if we created all of the combinations of child terms it would add about 450 new terms.

Nothing: Do not create any specific part_of children for vascular leaf and other types of leaves. Keep or move all part_of children under leaf, and use column 16 to create cross-products to the correct type of leaf.

Somewhere in between: There are 21 part_of descendents of leaf that currently have annotations associated with them. All of these annotations come from vascular plants. We could create specific part_of vascular leaf children only for these 21 terms, and then add others as annotations for them arise.

We could adopt a policy of only adding specific part_of children for vascular leaf and non-vascular leaf. All other leaf types could be considered phenotypes (e.g. compound or simple leaf, spine leaf) or growth-stage specific forms (e.g., embryo leaf or cotyledon), and we could ask annotators to use column 16 to associate the part of the leaf to the type of leaf in these cases.


Unless we adopt the "All" strategy (which seems impracticle), we will need a mechanism for associating the annotation that is on the part_of a leaf to the correct type of leaf. Such a mechanism would be very useful for other types of structures, as it would allow users to create new cross-product terms on the fly. It could also be used to more accurately annotate gene expression that occurs in a structures at a specific growth stage (right now, users simply put the annotation on both the structure and the growth stage, without any link between them). Annotation extensions (Column 16) allow us to do this.

See PO_Annotation_Extensions_(column_16) for a full explanation of how this would work.

Action items

???

Annotations on terms that are part_of leaf

The list below contains all of the terms that are part_of leaf and have annotations associated with them.

In the last round of revisions, we decided that any existing annotation for these terms should also be copied to vascular leaf. Future annotations should go to both the part and to the appropriate leaf type. However, we have not actually transferred any of the annotation yet.


term name - (id) - number of annotations (from version 14, not from most recent association files)

  • leaf aerenchyma (PO:0006215) 1
  • leaf apex (PO:0020137) 12890
  • leaf base (PO:0020040) 5
  • leaf epidermis (PO:0006016)365, includes:
    • buliform cell (PO:0004001) 1
    • leaf abaxial epidermis (PO:0006019) 4
    • leaf adaxial epidermis (PO:0006018) 4
    • leaf lamina epidermis (PO:0000047) 1
    • leaf trichome (PO:0006504) 63
  • leaf intercalary meristem (PO:0006346) 1
  • leaf lamina (PO:0020039) 12800, includes:
    • leaf lamina base (PO:0008019) 12614
    • leaf lamina vascular system (PO:0000048) 1 (already shows up under vascular leaf)
  • leaf margin (PO:0020128) 100
  • leaf mesophyll (PO:0005645) 762, includes:
    • palisade mesophyll cell (PO:0006206) 1
    • spongy mesophyll (PO:0005647) 1
    • spongy mesophyll cell (PO:0006205) 2
    • leaf prickle (PO:0025175) 0
  • leaf sheath (PO:0020104) 205, includes:
    • leaf sheath pulvinus (PO:0008017) 2


If we were to adopt a policy of only creating specific terms when they are needed for annotation, we would have to create a vascular leaf child for each of these 21 terms.

Report from the2011 Semantic Web Workshop June 6th and 7th, Santa Fe, NM

Hosted by Damian Gessler and the iPlant Collaborative, this two-day workshop will focus on biological applications for semantic web services.

-JE and JP will be attending

-JE has already worked with Damian to implement a SSWAP web service for PO terms, so further collaboration with him and iPlant will benefit the POC going forward.

For more Workshop details: Semantic web.


Upcoming meetings 2011:

Botany 2011 Meeting [Botany 2011] St. Louis, MO at the Chase Park Plaza, July 9-13.

Societies participating: Society for Economic Botany, the American Fern Society (AFS), the American Society of Plant Taxonomists (ASPT), and the Botanical Society of America (BSA).

Anybody going??


* ICBO 2011 Second International Conference on Biomedical Ontology July 26-30, 2011 Buffalo, New York

ICBO

LC is co-organizing the workshop "From Fins to Limbs to Leaves: Facilitating anatomy ontology interoperability" along with Melissa Haendel, Chris Mungall, Alan Ruttenberg, David Osumi-Sutherland.

Full-Day Workshops Schedule:

July 26 9am-6pm The Ontological Representation of Adverse Events: Working with Multiple Biomedical Ontologies

July 27 8.30am-4pm Facilitating Anatomy Ontology Interoperability

July 26 6.30pm-9pm Evening Workshop: Common Logic

July 27 4pm-8pm Evening Workshop: Doctoral and Post-Doctoral Consortium

- LC will attend and represent the PO. Invite other plant people?


*Plant Biology 2011, Aug 6-10th, Minneapolis, Minn

Plant Biology 2011


For inclusion on the program memory stick and in the program book, abstracts must be submitted by May 27.

Gramene will be putting together a workshop again, focusing on pathways. LC and PJ will present a PO poster.

TAIR (Kate Dreher) is organizing an Outreach Booth and we are invited to take part.



* International Botanical Congress (IBC2011)

July 23rd-30th 2011, Melbourne, Australia

Registration is open Important dates

Symposium 'Bio-Ontologies for the Plant Sciences' under the Genetics, Genomics and Bioinformatics theme, wiil be held on Thursday, 27 July, from 13:30 to 15:30.

Dennis, Alejandra, Pankaj and Ramona are planning to attend.

See IBC 2011 Bio-Ontologies Symposium wiki page for more details


Next meeting scheduled for Tuesday, July 5th, 2011 at 10am PDT/1pm EDT