https://wiki.geneontology.org/api.php?action=feedcontributions&user=Juliep&feedformat=atomGO Wiki - User contributions [en]2024-03-29T00:33:08ZUser contributionsMediaWiki 1.40.0https://wiki.geneontology.org/index.php?title=2012_Stanford_Annotation_Meeting_Logistics&diff=385782012 Stanford Annotation Meeting Logistics2011-12-13T17:50:46Z<p>Juliep: /* Attendees */</p>
<hr />
<div>=Dates=<br />
GOC Annotation Meeting at Stanford, 26-28th February, 2012. Start Sunday at 11:00am and end Tuesday at 4:00pm.<br />
<br />
=Venue=<br />
Cardinal Room in the Clubhouse (adjacent to the [http://g.co/maps/nc7zu Tresidder Student Union])<br><br />
524 Lasuen Mall, <br><br />
[http://www.stanford.edu Stanford University], <br><br />
Stanford, CA, USA.<br />
<br />
There will be a GOC group dinner on Feb 26th (Sunday) at Mike Cherry's residence.<br><br />
Address: [http://g.co/maps/rnzm9 921 Casanueva Place, Stanford]<br><br />
Time: ~5:30pm<br />
<br />
=Maps=<br />
[http://maps.stanford.edu/maps_library Stanford University maps]<br />
<br />
Meeting will be held at the Cardinal Room, Clubhouse (adjacent to the [http://g.co/maps/nc7zu Tresidder Student Union]), 524 Lasuen Mall, Stanford, CA.<br />
<br />
=Campus Shuttle (Marguerite)=<br />
Stanford University operates shuttle service ([http://transportation.stanford.edu/marguerite/MargueriteSched.shtml Shuttle Route Maps and Schedules]) from Downtown Palo Alto, Palo Alto and California Avenue CalTrain stations. To get to the Cardinal Room, get off at the BookStore stop.<br />
<br />
Realtime [http://lbre-apps.stanford.edu/transportation/stanford_ivl/ Shuttle Bus Service]. The Stanford Marguerite Shuttle is free.<br />
<br />
=Registration=<br />
#Please indicate if you will be attending this meeting in the table below. This is important so we can make the appropriate room and food arrangement. We will provide toll free telephone & WebEx for remote attendees. <br />
<br />
#No Registration Fee. The meeting will be sponsored by the Cherry Lab and the Department of Genetics, Stanford University.<br />
<br />
=Travel Reimbursement=<br />
For those seeking travel funding, please contact Ashley Stanton (Judy's assistant at MGI). <br><br />
Ashley Stanton<br><br />
ashley.stanton@jax.org<br><br />
207-288-6332<br />
<br />
=Lodging Information=<br />
Five hotels are within a 15-20 minute walk to the meeting venue. Ordered below by price per night, lowest to highest.<br />
<br />
#[http://www.hotelcalifornia.com/ Hotel California] $100/night<br />
#[http://book.cardinalhotel.com/gene Cardinal Hotel] $free while rooms last. Room charges at this hotel will be paid by the Cherry Lab.<br />
#[http://www.stanfordterraceinn.com/ Stanford Terrace Inn] $190/night<br />
#[http://specialoffers.starwoodhotels.com/SheratonPaloAlto/so.htm?PS=PS_aa_Western_Google_sheraton_palo_alto_california_011209_NAD_FM Sheraton Palo Alto Hotel] $260/night<br />
#[http://specialoffers.starwoodhotels.com/WestinPaloAlto/so.htm?PS=PS_aa_Western_Google_westin_palo_alto_ca_011209_NAD_FM Westin Palo Alto] $260/night<br />
<br />
=Airports=<br />
These airports are both convenient to Palo Alto. Their is public transit from the airports. A taxi will be expensive but there are shared vans for much less cost.<br />
<br />
* [http://flysfo.com/web/page/index.jsp San Francisco International Airport]<br />
* [http://sjc.org/ San Jose International Airport]<br />
<br />
=Attendees=<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! Hotel Name<br />
! Vegetarian (Y/N)<br />
|-<br />
|Rama Balakrishnan<br />
|Stanford University<br />
| -<br />
|Y<br />
|-<br />
|Mike Cherry<br />
|Stanford University<br />
| -<br />
|N<br />
|-<br />
|Stacia Engel<br />
|Stanford University<br />
|Hotel California<br />
|N<br />
|-<br />
|Ben Hitz<br />
|Stanford University<br />
| -<br />
|N<br />
|-<br />
|Judy Blake<br />
|Jackson Laboratory<br />
|Stanford Terrace Inn<br />
|N<br />
|-<br />
|Paola Roncaglia<br />
|GO Office at EBI<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Kimberly Van Auken<br />
|WormBase<br />
|Cardinal Hotel<br />
|Y<br />
|-<br />
|David Hill<br />
|Jackson Laboratory<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Li Ni<br />
|Jackson Laboratory<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Chris Mungall<br />
|LBL<br />
|n/a<br />
|Y<br />
|-<br />
|Susan Tweedie<br />
|FlyBase<br />
|<br />
|N<br />
|-<br />
|Doug Howe<br />
|ZFIN<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Ruth Lovering<br />
|BHF-UCL<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Emily Dimmer<br />
|UniProt-GOA <br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Yasmin Alam-Faruque<br />
|UniProt-GOA <br />
|Cardinal Hotel<br />
|Y<br />
|-<br />
|Prudence Mutowo<br />
|UniProt-GOA <br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Jane Lomax<br />
|EBI<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Claire O'Donovan<br />
|UniProt <br />
| <br />
|gluten intolerant<br />
|- <br />
|Rolf Apweiler<br />
|UniProt <br />
|<br />
|N<br />
|-<br />
|Harold Drabkin<br />
|Jackson Laboratory<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Varsha Khodiyar<br />
|BHF-UCL<br />
|Cardinal Hotel<br />
|No beef<br />
|-<br />
|Valerie Wood<br />
|PomBase<br />
|Cardinal Hotel<br />
|N<br />
|-<br />
|Tanya Berardini<br />
|TAIR<br />
| -<br />
|N<br />
|-<br />
|Donghui Li<br />
|TAIR<br />
| -<br />
|N<br />
|-<br />
|Dianna Fisk<br />
|SGD<br />
| -<br />
|N<br />
|-<br />
|Petra Fey<br />
|dictyBase<br />
|Cardinal Hotel<br />
|No red meat<br />
|-<br />
|Julie Park<br />
|SGD<br />
| -<br />
|N</div>Juliephttps://wiki.geneontology.org/index.php?title=2011_UCL_Meeting_Logistics&diff=377332011 UCL Meeting Logistics2011-10-26T17:15:02Z<p>Juliep: /* Attendees */</p>
<hr />
<div>Return to [[Consortium_Meetings]] page<br />
[[Category:Meetings]]<br />
<br />
=Questions=<br />
please contact Ruth, r.lovering@ucl.ac.uk if you have any questions/queries<br />
<br />
=Dates=<br />
The GO meeting will be begin at 9am on Monday 7th November, 2011 and end at 1pm on Wednesday 9th November, 2011, and will be held at the University College London.<br />
<br />
=Venue=<br />
Wilkins Haldane Room ([http://crf.casa.ucl.ac.uk/screenRoute.aspx?s=1019&d=187&w=False])<br />
Wilkins Building, ([http://maps.google.co.uk/maps?f=q&source=embed&hl=en&geocode=&q=WILKINS+BUILDING@51.524699,-0.13366&ie=UTF8&ll=51.524699,-0.13366&z=16])<br/><br />
University College London,<br/><br />
Gower Street,<br/><br />
London. WC1E 6BT<br />
<br />
<br />
== GOC dinner ==<br />
<br />
Monday 6:30pm<br />
<br />
Sardo <br />
<br />
47 Grafton Way<br />
<br />
http://www.sardo-restaurant.com/index.html<br />
<br />
Menu: based on the Christmas menu http://www.sardo-restaurant.com/setmenu.html<br />
Soup and Main fish course option varies, depending on seasonal supply.<br />
Additional starter: Carpaccio di Manzo (slices of beef)<br />
Main vegetarian option will be Fregola con asparagi e ricotta, (pasta with asparagus and ricotta, not the Christmas option)<br />
<br />
Vegan and Gluten free options available from the main menu, gluten free pasta option. Maybe able to have other vegetarian options too.<br />
<br />
http://www.sardo-restaurant.com/menu.html<br />
<br />
=Registration=<br />
Register by entering your name in the [http://wiki.geneontology.org/index.php/2011_UCL_Meeting_Logistics#Attendees Attendees section] below.<br />
<br />
*Registration fee to be decided (depending on number of participants). Aiming for £140, to include lunches and coffee breaks and 1 evening dinner. This will be payable by credit card the first day of the meeting. Please use the Attendees table below to register for the meeting.<br />
<br />
=Lodging Information=<br />
Please make your own Hotel reservations (see table below). The most reasonable hotels are Ibis and Premier Inn. <br />
<br />
Early booking is recommended as the prices are likely to increase closer to the time, some sites offer free cancellation options. <br />
It might be worth checking hotel costs direct from hotel versus online sites eg [[http://www.booking.com/ booking.com]] filter on bloomsbury, or [[http://www.tripadvisor.co.uk/ Tripadvisor.co.uk]]. <br />
<br />
All hotels below are within a 10-15 min walk from the meeting room. In General London is a pretty safe area, although 20 min east of UCL (around King's cross) is a red light district so I would suggest you avoid this area. None of the hotels below are in the Red Light area! Obviously there are a lot more hotels you could try.<br />
<br />
If anyone has stayed in these hotels please comment on them below.<br />
<br />
----<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Hotel Name<br />
! Cost for 3 nights<br />
! Walking time to UCL<br />
! Address <br />
! Phone number<br />
! Gym (Y/N)<br />
! Internet cost<br />
! Star rating<br />
! Noisy (Y/N)<br />
|-<br />
|[http://www.micentre.com/ MIC] fully booked?<br />
|£225<br />
|5 min<br />
|81 - 103 Euston Street, London NW1 2EZ<br />
|0207 380 0001<br />
|N<br />
|?<br />
|3<br />
|N, shouldn't be<br />
|-<br />
|[http://www.premierinn.com/en/hotel/LONEUS/london-euston Premier Inn]<br />
|£365<br />
|9 min<br />
|1 Dukes Road,London, WC1H 9PJ<br />
|0870 850 5115<br />
|N<br />
|?<br />
|3<br />
|N<br />
|-<br />
|[http://www.ibishotel.com/gb/hotel-0921-ibis-london-euston-st-pancras/index.shtml Ibis]<br />
|£335<br />
|7 min<br />
|3 Cardington Street NW1 2LW<br />
|0207 3887777<br />
|N<br />
|?<br />
|2<br />
|N&Y room dependent<br />
|-<br />
|[http://www.novotel.com/gb/hotel-5309-novotel-london-st-pancras/index.shtml Novatel]<br />
|£440 (now £520)<br />
|10 min<br />
|100 - 110 Euston Road NW1 2AJ<br />
|0207 6669000<br />
|Y<br />
|?<br />
|4<br />
|N<br />
|-<br />
|[http://www.holidayinn.com/hotels/gb/en/london/lonbl/hoteldetail Holiday Inn]<br />
|£512<br />
|11 min<br />
|Coram Street, London, WC1N 1HT<br />
|0871 9429222<br />
|Y<br />
|£5/hour<br />
|4<br />
|N<br />
|-<br />
|[http://www.londonrussellhotel.co.uk/ The Hotel Russell]<br />
|£493<br />
|12 min<br />
|1-8 Russell Square, Bloomsbury, WC1B 5BE<br />
|0870 850 5115<br />
|off site £5<br />
|£15/day<br />
|4<br />
|Y<br />
|-<br />
|[http://centrallondon.stgiles.com/default.aspx?pg=suites St Giles Hotel & Leisure Club]<br />
|£337<br />
|15 min<br />
|Bedford Avenue, Bloomsbury, WC1B 3GH<br />
|0207 300 3000<br />
|yes and pool<br />
|£10/day<br />
|3<br />
|? should be OK<br />
|-<br />
|The White Hall Hotel<br />
|£450**, only executive rooms now free £558**<br />
|12 min<br />
|2-5 Montague Street, WC1B 5BU <br />
|020 7233 7888<br />
|N<br />
|?<br />
|4<br />
|? should be OK<br />
|}<br />
<br />
(**) If you are interested in The White Hall Hotel let me know and I will book these via UCL, to get this discount price (Ruth r.lovering@ucl.ac.uk).<br />
----<br />
<br />
=Maps and Transportation=<br />
<br />
== Airports ==<br />
<br />
You can get to central London from any of the following airports, taxis will be more expensive than trains and all airports have good train services available. Once in a central London train station, either get a taxi to your hotel or the meeting or get on the tube (see information below).<br />
<br />
* Heathrow [http://www.heathrowairport.com/portal/controller/dispatcher.jsp?CiID=759c9b25f9599110VgnVCM10000036821c0a____&ChID=4504abfa784d3110VgnVCM10000036821c0a____&Ct=B2C_CT_GENERAL&CtID=448c6a4c7f1b0010VgnVCM200000357e120a____&ChPath=Home^Heathrow^General^To+and+from+Heathrow^Trains&search=true link to train information ]<br />
<br />
* Gatwick [http://www.gatwickairport.com/transport/gatwick-express/ link to train information ]<br />
<br />
* Stansted [http://www.stanstedairport.com/portal/page/Stansted%5EGeneral%5ETo+and+from+Stansted%5ETrains/a024e37e8077d110VgnVCM10000036821c0a____/448c6a4c7f1b0010VgnVCM200000357e120a____/ link to train information ]<br />
<br />
== Airport to Central London ==<br />
<br />
The meeting is in central London and is walkable from Euston, Euston Square, Warren Street, Goodge Street tube stations. Note Tottenham Court Road Tube station is closed.<br />
<br />
There is a good [http://www.tfl.gov.uk/gettingaround/1106.aspx journey planner site] <br />
<br />
=== From Heathrow: ===<br />
<br />
* Either: catch the Heathrow express train from Heathrow to Paddington, and then get a taxi, to your hotel/UCL from there, or get the tube from Paddington to Euston Square (east bound on the Hammersmith & City Line towards Baker Street or the Circle Line towards Kings Cross St Pancras). <br />
Journey time around 1 hour. Cost around £38 return, £21 single plus tube fare £4 each way (taxi cost unknown).<br />
<br />
* Or get the Piccadilly tube: from Heathrow to Green Park and change onto the Victoria Line (heading north) and either get out at Warren Street (meeting) or Euston (depending on hotel). <br />
Journey time around 1 hour 10 min. Cost around £5 single (Heathrow is zone 6).<br />
<br />
* Or taxi, there are lots of online sites suggesting the cost is around £44, each way, and will take about 40 min (but this will be traffic dependent).<br />
<br />
=== From Gatwick: ===<br />
<br />
* Either: catch the Gatwick express train from Gatwick to Victoria, and then get a taxi, to your hotel/UCL from there, or get the tube from Victoria to Warren Street (north bound on the Victoria Line). <br />
Journey time around 1 hour. Cost around £30 return, £17 single, plus tube fare £4 each way (taxi cost unknown).<br />
<br />
* Or taxi, there are lots of online sites suggesting the cost is around £60, each way, and will take about 1 hour (but this will be traffic dependent).<br />
<br />
=== From Stansted: ===<br />
<br />
* Either: catch the Stansted express train from Stansted to Liverpool Street, and then get a taxi, to your hotel/UCL from there, or get the tube from Liverpool Street to Euston Square (west bound on the Hammersmith & City Line/Metropolitan Line, or the Circle Line towards Kings Cross St Pancras). <br />
Journey time around 1 hour. Cost around £27 return, £20 single, plus tube fare £4 each way (taxi cost unknown).<br />
<br />
* Or taxi, there are lots of online sites suggesting the cost is around £45, each way, and will take about 1 hour (but this will be traffic dependent).<br />
<br />
=Meeting Agenda= <br />
<br />
The agenda can be found here: [[2011_UCL_Meeting_Agenda]]<br />
<br />
=Attendees=<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! Arrival Date/Time at Airport <br />
! Departure Date/Time from Airport<br />
! Hotel booked?<br />
! Vegetarian (Y/N)<br />
|-<br />
|Ruth Lovering <br />
|BHF-UCL<br />
|N/A<br />
|N/A<br />
|Travel from home and St Giles Monday night<br />
|N<br />
|-<br />
|Peter D'Eustachio <br />
|NYU - Reactome<br />
|6 Nov 9:25 AM LHR<br />
|12 Nov 10:25 AM LHR<br />
|Regency House 71 Gower St<br />
|N<br />
|-<br />
|Varsha Khodiyar <br />
|BHF-UCL<br />
|N/A<br />
|N/A<br />
|Travel from home and St Giles Monday night<br />
|N<br />
|-<br />
|Emily Dimmer<br />
|UniProtKB<br />
|N/A<br />
|N/A<br />
|Travel from home and Ibis Monday night<br />
|N<br />
|-<br />
|Tony Sawford<br />
|UniProtKB<br />
|N/A<br />
|N/A<br />
|Travel from home and Ibis Monday night<br />
|N<br />
|-<br />
|Jane Lomax<br />
|GO-EBI<br />
|N/A<br />
|N/A<br />
|Travel from home<br />
|N<br />
|-<br />
|Seth Carbon<br />
|BBOP-LBNL<br />
|N/A<br />
|N/A<br />
|yes<br />
|N<br />
|-<br />
|Chris Mungall<br />
|BBOP-LBNL<br />
|N/A<br />
|N/A<br />
|not yet<br />
|Y<br />
|-<br />
|Suzanna Lewis<br />
|BBOP-LBNL<br />
|N/A<br />
|N/A<br />
|yes<br />
|N<br />
|-<br />
|Paola Roncaglia<br />
|GO-EBI<br />
|N/A<br />
|N/A<br />
|Travel from home & MIC Monday night<br />
|N<br />
|-<br />
|Mike Cherry<br />
|Stanford<br />
|Nov 7, LHR, 6:50AM<br />
|Nov 10, LHR, 1:35PM<br />
|The White Hall Hotel <br />
|N<br />
|-<br />
|Judy Blake<br />
|The Jackson Laboratory<br />
|Nov 6, LHR, 9:25 AM<br />
|Nov 10, LHR, 12:05 PM<br />
|don't know yet.<br />
|N<br />
|-<br />
|Brenley McIntosh <br />
|Tx A&M - EcoliWiki<br />
|?<br />
|?<br />
|not yet<br />
|N<br />
|-<br />
|Val Wood<br />
|PomBase<br />
|n/a<br />
|n/a<br />
|TBD may stay one night<br />
|N<br />
|-<br />
|Yasmin Alam-Faruque<br />
|UniProtKB-GOA<br />
|n/a<br />
|n/a<br />
|Travel from home and Ibis Monday night<br />
|Y<br />
|-<br />
|Rebecca Foulger<br />
|GO-EBI<br />
|N/A<br />
|N/A<br />
|Travel from home & MIC on Monday night<br />
|N<br />
|-<br />
|Rama Balakrishnan<br />
|SGD, Stanford<br />
|n/a<br />
|n/a<br />
|not yet<br />
|Y (vegan if possible)<br />
|-<br />
|Stan Laulederkind<br />
|RGD<br />
|Nov 6<br />
|Nov 11<br />
|not yet<br />
|N<br />
|-<br />
|David Hill <br />
|The Jackson Laboratory<br />
|?<br />
|?<br />
|not yet<br />
|N<br />
|-<br />
|Kimberly Van Auken<br />
|WormBase, Caltech<br />
|Nov 6, LHR, 6:35am<br />
|Nov 10, LHR, 10:30am<br />
|Premier Inn<br />
|Yes, please<br />
|-<br />
|Julie Park<br />
|SGD, Stanford<br />
|N/A<br />
|Nov 10, LHR, 1:35PM<br />
|Premier Inn<br />
|N<br />
|-<br />
|Midori Harris<br />
|PomBase, Cambridge<br />
|N/A<br />
|N/A<br />
|TBD - may stay one night<br />
|N (but don't want meat every meal)<br />
|-<br />
|Tanya Berardini<br />
|TAIR<br />
|?<br />
|?<br />
|not yet<br />
|N<br />
|-<br />
|Claire O'Donovan<br />
|UniProtKB<br />
|N/A<br />
|N/A<br />
|Travel from home and Ibis Monday night<br />
|gluten-free<br />
|-<br />
|Susan Tweedie<br />
|FlyBase<br />
|N/A<br />
|N/A<br />
|not yet<br />
|N<br />
|-<br />
|Prudence Mutowo <br />
|GOA-UniProtKB<br />
|N/A<br />
|N/A<br />
|Travel from home and Ibis Monday night<br />
|no rice<br />
|-<br />
|Donghui Li<br />
|TAIR<br />
|Nov 6 LHR 11:25AM<br />
|Nov 10 LHR 01:35PM<br />
|MIC<br />
|N<br />
|-<br />
|Rachael Huntley <br />
|GOA-UniProtKB<br />
|N/A<br />
|N/A<br />
|Travel from home and Ibis Monday night<br />
|Y<br />
|-<br />
|Heiko Dietze<br />
|BBOP-LBNL<br />
|Nov 6, 11:25 am LHR<br />
|Nov 10, 1:35 pm LHR<br />
|Holiday Inn<br />
|N<br />
|-<br />
|Antonia Lock<br />
|Pombase UCL<br />
|N/A<br />
|N/A<br />
|TBD may stay one night<br />
|N<br />
|-<br />
|Alex Michell<br />
|InterPro<br />
|N/A<br />
|N/A<br />
|TBD may stay one night<br />
|N<br />
|-<br />
|Amaia Sangrador<br />
|InterPro<br />
|N/A<br />
|N/A<br />
|TBD may stay one night<br />
|N<br />
|}<br />
<br />
=Invited attendees =<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! Date presenting<br />
! Arrival Date/Time at Airport <br />
! Departure Date/Time from Airport<br />
! Hotel booked?<br />
! Vegetarian (Y/N)<br />
|-<br />
|Sandra Orchard<br />
|IntAct<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|Philippa Talmud<br />
|BHF-UCL<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Pablo Millan<br />
|IntAct<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
=Remote Attendees=<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! email (needed to set up your remote access)<br />
! Time Zone<br />
|-<br />
|Doug Howe<br />
|ZFIN<br />
|dhowe@zfin.org<br />
|PDT (UTC -7)<br />
|-<br />
|Harold Drabkin<br />
|MGI<br />
|harold.drabkin@jax.org<br />
|EST<br />
|-<br />
|Mary Dolan<br />
|MGI<br />
|mdolan@informatics.jax.org<br />
|EST<br />
|-<br />
|Alexander Diehl<br />
|University at Buffalo<br />
|addiehl@buffalo.edu<br />
|EST<br />
|}<br />
<br />
<br />
<br />
----<br />
Return to [[Consortium_Meetings]] page<br />
[[Category:Meetings]]</div>Juliephttps://wiki.geneontology.org/index.php?title=2011_UCL_Meeting_Logistics&diff=370602011 UCL Meeting Logistics2011-09-08T19:22:13Z<p>Juliep: /* Attendees */</p>
<hr />
<div>Return to [[Consortium_Meetings]] page<br />
[[Category:Meetings]]<br />
<br />
=Questions=<br />
please contact Ruth, r.lovering@ucl.ac.uk if you have any questions/queries<br />
<br />
=Dates=<br />
The GO meeting will be begin at 9am on Monday 7th November, 2011 and end at 1pm on Wednesday 9th November, 2011, and will be held at the University College London.<br />
<br />
=Venue=<br />
Wilkins Haldane Room ([http://crf.casa.ucl.ac.uk/screenRoute.aspx?s=1019&d=187&w=False])<br />
Wilkins Building, ([http://maps.google.co.uk/maps?f=q&source=embed&hl=en&geocode=&q=WILKINS+BUILDING@51.524699,-0.13366&ie=UTF8&ll=51.524699,-0.13366&z=16])<br/><br />
University College London,<br/><br />
Gower Street,<br/><br />
London. WC1E 6BT<br />
<br />
=Registration=<br />
Register by entering your name in the [http://wiki.geneontology.org/index.php/2011_UCL_Meeting_Logistics#Attendees Attendees section] below.<br />
<br />
*Registration fee to be decided (depending on number of participants). Aiming for £140, to include lunches and coffee breaks and 1 evening dinner. This will be payable by credit card the first day of the meeting. Please use the Attendees table below to register for the meeting.<br />
<br />
=Lodging Information=<br />
Please make your own Hotel reservations (see table below). The most reasonable hotels are Ibis and Premier Inn. <br />
<br />
Early booking is recommended as the prices are likely to increase closer to the time, some sites offer free cancellation options. <br />
It might be worth checking hotel costs direct from hotel versus online sites eg [[http://www.booking.com/ booking.com]] filter on bloomsbury, or [[http://www.tripadvisor.co.uk/ Tripadvisor.co.uk]]. <br />
<br />
All hotels below are within a 10-15 min walk from the meeting room. In General London is a pretty safe area, although 20 min east of UCL (around King's cross) is a red light district so I would suggest you avoid this area. None of the hotels below are in the Red Light area! Obviously there are a lot more hotels you could try.<br />
<br />
If anyone has stayed in these hotels please comment on them below.<br />
<br />
----<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Hotel Name<br />
! Cost for 3 nights<br />
! Walking time to UCL<br />
! Address <br />
! Phone number<br />
! Gym (Y/N)<br />
! Internet cost<br />
! Star rating<br />
! Noisy (Y/N)<br />
|-<br />
|Premier Inn<br />
|£365<br />
|9 min<br />
|1 Dukes Road,London, WC1H 9PJ<br />
|0870 850 5115<br />
|N<br />
|?<br />
|3<br />
|N<br />
|-<br />
|Ibis<br />
|£335<br />
|7 min<br />
|3 Cardington Street NW1 2LW<br />
|0207 3887777<br />
|N<br />
|?<br />
|2<br />
|N&Y room dependent<br />
|-<br />
|Novatel<br />
|£440<br />
|10 min<br />
|100 - 110 Euston Road NW1 2AJ<br />
|0207 6669000<br />
|Y<br />
|?<br />
|4<br />
|N<br />
|-<br />
|Holiday Inn<br />
|£512<br />
|11 min<br />
|Coram Street, London, WC1N 1HT<br />
|0871 9429222<br />
|Y<br />
|£5/hour<br />
|4<br />
|N<br />
|-<br />
|The Hotel Russell<br />
|£493<br />
|12 min<br />
|1-8 Russell Square, Bloomsbury, WC1B 5BE<br />
|0870 850 5115<br />
|off site £5<br />
|£15/day<br />
|4<br />
|Y<br />
|-<br />
|St Giles Hotel & Leisure Club<br />
|£337<br />
|15 min<br />
|Bedford Avenue, Bloomsbury, WC1B 3GH<br />
|0207 300 3000<br />
|yes and pool<br />
|£10/day<br />
|3<br />
|? should be OK<br />
|-<br />
|The White Hall Hotel<br />
|£450**<br />
|12 min<br />
|2-5 Montague Street, WC1B 5BU <br />
|020 7233 7888<br />
|N<br />
|?<br />
|4<br />
|? should be OK<br />
|}<br />
<br />
(**) If you are interested in The White Hall Hotel let me know and I will book these via UCL, to get this discount price (Ruth r.lovering@ucl.ac.uk).<br />
----<br />
<br />
=Maps and Transportation=<br />
<br />
== Airports ==<br />
<br />
You can get to central London from any of the following airports, taxis will be more expensive than trains and all airports have good train services available. Once in a central London train station, either get a taxi to your hotel or the meeting or get on the tube (see information below).<br />
<br />
* Heathrow [http://www.heathrowairport.com/portal/controller/dispatcher.jsp?CiID=759c9b25f9599110VgnVCM10000036821c0a____&ChID=4504abfa784d3110VgnVCM10000036821c0a____&Ct=B2C_CT_GENERAL&CtID=448c6a4c7f1b0010VgnVCM200000357e120a____&ChPath=Home^Heathrow^General^To+and+from+Heathrow^Trains&search=true link to train information ]<br />
<br />
* Gatwick [http://www.gatwickairport.com/transport/gatwick-express/ link to train information ]<br />
<br />
* Stansted [http://www.stanstedairport.com/portal/page/Stansted%5EGeneral%5ETo+and+from+Stansted%5ETrains/a024e37e8077d110VgnVCM10000036821c0a____/448c6a4c7f1b0010VgnVCM200000357e120a____/ link to train information ]<br />
<br />
== Airport to Central London ==<br />
<br />
The meeting is in central London and is walkable from Euston, Euston Square, Warren Street, Goodge Street tube stations. Note Tottenham Court Road Tube station is closed.<br />
<br />
There is a good [http://www.tfl.gov.uk/gettingaround/1106.aspx journey planner site] <br />
<br />
=== From Heathrow: ===<br />
<br />
* Either: catch the Heathrow express train from Heathrow to Paddington, and then get a taxi, to your hotel/UCL from there, or get the tube from Paddington to Euston Square (east bound on the Hammersmith & City Line towards Baker Street or the Circle Line towards Kings Cross St Pancras). <br />
Journey time around 1 hour. Cost around £38 return, £21 single plus tube fare £4 each way (taxi cost unknown).<br />
<br />
* Or get the Piccadilly tube: from Heathrow to Green Park and change onto the Victoria Line (heading north) and either get out at Warren Street (meeting) or Euston (depending on hotel). <br />
Journey time around 1 hour 10 min. Cost around £5 single (Heathrow is zone 6).<br />
<br />
* Or taxi, there are lots of online sites suggesting the cost is around £44, each way, and will take about 40 min (but this will be traffic dependent).<br />
<br />
=== From Gatwick: ===<br />
<br />
* Either: catch the Gatwick express train from Gatwick to Victoria, and then get a taxi, to your hotel/UCL from there, or get the tube from Victoria to Warren Street (north bound on the Victoria Line). <br />
Journey time around 1 hour. Cost around £30 return, £17 single, plus tube fare £4 each way (taxi cost unknown).<br />
<br />
* Or taxi, there are lots of online sites suggesting the cost is around £60, each way, and will take about 1 hour (but this will be traffic dependent).<br />
<br />
=== From Stansted: ===<br />
<br />
* Either: catch the Stansted express train from Stansted to Liverpool Street, and then get a taxi, to your hotel/UCL from there, or get the tube from Liverpool Street to Euston Square (west bound on the Hammersmith & City Line/Metropolitan Line, or the Circle Line towards Kings Cross St Pancras). <br />
Journey time around 1 hour. Cost around £27 return, £20 single, plus tube fare £4 each way (taxi cost unknown).<br />
<br />
* Or taxi, there are lots of online sites suggesting the cost is around £45, each way, and will take about 1 hour (but this will be traffic dependent).<br />
<br />
=Meeting Agenda= <br />
<br />
The agenda can be found here: [[2011_UCL_Meeting_Agenda]]<br />
<br />
=Attendees=<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! Arrival Date/Time at Airport <br />
! Departure Date/Time from Airport<br />
! Hotel booked?<br />
! Vegetarian (Y/N)<br />
|-<br />
|Ruth Lovering <br />
|BHF-UCL<br />
|N/A<br />
|N/A<br />
|Travel from home<br />
|N<br />
|-<br />
|Peter D'Eustachio <br />
|NYU - Reactome<br />
|?<br />
|?<br />
|not yet<br />
|N<br />
|-<br />
|Varsha Khodiyar <br />
|BHF-UCL<br />
|N/A<br />
|N/A<br />
|Travel from home<br />
|N<br />
|-<br />
|Emily Dimmer<br />
|UniProtKB<br />
|N/A<br />
|N/A<br />
|Travel from home<br />
|N<br />
|-<br />
|Jane Lomax<br />
|GO-EBI<br />
|N/A<br />
|N/A<br />
|Travel from home<br />
|N<br />
|-<br />
|Seth Carbon<br />
|Berkeley BOP<br />
|N/A<br />
|N/A<br />
|yes<br />
|N<br />
|-<br />
|Chris Mungall<br />
|BBOP<br />
|N/A<br />
|N/A<br />
|not yet<br />
|Y<br />
|-<br />
|Paola Roncaglia<br />
|GO-EBI<br />
|N/A<br />
|N/A<br />
|Travel from home<br />
|N<br />
|-<br />
|Mike Cherry<br />
|Stanford<br />
|Nov 7, LHR, 6:50AM<br />
|Nov 10, LHR, 1:35PM<br />
|The White Hall Hotel <br />
|N<br />
|-<br />
|Judy Blake<br />
|The Jackson Laboratory<br />
|Nov 6, LHR, 9:25 AM<br />
|Nov 10, LHR, 12:05 PM<br />
|don't know yet.<br />
|N<br />
|-<br />
|Brenley McIntosh <br />
|Tx A&M - EcoliWiki<br />
|?<br />
|?<br />
|not yet<br />
|N<br />
|-<br />
|Val Wood<br />
|PomBase<br />
|n/a<br />
|n/a<br />
|Travel from home<br />
|N<br />
|-<br />
|Yasmin Alam-Faruque<br />
|UniProtKB-GOA<br />
|n/a<br />
|n/a<br />
|Travel from home<br />
|Y<br />
|-<br />
|Rebecca Foulger<br />
|GO-EBI<br />
|N/A<br />
|N/A<br />
|Travel from home<br />
|N<br />
|-<br />
|Rama Balakrishnan<br />
|SGD, Stanford<br />
|n/a<br />
|n/a<br />
|not yet<br />
|Y (vegan if possible)<br />
|-<br />
|Stan Laulederkind<br />
|RGD<br />
|Nov 6<br />
|Nov 11<br />
|not yet<br />
|N<br />
|-<br />
|David Hill <br />
|The Jackson Laboratory<br />
|?<br />
|?<br />
|not yet<br />
|N<br />
|-<br />
|Kimberly Van Auken<br />
|WormBase, Caltech<br />
|?<br />
|?<br />
| not yet<br />
| Yes, please<br />
|-<br />
|Julie Park<br />
|SGD, Stanford<br />
|N/A<br />
|Nov 10, LHR, 1:35PM<br />
| not yet<br />
|N<br />
|}<br />
<br />
=Remote Attendees=<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! email (needed to set up your remote access)<br />
! Time Zone<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
<br />
<br />
----<br />
Return to [[Consortium_Meetings]] page<br />
[[Category:Meetings]]</div>Juliephttps://wiki.geneontology.org/index.php?title=2011_USC_Meeting_Logistics&diff=343862011 USC Meeting Logistics2011-04-04T16:02:20Z<p>Juliep: /* Attendees */</p>
<hr />
<div>=Dates=<br />
The GO meeting will be begin at 9am on May 19, 2011 and end at 1pm on May 21, 2011, and will be held at the University of Southern California in Los Angeles.<br />
<br />
=Venue=<br />
California Room<br/><br />
Davidson Conference Center ([http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=3415+South+Figueroa+Street,+Los+Angeles,+CA&aq=0&sll=37.0625,-95.677068&sspn=38.690438,61.435547&ie=UTF8&hq=&hnear=3415+S+Figueroa+St,+Los+Angeles,+California+90007&z=16 map])<br/><br />
University of Southern California<br/><br />
3415 South Figueroa Street<br/><br />
Los Angeles, CA 90089-0871<br />
<br />
=Registration=<br />
Register by entering your name in the Attendees section below.<br />
<br />
*There will be a registration fee to cover the breakfasts, lunches and coffee breaks, but we have not set it yet.<br />
<br />
=Lodging Information=<br />
'''Note: We will reserve the room for you to ensure the special rate, though of course you will have to pay at checkout. Just enter your hotel preference in the attendee table below.'''<br/><br />
<br />
There are two choices for lodging: downtown Los Angeles and on campus. Downtown is only a 10 min. ride away (we will arrange for shuttle service and there is also fast, cheap local transportation on the DASH). If you want to share a room, please contact Pauline Martinez at pauline.martinez@med.usc.edu.<br />
<br />
----<br />
Downtown:<br/><br />
[http://www.marriott.com/hotels/travel/laxjw-jw-marriott-hotel-los-angeles-at-la-live/ JW Marriott Los Angeles L.A. LIVE]<br/><br />
900 West Olympic Boulevard, Los Angeles, CA 90015<br/><br />
Rate: $179/night<br/><br />
----<br />
Campus:<br/><br />
[http://www.radisson.com/los-angeles-hotel-ca-90007/cafiguer Radisson Los Angeles at USC]<br/><br />
3540 S. Figueroa Street, Los Angeles, CA 90007<br/><br />
Rate: $144/night<br/><br />
----<br />
<br />
=Maps and Transportation=<br />
==Airport to Hotel==<br />
* LA taxis have a flat rate to downtown (not the USC campus) of $46.50 (not including tip)<br />
* Prime Time Shuttle<br />
** phone 1(800) 733-8267<br />
** USC rate to any USC location, including downtown: $13.50 per person<br />
==Downtown Hotel to USC Campus==<br />
* We will arrange for a shuttle if enough people stay downtown<br />
* The [http://www.ladottransit.com/dash/routes/downtown/downtown.php DASH bus, route F] runs every 10 min. on weekdays and costs 35 cents.<br />
<br />
=To do=<br />
Coming soon.<br />
<br />
=Meeting Agenda= <br />
<br />
The agenda can be found here: [[2011_USC_Meeting_Agenda]]<br />
<br />
=Attendees=<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! Arrival Date/Time from Airport <br />
! Departure Date/Time to Airport<br />
! Hotel pref. (Downtown/Campus)<br />
! Vegetarian (Y/N)<br />
|-<br />
| Paul Thomas<br />
| USC/PANTHER<br />
| N/A<br />
| N/A<br />
| Downtown<br />
| N<br />
|-<br />
| Paul Sternberg<br />
| Caltech/Wormbase<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Suzi Lewis<br />
| LBNL<br />
|<br />
|<br />
|Downtown Marriott <br />
|<br />
|-<br />
| Mike Cherry<br />
| Stanford/SGD<br />
| 1900 / May 18<br />
| 1500 / May 21<br />
| Downtown Marriott<br />
| N<br />
|-<br />
| Judy Blake<br />
| Jackson Laboratory/MGI<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
| Rama Balakrishnan<br />
| SGD, Stanford University<br />
| May 18<br />
| May 21<br />
| Campus<br />
| Y<br />
|-<br />
<br />
| Valerie Wood<br />
| PomBase, Cambridge University<br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| Doug Howe<br />
| ZFIN, U. Oregon<br />
| May 18<br />
| May 22<br />
| Campus (4 nights)<br />
| N<br />
|-<br />
| David Hill<br />
| Jackson Laboratory/MGI<br />
| May 18th 1:36PM<br />
| May 21st 11:00PM<br />
|<br />
| N<br />
|-<br />
| Harold Drabkin<br />
| Jackson Laboratory/MGI/PRO<br />
| May 18 tbd<br />
| May 21 tbd<br />
|<br />
| N<br />
|-<br />
| Eurie Hong<br />
| Stanford/SGD<br />
| <br />
| <br />
| Downtown<br />
| N<br />
|-<br />
| Tanya Berardini<br />
| TAIR<br />
| May 18<br />
| May 20<br />
| Campus (2 nights)<br />
| N<br />
|-<br />
| Susan Tweedie<br />
| FlyBase<br />
| May 18 13:40<br />
| May 22 17:45<br />
| <br />
| N<br />
|-<br />
| Julie Park<br />
| Stanford/SGD<br />
| May 18 <br />
| May 21 <br />
| Downtown<br />
| N<br />
|}<br />
<br />
=Remote Attendees=<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! email (needed to set up your remote access)<br />
! Time Zone<br />
|-<br />
|Anushya Muruganujan<br />
|USC/PANTHER<br />
|muruganu@usc.edu<br />
|PDT<br />
|-<br />
|Peter D'Eustachio<br />
|NYU / Reactome<br />
|deustp01@nyumc.org<br />
|EDT<br />
|-<br />
|Mike Livstone (Friday only)<br />
|Princeton/P-POD<br />
|livstone@genomics.princeton.edu<br />
|EDT<br />
|-<br />
|}<br />
<br />
<br />
----<br />
Return to [[Consortium_Meetings]] page<br />
[[Category:Meetings]]</div>Juliephttps://wiki.geneontology.org/index.php?title=Wnt_signaling_Pathway_(Archived)&diff=29332Wnt signaling Pathway (Archived)2010-07-20T23:36:21Z<p>Juliep: /* Annotation targets/progress table (BATCH 1) */</p>
<hr />
<div>==Project leaders==<br />
Varsha Khodiyar, Suzi Lewis<br />
==Justification (Impact and significance)==<br />
Wnt proteins form a family of highly conserved secreted signaling molecules that regulate cell-to-cell interactions during embryogenesis. Insights into the mechanisms of Wnt action have emerged from several systems: genetics in Drosophila and Caenorhabditis elegans; biochemistry in cell culture and ectopic gene expression in Xenopus embryos. Mutations in Wnt genes or Wnt pathway components lead to specific developmental defects, while various human diseases, including cancer, are caused by abnormal Wnt signaling. As currently understood, Wnt proteins bind to receptors of the Frizzled and LRP families on the cell surface. Through several cytoplasmic relay components, the signal is transduced to beta-catenin, which enters the nucleus and forms a complex with TCF to activate transcription of Wnt target gene (text from [http://www.stanford.edu/~rnusse/wntwindow.htm]<br />
==Range of species in which the pathway is found==<br />
<br />
Each reference genome species is represented in at least 1 of the panther families, except for E.coli which has no gene products in any of these families.<br />
<br />
==Species experimentally studied ==<br />
==Possible experts==<br />
make sure to represent mammals, but also : fly, zebra fish, other models??<br />
==Ontology status==<br />
==Time frame of the project==<br />
* June - August 2010: Primary annotations<br />
* November - December 2010: Tree Annotation<br />
<br />
==Background reading==<br />
[[image:220px-WNTPathway.png |right| Wnt receptor]]<br />
<br />
* http://en.wikipedia.org/wiki/Wnt_signaling_pathway<br />
* http://www.stanford.edu/~rnusse/wntwindow.html (note that there are some errors in their phylogenetic trees)<br />
<br />
==Families to annotate (BATCH 1) ==<br />
* Pascale and Paul have reviewed the trees, and there are no obvious problems<br />
Summary: http://amigo-sven.princeton.edu/cgi-bin/amigo/phylotree?mode=index&id=PTHR10202+PTHR16505+PTHR10373+PTHR12027+PTHR11309+PTHR10878+PTHR10845+PTHR10529+PTHR23315+PTHR12607<br />
<br />
# PTHR12027 wnt: 6 distinct subfamilies<br />
#*Secreted signalling proteins, implicated in regulation of cell fate and patterning during embryogenesis.<br />
#PTHR23315: beta-catenin and the subtree to which beta-catenin belongs seems okay<br />
#PTHR10845:AN318: Axin <br />
#*Subfamily of the RGS (Regulators of G-protein signaling)<br />
# PTHR11309 frizzled: 7 distinct subfamilies<br />
#* Transmembrane proteins that are receptors for the Wnt signaling proteins.<br />
#* Proteins that are related to the frizzled protein family in that they also contain the Wnt-binding site, but SFRP family are secreted and not membrane bound. We will include these as they are in the same family<br />
#PTHR10878: Disheveled<br />
#*Cytoplasmic phosphoproteins, role in cytoplasmic signal transduction of Wnt signaling pathway. Regulation of beta-catenin stability.<br />
#PTHR10529: LRP<br />
#*Probable co-receptor together with Frizzled for Wnt. Rather large family, so only annotating LRP5 and LRP6 for this project.<br />
# PTHR12607 ADENOMATOUS POLYPOSIS COLI PROTEIN<br />
#* Intracellular cytoskeleton, role in structure of adherens junction. Negative regulator of Wnt signaling, degrades CTNNB1<br />
# PTHR10373 LYMPHOID ENHANCER-BINDING FACTOR 1<br />
#* Participates in the Wnt signaling pathway. Activates transcription of target genes in the presence of CTNNB1 and EP300.<br />
<br />
== Annotation targets/progress table (BATCH 1) ==<br />
<br />
<b><font color ="red"> Note that the panther subfamilies can be accessed by searching the Panther website: http://www.pantherdb.org/ <br> or directly using the following example URL: <br><br />
http://www.pantherdb.org/panther<br>/family.do?clsAccession=PTHR10373:SF11<br />
</font></b><br />
<br />
{| {{table border ="1"}}<br />
| align="center" style="background:#f0f0f0;"|'''Active annotation period (Dates)'''<br />
| align="center" style="background:#f0f0f0;"|'''Panther Family'''<br />
| align="center" style="background:#f0f0f0;"|'''Gene Symbol (Human protein ID)'''<br />
| align="center" style="background:#f0f0f0;"|'''PAINT due to begin'''<br />
| align="center" style="background:#f0f0f0;"|'''GOA / BHF-UCL'''<br />
| align="center" style="background:#f0f0f0;"|'''MGI'''<br />
| align="center" style="background:#f0f0f0;"|'''RGD'''<br />
| align="center" style="background:#f0f0f0;"|'''ZFIN'''<br />
| align="center" style="background:#f0f0f0;"|'''Wormbase'''<br />
| align="center" style="background:#f0f0f0;"|'''Flybase'''<br />
| align="center" style="background:#f0f0f0;"|'''Agbase'''<br />
| align="center" style="background:#f0f0f0;"|'''Dictybase'''<br />
| align="center" style="background:#f0f0f0;"|'''TAIR'''<br />
| align="center" style="background:#f0f0f0;"|'''SGD'''<br />
| align="center" style="background:#f0f0f0;"|'''Pombase'''<br />
|-<br />
| Week 1-2 (1st-16th July)||PTHR12027:SF15, PTHR12027:SF18, PTHR12027:SF25|| wnt1 (P04628) wnt3 (P56703) ||Week 3||8th July [VK] || ||done||done|| || || || none||none||none||none<br />
|-<br />
| ||PTHR12027:SF21, PTHR12027:SF23||wnt2 (P09544) wnt5 (P41221, Q9H1J7) ||Week 3 ||14th July [RL,RH] ||done||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF4, PTHR12027:SF6, PTHR12027:SF7, PTHR12027:SF19|| wnt4 (P56705) wnt8 (Q9H1J5, Q93098) wnt9 (O14904, O14905) wnt11 (O96014) ||Week 3 || 15th July [VK,YAF] || ||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF14|| wnt6 (Q9Y6F9) ||Week 3 ||9th July [RL] ||done||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF16, PTHR12027:SF22, PTHR12027:SF26|| wnt7 (O00755, P56706) wnt16 (Q9UBV4) ||Week 3 ||13th July [RL,YAF] ||done||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF11|| wnt10 (WNT10A Q9GZT5, WNT10B O00744) ||Week 3||2nd July [RL]|| ||done||done|| || || || none||none||none||none <br />
|-<br />
| Week 3 (17th-23rd July)||PTHR23315|| CTNNB1 (P35222)||Week 5|| ||done||done||done|| || || || none||done||done||30th June [VW]<br />
|-<br />
| ||PTHR16505|| CTNNBIP1 (Q9NSA3) ||Week 5|| ||done||done||done|| || none|| || none||none||none||none<br />
|-<br />
| Week 4 (24th-31st July)|| PTHR10845:SF11|| Axin1 (O15169) ||Week 6|| || ||done||done|| || || || || ||none||30th June [VW]<br />
|-<br />
| ||PTHR10845:SF103|| Axin2 (Q9Y2T1) ||Week 6 || || ||done||done|| || || || || ||none|| 30th June [VW]<br />
|-<br />
| Week 5-6 (1st-13th August)|| PTHR11309:SF31, PTHR11309:SF32, PTHR11309:SF33, PTHR11309:SF34, PTHR11309:SF49|| fzd1 (Q9UP38) fzd2 (Q14332) fzd7 (O75084) ||Week 7|| || || || || || || || none||none||none||none<br />
|-<br />
| ||PTHR11309:SF28, PTHR11309:SF29|| fzd5 (Q13467) fzd8 (Q9H461) ||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF23|| fzd4 (Q9ULV1) ||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF24|| fzd10 (Q9ULW2) ||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF25|| fzd9 (O00144) fzd3 (Q9NPG1)||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF21|| fzd6 (O60353)||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| Week 6-7 (14th-20th August)|| PTHR11309:SF7, PTHR11309:SF10|| SFRP1 (Q8N474) SFRP2 (Q96HF1) SFRP4 (Q6FHJ7) ||Week 8|| || || || || || || || none||none||none||none<br />
|-<br />
| ||PTHR11309:SF10|| SFRP5 (Q5T4F7) ||Week 8|| || || || || || || || none||none||none||none <br />
|-<br />
| Week 8 (21st-31st August)|| PTHR10878|| dvl1 (O14640) dvl2 (O14641) dvl3 (Q92997) ||Week 9|| || || || || || || || none||none||none||none<br />
|-<br />
| Week 9-10 (1st-10th September)|| PTHR10529:SF108|| LRP5 (O75197) ||Week 11|| || || || || || || || ||none||none||none<br />
|-<br />
| || PTHR10529:SF109|| LRP6 (O75581) ||Week 11|| || || || || || || || ||none||none||none<br />
|-<br />
| Week 11 (11th-17th September)|| PTHR12607|| APC (P25054) APC2 (O95996) || Week 12 || || || || || none ||none || || none||none||none||none<br />
|-<br />
| || PTHR10373:SF11|| LEF1 (Q9UJU2)|| Week 13 || || || || || || || || none||none||none||none<br />
|-<br />
| Week 12-14 (18th September - 8th October)|| Review annotations with respect to PAINT inferences)|| || || || || || || || || || || || ||<br />
|-<br />
|}<br />
<br />
<br />
The aim is to provide good annotation coverage for these Panther families across the 11 species in a 3-month time frame, followed by a 2-week period of annotation review in response to PAINT inferences.<br />
<br />
# Each family is annotated in the order listed above, for a maximum of 2 weeks.<br />
# The priority is to annotate the gene products listed above, and orthologs in all species. Where the subfamily is shown, this means that the Panther family is very large and so MODs are asked to focus on the specific subfamilies shown. MODs are free to annotate to members of the larger family if they have time and wish to do so.<br />
# We are asking MODs to sign off each line of this table, so we can confirm that the whole clade has been annotated across all species. <br />
# PAINT curation will take place using as many annotations as available for each species, at the end of the specified annotation 2-week period. At this point they will deposit a GAF file in the CVS repository (http://cvsweb.geneontology.org/cgi-bin/cvsweb.cgi/go/gene-associations/submission/paint/#dirlist). It is only necessary that the annotations for the proteins/genes worked on in this period be provided.<br />
# PAINT inferences will begin to be sent back to MODs for checking as soon as they have been completed. We have allowed 2 weeks at the end of the annotation period for PAINT inference checking; however, MODs will be able to check the inferences earlier than this if they wish.<br />
<br />
==Other families to annotate (Prioritization TBD) ==<br />
# PTHR10878:SF4 DIXIN (DIX DOMAIN-CONTAINING PROTEIN 1)(COILED-COIL PROTEIN DIX1)<br />
#* dixdc1 (Q80Y83)<br />
# PTHR22844:SF10 F-BOX AND WD-40 DOMAIN PROTEIN<br />
#* BTRC (Q9Y297) Mediates the ubiquitination of CTNNB1 and participates in Wnt signaling<br />
#* FBXW11 (Q9UKB1) mediates the ubiquitination of CTNNB1 and participates in Wnt signaling<br />
# PTHR13164:SF3 Ubiquitin-mediated degradation of beta-catenin (CTNNB1)<br />
#* CACYBP (Q9HB71)<br />
# PTHR12011:SF67 and PTHR25100:SF76 CALCITONIN RECEPTOR <br />
#* CALCR (P30988)<br />
# PTHR24347:SF64: long-term potentiation and neurotransmitter release<br />
#* CAMK2A (Q9UQM7)<br />
#* CAMK2B (Q13554)<br />
#* CAMK2D (Q13557)<br />
#* CAMK2G (Q13555)<br />
# PTHR12015:SF30 SMALL INDUCIBLE CYTOKINE A<br />
#* CCL2 P13500<br />
# PTHR10177:SF67 G1/S-SPECIFIC CYCLIN-D1<br />
#* CCND1 (P24385)<br />
#* CCND2 (P30279)<br />
#* CCND3 (P30281)<br />
# PTHR15273:SF0<br />
#* CER1 (O95813)<br />
# PTHR10799:SF46 CHROMODOMAIN-HELICASE-DNA-BINDING PROTEIN 8 (CHD-8)<br />
#* CHD8 (Q9HCK8) negative regulator of Wnt signaling pathway by regulating beta-catenin (CTNNB1) activity<br />
# PTHR24344:SF26<br />
#* CHEK2 (O96017)<br />
# PTHR23056:SF4 CALCINEURIN B SUBUNIT<br />
#* CHP (Q99653)<br />
#* CHP2 (O43745)<br />
#* PPP3R1 P63098<br />
#* PPP3R2 Q96LZ3<br />
# PTHR24023:SF127<br />
#* COL1A1 (P02452)<br />
#* COL1A2 (P08123)<br />
# PTHR13808:SF0<br />
#* CREBBP (Q92793) part of canonical Wnt pathway<br />
#* EP300 (Q09472)<br />
# PTHR11909:SF20<br />
#* CSNK1A1 (P48729) Participates in Wnt signaling<br />
#* CSNK1A1L (Q8N752) Participates in Wnt signaling<br />
#* CSNK1E (P49674) Participates in Wnt signaling<br />
# PTHR24054:SF37<br />
#* CSNK2A1 (P68400) Participates in Wnt signaling<br />
#* CSNK2A2 (P19784) Participates in Wnt signaling<br />
# PTHR11740:SF0<br />
#* CSNK2B (P67870) Participates in Wnt signaling<br />
# PTHR10996:SF11 C-TERMINAL-BINDING PROTEIN 1<br />
#* CTBP1 (Q13363) Canonical Wnt signaling pathway. <br />
#* CTBP2 (P56545)<br />
# PTHR11932:SF19 CULLIN 1<br />
#* CUL1 (Q13616) direct ubiquitination of CTNNB1 and participate in Wnt signaling<br />
# PTHR13419:SF0<br />
#* CXXC4 (Q9H2H0) negative regulator of the Wnt signaling pathway via its interaction with DVL1<br />
# PTHR23213:SF44<br />
#* DAAM1 (Q9Y4D1) mediates Wnt-induced Dvl-Rho complex formation<br />
#* DAAM2 (Q86T65)<br />
# PTHR10568:SF4 DICKKOPF-RELATED PROTEIN 1<br />
#* DKK1 (O94907) Antagonizes canonical Wnt signaling by inhibiting LRP5/6 interaction with Wnt<br />
#* DKK2 (Q9UBU2) Antagonizes canonical Wnt signaling by inhibiting LRP5/6 interaction with Wnt<br />
# PTHR12113:SF2<br />
#* DKK4 (Q9UBP4) Antagonizes canonical Wnt signaling by inhibiting LRP5/6 interaction with Wnt<br />
#PTHR11371:SF7 DEOXYRIBONUCLEASE I<br />
#* DNASE1 (P24855)<br />
# PTHR23351 FOS-RELATED ANTIGEN 1<br />
#* FOSL1 (P15407)<br />
# PTHR15277<br />
#* FRAT1 (Q92837) Positively regulates the Wnt signaling pathway by stabilizing beta-catenin through the association with GSK-3<br />
#* FRAT2 (O75474) Positively regulates the Wnt signaling pathway by stabilizing beta-catenin through the association with GSK-3.<br />
# PTHR24057<br />
#* GSK3B (P49841) Participates in the Wnt signaling pathway.<br />
# PTHR10082 INTEGRIN BETA-3<br />
#* ITGB3 (P05106)<br />
# PTHR11462 TRANSCRIPTION FACTOR C-JUN<br />
#* JUN (P05412) Presenilin action in Notch and Wnt signaling. <br />
# ??<br />
#* MAP3K7 O43318 Noncanonical Wnt signaling pathway. <br />
# PTHR24055 <br />
#* MAPK10 P53779<br />
#* MAPK8 P45983<br />
#* MAPK9 P45984<br />
# PTHR11501 MICROTUBULE-ASSOCIATED PROTEIN TAU<br />
#* MAPT P10636<br />
# PTHR10201 MATRILYSIN<br />
#* MMP7 P09237<br />
# PTHR11514 MYC PROTO-ONCOGENE PROTEIN<br />
#* MYC P01106 Canonical Wnt signaling pathway. <br />
# PTHR12533 <br />
#* NFAT5 O94916<br />
#* NFATC1 O95644<br />
#* NFATC2 Q13469 Noncanonical Wnt signaling pathway. <br />
#* NFATC3 Q12968<br />
#* NFATC4 Q14934<br />
# PTHR22611<br />
#* NKD1 Q969G9 Cell autonomous antagonist of the canonical Wnt signaling pathway.<br />
#* NKD2 Q969F2 Cell autonomous antagonist of the canonical Wnt signaling pathway.<br />
# PTHR24055<br />
#* NLK Q9UBE8 Acts downstream of MAP3K7 and HIPK2 to negatively regulate the canonical Wnt/beta-catenin signaling pathway<br />
# PTHR24214<br />
#* PDLIM4 P50479<br />
# PTHR10336 1-PHOSPHATIDYLINOSITOL-4,5-BISPHOSPHATE PHOSPHODIESTERASE BETA-1<br />
#* PLCB1 Q9NQ66<br />
#* PLCB2 Q00722<br />
#* PLCB3 Q01970<br />
#* PLCB4 Q15147<br />
# PTHR13906 PORCUPINE<br />
#* PORCN Q9H237 Modulates the processing of Wnt proteins. <br />
# PTHR24082<br />
#* PPARD Q03181 Presenilin action in Notch and Wnt signaling. <br />
#* VDR P11473<br />
# PTHR11668 SERINE/THREONINE PROTEIN PHOSPHATASE PP2A<br />
#* PPP2CA P67775 Regulation of Wnt receptor signaling pathway<br />
#* PPP2CB P62714 Signaling by Wnt. <br />
#* PPP3CA Q08209<br />
#* PPP3CB P16298<br />
#* PPP3CC P48454<br />
# PTHR10648 SERINE/THREONINE-PROTEIN PHOSPHATASE 2A 65 KDA REGULATORY SUBUNIT A ALPHA ISOFORM<br />
#* PPP2R1A P30153 regulation of Wnt receptor signaling pathway<br />
#* PPP2R1B P30154 Signaling by Wnt. <br />
# PTHR10257 SERINE/THREONINE-PROTEIN PHOSPHATASE 2A 56 KDA REGULATORY SUBUNIT ALPHA ISOFORM<br />
#* PPP2R5A Q15172 Signaling by Wnt. <br />
#* PPP2R5B Q15173 Signaling by Wnt. <br />
#* PPP2R5C Q13362 Signaling by Wnt. <br />
#* PPP2R5D Q14738 Canonical Wnt signaling pathway. <br />
#* PPP2R5E Q16537<br />
# PTHR24218<br />
#* PRICKLE1 Q96MT3<br />
#* PRICKLE2 Q7Z3G6<br />
# PTHR24353<br />
#* PRKACA P17612<br />
#* PRKACB P22694<br />
#* PRKACG P22612<br />
# PTHR24355<br />
#* RPS6KA3 Q7Z2J4<br />
# PTHR24357<br />
#* PRKCA P17252<br />
#* PRKCB P05771<br />
#* PRKCG P05129<br />
# PTHR24353<br />
#* PRKX P51817<br />
# PTHR10202:SF7 PRESENILIN-1 *Former RefGenome target<br />
#* PSEN1 P49768 increases the pool of cytoplasmic beta-catenin, thus negatively regulating Wnt signaling<br />
# PTHR11599 PROTEASOME SUBUNIT ALPHA TYPE 1<br />
#* PSMA1 P25786 Signaling by Wnt. <br />
#* PSMA2 P25787 Signaling by Wnt. <br />
#* PSMA3 P25788 Signaling by Wnt. <br />
#* PSMA4 P25789 Signaling by Wnt. <br />
#* PSMA5 P28066 Signaling by Wnt. <br />
#* PSMA6 P60900 Signaling by Wnt. <br />
#* PSMA7 O14818 Signaling by Wnt. <br />
#* PSMB1 P20618 Signaling by Wnt. <br />
#* PSMB10 P40306 Signaling by Wnt. <br />
#* PSMB2 P49721 Signaling by Wnt. <br />
#* PSMB3 P49720 Signaling by Wnt. <br />
#* PSMB4 P28070 Signaling by Wnt. <br />
#* PSMB5 P28074 Signaling by Wnt. <br />
#* PSMB6 P28072 Signaling by Wnt. <br />
#* PSMB7 Q99436 Signaling by Wnt. <br />
#* PSMB8 P28062 Signaling by Wnt. <br />
#* PSMB9 P28065 Signaling by Wnt. <br />
# PTHR23073 26S PROTEASE REGULATORY SUBUNIT 4<br />
#* PSMC1 P62191 Signaling by Wnt. <br />
#* PSMC2 P35998 Signaling by Wnt. <br />
#* PSMC3 P17980 Signaling by Wnt. <br />
#* PSMC4 P43686 Signaling by Wnt. <br />
#* PSMC5 P62195 Signaling by Wnt. <br />
#* PSMC6 P62333 Signaling by Wnt. <br />
# PTHR10943 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 1 <br />
#* PSMD1 Q99460 Signaling by Wnt. <br />
# PTHR24199<br />
#* PSMD10 O75832 Signaling by Wnt. <br />
# PTHR10678 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 11<br />
#* PSMD11 O00231 Signaling by Wnt. <br />
# PTHR10855 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 12<br />
#* PSMD12 O00232 Signaling by Wnt. <br />
# PTHR10539 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 13<br />
#* PSMD13 Q9UNM6 Signaling by Wnt. <br />
# PTHR10410 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 14<br />
#* PSMD14 O00487 Signaling by Wnt. <br />
# PTHR10943 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 2 <br />
#* PSMD2 Q13200 Signaling by Wnt. <br />
# PTHR10758 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 3<br />
#* PSMD3 O43242 Signaling by Wnt. <br />
# PTHR10223 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 4<br />
#* PSMD4 P55036 Signaling by Wnt. <br />
# PTHR13554 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 5<br />
#* PSMD5 Q16401 Signaling by Wnt. <br />
# PTHR14145 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 6<br />
#* PSMD6 Q15008 Signaling by Wnt. <br />
# PTHR10540 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 7<br />
#* PSMD7 P51665 Signaling by Wnt. <br />
# PTHR12387<br />
#* PSMD8 P48556 Signaling by Wnt. <br />
# PTHR12651<br />
#* PSMD9 O00233 Signaling by Wnt. <br />
# PTHR10660 PROTEASOME ACTIVATOR COMPLEX SUBUNIT 1<br />
#* PSME1 Q06323 Signaling by Wnt. <br />
#* PSME2 Q9UL46 Signaling by Wnt. <br />
#* PSME3 P61289 Signaling by Wnt. <br />
# PTHR13266<br />
#* PSMF1 Q92530 Signaling by Wnt. <br />
# PTHR19134 PROTEIN TYROSINE PHOSPHATASE N11 (SHP2)<br />
#* PTPN11 Q06124<br />
# PTHR24072<br />
#* RAC1 P63000<br />
#* RAC2 P15153<br />
#* RAC3 P60763<br />
#* RHOA P61586<br />
# PTHR13742 RETINOBLASTOMA-ASSOCIATED PROTEIN<br />
#* RB1 P06400<br />
# PTHR11210:SF2 RING FINGER 1<br />
#* RBX1 P62877<br />
# PTHR22988 RHO-ASSOCIATED, COILED-COIL CONTAINING PROTEIN KINASE<br />
#* ROCK1 Q13464<br />
#* ROCK2 O75116<br />
# PTHR10666 UBIQUITIN (RIBOSOMAL PROTEIN L40)<br />
#* RPS27A P62988 Signaling by Wnt. <br />
# PTHR11093<br />
#* RUVBL1 Q9Y265<br />
# PTHR12606<br />
#* SENP2 Q9HC62 down-regulate CTNNB1 levels and thereby modulate the Wnt pathway<br />
# PTHR11165 SKP1-RELATED<br />
#* SKP1 P63208 Signaling by Wnt. <br />
# PTHR13703 SMAD<br />
#* SMAD1 Q15797<br />
#* SMAD2 Q15796 <br />
#* SMAD3 P84022<br />
#* SMAD4 Q13485 Canonical Wnt signaling pathway. <br />
# PTHR23113 RAS GTP EXCHANGE FACTOR, SON OF SEVENLESS<br />
#* SOS1 Q07889<br />
# PTHR10270 TRANSCRIPTION FACTOR SOX-17<br />
#* SOX17 Q9H6I2 negative regulation of Wnt receptor signaling pathway through beta-catenin<br />
# PTHR11267 BRACHYURY <br />
#* T O15178<br />
# PTHR22846 TRANSDUCIN BETA-LIKE 1<br />
#* TBL1X O60907 Wnt receptor signaling pathway through beta-catenin<br />
#* TBL1XR1 Q9BZK7 Wnt receptor signaling pathway through beta-catenin<br />
#* TBL1Y Q9BQ87<br />
# PTHR10373 TRANSCRIPTION FACTOR 7 <br />
#* TCF7 P36402 Wnt signaling pathway<br />
#* TCF7L1 Q9HCS4 Participates in the Wnt signaling pathway. <br />
#* TCF7L2 Q9NQB0 Participates in the Wnt signaling pathway <br />
# PTHR11447 CELLULAR TUMOR ANTIGEN P53 *Former RefGenome target<br />
#* TP53 P04637<br />
# PTHR11371:SF7 DEOXYRIBONUCLEASE I<br />
#* TRAP1 P24855<br />
# PTHR20886<br />
#* VANGL1 Q8TAA9<br />
#* VANGL2 Q9ULK5<br />
# PTHR15160<br />
#* VHL P40337<br />
# PTHR24838<br />
#* WIF1 Q9Y5W5 Binds to WNT proteins and inhibits their activities.</div>Juliephttps://wiki.geneontology.org/index.php?title=Wnt_signaling_Pathway_(Archived)&diff=29329Wnt signaling Pathway (Archived)2010-07-20T22:58:52Z<p>Juliep: /* Annotation targets/progress table (BATCH 1) */</p>
<hr />
<div>==Project leaders==<br />
Varsha Khodiyar, Suzi Lewis<br />
==Justification (Impact and significance)==<br />
Wnt proteins form a family of highly conserved secreted signaling molecules that regulate cell-to-cell interactions during embryogenesis. Insights into the mechanisms of Wnt action have emerged from several systems: genetics in Drosophila and Caenorhabditis elegans; biochemistry in cell culture and ectopic gene expression in Xenopus embryos. Mutations in Wnt genes or Wnt pathway components lead to specific developmental defects, while various human diseases, including cancer, are caused by abnormal Wnt signaling. As currently understood, Wnt proteins bind to receptors of the Frizzled and LRP families on the cell surface. Through several cytoplasmic relay components, the signal is transduced to beta-catenin, which enters the nucleus and forms a complex with TCF to activate transcription of Wnt target gene (text from [http://www.stanford.edu/~rnusse/wntwindow.htm]<br />
==Range of species in which the pathway is found==<br />
<br />
Each reference genome species is represented in at least 1 of the panther families, except for E.coli which has no gene products in any of these families.<br />
<br />
==Species experimentally studied ==<br />
==Possible experts==<br />
make sure to represent mammals, but also : fly, zebra fish, other models??<br />
==Ontology status==<br />
==Time frame of the project==<br />
* June - August 2010: Primary annotations<br />
* November - December 2010: Tree Annotation<br />
<br />
==Background reading==<br />
[[image:220px-WNTPathway.png |right| Wnt receptor]]<br />
<br />
* http://en.wikipedia.org/wiki/Wnt_signaling_pathway<br />
* http://www.stanford.edu/~rnusse/wntwindow.html (note that there are some errors in their phylogenetic trees)<br />
<br />
==Families to annotate (BATCH 1) ==<br />
* Pascale and Paul have reviewed the trees, and there are no obvious problems<br />
Summary: http://amigo-sven.princeton.edu/cgi-bin/amigo/phylotree?mode=index&id=PTHR10202+PTHR16505+PTHR10373+PTHR12027+PTHR11309+PTHR10878+PTHR10845+PTHR10529+PTHR23315+PTHR12607<br />
<br />
# PTHR12027 wnt: 6 distinct subfamilies<br />
#*Secreted signalling proteins, implicated in regulation of cell fate and patterning during embryogenesis.<br />
#PTHR23315: beta-catenin and the subtree to which beta-catenin belongs seems okay<br />
#PTHR10845:AN318: Axin <br />
#*Subfamily of the RGS (Regulators of G-protein signaling)<br />
# PTHR11309 frizzled: 7 distinct subfamilies<br />
#* Transmembrane proteins that are receptors for the Wnt signaling proteins.<br />
#* Proteins that are related to the frizzled protein family in that they also contain the Wnt-binding site, but SFRP family are secreted and not membrane bound. We will include these as they are in the same family<br />
#PTHR10878: Disheveled<br />
#*Cytoplasmic phosphoproteins, role in cytoplasmic signal transduction of Wnt signaling pathway. Regulation of beta-catenin stability.<br />
#PTHR10529: LRP<br />
#*Probable co-receptor together with Frizzled for Wnt. Rather large family, so only annotating LRP5 and LRP6 for this project.<br />
# PTHR12607 ADENOMATOUS POLYPOSIS COLI PROTEIN<br />
#* Intracellular cytoskeleton, role in structure of adherens junction. Negative regulator of Wnt signaling, degrades CTNNB1<br />
# PTHR10373 LYMPHOID ENHANCER-BINDING FACTOR 1<br />
#* Participates in the Wnt signaling pathway. Activates transcription of target genes in the presence of CTNNB1 and EP300.<br />
<br />
== Annotation targets/progress table (BATCH 1) ==<br />
<br />
<b><font color ="red"> Note that the panther subfamilies can be accessed by searching the Panther website: http://www.pantherdb.org/ <br> or directly using the following example URL: <br><br />
http://www.pantherdb.org/panther<br>/family.do?clsAccession=PTHR10373:SF11<br />
</font></b><br />
<br />
{| {{table border ="1"}}<br />
| align="center" style="background:#f0f0f0;"|'''Active annotation period (Dates)'''<br />
| align="center" style="background:#f0f0f0;"|'''Panther Family'''<br />
| align="center" style="background:#f0f0f0;"|'''Gene Symbol (Human protein ID)'''<br />
| align="center" style="background:#f0f0f0;"|'''PAINT due to begin'''<br />
| align="center" style="background:#f0f0f0;"|'''GOA / BHF-UCL'''<br />
| align="center" style="background:#f0f0f0;"|'''MGI'''<br />
| align="center" style="background:#f0f0f0;"|'''RGD'''<br />
| align="center" style="background:#f0f0f0;"|'''ZFIN'''<br />
| align="center" style="background:#f0f0f0;"|'''Wormbase'''<br />
| align="center" style="background:#f0f0f0;"|'''Flybase'''<br />
| align="center" style="background:#f0f0f0;"|'''Agbase'''<br />
| align="center" style="background:#f0f0f0;"|'''Dictybase'''<br />
| align="center" style="background:#f0f0f0;"|'''TAIR'''<br />
| align="center" style="background:#f0f0f0;"|'''SGD'''<br />
| align="center" style="background:#f0f0f0;"|'''Pombase'''<br />
|-<br />
| Week 1-2 (1st-16th July)||PTHR12027:SF15, PTHR12027:SF18, PTHR12027:SF25|| wnt1 (P04628) wnt3 (P56703) ||Week 3||8th July [VK] || ||done||done|| || || || none||none||none||none<br />
|-<br />
| ||PTHR12027:SF21, PTHR12027:SF23||wnt2 (P09544) wnt5 (P41221, Q9H1J7) ||Week 3 ||14th July [RL,RH] ||done||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF4, PTHR12027:SF6, PTHR12027:SF7, PTHR12027:SF19|| wnt4 (P56705) wnt8 (Q9H1J5, Q93098) wnt9 (O14904, O14905) wnt11 (O96014) ||Week 3 || 15th July [VK,YAF] || ||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF14|| wnt6 (Q9Y6F9) ||Week 3 ||9th July [RL] ||done||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF16, PTHR12027:SF22, PTHR12027:SF26|| wnt7 (O00755, P56706) wnt16 (Q9UBV4) ||Week 3 ||13th July [RL,YAF] ||done||done||done|| || || || none||none||none||none <br />
|-<br />
| ||PTHR12027:SF11|| wnt10 (WNT10A Q9GZT5, WNT10B O00744) ||Week 3||2nd July [RL]|| ||done||done|| || || || none||none||none||none <br />
|-<br />
| Week 3 (17th-23rd July)||PTHR23315|| CTNNB1 (P35222)||Week 5|| ||done||done||done|| || || || none||done||done||30th June [VW]<br />
|-<br />
| ||PTHR16505|| CTNNBIP1 (Q9NSA3) ||Week 5|| ||done||done||done|| || none|| || none||none||none||none<br />
|-<br />
| Week 4 (24th-31st July)|| PTHR10845:SF11|| Axin1 (O15169) ||Week 6|| || ||done||done|| || || || || || ||30th June [VW]<br />
|-<br />
| ||PTHR10845:SF103|| Axin2 (Q9Y2T1) ||Week 6 || || ||done||done|| || || || || || || 30th June [VW]<br />
|-<br />
| Week 5-6 (1st-13th August)|| PTHR11309:SF31, PTHR11309:SF32, PTHR11309:SF33, PTHR11309:SF34, PTHR11309:SF49|| fzd1 (Q9UP38) fzd2 (Q14332) fzd7 (O75084) ||Week 7|| || || || || || || || none||none||none||none<br />
|-<br />
| ||PTHR11309:SF28, PTHR11309:SF29|| fzd5 (Q13467) fzd8 (Q9H461) ||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF23|| fzd4 (Q9ULV1) ||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF24|| fzd10 (Q9ULW2) ||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF25|| fzd9 (O00144) fzd3 (Q9NPG1)||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| ||PTHR11309:SF21|| fzd6 (O60353)||Week 7|| || || || || || || || none||none||none||none <br />
|-<br />
| Week 6-7 (14th-20th August)|| PTHR11309:SF7, PTHR11309:SF10|| SFRP1 (Q8N474) SFRP2 (Q96HF1) SFRP4 (Q6FHJ7) ||Week 8|| || || || || || || || none||none||none||none<br />
|-<br />
| ||PTHR11309:SF10|| SFRP5 (Q5T4F7) ||Week 8|| || || || || || || || none||none||none||none <br />
|-<br />
| Week 8 (21st-31st August)|| PTHR10878|| dvl1 (O14640) dvl2 (O14641) dvl3 (Q92997) ||Week 9|| || || || || || || || none||none||none||none<br />
|-<br />
| Week 9-10 (1st-10th September)|| PTHR10529:SF108|| LRP5 (O75197) ||Week 11|| || || || || || || || ||none||none||none<br />
|-<br />
| || PTHR10529:SF109|| LRP6 (O75581) ||Week 11|| || || || || || || || ||none||none||none<br />
|-<br />
| Week 11 (11th-17th September)|| PTHR12607|| APC (P25054) APC2 (O95996) || Week 12 || || || || || none ||none || || none||none||none||none<br />
|-<br />
| || PTHR10373:SF11|| LEF1 (Q9UJU2)|| Week 13 || || || || || || || || none||none||none||none<br />
|-<br />
| Week 12-14 (18th September - 8th October)|| Review annotations with respect to PAINT inferences)|| || || || || || || || || || || || ||<br />
|-<br />
|}<br />
<br />
<br />
The aim is to provide good annotation coverage for these Panther families across the 11 species in a 3-month time frame, followed by a 2-week period of annotation review in response to PAINT inferences.<br />
<br />
# Each family is annotated in the order listed above, for a maximum of 2 weeks.<br />
# The priority is to annotate the gene products listed above, and orthologs in all species. Where the subfamily is shown, this means that the Panther family is very large and so MODs are asked to focus on the specific subfamilies shown. MODs are free to annotate to members of the larger family if they have time and wish to do so.<br />
# We are asking MODs to sign off each line of this table, so we can confirm that the whole clade has been annotated across all species. <br />
# PAINT curation will take place using as many annotations as available for each species, at the end of the specified annotation 2-week period. At this point they will deposit a GAF file in the CVS repository (http://cvsweb.geneontology.org/cgi-bin/cvsweb.cgi/go/gene-associations/submission/paint/#dirlist). It is only necessary that the annotations for the proteins/genes worked on in this period be provided.<br />
# PAINT inferences will begin to be sent back to MODs for checking as soon as they have been completed. We have allowed 2 weeks at the end of the annotation period for PAINT inference checking; however, MODs will be able to check the inferences earlier than this if they wish.<br />
<br />
==Other families to annotate (Prioritization TBD) ==<br />
# PTHR10878:SF4 DIXIN (DIX DOMAIN-CONTAINING PROTEIN 1)(COILED-COIL PROTEIN DIX1)<br />
#* dixdc1 (Q80Y83)<br />
# PTHR22844:SF10 F-BOX AND WD-40 DOMAIN PROTEIN<br />
#* BTRC (Q9Y297) Mediates the ubiquitination of CTNNB1 and participates in Wnt signaling<br />
#* FBXW11 (Q9UKB1) mediates the ubiquitination of CTNNB1 and participates in Wnt signaling<br />
# PTHR13164:SF3 Ubiquitin-mediated degradation of beta-catenin (CTNNB1)<br />
#* CACYBP (Q9HB71)<br />
# PTHR12011:SF67 and PTHR25100:SF76 CALCITONIN RECEPTOR <br />
#* CALCR (P30988)<br />
# PTHR24347:SF64: long-term potentiation and neurotransmitter release<br />
#* CAMK2A (Q9UQM7)<br />
#* CAMK2B (Q13554)<br />
#* CAMK2D (Q13557)<br />
#* CAMK2G (Q13555)<br />
# PTHR12015:SF30 SMALL INDUCIBLE CYTOKINE A<br />
#* CCL2 P13500<br />
# PTHR10177:SF67 G1/S-SPECIFIC CYCLIN-D1<br />
#* CCND1 (P24385)<br />
#* CCND2 (P30279)<br />
#* CCND3 (P30281)<br />
# PTHR15273:SF0<br />
#* CER1 (O95813)<br />
# PTHR10799:SF46 CHROMODOMAIN-HELICASE-DNA-BINDING PROTEIN 8 (CHD-8)<br />
#* CHD8 (Q9HCK8) negative regulator of Wnt signaling pathway by regulating beta-catenin (CTNNB1) activity<br />
# PTHR24344:SF26<br />
#* CHEK2 (O96017)<br />
# PTHR23056:SF4 CALCINEURIN B SUBUNIT<br />
#* CHP (Q99653)<br />
#* CHP2 (O43745)<br />
#* PPP3R1 P63098<br />
#* PPP3R2 Q96LZ3<br />
# PTHR24023:SF127<br />
#* COL1A1 (P02452)<br />
#* COL1A2 (P08123)<br />
# PTHR13808:SF0<br />
#* CREBBP (Q92793) part of canonical Wnt pathway<br />
#* EP300 (Q09472)<br />
# PTHR11909:SF20<br />
#* CSNK1A1 (P48729) Participates in Wnt signaling<br />
#* CSNK1A1L (Q8N752) Participates in Wnt signaling<br />
#* CSNK1E (P49674) Participates in Wnt signaling<br />
# PTHR24054:SF37<br />
#* CSNK2A1 (P68400) Participates in Wnt signaling<br />
#* CSNK2A2 (P19784) Participates in Wnt signaling<br />
# PTHR11740:SF0<br />
#* CSNK2B (P67870) Participates in Wnt signaling<br />
# PTHR10996:SF11 C-TERMINAL-BINDING PROTEIN 1<br />
#* CTBP1 (Q13363) Canonical Wnt signaling pathway. <br />
#* CTBP2 (P56545)<br />
# PTHR11932:SF19 CULLIN 1<br />
#* CUL1 (Q13616) direct ubiquitination of CTNNB1 and participate in Wnt signaling<br />
# PTHR13419:SF0<br />
#* CXXC4 (Q9H2H0) negative regulator of the Wnt signaling pathway via its interaction with DVL1<br />
# PTHR23213:SF44<br />
#* DAAM1 (Q9Y4D1) mediates Wnt-induced Dvl-Rho complex formation<br />
#* DAAM2 (Q86T65)<br />
# PTHR10568:SF4 DICKKOPF-RELATED PROTEIN 1<br />
#* DKK1 (O94907) Antagonizes canonical Wnt signaling by inhibiting LRP5/6 interaction with Wnt<br />
#* DKK2 (Q9UBU2) Antagonizes canonical Wnt signaling by inhibiting LRP5/6 interaction with Wnt<br />
# PTHR12113:SF2<br />
#* DKK4 (Q9UBP4) Antagonizes canonical Wnt signaling by inhibiting LRP5/6 interaction with Wnt<br />
#PTHR11371:SF7 DEOXYRIBONUCLEASE I<br />
#* DNASE1 (P24855)<br />
# PTHR23351 FOS-RELATED ANTIGEN 1<br />
#* FOSL1 (P15407)<br />
# PTHR15277<br />
#* FRAT1 (Q92837) Positively regulates the Wnt signaling pathway by stabilizing beta-catenin through the association with GSK-3<br />
#* FRAT2 (O75474) Positively regulates the Wnt signaling pathway by stabilizing beta-catenin through the association with GSK-3.<br />
# PTHR24057<br />
#* GSK3B (P49841) Participates in the Wnt signaling pathway.<br />
# PTHR10082 INTEGRIN BETA-3<br />
#* ITGB3 (P05106)<br />
# PTHR11462 TRANSCRIPTION FACTOR C-JUN<br />
#* JUN (P05412) Presenilin action in Notch and Wnt signaling. <br />
# ??<br />
#* MAP3K7 O43318 Noncanonical Wnt signaling pathway. <br />
# PTHR24055 <br />
#* MAPK10 P53779<br />
#* MAPK8 P45983<br />
#* MAPK9 P45984<br />
# PTHR11501 MICROTUBULE-ASSOCIATED PROTEIN TAU<br />
#* MAPT P10636<br />
# PTHR10201 MATRILYSIN<br />
#* MMP7 P09237<br />
# PTHR11514 MYC PROTO-ONCOGENE PROTEIN<br />
#* MYC P01106 Canonical Wnt signaling pathway. <br />
# PTHR12533 <br />
#* NFAT5 O94916<br />
#* NFATC1 O95644<br />
#* NFATC2 Q13469 Noncanonical Wnt signaling pathway. <br />
#* NFATC3 Q12968<br />
#* NFATC4 Q14934<br />
# PTHR22611<br />
#* NKD1 Q969G9 Cell autonomous antagonist of the canonical Wnt signaling pathway.<br />
#* NKD2 Q969F2 Cell autonomous antagonist of the canonical Wnt signaling pathway.<br />
# PTHR24055<br />
#* NLK Q9UBE8 Acts downstream of MAP3K7 and HIPK2 to negatively regulate the canonical Wnt/beta-catenin signaling pathway<br />
# PTHR24214<br />
#* PDLIM4 P50479<br />
# PTHR10336 1-PHOSPHATIDYLINOSITOL-4,5-BISPHOSPHATE PHOSPHODIESTERASE BETA-1<br />
#* PLCB1 Q9NQ66<br />
#* PLCB2 Q00722<br />
#* PLCB3 Q01970<br />
#* PLCB4 Q15147<br />
# PTHR13906 PORCUPINE<br />
#* PORCN Q9H237 Modulates the processing of Wnt proteins. <br />
# PTHR24082<br />
#* PPARD Q03181 Presenilin action in Notch and Wnt signaling. <br />
#* VDR P11473<br />
# PTHR11668 SERINE/THREONINE PROTEIN PHOSPHATASE PP2A<br />
#* PPP2CA P67775 Regulation of Wnt receptor signaling pathway<br />
#* PPP2CB P62714 Signaling by Wnt. <br />
#* PPP3CA Q08209<br />
#* PPP3CB P16298<br />
#* PPP3CC P48454<br />
# PTHR10648 SERINE/THREONINE-PROTEIN PHOSPHATASE 2A 65 KDA REGULATORY SUBUNIT A ALPHA ISOFORM<br />
#* PPP2R1A P30153 regulation of Wnt receptor signaling pathway<br />
#* PPP2R1B P30154 Signaling by Wnt. <br />
# PTHR10257 SERINE/THREONINE-PROTEIN PHOSPHATASE 2A 56 KDA REGULATORY SUBUNIT ALPHA ISOFORM<br />
#* PPP2R5A Q15172 Signaling by Wnt. <br />
#* PPP2R5B Q15173 Signaling by Wnt. <br />
#* PPP2R5C Q13362 Signaling by Wnt. <br />
#* PPP2R5D Q14738 Canonical Wnt signaling pathway. <br />
#* PPP2R5E Q16537<br />
# PTHR24218<br />
#* PRICKLE1 Q96MT3<br />
#* PRICKLE2 Q7Z3G6<br />
# PTHR24353<br />
#* PRKACA P17612<br />
#* PRKACB P22694<br />
#* PRKACG P22612<br />
# PTHR24355<br />
#* RPS6KA3 Q7Z2J4<br />
# PTHR24357<br />
#* PRKCA P17252<br />
#* PRKCB P05771<br />
#* PRKCG P05129<br />
# PTHR24353<br />
#* PRKX P51817<br />
# PTHR10202:SF7 PRESENILIN-1 *Former RefGenome target<br />
#* PSEN1 P49768 increases the pool of cytoplasmic beta-catenin, thus negatively regulating Wnt signaling<br />
# PTHR11599 PROTEASOME SUBUNIT ALPHA TYPE 1<br />
#* PSMA1 P25786 Signaling by Wnt. <br />
#* PSMA2 P25787 Signaling by Wnt. <br />
#* PSMA3 P25788 Signaling by Wnt. <br />
#* PSMA4 P25789 Signaling by Wnt. <br />
#* PSMA5 P28066 Signaling by Wnt. <br />
#* PSMA6 P60900 Signaling by Wnt. <br />
#* PSMA7 O14818 Signaling by Wnt. <br />
#* PSMB1 P20618 Signaling by Wnt. <br />
#* PSMB10 P40306 Signaling by Wnt. <br />
#* PSMB2 P49721 Signaling by Wnt. <br />
#* PSMB3 P49720 Signaling by Wnt. <br />
#* PSMB4 P28070 Signaling by Wnt. <br />
#* PSMB5 P28074 Signaling by Wnt. <br />
#* PSMB6 P28072 Signaling by Wnt. <br />
#* PSMB7 Q99436 Signaling by Wnt. <br />
#* PSMB8 P28062 Signaling by Wnt. <br />
#* PSMB9 P28065 Signaling by Wnt. <br />
# PTHR23073 26S PROTEASE REGULATORY SUBUNIT 4<br />
#* PSMC1 P62191 Signaling by Wnt. <br />
#* PSMC2 P35998 Signaling by Wnt. <br />
#* PSMC3 P17980 Signaling by Wnt. <br />
#* PSMC4 P43686 Signaling by Wnt. <br />
#* PSMC5 P62195 Signaling by Wnt. <br />
#* PSMC6 P62333 Signaling by Wnt. <br />
# PTHR10943 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 1 <br />
#* PSMD1 Q99460 Signaling by Wnt. <br />
# PTHR24199<br />
#* PSMD10 O75832 Signaling by Wnt. <br />
# PTHR10678 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 11<br />
#* PSMD11 O00231 Signaling by Wnt. <br />
# PTHR10855 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 12<br />
#* PSMD12 O00232 Signaling by Wnt. <br />
# PTHR10539 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 13<br />
#* PSMD13 Q9UNM6 Signaling by Wnt. <br />
# PTHR10410 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 14<br />
#* PSMD14 O00487 Signaling by Wnt. <br />
# PTHR10943 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 2 <br />
#* PSMD2 Q13200 Signaling by Wnt. <br />
# PTHR10758 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 3<br />
#* PSMD3 O43242 Signaling by Wnt. <br />
# PTHR10223 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 4<br />
#* PSMD4 P55036 Signaling by Wnt. <br />
# PTHR13554 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 5<br />
#* PSMD5 Q16401 Signaling by Wnt. <br />
# PTHR14145 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 6<br />
#* PSMD6 Q15008 Signaling by Wnt. <br />
# PTHR10540 26S PROTEASOME NON-ATPASE REGULATORY SUBUNIT 7<br />
#* PSMD7 P51665 Signaling by Wnt. <br />
# PTHR12387<br />
#* PSMD8 P48556 Signaling by Wnt. <br />
# PTHR12651<br />
#* PSMD9 O00233 Signaling by Wnt. <br />
# PTHR10660 PROTEASOME ACTIVATOR COMPLEX SUBUNIT 1<br />
#* PSME1 Q06323 Signaling by Wnt. <br />
#* PSME2 Q9UL46 Signaling by Wnt. <br />
#* PSME3 P61289 Signaling by Wnt. <br />
# PTHR13266<br />
#* PSMF1 Q92530 Signaling by Wnt. <br />
# PTHR19134 PROTEIN TYROSINE PHOSPHATASE N11 (SHP2)<br />
#* PTPN11 Q06124<br />
# PTHR24072<br />
#* RAC1 P63000<br />
#* RAC2 P15153<br />
#* RAC3 P60763<br />
#* RHOA P61586<br />
# PTHR13742 RETINOBLASTOMA-ASSOCIATED PROTEIN<br />
#* RB1 P06400<br />
# PTHR11210:SF2 RING FINGER 1<br />
#* RBX1 P62877<br />
# PTHR22988 RHO-ASSOCIATED, COILED-COIL CONTAINING PROTEIN KINASE<br />
#* ROCK1 Q13464<br />
#* ROCK2 O75116<br />
# PTHR10666 UBIQUITIN (RIBOSOMAL PROTEIN L40)<br />
#* RPS27A P62988 Signaling by Wnt. <br />
# PTHR11093<br />
#* RUVBL1 Q9Y265<br />
# PTHR12606<br />
#* SENP2 Q9HC62 down-regulate CTNNB1 levels and thereby modulate the Wnt pathway<br />
# PTHR11165 SKP1-RELATED<br />
#* SKP1 P63208 Signaling by Wnt. <br />
# PTHR13703 SMAD<br />
#* SMAD1 Q15797<br />
#* SMAD2 Q15796 <br />
#* SMAD3 P84022<br />
#* SMAD4 Q13485 Canonical Wnt signaling pathway. <br />
# PTHR23113 RAS GTP EXCHANGE FACTOR, SON OF SEVENLESS<br />
#* SOS1 Q07889<br />
# PTHR10270 TRANSCRIPTION FACTOR SOX-17<br />
#* SOX17 Q9H6I2 negative regulation of Wnt receptor signaling pathway through beta-catenin<br />
# PTHR11267 BRACHYURY <br />
#* T O15178<br />
# PTHR22846 TRANSDUCIN BETA-LIKE 1<br />
#* TBL1X O60907 Wnt receptor signaling pathway through beta-catenin<br />
#* TBL1XR1 Q9BZK7 Wnt receptor signaling pathway through beta-catenin<br />
#* TBL1Y Q9BQ87<br />
# PTHR10373 TRANSCRIPTION FACTOR 7 <br />
#* TCF7 P36402 Wnt signaling pathway<br />
#* TCF7L1 Q9HCS4 Participates in the Wnt signaling pathway. <br />
#* TCF7L2 Q9NQB0 Participates in the Wnt signaling pathway <br />
# PTHR11447 CELLULAR TUMOR ANTIGEN P53 *Former RefGenome target<br />
#* TP53 P04637<br />
# PTHR11371:SF7 DEOXYRIBONUCLEASE I<br />
#* TRAP1 P24855<br />
# PTHR20886<br />
#* VANGL1 Q8TAA9<br />
#* VANGL2 Q9ULK5<br />
# PTHR15160<br />
#* VHL P40337<br />
# PTHR24838<br />
#* WIF1 Q9Y5W5 Binds to WNT proteins and inhibits their activities.</div>Juliephttps://wiki.geneontology.org/index.php?title=13_JULY_2010_RefGen_Phone_Conference_(Archived)&diff=2920013 JULY 2010 RefGen Phone Conference (Archived)2010-07-14T21:29:18Z<p>Juliep: /* PAINT-generated GAF files */</p>
<hr />
<div>==Present==<br />
<br />
Varsha: BHF/UCL<br />
<br />
Pascale: dictyBase<br />
<br />
David: MGI<br />
<br />
Tanya: TAIR<br />
<br />
Doug: ZFIN<br />
<br />
Kimberly: WormBase<br />
<br />
Ranjana: WormBase<br />
<br />
Susan: FlyBase<br />
<br />
Rachael: GOA<br />
<br />
Julie: SGD<br />
<br />
Stan: RGD<br />
<br />
Jim: Ecoli<br />
<br />
Yasmin: GOA<br />
<br />
Seth: BBOP<br />
<br />
==wnt project==<br />
<br />
'''Please add when annotation is done to the Wnt wiki page.'''<br />
<br />
Ontology Issues<br />
<br />
'''Canonical vs Non-Canonical Wnt Signaling'''<br />
<br />
Varsha: Split into canonical or non-canonical?<br />
<br />
Stan: Yes, authors usually make that distinction in the papers.<br />
<br />
'''Molecular Function for Wnts'''<br />
<br />
Varsha: email that Ruth sent to Ref Genome list<br />
<br />
Ruth wanted to have a better way of describing the molecular function of Wnts, e.g. Wnt ligand activity?<br />
<br />
What do people think about that?<br />
<br />
What functions would be suggested?<br />
<br />
Some type of signaling activity other than just binding to the receptor.<br />
<br />
Susan: Is Ruth striving to describe the class of protein rather than the actual function? Does the molecular function extend beyond the binding? <br />
<br />
Becky and Susan responded to the accompanying SourceForge item, felt that binding captured the function sufficiently.<br />
<br />
'''SourceForge Items'''<br />
<br />
Quite a few SF items related to Wnt project; curators, please keep an eye on these and comment, as needed.<br />
<br />
'''New Annotation Schedule'''<br />
<br />
Can people meet the Friday deadline?<br />
<br />
Susan: Waiting for new terms, some other projects at FlyBase preclude GAF file upload until next week; still working on Wnt1<br />
<br />
How long does it take to do the PAINT annotations? Is it okay to wait a few days?<br />
<br />
Mike: Giving himself a week to curate each family, one day for MF and CC, three days for BP.<br />
<br />
Susan: The annotations are already there, but working on cleaning them up. But other concern is new terms, that haven't been processed yet. Is it worth it to wait another week to start the PAINT annotations?<br />
<br />
Mike: PAINT anticipates a two-week lag for annotations to make it to the server.<br />
<br />
Susan: That should be fine.<br />
<br />
Varsha: We'll stick to the two-week schedule and see how it goes.<br />
<br />
==GO camp action items==<br />
<br />
* '''Send final guidelines to Rachael/Pascale for inclusion on the GO wiki'''<br />
<br />
'''Much of this work is still in progress, but there will be wiki pages on annotation wrt each of these items.'''<br />
<br />
===Binding group action items===<br />
<br />
* Unresolved issues to be discussed by binding group<br />
<br />
1. Annotation of 'NOT' binding a specific protein: new GO term or column 16 (consider IntAct guidelines on this)?<br />
<br />
2. Automate annotation to specific binding term from known functions of protein, eg transcription factor binding, based on evidence that protein is transcription factor, or domain implied? Or not create this type of term?<br />
<br />
3. Transferring cross species information by ISS and inclusion of non in-vivo targets in column 8 or 16.<br />
<br />
4. How specific to make substrate/product target information?<br />
<br />
5. Will CHEBI IDs in function ontology propagate to process terms?<br />
<br />
6. Existing GO to follow new has_part relationships implying substrate binding <br />
<br />
* Unresolved issues to be discussed by other groups:<br />
<br />
1. Incorporation of IMEX data being discussed<br />
<br />
2. Col 16 relationship ontology (has_input=substrate) <br />
<br />
===Response group action items===<br />
<br />
1. Update definition of response to terms to indicate that we are capturing mediators (wording needs to be worked out)<br />
<br />
===Protein complexes group action items===<br />
<br />
1. Long term goal is to annotate complexes; details and requirements need to be clarified. <br />
<br />
Pascale: Discussion at ISMB amongst IntAct and PRO deciding what they will do. It will be possible to annotate to protein complexes once they exist. <br />
<br />
===Downstream Process group action items===<br />
<br />
1. What is the process term for a specific transcription factor? (i.e. 'transcription' or 'regulation of transcription'?) ACTION: transcription ontology revision<br />
<br />
2. Define the start and end of signaling processes. ACTION: signaling working group<br />
<br />
3. Is a ligand part of the pathway? Can it also regulate the pathway? Is there a difference between intra- and inter-cellular pathways regarding the ligand?<br />
<br />
4. Some MODs keep legacy annotations (i.e. correct annotations to downstream processes), but some prefer to remove them, is this a problem? ACTION: all<br />
<br />
5. Form a working group to look into phenotype/development/IMP issues. How should we annotate to development terms?<br />
<br />
6. Regarding the survey question 2, whether to annotate ubiquitin ligases to regulation of histone methylation, Val will give reasons why she would like to annotate to regulation of histone methylation. The ontology may need altering to reflect the step-by-step nature of this pathway. ACTION: Val/Sylvain/Ontology editors <br />
<br />
===Quality control checks=== <br />
<br />
Rachael: Will need to be sent to Chris to be fleshed out a bit more.<br />
<br />
1. High level ‘response to’ terms should not directly be used for annotation<br />
<br />
2. Avoid annotations to GO: MF by IPI (except for ‘protein binding’ and children) <br />
<br />
3. Check for less-granular and more-granular annotation from the same path (soft check)<br />
<br />
== PAINT-generated GAF files==<br />
* http://cvsweb.geneontology.org/cgi-bin/cvsweb.cgi/go/gene-associations/submission/paint/<br />
* Notes from the curation can be found on the cvs repository (.txt file) and in the family overview page: <br />
* PTHR10046 [http://amigo-sven.princeton.edu/cgi-bin/amigo/phylotree?mode=cluster&key=PTHR10046&dbname=PantherDB]<br />
* SGD displays on their test server<br />
<br />
<br />
'''GAF Files'''<br />
<br />
Mike: Pascale put a link about GAF files on the agenda. <br />
<br />
Click on the link, there are six directories.<br />
<br />
Each directory has ~8-9 files. Most important is the .gaf file and the .txt file contains the reasoning and questions regarding curation. emails have also been sent out; please address questions when you have a chance.<br />
<br />
Also, Sven is trying to get the files from CVS onto the family display in AmiGO labs; they may appear and disappear randomly.<br />
<br />
Pascale: Clarify?<br />
<br />
Mike: As Sven develops the pages, this may be a moving target.<br />
<br />
Ultimately the plan is to have the files displayed from the family page; but this work is in production.<br />
<br />
Seth: One thing....taking snapshots from AmiGO Sven and being moved to AmiGO labs. Should be more stable, but a bit behind. Hopefully this will give a more stable user interface.<br />
<br />
Seth will put a sample URL on the wiki page.<br />
<br />
Ranjana: Is this about having a more user friendly display of everything in the GAF?<br />
<br />
Mike: Yes; want to make sure annotations questions are more easily seen and can address questions in the .txt file.<br />
<br />
Ranjana: Looking at a GAF to review PAINT annotations is not user friendly. Do you want the MOD curators to review all of the annotations or just the ones for which there are questions?<br />
<br />
Mike: Questions that I'm writing pertain primarily to the existing experimental annotations - clarifications, etc.<br />
As for reviewing the lines in the GAF file that pertain to an organism - that will have to be an internal decision for each database.<br />
<br />
Rachael: Question about the GAFs. In the human GAFs, there were ENSEMBL and UniProt IDs? Can this be all UniProtKB IDs?<br />
<br />
This is an issue for Ed and Paul.<br />
<br />
Mike will send an email.<br />
<br />
David: Are the annotation files going to be available on an ftp site? concatenated? would be much easier to handle.<br />
<br />
Mike: Refer to Ed and Suzi.<br />
<br />
Pascale: People have requested one GAF file as opposed to several. Would that be simpler?<br />
<br />
Ranjana: One file of C. elegans genes new stuff, one file of everything.<br />
<br />
David: The issue with that is that if things get dropped, you wouldn't know it. MGI will completely strip out all of annotations and then get all of them again. That's why having one central location for the file is best.<br />
<br />
Ranjana: New files by date; files also by organism.<br />
<br />
David: If the file is just new annotations each week, then that won't work with MGI.<br />
<br />
Doug: Can the date in the GAF file be helpful in that regard? Use the annotation date to get this?<br />
<br />
Jim: Use taxon IDs to filter. Making separate files for each organism could be messy. <br />
<br />
Tanya: Then we still want one giant file with all of the PAINT annotations. Filter by tax ID. Or have one giant file with all of the annotations for each organism. Or have a giant file plus a file with just the new annotations.<br />
<br />
Ranjana: Just a question of what the scripts will do. Is it a problem to create different formats?<br />
<br />
Pascale: Everyone should write to the RefGenome list with their suggestions and then the PAINT developers and GO developers can discuss what is the best thing to do. Having every family in a separate directory is to complicated. We should try to find something relatively simple to propose.<br />
<br />
* Could PAINT provide their data similarly to how UniProtKB provides their IEA annotations? Groups either already have or are working towards ways of incorporating this data into their databases and files so consistency would avoid MODs having to create new scripts for each new external data source.<br />
<br />
Tanya: Please check the minutes to make sure what you've proposed has been recorded accurately :-).<br />
<br />
Doug: Files dumped from PAINT are in GAF2.0, in column 10 (protein, gene, etc.) - needs to be updated to GAF2.0 vocabulary.<br />
<br />
Mike will make a note to get new and old files consistent with GAF2.0.<br />
<br />
Susan: What references are being used? Idea was to have one reference per PANTHER group and until those were available, there was a generic GO Ref being used. Current files are a mixture.<br />
<br />
Mike: They're not all showing up as GO_REF: PTHRnnnnn<br />
<br />
Susan: Will need to make new references in FB for each PTHR family. Thought a generic GO_REF would be used until the PTHR family Refs did exist.<br />
<br />
Julie: There is a generic GO_Ref on GO, this would have to be substituted for the specific references.<br />
<br />
David: GO will need to provide GO_Refs a la PubMed so that groups can import these into their DBs.<br />
<br />
Pascale: PAINT curators are aware of this; will be put on the to do list. Don't have a dedicated PAINT developer at the moment.<br />
<br />
==External Links==<br />
<br />
* AmiGO Labs [http://amigo.berkeleybop.org/cgi-bin/amigo/amigo]<br />
* Sven's works snapshot at AmiGO Labs [http://amigo.berkeleybop.org/cgi-bin/amigo/phylotree]</div>Juliephttps://wiki.geneontology.org/index.php?title=Lung_development_genes&diff=26250Lung development genes2010-03-30T14:36:46Z<p>Juliep: /* November 2009 targets */</p>
<hr />
<div>The MGI group supplied the initial gene set of 14 genes based on recent MGI PI interest in lung development.<br />
<br />
==November 2009 targets==<br />
<br />
Annotation Progress - - <font color ="red"> High priority targets are in red</font><br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!Panther ID <br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR13935<br />
|Ascl1<br />
| -<br />
| -<br />
|<br />
| -<br />
|done(3)<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11486<br />
|<font color ="red">Fgf8/10</font><br />
| -<br />
| -<br />
|<br />
| -<br />
| -<br />
|done<br />
|<br />
|<br />
|<br />
|key features in (21/37)<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11829<br />
|Foxa2 (also assigned in December)<br />
| -<br />
| done(4)<br />
| done but not appropriate for functional transfer<br />
| -<br />
| -<br />
|done(1)<br />
|done<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10071<br />
|Gata6<br />
| -<br />
|done (4)<br />
|done but not appropriate for functional transfer<br />
|done (1)<br />
|done(21)<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR19818<br />
|Gli2/3<br />
| -<br />
| -<br />
|done (1), but likely mis prediction<br />
|done (2)<br />
| -<br />
|done(2)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24083<br />
|Hnf4a<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
|done(2)<br />
|done<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24416<br />
|Kdr<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
|<br />
|done<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24340<br />
|Nkx2-1<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10796<br />
|Ptch1<br />
| -<br />
| done(1)<br />
| -<br />
|done (2)<br />
|done(2)<br />
|done(3)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24082<br />
|Rara<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
|done(3)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10270<br />
|Sox18 (Sox8?)<br />
| -<br />
| done(1)<br />
|done but not appropriate for functional transfer<br />
|done(5)<br />
|done(1)<br />
|done(2)<br />
|done<br />
|<br />
|<br />
|done<br />
|done<br />
|done (4)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR12025<br />
|Vegfa<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=Reference_Genome_ProgressReport_April_2010_(Archived)&diff=25979Reference Genome ProgressReport April 2010 (Archived)2010-03-25T22:44:26Z<p>Juliep: /* Curation Progress */</p>
<hr />
<div>=Objectives and metrics=<br />
* Sven: annotation status tracking tool <br />
<br />
=Curation Progress=<br />
The numbers of genes per species is based on the google spreadsheets, parsed by Mary Dolan. It excludes the Jan/Feb targets. <br />
See complete list on the ftp site here: [ftp://ftp.informatics.jax.org/pub/curatorwork/GODB/refg_id_list.txt<br />
]<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Group<br />
! Number of curation targets <br />
! Number of genes curated for ref genome<br />
|-<br />
! AgBase<br />
! 570<br />
! <br />
|-<br />
! BHF-UCL<br />
! <br />
! <br />
|-<br />
! dictyBase<br />
! 463<br />
! <br />
|-<br />
! Ecoli<br />
! 158<br />
! <br />
|-<br />
! FlyBase<br />
! 422<br />
! <br />
|-<br />
! GOA<br />
! 1018<br />
! 673<br />
|-<br />
! MGI<br />
! 955<br />
! <br />
|-<br />
! pombe<br />
! 344<br />
! <br />
|-<br />
! RGD<br />
! 920<br />
! 888<br />
|-<br />
! SGD<br />
! 513<br />
! 492<br />
|-<br />
! TAIR<br />
! 705<br />
! <br />
|-<br />
! WormBase<br />
! 640<br />
! 431<br />
|-<br />
! ZFIN<br />
! 927<br />
! <br />
|}<br />
<br />
=PAINT= <br />
Software for propagation of annotations is now functional. First public release expected March 2010.<br />
<br />
=Protein sets=<br />
<br />
Human, mouse, rat, chicken and zebrafish proteomes from UniProt are augmented with Ensembl proteins. 51 species are covered, including all reference Genomes species. Plasmodium falciparum and Ixodes scapularis will appear in the 3rd release.<br />
<br />
Release 3 has a bug fix for duplicate entries between UniProt and Ensembl that link to the same UniProtKB/Swiss-Prot entry.<br />
It also sees a huge improvement for the chicken proteome. This is now the best representation of the proteome available by combining UniProt and Ensembl. A better understanding of the Ensembl pipeline identified a database input that was not included in the QfO proteome generation pipeline (IPI), with the addition of this extra database identifier the proteomes are more complete.<br />
<br />
Full details of Release 2 are here: http://www.ebi.ac.uk/~dbarrell/qfo/<br />
<br />
Release 3 will be ready for the end of March.<br />
<br />
=Concurrent annotation=<br />
We have switched from annotating unrelated genes to annotating genes involved in a narrower biological process. The advantages of this approach are <br />
# facilitates coordination with ontology development <br />
# makes it easier to do the annotations because we're addressing a single general area of biology<br />
# makes it possible to solicit the help of experts to help review the annotations and ensure that nothing is missing. <br />
<br />
==Topics covered==<br />
* Lung branching morphogenesis (November 2009- March 2010)<br />
* Heart development (April 2010 - )<br />
<br />
=Annotation status reporting tool=<br />
Kara Dolinski and her group have started to work on a tool that would display the annotation status of the Panther families. There will be a regularly updated web page that will show the following information: <br />
<br />
# Panther family ID <br />
# Date selected for concurrent annotation <br />
# Date Panther family last annotated (tree annotations) <br />
# Number of members <br />
# Number of RefG members <br />
# Number of members with EXP <br />
# Date more recent member last annotated<br />
# 'Date comprehensively annotated' for groups that can provide this information<br />
<br />
http://amigo-sven.princeton.edu/cgi-bin/amigo/phylotree<br />
<br />
http://amigo-sven.princeton.edu/cgi-bin/amigo/phylotree?mode=cluster&key=PTHR10000&dbname=PantherDB<br />
<br />
http://amigo.berkeleybop.org/cgi-bin/amigo/amigo_exp?mode=ntree&external_resource=http%3A%2F%2Famigo.berkeleybop.org%2Famigo%2Fpanther%2FPTHR10000.tree<br />
<br />
= Electronic annotation jamborees= <br />
To allow curators to discuss annotation consistency, we hold electronic annotation jamborees three times per year where we discuss annotation of two different genes. The latest was held in February 2010. We discussed SLIT2 (thought to act as molecular guidance cue in cellular migration, and function appears to be mediated by interaction with roundabout homolog receptors) and NIPBL (that probably plays a structural role in chromatin. Involved in sister chromatid cohesion, possibly by interacting with the cohesin complex). <br />
<br />
The major action item from this meeting was the need to improve the representation of neuronal processes.<br />
<br />
=GO annotation camp=<br />
The SIB group in Geneva will host a meeting in June 2010 where annotators will meet to resolve specific annotation issues. The outcome of this meeting will be clear documentation about a number of focused topics. Unless we decide to change those at the GOC meeting, the plan is to discuss : <br />
* Binding and complexes (finalize protein binding documentation, see [[Binding_terms_working_group]]<br />
* Use of regulation <br />
* Response to terms, how will these relate to signaling terms and to final cellular effect<br />
* How is a downstream effect defined (i.e when not to capture phenotypes )<br />
<br />
= Advertising ref genomes at the MODs=<br />
<br />
= New annotators=<br />
We are very pleased to announce that Swiss-Prot annotators are now doing GO annotation. Emily Dimmer and Rachael Huntley trained 34 annotators during the past year. <br />
<br />
<br />
<br />
----</div>Juliephttps://wiki.geneontology.org/index.php?title=January/February_2010_lung_targets&diff=25756January/February 2010 lung targets2010-03-18T20:30:26Z<p>Juliep: </p>
<hr />
<div>==January/February 2010 targets==<br />
<br />
Annotation Progress - <font color ="red"> High priority targets are in red</font><br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!link to family members<br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|http://wiki.geneontology.org/index.php/ACER2<br />
|<font color ="red">ACER2</font><br />
| -<br />
| done (2)<br />
| -<br />
| 2 genes - no EXP<br />
| done (2)<br />
| <br />
|no Zfish gene<br />
|done (1)<br />
|no EXP<br />
|done<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ADCY7<br />
|<font color ="red">ADCY7</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
|<br />
| done (1)<br />
|<br />
|no EXP<br />
|done<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ALOX5AP_RefG<br />
|<font color ="red">ALOX5AP</font><br />
| -<br />
| -<br />
| -<br />
| 1 gene - no EXP<br />
| -<br />
|no worm<br />
| done (2)<br />
|no fly<br />
|no EXP<br />
|done<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ANGPT1<br />
|<font color ="red">ANGPT1</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
|no worm<br />
| done (1)<br />
|no fly<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ANXA3<br />
|<font color ="red">ANXA3</font><br />
| -<br />
| -<br />
| -<br />
| 1 gene - done<br />
| done (2)<br />
| done (3/4) - also waiting on term requests<br />
| done (4)<br />
|<br />
|<br />
|done<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/AQP1<br />
|<font color ="red">AQP1<br />
| aqpZ (in progress)<br />
| -<br />
| -<br />
| 5 genes no EXP (aqpA, wacA, done)<br />
| 8 (in progress)<br />
|<br />
| done (1)<br />
|<br />
|<br />
|<br />
|<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/CDKN2 <br />
|<font color ="red">CDKN2A, CDKN2B</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
| no worm<br />
| done (1)<br />
|no fly<br />
|<br />
|<br />
|<br />
|done (3)<br />
|-<br />
|http://wiki.geneontology.org/index.php/COL4A4<br />
|<font color ="red">COL4A4</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
| no worm<br />
| no zfish gene<br />
|no fly<br />
|no EXP<br />
|done<br />
|<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/DUSP6<br />
|<font color ="red">DUSP6</font><br />
| ynbD (in progress)<br />
| done (4)<br />
|in progress (2)<br />
| 2/7 have EXP, mpl1 done, dupA to finish<br />
| done (5)<br />
| done<br />
| done (2)<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ENG_RefG<br />
|<font color ="red">ENG</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
| no worm<br />
| Only Ensembl gene, matches nothing in zfin, done<br />
|no fly<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/GSTT1<br />
|GSTT1<br />
| -<br />
| -<br />
| -<br />
| 2 genes - no EXP<br />
|<br />
| no worm<br />
| done (2)<br />
|<br />
|<br />
|done<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/HMGB2<br />
|HMGB2<br />
| -<br />
| done (6)<br />
| - (3 genes here but ortholog predictions inc, not appropriate for annotation tf)<br />
| 1 gene, no EXP<br />
| -<br />
|<br />
| done (6)<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PLEKHA2<br />
|<font color ="red">PLEKHA2</font><br />
| -<br />
| -<br />
| -<br />
|1 gene, no EXP<br />
| -<br />
| no worm<br />
| done (1)<br />
|no fly<br />
|no EXP<br />
|done<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/S100A13<br />
|<font color ="red">S100A13</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
| no worm<br />
| done (1)<br />
|no fly<br />
|no EXP<br />
|done<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/SERPINB9<br />
|<font color ="red">SERPINB9</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
| no worm<br />
| no zfish gene<br />
|no fly<br />
|no Gallus<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/SERPINE1<br />
|SERPINE1<br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
| worm<br />
| done (1)<br />
|no fly<br />
|<br />
|<br />
|<br />
|in progress<br />
|-<br />
|http://wiki.geneontology.org/index.php/TAP2_RefG<br />
|<font color ="red">TAP2</font><br />
| 2 (mdlA & msbA), to do <br />
| done (2)<br />
| done (1)<br />
| 2 genes (tagA, abcB1), to do<br />
| done (2)<br />
|<br />
| done (3)<br />
|done (1) no EXP<br />
|<br />
|<br />
|<br />
|done (3)<br />
|-<br />
|http://wiki.geneontology.org/index.php/THBS3<br />
|<font color ="red">THBS3</font><br />
| -<br />
| -<br />
| -<br />
| no Dicty<br />
| -<br />
|<br />
| done (6)<br />
|done (3) EXP<br />
|<br />
|<br />
|<br />
|done (3)<br />
|-<br />
|}<br />
----<br />
Back to [[Reference_Genome_Annotation_Project Reference Genome Main Page]]</div>Juliephttps://wiki.geneontology.org/index.php?title=2010_Stanford_Meeting_Logistics&diff=253162010 Stanford Meeting Logistics2010-03-08T22:53:28Z<p>Juliep: /* Attendees */</p>
<hr />
<div>=Dates=<br />
GO consortium & SAB meetings March 30-31, April 1, 2010<br />
<br />
# We wish all attendees to attend from the morning of March 30 through the morning of April 1st. The afternoon of April 1st will be for all GO subcontract PIs, GOC PIs and our SAB. We suggest you arrive the evening of March 29th and leave after noon on the 1st, unless you are a PI or SAB member.<br />
<br />
=Venue=<br />
Meetings will be at the [http://www.stanford.edu Stanford University], Stanford, CA, USA.<br />
<br />
The GOC and SAB meeting will take place at the [http://www.stanfordalumni.org/aboutsaa/alumni_center/conference/home.html Arrillaga Alumni Center].<br />
<br />
Lunches will be at the Arrillaga Center.<br />
<br />
There will be a group dinner on March 31st for the GOC and SAB.<br />
<br />
We will also facilitate dinners on March 29th and 30th. There are a large variety of restaurants in the area.<br />
<br />
=Maps=<br />
[http://maps.stanford.edu/ Stanford University maps]<br />
<br />
=Registration=<br />
Registration will open in early 2010. <br />
<br />
#Registration Fee. We anticipate a minimal registration fee to cover lunch and a light breakfast. The meeting will be sponsored by the Cherry Lab.<br />
<br />
=Lodging Information=<br />
Four hotels are within a 15-20 minute walk to the Alumni Center. Ordered below by price per night, lowest to highest.<br />
<br />
#[http://www.hotelcalifornia.com/ Hotel California] $<br />
#[http://www.cardinalhotel.com/ Cardinal Hotel] $<br />
#[http://www.stanfordterraceinn.com/ Stanford Terrace Inn] $$<br />
#[http://specialoffers.starwoodhotels.com/SheratonPaloAlto/so.htm?PS=PS_aa_Western_Google_sheraton_palo_alto_california_011209_NAD_FM Sheraton Palo Alto Hotel] $$$$<br />
#[http://specialoffers.starwoodhotels.com/WestinPaloAlto/so.htm?PS=PS_aa_Western_Google_westin_palo_alto_ca_011209_NAD_FM Westin Palo Alto] $$$$<br />
<br />
=Agenda=<br />
<br />
==Workshop/Tutorial-Curators meet developers (content and software)==<br />
A workshop/tutorial on how to use all the utilities and content that GO has to offer. <br />
*AmiGO has lot of cool features now and many curators may or may not know how to incorporate these features in everyday curation. <br />
*how to interpret relationships in the ontology, how the annotations can mean something else if the relationships are overlooked etc.<br />
<br />
== Taxon IDs ==<br />
I'd like a discussion of taxon IDs and subspecies. --[[User:JimHu|JimHu]] 17:28, 4 February 2010 (UTC)<br />
<br />
==Making ext GO 'main'==<br />
A suggestion from the OBO Foundry meeting: we make GO ext the main GO file, the one that new users see. The other files continue to exist in the same place, but make it clear they are legacy files. That way anyone new coming to GO will build tools using GO ext. [Jane]<br />
<br />
==Guidelines for 'binding' terms==<br />
<br />
Discuss guideline documentation, progess and unresolved issues [Ruth].<br />
<br />
[http://wiki.geneontology.org/index.php/Binding_terms_working_group#2010_discussion proposed guidelines]<br />
<br />
'''Unresolved issues:'''<br />
* Should we include transporters in these guidelines? <br />
* Should we capture drug information?<br />
* Should the guidelines include a statement suggesting that the specific substrate for an enzyme with 'GO:0032451 demethylase activity' can be included in column 16?<br />
* Should we create terms like ‘ATP binding involved in kinase activity'?<br />
* What, if any, binding term annotations can be transferred via ISS/ISO?<br />
<br />
=Attendees=<br />
Airport codes: SFO = San Francisco International; SJC = San Jose International Airport<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! Arrival Date/Time to Airport (see codes above)<br />
! Departure Date/Time from Airport<br />
|-<br />
| Mike Cherry<br />
| GO / SGD<br />
| walking<br />
| <br />
|-<br />
| Judy Blake<br />
| GO / MGI<br />
| March 29 SFO<br />
| April 2 SFO<br />
|-<br />
| Suzi Lewis<br />
| GO / BBOP<br />
| Driving<br />
|<br />
|-<br />
| Chris Mungall<br />
| GO / BBOP<br />
| CalTrain<br />
|<br />
|-<br />
| Seth Carbon<br />
| GO / BBOP<br />
| Driving<br />
|<br />
|-<br />
| Amina Abdulla<br />
| GO / BBOP<br />
| Driving<br />
|<br />
|-<br />
| Amelia Ireland<br />
| GO / BBOP<br />
| Hitching a ride<br />
|<br />
|-<br />
| Kara Dolinski<br />
| GO / PPOD<br />
| TBA<br />
| TBA<br />
|-<br />
| Eva Huala<br />
| TAIR<br />
| March 29<br />
| April 2<br />
|-<br />
| Karen Eilbeck<br />
| SO (U of Utah)<br />
| San Jose 29th March<br />
| San Jose April 1 - evening<br />
|-<br />
| Barry Smith<br />
| SAB (U at Buffalo)<br />
| March 31 SFO<br />
| April 1 SFO<br />
|-<br />
| Tanya Berardini<br />
| TAIR<br />
| on site<br />
| on site<br />
|-<br />
| Donghui li<br />
| TAIR<br />
| on site<br />
| on site<br />
|-<br />
| Larry Hunter<br />
| SAB (U Colorado)<br />
| March 31 SFO<br />
| April 2 SFO<br />
|- <br />
|Paul Sternberg<br />
|WormBase and Caltech<br />
|San Jose<br />
|San Jose<br />
|-<br />
|Doug Howe<br />
|ZFIN<br />
|SFO March 29<br />
| <br />
|-<br />
|Dianna Fisk<br />
|SGD<br />
|on site<br />
|on site<br />
|-<br />
|Ben Hitz<br />
|SGD<br />
|on site<br />
|on site<br />
|-<br />
|Susan Tweedie<br />
|FlyBase<br />
|March 27 SFO<br />
|April 1 16:55 SFO<br />
|-<br />
|Jane Lomax<br />
|GO-EBI<br />
|March 29 SFO<br />
|April 2 SFO<br />
|-<br />
|Pascale Gaudet<br />
|dictyBase<br />
| <br />
| <br />
|-<br />
|Harold Drabkin<br />
|MGI<br />
|March 29th SFO<br />
|April TBA<br />
|-<br />
|Jim Hu<br />
|EcoliWiki<br />
|<br />
|<br />
|-<br />
|David Hill<br />
|GO/MGI<br />
|<br />
|<br />
|-<br />
|Stan Laulederkind<br />
|RGD<br />
|<br />
|<br />
|-<br />
|Monte Westerfield<br />
|ZFIN<br />
|April 1 SFO<br />
|<br />
|-<br />
|Selina Dwight<br />
|SGD<br />
|on site<br />
|on site<br />
|-<br />
|Kate Dreher<br />
|TAIR<br />
|on site<br />
|on site<br />
|-<br />
|Rama Balakrishnan<br />
|SGD<br />
|on site<br />
|on site<br />
|-<br />
|Stacia Engel<br />
|SGD<br />
|N/A<br />
|N/A<br />
|-<br />
|Ranjana Kishore<br />
|WormBase<br />
|March 29 San Jose<br />
|April 1 San Jose<br />
|-<br />
|Kimberly Van Auken<br />
|WormBase<br />
|TBD<br />
|TBD<br />
|-<br />
|Petra Fey<br />
|dictyBase<br />
|TBD<br />
|TBD<br />
|-<br />
|Peter D'Eustachio<br />
|Reactome / NYUMC<br />
|SJC 3/29 7:02 PM<br />
|SJC 4/1 10:25 PM<br />
|-<br />
|Serenella Ferro Rojas<br />
|UniProtKB/Swiss-Prot<br />
|March 29 SFO<br />
|April 4 SFO<br />
|-<br />
|Eurie Hong<br />
|SGD<br />
|on site<br />
|on site<br />
|-<br />
|Emily Dimmer<br />
|GOA<br />
|March 29 SFO<br />
|April 2 SFO<br />
|-<br />
|-<br />
|Tony Sawford<br />
|GOA<br />
|March 29 SFO<br />
|April 2 SFO<br />
|-<br />
|Karen Christie<br />
|SGD<br />
|on site<br />
|on site<br />
|-<br />
|Julie Park<br />
|SGD<br />
|on site<br />
|on site<br />
|-<br />
|}<br />
<br />
=Remote Attendees=<br />
Webex and Telephone Conferencing will be provided<br />
<br />
{| {{Prettytable}} class='sortable'<br />
|-<br />
! Name<br />
! Organization<br />
! email (needed to set up your remote access)<br />
! Attending GOC (March 30-31)<br />
! Attending SAB (April 1)<br />
! Calling in alone or in a group (with whom and from where, if known)<br />
|-<br />
|Midori Harris<br />
|EBI GO<br />
|midori at ebi dot ac dot uk<br />
|yes<br />
|yes<br />
|TBD<br />
|-<br />
| Jennifer Deegan<br />
| GO Editorial Office<br />
| jdeegan at ebi.ac.uk<br />
| Yes<br />
| Yes<br />
| Probably alone from home.<br />
|-<br />
| Ruth Lovering<br />
| BHF-UCL annotator<br />
| r.lovering at ucl.ac.uk<br />
| Yes<br />
| Yes<br />
| From home<br />
|-<br />
| Rachael Huntley<br />
| GOA Curator<br />
| huntley at ebi.ac.uk<br />
| Yes<br />
| Yes<br />
| From home.<br />
|-<br />
| Michelle Giglio<br />
| IGS, UMD<br />
| mgiglio at som.umaryland.edu<br />
| Yes<br />
| No<br />
| alone from work/home<br />
|-<br />
| Marcus Chibucos<br />
| IGS, UMD<br />
| mchibucos at som dot umaryland dot edu<br />
| Yes<br />
| No<br />
| alone from work/home<br />
|}<br />
<br />
<br />
----<br />
Return to [[Consortium_Meetings]] page</div>Juliephttps://wiki.geneontology.org/index.php?title=Lung_development_genes&diff=25315Lung development genes2010-03-08T22:24:51Z<p>Juliep: /* November 2009 targets */</p>
<hr />
<div>The MGI group supplied the initial gene set of 14 genes based on recent MGI PI interest in lung development.<br />
<br />
==November 2009 targets==<br />
<br />
Annotation Progress - - <font color ="red"> High priority targets are in red</font><br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!Panther ID <br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR13935<br />
|Ascl1<br />
|<br />
| -<br />
|<br />
| -<br />
|done(3)<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11486<br />
|<font color ="red">Fgf8/10</font><br />
|<br />
| -<br />
|<br />
| -<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11829<br />
|Foxa2 (also assigned in December)<br />
|<br />
| done(4)<br />
|<br />
| -<br />
| -<br />
|done(1)<br />
|done<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10071<br />
|Gata6<br />
|<br />
|<br />
|<br />
|done (1)<br />
|done(21)<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR19818<br />
|Gli2/3<br />
|<br />
| -<br />
|<br />
|done (2)<br />
| -<br />
|done(2)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24083<br />
|Hnf4a<br />
|<br />
| -<br />
|<br />
| -<br />
| -<br />
|done(2)<br />
|done<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24416<br />
|Kdr<br />
|<br />
| -<br />
|<br />
| -<br />
| -<br />
|<br />
|done<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24340<br />
|Nkx2-1<br />
|<br />
| -<br />
|<br />
| -<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10796<br />
|Ptch1<br />
|<br />
| done(1)<br />
|<br />
|done (2)<br />
|done(2)<br />
|done(3)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24082<br />
|Rara<br />
|<br />
| -<br />
|<br />
| -<br />
| -<br />
|done(3)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10270<br />
|Sox18 (Sox8?)<br />
|<br />
| done(1)<br />
|<br />
|done(5)<br />
|done(1)<br />
|done(2)<br />
|done<br />
|<br />
|<br />
|done<br />
|done<br />
|done (4)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR12025<br />
|Vegfa<br />
|<br />
| -<br />
|<br />
| -<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=Lung_branching_morphogenesis_genes_(Archived)&diff=25203Lung branching morphogenesis genes (Archived)2010-03-04T16:37:29Z<p>Juliep: /* Annotation Progress */</p>
<hr />
<div>This set of genes was selected to support knowledge representation for the biological process of ‘branching involved in lung morphogenesis’. The MGI group supplied the initial gene set of 12 genes based on recent MGI PI interest in branching morphogenesis and lung development. The branching terminology has been recently updated, and curation of mouse papers concerned with branching morphogenesis resulted in the gene set provided here. The set of 12 genes contributing to this biological process is thus considered complete at this time. Because two of the 12 genes [Shh and Fgf10] had previously been selected for comprehensive annotation, they are not included in Dec 2009 target list.<br />
<br />
==December 2009 targets==<br />
<br />
==Annotation Progress==<br />
<font color ="red"> High priority targets are in red</font><br />
<br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!Panther ID <br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR21559<br />
|Dag1<br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|done (1 of 4)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11829<br />
|<font color ="red">Foxf1a</font> (family also assigned in November 2009)<br />
|<br />
| done(4)<br />
|<br />
| no Dicty<br />
| -<br />
|done(1)<br />
|done<br />
|<br />
|<br />
|<br />
|<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24316<br />
|<font color ="red">Rdh10</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|done<br />
|done(3)<br />
|<br />
|done<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11848<br />
|Bmp4<br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24324<br />
|<font color ="red">Hhex</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|done(1)<br />
|No D.rerio<br />
|<br />
|<br />
|done<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24326<br />
|Hoxa5<br />
|<br />
|done<br />
|<br />
| no Dicty<br />
|done(2)<br />
|done(1)<br />
|<br />
|<br />
|<br />
|done<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR23315<br />
|Ctnnb1<br />
|<br />
|done<br />
|<br />
| no Dicty<br />
|done(2)<br />
|done (1)<br />
|<br />
|<br />
|done<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR12027<br />
|<font color ="red">Wnt2/2b</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10574<br />
|<font color ="red">Lama1</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|No elegans<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=January/February_2010_lung_targets&diff=25167January/February 2010 lung targets2010-03-02T16:23:37Z<p>Juliep: /* January/February 2010 targets */</p>
<hr />
<div>==January/February 2010 targets==<br />
<br />
Annotation Progress - <font color ="red"> High priority targets are in red</font><br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!link to family members<br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|http://wiki.geneontology.org/index.php/ACER2<br />
|<font color ="red">ACER2</font><br />
| <br />
| done (2)<br />
|<br />
| 2 genes - no EXP<br />
| done (2)<br />
| <br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ADCY7<br />
|<font color ="red">ADCY7</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ALOX5AP_RefG<br />
|<font color ="red">ALOX5AP</font><br />
|<br />
| -<br />
|<br />
| 1 gene - no EXP<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ANGPT1<br />
|<font color ="red">ANGPT1</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/ANXA3<br />
|<font color ="red">ANXA3</font><br />
|<br />
| -<br />
|<br />
| 1 gene - done<br />
| done (2)<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/AQP1<br />
|<font color ="red">AQP1<br />
|<br />
| -<br />
|<br />
| 5 genes no EXP (aqpA, wacA, done)<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/CDKN2 <br />
|<font color ="red">CDKN2A, CDKN2B</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (3)<br />
|-<br />
|http://wiki.geneontology.org/index.php/COL4A4<br />
|<font color ="red">COL4A4</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/DUSP6<br />
|<font color ="red">DUSP6</font><br />
|<br />
| done (4)<br />
|<br />
| 2/7 have EXP, mpl1 done, dupA to finish<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/ENG_RefG<br />
|<font color ="red">ENG</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/GSTT1<br />
|GSTT1<br />
|<br />
| -<br />
|<br />
| 2 genes - no EXP<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/HMGB2<br />
|HMGB2<br />
|<br />
|<br />
|<br />
| 1 gene, no EXP<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PLEKHA2<br />
|<font color ="red">PLEKHA2</font><br />
|<br />
| -<br />
|<br />
|1 gene, no EXP<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/S100A13<br />
|<font color ="red">S100A13</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (2)<br />
|-<br />
|http://wiki.geneontology.org/index.php/SERPINB9<br />
|<font color ="red">SERPINB9</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/SERPINE1<br />
|SERPINE1<br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/TAP2_RefG<br />
|<font color ="red">TAP2</font><br />
|<br />
| done (2)<br />
|<br />
| 2 genes (tagA, abcB1), to do<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/THBS3<br />
|<font color ="red">THBS3</font><br />
|<br />
| -<br />
|<br />
| no Dicty<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (3)<br />
|-<br />
|}<br />
----<br />
Back to [[Reference_Genome_Annotation_Project Reference Genome Main Page]]</div>Juliephttps://wiki.geneontology.org/index.php?title=9_FEB_2010_RefGen_Phone_Conference_(Archived)&diff=247869 FEB 2010 RefGen Phone Conference (Archived)2010-02-08T16:10:34Z<p>Juliep: /* Plan for annotation status reporting tool */</p>
<hr />
<div>==ACTION ITEMS==<br />
'''ALL GROUPS: '''<br />
Please fill three sections here: <br />
# Annotation Status of lung curation targets[[9_FEB_2010_RefGen_Phone_Conference#Lung_curation_targets]]<br />
# Who captures the 'comprehensive annotation' status?[[9_FEB_2010_RefGen_Phone_Conference#Plan_for_annotation_status_reporting_tool]]<br />
# Please describe How_is_your_group_Publicizing_Ref.Genome annotation here: [[Ideas_for_publicizing_Ref.Genome_Annotation_Data#How_is_your_group_Publicizing_Ref.Genome_Data]]<br />
<br />
==Present==<br />
* GOA: <br />
* BHF-UCL: <br />
* MGI:<br />
* RGD: <br />
* Flybase: <br />
* dictyBase: <br />
* TAIR: <br />
* AgBase:<br />
* SGD:<br />
* pombe<br />
* Ecoli: <br />
* Wormbase: <br />
* ZFIN:<br />
* PPOD: <br />
* Berkeley:<br />
----<br />
==Lung curation targets==<br />
# Discuss the priorities (Dec, Jan, and fgf10 from November) and goal (March 1st) <br />
# <font color= "red"> Please answer prior to the call</font>: Can everyone have the curation targets annotated by then? If not, can you write down which families are problematic?<br />
* GOA: We will have a good stab at getting most of them done, the most problematic will be those with many publications; DAG1, GSTT1, SerpineE1 and E2. We will try to get at least some annotations for each aspect on all of them by March 1st though.<br />
* BHF-UCL: <br />
* MGI:<br />
* RGD: The genes on the lists have been curated.<br />
* FlyBase: The Dec genes BMP4, CTNNB1 and HOXA5 are a problem for me as the fly orthologs (decapentaplegic, Antennapedia, bicoid and armadillo) are among the most intensively studied fly genes having 500 to <1000 pubs each. I'll do my best to curate the key features. I haven't started the Jan targets yet but there doesn't seem to be much info for most of the 32 genes so I hope it will possible to complete these by March 1st The other problem we have is that it takes a month or two for my annotations to make it into the public version of FlyBase and then into the ga file so even if the annotations are done by March 1st they won't necessarily be visible to the paint annotators. <br />
* dictyBase: We expect that we will be able to complete the lung targets by March 1st.<br />
* TAIR: <br />
* AgBase:<br />
* SGD:The HMGB2 targets may not be done by then. The curators who are working on them have said that even if they are not done by March 1st, they will be done within a week or two after that.<br />
* pombe<br />
* Ecoli: <br />
* Wormbase: We expect that we will be able to complete the lung targets by March 1st.<br />
* ZFIN:<br />
<br />
==PAINT demo==<br />
Ed Lee, Berkeley<br />
<br />
==Plan for annotation status reporting tool==<br />
Kara and her group have started to work on a tool that would display the annotation status of the Panther families. There will be a regularly updated web page that will show the following information: <br />
<br />
# Panther family ID <br />
# Date selected for concurrent annotation <br />
# Date Panther family last annotated (tree annotations) <br />
# Number of members <br />
# Number of RefG members <br />
# Number of members with EXP <br />
# Date more recent member last annotated<br />
# We could add 'date comprehensively annotated' for groups that can provide this information: <br />
<br />
<font color = "red">Please answer prior to the call</font>: who currently captures the 'date comprehensively annotated' and could generate a file with such information. <br />
* GOA: Yes<br />
* BHF-UCL: <br />
* MGI:<br />
* RGD: We don't capture that information.<br />
* Flybase: <br />
* dictyBase: Yes (we capture curation status for the entire 'gene' curation, but could use that for now)<br />
* TAIR: <br />
* AgBase:<br />
* SGD: We capture this date, but cannot generate a file at this time. We would be able to provide this date eventually.<br />
* pombe<br />
* Ecoli: <br />
* Wormbase:We capture the date at which we've comprehensively annotated experimental data for RefGenome genes. <br />
* ZFIN:<br />
<br />
<br />
* Alerts: <br />
** Tree curators should be alerted when the Date in Column 7 (protein annotations by MODs) is more recent than the date in Column 3 (tree annotation). <br />
** When the Panther families are modified (once-twice per year), there should be a check to verify that the members are still the same. If there are additions or deletions: there should be an alert for curators annotations. We may be able to automate part of the required modifications to annotations. <br />
<br />
* Annotations to nodes: All the previous part of the script is just a report based on the trees and the GAF files. However in some cases we annotate to nodes rather to entire trees. There needs to be a way to request a report for a specific tree node. This will be done as a second step.<br />
<br />
==Branding Ref.genome annotation data in GOC and within each group==<br />
<br />
Rama started a wiki page to collect ideas. <font color = "red">Use this page to describe how your group is branding reference genomes and to provide suggestions.</font><br><br />
Please also take a look at ref.genome annotation data in AmiGO and provide feedback to improve those.<br />
<br />
http://gocwiki.geneontology.org/index.php/Ideas_for_publicizing_Ref.Genome_Annotation_Data<br />
<br />
==GO annotation camp==<br />
# '''Overview''': The annotation camp will take place over 3 days, from June 16-18 (Wednesday-Friday). <br />
# '''Goals''': This annotation camp will be focused on updating and refining skills of existing GO biocurators including new GO biocurators in existing annotation groups and including the Swiss-Prot curation team. We hope members of each MOD will be represented. <br />
# '''Structure''': There will be '''three (3) ‘focused annotation sessions’''' where specific annotation issues will be discussed. Suggestion for discussion topics should be added to the GO camp agenda: [[2010_GO_camp_Meeting_Logistics#Suggestions_for_annotation_issues_to_be_discussed]]<br />
# '''Deliverables''': (1) final annotation documentation for each of the three annotation topics. <br />
#*There will be a special emphasis on the reference genome project. Deliverable: (2) annotation propagation rules for the reference genome project. <br />
#Registration: If you already know whether you'll be able to attend or not, please fill the wiki meeting logistics page: [[2010_GO_camp_Meeting_Logistics]]<br />
<br />
<br />
----<br />
Back to Reference Genome [[Conference_Calls]] Page</div>Juliephttps://wiki.geneontology.org/index.php?title=9_FEB_2010_RefGen_Phone_Conference_(Archived)&diff=247829 FEB 2010 RefGen Phone Conference (Archived)2010-02-08T16:00:44Z<p>Juliep: /* Lung curation targets */</p>
<hr />
<div>==ACTION ITEMS==<br />
'''ALL GROUPS: '''<br />
Please fill three sections here: <br />
# Annotation Status of lung curation targets[[9_FEB_2010_RefGen_Phone_Conference#Lung_curation_targets]]<br />
# Who captures the 'comprehensive annotation' status?[[9_FEB_2010_RefGen_Phone_Conference#Plan_for_annotation_status_reporting_tool]]<br />
# Please describe How_is_your_group_Publicizing_Ref.Genome annotation here: [[Ideas_for_publicizing_Ref.Genome_Annotation_Data#How_is_your_group_Publicizing_Ref.Genome_Data]]<br />
<br />
==Present==<br />
* GOA: <br />
* BHF-UCL: <br />
* MGI:<br />
* RGD: <br />
* Flybase: <br />
* dictyBase: <br />
* TAIR: <br />
* AgBase:<br />
* SGD:<br />
* pombe<br />
* Ecoli: <br />
* Wormbase: <br />
* ZFIN:<br />
* PPOD: <br />
* Berkeley:<br />
----<br />
==Lung curation targets==<br />
# Discuss the priorities (Dec, Jan, and fgf10 from November) and goal (March 1st) <br />
# <font color= "red"> Please answer prior to the call</font>: Can everyone have the curation targets annotated by then? If not, can you write down which families are problematic?<br />
* GOA: We will have a good stab at getting most of them done, the most problematic will be those with many publications; DAG1, GSTT1, SerpineE1 and E2. We will try to get at least some annotations for each aspect on all of them by March 1st though.<br />
* BHF-UCL: <br />
* MGI:<br />
* RGD: The genes on the lists have been curated.<br />
* FlyBase: The Dec genes BMP4, CTNNB1 and HOXA5 are a problem for me as the fly orthologs (decapentaplegic, Antennapedia, bicoid and armadillo) are among the most intensively studied fly genes having 500 to <1000 pubs each. I'll do my best to curate the key features. I haven't started the Jan targets yet but there doesn't seem to be much info for most of the 32 genes so I hope it will possible to complete these by March 1st The other problem we have is that it takes a month or two for my annotations to make it into the public version of FlyBase and then into the ga file so even if the annotations are done by March 1st they won't necessarily be visible to the paint annotators. <br />
* dictyBase: <br />
* TAIR: <br />
* AgBase:<br />
* SGD:The HMGB2 targets may not be done by then. The curators who are working on them have said that even if they are not done by March 1st, they will be done within a week or two after that.<br />
* pombe<br />
* Ecoli: <br />
* Wormbase: We expect that we will be able to complete the lung targets by March 1st.<br />
* ZFIN:<br />
<br />
==PAINT demo==<br />
Ed Lee, Berkeley<br />
<br />
==Plan for annotation status reporting tool==<br />
Kara and her group have started to work on a tool that would display the annotation status of the Panther families. There will be a regularly updated web page that will show the following information: <br />
<br />
# Panther family ID <br />
# Date selected for concurrent annotation <br />
# Date Panther family last annotated (tree annotations) <br />
# Number of members <br />
# Number of RefG members <br />
# Number of members with EXP <br />
# Date more recent member last annotated<br />
# We could add 'date comprehensively annotated' for groups that can provide this information: <br />
<br />
<font color = "red">Please answer prior to the call</font>: who currently captures the 'date comprehensively annotated' and could generate a file with such information. <br />
* GOA: Yes<br />
* BHF-UCL: <br />
* MGI:<br />
* RGD: We don't capture that information.<br />
* Flybase: <br />
* dictyBase: Yes (we capture curation status for the entire 'gene' curation, but could use that for now)<br />
* TAIR: <br />
* AgBase:<br />
* SGD:<br />
* pombe<br />
* Ecoli: <br />
* Wormbase:We capture the date at which we've comprehensively annotated experimental data for RefGenome genes. <br />
* ZFIN:<br />
<br />
<br />
* Alerts: <br />
** Tree curators should be alerted when the Date in Column 7 (protein annotations by MODs) is more recent than the date in Column 3 (tree annotation). <br />
** When the Panther families are modified (once-twice per year), there should be a check to verify that the members are still the same. If there are additions or deletions: there should be an alert for curators annotations. We may be able to automate part of the required modifications to annotations. <br />
<br />
* Annotations to nodes: All the previous part of the script is just a report based on the trees and the GAF files. However in some cases we annotate to nodes rather to entire trees. There needs to be a way to request a report for a specific tree node. This will be done as a second step.<br />
<br />
==Branding Ref.genome annotation data in GOC and within each group==<br />
<br />
Rama started a wiki page to collect ideas. <font color = "red">Use this page to describe how your group is branding reference genomes and to provide suggestions.</font><br><br />
Please also take a look at ref.genome annotation data in AmiGO and provide feedback to improve those.<br />
<br />
http://gocwiki.geneontology.org/index.php/Ideas_for_publicizing_Ref.Genome_Annotation_Data<br />
<br />
<br />
<br />
----<br />
Back to Reference Genome [[Conference_Calls]] Page</div>Juliephttps://wiki.geneontology.org/index.php?title=Lung_branching_morphogenesis_genes_(Archived)&diff=24586Lung branching morphogenesis genes (Archived)2010-02-01T20:16:07Z<p>Juliep: </p>
<hr />
<div>This set of genes was selected to support knowledge representation for the biological process of ‘branching involved in lung morphogenesis’. The MGI group supplied the initial gene set of 12 genes based on recent MGI PI interest in branching morphogenesis and lung development. The branching terminology has been recently updated, and curation of mouse papers concerned with branching morphogenesis resulted in the gene set provided here. The set of 12 genes contributing to this biological process is thus considered complete at this time. Because two of the 12 genes [Shh and Fgf10] had previously been selected for comprehensive annotation, they are not included in Dec 2009 target list.<br />
<br />
==December 2009 targets==<br />
<br />
==Annotation Progress==<br />
<br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!Panther ID <br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR21559<br />
|Dag1<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|done<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11829<br />
|Foxf1a (family also assigned in November 2009)<br />
|<br />
| <br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24316<br />
|Rdh10<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11848<br />
|Bmp4<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24324<br />
|Hhex<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24326<br />
|Hoxa5<br />
|<br />
|done<br />
|<br />
|<br />
|done(2)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR23315<br />
|Ctnnb1<br />
|<br />
|done<br />
|<br />
|<br />
|done(2)<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR12027<br />
|Wnt2/2b<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10574<br />
|Lama1<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=Lung_branching_morphogenesis_genes_(Archived)&diff=24577Lung branching morphogenesis genes (Archived)2010-02-01T18:53:02Z<p>Juliep: </p>
<hr />
<div>This set of genes was selected to support knowledge representation for the biological process of ‘branching involved in lung morphogenesis’. The MGI group supplied the initial gene set of 12 genes based on recent MGI PI interest in branching morphogenesis and lung development. The branching terminology has been recently updated, and curation of mouse papers concerned with branching morphogenesis resulted in the gene set provided here. The set of 12 genes contributing to this biological process is thus considered complete at this time. Because two of the 12 genes [Shh and Fgf10] had previously been selected for comprehensive annotation, they are not included in Dec 2009 target list.<br />
<br />
==December 2009 targets==<br />
<br />
==Annotation Progress==<br />
<br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!Panther ID <br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR21559<br />
|Dag1<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|done<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11829<br />
|Foxf1a (family also assigned in November 2009)<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24316<br />
|Rdh10<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR11848<br />
|Bmp4<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24324<br />
|Hhex<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR24326<br />
|Hoxa5<br />
|<br />
|done<br />
|<br />
|<br />
|done(2)<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR23315<br />
|Ctnnb1<br />
|<br />
|done<br />
|<br />
|<br />
|done(2)<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR12027<br />
|Wnt2/2b<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|done<br />
|<br />
|-<br />
|http://wiki.geneontology.org/index.php/PTHR10574<br />
|Lama1<br />
|<br />
| -<br />
|<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done (1)<br />
|-<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=Lung_branching_morphogenesis_genes_(Archived)&diff=24338Lung branching morphogenesis genes (Archived)2010-01-25T18:35:40Z<p>Juliep: </p>
<hr />
<div>This set of genes was selected to support knowledge representation for the biological process of ‘branching involved in lung morphogenesis’. The MGI group supplied the initial gene set of 12 genes based on recent MGI PI interest in branching morphogenesis and lung development. The branching terminology has been recently updated, and curation of mouse papers concerned with branching morphogenesis resulted in the gene set provided here. The set of 12 genes contributing to this biological process is thus considered complete at this time. Because two of the 12 genes [Shh and Fgf10] had previously been selected for comprehensive annotation, they are not included in Dec 2009 target list.<br />
<br />
<br />
Annotation Progress<br />
<br />
{|border="1" cell spacing="0" cellpadding="5" align="center"<br />
!Panther ID <br />
!set label<br />
!E.coli<br />
!SGD <br />
!S. pombe<br />
!dictyBase<br />
!TAIR<br />
!WormBase<br />
!Zebrafish<br />
!FlyBase<br />
!Chicken<br />
!MGI<br />
!RGD<br />
!Human<br />
|-<br />
|PTHR21559<br />
|Dag1<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|PTHR11829<br />
|Foxf1a<br />
|family also assigned in November 2009<br />
|-<br />
|PTHR24316<br />
|Rdh10<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|PTHR11848<br />
|Bmp4<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done<br />
|<br />
|-<br />
|PTHR24324<br />
|Hhex<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|PTHR24326<br />
|Hoxa5<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|done<br />
|<br />
|-<br />
|PTHR23315<br />
|Ctnnb1<br />
|<br />
|done<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|PTHR12027<br />
|Wnt2/2b<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-<br />
|PTHR10574<br />
|Lama1<br />
|<br />
| -<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|<br />
|done<br />
|<br />
|-</div>Juliephttps://wiki.geneontology.org/index.php?title=Survey_Handling_PAINT-generated_GAF_(Archived)&diff=24215Survey Handling PAINT-generated GAF (Archived)2010-01-13T18:03:29Z<p>Juliep: </p>
<hr />
<div>This survey was done to assess how every participating database was handling GAF files and to see how the PAINT annotations would be integrated. <br />
<br />
November 2009 <br />
<br />
{| {{Prettytable}} class='sortable' align='top'<br />
|-<br />
!database <br />
!ZFIN <br />
!MGI <br />
!FlyBase <br />
!TAIR <br />
!RGD <br />
!dictybase <br />
!GOA <br />
!EcoWiki <br />
!Wormbase <br />
!GeneDB (S.pombe) <br />
!SGD <br />
!AgBase <br />
|-<br />
|contact person <br />
|Doug<br />
|Harold<br />
|Susan<br />
|Tanya<br />
|Stan<br />
|Pascale<br />
|Emily<br />
|Daniel Renfro & Brenley McIntosh<br />
|Ranjana<br />
|Val Wood<br />
|Julie<br />
|Fiona<br />
|-<br />
| Do you currently upload GAF files from external sources, such as from GOA? <br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| No<br />
| Yes<br />
| Yes<br />
| Yes<br />
| yes<br />
| yes<br />
| yes<br />
|-<br />
| frequency of incorporation of external GAF files? <br />
| Monthly (or more often)<br />
| Monthly (or more often)<br />
| ad hoc<br />
| ad hoc<br />
| Monthly (or more often)<br />
| Not applicable<br />
| Monthly (or more often)<br />
| Monthly (or more often)<br />
| Monthly (or more often)<br />
| Monthly (or more often)<br />
| Monthly (or more often)<br />
| Quarterly<br />
|-<br />
| Do you expect your your database to run manual and/or automated verifications (redundancies, quality of annotations) before integrating the GAFs that will be provided by ref genome?<br />
| Yes, We may like to only accept ISS annotations from PAINT that are not trumped by experimentally supported annotations to more granular terms...though we do not currently have the facilites in our database to do this type of check. Soon we should though.<br />
| Yes, redundancy only for automated; depending on the size of the GAF, some manual inspection may initially be done, but at some point we will need to feel confident enough to forgo this, as we cannot afford the curator time.<br />
| Yes, Manual verification of quality (in the first instance at least). It is less of a priority to eliminate redundancy for the new PANTHER annotations. I plan to add these even if we have an existing ISS for the same term - the PAINT annotations are arguably based on stronger evidence than most of our existing pairwise annotations. There is a argument for excluding then if we already have experimental evidence for the same term but since they wouldn't be wrong there isn't much point. For other GAFs we do not load new annotations with NAS, TAS evidence codes or annotations that are completely redundant with existing annotations - i.e. same term, same gene, same pub, same evidence. If we find conflicting annotations for the same publication then we try to resolve them with the other source.<br />
| Yes, We remove IEA annotations, since we do our own IEA analyses. We also check for redundancies by comparing ids for the object annotated (UniProt ID vs. TAIR id using mapping file), the GO id, evidence code and reference (based on PMID). Only non-redundant, non-IEA and mapped annotations are attached to the GAF file that we check into the GO cvs.<br />
| Not applicable<br />
| Yes, We will want to put a script that removes redundant annotations, and have the possibility to verify the PAINT annotations (the current visualization tools such as GO-nuts should be enough)<br />
| Yes, manual checks of the correctness of the GO terms applied in the annotation set automatic checks to ensure that primary UniProtKB accessions are used. we are not intending that redundant annotations will be removed from our files, as our other electronic annotation pipelines already generate redundant GO annotations. The web-based display of annotations will be filtered however.<br />
| Yes, Redundancies. Check for validity to prokaryotic organisms (ie no mitochondrial terms).<br />
| Yes, We remove redundant and electronic annotations.<br />
| yes, I plan to filter the ref geneome annotations against existing non-IEA annotation. After import I will run quality control checks to evaluate the remaining annotations (I expect that most will already be annotated)<br />
| No, At this point we do not plan to individually review the RefGenome annotations, but instead will incorporate them all without review and display them in the computational section of our GO pages. This is also how we treat other predicted annotations such as the GOA IEAs and other tool-based predictions. As the number of PAINT annotations accumulate and we have a sense of how many and what kind of annotations we will actually be dealing with on a monthly basis, SGD plans to revisit the question of whether or not to review the PAINT annotations. For our review process of a subset of the GOA annotations, please see the comments under question 5.<br />
| Not applicable<br />
|-<br />
| Do you have a script that loads these annotations into your MOD?<br />
| Actually, we do not load GOA annotations into ZFIN. You won't find them in our database. We append those annotations to the end of our GAF each week..so they appear in AmiGO..but not in ZFIN. We hope to rectify this at the same time we prepare scripts to load PAINT annotations into ZFIN.<br />
| Yes, script does this; complicated regime because their annotation object is always a uniprot id, and ours is a gene. GOA is loaded as follows: 1. Does UniProt ID exist in MGI 1. if yes proceed to 2 2. if no, append to GAF (note, direct annotation to isoforms (Q12345-1) is not supported at this time 2. Does annotation have PMID 1. if no, do not load; append to GAF 2. if yes does it match one in MGI? 1. if no, cannot load; put to qc to get PMID into db 2. if yes proceed to next 3. Does annotation duplicate already existing 1. if not, add but NOT if evidence code is IEP (MGI does not use IEP); append to GAF 2. if yes (match needs to be GO _ID, PMID, evidence code) skip; do not append to GAF NO IEAs are loaded because the method used is identical to MGIs (UniProt Keyword and Interpro domain mapping).<br />
| No, We are currently working on a script to automate this system. The plan is that the ref genome annotations will be loaded via this script. Previously we have been sent notification of new annotations from UniProtKB and these have been added via our standard pipleine after manual checks.<br />
| No, Right now, we do not load GOA annotations into our database, we append their annotations to ours and check the combined GAF file into the GO cvs.<br />
| No <br />
| Yes, The GOA pipeline imports the GOA_RAT file from the GOA website, uses the UniProtKB or RefSeq protein ID to match the incoming annotation to an RGD gene record. Once a match has been made, it checks to make sure the annotation isn't already in our db and loads the annotation into the correct table using the matched RGD ID as the DB_ID. Annotations from the file that would be duplicates in our database (i.e. one gene corresponds to multiple proteins each containing the same annotation) are stored and concatenated onto the end of the outgoing gene_association.rgd file as is. For annotation that are loaded into RGD, the DB field (column 1) becomes RGD in the outgoing GAF but the Assigned_by field (column 15) goes into our db and is exported from our database unchanged (so annotations that come from UniProtKB still have an assigned by designation of UniProtKB in the gene_association.rgd file.<br />
| Yes, GAFs are automatically loaded into the GOA Oracle database, gp2protein files are used to map MOD identifiers to UniProtKB accessions.<br />
| Yes, Perl scripts prepare data and then loaded by PHP script.<br />
| No, Currently we are not loading any external annotations into our database.<br />
| yes, We have scripts to load GAFs, but they need to have the dtabase and database identifier (column 1&2) specified as GeneDB, and the GeneDB identifier.<br />
| Yes, We have different pipelines for the GOA IEAs versus other GOA annotations. *IEAs (~once a month, tens of thousands) We have a script that retrieves the gene_association.goa_uniprot.gz file and filters it to get only IEA annotations for the taxon ID 4932 (S. cerevisiae). The output file is still in gene association file format. We then compare that file to the file generated from the previous month's release and remove from SGD all the annotations that do not appear in the current release. We then run a loading script on the current file that takes the most recent IEA file and either adds new annotations to the database or updates the date associated with any annotations already existing in the database. Our loading script can accept either the SGDID or the UniProt ID in column 2, converting all UniProt IDs into the SGDID. Also, our script is able to accept column 1 from the incoming file as 'UniProtKB' but this gets converted to 'SGD' in the gene_associations files we submit. *non-IEA annotations (~once a quarter, a few dozen) We have a script that retrieves the gene_association.goa_uniprot.gz file and filters for the following criteria: 1. only retrieve annotations with taxon 4932 (S. cerevisiae 2. NO annotations from SGD 3. NO IEA annotations 4. NO annotations by IntAct using IPI evidence to protein binding (GO:0005515) A second script is run on this output file comparing it to the previous quarter's file to retrieve only new annotations made in the last quarter. These new annotations are divided amongst a couple of SGD curators who go through and review each annotation to see if they meet the standards for the core manual set of SGD annotations and are correct (evidence code, term choice). During our review process we mark the reviewed annotation in one of three ways: Y we accept the GOA annotations, N if we do not accept their annotation, and R if we want GOA to review their annotation. We also try to comment on why the annotation was classified as Y/N/R. -Y: if their annotation is completely correct and we don't have that annotation at SGD. We can accept their annotation even if we have an annotation to the same term but from a different paper. -N: if we have the exact same annotation or if the annotation cannot be made from the paper they chose (not enough evidence, gene name not mentioned in paper etc) or if we have an annotation from the same paper but to a more granular term or the reference is not a published journal article or the evidence code is not one of the experimental ones. -R: if we think they almost have the right annotation, but a different evidence code fits the experiment, if we think they have a typo in the PMID, etc. We send a file with the N and R annotations back to Emily at GOA. For the Y annotations we manually put them into a GAF file and load them into SGD using the same loading script as we use for the IEAs.<br />
| yes<br />
|-<br />
| Are those external annotations displayed on your web pages for GO annotations? <br />
| No<br />
| yes<br />
| yes<br />
| no<br />
| yes<br />
| no<br />
| yes<br />
| yes<br />
| no <br />
| yes<br />
| yes<br />
| yes<br />
|-<br />
| Do you display the original source of the annotation (column 15)? <br />
| No, Currently, all the annotations found in ZFIN originated at ZFIN...so we do not show the source. However, if we started loading externally provided annotations into our databse, we would make every attempt to make the source information available. The references are provided for each GO annotation as a direct link to the originating pub record in our database or internal pub describing the annotation method. For the PAINT annotations we could link to a pub in the GO pub set or a PMID or an internal reference describing the PAINT annotation process.<br />
| No, We display only Aspect, GO term (with link to browser), evidence qualifier, evidence, with, and reference. Column 15 that we give to GO does display proper source.<br />
| yes, The original source is only displayed if it is external. References are displayed in an abbreviated (first author, year) format - this is hyperlinked to an internal reference report page which displays pubmed IDs where available (these are also linked-out to pubmed.<br />
| No, Annotations from GOA are not displayed on TAIR's web pages at the moment.<br />
| Yes, For annotations that are loaded into RGD, the DB field (column 1) becomes RGD in the outgoing GAF but the Assigned_by field (column 15) goes into our db and is exported from our database unchanged (so annotations that come from UniProtKB still have an assigned by designation of UniProtKB in the gene_association.rgd file. The reference column has an RGD ID which identifies the GOA pipeline as the source of the information.<br />
| yes, we would/will do<br />
| yes, External GO annotations are mapped to UniProtKB accession. Therefore columns 1 and 2 will differ from that of the external MOD. In addition, GOA standardizes the gene symbol, protein name and synonyms displayed in columns 3,10 and 11; using UniProtKB data. Where a MOD pipes together an internal reference and PubMed identifier in the reference column, GOA only displays the PubMed identifier. Currently only the external annotations which apply a PubMed identifier are integrated. Although we are intending to increase the scope of integrations, and in future include other sources of external annotation.<br />
| No, In table format, we display (as the column headers): Qualifier, GO ID, GO term name, Reference(s), Evidence Code, with/from, Aspect, Notes & Status. Status column says "complete" if a valid GO ID, reference and evidence code are provided.<br />
| No<br />
| no, we do not supply source for any external mappings, reference is provided through the IEA (GO_REF:0000002) with InterPro:IPR001394(hyperlinked) IEA (GO_REF:0000004) with SP_KW:KW-0788(hyoperlinked) etc.<br />
| yes, Annotations are displayed with a "Last update date" listed followed by the information: GO ID GO Term Name Evidence Qualifier Assigned By<br />
|-<br />
| Does the annotations from the external GAFs appear in your GAF file that gets submitted to the GO database? <br />
| Yes<br />
| Yes<br />
| yes<br />
| yes<br />
| yes<br />
| no<br />
| yes<br />
| no <br />
| yes<br />
| yes<br />
| yes<br />
| yes<br />
|-<br />
| What appears in your GAF file as the annotation source for annotations originally coming from external sources? <br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
| The original contributor<br />
|-<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1640920th GO Consortium Meeting Minutes2008-10-22T21:18:19Z<p>Juliep: /* Michael: text-mining ontologies */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
(everybody) SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* The sometimes_is_part relationship was agreed as a good idea. We should try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators) <br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
(tanya) Send out function process email again.<br />
(chris) Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
organization<br />
-[i] assembly<br />
-[i] disassembly<br />
-[i] maintenance<br />
-[i] morphogensis<br />
biogenesis<br />
-[p] assembly<br />
-[p] part biosynthesis<br />
</pre><br />
====ACTION ITEM====<br />
(ontology dev) Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
Pursue an ontology development meeting one or two:<br />
(Brenley, Kimberley, Candice, Michelle, Jane) Viral processes<br />
(Pascale, David, ???) GPCR<br />
(?) A couple of GO meeting with major meetings on these topics<br />
(?) Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
(?) remove sensu synonyms<br />
(Jen) Continue implementation of trigger system<br />
(Dan) Make GOA quickgo checking available to the public<br />
(?) write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Evidence code ontology (ECO) (Michelle) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
(suzi) We will use the ECO and create an EV code ontology tracker<br />
(everybody) people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
In principle, most everyone was supportive of the idea to separate the evidence used to make the annotation and the curation method to make that annotation. There was, however, much discussion on the scope and implementation of this proposal.<br />
<br />
Two implementation methods were proposed:<br />
# A new column that contains a text describing the annotation process<br />
# Creating a cross-product between the evidence code branch of the ECO and a methods branch of the ECO. This ID would be used in the GAF.<br />
<br />
Because proposal 2 does not create a new column and is expandable to multiple combinations, it was favored.<br />
<br />
Proposed methods were not agreed upon but words that were used to describe included<br />
*curator reviewed<br />
*not curator reviewed<br />
*electronic<br />
*manual<br />
<br />
A direct consequence of this would be that IEA would go away. Emily proposed the following mappings:<br />
*Interpro2GO -> ISS/ISM, not reviewed<br />
*keyword mappings -> TAS, not reviewed<br />
<br />
IEAs are stripped out after a year. How would those "not curator reviewed' be treated? Since the intent was to remove annotations based on sequences, maybe only those should be removed because they can be easily recomputed. Large-scale/high-volume/high-throughput experiments won't be repeated but still are experimental. We would have to consider exceptions for these.<br />
<br />
There was some discussion about what users wanted and how users were taking advantage of the evidence codes. There is a range - some people just strip evidence codes and do not consider them. However, others would take advantage of additional levels of information. Both advisors mentioned that what users wanted was a level of confidence. This, however, would be difficult to do.<br />
<br />
It was agreed that multiple issues need to be considered when dealing with this new qualifier of evidence codes:<br />
# the experimental evidence <br />
# was there judgement involved<br />
# was there a review of the data<br />
<br />
===ACTION ITEM=== <br />
(Suzi, Michelle, Judy, Pascale, Emily, Eurie) Example cases of annotations and implementation into the ECO<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
(everybody) go ahead with the implementation of the expressive model in column 16<br />
* get more examples <br />
* get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
<br />
= Reference Genome =<br />
<br />
== How curators can use evo trees (Paul) ==<br />
(has slides)<br />
<br />
Paul presented a proposal for the new process. Highlights of new process include the following:<br />
* Trees will be overlayed with the OrthoMCL "ortholog clusters" to find "equivalogs" - the equivalent gene in all organisms.<br />
* Finding these groups will allow annotations to be inferred to the shared ancestor protein<br />
* Annotations can then be propagated to the extant protein so that annotations are concurrent and consistent in the context of the evolutionary tree.<br />
* There is an evidence trail that is documented.<br />
* The strength of this approach allows annotation of organisms where there are no curators. GOA could take these annotations.<br />
* Includes bacteria and archaeal sequences but horizontal transfer makes it harder.<br />
* The update would occur twice a year.<br />
<br />
Paul showed screen shots of the tool that had GO annotations overlayed on the tree. The GO annotations displayed are mapped up the tree. Additional information can also be applied to the tree, such as bootstrap values or Interpro domains. This tool can be updated to reflect current GO annotation and GO tree structure.<br />
<br />
The proposal also included a change to the gp2protein files. Most are complete but if genes are missing, they were supplemented with the ENSEMBL or Entrez Gene ID (based on the group). However, these genes are represented by a single representative protein sequence so this is not a long term solution. The proposal was to switch to the Swiss-Prot canonical protein sequence which is mapped to individual UniProt IDs and has instructions on how to generate all isoforms. There was agreement that two groups (MODs and SwissProt) should not work independently to create the same file and that they should communicate.<br />
<br />
There was some concern that we were overloading the purpose of the gp2protein file. And that the GOC still needs additional files to keep track of all gene products in a genome as well as a mapping between genes and IDs for all isoforms.<br />
<br />
== The annotation process (Kara) ==<br />
(has slides)<br />
<br />
Kara then presented how this pipeline would work. The major points of the new pipeline include the following:<br />
<br />
* a new curator, known as a protein family curator, will suggest protein based on tree<br />
* MOD curators annotate all experimental data to completion<br />
* the protein family curator mediates/coordinates review of experimental based annotation review<br />
* the protein family curator also creates inferrence of annotations to equivalent genes<br />
<br />
There was some initial discussion about how the interaction between the protein family curator and the MOD curator would work at each of the rounds. The process is intended to be an iterative process that requires feedback at each round. For example, curators may want to adjust experimental-based <br />
annotations after seeing another MOD's annotations. But there needs to be a fixed timeline to finish the experimental-based curation in order for propagation of annotation to occur in a timely fashion<br />
<br />
This pipeline can generate reports to help get outlier annotations and other oddities. Automated checks can be done to alert groups when a MOD has added a new annotation or the equivalog tree has been updated or changed, particularly if a common ancestor has changed.<br />
<br />
Kara also presented new features on P-POD:<br />
* multiple genes can be input in the search<br />
* tree display is based on Notung with an interactive applet<br />
* lists publications with functional complementation<br />
* has links to GO MGI and AmiGO graphs<br />
* if you have suggestions, please sent them along<br />
<br />
==Mechanics of incorporating ancestral inferences (Suzi)==<br />
<br />
(has slides) <br />
<br />
There were two options proposed for inputting ancestrally inferred annotations:<br />
# These annotations would be provided back to the MODs, and the MODs would incorporate them into their gene association submissions to the GO consortium<br />
# They would be directly inputted into the GO database with a filtering script<br />
<br />
Although it was brought up that a downside to the first option would be a delay in incorporation of annotations, people much preferred the first option for the following reasons: <br />
* it is consistent with the current policy of each MOD being the definitive source of annotations for their organisms. <br />
* most of the MODs also have systems in place to load external annotations (e.g. GOA). <br />
* it will ensure that annotations remain in sync between the MODs and the GO consortium files<br />
<br />
This interaction should not be a part of the ejamboree but instead should be a one-on-one interaction between the MOD and the protein family curator. Also, feedback is only needed if there is a problem<br />
<br />
Judy asked what the evidence code and source for the ancestrally inferred annotations would be. RefGenome was suggested as a source and this was considered favorably as it would increase visibility of the project. We could also version these annotations by the date. Suzi said the evidence code discussion should wait until there were annotations that could be discussed.<br />
<br />
=== ACTION ITEMS ===<br />
* Draft a document about coordinating the GO gp2protein files with the UniProt proteome project (Paul/Kara). Look over it and bring it to Amos as a proposal (Michael A.).<br />
* For GO, generate a list of what files are needed (gp2protein, spliceforms, all gene products), define what these files should be, and build a file structure. (Paul/Kara)<br />
* Pascale will provide the seed genes for the annotation set at the first of every month, and the sets are to decided by Paul and Kara's trees.<br />
* If there are problems with the tree, the MODs will correspond with Paul and Kara. This will be done on a one-on-one as-needed basis.<br />
* Annotations made by ancestral inference will get fed back to the MODs in gaf format for them to incorporate into their sets to submit to the GO database. 'RefGenome' will become the source of these annotations.<br />
<br />
<br />
== Annotation Progress (Mike) ==<br />
(has slides)<br />
Showed more graphs since people like them. Bottom line is that progress is being made. The numbers for the Ref Genome genes are a bit off since it's not easy to get the list of genes so current numbers are a bit off. Paul has number on his FTP site.<br />
<br />
==== ACTION ITEM ====<br />
(berkeley) automate mike's graph (as in proposal), need to be able to see progress through time<br />
<br />
== Ref Genome impact on ontology development and documentation (David) ==<br />
(has slides)<br />
<br />
David provided an update of the impact of Ref Genome curation on ontology development.<br />
* 237 requests, 223 closed with 14 open<br />
* New requests tend to be two flavors: new term requests and problem areas in ontology<br />
* New term requests turn around is fast<br />
* Problem areas in ontology are slower because often lead to large-scale changes and are pointed out by multiple sources (curators and QC reports)<br />
<br />
Current issues in progress that need curator comments.<br />
* signaling<br />
* detection of signal<br />
* response to - how broad is this terms? Is detection of something is part of the response or if it is separate?<br />
<br />
<br />
And a reminder to make sure to mark all SourceForge items as the group "Ref Genome".<br />
<br />
Communication ontology changes is needed, particularly large rearrangements. David suggested having a tutorial for annotators.<br />
<br />
And there is a general issue of not being able to find documentation and when it's appropriate to use a term. Particularly since some of this information is spread between the wiki, GO web page, meeting minutes, annotation camp minutes, etc. This often leads to inconsistent usage - "binding" and "regulation" terms were brought up as examples.<br />
<br />
Although the definition provides the core usage, it often is not enough. Many people voiced support for examples of how to use the term, with PMIDs, as well as examples of cases when you wouldn't want to use it. Seth and Debby suggested links to GONUTS from AmiGO. Having a wiki would not limit the amount of space that's available. If there are links to a wiki page, they need to be propagated through to all children terms. A few were concerned about displaying this publicly but in general, there was support for making it public, particularly since E. coli is trying to have the community annotate.<br />
<br />
The current documentation for GO is in many places and spans many many pages. It was agreed that there needed to be a central, consolidated repository for the documentation that was easily accessible and searchable. Jen brought up that these types of project works best when there is one person in charge of the technology and individuals take responsibility for sending that person up-to-date content. The GO editorial office can have oversight but would need input from all the groups. Peter pointed out that the RefGenome group already has a forum where examples and counterexamples with references are brought up and would be a natural group for providing documentation content.<br />
<br />
==== ACTION ITEMS ====<br />
- Amelia is the point person for the documentation project.<br />
- New content driven by Kara and Pascale as they go through the trees for the RefGenome project and see the usage of the terms<br />
- Debby and Brenley will be in charge of salvaging and consolidation of existing documentation<br />
- everyone will send appropriate examples and counter-examples with PMIDs to the GO editorial office to add as comments to the GO terms and definitions<br />
- All documentation will be indexed and searchable on GONUTS (Seth, Amelia)<br />
<br />
<br />
=User Advocacy and Outreach=<br />
== GO helpdesk (Jane) ==<br />
(has slides)<br />
<br />
Highlights about the gohelp email address:<br />
* increasing number of queries<br />
* response time has gone down<br />
* types of queries remain same<br />
<br />
When checking usage for other avenues for help, FAQ is hit more than the rest of the web pages (~500/week vs. ~250/week). The FAQ is stale and needs to be cleaned up. The usage of the FAQ suggests that this should be the highest priority for clean up.<br />
<br />
=== ACTION ITEM ===<br />
amelia will be documentation coord<br />
<br />
== Newsletter (Jane) ==<br />
<br />
We are producing 4 newsletters a year but it is a lot of work, particularly formatting. Suggestions for additional outlets provided were;<br />
* do it dynamically, like an RSS<br />
* reduce frequency<br />
<br />
The RSS could complement but not replace the newsletter. The PDF version is nice to take to meetings. Also, since we announce software changes in the newsletter for widespread dissemination, decreasing the frequency may impact release of new features.<br />
<br />
There was some discussion about who actually reads the newsletter. Since the original intent of the newsletter was to make GO relevant to biologists, the newsletter needs to be general enough for general consumption. The users are GOC people, software developers, as well as biologists.<br />
<br />
=== ACTION ITEM ===<br />
(jane) look into outsourcing newsletter construction<br />
<br />
=== ACTION ITEM ===<br />
Think about separating newsletter into the above three listed sections<br />
<br />
==Tools (Jane) ==<br />
<br />
Upcoming plans to contact tools developers<br />
* will check all tools developers and have them fill out a form<br />
* goal will be to provide better information about the tools<br />
* default will be to delete tools if we don't get a response<br />
<br />
== PAMGO outreach workshop (Michelle) ==<br />
(has slides)<br />
<br />
Michelle is doing annotation workshops at IGS, complementing JVCI workshops. GO was mentioned in the BRC RFA.<br />
<br />
==TAIR and Plant Physiology collaboration (Tanya) ==<br />
(has slides)<br />
<br />
A couple dozen GO annotations have been made from this effort. Not yet 100% compliance but increased after wording changed to "you are required to submit data". Authors are only asked for data after paper has been accepted. The papers are not curated at TAIR, authors make the annotations. There has been no spot checking of the annotations to check for accuracy.<br />
<br />
== Swissprot (Michael)==<br />
<br />
Swissprot curators in Geneva are beginning to do GO annotations. There are about 40-50 curators. They will be trained by the EBI team and use their annotation software. They will only MF and BP because they use their own CC ontology. The CC ontology is mapped to GO by GOA.<br />
<br />
== Seth: AmiGO ==<br />
(has slides)<br />
<br />
=== AmiGO 1.5 Status ===<br />
<br />
* Work on speeding-up the input system for slimmer and term enrichment<br />
** Can now take input in the many thousands <br />
* rolling bugfixes<br />
* rolling text fixes<br />
<br />
=== AmiGO 1.6 Status ===<br />
<br />
Currently [http://ash.lbl.gov/cgi-bin/amigo/go beta]<br />
<br />
==== Community annotation ====<br />
<br />
* Round trip through GONuts [http://ash.lbl.gov/cgi-bin/amigo/term-details.cgi?term=GO:0035194]<br />
** Real-time participation<br />
<br />
==== Reference Genome Support ====<br />
<br />
* Includes full support for Reference Genome displays<br />
** Links in from AmiGO<br />
*** gene product search page [http://ash.lbl.gov/cgi-bin/amigo/search.cgi] (search for "pou5f")<br />
*** gene product details page [http://ash.lbl.gov/cgi-bin/amigo/gp-details.cgi?gp=UniProtKB:Q01860]<br />
** Details [http://ash.lbl.gov/cgi-bin/amigo/amigo?mode=homolset_annotation&set=307&order=default]<br />
*** details of evidence type<br />
*** sortable<br />
** Vizualizations<br />
*** Cachable<br />
*** Interative SVG [http://ash.lbl.gov/cgi-bin/amigo/amigo?mode=homolset_graph&set=307&format=svg]<br />
**** information from the details page<br />
*** Static PNG [http://ash.lbl.gov/cgi-bin/amigo/amigo?mode=homolset_graph&set=307&format=png] (large download)<br />
** Summary [http://ash.lbl.gov/cgi-bin/amigo/amigo?mode=homolset_summary]<br />
*** Cachable<br />
*** evidence type groups<br />
<br />
==== ACTION ITEM ====<br />
(seth) work with RGWG to make displays correct for users<br />
<br />
==== ACTION ITEM ====<br />
(seth) work out IDA bug that keeps coming (check with david for clarification of algorithm)<br />
<br />
=== Future work in progress (visible in live beta) ===<br />
<br />
* many different things, moving over to a new infrastructure<br />
* most importantly probably: Lucene<br />
** speed<br />
** complex search<br />
*** boolean<br />
*** distance<br />
*** weight<br />
<br />
==Obo-edit text mining plugin (Michael Schroeder)==<br />
(live demo)<br />
<br />
Michael presented a tool that can help in ontology development by:<br />
# Analyzing text to generate ontologies (Ontology Generation Tool)<br />
# Suggesting definitions from doing a Yahoo! query to pick out text strings that appear to define the search term (Definition Generation)<br />
# Add to Ontology<br />
<br />
* The gopubmed tool also indexes GO terms and Mesh terms. All search results are filterable by several different parameters. The GoGene (www.gopubmed.org/gogene/) searches pubmed abstracts. Mutations and sequence searches are possible as well.<br />
<br />
* All of the suggestions are automatically generated so it would be up to curators to go to the literature to verify.<br />
<br />
* They would like annotators/editors to evaulate it, especially those who generate ontologies. The plugin will soon be in the SVN of Obo-edit. Michael and Chris will also discuss usages of this tool for AmiGO (GOst) as well.<br />
<br />
== Michael: Next Meeting ==<br />
<br />
* Berlin<br />
* Cambridge, and then to berlin?<br />
* Maine<br />
* Eugene? Portland?<br />
* Texas <br />
<br />
==== ACTION ITEM ====<br />
will setup doodle for next location<br />
<br />
<br />
<br />
= Final = <br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues<br />
<br />
= Previous Incomplete Action Items =<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| In Progress<br />
| Documentation working group<br />
| Document annotation SOPs <br />
| Another factor we have been tracking is when a curator judges that the curation of a gene is ‘comprehensive’, that is, that is accurately represents the biology (irrespective of the number of papers available or read). This appears in the spreadsheets. The guideline is that when there are few papers, all papers should be read; when there are many (a curator can judge what is too many), then a review should be read to find the important primary literature and decide what information needs to be captured. We don’t keep track of whether or not reviews have been read. Wormbase uses textpresso (PMID 15383839), that helps ensuring curators do not overlook information. The ‘comprehensive’ curation status doesn’t get invalidated when a newer paper is published; however, curators may (and are encouraged to) update the date when the newer literature is curated.<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with is_a only paths<br />
|<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with experimental codes only<br />
| generate several versions of the data classified by different evidence codes?<br />
|-<br />
|<br />
| Chris Mungall<br />
| Provide such reports on a regular basis<br />
|<br />
|-<br />
|<br />
| Judy Blake<br />
| Contact NCBI/NLM/OMIM to link to reference genome genes<br />
|<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to Gene Association File (GAF) <br />
| column 2 is canonical gene ID; column 17 is thing you are annotating (always required); column 12 matches column 17 and contains SO ID's; add header to gene association file<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to gp2protein file <br />
| includes complete gene index (except for pseudogenes and transposons); column 1 is canonical gene ID; column 2 is accession for sequence of longest form of protein from UniProtKB: or NCBI; syntax of gp2protein file will be provided by Mike and Chris <br />
|-<br />
| In progress<br />
| (Jane)<br />
| write notice of changes to GAF and gp2protein to users <br />
| <br />
|-<br />
| In progress<br />
| MODs + Ben Hitz<br />
| make sure that their input matches new GAF and gp2protein requirements <br />
| <br />
|-<br />
| <br />
| Seth Carbon<br />
| Have AmiGO show co-occurrency terms<br />
| similar to function in QuickGO. <br />
|-<br />
| <br />
| Seth Carbon & Val Wood<br />
| SLIM by SLIM matrix<br />
| Would be used to review intersections of different cellular processes and look for unexpected intersections which may identify possible errors. Try first applying to function and component terms; outline cells that you expect to be empty, Have these matrices generated automatically from the AmiGO database. <br />
|-<br />
|<br />
| Ben & Mike<br />
| Get isoforms into GO database<br />
|<br />
|-<br />
|<br />
| MODs & Chris<br />
| Consistent use of IMP "with" column<br />
| Chris will be talking to individual groups with how they use the with column for IMP. Each MOD groups needs to respond to this for Chris.<br />
|-<br />
|<br />
| Michelle<br />
| Implement Michelle's proposal<br />
| decide whether to put 'response to drug' ID in column 16 or is separate IC annotation. Annotate to chemical term ‘response to cocaine’, co-annotate with chemical term for now, then later when available, put GO ID for “response to drug’ in column 16 (or separate IC annotation).<br />
|-<br />
| pending<br />
| Midori, David, Chris, Mike Bada<br />
| Chemical derivatives and metabolism terms<br />
| Need input from Chris and Mike on how much can be automated; possibly also current and near-future state of ChEBI<br />
|-<br />
|<br />
| MODs & Pascale<br />
| All groups to check on how they use IGI and update annotations as per Princeton discussion.<br />
|<br />
|-<br />
|<br />
| Val <br />
| Circulate draft doc on how contributes_to can & can't be used<br />
| Will include: "Would this annotation make sense if this subunit was" ... [thought not finished; might be something like "viewed by itself"].<br />
|-<br />
|<br />
| MODs & Pascale<br />
| Check existing annotations for "contributes_to" with IDA<br />
| We think only allow contributes_to with IDA. Look into adding to annotation checking script to flag contributes_to.<br />
|-<br />
| <br />
| Jen<br />
| Implement rules and software for sanity checking automated annotations (species-based trigger file).<br />
| <br />
|}<br />
<br />
= New Items =<br />
<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| empty<br />
| empty<br />
| empty<br />
| empty<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1640120th GO Consortium Meeting Minutes2008-10-22T20:59:36Z<p>Juliep: </p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
(everybody) SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* The sometimes_is_part relationship was agreed as a good idea. We should try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators) <br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
(tanya) Send out function process email again.<br />
(chris) Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
organization<br />
-[i] assembly<br />
-[i] disassembly<br />
-[i] maintenance<br />
-[i] morphogensis<br />
biogenesis<br />
-[p] assembly<br />
-[p] part biosynthesis<br />
</pre><br />
====ACTION ITEM====<br />
(ontology dev) Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
Pursue an ontology development meeting one or two:<br />
(Brenley, Kimberley, Candice, Michelle, Jane) Viral processes<br />
(Pascale, David, ???) GPCR<br />
(?) A couple of GO meeting with major meetings on these topics<br />
(?) Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
(?) remove sensu synonyms<br />
(Jen) Continue implementation of trigger system<br />
(Dan) Make GOA quickgo checking available to the public<br />
(?) write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Evidence code ontology (ECO) (Michelle) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
(suzi) We will use the ECO and create an EV code ontology tracker<br />
(everybody) people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
In principle, most everyone was supportive of the idea to separate the evidence used to make the annotation and the curation method to make that annotation. There was, however, much discussion on the scope and implementation of this proposal.<br />
<br />
Two implementation methods were proposed:<br />
# A new column that contains a text describing the annotation process<br />
# Creating a cross-product between the evidence code branch of the ECO and a methods branch of the ECO. This ID would be used in the GAF.<br />
<br />
Because proposal 2 does not create a new column and is expandable to multiple combinations, it was favored.<br />
<br />
Proposed methods were not agreed upon but words that were used to describe included<br />
*curator reviewed<br />
*not curator reviewed<br />
*electronic<br />
*manual<br />
<br />
A direct consequence of this would be that IEA would go away. Emily proposed the following mappings:<br />
*Interpro2GO -> ISS/ISM, not reviewed<br />
*keyword mappings -> TAS, not reviewed<br />
<br />
IEAs are stripped out after a year. How would those "not curator reviewed' be treated? Since the intent was to remove annotations based on sequences, maybe only those should be removed because they can be easily recomputed. Large-scale/high-volume/high-throughput experiments won't be repeated but still are experimental. We would have to consider exceptions for these.<br />
<br />
There was some discussion about what users wanted and how users were taking advantage of the evidence codes. There is a range - some people just strip evidence codes and do not consider them. However, others would take advantage of additional levels of information. Both advisors mentioned that what users wanted was a level of confidence. This, however, would be difficult to do.<br />
<br />
It was agreed that multiple issues need to be considered when dealing with this new qualifier of evidence codes:<br />
# the experimental evidence <br />
# was there judgement involved<br />
# was there a review of the data<br />
<br />
===ACTION ITEM=== <br />
(Suzi, Michelle, Judy, Pascale, Emily, Eurie) Example cases of annotations and implementation into the ECO<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
(everybody) go ahead with the implementation of the expressive model in column 16<br />
* get more examples <br />
* get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
<br />
= Reference Genome =<br />
<br />
== How curators can use evo trees (Paul) ==<br />
(has slides)<br />
<br />
Paul presented a proposal for the new process. Highlights of new process include the following:<br />
* Trees will be overlayed with the OrthoMCL "ortholog clusters" to find "equivalogs" - the equivalent gene in all organisms.<br />
* Finding these groups will allow annotations to be inferred to the shared ancestor protein<br />
* Annotations can then be propagated to the extant protein so that annotations are concurrent and consistent in the context of the evolutionary tree.<br />
* There is an evidence trail that is documented.<br />
* The strength of this approach allows annotation of organisms where there are no curators. GOA could take these annotations.<br />
* Includes bacteria and archaeal sequences but horizontal transfer makes it harder.<br />
* The update would occur twice a year.<br />
<br />
Paul showed screen shots of the tool that had GO annotations overlayed on the tree. The GO annotations displayed are mapped up the tree. Additional information can also be applied to the tree, such as bootstrap values or Interpro domains. This tool can be updated to reflect current GO annotation and GO tree structure.<br />
<br />
The proposal also included a change to the gp2protein files. Most are complete but if genes are missing, they were supplemented with the ENSEMBL or Entrez Gene ID (based on the group). However, these genes are represented by a single representative protein sequence so this is not a long term solution. The proposal was to switch to the Swiss-Prot canonical protein sequence which is mapped to individual UniProt IDs and has instructions on how to generate all isoforms. There was agreement that two groups (MODs and SwissProt) should not work independently to create the same file and that they should communicate.<br />
<br />
There was some concern that we were overloading the purpose of the gp2protein file. And that the GOC still needs additional files to keep track of all gene products in a genome as well as a mapping between genes and IDs for all isoforms.<br />
<br />
== The annotation process (Kara) ==<br />
(has slides)<br />
<br />
Kara then presented how this pipeline would work. The major points of the new pipeline include the following:<br />
<br />
* a new curator, known as a protein family curator, will suggest protein based on tree<br />
* MOD curators annotate all experimental data to completion<br />
* the protein family curator mediates/coordinates review of experimental based annotation review<br />
* the protein family curator also creates inferrence of annotations to equivalent genes<br />
<br />
There was some initial discussion about how the interaction between the protein family curator and the MOD curator would work at each of the rounds. The process is intended to be an iterative process that requires feedback at each round. For example, curators may want to adjust experimental-based <br />
annotations after seeing another MOD's annotations. But there needs to be a fixed timeline to finish the experimental-based curation in order for propagation of annotation to occur in a timely fashion<br />
<br />
This pipeline can generate reports to help get outlier annotations and other oddities. Automated checks can be done to alert groups when a MOD has added a new annotation or the equivalog tree has been updated or changed, particularly if a common ancestor has changed.<br />
<br />
Kara also presented new features on P-POD:<br />
* multiple genes can be input in the search<br />
* tree display is based on Notung with an interactive applet<br />
* lists publications with functional complementation<br />
* has links to GO MGI and AmiGO graphs<br />
* if you have suggestions, please sent them along<br />
<br />
==Mechanics of incorporating ancestral inferences (Suzi)==<br />
<br />
(has slides) <br />
<br />
There were two options proposed for inputting ancestrally inferred annotations:<br />
# These annotations would be provided back to the MODs, and the MODs would incorporate them into their gene association submissions to the GO consortium<br />
# They would be directly inputted into the GO database with a filtering script<br />
<br />
Although it was brought up that a downside to the first option would be a delay in incorporation of annotations, people much preferred the first option for the following reasons: <br />
* it is consistent with the current policy of each MOD being the definitive source of annotations for their organisms. <br />
* most of the MODs also have systems in place to load external annotations (e.g. GOA). <br />
* it will ensure that annotations remain in sync between the MODs and the GO consortium files<br />
<br />
This interaction should not be a part of the ejamboree but instead should be a one-on-one interaction between the MOD and the protein family curator. Also, feedback is only needed if there is a problem<br />
<br />
Judy asked what the evidence code and source for the ancestrally inferred annotations would be. RefGenome was suggested as a source and this was considered favorably as it would increase visibility of the project. We could also version these annotations by the date. Suzi said the evidence code discussion should wait until there were annotations that could be discussed.<br />
<br />
=== ACTION ITEMS ===<br />
* Draft a document about coordinating the GO gp2protein files with the UniProt proteome project (Paul/Kara). Look over it and bring it to Amos as a proposal (Michael A.).<br />
* For GO, generate a list of what files are needed (gp2protein, spliceforms, all gene products), define what these files should be, and build a file structure. (Paul/Kara)<br />
* Pascale will provide the seed genes for the annotation set at the first of every month, and the sets are to decided by Paul and Kara's trees.<br />
* If there are problems with the tree, the MODs will correspond with Paul and Kara. This will be done on a one-on-one as-needed basis.<br />
* Annotations made by ancestral inference will get fed back to the MODs in gaf format for them to incorporate into their sets to submit to the GO database. 'RefGenome' will become the source of these annotations.<br />
<br />
<br />
== Annotation Progress (Mike) ==<br />
(has slides)<br />
Showed more graphs since people like them. Bottom line is that progress is being made. The numbers for the Ref Genome genes are a bit off since it's not easy to get the list of genes so current numbers are a bit off. Paul has number on his FTP site.<br />
<br />
==== ACTION ITEM ====<br />
(berkeley) automate mike's graph (as in proposal), need to be able to see progress through time<br />
<br />
== Ref Genome impact on ontology development and documentation (David) ==<br />
(has slides)<br />
<br />
David provided an update of the impact of Ref Genome curation on ontology development.<br />
* 237 requests, 223 closed with 14 open<br />
* New requests tend to be two flavors: new term requests and problem areas in ontology<br />
* New term requests turn around is fast<br />
* Problem areas in ontology are slower because often lead to large-scale changes and are pointed out by multiple sources (curators and QC reports)<br />
<br />
Current issues in progress that need curator comments.<br />
* signaling<br />
* detection of signal<br />
* response to - how broad is this terms? Is detection of something is part of the response or if it is separate?<br />
<br />
<br />
And a reminder to make sure to mark all SourceForge items as the group "Ref Genome".<br />
<br />
Communication ontology changes is needed, particularly large rearrangements. David suggested having a tutorial for annotators.<br />
<br />
And there is a general issue of not being able to find documentation and when it's appropriate to use a term. Particularly since some of this information is spread between the wiki, GO web page, meeting minutes, annotation camp minutes, etc. This often leads to inconsistent usage - "binding" and "regulation" terms were brought up as examples.<br />
<br />
Although the definition provides the core usage, it often is not enough. Many people voiced support for examples of how to use the term, with PMIDs, as well as examples of cases when you wouldn't want to use it. Seth and Debby suggested links to GONUTS from AmiGO. Having a wiki would not limit the amount of space that's available. If there are links to a wiki page, they need to be propagated through to all children terms. A few were concerned about displaying this publicly but in general, there was support for making it public, particularly since E. coli is trying to have the community annotate.<br />
<br />
The current documentation for GO is in many places and spans many many pages. It was agreed that there needed to be a central, consolidated repository for the documentation that was easily accessible and searchable. Jen brought up that these types of project works best when there is one person in charge of the technology and individuals take responsibility for sending that person up-to-date content. The GO editorial office can have oversight but would need input from all the groups. Peter pointed out that the RefGenome group already has a forum where examples and counterexamples with references are brought up and would be a natural group for providing documentation content.<br />
<br />
==== ACTION ITEMS ====<br />
- Amelia is the point person for the documentation project.<br />
- New content driven by Kara and Pascale as they go through the trees for the RefGenome project and see the usage of the terms<br />
- Debby and Brenley will be in charge of salvaging and consolidation of existing documentation<br />
- everyone will send appropriate examples and counter-examples with PMIDs to the GO editorial office to add as comments to the GO terms and definitions<br />
- All documentation will be indexed and searchable on GONUTS (Seth, Amelia)<br />
<br />
<br />
== Jane: helpdesk and newsletter ==<br />
(has slides)<br />
<br />
* central email address<br />
* list rota<br />
* lotsa queries<br />
** response times decreasing<br />
* pie charts of query types<br />
* other avenues for help<br />
** faq<br />
** web docs<br />
** amigo help<br />
** suzi: how about a "was this page helpful" button<br />
** david: that slide shows that most work should be done on the faq<br />
<br />
==== ACTION ITEM ====<br />
amelia will be documentation coord<br />
<br />
* newsletter<br />
** suzi: can do dynamic, RSS, etc.<br />
** judy: likes the PDFs and have different releases<br />
** eurie: it needs to be general enough for general consumption<br />
** eurie: it takes a lot of time to write this stuff;<br />
** pascale: maybe decrease frequency<br />
*** suzi: frequency affects new features, so higher is better<br />
** jen: <br />
** suzi: the users are software, internal, and external<br />
<br />
==== ACTION ITEM ====<br />
(jane) look into outsourcing newsletter construction<br />
<br />
==== ACTION ITEM ====<br />
(?) separate newsletter into the above three listed sections<br />
<br />
* tools tool<br />
** will check all tools developers and see what's dead<br />
** will provide better information about the tools<br />
** mike: default will be to delete tools if we don't get a response<br />
<br />
== Michelle: PAMGO outreach workshop ==<br />
(has slides)<br />
<br />
* .<br />
* jvci outreach<br />
* igs outreach<br />
* snippet from BRC II RFA<br />
** GO mentioned by name<br />
* talk of RFAs and BRCs<br />
<br />
<br />
== Tanya: TAIR and plant physiology collab ==<br />
(has slides)<br />
<br />
* web interface<br />
* tracking results<br />
** not yet 100% compliance<br />
* only ask for info after it has been accepted<br />
* rex: haven't done spot checking?<br />
** no<br />
<br />
== Michael: swissprot ==<br />
<br />
* curation split three ways<br />
** there has been resistance in geneva to use GO terms<br />
** at last meeting in princeton, from now on, some will start using GO (~40)<br />
** EBI and (SID?) will work things out<br />
<br />
== Seth: AmiGO ==<br />
(has slides)<br />
<br />
* ...<br />
<br />
== Michael: text-mining ontologies ==<br />
(live demo)<br />
<br />
* ... [missed first few minutes]<br />
* OBO-Edit plugins<br />
** use of web resources for automated term generation<br />
** ...<br />
* indexing GO term MESH terms<br />
* workig onto gene symbols<br />
<br />
* gogene<br />
** ...<br />
<br />
* ...<br />
<br />
* suzi: it takes gene ident and goes to NCBI or somewhere, there is usually a pub--could that be used to boost results?<br />
** should be already indexed<br />
<br />
* ...<br />
<br />
* at the end, you'll always go back to the article to check if it was useful<br />
<br />
* would like GO curators to try this tool and see how good the results are<br />
<br />
* plugin should be in SVN soon<br />
* suzi: might be useful for AmiGO as well<br />
** usable for GOst<br />
<br />
== Michael: Next Meeting ==<br />
<br />
* Berlin<br />
* Cambridge, and then to berlin?<br />
* Maine<br />
* Eugene? Portland?<br />
* Texas <br />
<br />
==== ACTION ITEM ====<br />
will setup doodle for next location<br />
<br />
<br />
<br />
= Final = <br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues<br />
<br />
= Previous Incomplete Action Items =<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| In Progress<br />
| Documentation working group<br />
| Document annotation SOPs <br />
| Another factor we have been tracking is when a curator judges that the curation of a gene is ‘comprehensive’, that is, that is accurately represents the biology (irrespective of the number of papers available or read). This appears in the spreadsheets. The guideline is that when there are few papers, all papers should be read; when there are many (a curator can judge what is too many), then a review should be read to find the important primary literature and decide what information needs to be captured. We don’t keep track of whether or not reviews have been read. Wormbase uses textpresso (PMID 15383839), that helps ensuring curators do not overlook information. The ‘comprehensive’ curation status doesn’t get invalidated when a newer paper is published; however, curators may (and are encouraged to) update the date when the newer literature is curated.<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with is_a only paths<br />
|<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with experimental codes only<br />
| generate several versions of the data classified by different evidence codes?<br />
|-<br />
|<br />
| Chris Mungall<br />
| Provide such reports on a regular basis<br />
|<br />
|-<br />
|<br />
| Judy Blake<br />
| Contact NCBI/NLM/OMIM to link to reference genome genes<br />
|<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to Gene Association File (GAF) <br />
| column 2 is canonical gene ID; column 17 is thing you are annotating (always required); column 12 matches column 17 and contains SO ID's; add header to gene association file<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to gp2protein file <br />
| includes complete gene index (except for pseudogenes and transposons); column 1 is canonical gene ID; column 2 is accession for sequence of longest form of protein from UniProtKB: or NCBI; syntax of gp2protein file will be provided by Mike and Chris <br />
|-<br />
| In progress<br />
| (Jane)<br />
| write notice of changes to GAF and gp2protein to users <br />
| <br />
|-<br />
| In progress<br />
| MODs + Ben Hitz<br />
| make sure that their input matches new GAF and gp2protein requirements <br />
| <br />
|-<br />
| <br />
| Seth Carbon<br />
| Have AmiGO show co-occurrency terms<br />
| similar to function in QuickGO. <br />
|-<br />
| <br />
| Seth Carbon & Val Wood<br />
| SLIM by SLIM matrix<br />
| Would be used to review intersections of different cellular processes and look for unexpected intersections which may identify possible errors. Try first applying to function and component terms; outline cells that you expect to be empty, Have these matrices generated automatically from the AmiGO database. <br />
|-<br />
|<br />
| Ben & Mike<br />
| Get isoforms into GO database<br />
|<br />
|-<br />
|<br />
| MODs & Chris<br />
| Consistent use of IMP "with" column<br />
| Chris will be talking to individual groups with how they use the with column for IMP. Each MOD groups needs to respond to this for Chris.<br />
|-<br />
|<br />
| Michelle<br />
| Implement Michelle's proposal<br />
| decide whether to put 'response to drug' ID in column 16 or is separate IC annotation. Annotate to chemical term ‘response to cocaine’, co-annotate with chemical term for now, then later when available, put GO ID for “response to drug’ in column 16 (or separate IC annotation).<br />
|-<br />
| pending<br />
| Midori, David, Chris, Mike Bada<br />
| Chemical derivatives and metabolism terms<br />
| Need input from Chris and Mike on how much can be automated; possibly also current and near-future state of ChEBI<br />
|-<br />
|<br />
| MODs & Pascale<br />
| All groups to check on how they use IGI and update annotations as per Princeton discussion.<br />
|<br />
|-<br />
|<br />
| Val <br />
| Circulate draft doc on how contributes_to can & can't be used<br />
| Will include: "Would this annotation make sense if this subunit was" ... [thought not finished; might be something like "viewed by itself"].<br />
|-<br />
|<br />
| MODs & Pascale<br />
| Check existing annotations for "contributes_to" with IDA<br />
| We think only allow contributes_to with IDA. Look into adding to annotation checking script to flag contributes_to.<br />
|-<br />
| <br />
| Jen<br />
| Implement rules and software for sanity checking automated annotations (species-based trigger file).<br />
| <br />
|}<br />
<br />
= New Items =<br />
<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| empty<br />
| empty<br />
| empty<br />
| empty<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1640020th GO Consortium Meeting Minutes2008-10-22T20:58:55Z<p>Juliep: /* Ref Genome impact on ontology development (David) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
(everybody) SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* The sometimes_is_part relationship was agreed as a good idea. We should try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators) <br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
(tanya) Send out function process email again.<br />
(chris) Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
organization<br />
-[i] assembly<br />
-[i] disassembly<br />
-[i] maintenance<br />
-[i] morphogensis<br />
biogenesis<br />
-[p] assembly<br />
-[p] part biosynthesis<br />
</pre><br />
====ACTION ITEM====<br />
(ontology dev) Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
Pursue an ontology development meeting one or two:<br />
(Brenley, Kimberley, Candice, Michelle, Jane) Viral processes<br />
(Pascale, David, ???) GPCR<br />
(?) A couple of GO meeting with major meetings on these topics<br />
(?) Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
(?) remove sensu synonyms<br />
(Jen) Continue implementation of trigger system<br />
(Dan) Make GOA quickgo checking available to the public<br />
(?) write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Evidence code ontology (ECO) (Michelle) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
(suzi) We will use the ECO and create an EV code ontology tracker<br />
(everybody) people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
In principle, most everyone was supportive of the idea to separate the evidence used to make the annotation and the curation method to make that annotation. There was, however, much discussion on the scope and implementation of this proposal.<br />
<br />
Two implementation methods were proposed:<br />
# A new column that contains a text describing the annotation process<br />
# Creating a cross-product between the evidence code branch of the ECO and a methods branch of the ECO. This ID would be used in the GAF.<br />
<br />
Because proposal 2 does not create a new column and is expandable to multiple combinations, it was favored.<br />
<br />
Proposed methods were not agreed upon but words that were used to describe included<br />
*curator reviewed<br />
*not curator reviewed<br />
*electronic<br />
*manual<br />
<br />
A direct consequence of this would be that IEA would go away. Emily proposed the following mappings:<br />
*Interpro2GO -> ISS/ISM, not reviewed<br />
*keyword mappings -> TAS, not reviewed<br />
<br />
IEAs are stripped out after a year. How would those "not curator reviewed' be treated? Since the intent was to remove annotations based on sequences, maybe only those should be removed because they can be easily recomputed. Large-scale/high-volume/high-throughput experiments won't be repeated but still are experimental. We would have to consider exceptions for these.<br />
<br />
There was some discussion about what users wanted and how users were taking advantage of the evidence codes. There is a range - some people just strip evidence codes and do not consider them. However, others would take advantage of additional levels of information. Both advisors mentioned that what users wanted was a level of confidence. This, however, would be difficult to do.<br />
<br />
It was agreed that multiple issues need to be considered when dealing with this new qualifier of evidence codes:<br />
# the experimental evidence <br />
# was there judgement involved<br />
# was there a review of the data<br />
<br />
===ACTION ITEM=== <br />
(Suzi, Michelle, Judy, Pascale, Emily, Eurie) Example cases of annotations and implementation into the ECO<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
(everybody) go ahead with the implementation of the expressive model in column 16<br />
* get more examples <br />
* get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
<br />
= Reference Genome =<br />
<br />
== How curators can use evo trees (Paul) ==<br />
(has slides)<br />
<br />
Paul presented a proposal for the new process. Highlights of new process include the following:<br />
* Trees will be overlayed with the OrthoMCL "ortholog clusters" to find "equivalogs" - the equivalent gene in all organisms.<br />
* Finding these groups will allow annotations to be inferred to the shared ancestor protein<br />
* Annotations can then be propagated to the extant protein so that annotations are concurrent and consistent in the context of the evolutionary tree.<br />
* There is an evidence trail that is documented.<br />
* The strength of this approach allows annotation of organisms where there are no curators. GOA could take these annotations.<br />
* Includes bacteria and archaeal sequences but horizontal transfer makes it harder.<br />
* The update would occur twice a year.<br />
<br />
Paul showed screen shots of the tool that had GO annotations overlayed on the tree. The GO annotations displayed are mapped up the tree. Additional information can also be applied to the tree, such as bootstrap values or Interpro domains. This tool can be updated to reflect current GO annotation and GO tree structure.<br />
<br />
The proposal also included a change to the gp2protein files. Most are complete but if genes are missing, they were supplemented with the ENSEMBL or Entrez Gene ID (based on the group). However, these genes are represented by a single representative protein sequence so this is not a long term solution. The proposal was to switch to the Swiss-Prot canonical protein sequence which is mapped to individual UniProt IDs and has instructions on how to generate all isoforms. There was agreement that two groups (MODs and SwissProt) should not work independently to create the same file and that they should communicate.<br />
<br />
There was some concern that we were overloading the purpose of the gp2protein file. And that the GOC still needs additional files to keep track of all gene products in a genome as well as a mapping between genes and IDs for all isoforms.<br />
<br />
== The annotation process (Kara) ==<br />
(has slides)<br />
<br />
Kara then presented how this pipeline would work. The major points of the new pipeline include the following:<br />
<br />
* a new curator, known as a protein family curator, will suggest protein based on tree<br />
* MOD curators annotate all experimental data to completion<br />
* the protein family curator mediates/coordinates review of experimental based annotation review<br />
* the protein family curator also creates inferrence of annotations to equivalent genes<br />
<br />
There was some initial discussion about how the interaction between the protein family curator and the MOD curator would work at each of the rounds. The process is intended to be an iterative process that requires feedback at each round. For example, curators may want to adjust experimental-based <br />
annotations after seeing another MOD's annotations. But there needs to be a fixed timeline to finish the experimental-based curation in order for propagation of annotation to occur in a timely fashion<br />
<br />
This pipeline can generate reports to help get outlier annotations and other oddities. Automated checks can be done to alert groups when a MOD has added a new annotation or the equivalog tree has been updated or changed, particularly if a common ancestor has changed.<br />
<br />
Kara also presented new features on P-POD:<br />
* multiple genes can be input in the search<br />
* tree display is based on Notung with an interactive applet<br />
* lists publications with functional complementation<br />
* has links to GO MGI and AmiGO graphs<br />
* if you have suggestions, please sent them along<br />
<br />
==Mechanics of incorporating ancestral inferences (Suzi)==<br />
<br />
(has slides) <br />
<br />
There were two options proposed for inputting ancestrally inferred annotations:<br />
# These annotations would be provided back to the MODs, and the MODs would incorporate them into their gene association submissions to the GO consortium<br />
# They would be directly inputted into the GO database with a filtering script<br />
<br />
Although it was brought up that a downside to the first option would be a delay in incorporation of annotations, people much preferred the first option for the following reasons: <br />
* it is consistent with the current policy of each MOD being the definitive source of annotations for their organisms. <br />
* most of the MODs also have systems in place to load external annotations (e.g. GOA). <br />
* it will ensure that annotations remain in sync between the MODs and the GO consortium files<br />
<br />
This interaction should not be a part of the ejamboree but instead should be a one-on-one interaction between the MOD and the protein family curator. Also, feedback is only needed if there is a problem<br />
<br />
Judy asked what the evidence code and source for the ancestrally inferred annotations would be. RefGenome was suggested as a source and this was considered favorably as it would increase visibility of the project. We could also version these annotations by the date. Suzi said the evidence code discussion should wait until there were annotations that could be discussed.<br />
<br />
=== ACTION ITEMS ===<br />
* Draft a document about coordinating the GO gp2protein files with the UniProt proteome project (Paul/Kara). Look over it and bring it to Amos as a proposal (Michael A.).<br />
* For GO, generate a list of what files are needed (gp2protein, spliceforms, all gene products), define what these files should be, and build a file structure. (Paul/Kara)<br />
* Pascale will provide the seed genes for the annotation set at the first of every month, and the sets are to decided by Paul and Kara's trees.<br />
* If there are problems with the tree, the MODs will correspond with Paul and Kara. This will be done on a one-on-one as-needed basis.<br />
* Annotations made by ancestral inference will get fed back to the MODs in gaf format for them to incorporate into their sets to submit to the GO database. 'RefGenome' will become the source of these annotations.<br />
<br />
<br />
== Annotation Progress (Mike) ==<br />
(has slides)<br />
Showed more graphs since people like them. Bottom line is that progress is being made. The numbers for the Ref Genome genes are a bit off since it's not easy to get the list of genes so current numbers are a bit off. Paul has number on his FTP site.<br />
<br />
==== ACTION ITEM ====<br />
(berkeley) automate mike's graph (as in proposal), need to be able to see progress through time<br />
<br />
== Ref Genome impact on ontology development and documentation (David) ==<br />
(has slides)<br />
<br />
David provided an update of the impact of Ref Genome curation on ontology development.<br />
* 237 requests, 223 closed with 14 open<br />
* New requests tend to be two flavors: new term requests and problem areas in ontology<br />
* New term requests turn around is fast<br />
* Problem areas in ontology are slower because often lead to large-scale changes and are pointed out by multiple sources (curators and QC reports)<br />
<br />
Current issues in progress that need curator comments.<br />
* signaling<br />
* detection of signal<br />
* response to - how broad is this terms? Is detection of something is part of the response or if it is separate?<br />
<br />
<br />
And a reminder to make sure to mark all SourceForge items as the group "Ref Genome".<br />
<br />
Communication ontology changes is needed, particularly large rearrangements. David suggested having a tutorial for annotators.<br />
<br />
And there is a general issue of not being able to find documentation and when it's appropriate to use a term. Particularly since some of this information is spread between the wiki, GO web page, meeting minutes, annotation camp minutes, etc. This often leads to inconsistent usage - "binding" and "regulation" terms were brought up as examples.<br />
<br />
Although the definition provides the core usage, it often is not enough. Many people voiced support for examples of how to use the term, with PMIDs, as well as examples of cases when you wouldn't want to use it. Seth and Debby suggested links to GONUTS from AmiGO. Having a wiki would not limit the amount of space that's available. If there are links to a wiki page, they need to be propagated through to all children terms. A few were concerned about displaying this publicly but in general, there was support for making it public, particularly since E. coli is trying to have the community annotate.<br />
<br />
The current documentation for GO is in many places and spans many many pages. It was agreed that there needed to be a central, consolidated repository for the documentation that was easily accessible and searchable. Jen brought up that these types of project works best when there is one person in charge of the technology and individuals take responsibility for sending that person up-to-date content. The GO editorial office can have oversight but would need input from all the groups. Peter pointed out that the RefGenome group already has a forum where examples and counterexamples with references are brought up and would be a natural group for providing documentation content.<br />
<br />
==== ACTION ITEMS ====<br />
- Amelia is the point person for the documentation project.<br />
- New content driven by Kara and Pascale as they go through the trees for the RefGenome project and see the usage of the terms<br />
- Debby and Brenley will be in charge of salvaging and consolidation of existing documentation<br />
- everyone will send appropriate examples and counter-examples with PMIDs to the GO editorial office to add as comments to the GO terms and definitions<br />
- All documentation will be indexed and searchable on GONUTS (Seth, Amelia)<br />
<br />
== Discussion continued after lunch ==<br />
<br />
* PF will be responsible for some of the term usage<br />
* rex: we shoul<br />
* peter: sounds like w should use RG group, as they have he most concrete need<br />
* midori: GEO can help, but shouldn't be responsible--may not be able to give usful feedback<br />
* suzi: it is distibuted task, but it needs a coordinator<br />
* amelia: will put stuff up, but dont' want to manage content<br />
* suzi: salvage old content vs. getting new content; salvage would be one-off<br />
* pascal: who actually knows where this stuff is? probably web people and those who put it up<br />
* debbie: volunteer to help go through and look for documentation for certain terms<br />
* david: pascale's list of problem terms isn't cross with other materials<br />
* rex: there is a lot of salvagable material<br />
** indexed, consolidated, wikified<br />
<br />
==== ACTION ITEM ====<br />
Amelia is point for documentation<br />
<br />
==== ACTION ITEM ====<br />
pascale and kara for new content<br />
<br />
==== ACTION ITEM ====<br />
debbie and brenlie will over salvage of existing<br />
<br />
==== ACTION ITEM ====<br />
everyone will send examples and counter examples<br />
<br />
==== ACTION ITEM ====<br />
GOE will add ...<br />
<br />
==== ACTION ITEM ====<br />
GONuts, seth, amelia search, indexing, and wikification<br />
<br />
== Jane: helpdesk and newsletter ==<br />
(has slides)<br />
<br />
* central email address<br />
* list rota<br />
* lotsa queries<br />
** response times decreasing<br />
* pie charts of query types<br />
* other avenues for help<br />
** faq<br />
** web docs<br />
** amigo help<br />
** suzi: how about a "was this page helpful" button<br />
** david: that slide shows that most work should be done on the faq<br />
<br />
==== ACTION ITEM ====<br />
amelia will be documentation coord<br />
<br />
* newsletter<br />
** suzi: can do dynamic, RSS, etc.<br />
** judy: likes the PDFs and have different releases<br />
** eurie: it needs to be general enough for general consumption<br />
** eurie: it takes a lot of time to write this stuff;<br />
** pascale: maybe decrease frequency<br />
*** suzi: frequency affects new features, so higher is better<br />
** jen: <br />
** suzi: the users are software, internal, and external<br />
<br />
==== ACTION ITEM ====<br />
(jane) look into outsourcing newsletter construction<br />
<br />
==== ACTION ITEM ====<br />
(?) separate newsletter into the above three listed sections<br />
<br />
* tools tool<br />
** will check all tools developers and see what's dead<br />
** will provide better information about the tools<br />
** mike: default will be to delete tools if we don't get a response<br />
<br />
== Michelle: PAMGO outreach workshop ==<br />
(has slides)<br />
<br />
* .<br />
* jvci outreach<br />
* igs outreach<br />
* snippet from BRC II RFA<br />
** GO mentioned by name<br />
* talk of RFAs and BRCs<br />
<br />
<br />
== Tanya: TAIR and plant physiology collab ==<br />
(has slides)<br />
<br />
* web interface<br />
* tracking results<br />
** not yet 100% compliance<br />
* only ask for info after it has been accepted<br />
* rex: haven't done spot checking?<br />
** no<br />
<br />
== Michael: swissprot ==<br />
<br />
* curation split three ways<br />
** there has been resistance in geneva to use GO terms<br />
** at last meeting in princeton, from now on, some will start using GO (~40)<br />
** EBI and (SID?) will work things out<br />
<br />
== Seth: AmiGO ==<br />
(has slides)<br />
<br />
* ...<br />
<br />
== Michael: text-mining ontologies ==<br />
(live demo)<br />
<br />
* ... [missed first few minutes]<br />
* OBO-Edit plugins<br />
** use of web resources for automated term generation<br />
** ...<br />
* indexing GO term MESH terms<br />
* workig onto gene symbols<br />
<br />
* gogene<br />
** ...<br />
<br />
* ...<br />
<br />
* suzi: it takes gene ident and goes to NCBI or somewhere, there is usually a pub--could that be used to boost results?<br />
** should be already indexed<br />
<br />
* ...<br />
<br />
* at the end, you'll always go back to the article to check if it was useful<br />
<br />
* would like GO curators to try this tool and see how good the results are<br />
<br />
* plugin should be in SVN soon<br />
* suzi: might be useful for AmiGO as well<br />
** usable for GOst<br />
<br />
== Michael: Next Meeting ==<br />
<br />
* Berlin<br />
* Cambridge, and then to berlin?<br />
* Maine<br />
* Eugene? Portland?<br />
* Texas <br />
<br />
==== ACTION ITEM ====<br />
will setup doodle for next location<br />
<br />
<br />
<br />
= Final = <br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues<br />
<br />
= Previous Incomplete Action Items =<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| In Progress<br />
| Documentation working group<br />
| Document annotation SOPs <br />
| Another factor we have been tracking is when a curator judges that the curation of a gene is ‘comprehensive’, that is, that is accurately represents the biology (irrespective of the number of papers available or read). This appears in the spreadsheets. The guideline is that when there are few papers, all papers should be read; when there are many (a curator can judge what is too many), then a review should be read to find the important primary literature and decide what information needs to be captured. We don’t keep track of whether or not reviews have been read. Wormbase uses textpresso (PMID 15383839), that helps ensuring curators do not overlook information. The ‘comprehensive’ curation status doesn’t get invalidated when a newer paper is published; however, curators may (and are encouraged to) update the date when the newer literature is curated.<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with is_a only paths<br />
|<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with experimental codes only<br />
| generate several versions of the data classified by different evidence codes?<br />
|-<br />
|<br />
| Chris Mungall<br />
| Provide such reports on a regular basis<br />
|<br />
|-<br />
|<br />
| Judy Blake<br />
| Contact NCBI/NLM/OMIM to link to reference genome genes<br />
|<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to Gene Association File (GAF) <br />
| column 2 is canonical gene ID; column 17 is thing you are annotating (always required); column 12 matches column 17 and contains SO ID's; add header to gene association file<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to gp2protein file <br />
| includes complete gene index (except for pseudogenes and transposons); column 1 is canonical gene ID; column 2 is accession for sequence of longest form of protein from UniProtKB: or NCBI; syntax of gp2protein file will be provided by Mike and Chris <br />
|-<br />
| In progress<br />
| (Jane)<br />
| write notice of changes to GAF and gp2protein to users <br />
| <br />
|-<br />
| In progress<br />
| MODs + Ben Hitz<br />
| make sure that their input matches new GAF and gp2protein requirements <br />
| <br />
|-<br />
| <br />
| Seth Carbon<br />
| Have AmiGO show co-occurrency terms<br />
| similar to function in QuickGO. <br />
|-<br />
| <br />
| Seth Carbon & Val Wood<br />
| SLIM by SLIM matrix<br />
| Would be used to review intersections of different cellular processes and look for unexpected intersections which may identify possible errors. Try first applying to function and component terms; outline cells that you expect to be empty, Have these matrices generated automatically from the AmiGO database. <br />
|-<br />
|<br />
| Ben & Mike<br />
| Get isoforms into GO database<br />
|<br />
|-<br />
|<br />
| MODs & Chris<br />
| Consistent use of IMP "with" column<br />
| Chris will be talking to individual groups with how they use the with column for IMP. Each MOD groups needs to respond to this for Chris.<br />
|-<br />
|<br />
| Michelle<br />
| Implement Michelle's proposal<br />
| decide whether to put 'response to drug' ID in column 16 or is separate IC annotation. Annotate to chemical term ‘response to cocaine’, co-annotate with chemical term for now, then later when available, put GO ID for “response to drug’ in column 16 (or separate IC annotation).<br />
|-<br />
| pending<br />
| Midori, David, Chris, Mike Bada<br />
| Chemical derivatives and metabolism terms<br />
| Need input from Chris and Mike on how much can be automated; possibly also current and near-future state of ChEBI<br />
|-<br />
|<br />
| MODs & Pascale<br />
| All groups to check on how they use IGI and update annotations as per Princeton discussion.<br />
|<br />
|-<br />
|<br />
| Val <br />
| Circulate draft doc on how contributes_to can & can't be used<br />
| Will include: "Would this annotation make sense if this subunit was" ... [thought not finished; might be something like "viewed by itself"].<br />
|-<br />
|<br />
| MODs & Pascale<br />
| Check existing annotations for "contributes_to" with IDA<br />
| We think only allow contributes_to with IDA. Look into adding to annotation checking script to flag contributes_to.<br />
|-<br />
| <br />
| Jen<br />
| Implement rules and software for sanity checking automated annotations (species-based trigger file).<br />
| <br />
|}<br />
<br />
= New Items =<br />
<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| empty<br />
| empty<br />
| empty<br />
| empty<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1638720th GO Consortium Meeting Minutes2008-10-22T19:32:14Z<p>Juliep: /* Reference Genome */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
(everybody) SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* The sometimes_is_part relationship was agreed as a good idea. We should try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators) <br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
(tanya) Send out function process email again.<br />
(chris) Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
organization<br />
-[i] assembly<br />
-[i] disassembly<br />
-[i] maintenance<br />
-[i] morphogensis<br />
biogenesis<br />
-[p] assembly<br />
-[p] part biosynthesis<br />
</pre><br />
====ACTION ITEM====<br />
(ontology dev) Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
Pursue an ontology development meeting one or two:<br />
(Brenley, Kimberley, Candice, Michelle, Jane) Viral processes<br />
(Pascale, David, ???) GPCR<br />
(?) A couple of GO meeting with major meetings on these topics<br />
(?) Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
(?) remove sensu synonyms<br />
(Jen) Continue implementation of trigger system<br />
(Dan) Make GOA quickgo checking available to the public<br />
(?) write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Evidence code ontology (ECO) (Michelle) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
(suzi) We will use the ECO and create an EV code ontology tracker<br />
(everybody) people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
In principle, most everyone was supportive of the idea to separate the evidence used to make the annotation and the curation method to make that annotation. There was, however, much discussion on the scope and implementation of this proposal.<br />
<br />
Two implementation methods were proposed:<br />
# A new column that contains a text describing the annotation process<br />
# Creating a cross-product between the evidence code branch of the ECO and a methods branch of the ECO. This ID would be used in the GAF.<br />
<br />
Because proposal 2 does not create a new column and is expandable to multiple combinations, it was favored.<br />
<br />
Proposed methods were not agreed upon but words that were used to describe included<br />
*curator reviewed<br />
*not curator reviewed<br />
*electronic<br />
*manual<br />
<br />
A direct consequence of this would be that IEA would go away. Emily proposed the following mappings:<br />
*Interpro2GO -> ISS/ISM, not reviewed<br />
*keyword mappings -> TAS, not reviewed<br />
<br />
IEAs are stripped out after a year. How would those "not curator reviewed' be treated? Since the intent was to remove annotations based on sequences, maybe only those should be removed because they can be easily recomputed. Large-scale/high-volume/high-throughput experiments won't be repeated but still are experimental. We would have to consider exceptions for these.<br />
<br />
There was some discussion about what users wanted and how users were taking advantage of the evidence codes. There is a range - some people just strip evidence codes and do not consider them. However, others would take advantage of additional levels of information. Both advisors mentioned that what users wanted was a level of confidence. This, however, would be difficult to do.<br />
<br />
It was agreed that multiple issues need to be considered when dealing with this new qualifier of evidence codes:<br />
# the experimental evidence <br />
# was there judgement involved<br />
# was there a review of the data<br />
<br />
===ACTION ITEM=== <br />
(Suzi, Michelle, Judy, Pascale, Emily, Eurie) Example cases of annotations and implementation into the ECO<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
(everybody) go ahead with the implementation of the expressive model in column 16<br />
* get more examples <br />
* get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
<br />
= Reference Genome =<br />
<br />
== How curators can use evo trees (Paul) ==<br />
(has slides)<br />
<br />
Paul presented a proposal for the new process. Highlights of new process include the following:<br />
* Trees will be overlayed with the OrthoMCL "ortholog clusters" to find "equivalogs" - the equivalent gene in all organisms.<br />
* Finding these groups will allow annotations to be inferred to the shared ancestor protein<br />
* Annotations can then be propagated to the extant protein so that annotations are concurrent and consistent in the context of the evolutionary tree.<br />
* There is an evidence trail that is documented.<br />
* The strength of this approach allows annotation of organisms where there are no curators. GOA could take these annotations.<br />
* Includes bacteria and archaeal sequences but horizontal transfer makes it harder.<br />
* The update would occur twice a year.<br />
<br />
Paul showed screen shots of the tool that had GO annotations overlayed on the tree. The GO annotations displayed are mapped up the tree. Additional information can also be applied to the tree, such as bootstrap values or Interpro domains. This tool can be updated to reflect current GO annotation and GO tree structure.<br />
<br />
The proposal also included a change to the gp2protein files. Most are complete but if genes are missing, they were supplemented with the ENSEMBL or Entrez Gene ID (based on the group). However, these genes are represented by a single representative protein sequence so this is not a long term solution. The proposal was to switch to the Swiss-Prot canonical protein sequence which is mapped to individual UniProt IDs and has instructions on how to generate all isoforms. There was agreement that two groups (MODs and SwissProt) should not work independently to create the same file and that they should communicate.<br />
<br />
There was some concern that we were overloading the purpose of the gp2protein file. And that the GOC still needs additional files to keep track of all gene products in a genome as well as a mapping between genes and IDs for all isoforms.<br />
<br />
== The annotation process (Kara) ==<br />
(has slides)<br />
<br />
Kara then presented how this pipeline would work. The major points of the new pipeline include the following:<br />
<br />
* a new curator, known as a protein family curator, will suggest protein based on tree<br />
* MOD curators annotate all experimental data to completion<br />
* the protein family curator mediates/coordinates review of experimental based annotation review<br />
* the protein family curator also creates inferrence of annotations to equivalent genes<br />
<br />
There was some initial discussion about how the interaction between the protein family curator and the MOD curator would work at each of the rounds. The process is intended to be an iterative process that requires feedback at each round. For example, curators may want to adjust experimental-based <br />
annotations after seeing another MOD's annotations. But there needs to be a fixed timeline to finish the experimental-based curation in order for propagation of annotation to occur in a timely fashion<br />
<br />
This pipeline can generate reports to help get outlier annotations and other oddities. Automated checks can be done to alert groups when a MOD has added a new annotation or the equivalog tree has been updated or changed, particularly if a common ancestor has changed.<br />
<br />
Kara also presented new features on P-POD:<br />
* multiple genes can be input in the search<br />
* tree display is based on Notung with an interactive applet<br />
* lists publications with functional complementation<br />
* has links to GO MGI and AmiGO graphs<br />
* if you have suggestions, please sent them along<br />
<br />
==Mechanics of incorporating ancestral inferences (Suzi)==<br />
<br />
(has slides) <br />
<br />
There were two options proposed for inputting ancestrally inferred annotations:<br />
# These annotations would be provided back to the MODs, and the MODs would incorporate them into their gene association submissions to the GO consortium<br />
# They would be directly inputted into the GO database with a filtering script<br />
<br />
Although it was brought up that a downside to the first option would be a delay in incorporation of annotations, people much preferred the first option for the following reasons: <br />
* it is consistent with the current policy of each MOD being the definitive source of annotations for their organisms. <br />
* most of the MODs also have systems in place to load external annotations (e.g. GOA). <br />
* it will ensure that annotations remain in sync between the MODs and the GO consortium files<br />
<br />
This interaction should not be a part of the ejamboree but instead should be a one-on-one interaction between the MOD and the protein family curator. Also, feedback is only needed if there is a problem<br />
<br />
Judy asked what the evidence code and source for the ancestrally inferred annotations would be. RefGenome was suggested as a source and this was considered favorably as it would increase visibility of the project. We could also version these annotations by the date. Suzi said the evidence code discussion should wait until there were annotations that could be discussed.<br />
<br />
=== ACTION ITEMS ===<br />
* Draft a document about coordinating the GO gp2protein files with the UniProt proteome project (Paul/Kara). Look over it and bring it to Amos as a proposal (Michael A.).<br />
* For GO, generate a list of what files are needed (gp2protein, spliceforms, all gene products), define what these files should be, and build a file structure. (Paul/Kara)<br />
* Pascale will provide the seed genes for the annotation set at the first of every month, and the sets are to decided by Paul and Kara's trees.<br />
* If there are problems with the tree, the MODs will correspond with Paul and Kara. This will be done on a one-on-one as-needed basis.<br />
* Annotations made by ancestral inference will get fed back to the MODs in gaf format for them to incorporate into their sets to submit to the GO database. 'RefGenome' will become the source of these annotations.<br />
<br />
<br />
== Mike: Annotation Progress ==<br />
(has slides)<br />
Showed more graphs since people like them. Bottom line is that progress is being made. The numbers for the Ref Genome genes are a bit off since it's not easy to get the list of genes so current numbers are a bit off. Paul has number on his FTP site.<br />
<br />
==== ACTION ITEM ====<br />
(berkeley) automate mike's graph (as in proposal), need to be able to see progress through time<br />
<br />
== David: RG from ont dev prespective ==<br />
(has slides)<br />
<br />
* we work through SF<br />
** RG request are prioritized<br />
*** two flavors<br />
**** new term for RG<br />
**** problem areas in ont<br />
***** slower<br />
* need annotors to get info about "response to" terms<br />
* doing signalling now<br />
* ...argh...<br />
<br />
* please use SF and mark as RG<br />
<br />
* pascale: documentation and anno consis<br />
** when doing big branch of ont, more discussion with RG group<br />
* jen: doc for every big reorg, sometimes I don't know about a change<br />
* debbie: def is sometimes unclear<br />
** ex: ATP binding<br />
** pascale: "binding", "regulating", ev--these are always a problem<br />
** pascale: we need a group to make a proposal to get the defs down flat<br />
** peter: ont distinguishes binding from catalysis <br />
** kimberly: we're not consistant about how we use binding<br />
** rex: documentation is the core issue<br />
*** docs will solve all of the above<br />
<br />
* ntrs turn around fairly quickly<br />
* ontology problems are slower<br />
* David, what do you include in your response to terms.<br />
** how broad is the "response to"?<br />
** Is detection of something is part of the response or if it is separate?<br />
* organization and biogenesis<br />
* Debby: definition isn't always clear when to use to annotate to a certain term. If it's a substrate of a reaction then do you use it or not?<br />
* David/Harold: If the experiment shows that it binds, it binds.<br />
* Peter: Interactions that occur for catalysis seem different than binding in the GO sense.<br />
* Kimberley: We're not consistent in how we're using binding.<br />
* Rex: Important issue of documentiaton and how documentation organize. We cna have a working group for each of these issues but if the documentation is not clear and rationally planned out and indexed and easily accessible, it is not useful for current annotation and future annotation. <br />
* Ingrid: Look to definition of term, to have usage example in the comments. This can link to somewhe re with a longer explanation.<br />
* David: If ref genomes decides on how to use a term, then write to the editors to put a comment in <br />
* Judy: no link from definition, conflict between use of resource by curators and use by the community. Where do we provide this for the curators that doesn't impinge on the community.<br />
* Seth: linkout to GONUTS to keep the information separate from the database.<br />
* Richard: having examples of the use of the term has been valuable along with the definition. You might also want to include examples of improper uses.<br />
* Pascale: already in the comments fields, there is already some informtation there we could extend. We could also add another field called "curator information"<br />
* Alex: This information can also be useful to the community and not just the curators. <br />
* Jen: One place for documentation, and one search that just searches the documentation<br />
* Mike: I don't think this should be private. If it's useful for the curators on how to curate it, then it would be extremely useful for the user to know how the term was used.<br />
* Debby: We're trying to do community annotation so for us the community are the curators. Comments, with linkouts to GONUTS that contains the history and the discussion of this term.<br />
* Emily: There's only so much information in a public section that you can add. Having the wiki would enable us not be limited by space. Need to propagate these linkouts to child terms or related nodes such that they show up in different GO browsers.<br />
* Jane: documentation goes out of date very quickly and there is a large overhead in maintaining it.<br />
* David: it still comes down to curator judgement about what was shown in that paper and what term is appropriate.<br />
<br />
<br />
==== ACTION ITEM ====<br />
come up with rational plan for documentation and indexing (including rational and examples)<br />
<br />
* suzi: we can ask the SAB about this as well<br />
* ingrid: i look at term def<br />
* how should we do this?<br />
* seth: why not GONuts and not muck-up the data<br />
* richard: examples would be very valuable, including counter examples<br />
* pascale: add more fields that didfferent people could see<br />
* alex: users should see the information<br />
* jen: wants one single information resource<br />
* mike: this curator info shouldn't be private--this is good stuff<br />
* debbie: seconds mike, and GONuts<br />
* emily: seconds<br />
** children as well<br />
* jen: graph can be weird<br />
** david: will fill in missing bits<br />
* jane: docs go bad over time need freshness<br />
* david: great defs vs. curator judgement--still an art<br />
** harold: seconds; always constrained by training<br />
<br />
...<br />
<br />
==== ACTION ITEM ====<br />
<br />
= Final = <br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues<br />
<br />
= Previous Incomplete Action Items =<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| In Progress<br />
| Documentation working group<br />
| Document annotation SOPs <br />
| Another factor we have been tracking is when a curator judges that the curation of a gene is ‘comprehensive’, that is, that is accurately represents the biology (irrespective of the number of papers available or read). This appears in the spreadsheets. The guideline is that when there are few papers, all papers should be read; when there are many (a curator can judge what is too many), then a review should be read to find the important primary literature and decide what information needs to be captured. We don’t keep track of whether or not reviews have been read. Wormbase uses textpresso (PMID 15383839), that helps ensuring curators do not overlook information. The ‘comprehensive’ curation status doesn’t get invalidated when a newer paper is published; however, curators may (and are encouraged to) update the date when the newer literature is curated.<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with is_a only paths<br />
|<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with experimental codes only<br />
| generate several versions of the data classified by different evidence codes?<br />
|-<br />
|<br />
| Chris Mungall<br />
| Provide such reports on a regular basis<br />
|<br />
|-<br />
|<br />
| Judy Blake<br />
| Contact NCBI/NLM/OMIM to link to reference genome genes<br />
|<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to Gene Association File (GAF) <br />
| column 2 is canonical gene ID; column 17 is thing you are annotating (always required); column 12 matches column 17 and contains SO ID's; add header to gene association file<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to gp2protein file <br />
| includes complete gene index (except for pseudogenes and transposons); column 1 is canonical gene ID; column 2 is accession for sequence of longest form of protein from UniProtKB: or NCBI; syntax of gp2protein file will be provided by Mike and Chris <br />
|-<br />
| In progress<br />
| (Jane)<br />
| write notice of changes to GAF and gp2protein to users <br />
| <br />
|-<br />
| In progress<br />
| MODs + Ben Hitz<br />
| make sure that their input matches new GAF and gp2protein requirements <br />
| <br />
|-<br />
| <br />
| Seth Carbon<br />
| Have AmiGO show co-occurrency terms<br />
| similar to function in QuickGO. <br />
|-<br />
| <br />
| Seth Carbon & Val Wood<br />
| SLIM by SLIM matrix<br />
| Would be used to review intersections of different cellular processes and look for unexpected intersections which may identify possible errors. Try first applying to function and component terms; outline cells that you expect to be empty, Have these matrices generated automatically from the AmiGO database. <br />
|-<br />
|<br />
| Ben & Mike<br />
| Get isoforms into GO database<br />
|<br />
|-<br />
|<br />
| MODs & Chris<br />
| Consistent use of IMP "with" column<br />
| Chris will be talking to individual groups with how they use the with column for IMP. Each MOD groups needs to respond to this for Chris.<br />
|-<br />
|<br />
| Michelle<br />
| Implement Michelle's proposal<br />
| decide whether to put 'response to drug' ID in column 16 or is separate IC annotation. Annotate to chemical term ‘response to cocaine’, co-annotate with chemical term for now, then later when available, put GO ID for “response to drug’ in column 16 (or separate IC annotation).<br />
|-<br />
| pending<br />
| Midori, David, Chris, Mike Bada<br />
| Chemical derivatives and metabolism terms<br />
| Need input from Chris and Mike on how much can be automated; possibly also current and near-future state of ChEBI<br />
|-<br />
|<br />
| MODs & Pascale<br />
| All groups to check on how they use IGI and update annotations as per Princeton discussion.<br />
|<br />
|-<br />
|<br />
| Val <br />
| Circulate draft doc on how contributes_to can & can't be used<br />
| Will include: "Would this annotation make sense if this subunit was" ... [thought not finished; might be something like "viewed by itself"].<br />
|-<br />
|<br />
| MODs & Pascale<br />
| Check existing annotations for "contributes_to" with IDA<br />
| We think only allow contributes_to with IDA. Look into adding to annotation checking script to flag contributes_to.<br />
|-<br />
| <br />
| Jen<br />
| Implement rules and software for sanity checking automated annotations (species-based trigger file).<br />
| <br />
|}<br />
<br />
= New Items =<br />
<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| empty<br />
| empty<br />
| empty<br />
| empty<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1638620th GO Consortium Meeting Minutes2008-10-22T19:13:55Z<p>Juliep: </p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
(everybody) SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* The sometimes_is_part relationship was agreed as a good idea. We should try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators) <br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
(tanya) Send out function process email again.<br />
(chris) Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
organization<br />
-[i] assembly<br />
-[i] disassembly<br />
-[i] maintenance<br />
-[i] morphogensis<br />
biogenesis<br />
-[p] assembly<br />
-[p] part biosynthesis<br />
</pre><br />
====ACTION ITEM====<br />
(ontology dev) Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
Pursue an ontology development meeting one or two:<br />
(Brenley, Kimberley, Candice, Michelle, Jane) Viral processes<br />
(Pascale, David, ???) GPCR<br />
(?) A couple of GO meeting with major meetings on these topics<br />
(?) Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
(?) remove sensu synonyms<br />
(Jen) Continue implementation of trigger system<br />
(Dan) Make GOA quickgo checking available to the public<br />
(?) write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Evidence code ontology (ECO) (Michelle) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
(suzi) We will use the ECO and create an EV code ontology tracker<br />
(everybody) people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
In principle, most everyone was supportive of the idea to separate the evidence used to make the annotation and the curation method to make that annotation. There was, however, much discussion on the scope and implementation of this proposal.<br />
<br />
Two implementation methods were proposed:<br />
# A new column that contains a text describing the annotation process<br />
# Creating a cross-product between the evidence code branch of the ECO and a methods branch of the ECO. This ID would be used in the GAF.<br />
<br />
Because proposal 2 does not create a new column and is expandable to multiple combinations, it was favored.<br />
<br />
Proposed methods were not agreed upon but words that were used to describe included<br />
*curator reviewed<br />
*not curator reviewed<br />
*electronic<br />
*manual<br />
<br />
A direct consequence of this would be that IEA would go away. Emily proposed the following mappings:<br />
*Interpro2GO -> ISS/ISM, not reviewed<br />
*keyword mappings -> TAS, not reviewed<br />
<br />
IEAs are stripped out after a year. How would those "not curator reviewed' be treated? Since the intent was to remove annotations based on sequences, maybe only those should be removed because they can be easily recomputed. Large-scale/high-volume/high-throughput experiments won't be repeated but still are experimental. We would have to consider exceptions for these.<br />
<br />
There was some discussion about what users wanted and how users were taking advantage of the evidence codes. There is a range - some people just strip evidence codes and do not consider them. However, others would take advantage of additional levels of information. Both advisors mentioned that what users wanted was a level of confidence. This, however, would be difficult to do.<br />
<br />
It was agreed that multiple issues need to be considered when dealing with this new qualifier of evidence codes:<br />
# the experimental evidence <br />
# was there judgement involved<br />
# was there a review of the data<br />
<br />
===ACTION ITEM=== <br />
(Suzi, Michelle, Judy, Pascale, Emily, Eurie) Example cases of annotations and implementation into the ECO<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
(everybody) go ahead with the implementation of the expressive model in column 16<br />
* get more examples <br />
* get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
<br />
= Reference Genome =<br />
<br />
=== ACTION ITEMS ===<br />
* Draft a document about coordinating the GO gp2protein files with the UniProt proteome project (Paul/Kara). Look over it and bring it to Amos as a proposal (Michael A.).<br />
* For GO, generate a list of what files are needed (gp2protein, spliceforms, all gene products), define what these files should be, and build a file structure. (Paul/Kara)<br />
* Pascale will provide the seed genes for the annotation set at the first of every month, and the sets are to decided by Paul and Kara's trees.<br />
* If there are problems with the tree, the MODs will correspond with Paul and Kara. This will be done on a one-on-one as-needed basis.<br />
* Annotations made by ancestral inference will get fed back to the MODs in gaf format for them to incorporate into their sets to submit to the GO database. 'RefGenome' will become the source of these annotations.<br />
<br />
== How curators can use evo trees (Paul) ==<br />
(has slides)<br />
<br />
Paul presented a proposal for the new process. Highlights of new process include the following:<br />
* Trees will be overlayed with the OrthoMCL "ortholog clusters" to find "equivalogs" - the equivalent gene in all organisms.<br />
* Finding these groups will allow annotations to be inferred to the shared ancestor protein<br />
* Annotations can then be propagated to the extant protein so that annotations are concurrent and consistent in the context of the evolutionary tree.<br />
* There is an evidence trail that is documented.<br />
* The strength of this approach allows annotation of organisms where there are no curators. GOA could take these annotations.<br />
* Includes bacteria and archaeal sequences but horizontal transfer makes it harder.<br />
* The update would occur twice a year.<br />
<br />
Paul showed screen shots of the tool that had GO annotations overlayed on the tree. The GO annotations displayed are mapped up the tree. Additional information can also be applied to the tree, such as bootstrap values or Interpro domains. This tool can be updated to reflect current GO annotation and GO tree structure.<br />
<br />
The proposal also included a change to the gp2protein files. Most are complete but if genes are missing, they were supplemented with the ENSEMBL or Entrez Gene ID (based on the group). However, these genes are represented by a single representative protein sequence so this is not a long term solution. The proposal was to switch to the Swiss-Prot canonical protein sequence which is mapped to individual UniProt IDs and has instructions on how to generate all isoforms. There was agreement that two groups (MODs and SwissProt) should not work independently to create the same file and that they should communicate.<br />
<br />
There was some concern that we were overloading the purpose of the gp2protein file. And that the GOC still needs additional files to keep track of all gene products in a genome as well as a mapping between genes and IDs for all isoforms.<br />
<br />
== The annotation process (Kara) ==<br />
(has slides)<br />
<br />
Kara then presented how this pipeline would work. The major points of the new pipeline include the following:<br />
<br />
* a new curator, known as a protein family curator, will suggest protein based on tree<br />
* MOD curators annotate all experimental data to completion<br />
* the protein family curator mediates/coordinates review of experimental based annotation review<br />
* the protein family curator also creates inferrence of annotations to equivalent genes<br />
<br />
There was some initial discussion about how the interaction between the protein family curator and the MOD curator would work at each of the rounds. The process is intended to be an iterative process that requires feedback at each round. For example, curators may want to adjust experimental-based <br />
annotations after seeing another MOD's annotations. But there needs to be a fixed timeline to finish the experimental-based curation in order for propagation of annotation to occur in a timely fashion<br />
<br />
This pipeline can generate reports to help get outlier annotations and other oddities. Automated checks can be done to alert groups when a MOD has added a new annotation or the equivalog tree has been updated or changed, particularly if a common ancestor has changed.<br />
<br />
Kara also presented new features on P-POD:<br />
* multiple genes can be input in the search<br />
* tree display is based on Notung with an interactive applet<br />
* lists publications with functional complementation<br />
* has links to GO MGI and AmiGO graphs<br />
* if you have suggestions, please sent them along<br />
<br />
<br />
== Reference Genome Annotation Discussion ==<br />
(has slides)<br />
<br />
It was decided that the process for selecting the initial genes to determine the RefGenome sets would not change. Pascale would continue to provide the gene list at the beginning of each month.<br />
<br />
It is not necessary to discuss the problems with the tree as a group and feedback can be given to Paul and Kara. Paul proposed that this discussion could be tacked on at the end of an ejamboree session<br />
<br />
For the gp2protein input, we want to have a reference protein with all the exons (Kimberley)<br />
<br />
<br />
* judy: multiple reps of protein families, want to take advantage of them, like swissprot<br />
** completely extensible, can put in as many as you want<br />
* need to be careful with definitions, maybe we should be better<br />
* m.a.: we should go slow and prepare a document for this and make sure that we have everybody with us<br />
** we aren't in a hurry<br />
<br />
<br />
* Kimberley: How do you handle new literature that comes to the MODs? Do you revisit?<br />
* Rex: As we identify a new paper that might cause us to revise an annotation, it needs to get fed into the system.<br />
* Judy: The group needs to be notified if there is a new function that has been identified.<br />
* Rex: if the change is an outlier, then the group needs to talk about it.<br />
* Kara: In the proposal, reports will be generated.<br />
* Mike: Are there equivalog sets that you will exclude that the function evolves faster than the sequence?<br />
* Paul: There will be a proposal from a pfc and the group will be able to talk about it. And the curator will be able to make a judgement on what level of annotation to transfer. There is something you can say, it may be more specific, it may be less specific, but that's where the biological expertise comes in.<br />
* MA: this is so much rigorous than what we've done before, and everything is traceable.<br />
* Mke: pfc will define annotation set. How do you envision MOD interaction on a given set b/c <br />
* Kara: there will be a given set and the MOD curators will make the annotations and the pfc will mediate<br />
* Mike/Kara/Rex: This will be an iterative process b/c some MODs will want to change their annotations based on what other groups have annotated.<br />
* Rex: to make this work, there needs to be a defined time frame so the iterative process can happen.<br />
* MIchelle: are bacterial species included?<br />
* Paul: They already are, but horizontal gene transfer does make this more difficult.<br />
* Mike: are you going to take existing annotations to help make trees?<br />
* Judy: Mouse could provide information about duplication, that could be an extension of this work, but this would be a place to start.<br />
* Paul: Sometimes the tree will be wrong because the data is problematic. Chicken genes are problematic. But it is traceable where the tree breaks down and can report back to the MOD so they can look at their data<br />
* Judy: look at this side by side with Mary's trees that look at annotations within the GO structure<br />
* MA: The underlying structure of the tree is the species tree? (yes) What happens when the species tree changes?<br />
* Paul: we just have to figure out how that affects the nodes that have been annotated, but I don't think that these are going to be dramatic changes. We look at how this changes the distribution of annotations for predicted groups. The question is "does the ancestor change"?<br />
<br />
<br />
<br />
<br />
* How can we get better about generating the protein sets?<br />
** work in collaboration with UniProt proteome project?<br />
* uniprot; complete proteome project<br />
* protein curator; how to efficiently incorporate input from all MODs<br />
* how to deliver resulting homol-based annotations to MODs<br />
* judy: doesn't like gp to protein files<br />
** what's in a name<br />
* judy: MODs are building gp to protein, how to work with uniprot?<br />
** judy: eventually they will be working together<br />
* Judy: we're also including functional RNAs, you're calling them gp2protein files<br />
* Paul: This is a legacy name issue<br />
* Judy: given that we are building these files on a MOD by MOD basis, how are we going to interface with UniProt since their effort is the same.<br />
* Judy: the goal is to annotate one gene representitive and one protein representitive<br />
* Pascale: UniProt are the missing proteomes mouse, zebrafish, chicken, rat.<br />
* Judy: the goal of the project should be that the UniProt and GO files <br />
* Suzi: We have loaded the gp2protein file, but we need an additional file for spliceforms, and ones that has RNAs, etc.<br />
* Kimberley: c elegans sent the longest, but what you really want is all the exons <br />
* Paul: The SwissProt representation is ideal.<br />
* Judy: in terms of isoforms, there are multiple ways of representing ptn family sets, so what are the thoughts of having multiple groups overlayed on these trees?<br />
* Paul: This system is completely extensible.<br />
* Rex: we should be careful about what you're calling protein families, really they are gene trees.<br />
* MA: we should prepare a document for what the GO means and what we should do. And what protein sets we are going to coordinate from the MODs, what they are going to be used for, what are they going to include<br />
* How to most efficently incorporate input from all MOD curators?<br />
** proposal--protein family curator<br />
* How are resulting homology-based annotations delivered to MODs?<br />
* Judy: how do we decide which genes get chosen?<br />
** Is it working, do we want to change anything?<br />
* Judy: it would be good to set the priority sets.<br />
* Rex: We've discussed this every time and the priority changes, it doesn't matter how we pick them, just pick them.<br />
* suzi: give a gene/focal point, what from every species is the protein that you want to include--that will be the tree stuff<br />
* suzi: no discussion about the seed; but we may have one about the set.<br />
* rex: let's just truct paul's trees, good enough<br />
* kara: will have much improvement once we start using trees<br />
* pascale: any problems should bump back to paul and kara, not necessary to discuss as a group<br />
* Debby: Should we have the discussion about the inferences at the ejamboree?--NO. the curators might want to go back and do additional annotations based on the dicussion and it would be more fruitful to have a separate call about the inferences.<br />
* Kara: We'd like to sit down and create a proposal about how to do the reviewal without making extra work. want to just hammer things out with pascale and have a concrete system<br />
* judy: MODs should incorporate new inf instead of GO<br />
* Rex: requirement of the ref gen group, to quickly incorporate the inferencial annotations by each MOD to their GA file.<br />
**** paul: MODs should check tree, until comfortable<br />
*** paul: how does PF interface with mods?<br />
* David: The most efficient way would be for the pfc to contact each of the MOD individually.<br />
* Rex: turn it around. Have the MODs review and if there is a problem, then they get in touch with the pfc in a defined amount of time.<br />
* David: only people who have experimental data should get together and annotate<br />
* Pascale: these are only predictions. We want to be conservative in propagating these functions.<br />
* tree rebuild will happen every 6 mos or so.<br />
<br />
<br />
currently do not have complete protein files for mouse, rat, chicken, zebrafish<br />
<br />
<br />
Mechanics <br />
There were two options proposed for inputting ancestrally inferred annotations:<br />
# These annotations would be provided back to the MODs, and the MODs would incorporate them into their gene association submissions to the GO consortium<br />
# They would be directly inputted into the GO database with a filtering script<br />
<br />
Although it was brought up that a downside to the first option would be a delay in incorporation of annotations, people much preferred the first option for the following reasons: <br />
* it is consistent with the current policy of each MOD being the definitive source of annotations for their organisms. <br />
* most of the MODs also have systems in place to load external annotations (e.g. GOA). <br />
* it will ensure that annotations remain in sync between the MODs and the GO consortium files<br />
<br />
Judy asked what the evidence code and source for the ancestrally inferred annotations would be. RefGenome was suggested as a source and this was considered favorably as it would increase visibility of the project. We could also version these annotations by the date. Suzi said the evidence code discussion should wait until there were annotations that could be discussed.<br />
<br />
<br />
<br />
<br />
=== ACTION ITEMS ===<br />
* Draft a document about coordinating the GO gp2protein files with the UniProt proteome project (Paul/Kara). Look over it and bring it to Amos as a proposal (Michael A.).<br />
* For GO, generate a list of what files are needed (gp2protein, spliceforms, all gene products), define what these files should be, and build a file structure. (Paul/Kara)<br />
* Pascale will provide the seed genes for the annotation set at the first of every month, and the sets are to decided by Paul and Kara's trees.<br />
* If there are problems with the tree, the MODs will correspond with Paul and Kara. This will be done on a one-on-one as-needed basis.<br />
* Annotations made by ancestral inference will get fed back to the MODs in gaf format for them to incorporate into their sets to submit to the GO database. 'RefGenome' will become the source of these annotations.<br />
<br />
<br />
== Mike: Annotation Progress ==<br />
(has slides)<br />
Showed more graphs since people like them. Bottom line is that progress is being made. The numbers for the Ref Genome genes are a bit off since it's not easy to get the list of genes so current numbers are a bit off. Paul has number on his FTP site.<br />
<br />
==== ACTION ITEM ====<br />
(berkeley) automate mike's graph (as in proposal), need to be able to see progress through time<br />
<br />
== David: RG from ont dev prespective ==<br />
(has slides)<br />
<br />
* we work through SF<br />
** RG request are prioritized<br />
*** two flavors<br />
**** new term for RG<br />
**** problem areas in ont<br />
***** slower<br />
* need annotors to get info about "response to" terms<br />
* doing signalling now<br />
* ...argh...<br />
<br />
* please use SF and mark as RG<br />
<br />
* pascale: documentation and anno consis<br />
** when doing big branch of ont, more discussion with RG group<br />
* jen: doc for every big reorg, sometimes I don't know about a change<br />
* debbie: def is sometimes unclear<br />
** ex: ATP binding<br />
** pascale: "binding", "regulating", ev--these are always a problem<br />
** pascale: we need a group to make a proposal to get the defs down flat<br />
** peter: ont distinguishes binding from catalysis <br />
** kimberly: we're not consistant about how we use binding<br />
** rex: documentation is the core issue<br />
*** docs will solve all of the above<br />
<br />
==== ACTION ITEM ====<br />
come up with rational plan for documentation and indexing (including rational and examples)<br />
<br />
* suzi: we can ask the SAB about this as well<br />
* ingrid: i look at term def<br />
* how should we do this?<br />
* seth: why not GONuts and not muck-up the data<br />
* richard: examples would be very valuable, including counter examples<br />
* pascale: add more fields that didfferent people could see<br />
* alex: users should see the information<br />
* jen: wants one single information resource<br />
* mike: this curator info shouldn't be private--this is good stuff<br />
* debbie: seconds mike, and GONuts<br />
* emily: seconds<br />
** children as well<br />
* jen: graph can be weird<br />
** david: will fill in missing bits<br />
* jane: docs go bad over time need freshness<br />
* david: great defs vs. curator judgement--still an art<br />
** harold: seconds; always constrained by training<br />
<br />
...<br />
<br />
==== ACTION ITEM ====<br />
<br />
= Final = <br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues<br />
<br />
= Previous Incomplete Action Items =<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| In Progress<br />
| Documentation working group<br />
| Document annotation SOPs <br />
| Another factor we have been tracking is when a curator judges that the curation of a gene is ‘comprehensive’, that is, that is accurately represents the biology (irrespective of the number of papers available or read). This appears in the spreadsheets. The guideline is that when there are few papers, all papers should be read; when there are many (a curator can judge what is too many), then a review should be read to find the important primary literature and decide what information needs to be captured. We don’t keep track of whether or not reviews have been read. Wormbase uses textpresso (PMID 15383839), that helps ensuring curators do not overlook information. The ‘comprehensive’ curation status doesn’t get invalidated when a newer paper is published; however, curators may (and are encouraged to) update the date when the newer literature is curated.<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with is_a only paths<br />
|<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with experimental codes only<br />
| generate several versions of the data classified by different evidence codes?<br />
|-<br />
|<br />
| Chris Mungall<br />
| Provide such reports on a regular basis<br />
|<br />
|-<br />
|<br />
| Judy Blake<br />
| Contact NCBI/NLM/OMIM to link to reference genome genes<br />
|<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to Gene Association File (GAF) <br />
| column 2 is canonical gene ID; column 17 is thing you are annotating (always required); column 12 matches column 17 and contains SO ID's; add header to gene association file<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to gp2protein file <br />
| includes complete gene index (except for pseudogenes and transposons); column 1 is canonical gene ID; column 2 is accession for sequence of longest form of protein from UniProtKB: or NCBI; syntax of gp2protein file will be provided by Mike and Chris <br />
|-<br />
| In progress<br />
| (Jane)<br />
| write notice of changes to GAF and gp2protein to users <br />
| <br />
|-<br />
| In progress<br />
| MODs + Ben Hitz<br />
| make sure that their input matches new GAF and gp2protein requirements <br />
| <br />
|-<br />
| <br />
| Seth Carbon<br />
| Have AmiGO show co-occurrency terms<br />
| similar to function in QuickGO. <br />
|-<br />
| <br />
| Seth Carbon & Val Wood<br />
| SLIM by SLIM matrix<br />
| Would be used to review intersections of different cellular processes and look for unexpected intersections which may identify possible errors. Try first applying to function and component terms; outline cells that you expect to be empty, Have these matrices generated automatically from the AmiGO database. <br />
|-<br />
|<br />
| Ben & Mike<br />
| Get isoforms into GO database<br />
|<br />
|-<br />
|<br />
| MODs & Chris<br />
| Consistent use of IMP "with" column<br />
| Chris will be talking to individual groups with how they use the with column for IMP. Each MOD groups needs to respond to this for Chris.<br />
|-<br />
|<br />
| Michelle<br />
| Implement Michelle's proposal<br />
| decide whether to put 'response to drug' ID in column 16 or is separate IC annotation. Annotate to chemical term ‘response to cocaine’, co-annotate with chemical term for now, then later when available, put GO ID for “response to drug’ in column 16 (or separate IC annotation).<br />
|-<br />
| pending<br />
| Midori, David, Chris, Mike Bada<br />
| Chemical derivatives and metabolism terms<br />
| Need input from Chris and Mike on how much can be automated; possibly also current and near-future state of ChEBI<br />
|-<br />
|<br />
| MODs & Pascale<br />
| All groups to check on how they use IGI and update annotations as per Princeton discussion.<br />
|<br />
|-<br />
|<br />
| Val <br />
| Circulate draft doc on how contributes_to can & can't be used<br />
| Will include: "Would this annotation make sense if this subunit was" ... [thought not finished; might be something like "viewed by itself"].<br />
|-<br />
|<br />
| MODs & Pascale<br />
| Check existing annotations for "contributes_to" with IDA<br />
| We think only allow contributes_to with IDA. Look into adding to annotation checking script to flag contributes_to.<br />
|-<br />
| <br />
| Jen<br />
| Implement rules and software for sanity checking automated annotations (species-based trigger file).<br />
| <br />
|}<br />
<br />
= New Items =<br />
<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| empty<br />
| empty<br />
| empty<br />
| empty<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1637420th GO Consortium Meeting Minutes2008-10-22T17:22:57Z<p>Juliep: /* Day 2 */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
(everybody) SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* The sometimes_is_part relationship was agreed as a good idea. We should try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators) <br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
(tanya) Send out function process email again.<br />
(chris) Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
organization<br />
-[i] assembly<br />
-[i] disassembly<br />
-[i] maintenance<br />
-[i] morphogensis<br />
biogenesis<br />
-[p] assembly<br />
-[p] part biosynthesis<br />
</pre><br />
====ACTION ITEM====<br />
(ontology dev) Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
Pursue an ontology development meeting one or two:<br />
(Brenley, Kimberley, Candice, Michelle, Jane) Viral processes<br />
(Pascale, David, ???) GPCR<br />
(?) A couple of GO meeting with major meetings on these topics<br />
(?) Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
(?) remove sensu synonyms<br />
(Jen) Continue implementation of trigger system<br />
(Dan) Make GOA quickgo checking available to the public<br />
(?) write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Evidence code ontology (ECO) (Michelle) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
In principle, most everyone was supportive of the idea to separate the evidence used to make the annotation and the curation method to make that annotation. There was, however, much discussion on the scope and implementation of this proposal.<br />
<br />
Two implementation methods were proposed:<br />
# A new column that contains a text describing the annotation process<br />
# Creating a cross-product between the evidence code branch of the ECO and a methods branch of the ECO. This ID would be used in the GAF.<br />
<br />
Because proposal 2 does not create a new column and is expandable to multiple combinations, it was favored.<br />
<br />
Proposed methods were not agreed upon but words that were used to describe included<br />
*curator reviewed<br />
*not curator reviewed<br />
*electronic<br />
*manual<br />
<br />
A direct consequence of this would be that IEA would go away. Emily proposed the following mappings:<br />
*Interpro2GO -> ISS/ISM, not reviewed<br />
*keyword mappings -> TAS, not reviewed<br />
<br />
IEAs are stripped out after a year. How would those "not curator reviewed' be treated? Since the intent was to remove annotations based on sequences, maybe only those should be removed because they can be easily recomputed. Large-scale/high-volume/high-throughput experiments won't be repeated but still are experimental. We would have to consider exceptions for these.<br />
<br />
There was some discussion about what users wanted and how users were taking advantage of the evidence codes. There is a range - some people just strip evidence codes and do not consider them. However, others would take advantage of additional levels of information. Both advisors mentioned that what users wanted was a level of confidence. This, however, would be difficult to do.<br />
<br />
It was agreed that multiple issues need to be considered when dealing with this new qualifier of evidence codes:<br />
# the experimental evidence <br />
# was there judgement involved<br />
# was there a review of the data<br />
<br />
===ACTION ITEM=== <br />
(Suzi, Michelle, Judy, Pascale, Emily, Eurie) Example cases of annotations and implementation into the ECO<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
(everybody) go ahead with the implementation of the expressive model in column 16<br />
* get more examples <br />
* get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
<br />
= Day 2 =<br />
<br />
=== ACTION ITEMS ===<br />
* Draft a document about coordinating the GO gp2protein files with the UniProt proteome project (Paul/Kara). Look over it and bring it to Amos as a proposal (Michael A.).<br />
* For GO, generate a list of what files are needed (gp2protein, spliceforms, all gene products), define what these files should be, and build a file structure. (Paul/Kara)<br />
* Pascale will provide the seed genes for the annotation set at the first of every month, and the sets are to decided by Paul and Kara's trees.<br />
* If there are problems with the tree, the MODs will correspond with Paul and Kara. This will be done on a one-on-one as-needed basis.<br />
* Annotations made by ancestral inference will get fed back to the MODs in gaf format for them to incorporate into their sets to submit to the GO database. 'RefGenome' will become the source of these annotations.<br />
<br />
== Paul: how curators can use evo trees ==<br />
(has slides)<br />
<br />
* Discussion of current process<br />
* New process<br />
** will now build trees using MOD data<br />
** these tree will be used to make annotations concurrently and consistantly with evo tree<br />
* Short-term solution has been implemented<br />
** some cutting and pasting done--a little ad hoc<br />
* What about the long term?<br />
** several ideas<br />
* update on progress with gene trees and homolset selection tool<br />
** getting there<br />
** far enought that it has worked on an end user machine<br />
* better definition than ortholog<br />
** equivalogs<br />
** genes most similar to common ancestor<br />
* Example: NEDD4<br />
** tool shown<br />
** judy: what info did you use?<br />
*** ensembl...<br />
* annotation inference based on homology<br />
** must be correct and consistant<br />
*** experimental evidence<br />
*** evolutionary correct paradigm<br />
*** traceable evidence trail<br />
** example... ubiquitin-protein ligase activity<br />
*** judy: showing just terminal nodes in GO tree? or going up the tree?<br />
**** actually, going up the tree<br />
**** will be able to put bootstrap values on the tree<br />
* tree gives us an explicit model for the evolution of gene func/proc<br />
** this allows consistent inferences<br />
* judy: long term plan is updating trees regularly and combine into AmiGO and look at how distributed in graph<br />
** will be able to see alll of the data at the same time to seem where you can and can't transfer information<br />
** interprot will make sure that all of the information we need is in there<br />
<br />
== Kara: the annotation process ==<br />
(has slides)<br />
<br />
* big picture (this is an iterative process)<br />
** have a new protein family curator that suggest protein based on tree<br />
** MOD annotate all experimental data to completion<br />
** protein curator mediates annotation review<br />
* mike: how do you envision interaction between mods <br />
** social; will talk more about it<br />
* rex: we need a fixed time scale to make sure that we get results<br />
* generating reports to help get outliers and other oddities<br />
* mike: are there equivalog sets that will be excluded?<br />
** [general discussion]<br />
* candace: will tree include bateria?<br />
** it does, it will<br />
** horizontal x-fer makes things hard<br />
* mike: <br />
** [general discussion]<br />
* judy: looking at GO next to trees would be neat<br />
* m.a.: what happens when the tree changes?<br />
** small changes in group won't matter<br />
** real question is if the common ancestor changes<br />
* princeton / p-pod update<br />
** search<br />
** spec dist graph<br />
** new algorithm (notom(?) from MIT)<br />
** interactive applet<br />
** if you have suggestions, please sent them along<br />
<br />
Discussion<br />
<br />
== Suzi: Discussion ==<br />
(has slides)<br />
<br />
* uniprot; complete proteome project<br />
* protein curator; how to efficiently incorporate input from all MODs<br />
* how to deliver resulting homol-based annotations to MODs<br />
* judy: doesn't like gp to protein files<br />
** what's in a name<br />
* judy: MODs are building gp to protein, how to work with uniprot?<br />
** judy: eventually they will be working together<br />
<br />
==== ACTION ITEM ====<br />
(mouse rat chicken zfish) GO contacts uniprot to sync<br />
<br />
* kimberly: want reference protein with all the exons?<br />
** yes<br />
<br />
==== ACTION ITEM ====<br />
Generate definition for what each of the files needs to be and generate tags<br />
(paul and kara)<br />
<br />
* judy: multiple reps of protein families, want to take advantage of them, like swissprot<br />
** completely extensible, can put in as many as you want<br />
* need to be careful with definitions, maybe we should be better<br />
* m.a.: we should go slow and prepare a document for this and make sure that we have everybody with us<br />
** we aren't in a hurry<br />
<br />
==== ACTION ITEM ====<br />
(Paul and Kara) draft and m.a. will take pass afterwards<br />
<br />
== Suzi: Mor Discussion ==<br />
(has slides)<br />
<br />
* let's talk about the flow<br />
** should we do it as in the slides?<br />
*** no complaints<br />
* paul: should we try this as part of electronic jamboree? we can try and time it<br />
** judy: a set of genes in a month<br />
** pascale: want to change how we do it<br />
*** <br />
** judy: how are we selecting genes ...?<br />
*** suzi: we use the trees<br />
**** judy: hat selection is dependent on exp anno<br />
** paul: we wont use current anno to select genes<br />
** pascale: disease genes, no anno, highly conserved<br />
*** some might be easier (pascale's display)<br />
** judy: are we going to contine with what we're doing?<br />
*** rotation, etc.<br />
** pascale: pascale and kara will define the set<br />
*** judy: set the priority sets<br />
**** rex: let's just move forward<br />
** judy: can we do this next week?<br />
*** yes<br />
<br />
==== ACTION ITEM====<br />
pascale will provide list at the beginning of each month<br />
<br />
* suzi: give a gene/focal point, what from every species is the protein that you want to include--that will be the tree stuff<br />
* suzi: no discussion about the seed; but we may have one about the set.<br />
* rex: let's just truct paul's trees, good enough<br />
* kara: will have much improvement once we start using trees<br />
* pascale: any problems should bump back to paul and kara, not necessary to discuss as a group<br />
* debbie: more fruitful to have calll just about inference set after jamboree<br />
* kara: want to just hammer things out with pascale and have a concrete system<br />
* judy: MODs should incorporate new inf instead of GO<br />
** rex: as req of being part of RG, need to add infs quickly<br />
** m.a.: <br />
*** judy: wary of paralog groups<br />
**** paul: that's what we're doing<br />
***** crosstalk<br />
**** paul: MODs should check tree, until comfortable<br />
*** paul: how does PF interface with mods?<br />
**** david: not conference, but one-on-one would be better<br />
***** rex: have them review, and if they have a problem, the onus is on them<br />
*** suzi: (on diagram)<br />
**** pascale gives example with diagram<br />
** m.a.: need to be in MOD and GO db; what is route?<br />
*** paul: we can put the non-MOD inferences in GOA?<br />
**** yes<br />
<br />
==== ACTION ITEM ====<br />
(pascale) picks gene by magic<br />
<br />
==== ACTION ITEM ====<br />
set done by kara and paul, complaints to them<br />
<br />
* trees done every six months<br />
<br />
==== ACTION ITEM ====<br />
one-on-one MOD discussion (if problem)<br />
<br />
* mechanics of how this all gets into MOD and GO db<br />
** suzi: possibilites:<br />
*** opt 1: if it goes back to MODs from PF DB<br />
**** there may be a delay<br />
**** rex: timelime agreement could solve it<br />
*** opt 2: done in DB load script<br />
*** rex: likes first; if we need police, so be it; opt 2 not good--mods shouls control their own data<br />
**** judy: agrees<br />
*** pascale: like opt 2<br />
**** crosstalk<br />
*** david: opt 1<br />
**** nervous about sync delays<br />
*** eurie: likes opt 1<br />
*** emily: opt 1<br />
<br />
==== ACTION ITEM ====<br />
(RG) MODs will fold in changes and pass them on to GO<br />
<br />
* judy: what is evcode, what is source?<br />
* judy: this will make versioning easier<br />
* rex: ref gen as source<br />
** increase visability--branding!<br />
** in twice yearly tree change, how big are they usually?<br />
*** paul: not too likely; and an auditable process<br />
*** pascale: let's say we have 5% of 10000 trees change, can we identify them?<br />
**** paul: since we;re just interested in local properties, not a big deal<br />
**** pascale: if there is new info in mouse for that tree ...<br />
***** need to make sure that annotations are current<br />
<br />
* suzi: evcode discussion should wait until we have something to discuss<br />
<br />
* everybody has warm fuzzies about the PF/RG developments<br />
<br />
== Mike: Annotation Progress ==<br />
(has slides)<br />
<br />
* folks like these graphs<br />
** shows sept 07<br />
** shows may 08<br />
*** chickens added<br />
*** not a lot of change<br />
** shows graph from a couple of days ago<br />
*** progress is clear<br />
* judy: uniprot has done human proteome, number are different<br />
* paul: has number on FTP site<br />
<br />
* RG graphs<br />
** sept 07<br />
** april 08<br />
*** number changed with <br />
** most recent<br />
*** everything decreased except human<br />
**** i can update if I get these in the next few hours<br />
** suzi: in proposal, we can use your software and automate it<br />
<br />
==== ACTION ITEM ====<br />
(berkeley) automate mike's graph (as in proposal), need to be able to see progress through time<br />
<br />
== David: RG from ont dev prespective ==<br />
(has slides)<br />
<br />
* we work through SF<br />
** RG request are prioritized<br />
*** two flavors<br />
**** new term for RG<br />
**** problem areas in ont<br />
***** slower<br />
* need annotors to get info about "response to" terms<br />
* doing signalling now<br />
* ...argh...<br />
<br />
* please use SF and mark as RG<br />
<br />
* pascale: documentation and anno consis<br />
** when doing big branch of ont, more discussion with RG group<br />
* jen: doc for every big reorg, sometimes I don't know about a change<br />
* debbie: def is sometimes unclear<br />
** ex: ATP binding<br />
** pascale: "binding", "regulating", ev--these are always a problem<br />
** pascale: we need a group to make a proposal to get the defs down flat<br />
** peter: ont distinguishes binding from catalysis <br />
** kimberly: we're not consistant about how we use binding<br />
** rex: documentation is the core issue<br />
*** docs will solve all of the above<br />
<br />
==== ACTION ITEM ====<br />
come up with rational plan for documentation and indexing (including rational and examples)<br />
<br />
* suzi: we can ask the SAB about this as well<br />
* ingrid: i look at term def<br />
* how should we do this?<br />
* seth: why not GONuts and not muck-up the data<br />
* richard: examples would be very valuable, including counter examples<br />
* pascale: add more fields that didfferent people could see<br />
* alex: users should see the information<br />
* jen: wants one single information resource<br />
* mike: this curator info shouldn't be private--this is good stuff<br />
* debbie: seconds mike, and GONuts<br />
* emily: seconds<br />
** children as well<br />
* jen: graph can be weird<br />
** david: will fill in missing bits<br />
* jane: docs go bad over time need freshness<br />
* david: great defs vs. curator judgement--still an art<br />
** harold: seconds; always constrained by training<br />
<br />
...<br />
<br />
==== ACTION ITEM ====<br />
<br />
= Final = <br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues<br />
<br />
= Previous Incomplete Action Items =<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| In Progress<br />
| Documentation working group<br />
| Document annotation SOPs <br />
| Another factor we have been tracking is when a curator judges that the curation of a gene is ‘comprehensive’, that is, that is accurately represents the biology (irrespective of the number of papers available or read). This appears in the spreadsheets. The guideline is that when there are few papers, all papers should be read; when there are many (a curator can judge what is too many), then a review should be read to find the important primary literature and decide what information needs to be captured. We don’t keep track of whether or not reviews have been read. Wormbase uses textpresso (PMID 15383839), that helps ensuring curators do not overlook information. The ‘comprehensive’ curation status doesn’t get invalidated when a newer paper is published; however, curators may (and are encouraged to) update the date when the newer literature is curated.<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with is_a only paths<br />
|<br />
|-<br />
|<br />
| Chris Mungall<br />
| Re-calculate with experimental codes only<br />
| generate several versions of the data classified by different evidence codes?<br />
|-<br />
|<br />
| Chris Mungall<br />
| Provide such reports on a regular basis<br />
|<br />
|-<br />
|<br />
| Judy Blake<br />
| Contact NCBI/NLM/OMIM to link to reference genome genes<br />
|<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to Gene Association File (GAF) <br />
| column 2 is canonical gene ID; column 17 is thing you are annotating (always required); column 12 matches column 17 and contains SO ID's; add header to gene association file<br />
|-<br />
| In progress<br />
| Documentation working group<br />
| Document Changes to gp2protein file <br />
| includes complete gene index (except for pseudogenes and transposons); column 1 is canonical gene ID; column 2 is accession for sequence of longest form of protein from UniProtKB: or NCBI; syntax of gp2protein file will be provided by Mike and Chris <br />
|-<br />
| In progress<br />
| (Jane)<br />
| write notice of changes to GAF and gp2protein to users <br />
| <br />
|-<br />
| In progress<br />
| MODs + Ben Hitz<br />
| make sure that their input matches new GAF and gp2protein requirements <br />
| <br />
|-<br />
| <br />
| Seth Carbon<br />
| Have AmiGO show co-occurrency terms<br />
| similar to function in QuickGO. <br />
|-<br />
| <br />
| Seth Carbon & Val Wood<br />
| SLIM by SLIM matrix<br />
| Would be used to review intersections of different cellular processes and look for unexpected intersections which may identify possible errors. Try first applying to function and component terms; outline cells that you expect to be empty, Have these matrices generated automatically from the AmiGO database. <br />
|-<br />
|<br />
| Ben & Mike<br />
| Get isoforms into GO database<br />
|<br />
|-<br />
|<br />
| MODs & Chris<br />
| Consistent use of IMP "with" column<br />
| Chris will be talking to individual groups with how they use the with column for IMP. Each MOD groups needs to respond to this for Chris.<br />
|-<br />
|<br />
| Michelle<br />
| Implement Michelle's proposal<br />
| decide whether to put 'response to drug' ID in column 16 or is separate IC annotation. Annotate to chemical term ‘response to cocaine’, co-annotate with chemical term for now, then later when available, put GO ID for “response to drug’ in column 16 (or separate IC annotation).<br />
|-<br />
| pending<br />
| Midori, David, Chris, Mike Bada<br />
| Chemical derivatives and metabolism terms<br />
| Need input from Chris and Mike on how much can be automated; possibly also current and near-future state of ChEBI<br />
|-<br />
|<br />
| MODs & Pascale<br />
| All groups to check on how they use IGI and update annotations as per Princeton discussion.<br />
|<br />
|-<br />
|<br />
| Val <br />
| Circulate draft doc on how contributes_to can & can't be used<br />
| Will include: "Would this annotation make sense if this subunit was" ... [thought not finished; might be something like "viewed by itself"].<br />
|-<br />
|<br />
| MODs & Pascale<br />
| Check existing annotations for "contributes_to" with IDA<br />
| We think only allow contributes_to with IDA. Look into adding to annotation checking script to flag contributes_to.<br />
|-<br />
| <br />
| Jen<br />
| Implement rules and software for sanity checking automated annotations (species-based trigger file).<br />
| <br />
|}<br />
<br />
= New Items =<br />
<br />
<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Status<br />
! Responsible Party<br />
! Task<br />
! Comments<br />
|-<br />
| empty<br />
| empty<br />
| empty<br />
| empty<br />
|}</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1626820th GO Consortium Meeting Minutes2008-10-21T22:00:47Z<p>Juliep: /* Michelle: Evidence code ontology (ECO) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Evidence code ontology (ECO) (Michelle) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
In principle, most everyone was supportive of the idea to separate the evidence used to make the annotation and the curation method to make that annotation. There was, however, much discussion on the scope and implementation of this proposal.<br />
<br />
Two implementation methods were proposed:<br />
# A new column that contains a text describing the annotation process<br />
# Creating a cross-product between the evidence code branch of the ECO and a methods branch of the ECO. This ID would be used in the GAF.<br />
<br />
Because proposal 2 does not create a new column and is expandable to multiple combinations, it was favored.<br />
<br />
Proposed methods were not agreed upon but words that were used to describe included<br />
*curator reviewed<br />
*not curator reviewed<br />
*electronic<br />
*manual<br />
<br />
A direct consequence of this would be that IEA would go away. Emily proposed the following mappings:<br />
*Interpro2GO -> ISS/ISM, not reviewed<br />
*keyword mappings -> TAS, not reviewed<br />
<br />
IEAs are stripped out after a year. How would those "not curator reviewed' be treated? Since the intent was to remove annotations based on sequences, maybe only those should be removed because they can be easily recomputed. Large-scale/high-volume/high-throughput experiments won't be repeated but still are experimental. We would have to consider exceptions for these. <br />
<br />
It was agreed that multiple issues need to be considered when dealing with this new qualifier of evidence codes:<br />
# the experimental evidence <br />
# was there judgement involved<br />
# was there a review of the data<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO (Suzi, Michelle, Judy, Pascale, Emily, Eurie)<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1626220th GO Consortium Meeting Minutes2008-10-21T21:53:45Z<p>Juliep: /* Michelle: Evidence code ontology (ECO) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Mike asked is ECO the responsibility of this community? Michael says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. Michael and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--Suzi pointed out you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
In response to a question from Eurie, it was stated that the GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1626120th GO Consortium Meeting Minutes2008-10-21T21:49:39Z<p>Juliep: /* Transitive Relationships in GO */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
(has slides)<br />
<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1626020th GO Consortium Meeting Minutes2008-10-21T21:48:54Z<p>Juliep: /* Transitive Relationships in GO */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
Relationships in terms, it's wrong to just slim terms given the different relationship types. Unless you're careful, you will violate true path rules.<br />
<br />
* The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
* If you regulate a process, you regulate part of that process, not that whole process.<br />
* As you add more relationships, you need to create these transitive closures.<br />
* And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
Judy proposed that we need a tool to help with this.<br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1625920th GO Consortium Meeting Minutes2008-10-21T21:47:21Z<p>Juliep: /* Michelle: Evidence code ontology (ECO) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
Relationships in terms - why it's wrong to just slim terms.<br />
<br />
The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
<br />
If you regulate a process, you regulate part of that process, not that whole process.<br />
<br />
As you add more relationships, need to create these transitive closures.<br />
<br />
And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1625820th GO Consortium Meeting Minutes2008-10-21T21:47:04Z<p>Juliep: /* Look at action item from last meeting */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
Of 47,000 errors in the GOA file (0.14% of total), only 5 manual annotations were flagged suggesting that the graph may need improvement. The rest were IEAs. <br />
<br />
Trigger file is being used by GOA and MGI for consistency. There was discussion whether this use should be expanded and run against all annotations when the files are submitted. This would address a QC aspect. <br />
<br />
Emily said that it can be used as feedback to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems. Dan also suggested that it could be integrated into QuickGO as a public resource.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
Relationships in terms - why it's wrong to just slim terms.<br />
<br />
The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
<br />
If you regulate a process, you regulate part of that process, not that whole process.<br />
<br />
As you add more relationships, need to create these transitive closures.<br />
<br />
And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action items from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward documentations issues</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1625620th GO Consortium Meeting Minutes2008-10-21T21:45:58Z<p>Juliep: /* Michelle: Evidence code ontology (ECO) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
Goals:<br />
* Correct incosistencies in the ECO with GO<br />
** ECO exists as its own and includes things other than GO and GO pulls from the ECO, using a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
Relationships in terms - why it's wrong to just slim terms.<br />
<br />
The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
<br />
If you regulate a process, you regulate part of that process, not that whole process.<br />
<br />
As you add more relationships, need to create these transitive closures.<br />
<br />
And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1625520th GO Consortium Meeting Minutes2008-10-21T21:44:47Z<p>Juliep: /* Michelle: Evidence code ontology (ECO) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
This is an ongoing process. Lots of "regulates" terms.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
All "organization & biogeneis" terms will be changed to "organization" with the proposed high level structure:<br />
<br />
<pre><br />
biogenesis<br />
organization<br />
biosynthesis/formation<br />
assembly<br />
modification/processing<br />
disassembly<br />
catabolism<br />
maintenance<br />
</pre><br />
====ACTION ITEM====<br />
* Continue work on "organization and biogenesis" terms. Maybe biogenesis & organization should be switched at the higher level but this is up for discussion.<br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
Is responding to the signal the same to the reception of the signal? Currently defined as within the realm of reception of the signal?<br />
<br />
===Future content meeting discussion===<br />
The discussion of signaling touches on every species. David pointed that some of these are huge issues - signaling alone can be roughly categorized into<br />
*g-protein coupled receptor signaling<br />
*calcium signaling<br />
*tyrosine kinase singaling<br />
*MAP kinase cascade<br />
===ACTION ITEMS=== <br />
* Pursue an ontology development meeting one or two<br />
** Viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Couple a GO meeting with major meetings on these topics<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking over managing the Evidence Code Ontology.<br />
<br />
Goals:<br />
* correct incosistencies in the eco with GO<br />
* eco exists as its own and includes things other than GO<br />
* GO pulls from the eco - uses a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns from Peter about overloading the EXP term and/or losing accuracy. There is a lot of time spent debating which lower code to use and Rex would rather have people agree to EXP and spend more time annotating.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption. We could also explore writing software to slim the evidence codes used.<br />
<br />
===ACTION ITEMS===<br />
* We will use the ECO and create an EV code ontology tracker (Suzi)<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
Relationships in terms - why it's wrong to just slim terms.<br />
<br />
The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
<br />
If you regulate a process, you regulate part of that process, not that whole process.<br />
<br />
As you add more relationships, need to create these transitive closures.<br />
<br />
And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1625120th GO Consortium Meeting Minutes2008-10-21T21:34:35Z<p>Juliep: /* Cross products: Column 16 (Tanya) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking it over.<br />
<br />
Goals:<br />
* correct incosistencies in the eco with GO<br />
* eco exists as its own and includes things other than GO<br />
* GO pulls from the eco - uses a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns about overloading the EXP term and also concerns<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption.<br />
<br />
DECISION: we will use the ECO.<br />
<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. hard to figure out what evidence is in some cases.<br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
Initially proposed in Jan 2007.<br />
<br />
Reminder: this is extra information to combine multiple terms in a single annotation. These are GOIDs that we don't want to encode links in the ontology. If there is more than 1 localization, they can be piped and several different ontologies can be piped in the same row. <br />
* You are not restricted to one ontology in column 16<br />
* Column 16 is optional<br />
* Column 16 can also be used to identify a target i.e. regulation of transcription (Note that the current documentation states that column 16 is only for external ontologies.) or a chebi ID for a chemical when annotating "response to drug". <br />
<br />
There were two proposed solutions on the table:<br />
* simple solution<br />
* expressive solution<br />
<br />
No one had concerns about adding this column and a few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
Relationships in terms - why it's wrong to just slim terms.<br />
<br />
The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
<br />
If you regulate a process, you regulate part of that process, not that whole process.<br />
<br />
As you add more relationships, need to create these transitive closures.<br />
<br />
And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1625020th GO Consortium Meeting Minutes2008-10-21T21:29:07Z<p>Juliep: /* Transitive Relationships in GO */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes. Jane emphasized that we couldn't do testing for all tools but the users need to test.<br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==Quality Control (Tanya)==<br />
Much of the information is on the wiki. For regulation terms, the reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing. These were all reviewed.<br />
<br />
Ontology developers will continue to review Chris' reports - it's becoming part of the process of ontology development since it is part of OBO-edit.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking it over.<br />
<br />
Goals:<br />
* correct incosistencies in the eco with GO<br />
* eco exists as its own and includes things other than GO<br />
* GO pulls from the eco - uses a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns about overloading the EXP term and also concerns<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption.<br />
<br />
DECISION: we will use the ECO.<br />
<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. hard to figure out what evidence is in some cases.<br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
* Proposed solutions<br />
** simple solution<br />
** expressive solution<br />
* There are examples of both in the wiki and it hasn't been decided which to use<br />
* No one had concerns about adding this column<br />
* A few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
* not restricted to one ontology in column 16<br />
* column 16 is optional<br />
* column can also be used to identify a target i.e. regulation of transcription<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
Relationships in terms - why it's wrong to just slim terms.<br />
<br />
The composition of is_a and part_of need to be taken into consideration for true path violations.<br />
<br />
If you regulate a process, you regulate part of that process, not that whole process.<br />
<br />
As you add more relationships, need to create these transitive closures.<br />
<br />
And as you take these into consideration, the slimming can become more sophisticated.<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1624720th GO Consortium Meeting Minutes2008-10-21T21:25:57Z<p>Juliep: /* PAMGO (Michelle/Candace) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes.<br />
<br />
==Quality Control (Tanya)==<br />
(info on wiki)<br />
<br />
Regulation terms: reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing<br />
<br />
* Emily: GO tools needing to adapt with the proliferation of the ontologies, it's in the OBO edit. Also, we shouldn't endorse tools that do not appropriately slim. <br />
* Emily/Jane: We should continuously send out notices but it's the responsibility of the tool creator to take the initiative to test their tools.<br />
<br />
* continue to review chris' reports--becoming part of the process <br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking it over.<br />
<br />
Goals:<br />
* correct incosistencies in the eco with GO<br />
* eco exists as its own and includes things other than GO<br />
* GO pulls from the eco - uses a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns about overloading the EXP term and also concerns<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption.<br />
<br />
DECISION: we will use the ECO.<br />
<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. hard to figure out what evidence is in some cases.<br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
Candance gives an overview of the new terms. Project is coming to an end - funding is coming to an end. New gene association files have been submitted.<br />
<br />
Successes<br />
* PAMGO terms outside of PAMGO: viruses, c. albicans, p. falciparum, t. cruzi, t.brucei.<br />
<br />
Issues<br />
* incorrect uses also.<br />
* there are a few terms where it is ambiguous whether or not the process is for the host or the virus side.<br />
<br />
Future directions<br />
* fix virus terms<br />
* add comments<br />
* adopt more descriptive form for annotations.<br />
<br />
Fixes<br />
* missing taxon ids for dual taxons<br />
* need a way to capture "acted_upon" annotations<br />
<br />
Dual taxon IDs<br />
* still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'interaction with host' branches to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
* Proposed solutions<br />
** simple solution<br />
** expressive solution<br />
* There are examples of both in the wiki and it hasn't been decided which to use<br />
* No one had concerns about adding this column<br />
* A few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
* not restricted to one ontology in column 16<br />
* column 16 is optional<br />
* column can also be used to identify a target i.e. regulation of transcription<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1624620th GO Consortium Meeting Minutes2008-10-21T21:23:27Z<p>Juliep: /* Separating annotation method from experimental method */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
New relationships will be released to the public in Feb 2009. This is the first cross-ontology links between BP and MF. It will occur between the BP "regulation of catalytic activity" and MF "catalytic activity". Those functions that regulate function terms will get the regulates relationship.<br />
<br />
One major consequence is that all groups have to take into account relationships. The BP "negative regulation of kinase activity" is part_of "kinase activity", but the slimming will make them "kinase activity". Need to be careful about this.<br />
<br />
Michael was concerned about whether the meaning of "part_of" was being overloaded. David replied that we probably are but practically, it may not matter because the child term really cannot be part of the both parents at the same time.<br />
<br />
We will have to make sure that GO tools support these links. In addition, we need to make sure that users who develop tools are aware of these changes.<br />
<br />
==Quality Control (Tanya)==<br />
(info on wiki)<br />
<br />
Regulation terms: reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing<br />
<br />
* Emily: GO tools needing to adapt with the proliferation of the ontologies, it's in the OBO edit. Also, we shouldn't endorse tools that do not appropriately slim. <br />
* Emily/Jane: We should continuously send out notices but it's the responsibility of the tool creator to take the initiative to test their tools.<br />
<br />
* continue to review chris' reports--becoming part of the process <br />
<br />
===ACTION ITEM===<br />
* Send out function process email again.<br />
* Release examples of relationship usage for software development.<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking it over.<br />
<br />
Goals:<br />
* correct incosistencies in the eco with GO<br />
* eco exists as its own and includes things other than GO<br />
* GO pulls from the eco - uses a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns about overloading the EXP term and also concerns<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption.<br />
<br />
DECISION: we will use the ECO.<br />
<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. hard to figure out what evidence is in some cases.<br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code. We have a way to indicate that an annotation has not been manually reviewed. <br />
* Chris' proposal: use ECO and make a cross-product between evidence code and method. evidence code has an ID, methodology has an ID, the cross-product would have an instantiated ID. Then don't need to make another column on the GAF.<br />
** Implication is that IEA would go away.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP situation?<br />
* Many people: NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
* Judy: with the metabalome projects, is there anything that the GO community can do or are you just going to use the GO?<br />
* Michelle: the latter<br />
* Jane: using the triggers to find places in the ontology that have issues?<br />
<br />
* dual taxon IDs<br />
** still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'response to host' terms to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
* Proposed solutions<br />
** simple solution<br />
** expressive solution<br />
* There are examples of both in the wiki and it hasn't been decided which to use<br />
* No one had concerns about adding this column<br />
* A few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
* not restricted to one ontology in column 16<br />
* column 16 is optional<br />
* column can also be used to identify a target i.e. regulation of transcription<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1624320th GO Consortium Meeting Minutes2008-10-21T21:14:04Z<p>Juliep: /* Michelle: Evidence code ontology (ECO) */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function should be a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. Ingrid mentioned John Ingram (an experienced physiologist) said a metabolic pathway should begin and end with a central metabolite. Then pathways can feed into a common point that can then go to a central metabolite. But there is probably less consensus for models that are still being developed. All agree that a discussion needs to occur to work on coming to a common agreement.<br />
<br />
Paul pointed out there we were discussing two extremes: an uncurated automated link and curated links. The curated links are the ultimate goal but there could be a compromise in the middle. The relationship linked between MF and BP go through KEGG, that evidence trail is documented. This is something better than "sometimes part_of". The concern with this is that changes other groups make need to be propagated. <br />
<br />
There was a discussion about the impact on curation. With these inter-ontology links, you have to take the links in account as a true path rule. In addition, how much evidence do you need to make those annotations? That is why there is the "sometimes_part_of" but what if that pathway doesn't exist in your organism?<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
<br />
* there will be problems with slimming if they don't think about relationships<br />
* ACTION: software, release examples of relationship usage <br />
* michael: are we overloading part_of<br />
** david: yes we are, but it probably doesn't matter.<br />
<br />
Terms in MF that describe fns that regulate other fns - e.g. inhibitor activity<br />
<br />
TS regulator activity - describes fns that regulate processes<br />
<br />
Feb 2009 - regulates relationships going into the db full tilt<br />
<br />
*big impact on SLIMMING activities<br />
*simple slimming is not a good idea<br />
*will have to enforce community awareness of relationships<br />
*test case for whether inter-ontology links will break software or not<br />
*will provide backups for those not up to date with relationships<br />
<br />
<br />
- Michael - are we overloading part-of?<br />
* David: We've looked at everything in the BP that have more than one part_of parent. Gut feeling is 'yes', but practical feeling is 'it doesn't matter'. i.e. development of an anatomical structure.<br />
<br />
<br />
==Quality Control (Tanya)==<br />
(info on wiki)<br />
<br />
Regulation terms: reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing<br />
<br />
* Emily: GO tools needing to adapt with the proliferation of the ontologies, it's in the OBO edit. Also, we shouldn't endorse tools that do not appropriately slim. <br />
* Emily/Jane: We should continuously send out notices but it's the responsibility of the tool creator to take the initiative to test their tools.<br />
<br />
* continue to review chris' reports--becoming part of the process <br />
<br />
===ACTION ITEM===<br />
* send out function process email again<br />
* we now have systematic ways of determining right, not just ad hoc<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking it over.<br />
<br />
Goals:<br />
* correct incosistencies in the eco with GO<br />
* eco exists as its own and includes things other than GO<br />
* GO pulls from the eco - uses a subset<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you should annotate to the degree of knowledge available and this might end up being to the more general EV code. Also this allows for not having to retrofit older annotations as brought up by Harold.<br />
<br />
Suzi brought up there could be various slim sets for various projects - AmiGO, Ref Genome, etc. for display purposes in the interfaces.<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have use more if they wanted, but would have to convert it into the standard set for the GA file.<br />
<br />
<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available. There were concerns about overloading the EXP term and also concerns<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption.<br />
<br />
DECISION: we will use the ECO.<br />
<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. hard to figure out what evidence is in some cases.<br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP/<br />
NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
* Judy: with the metabalome projects, is there anything that the GO community can do or are you just going to use the GO?<br />
* Michelle: the latter<br />
* Jane: using the triggers to find places in the ontology that have issues?<br />
<br />
* dual taxon IDs<br />
** still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'response to host' terms to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
* Proposed solutions<br />
** simple solution<br />
** expressive solution<br />
* There are examples of both in the wiki and it hasn't been decided which to use<br />
* No one had concerns about adding this column<br />
* A few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
* not restricted to one ontology in column 16<br />
* column 16 is optional<br />
* column can also be used to identify a target i.e. regulation of transcription<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1624120th GO Consortium Meeting Minutes2008-10-21T21:05:18Z<p>Juliep: /* General Annotation Issues */</p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Theory and examples of function and process links (Harold, Jen)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
* peter: counter-example ?? <br />
<br />
* suzi: never really done annotations to conjuntive annotations<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. <br />
<br />
Ingrid mentioned John Ingram is an experienced physiologist. His idea of a metabolic pathway should begin and end with a central metabolite. There are pathways that feed into a common point that can then go to a central metabolite.<br />
<br />
But All both agreed that a discussion needs to occur.<br />
<br />
<br />
* Peter: manual curation will be necessary ; also, legacy clean-up problems; may be hard to get mutually ok; For metabolites, there is more consensus than something like apoptosis. We are also going to rediscover the sensu problem. <br />
* let's explore how good can common start and ends can be created in the GO<br />
* judy: we need a process to work towards a shared start and end, but respect the dfferences; we should just get the ones where we can get the overlaps first<br />
* paul: is there a compromise argreement for the interim? saw two extremes (some has part and hash part with sublasses); external layer between function and process, start with a sampling that are more specific; <br />
* rex: when thay make changes, how do they get propagated so they don't break our system?<br />
* eurie: Annotations with links between function and process--sometimes you just don't have the evidence to make the annotation without breaking true path rules. It becomes an annotation issue when true path rules have to be considered.<br />
* Jen: That's why we are asking for sometimes_part_of<br />
* Kimberly: Would we have to use sometimes_part in all of these cases and couldn't we do better in cases where we have the information.<br />
* judy: what descisions do we need to make?<br />
<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
<br />
* there will be problems with slimming if they don't think about relationships<br />
* ACTION: software, release examples of relationship usage <br />
* michael: are we overloading part_of<br />
** david: yes we are, but it probably doesn't matter.<br />
<br />
Terms in MF that describe fns that regulate other fns - e.g. inhibitor activity<br />
<br />
TS regulator activity - describes fns that regulate processes<br />
<br />
Feb 2009 - regulates relationships going into the db full tilt<br />
<br />
*big impact on SLIMMING activities<br />
*simple slimming is not a good idea<br />
*will have to enforce community awareness of relationships<br />
*test case for whether inter-ontology links will break software or not<br />
*will provide backups for those not up to date with relationships<br />
<br />
<br />
- Michael - are we overloading part-of?<br />
* David: We've looked at everything in the BP that have more than one part_of parent. Gut feeling is 'yes', but practical feeling is 'it doesn't matter'. i.e. development of an anatomical structure.<br />
<br />
<br />
==Quality Control (Tanya)==<br />
(info on wiki)<br />
<br />
Regulation terms: reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing<br />
<br />
* Emily: GO tools needing to adapt with the proliferation of the ontologies, it's in the OBO edit. Also, we shouldn't endorse tools that do not appropriately slim. <br />
* Emily/Jane: We should continuously send out notices but it's the responsibility of the tool creator to take the initiative to test their tools.<br />
<br />
* continue to review chris' reports--becoming part of the process <br />
<br />
===ACTION ITEM===<br />
* send out function process email again<br />
* we now have systematic ways of determining right, not just ad hoc<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
Michelle is taking it over.<br />
<br />
Goals:<br />
* correct incosistencies in the eco with GO<br />
* eco exists as its own and includes things other than GO<br />
* GO pulls from the eco - uses a subset<br />
<br />
<br />
Is ECO the responsibility of this community? MA says yes because we started it. We have not used it because we wanted to start out pretty easy. TAIR then wanted a much richer set of evidence codes. MA and Sue did a mapping. But when TAIR reports to GO, they collapse the evidence codes down. Those arguments are still valid. If curators were faced with more evidence codes, it would take longer. IDA could be expanded to a zillion codes.<br />
<br />
MA: We should integrate GO evidences into ECO, GO should keep to the slim set.<br />
<br />
But will GO incorporate the use of more evidence codes? <br />
Judy seconds MA's statement.<br />
<br />
<br />
<br />
Michael thought we should integrate GO evidence codes into the ECO because other people might use them and that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.) Judy agreed and said if an individual MOD wants to make use of the granular codes, they can, but they must be mapped up to the higher-level codes used by the GO.<br />
<br />
Pascale asked if we needed to use the the more granular terms adopted by GO (ISM, ISO, ISA) or if we could keep to the higher level terms. This was deemed fine--you . Also this allowed for not having to retrofit older annotations as brought up by Harold.<br />
<br />
GO <br />
<br />
<br />
The GOC would only set standards for the GOC accepted codes, not all codes. Each database could have <br />
<br />
Suzi: there could be various slim sets for various projects - AmiGO, Ref Genome, etc.<br />
<br />
Maybe EXP would be better when there is no consensus on which evidence code should be made. This may prevent spinning it. For use of ref genome, maybe have to have additional standards available.<br />
<br />
Any evidence code that is in the ECO could be submitted to the GOC for adoption.<br />
<br />
DECISION: we will use the ECO.<br />
<br />
<br />
<br />
<br />
<br />
Pascale: Do we need to go as granular as we can within the EV codes that are currently used by GO?<br />
Judy: as far a GO is concerned, should stay high-level; but communities should have mappables; <br />
* Suzi: Like any annotations, do it to the degree of knowledge available. You might want to go to the higher term. Secondly, we might want to use an EV code slim for AmiGO. should do to maximal degree available; different AmiGO slim and Ref Genome slim? when evcodes are organized, we can have x-prod modifiers <br />
* Rex: Why would you want to do that?<br />
* Mike/Suzi: b/c it's an interface. Just for display purposes<br />
* Suzi: When we have the evidence codes in the ontology we can append an experimental method to it. <br />
* Harold: Expansion of more granular descriptions--there would be a problem of two annotations of pre and post <br />
* Eurie: In terms of setting annotation standards for ev codes. Would we set standards just for just the GO set or for the entire ECO set.<br />
* Mike: Annotation standards would be just for the GO evidence codes. You can use more if you want to, but you have to convert it into the standard set for the GA file.<br />
* Emily: For the reference genome group, we have decided to use IDA, IMP, IGI, IPI, IEP, and the parent EXP is for groups that are not in the ref genome group but annotate, like Reactome.<br />
* Rex: Some cases there is a lack of agreement about which evidence code to apply in a situation would allow <br />
* harold: lost information from past annotations<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. hard to figure out what evidence is in some cases.<br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP/<br />
NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
* Judy: with the metabalome projects, is there anything that the GO community can do or are you just going to use the GO?<br />
* Michelle: the latter<br />
* Jane: using the triggers to find places in the ontology that have issues?<br />
<br />
* dual taxon IDs<br />
** still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'response to host' terms to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
* Proposed solutions<br />
** simple solution<br />
** expressive solution<br />
* There are examples of both in the wiki and it hasn't been decided which to use<br />
* No one had concerns about adding this column<br />
* A few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
* not restricted to one ontology in column 16<br />
* column 16 is optional<br />
* column can also be used to identify a target i.e. regulation of transcription<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1623720th GO Consortium Meeting Minutes2008-10-21T20:46:43Z<p>Juliep: </p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Biochemical pathway function and process links (Harold)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
==Theory and examples of function and process (Jen)==<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
* peter: counter-example ?? <br />
<br />
* suzi: never really done annotations to conjuntive annotations<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. <br />
<br />
Ingrid mentioned John Ingram is an experienced physiologist. His idea of a metabolic pathway should begin and end with a central metabolite. There are pathways that feed into a common point that can then go to a central metabolite.<br />
<br />
But All both agreed that a discussion needs to occur.<br />
<br />
<br />
* Peter: manual curation will be necessary ; also, legacy clean-up problems; may be hard to get mutually ok; For metabolites, there is more consensus than something like apoptosis. We are also going to rediscover the sensu problem. <br />
* let's explore how good can common start and ends can be created in the GO<br />
* judy: we need a process to work towards a shared start and end, but respect the dfferences; we should just get the ones where we can get the overlaps first<br />
* paul: is there a compromise argreement for the interim? saw two extremes (some has part and hash part with sublasses); external layer between function and process, start with a sampling that are more specific; <br />
* rex: when thay make changes, how do they get propagated so they don't break our system?<br />
* eurie: Annotations with links between function and process--sometimes you just don't have the evidence to make the annotation without breaking true path rules. It becomes an annotation issue when true path rules have to be considered.<br />
* Jen: That's why we are asking for sometimes_part_of<br />
* Kimberly: Would we have to use sometimes_part in all of these cases and couldn't we do better in cases where we have the information.<br />
* judy: what descisions do we need to make?<br />
<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
<br />
* there will be problems with slimming if they don't think about relationships<br />
* ACTION: software, release examples of relationship usage <br />
* michael: are we overloading part_of<br />
** david: yes we are, but it probably doesn't matter.<br />
<br />
Terms in MF that describe fns that regulate other fns - e.g. inhibitor activity<br />
<br />
TS regulator activity - describes fns that regulate processes<br />
<br />
Feb 2009 - regulates relationships going into the db full tilt<br />
<br />
*big impact on SLIMMING activities<br />
*simple slimming is not a good idea<br />
*will have to enforce community awareness of relationships<br />
*test case for whether inter-ontology links will break software or not<br />
*will provide backups for those not up to date with relationships<br />
<br />
<br />
- Michael - are we overloading part-of?<br />
* David: We've looked at everything in the BP that have more than one part_of parent. Gut feeling is 'yes', but practical feeling is 'it doesn't matter'. i.e. development of an anatomical structure.<br />
<br />
<br />
==Quality Control (Tanya)==<br />
(info on wiki)<br />
<br />
Regulation terms: reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing<br />
<br />
* Emily: GO tools needing to adapt with the proliferation of the ontologies, it's in the OBO edit. Also, we shouldn't endorse tools that do not appropriately slim. <br />
* Emily/Jane: We should continuously send out notices but it's the responsibility of the tool creator to take the initiative to test their tools.<br />
<br />
* continue to review chris' reports--becoming part of the process <br />
<br />
===ACTION ITEM===<br />
* send out function process email again<br />
* we now have systematic ways of determining right, not just ad hoc<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
== Michelle: Evidence code ontology (ECO) ==<br />
<br />
* includes things other than GO<br />
** curation of museum collections<br />
** morpho<br />
** etc<br />
* we want to corrct inconsistancies<br />
* want to make sure that GO is a subet<br />
* there will be a tracker<br />
<br />
<br />
* Mike: is ECO a responsibility of this community?<br />
* Michael: We started it.<br />
* Mike: If we started it, then why don't we use it<br />
* Michael: kept the list short<br />
# so EV codes can be easily distinguished<br />
# reasonably easy for the annotators to use it<br />
* TAIR wanted a much richer set of EV codes. Sue and Michael did a mapping to GO evidence codes.<br />
* If annotators were faced with 1500 evidence codes it would slow down annotation and wouldn't add a whole lot to the GO.<br />
* IEAs are not ISS's<br />
* We should integrate GO evidence codes into the ECO b/c other people might use it. And that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.)<br />
Pascale: Is it the case, b/c more hierarchical that we use the higher terms or to use the most granular.<br />
Judy: As far as GO is concerned, we should stay with the high level. Each mod can do more specific sub-curation. The power of the high-level EV codes is that we can bring together all these different communities.<br />
Pascale: Do we need to go as granular as we can within the EV codes that are currently used by GO?<br />
Judy: as far a GO is concerned, should stay high-level; but communities should have mappables; <br />
* Suzi: Like any annotations, do it to the degree of knowledge available. You might want to go to the higher term. Secondly, we might want to use an EV code slim for AmiGO. should do to maximal degree available; different AmiGO slim and Ref Genome slim? when evcodes are organized, we can have x-prod modifiers <br />
* Rex: Why would you want to do that?<br />
* Mike/Suzi: b/c it's an interface. Just for display purposes<br />
* Suzi: When we have the evidence codes in the ontology we can append an experimental method to it. <br />
* Harold: Expansion of more granular descriptions--there would be a problem of two annotations of pre and post <br />
* Eurie: In terms of setting annotation standards for ev codes. Would we set standards just for just the GO set or for the entire ECO set.<br />
* Mike: Annotation standards would be just for the GO evidence codes. You can use more if you want to, but you have to convert it into the standard set for the GA file.<br />
* Emily: For the reference genome group, we have decided to use IDA, IMP, IGI, IPI, IEP, and the parent EXP is for groups that are not in the ref genome group but annotate, like Reactome.<br />
* Rex: Some cases there is a lack of agreement about which evidence code to apply in a situation would allow <br />
* harold: lost information from past annotations<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. hard to figure out what evidence is in some cases.<br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP/<br />
NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
==PAMGO (Michelle/Candace)==<br />
* Judy: with the metabalome projects, is there anything that the GO community can do or are you just going to use the GO?<br />
* Michelle: the latter<br />
* Jane: using the triggers to find places in the ontology that have issues?<br />
<br />
* dual taxon IDs<br />
** still not displayed in AmiGO due to technical issues<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'response to host' terms to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
* Proposed solutions<br />
** simple solution<br />
** expressive solution<br />
* There are examples of both in the wiki and it hasn't been decided which to use<br />
* No one had concerns about adding this column<br />
* A few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
* not restricted to one ontology in column 16<br />
* column 16 is optional<br />
* column can also be used to identify a target i.e. regulation of transcription<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Transitive Relationships in GO==<br />
<br />
* judy: we need a tool<br />
<br />
== Look at action item from last meeting ==<br />
<br />
* push forward not dones<br />
* carry forward last pascale</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1623620th GO Consortium Meeting Minutes2008-10-21T20:36:42Z<p>Juliep: </p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Most of the report is on the wiki. A lot has been accomplished. Highlights include the following:<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
* peptidase reorg is finished: After SLC meeting, MEROPS database curators were contacted and they made recommendataions. Those recs have been acted upon and reorg is finished.<br />
<br />
There still are ~200 open items. All those that are more than 6 months old have been assigned but maybe those should be reviewed to see if the priority should be changed. Also, David mentioned that many of the items are being taken care of the in large chunks with ontology changes, such as "biogenesis and organization" terms. Some are stuck because no consensus can be reached.<br />
<br />
The majority of the ontology content section will talk about future work and the links that will be made between function and process ontologies.<br />
<br />
===ACTION ITEMS===<br />
* SF items that cannot be closed due to lack of consensus should be put onto a wiki page so they can be resolved at an upcoming GOC meeting. Midori said to email the editors and they'll take care of it.<br />
<br />
==Biochemical pathway function and process links (Harold)==<br />
<br />
(get his slides)<br />
<br />
Many groups have been working on systems for links trying to see how it works since it does represent biology. Harold showed examples of cross-products using biochemical pathways, defining a start and end, selecting paths, and using common resources. Done manually, the links looked OK but labor intensive. Could it be done automatically?<br />
<br />
Problems with doing it automatically:<br />
*missing DBXREFs<br />
*too many DBXREFs<br />
*creates links in the ontology that are "corret", but not always helpful to a given question for a human - like BP "carbohydrate metabolism"is linked to all glycolysis MF annotations.<br />
<br />
Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
==Theory and examples of function and process (Jen)==<br />
(from chris' and Jen's talk)<br />
<br />
So why should we even bother?<br />
* It will improve the GO because we need to be specific<br />
* It will help fill in annotation gaps - such as a MF "kinase activity" should be made to the BP "phoshorylation" - as well as provide ways to make suggestions new annotations. <br />
* It will allow better integration of pathway databases with GO.<br />
<br />
Chris has been try to use Reactome to make mappings between function and process and has come across the following issues:<br />
* DBXREFs not necessarily equivalent<br />
* There are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
There are also gotchas from biology because there could be multiple variations for lysine biosynthesis that include mix-and-match reactions and variations of those reactions. A combinatorial explosion. <br />
<br />
The proposal to deal with this:<br />
* When functions and process are closely related, like kinase and phosphorylation, can make a "part_of" annotation.<br />
* new relationship "sometimes part_of" when automated mappings are brought in which will avoid true path violations.<br />
<br />
==Function and process link discussion==<br />
<br />
David asked if every function a "part_of" process? In theory, there should be a link between each Molecular Function term to a Biological Process term. And there was general acceptance of this theory.<br />
<br />
* peter: counter-example ?? <br />
<br />
* suzi: never really done annotations to conjuntive annotations<br />
<br />
Eurie asked if MF enzyme terms made consistently in order to best make the links easy/consistent? Amelia pointed out there is also another issue that enzyme terms are usually forward and backward but we need separate terms. Harold also pointed out that we copied from EC but this may mean that two GO terms may exist solely on the basis of cofactors. So all these may contribute to issues in creating an automated mapping.<br />
<br />
Suzi and Peter discussed that the definition of pathways between Go and Reactome are different, using apoptosis as an example. There are good examples where start and end may be different from organisms to an organism. <br />
<br />
Ingrid mentioned John Ingram is an experienced physiologist. His idea of a metabolic pathway should begin and end with a central metabolite. There are pathways that feed into a common point that can then go to a central metabolite.<br />
<br />
But All both agreed that a discussion needs to occur.<br />
<br />
<br />
* Peter: manual curation will be necessary ; also, legacy clean-up problems; may be hard to get mutually ok; For metabolites, there is more consensus than something like apoptosis. We are also going to rediscover the sensu problem. <br />
* let's explore how good can common start and ends can be created in the GO<br />
* judy: we need a process to work towards a shared start and end, but respect the dfferences; we should just get the ones where we can get the overlaps first<br />
* paul: is there a compromise argreement for the interim? saw two extremes (some has part and hash part with sublasses); external layer between function and process, start with a sampling that are more specific; <br />
* rex: when thay make changes, how do they get propagated so they don't break our system?<br />
* eurie: Annotations with links between function and process--sometimes you just don't have the evidence to make the annotation without breaking true path rules. It becomes an annotation issue when true path rules have to be considered.<br />
* Jen: That's why we are asking for sometimes_part_of<br />
* Kimberly: Would we have to use sometimes_part in all of these cases and couldn't we do better in cases where we have the information.<br />
* judy: what descisions do we need to make?<br />
<br />
===ACTION ITEMS===<br />
* Add obvious part_of links, like MF "kinase" and BP "phosphorylation"; will be rolled out after regulates is released in Feb 2009<br />
* Try mining pathways for sometimes_part_of relationships using glycolysis, nucleotide metabolism, apoptosis first<br />
* Agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* Examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
<br />
* there will be problems with slimming if they don't think about relationships<br />
* ACTION: software, release examples of relationship usage <br />
* michael: are we overloading part_of<br />
** david: yes we are, but it probably doesn't matter.<br />
<br />
Terms in MF that describe fns that regulate other fns - e.g. inhibitor activity<br />
<br />
TS regulator activity - describes fns that regulate processes<br />
<br />
Feb 2009 - regulates relationships going into the db full tilt<br />
<br />
*big impact on SLIMMING activities<br />
*simple slimming is not a good idea<br />
*will have to enforce community awareness of relationships<br />
*test case for whether inter-ontology links will break software or not<br />
*will provide backups for those not up to date with relationships<br />
<br />
<br />
- Michael - are we overloading part-of?<br />
* David: We've looked at everything in the BP that have more than one part_of parent. Gut feeling is 'yes', but practical feeling is 'it doesn't matter'. i.e. development of an anatomical structure.<br />
<br />
<br />
==Quality Control (Tanya)==<br />
(info on wiki)<br />
<br />
Regulation terms: reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing<br />
<br />
* Emily: GO tools needing to adapt with the proliferation of the ontologies, it's in the OBO edit. Also, we shouldn't endorse tools that do not appropriately slim. <br />
* Emily/Jane: We should continuously send out notices but it's the responsibility of the tool creator to take the initiative to test their tools.<br />
<br />
* continue to review chris' reports--becoming part of the process <br />
<br />
===ACTION ITEM===<br />
* send out function process email again<br />
* we now have systematic ways of determining right, not just ad hoc<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
Priority should be testing and bug fixes. This version doesn't need more features but all the new features need to be tested, tested, tested.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=<br />
<br />
<br />
<br />
<br />
==Evidence codes==<br />
Mike: ECO is a resource<br />
Mike: is ECO a responsibility of this community?<br />
Michael: We started it.<br />
Mike: If we started it, then why don't we use it<br />
Michael: kept the list short<br />
# so EV codes can be easily distinguished<br />
# reasonably easy for the annotators to use it<br />
* TAIR wanted a much richer set of EV codes. Sue and Michael did a mapping to GO evidence codes.<br />
* If annotators were faced with 1500 evidence codes it would slow down annotation and wouldn't add a whole lot to the GO.<br />
* IEAs are not ISS's<br />
* We should integrate GO evidence codes into the ECO b/c other people might use it. And that GO should use a subset/slim of ECO (i.e. the ones that we are using the ones we use now.)<br />
Pascale: Is it the case, b/c more hierarchical that we use the higher terms or to use the most granular.<br />
Judy: As far as GO is concerned, we should stay with the high level. Each mod can do more specific sub-curation. The power of the high-level EV codes is that we can bring together all these different communities.<br />
Pascale: Do we need to go as granular as we can within the EV codes that are currently used by GO?<br />
Judy: <br />
* Suzi: Like any annotations, do it to the degree of knowledge available. You might want to go to the higher term. Secondly, we might want to use an EV code slim for AmiGO.<br />
* Rex: Why would you want to do that?<br />
* Mike/Suzi: b/c it's an interface. Just for display purposes<br />
* Suzi: When we have the evidence codes in the ontology we can append an experimental method to it. <br />
* Harold: Expansion of more granular descriptions--there would be a problem of two annotations of pre and post <br />
* Eurie: In terms of setting annotaiton standards for ev codes. Would we set standards just for just the GO set or for the entire ECO set.<br />
* Mike: Annotation standards would be just for the GO evidence codes. You can use more if you want to, but you have to convert it into the standard set for the GA file.<br />
* Emily: For the reference genome group, we have decided to use IDA, IMP, IGI, IPI, IEP, and the parent EXP is for groups that are not in the ref genome group but annotate, like Reactome.<br />
* Rex: Some cases there is a lack of agreement about which evidence code to apply in a situation would allow <br />
* Kara: Is anyone against going forward to implement Chris' suggestion.<br />
* Mike: It's the next topic.<br />
* Peter: You might end up overloading the EXP term. Reactome is not protein-centric and does not annotate in a way that the literature can be parsed out later. <br />
* Rex: worried about accuracy. There is not universal agreement for which code to use for a given experiment. There is a lot of time spent debating which lower code to use and I would rather have people agree to EXP and spend more time annotating.<br />
* Suzi: People can use any ev code in the ECO if it were useful, then we could explore writing software to slim things up.<br />
===ACTION ITEMS===<br />
* create an EV code ontology tracker<br />
* people can use the ECO in its entirety but they have to map up to the GO set of EV codes.<br />
<br />
==Separating annotation method from experimental method ==<br />
* We would have a way to say that an annotation is electronic, that we can use any evidence code.<br />
* Judy: You could use anything in combination<br />
* Suzi: There is no need to change the GAF.<br />
* Kara: There's agreeing on the concept and secondly the implementation.<br />
* Judy: IEAs are inferred.<br />
* Mike: If you use InterProt to infer function is that ISS?<br />
** It also solves a lot of problems for high-throughput.<br />
* Harold: So this is mainly for HTP/<br />
NO<br />
* Mike: This is to differentiate experimental or a prediction.<br />
* Donghui<br />
* Eurie: It splits off the evidence from the experiment happening and what we put in the annotation file. Did a curator review everything or did it just appear there.<br />
** need to put in the annotation file--if we don't tag that certain experiments came from htp experiments, it becomes a circular argument from people doing RCA experiments.<br />
* Debby: The data indicates two localizations but the database didn't capture the conflict, is that the issue? Is there a marker on the paper that everything was dumped in without someone reviewing it?<br />
* Judy: That an experiment can either have high volume or low volume; doesn't like the term htp, it's not about the data but how we're treating the data.<br />
* Suzi: Problem is that we're conflating several different things into one.<br />
# what method is used?<br />
# was there human judgement involved?<br />
# you may want to know something about the volume<br />
All these together says something about the quality of the evidence. If we build it into the ontology, it allows people to fileter based on their needs.<br />
* Michael: There is a fundemental difference between htp and individual experiments on a particular protein.<br />
** What would happen to the existing annotations?<br />
*** They would become oxymoranic <br />
* Suzie: IEA, if the method was sequence similarity, it becomes automated sequence similarity. ISS and IEA have the same method and the difference is the judgement used. In the long term we should build it into the ECO.<br />
* Emily: I don't see how htp annotations that are experimental would fit under an electronic tag.<br />
* Judy: two common IEA approaches<br />
# First pass through the InterProt, based on domains<br />
# look at the structure of the gene product<br />
* Mike: the majority of the annotations would stay the way they are (the cross-product would be manual) but there would be an additional ISS electronic. <br />
* IEA and ISS electronic are synonymous<br />
* No one seems against <br />
* Not electronic/manual, but curated/uncruated<br />
* ??: How is the end user using these ev codes and annotations?<br />
* Mike: we have all sorts of users, some strip out the evidence codes. some <br />
* Debby: I don't think that all IEAs are based on sequence similarity. What about IEAs based on keywords?<br />
* Mike: Those become something else, not ISS. We throw away IEAs after 12 mos.<br />
* Michael: What happens to everything 'uncurated'? Do we throw those out as well?<br />
* Petra: Why can't we leave IEA and have a new flag? <br />
* Kara: We have all these evidence codes are describing the experiment was done, but we have IEA that describes how the annotation was done. And the proposal is to formally separate that concept out.<br />
* Emily: A nuclear fractionation is not going to be done every year. If you have a protein where there is no other method and this looks good to you, then you put them in. Talking to users, they want to know what is small scale versus what was done in a large-scale experiment.<br />
* Rex: The year limitation was for things like sequence.<br />
* Judy: Experiments are different than things that can be recomputed. We do have methods that look at hundreds of thousands of points that have restrictions on how they were done and we need a way to handle that differently than sequence sets that we were discarding. <br />
* Mike Tyers: It really comes down to a matter of confidence. Is it possible to put a confidence score?<br />
* Michael: if there were a question, than hopefully the curator would not annotate.<br />
* Suzi: The current proposal is extensible. It allows you to ask what are the attributes of the evidence? It gives you flexibility by separating from the attribute from the method.<br />
* Rex: Worried about the amount of time we spend? Practicality of how much time the curator spends be considered.<br />
* Pascale: We should assay the community to see if this would be useful.<br />
* Judy: We spend an inordinate amount of time dealing with IEA and ISS . The crucial work is the high level experimental data.<br />
<br />
===ACTION ITEM=== <br />
* Example cases of annotations and implementation into the ECO.<br />
** Suzi, Michelle, Judy, Pascale, Emily, Eurie<br />
<br />
<br />
After coffee<br />
<br />
==PAMGO (Michelle/Candace)==<br />
* Judy: with the metabalome projects, is there anything that the GO community can do or are you just going to use the GO?<br />
* Michelle: the latter<br />
* Jane: using the triggers to find places in the ontology that have issues?<br />
<br />
* dual taxon IDs<br />
** still not displayed in AmiGO<br />
<br />
===ACTION ITEM===<br />
* Check your annotations to terms under the 'symbiosis' and 'response to host' terms to make sure that there aren't any problems.<br />
<br />
==Cross products: Column 16 (Tanya)==<br />
* Proposed solutions<br />
** simple solution<br />
** expressive solution<br />
* There are examples of both in the wiki and it hasn't been decided which to use<br />
* No one had concerns about adding this column<br />
* A few people spoke up in favor of the expressive because it would allow for more information and no need to retrofit.<br />
* not restricted to one ontology in column 16<br />
* column can also be used to identify a target i.e. regulation of transcription<br />
<br />
===ACTION ITEM===<br />
* go ahead with the implementation of the expressive model in column 16<br />
** get more examples <br />
** get the documentation together<br />
<br />
==Relationships in GO==<br />
<br />
<br />
<br />
<br />
==Documentation==</div>Juliephttps://wiki.geneontology.org/index.php?title=20th_GO_Consortium_Meeting_Minutes&diff=1622120th GO Consortium Meeting Minutes2008-10-21T19:04:39Z<p>Juliep: </p>
<hr />
<div>=Ontology content development=<br />
==Overview (Midori)==<br />
<br />
Mostly on wiki.<br />
ontology development<br />
<br />
* closed more SF items them opened since last meeting (~200)<br />
** done over time? (judy)<br />
** we should look at priorities<br />
** we may be able to take care of the in large chunks with ontology changes (david)<br />
<br />
* actually a lot accomplished<br />
** will make links between function and process ontologies<br />
<br />
* place on wiki for requests that have gotten wedged? (suzi)<br />
** Email us and we'll find a place for it. (Midori)<br />
<br />
==Function and process links (Harold)==<br />
<br />
(get his slides)<br />
<br />
* many groups have been working on systems for links trying to see how it works<br />
<br />
* life depends on cross-products<br />
<br />
* biochemical pathways<br />
** selected paths and used common resources<br />
** manually linked a set using GO<br />
*** looked OK<br />
** could this be done automatically?<br />
*** maybe, but problems...<br />
**** missing dbxrefs<br />
**** too many dbxrefs<br />
**** things in the ont that are "corrent", but not always helpful to a given question for a human<br />
*** Moving forward, using the dbxrefs seems to be the way to go but we will have to go in manually to make them more complete.<br />
<br />
==Theory and examples of function and process (Jen)==<br />
(get her slides)<br />
<br />
(from chris' talk)<br />
* chris has been try to use reactome to make mappings between function and process <br />
** xrefs not necessarily equivalent<br />
** there are some reactions that always occur in a given process for a particular species and others that do not and this is more difficult to mine from reactome.<br />
<br />
(get her slides)<br />
* manual cross-products (lysine biosynthesis example)<br />
** maybe 7, maybe even more...<br />
*** combinatorial explosion<br />
** where do they start and end?<br />
<br />
* if there were two isoforms...<br />
* let's continue...<br />
<br />
==Discussion==<br />
<br />
* sometimes_part_of if we bring in automatic<br />
<br />
* david: is every function a "part_of" process?<br />
** no complaints...<br />
*** peter: counter-example <br />
*** suzi: sounds like a lot of clean-up<br />
** david: we can just try a little and see<br />
<br />
* suzi: never really done annotations to conjuntive annotations<br />
* eurie: cofactors...<br />
* amelia: enzyme terms usually represent forward and backward, thus we need them as separate terms<br />
* harold: in general we try to use EC--sometimes opposite or different from what is expected<br />
** general agreement<br />
* suzi: reactome and GO beginning and end of apoptosis are very different<br />
* peter: what do we mean by pathway? need to be very specific; may be different in different organisms; <br />
* suzi: proposal: let's get argreement on what beginnings and are, even if they are arbitrary. <br />
* Ingrid: John Ingram is an experienced physiologist. His idea of a metabolic pathway should begin and end with a central metabolite. There are pathways that feed into a common point that can then go to a central metabolite.<br />
* Peter: manual curation will be necessary ; also, legacy clean-up problems; may be hard to get mutually ok; For metabolites, there is more consensus than something like apoptosis. We are also going to rediscover the sensu problem. <br />
* let's explore how good can common start and ends can be created in the GO<br />
* judy: we need a process to work towards a shared start and end, but respect the dfferences; we should just get the ones where we can get the overlaps first<br />
* paul: is there a compromise argreement for the interim? saw two extremes (some has part and hash part with sublasses); external layer between function and process, start with a sampling that are more specific; <br />
* rex: when thay make changes, how do they get propagated so they don't break our system?<br />
* eurie: Annotations with links between function and process--sometimes you just don't have the evidence to make the annotation without breaking true path rules. It becomes an annotation issue when true path rules have to be considered.<br />
* Jen: That's why we are asking for sometimes_part_of<br />
* Kimberly: Would we have to use sometimes_part in all of these cases and couldn't we do better in cases where we have the information.<br />
* judy: what descisions do we need to make?<br />
<br />
===ACTION ITEMS===<br />
* add obvious part_of links; roll out regulates (feb)<br />
* try mining pathways for sometimes_part_of relationships<br />
* do glycolysis, nucleotide metabolism, apoptosis first<br />
* agree on beginnings, middles, and ends of pathways/processes between Reactome and GO<br />
* examine impact on annotation priorities and implememntations<br />
* Can we source our relationships as well as our term definitions.<br />
** (david: this is about pushing the work onto the ontology developers and not the annotators)<br />
* assign process to every molecular function.<br />
* deferred: co-annotation 'has function as part of this process'<br />
<br />
==New relationship type (David)==<br />
<br />
* there will be problems with slimming if they don't think about relationships<br />
* ACTION: software, release examples of relationship usage <br />
* michael: are we overloading part_of<br />
** david: yes we are, but it probably doesn't matter.<br />
<br />
Terms in MF that describe fns that regulate other fns - e.g. inhibitor activity<br />
<br />
TS regulator activity - describes fns that regulate processes<br />
<br />
Feb 2009 - regulates relationships going into the db full tilt<br />
<br />
*big impact on SLIMMING activities<br />
*simple slimming is not a good idea<br />
*will have to enforce community awareness of relationships<br />
*test case for whether inter-ontology links will break software or not<br />
*will provide backups for those not up to date with relationships<br />
<br />
<br />
- Michael - are we overloading part-of?<br />
* David: We've looked at everything in the BP that have more than one part_of parent. Gut feeling is 'yes', but practical feeling is 'it doesn't matter'. i.e. development of an anatomical structure.<br />
<br />
<br />
==Quality Control (Tanya)==<br />
(info on wiki)<br />
<br />
Regulation terms: reasoner looks at regulation terms and then at corresponding process terms, checks if the structures match or if relationships missing<br />
<br />
* Emily: GO tools needing to adapt with the proliferation of the ontologies, it's in the OBO edit. Also, we shouldn't endorse tools that do not appropriately slim. <br />
* Emily/Jane: We should continuously send out notices but it's the responsibility of the tool creator to take the initiative to test their tools.<br />
<br />
* continue to review chris' reports--becoming part of the process <br />
<br />
===ACTION ITEM===<br />
* send out function process email again<br />
* we now have systematic ways of determining right, not just ad hoc<br />
<br />
==OBO-Edit (Amina)==<br />
(has slides)<br />
<br />
* midori:<br />
* judy: test test test--2.0 means great. Need a detailed testing protocol.<br />
<br />
==Reports (Jane)==<br />
(has slides)<br />
<br />
===PAMGO===<br />
<br />
* This is an ongoing process.<br />
<br />
===Organization and biogenesis of cellular components===<br />
(has slides)<br />
<br />
ACTION: continue work on org and bio terms <br />
<br />
==Signaling (Jen)==<br />
(has slides)<br />
<br />
===Future content meeting discussion===<br />
* brenley: volunteer for virus terms<br />
* judy: maybe infetctious diease group?<br />
* midori: touches on every species<br />
* david: there should be specific venues; some of these are huges issues;<br />
** focus: g-protein coupled receptors, calcium signaling, tyrosine kinase singaling, MAP kinase cascade<br />
<br />
===ACTION ITEMS=== <br />
* pursue an ontology development meeting one or two<br />
** viral processes (Brenley, Kimberley, Candice, Michelle, Jane)<br />
** GPCR (Pascale, David, ??)<br />
* Go to meetings on these topics and ask for experts to join meeting<br />
* Investigate funding sources<br />
<br />
==Annotation checking by trigger file (Jen)==<br />
(has slides)<br />
<br />
* problem IEAs<br />
** viral/bact ones should probably to be to host instead<br />
<br />
* Suzie: do we want all the groups submitting annotations run the triggers?<br />
* Judy: we can do a monthly run with the trigger file<br />
* Peter: Once it has run a few times, we can check for global issues from GA files.<br />
* Michael A: What will you do about the GOA annotations where there is a confilct<br />
* Emily: Can use to feed back to InterProt (for the InterProt to GO mappings) to update mappings because old mappings are causing problems.<br />
<br />
===ACTION ITEMS===<br />
* remove sensu synonyms<br />
* Make GOA quickgo checking available to the public<br />
* write up for near future news letter<br />
<br />
=General Annotation Issues=</div>Juliephttps://wiki.geneontology.org/index.php?title=October_2008_Meeting_Logistics&diff=15095October 2008 Meeting Logistics2008-08-27T17:14:32Z<p>Juliep: /* Attendees */</p>
<hr />
<div>===Dates===<br />
* GO consortium meeting will be held on October 21-22, 2008 (Tues-Wed)<br />
* SAB meeting will be held on October 23, 2008 (Thurs)<br />
<br />
===Venue===<br />
[http://www.montgabriel.com/en_home.php Mont Gabriel], 45 miles north of Montreal. <br />
<br />
===Registration===<br />
<br />
* '''Reserve your room by calling the hotel at 1-800-668-5253; ask for "reservations" and identify yourself as part of the Northwestern University group.''' <br><br />
Sorry, no online registration. <br />
* If you participate in both the GO meeting and the SAB, you should check in on the 20th (Monday) and leave on the 24th, as we are planning full days meetings. <br />
* You will need to pay a 50$ deposit by credit card at the time of reservation. <br />
* PLEASE REGISTER BEFORE SEPTEMBER 12, 2008<br />
<br />
====Room====<br />
* There is a choice between three kinds of rooms (depending on availability) [http://www.montgabriel.com/en_accommodations_tyrol.php Tyrol] ("Superior" room with balcony), [http://www.montgabriel.com/en_accommodations_rustique.php Rustique] (log cabin-style) (there are only about 8 rooms available of this type), and [http://www.montgabriel.com/en_accommodations_marquise.php Marquise] (smaller rooms). '''All rooms are the same price.'''<br />
<br />
===Cost===<br />
* The cost per day is CAN $208.00 (~208$ USD), including dinner, accommodation, breakfast and lunch (which includes taxes and service). If you plan to miss a meal, the price will be adjusted accordingly ($17 for breakfast, $22 for lunch, $43 dinner). <br />
* If you want to share a room (two double or queen beds); in that case the price for the room is the same, $126, so that's $63 per person. <br />
* We will need to charge a small fee (10-15$ per day) for coffee breaks but this needs to be done separately.<br />
<br />
===Internet===<br />
Wireless internet will be available in the conference room and in the rooms. <br />
<br />
===Food===<br />
* Bien sur, the menu is French-inspired, which means quite a bit of meat. However, there will always be fish and vegetarian options. Fill in the table below or contact me if you have special requirements.<br />
<br />
===Transportation===<br />
* Fly to Montreal-Trudeau Airport (YUL). This airport used to be called Dorval, you may still see that sometimes (for example, on Google maps...). <br />
* The hotel offers a shuttle from the Montreal Trudeau Airport for up to 6 people for a flat rate of $140. <br />
* A taxi would be about 100$ (Taxis des Pays-d'en-Haut, 450-227-3000; I suggest you call in advance). <br />
* You can also rent a car from the airport. [[YUL-Gabriel Driving instructions]].<br />
<br />
===To do===<br />
<br />
====On site====<br />
<br />
* http://www.montgabriel.com/en_activities.php<br />
Tennis and golf should be open; I am not sure about the pool. It's possible to go jogging on the golf course just outside the hotel.<br />
<br />
====If you want to explore Montreal====<br />
<br />
* Montreal links : http://www.montreal.com/tourism/general.html, http://www.discovermontreal.ca/, http://www.go-montreal.com/<br />
* Cycling in and around the city: http://english.montrealplus.ca/feature/crazy_for_cycling/8536/trails.jsp <br />
** I quite enjoy this one: http://english.montrealplus.ca/feature/crazy_for_cycling/8536/trails_lachine_canal.jsp<br />
* In October the Montreal Botanical Garden will have their annual 'THE MAGIC OF LANTERNS' event at Chinese gardens http://www2.ville.montreal.qc.ca/jardin/en/chine/programme.htm<br />
* You can combine the visit to the Botanical Garden with the Biodome [http://www2.ville.montreal.qc.ca/biodome/site/gabarit.php?dossier=visite&page=musee&menu=musee] and the Insectarium [http://www2.ville.montreal.qc.ca/insectarium/en/index.php]. The three museums part of the same complex and you can get combined tickets [http://www2.ville.montreal.qc.ca/biodome/site/gabarit.php?dossier=info&page=tarif&menu=tarif]<br />
* On a warm evening the Old Port [http://www.vieux.montreal.qc.ca/] [http://www.go-montreal.com/areas_oldmontreal.htm] is really nice.<br />
<br />
====In the Laurentians====<br />
<br />
* The Laurentians: http://www.laurentians.com/<br />
<br />
* Cycling/walking Le P'tit Train du Nord: http://www.out-there.com/pt-train.htm or http://www.laurentians.com/parclineaire/<br />
<br />
* Golfing http://www.teeingitup.com/canada/laurentians.htm<br />
<br />
* Yoga (they have camps - $80/day- or you can take a ~1.5 h lesson for $10) http://sivananda.hdthost.com/website/Main.aspx?lang=en-CA<br />
<br />
===Contact===<br />
'''Please contact Pascale Gaudet if you have any questions: pgaudet -at- northwestern.edu'''<br />
<br />
<br />
<br />
<br />
===Attendees===<br />
(please use the Arrival and Departure info columns if you would like to try a carpool to/from the airport)<br />
{|border="1" cell spacing="0" cellpadding="4" align="center"<br />
|-<br />
! Name<br />
! Attending GOC (Oct 21-22, 2008)<br />
! Attending SAB (Oct 23, 2008)<br />
! Food requirement (None, Veggie, Vegan)<br />
! Arrival Date/Time to Airport (YUL) <br />
! Departure Date/Time from Airport (YUL)<br />
|-<br />
| Pascale Gaudet<br />
| yes<br />
| yes<br />
| none<br />
|<br />
|<br />
|-<br />
| Amelia Ireland<br />
| yes<br />
|<br />
|<br />
| 20 Oct 18:00<br />
| 26 Oct 08:25<br />
|-<br />
| Chris Mungall<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Michael Ashburner<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Suzanna Lewis<br />
| yes<br />
| yes<br />
| yummy<br />
| Oct 20, 5:09PM, UA8185, LGA-Montreal<br />
| Oct 23, 7:55PM, UA8400, Montreal-LGA<br />
|-<br />
| Jennifer Deegan<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Midori Harris<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Jane Lomax<br />
| yes<br />
| yes (am only)<br />
| none<br />
|Oct 20, 425PM, NW8671, Montreal<br />
|Oct 23, 625PM, NW8672, Montreal<br />
|-<br />
| Harold Drabkin<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Rex Chisholm<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Kimberly Van Auken<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Alexander Diehl<br />
| yes<br />
| yes<br />
| none<br />
|<br />
|<br />
|-<br />
| Mike Cherry<br />
| yes<br />
| yes<br />
|<br />
|<br />
|<br />
|-<br />
| Judy Blake<br />
| yes<br />
| yes<br />
| none<br />
|<br />
|<br />
|-<br />
| Doug Howe<br />
| yes<br />
| no<br />
| none<br />
|Oct 20, 440PM United, Montreal<br />
|Oct 23, 240PM United, Montreal<br />
|-<br />
| Mary Dolan<br />
| yes<br />
| yes<br />
| none<br />
|<br />
|<br />
|-<br />
| David Hill<br />
| yes<br />
| yes<br />
| none<br />
|<br />
|<br />
|-<br />
| Victoria Petri<br />
| yes<br />
|<br />
| none<br />
|<br />
|<br />
|-<br />
| Eurie Hong<br />
| yes<br />
| yes<br />
| none<br />
| Oct 20, 8:10pm United<br />
| Oct 24, 8:40am United<br />
|-<br />
| Julie Park<br />
| yes<br />
| yes<br />
| none<br />
| Oct 20, 8:10pm United<br />
| Oct 24, 8:40am United<br />
|-<br />
| Debby Siegele<br />
| yes<br />
| <br />
| none<br />
|<br />
|<br />
|-<br />
| Brenley McIntosh<br />
| yes<br />
| <br />
| none<br />
|<br />
|<br />
|-<br />
| Tanya Berardini<br />
| yes<br />
| <br />
| none<br />
|<br />
|<br />
|-<br />
| Kara Dolinski<br />
| yes<br />
| no<br />
| none<br />
|<br />
|<br />
|-<br />
| Donghui Li<br />
| yes<br />
| <br />
| none<br />
|Oct 20, 8:10pm United<br />
|Oct 25, 8:40am, leaving from Montreal<br />
|-<br />
| Stan Laulederkind<br />
| yes<br />
| no<br />
| none<br />
|<br />
|<br />
|-<br />
| Edith Wong<br />
| yes<br />
| yes<br />
| none<br />
|<br />
|<br />
|-<br />
| Amina Abdulla<br />
| yes<br />
| no<br />
| none<br />
|<br />
|<br />
|-<br />
| Seth Carbon<br />
| yes<br />
| no<br />
| none<br />
|<br />
|<br />
|-<br />
| Candace Collmer<br />
| yes<br />
| no<br />
| none<br />
|20 Oct 17:15 US Airways<br />
|23 Oct 13:30 US Airways<br />
|<br />
|<br />
|}<br />
<br />
<br />
[[Consortium_Meetings|Consortium meetings main page]]<br />
<br />
[[Category:Meetings]]</div>Juliep