GO Internal

Pascale:

=TO BE FORMATTED=


See [[Ontology_Editors_Daily_Workflow]] for creating branches and basic Protégé instructions.

To create a new term, the ‘Asserted view’ must be active (not the ‘Inferred view’).

In the Class hierarchy window, click on the ‘Add subclass’ button at the upper left of the window.

A pop-up window will appear asking you to enter the Name of the new term. When you enter the term name, you will see your ID automatically populate the IRI box. Once you have entered the term, click ‘OK’ to save the new term. You will see it appear in the class hierarchy.

Navigate to the OBO annotation window.

In the OBO annotation window add:
Namespace
Begin typing one of the three branches (autocomplete will guide you to the correct term): - biological_process - cellular _component - molecular_function
For Type, select: xsd:string
Definition
Click on the + next to the Definition box
Add the textual definition in the pop-up box.
For Type, select: Xsd:string
Click OK.
Add Definition References
Click on the circle with the ‘Ref’ in it next to add Definition References and in the resulting pop-up click on the + to add a new ref, making sure they are properly formatted with a database abbreviation followed by a colon, followed by the text string or ID. Examples: GOC:bhm, PMID:27450630.
Select Type: xsd:string
Click OK.
Add each definition reference separately by clicking on the + sign.
Add synonyms and dbxrefs following the same procedure if they are required for the term.

If you have created a logical definition for your term, you can delete the asserted is_a parent in the ‘subclass of’ section. Once you synchronize the reasoner, you will see the automated classification of your new term. If the inferred classification doesn’t make sense, then you will need to modify the logical definition.

Protege tip: If you need to create a logical definition using a GO term name that does not begin
with an alphabetic character, e.g. GO:0004534 (5'-3' exoribonuclease activity), navigate to the
View menu in Protege and select 'Render by entity IRI short name (Id). This will allow you to
enter a logical definition by entering the relations and term as IDs, e.g. RO_0002215 some GO_0004534.
Note the use of the underscore instead of the colon in the ID. You can then return to the View
menu to switch back to Render by label (rdfs:label) to see the term names.

In some cases such as part_of relations based on external partonomies, it might be necessary to assert the part_of relationships. For example: ‘heart valve development’ part_of some ‘heart development’. In those cases, it is important to browse the external ontologies to be sure that nothing is missing.

When you have finished adding the term, you can hover over it in the class window to reveal its GO_id.

Save the file and return to your terminal window. Then, type: git status. This will confirm which file has been modified.

To see how the branch was modified, type: git diff. In this case, go-edit.obo was modified. The text below is not the entire diff for this edit, but is an example. If the diff is very large, you will need to hit a space to continue to see it and then hit ‘q’ to get back to the prompt at the end of the diff file.

~/repos/go-ontology/src/ontology(issue-13390) $ git diff
diff --git a/src/ontology/go-edit.obo b/src/ontology/go-edit.obo
index 72ae7e9..8d47fa1 100644
--- a/src/ontology/go-edit.obo
+++ b/src/ontology/go-edit.obo
@@ -400751,6 +400751,85 @@ created_by: dph
creation_date: 2017-04-28T12:39:13Z

[Term]
+id: GO:0061868
+name: hepatic stellate cell migration
+namespace: biological_process
+def: "The orderly movement of a hepatic stellate cell from one site to another." [PMID:24204762]
+intersection_of: GO:0016477 ! cell migration
+intersection_of: results_in_movement_of CL:0000632 ! hepatic stellate cell
+created_by: dph
+creation_date: 2017-05-01T13:01:40Z
+
+[Term]
id: GO:0065001
name: specification of axis polarity
namespace: biological_process
~/repos/go-ontology/src/ontology(issue-13390) $

See [[Ontology_Editors_Daily_Workflow Daily Workflow]] for commit, push and merge instructions.


[[Category:GO Editors]][[Category:Ontology]][[Category:Editor_Guide_2018]] Pascale

Pascale:

=TO BE FORMATTED=

