AmiGO development

From GO Wiki
Revision as of 16:09, 31 July 2007 by Sjcarbon (talk | contribs) (added base for page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Summary

This is a page for developers hash out API specs and other development issues.

AmiGO Layer

AmiGO::Reader

We could abstract away all of the IO at the top level with a general CGI input class. Basically, I imagine it should look like this:

my $r = AmiGO::Reader->new('go_ids');
my $term_l1 = $r->read_string('GO:1234567')
my $term_l2 = $r->read_filehandle(FILE);
die_template("Nuts: " . $r->error_message) if ! $r->success;

I'm already using something like this, so once the GO::Parser stuff is finally hooked in, we get a free ride for the input.

AmiGO::Slimmer

my @EXPORT = qw(new success error_message
                get_ontology_mappings get_association_mappings
                get_counts get_assoc add_ga_line);
my @EXPORT_OK = qw(map_to_subset);

## Takes an ontology graph, slim graph, and a binary argument for
## whether or not to use buckets.
sub new {

 my $class = shift;
 my $ontology_graph = shift;
 my $slim_graph = shift;
 my $bucket = shift;

 my $self = {};

 $self->{ONTOLOGY_GRAPH} = $ontology_graph;
 $self->{SLIM_GRAPH} = $slim_graph;
 $self->{SLIM_HASH} = {};
 $self->{MEMOIZED_RESULTS} = {};

 $self->{TERMS_FOUND_GA} = {}; # accs of terms (to be removed)
 $self->{NEW_GA_LINES} = []; # new lines for a GA file (to be removed)
 
 $self->{BUCKET} = 0;
 $self->{BUCKET} = 1 if $bucket && $bucket == 1;

 ## Start catching errors.
 $self->{SUCCESS} = 1;
 $self->{ERROR_MESSAGE} = 'n/a';

 ## Add buckets if we want them.
 $self->{SLIM_GRAPH}->add_buckets if $self->{BUCKET};

## And so on...
.
.
.
}
## Ugh. You didn't see this. Hopefully I'll be removing this today and 
## use a list of annotated terms instead.
sub add_ga_line
## Returns an array of lines for a new gene association file.
## Not a good method. Not sure what a more appropriate return
## system should be.
sub get_assoc
## Returns an array ref to an array of hashes containing data like:
## acc, name, counts, obsolete_p, bucket_term_p, etc.
sub get_counts
## The returning data structures are an array ref of hashes where:
##
##    array[0]{ACC} == <acc>
##    array[0]{LEAVES} == <a ref to an array of the leaf accs>
##    array[0]{ALL} == <a ref to an array of the all accs>
##
sub get_ontology_mappings()
sub get_association_mappings()
## Returns an array ref of leaf and all ancestor array refs.
## This is meant to be an internal function.
sub map_to_subset($acc)
## Returns 1 or 0 after all operations
sub success
## Returns an error message related to the reason for failure for
## all operations.
sub error_message

It would be nice to start working out common returns classes for the AmiGO layer functions. We could stash them all in AmiGO.pm and have them be the currency for everything below. These would be able to be dropped into a template (or other rendering interface) and need as little additional attention as possible.

Off the top of may head from things displayed in AmiGO so far and ignoring tree stuff, we'd need:

  • A term-like class
  • An association-like class
  • A list thingy that would have a main value, an ordering value, and a flexible number of additional informational fields (maybe lists)

I'm not sure where would be the best place to put URL creation in all of this.