Ontology meeting 2012-04-18

From GO Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  • 30 min call
  • 9am Pacific/12 noon East Coast/5pm UK

Attending: David, Harold, Heiko, Jane, Karen, Midori, Paola, Becky, Tanya, Mary, Val, Chris, Emily, Rachael.

MINUTES: PAOLA


  • COLUMN 16:

1. From the meeting on the 1st Feb., some evidence codes were slated for obsoletion and new ones suggested. Some of the larger changes were made to: ftp://ftp.geneontology.org/pub/go/scratch/xps/new_draft_go_extension_rels.obo

As we felt uneasy making large-scale changes to the go_relations ontology without discussion with all interested parties.

Many of the changes involve the description of targets/inputs/outputs for a MF or BP.

Suggested obsoletions: - has_downstream_target - has_upstream_or_downstream_target - has_upstream_target

Reasoning: Is it necessary to provide such upstream/downstream directionality to these relationships? Perhaps instead we are intending to describe the direct or indirect nature of the interaction of the MF/BP with its target substance?

A new organization of relationships for targets was created

  • Intending that, further to this:
'has_regulation target'

Def: Identifies a gene or gene product affected by a regulation BP (or regulator MF?).

should be replaced by:
'has_indirect_target'

Def:Identifies a gene or gene product affected by a regulation BP.

  • Do we need so many target relationships however? Could some be merged?

Would life be simpler but just as descriptive if we were to have a smaller set of target relationships, e.g.

has_target (narrow synonym: localizes)

[i] has_direct_target (narrow synonyms: directly_localizes; has_substrate)

[i] has_indirect_target (related synonym: has_regulation_target)


  • MINUTES:


ISSUES:

- Do we need to keep all current relationships? Can we obsolete some, and/or merge others?

- How can we make sure that they're used unambiguously?

- Can we have a unique repository for all relationships?

- We need to better define the relationships, so that it is easier to figure out which one to use, and they are well distinct (e.g. has_input versus has_target).


TAKE-HOME MESSAGES:

For the time being, we'll keep all relationships, except for

- has_downstream_target

- has_upstream_or_downstream_target

- has_upstream_target

which can be obsoleted.

As for the others, we'll decide on a case-by-case basis if we want to merge some.

Right now, it seems that the specificity may be useful in many cases, provided that the relationships are well defined.

The disjointedness axiom will warrant that there is no ambiguity in the usage of the relationships.


ACTION ITEMS:

- Obsolete has_downstream_target, has_upstream_or_downstream_target, has_upstream_target [who is going to do this?].

- Provide the users with a merged file containing all relationships [Chris].

- Provide better definitions for all relationships [Chris - is that ok?] and, where possible, examples [who?].

- Move the file into svn [Chris, coordinating with Midori].

I have committed all changes. Once other editors + Midori have theirs committed let's move it.

If there are still tools that are hardcoded with the old URL (just PomBase and EBI I think - though we will soon want to load this into our solr index) then we can have a jenkins job that synchronizes these - but I'd rather just replace the contents of a file with a comment stating the redirect.

The new location will be 

	GO-SVN/ontology/extensions/go_annotation_extension_relations.obo

The PURL will be

	http://purl.obolibrary.org/obo/go/extensions/go_annotation_extension_relations.obo

We will also move the examples file at this time.

This will always resolve to a set of relations that can be used in c16. In future this will be derived automatically by combining separate files but for now the editorial file is also the read-only obo file.

Once added to svn we will have a jenkins job that checks every commit for errors and inconsistencies.

- Arrange for another call on this topic, preferably about a month from now, using a half-hour slot [Jane].