Updating the local copy of the ontology with ‘git pull’

Navigate to the ontology directory of go-ontology: cd repos/go-ontology/src/ontology.

If the terminal window is not configured to display the branch name, type: git status. You will see:

On branch [master] [or the name of the branch you are on]
Your branch is up-to-date with 'origin/master'.

If you’re not in the master branch, type: git checkout master.

From the master branch, type: git pull. This will update your master branch, and all working branches, with the files that are most current on GitHub, bringing in and merging any changes that were made since you last pulled the repository using the command git pull. You will see something like this:

~/repos/go-ontology(master) $ git pull
remote: Counting objects: 26, done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 26 (delta 12), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (26/26), done.
From https://github.com/geneontology/go-ontology
580c01d..7225e89 master -> origin/master
* [new branch] issue#13029 -> origin/issue#13029
Updating 580c01d..7225e89
Fast-forward
src/ontology/go-edit.obo | 39 ++++++++++++++++++++++++---------------
1 file changed, 24 insertions(+), 15 deletions(-)
~/repos/go-ontology(master) $

Creating a New Working Branch with ‘git checkout’

When starting to work on a ticket, you should create a new branch of the repository to edit the ontology file.

Make sure you are on the master branch before creating a new branch. If the terminal window is not configured to display the branch name, type: git status to check which is the active branch. If necessary, go to master by typing git checkout master.

To create a new branch, type: git checkout -b issue-NNNNN in the terminal window. For naming branches, we recommend using the string ‘issue-‘ followed by the issue number. For instance, for this issue in the tracker: https://github.com/geneontology/go-ontology/issues/13390, you would create this branch: git checkout -b issue-13390. Typing this command will automatically put you in the new branch. You will see this message in your terminal window:

~/repos/go-ontology/src/ontology(master) $ git checkout -b issue-13390
Switched to a new branch 'issue-13390'
~/repos/go-ontology/src/ontology(issue-13390) $

Continuing work on an existing Working Branch

If you are continuing to do work on an existing branch, in addition to updating master, go to your branch by typing git checkout [branch name]. Note that you can view the existing local branches by typing git branch -l.
OPTIONAL: To update the working branch with respect to the current version of the ontology, type git pull origin master. This step is optional because it is not necessary to work on the current version of the ontology; all changes will be synchronized when git merge is performed.

Loading, navigating and saving the Ontology in Protégé

Before launching Protégé, make sure you are in the correct branch. To check the active branch, type git status.
Click on the ‘File’ pulldown. Open the file: go-edit.obo. The first time, you will have to navigate to repos/go-ontology/src/ontology. Once you have worked on the file, it will show up in the menu under ‘Open’/’Recent’.
Click on the ‘Classes’ tab.
Searching: Use the search box on the upper right to search for a term in the ontology. Wait for autocomplete to work in the pop-up window.
Viewing a term: Double-click on the term. This will reveal the term in the ‘Class hierarchy’ window after a few seconds.
Launching the reasoner: To see the term in the ‘Class hierarchy’ (inferred) window, you will need to run the ‘ELK reasoner’. ‘Reasoner’ > select ELK 0.4.3, then click ‘Start reasoner’. Close the various pop-up warnings about the ELK reasoner. You will now see the terms in the inferred hierarchy.
After modification of the ontology, synchronize the reasoner. Go to menu: ‘Reasoner’ > ‘ Synchronize reasoner’.
NOTE: The only changes that the reasoner will detect are those impacting the ontology structure: changes in equivalence axioms, subclasses, merges, obsoletions, new terms.
TIP: When adding new relations/axioms, ‘Synchronize’ the reasoner. When deleting relations/axioms, it is more reliable to ‘Stop’ and ‘Start’ the reasoner again.
Use File > Save to save your changes.

Committing, pushing and merging your changes to the repository

Review: Changes made to the ontology can be viewed by typing git diff in the terminal window. If there are changes that have already been committed, the changes in the active branch relative to master can be viewed by typing git diff master.

