AmiGO development: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Web Presence Working Group]] [[Category:Software]]
==Summary==
==Summary==


Line 4: Line 5:


==AmiGO Layer==
==AmiGO Layer==
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.
===AmiGO::Session (?)===
A layer between filesystem session storage (should be migratable to mod_perl) and AmiGO top-level. An example of use might be:
## Init.
my $session = AmiGO::Session->new();
## Get the one that the user wanted or start another to a default state.
$session->read_in('32453245345345');
$session->create() if ! $session->success;
## Collect some rendering information to be passed later.
my $page_size = $session->get_element('pref_pagesize');
## Work with a more complicated piece.
my $cart_array = $session->get_element('object_gocart');
push @{$cart_array}, $new_item;
$session->store_element('object_gocart', $cart_array);


===AmiGO::Reader===
===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:
A layer between go-perl and AmiGO top-level for handling IO.
 
Currently, because of the way that GO::Parser is implemented, it requires its input to be a file (even though Data::Stag::BaseGenerator doesn't require it). To get around this, the filehandle is written out and  and passed in via a temporary file, thus the need to initialize with a scratch directory. Kludge.


my $r = AmiGO::Reader->new('go_ids');
An example of use might be:
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.
my $reader = AmiGO::Reader->new('go_ids', 'sessions/scratch'); # create a go_ids reader
my $fh = new IO::Scalar \$slim_list; # convert to filehandle
my $graph = $reader->readh($fh); # convert to graph
die_template("Failed on term input ($type): " . $reader->error_message)
    if ! $reader->success;
 
The API as it stands now:
 
my @EXPORT = qw(new readh success error_message);
 
## Takes GO::Parser handler strings and a scratch directory as
## arguements.
my $reader = AmiGO::Reader->new($wanted_go_handler, $writable_directory);
 
## Convert the filehandle into a graph.
my $graph = $reader->readh($fh);
 
## Return 1 or 0 for all operations.
$reader->success
 
## Returns the reason for the above error.
$reader->error_message


===AmiGO::Slimmer===
===AmiGO::Slimmer===
The API as it stands now:


  my @EXPORT = qw(new success error_message
  my @EXPORT = qw(new success error_message
                 get_ontology_mappings get_association_mappings
                 get_ontology_mappings get_association_mappings
                 get_counts get_assoc add_ga_line);
                 get_counts get_columns add_graph);
  my @EXPORT_OK = qw(map_to_subset);
  my @EXPORT_OK = qw(map_to_subset);
 
  ## Takes an ontology graph, slim graph, and a binary argument for
  ## Takes an ontology graph, slim graph, and a binary argument for
  ## whether or not to use buckets.
  ## whether or not to use buckets.
  sub new {
  my $slimmer = AmiGO::Slimmer->new($ont_graph, $slim_graph, $use_bucket_p)
 
  my $class = shift;
  ## Adds a graph to the Slimmer object. Probably from a go_assoc file.
  my $ontology_graph = shift;
  $slimmer->add_graph($g)
  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
  ## Returns an array ref to an array of hashes containing data like:
  ## use a list of annotated terms instead.
  ## acc, name, counts, obsolete_p, bucket_term_p, etc.
  sub add_ga_line
  $slimmer->get_counts()


  ## Returns an array of lines for a new gene association file.
  ## Returns an array of arrays containing columns for a new gene association file.
  ## Not a good method. Not sure what a more appropriate return
  ## Not a good method. Not sure what a more appropriate return
  ## system should be.
  ## system should be.
  sub get_assoc
  $slimmer->get_columns()
 
## 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:
  ## The returning data structures are an array ref of hashes where:
Line 77: Line 103:
  ##    array[0]{ALL} == <a ref to an array of the all accs>
  ##    array[0]{ALL} == <a ref to an array of the all accs>
  ##
  ##
  sub get_ontology_mappings()
  $slim->get_ontology_mappings()
  sub get_association_mappings()
  $slim->get_association_mappings()


  ## Returns an array ref of leaf and all ancestor array refs.
  ## Returns an array ref to an array of two array refs. The first is an
  ## This is meant to be an internal function.
  ## array of the slim terms to which the $acc hits first while climbing
  sub map_to_subset($acc)
## the tree. The second is all ancestors in the slim.
  $slim->map_to_subset($acc)


  ## Returns 1 or 0 after all operations
  ## Returns 1 or 0 after all operations
  sub success
  $slim->success


  ## Returns an error message related to the reason for failure for
  ## Returns an error message related to the reason for failure for
  ## all operations.
  ## all operations.
  sub error_message
  $slim->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.


===AmiGO::TermFinder===
===AmiGO::TermFinder===


TODO (done but session, needs to be cleaned and posted) -sjc
TODO (done but session interface, needs to be cleaned and posted) -sjc
 
[[Category:AmiGO]][[Category:Development]][[Category:Software]]

Latest revision as of 16:38, 7 April 2014

Summary

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

AmiGO Layer

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.

AmiGO::Session (?)

A layer between filesystem session storage (should be migratable to mod_perl) and AmiGO top-level. An example of use might be:

## Init.
my $session = AmiGO::Session->new();

## Get the one that the user wanted or start another to a default state.
$session->read_in('32453245345345');
$session->create() if ! $session->success;
## Collect some rendering information to be passed later.
my $page_size = $session->get_element('pref_pagesize');
## Work with a more complicated piece.
my $cart_array = $session->get_element('object_gocart');
push @{$cart_array}, $new_item;
$session->store_element('object_gocart', $cart_array);

AmiGO::Reader

A layer between go-perl and AmiGO top-level for handling IO.

Currently, because of the way that GO::Parser is implemented, it requires its input to be a file (even though Data::Stag::BaseGenerator doesn't require it). To get around this, the filehandle is written out and and passed in via a temporary file, thus the need to initialize with a scratch directory. Kludge.

An example of use might be:

my $reader = AmiGO::Reader->new('go_ids', 'sessions/scratch'); # create a go_ids reader
my $fh = new IO::Scalar \$slim_list; # convert to filehandle
my $graph = $reader->readh($fh); # convert to graph
die_template("Failed on term input ($type): " . $reader->error_message)
   if ! $reader->success;

The API as it stands now:

my @EXPORT = qw(new readh success error_message);
## Takes GO::Parser handler strings and a scratch directory as
## arguements.
my $reader = AmiGO::Reader->new($wanted_go_handler, $writable_directory);
## Convert the filehandle into a graph.
my $graph = $reader->readh($fh);
## Return 1 or 0 for all operations.
$reader->success
## Returns the reason for the above error.
$reader->error_message

AmiGO::Slimmer

The API as it stands now:

my @EXPORT = qw(new success error_message
                get_ontology_mappings get_association_mappings
                get_counts get_columns add_graph);
my @EXPORT_OK = qw(map_to_subset);
## Takes an ontology graph, slim graph, and a binary argument for
## whether or not to use buckets.
my $slimmer = AmiGO::Slimmer->new($ont_graph, $slim_graph, $use_bucket_p)
## Adds a graph to the Slimmer object. Probably from a go_assoc file.
$slimmer->add_graph($g)
## Returns an array ref to an array of hashes containing data like:
## acc, name, counts, obsolete_p, bucket_term_p, etc.
$slimmer->get_counts()
## Returns an array of arrays containing columns for a new gene association file.
## Not a good method. Not sure what a more appropriate return
## system should be.
$slimmer->get_columns()
## 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>
##
$slim->get_ontology_mappings()
$slim->get_association_mappings()
## Returns an array ref to an array of two array refs. The first is an
## array of the slim terms to which the $acc hits first while climbing
## the tree. The second is all ancestors in the slim.
$slim->map_to_subset($acc)
## Returns 1 or 0 after all operations
$slim->success
## Returns an error message related to the reason for failure for
## all operations.
$slim->error_message

AmiGO::TermFinder

TODO (done but session interface, needs to be cleaned and posted) -sjc