Commit: Changes can be committed by typing: git commit -m ‘Meaningful message Fixes #ticketnumber’ go-edit.obo.

For example:

git commit -m ‘hepatic stellate cell migration and contraction and regulation terms. Fixes #13390’ go-edit.obo

This will save the changes to the go-edit.obo file. The terminal window will show something like:

~/repos/go-ontology/src/ontology(issue-13390) $ git commit -m 'Added hepatic stellate cell migration and contraction and regulation terms. Fixes #13390' go-edit.obo
[issue-13390 dec9df0] Added hepatic stellate cell migration and contraction and regulation terms. Fixes #13390
1 file changed, 79 insertions(+)
~/repos/go-ontology/src/ontology(issue-13390) $

NOTE: The word ‘fixes’ is a magic word in GitHub; when used in combination with the ticket number, it will automatically close the ticket. In the above example, when the file is merged in GitHub, it will close issue number 13390. Learn more on this GitHub Help Documentation page about ‘Closing issues via commit messages’.

‘Fixes’ is case-insensitive.

If you don’t want to close the ticket, just refer to the ticket # without the word ‘Fixes’. The commit will be associated with the correct ticket but the ticket will remain open.

NOTE: It is also possible to type a longer message than allowed when using the ‘-m’ argument; to do this, skip the -m, and a vi window (on mac) will open in which an unlimited description may be typed.

TIP: Git needs to know who is committing changes to the repository, so the first time you commit, you may see the following message:

Committer: Kimberly Van Auken <vanauken@kimberlukensmbp.dhcp.lbnl.us>
Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate.

See Configuration instructions to specify your name and email address.

Push: To incorporate the changes into the remote repository, type: git push origin mynewbranch.

Example:

git push origin issue-13390

TIP: Once you have pushed your changes to the repository, they are available for everyone to see, so at this stage you can ask for feedback.

Pull
In your browser, return to the GO Ontology repository on GitHub.
Navigate to the tab labeled as ‘Code’ geneontology/go-ontology/code. You will see your commit listed at the top of the page in a light yellow box. If you don’t see it, click on the ‘Branches’ link to reveal it in the list, and click on it.
Click the green button ‘Compare & pull request’ on the right.
You may now add comments and ask a colleague to review your pull request. If you want to have the ticket reviewed before closing it, you can select a reviewer for the ticket before you make the pull request by clicking on the ‘Reviewers’ list and entering a GitHub identifier (e.g. @superuser1). The reviewer will be notified when the pull request is submitted. Since the Pull Request is also a GitHub issue, the reviewer’s comments will show up in the dialog tab of the pull request, similarly to any other issue filed on the tracker.
The diff for your file is at the bottom of the page. Examine it as a sanity check.
Click on the green box ‘Pull request’ to generate a pull request.
Wait for the Travis checks to complete (this can take a few minutes). If the Travis checks failed, go back to your working copy and correct the reported errrors.

Merge If the Travis checks are succesful and if you are done working on that branch, merge the pull request. Confirming the merge will close the ticket if you have used the word ‘fixes’ in your commit comment. NOTE: Merge the branches only when the work is completed. If there is related work to be done as a follow up to the original request, create a new GitHub ticket and start the process from the beginning.

Delete your branch on the repository using the button on the right of the successful merge message.

You may also delete the working branch on your local copy. Note that this step is optional. However, if you wish to delete branches on your local machine, in your terminal window:
Go back to the master branch by typing git checkout master.
Update your local copy of the repository by typing git pull origin master
Delete the branch by typing git branch -d workingbranchname. Example: git branch -d issue-13390




[[Category:GO Editors]][[Category:Ontology]][[Category:Editor_Guide_2018]] Pascale

Pascale: /* Cloning the go-ontology repository from GitHub */

==Installing git==

# In order to locally edit the ontology and push changes back to the GitHub repository, you will need to have git installed on your machine.
# To check if you already have git installed, or to see what version of git you have, type either of these commands in your terminal: which git or git --version.
# To install git, follow instructions here: https://git-scm.com/

'''Note for MacOSX users:''' it is advised to install Xcode tools.

==Cloning the go-ontology repository from GitHub==

# Create a directory called repos on your local machine using this command: mkdir repos.
# Then paste this command into your terminal: git clone https://github.com/geneontology/go-ontology.git.
#* Example result:
Cloning into 'go-ontology'...
remote: Counting objects: 2541, done.
remote: Compressing objects: 100% (100/100), done.
remote: Total 2541 (delta 52), reused 0 (delta 0), pack-reused 2440
Receiving objects: 100% (2541/2541), 21.19 MiB | 5.22 MiB/s, done.
Resolving deltas: 100% (1532/1532), done.

==Editing the .profile (or .bashrc) file to indicate the branch you are working on==

It can be very helpful to know what branch you are working in on your terminal window. You can set this up to display by adding the following information to your .profile file (found by typing ls -a):

export GO_REPO=~/repos/go-ontology
. $GO_REPO/src/util/git-completion.bash
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
PS1="\w\$(parse_git_branch) $ "
export PATH=$PATH:$HOME/bin/

Note the last line is not relevant to git, but we do this now for later on when we want to run tools like robot.


[[Category:GO Editors]][[Category:Ontology]][[Category:Editor_Guide_2018]] Pascale

Pascale: /* Configuring New Entities Metadata */

==Configuring New Entities Metadata==

# In the Protege menu, select Preferences.
# Click on: Annotate new entities with creator (user)
# Creator property: Add http://www.geneontology.org/formats/oboInOwl#created_by
# Creator value: Use username
# Check: Annotate new entities with creation date and time.
# Date property: Add http://www.geneontology.org/formats/oboInOwl#creation_date
# Check: ISO-8601

==Configuring User details==

Select 'User name', and use the supplied user name; that is, your GOC identity.

===Identifying the user for commits===

Git needs to know who is committing changes to the repository, so the first time you commit, you may see the following message:

Committer: Kimberly Van Auken <vanauken@kimberlukensmbp.dhcp.lbnl.us>
Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate.

You can suppress this message by setting your name and email explicitly:

# Type git config --global user.name "Your Name"
# Type git config --global user.email you@example.com.
# You can then fix the identity used for this commit by typing: git commit --amend --reset-author.




[[Category:GO Editors]][[Category:Ontology]][[Category:Editor_Guide_2018]] Pascale

Pascale:

==Installing Protege==

# Follow the instructions on the GO wiki page: [http://wiki.geneontology.org/index.php Protege_setup_for_GO_Eds] '''CHECK THAT INFORMATION IS NOT REDUNDANT WITH INFORMATION HERE'''
# ''Need to add more here about the different Views and Tabs needed for working.''

==ID Ranges==

# Curators and projects are assigned specific GO term ID ranges.
# These ID ranges are stored in the file: [https://github.com/geneontology/go-ontology/blob/master/src/ontology/go-idranges.owl go-idranges.owl]
# '''NOTE:''' You should only use IDs within your range.
# If you have only just set up this repository, modify the idranges file and add yourself or other editors.

==Setting ID ranges in Protege==
# Once you have your assigned ID range, you need to configure Protege so that your ID range is recorded in the Preferences menu. Protege does not read the go-idranges.owl file.
# In the Protege menu, select Preferences.
# In the resulting pop-up window, click on the New Entities tab and set the values as follows.
# In the Entity IRI box: #* '''Start with:''' Specified IRI: [http://purl.obolibrary.org/obo http://purl.obolibrary.org/obo]
#* '''Followed by:''' /
#* '''End with:''' Auto-generated ID
# In the Entity Label section:
#* '''Same as label renderer:'''IRI: [http://www.w3.org/2000/01/rdf-schema#label http://www.w3.org/2000/01/rdf-schema#label]
# In the Auto-generated ID section:
#* Numeric
#* Prefix: "GO"
#* Suffix: ''leave this blank''
#* Digit Count "7"
#* '''Start:''' see [go-idranges.owl](https://github.com/geneontology/go-ontology/blob/master/src/ontology/go-idranges.owl). Only paste the number after the '''GO:''' prefix. Also, note that when you paste in your GO ID range, the number will automatically be converted to a standard number, e.g. pasting 0110001 will be converted to 110,001.)
#* '''End:''' see [go-idranges.owl](https://github.com/geneontology/go-ontology/blob/master/src/ontology/go-idranges.owl)
#* Remember last ID between Protege sessions: ALWAYS CHECK THIS
#* ('''Note:''' You want the ID to be remembered to prevent clashes when working in parallel on branches.)


[[Category:GO Editors]][[Category:Ontology]][[Category:Editor_Guide_2018]] Pascale

Pascale: /* This guide was developed following the Protégé meeting in November 2017. Last updated: June 2018 */

=This guide was developed following the Protégé meeting in November 2017. Last updated: June 2018=


[[Initial Setup]]

Configuration

Installing and Using git

Daily Workflow

Creating a New Ontology Term
Creating Regulation Terms
Deleting Asserted Subclasses
Obsoleting an Existing Ontology Term
Merging Ontology Terms
Term Comments

Adding a term to a GO Subset (Slim)
Adding a new GO Subset (Slim)
Adding taxon restrictions
Adding Terms to the Import Files




[[Category:GO Editors]][[Category:Ontology]] Pascale

Vanaukenk: /* GO Annotation Meetings */

= Meeting URL =
*https://stanford.zoom.us/j/976175422

= Agenda =
== Annotation File Pipeline ==
*Presentation on the new annotation file production pipeline
**How to submit annotation files
**Where to retrieve annotation files
**Annotation file reports

== GO Annotation Meetings ==
*Still will be Tuesdays at 8am PDT
*Proposed meeting schedule:
**1st Tuesday: Alliance Gene Function
**2nd Tuesday: GO Consortium
**3rd Tuesday: Alliance Gene Function/GO-CAM Working Group
**4th Tuesday: GO-CAM Working Group
**5th Tuesday: ad hoc, as needed

= Minutes =



[[Category:Annotation Working Group]] Vanaukenk

Pascale: /* PAINT GAF export */

[[Category:Reference Genome]]

=PAINT GAF Format=
By Huaiyu Mi

This document is to define the data used in each column of the PAINT GAF file. The file follows the GO Annotation File (GAF) format 2.1. See http://geneontology.org/page/go-annotation-file-gaf-format-21 for more details.

==Some history==

The legacy PAINT GAF files were created and stored on SVN at:
http://viewvc.geneontology.org/viewvc/GO-SVN/trunk/gene-associations/submission/paint/pre-submission/?sortby=date

In March 2017, a modified PAINT tool was released to retrieve and store all PAINT data through a database. A new process was created to generate PAINT GAF from the database The format of these GAF files were strictly based on the legacy PAINT GAFs. In Feb. 2018, during the transition of GO data release, a number of issues were raised with regard to the data in the GAF files, especially what type of data that should be captured in each column.

This document will serve as a guideline to create and use the PAINT GAF.


==PAINT GAF export==
* Monthly release (not yet implemented; currently ad hoc)
* Load current GO file (date of the GO.obo download got in the GAF file header)(not yet implemented?)
* Run touchup: (?)
* Remove annotations to obsolete terms: If there is a replaced_by tag, annotation is updated; otherwise it is just removed (?)
* Remove annotations for which experimental evidence is no longer available (?)
* During the annual Panther release: all the PTNs, all IBDs are forwardly tracked. PTN can change families,
* Remove annotations to ‘do not annotate’ and ‘do not manually annotate’ term (?)
* Run taxon constraints checks (?)
* All these actions are recorded in the ‘comments’ file (mostly; some notes were not yet populated
* If a, b or c happens, the family curation status will be changed to ‘REQUIRE PAINT REVIEW’
* Generate GAF as described below
* GAF are stored on the Panther db: ftp://ftp.pantherdb.org/downloads/paint/presubmission
* GO loads the yaml file from https://github.com/geneontology/go-site/blob/master/metadata/datasets/paint.yaml

==PAINT GAF Files==
File Header
All gene association files must start with a single line denoting the file format, followed by the date of creation, PANTHER and GO versions, as below, for example:

!gaf-version: 2.1
!Created on Thu Apr 5 23:42:21 2018.
!PANTHER version: v.13.1.
!GO version: 2017-12-27.

===Annotation Fields and Data Contents===
====DB (column 1)====
refers to the database from which the identifier in DB object ID (column 2) is drawn.
According to the GAF document, it must be one of the values from the set of GO database cross-references.
Below is the DB used for the GAF of each genome. The ones in red are the ones that are not in the GO database cross-references.

gene_association.paint_cgd.gaf
CGD
UniProtKB

gene_association.paint_chicken.gaf
UniProtKB

gene_association.paint_dictyBase.gaf
UniProtKB
dictyBase → DictyBase

gene_association.paint_ecocyc.gaf
EcoGene
UniProtKB

gene_association.paint_fb.gaf
FB
UniProtKB

gene_association.paint_human.gaf
UniProtKB
!!! Please note that UniProtKB IDs, NOT HGNC IDs, are used for human genes.

gene_association.paint_mgi.gaf
MGI
UniProtKB

gene_association.paint_pombase.gaf
PomBase
UniProtKB

gene_association.paint_rgd.gaf
RGD
UniProtKB

gene_association.paint_sgd.gaf
SGD

gene_association.paint_tair.gaf
Araport
TAIR
UniProtKB

gene_association.paint_wb.gaf
UniProtKB
WB

gene_association.paint_zfin.gaf
UniProtKB

gene_association.paint_other.gaf
UniProtKB
WB (some CAEBR genes)
Xenbase
ZFIN (???)

====DB Object ID (column 2)====
Primary identifier of the gene from the DB specified in column 1.
Example:
MGI:1921966
SPCC895.04c
Q13217

====DB Object Symbol (column 3)====
A gene symbol or gene name is used here. This is usually from the Reference Proteome dataset, from the GN file of their fasta file header.

====Qualifier (column 4)====
Enter qualifier such as NOT, contributes_to and colocalizes_with.

====GO ID (column 5)====
The GO identifier that is annotated to the gene in column 2, e.g., GO:0060070.

====DB:Reference (column 6)====

PMID:21873635

====Evidence Code (column 7)====
Should always be IBA

====With [or] From (column 8)====
The column contains the ancestral node PTN id that the annotation inherits from, as well as all the leaf sequence IDs with experimental annotations that are used as evidence for the IBD annotation to the ancestral node. They are in the following format:

PANTHER:PTNxxxxx|[seq1]|[seq 2]

Example:
PANTHER:PTN001527784|UniProtKB:Q14833|UniProtKB:Q14831

====Aspect (column 9)====
refers to the namespace or ontology to which the GO ID (column 5) belongs.
P (biological process)
F (molecular function)
C (cellular component)

====DB Object Name (column 10)====
Name of gene or gene product obtained from the UniProt Reference Proteomes.
All annotated genomes should be in the UniProt Reference Proteomes to have the correct names.

====DB Object Synonym (column 11)====
It is the UniProtKB ID and the leaf PTN ID separated by a pipe. If the DB (column 1) is already UniProtKB, then it is not included.
Example:
UniProtKB:Q8R4E4|PTN000409177

====DB Object Type (column 12)====
It is always ‘protein’.

====Taxon (column 13)====
This is the taxon ID in the format as below:
taxon:10090

====Date (column 14)====
Currently it is the date the update is done, but we will change to the date the original curation was done.

====Assigned By (column 15)====
‘GO_Central’.

====Annotation Extension (column 16)====
Blank now.

====Gene Product Form ID (column 17)====
Blank now. Pascale

Pascale: Created page with "Category:GO Managers Meetings ==From PI call== Managers should help define the tasks of the helpdesk group Proposal: (Pascale) * monitor helpdesk repo * monitor Biostar..."

[[Category:GO Managers Meetings]]

==From PI call==
Managers should help define the tasks of the helpdesk group

Proposal: (Pascale)
* monitor helpdesk repo
* monitor Biostars for GO-related questions





== Topics not discussed at last meeting ==

* create a simple challenge form? (see noctua new user form)
* licensing and "remix" for upstream sources (e.g. Reactome)
* licensing sign-over or statement (annotation input)
* zenodo and user metadata; proposal: "active" users and cull users.yaml (possibly a small sub-group from there, about half an hour)
* Laurent-Philippe: collect information / links / contacts about the GO user communities (e.g. R/bioconductor and ?)
* (Pascale) Rules, especially taxon checks: can we have this for the July release? https://github.com/geneontology/go-annotation/issues/1928


==Minutes== Pascale

Pascale: /* In progress */

=In progress=


==Molecular function==
Equivalent axioms for MF that include 'binding': use 'has_part' some binding (see https://github.com/geneontology/go-ontology/issues/14266)


==Children of transcription regulator activity==

For example: DNA-binding transcription factor activity

transcription regulator activity
'part of' some 'regulation of transcription, DNA-templated'
'has necessary component activity' some 'transcription regulatory region sequence-specific DNA binding'



[[Category:Ontology]] Pascale

David: Created page with "= Conference Line = *Zoom: https://stanford.zoom.us/j/828418143 = Agenda = ==GH project link== https://github.com/geneontology/go-ontology/projects/1 == Editors Discussio..."

= Conference Line =

*Zoom: https://stanford.zoom.us/j/828418143

= Agenda =


==GH project link==
https://github.com/geneontology/go-ontology/projects/1

== Editors Discussion ==

===Ontology Developers' workshop possibility- Geneva in late August (or maybe September)?===
* Topics
** GH Jamboree
** Creating necessary and sufficient logical definitions (We never got around to this in Berkeley)
** Updating Documentation
** GO-Rhea-Reactome alignment
** Dealing with GH conflicts

=== Outstanding Pull Requests ===
There are now 26 open requests. We are getting better.

=== Regenerate Imports File ===
What is the status of Docker and do we have documentation on its use?

=== Obsoletion plugin for Protege ===
Does everyone have Jim's plugin? If not we should all install it and I will update the documentation.
What is the status of the merge plugin?

=== DBxrefs ===
There was a recent thread about the scope of dbxrefs in the ontology. If we are going to use the dbxrefs to seed an alignment between GO Rhea and Reactome, at least for MF, they should be 1:1.

Did this get covered last week?

= Minutes =
*On call:


[[Category: Ontology]]
[[Category: Meetings]] David

Pascale:

* Which annotation validation rules are currently implemented ? https://github.com/geneontology/go-annotation/issues/1928
* Taxon checks should be a hard check: https://github.com/geneontology/go-site/issues/660
* TIGR, JCVI, PAMGO ISS annotations: Michelle:
The ISS annotations from at least TIGR (and should be also JCVI and PAMGO) were all manual. They were either matches to HMMs or based on pairwise alignments. We used IEA for any annotations that were automatic from our pipeline and not reviewed. I assume JCVI continued that process after I left - at least until they stopped using their pipeline and shifted completely to using the NCBI PGAP tool (prokaryotic genome annotation pipeline).
I think we (and hopefully PAMGO) were pretty good about using the GO_REFs to indicate whether it was HMM or pairwise. The problem with replacing our HMM annotations with InterPro2GO mappings is that we made much more specific annotations based on HMMs than what the InterPro mappings often do. I'd hate to lose those but I understand your desire to keep the annotations current.


[[Category:Quality Control]] Pascale