Bio::D...egator(3pm)

πŸ“¦
version 1.7.4 Β· 2 versions
, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble

πŸ’– NAME πŸ’–

Bio::DB::GFF::Aggregator β€” the glow-up machine that takes a bunch of GFF groups and smushes them into composite features ✨ (this is from the Bio::DB::GFF family, 3pm, and bestie it's a whole vibe).


🌸 SYNOPSIS 🌸

okay so first you gotta pull in the module and build your aggregators, like:

use Bio::DB::GFF;

my $agg1 = Bio::DB::GFF::Aggregator->new(-method       => 'cistron',
                                         -main_method  => 'locus',
                                         -sub_parts    => ['allele','variant']
                                        );

my $agg2 = Bio::DB::GFF::Aggregator->new(-method       => 'splice_group',
                                         -sub_parts    => 'transcript');

my $db      = Bio::DB::GFF->new( -adaptor    => 'dbi:mysql',
                                 -aggregator => [$agg1,$agg2],
                                 -dsn        => 'dbi:mysql:elegans42',
                                );

and that's it, that's the whole entrance πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

So Bio::DB::GFF::Aggregator is the class that aggregates GFF groups into composite features. Every composite feature has a "main part" β€” that's the top-level feature, the main character πŸ‘‘ β€” and then a series of zero or more subparts, which you retrieve with the sub_SeqFeature() method. And the way this class is set up? It's designed to be subclassable, so a whole variety of GFF feature types can be supported. slay.

The base Bio::DB::GFF::Aggregator class is generic β€” it's giving blank canvas β€” and you use it to create specific instances that you then pass to the -aggregator argument of the Bio::DB::GFF->new() call. Meanwhile the various subclasses of Bio::DB::GFF::Aggregator are tuned for specific common feature types, like clones, gapped alignments and transcripts. iykyk.


✨ the three attributes, bestie ✨

Instances of Bio::DB::GFF::Aggregator have three attributes:

  • method β€” this is the GFF method field of the composite feature as a whole. For example, "transcript" may be used for a composite feature created by aggregating individual intron, exon and UTR features.
  • main method β€” sometimes GFF groups are organized hierarchically, with one feature logically containing another. For example, in the C. elegans schema, methods of type "Sequence:curated" correspond to regions covered by curated genes. There can be zero or one main methods.
  • subparts β€” this is a list of one or more methods that correspond to the component features of the aggregates. For example, in the C. elegans database, the subparts of transcript are "intron", "exon" and "CDS".

πŸŽ€ the two big methods you can override πŸŽ€

Aggregators have two main methods that can be overridden in subclasses:

  • disaggregate() β€” this method gets called by the Adaptor object prior to fetching a list of features. It gets passed an associative array containing the [method,source] pairs that the user has requested, and it returns a list of raw features that it would like the adaptor to fetch.
  • aggregate() β€” this method gets called by the Adaptor object after it has fetched features. It gets passed a list of raw features and is expected to add its composite features to the list.

🌈 and if that's too much, here's the shortcut 🌈

The disaggregate() and aggregate() methods that come with the base Aggregator class should be sufficient for many applications. In that case, all a subclass needs to do is override these following methods:

  • method() β€” return the default method for the composite feature as a whole.
  • main_name() β€” return the default main method name.
  • part_names() β€” return a list of subpart method names.

Provided that method() and part_names() are overridden (and optionally main_name() as well πŸ‘€), then the bare name of the aggregator subclass can be passed to the -aggregator of Bio::DB::GFF->new(). For example, this is a small subclass that will aggregate features of type "allele" and "polymorphism" into an aggregate named "mutant":

package Bio::DB::GFF::Aggregator::mutant;

use strict;
use Bio::DB::GFF::Aggregator;

use base qw(Bio::DB::GFF::Aggregator);

sub method { 'mutant' }

sub part_names {
  return qw(allele polymorphism);
}

1;

Once installed, this aggregator can be passed to Bio::DB::GFF->new() by name, like so:

my $db      = Bio::DB::GFF->new( -adaptor    => 'dbi:mysql',
                                 -aggregator => 'mutant',
                                 -dsn        => 'dbi:mysql:elegans42',
                                );
🫢 and yes bestie, there's more where that came from β€” hang tight, the page continues πŸ’–

✨ API ✨

Okay bestie, the rest of this doc is literally just a tour of every public AND private method this module ships with. Buckle up πŸ’–


🌸 new

Title   : new
Usage   : $a = Bio::DB::GFF::Aggregator->new(@args)
Function: create a new aggregator
Returns : a Bio::DB::GFF::Aggregator object
Args    : see below
Status  : Public

This is the constructor for Bio::DB::GFF::Aggregator, aka where the whole thing gets born ✨ Named args go like this:

  • -method β€” the method for the composite feature
  • -main_method β€” the top-level raw feature, if any
  • -sub_parts β€” the list of raw features that will form the subparts of the composite feature (array reference or scalar)

πŸ¦‹ disaggregate

Title   : disaggregate
Usage   : $a->disaggregate($types,$factory)
Function: disaggregate type list into components
Returns : a true value if this aggregator should be called to reaggregate
Args    : see below
Status  : Public

So this one gets called to disaggregate a list of types down into the set of low-level features that are actually gonna be fetched from the GFF database. The list of types comes in as an array reference stuffed with a whole series of [method,source] pairs. This method then synthesizes a brand-new set of [method,source] pairs and appends them onto the list of requested types β€” changing that list in situ, no cap.

Arguments:

  • $types β€” reference to an array of [method,source] pairs
  • $factory β€” reference to the Adaptor object that is calling this method
Heads up 🫢 the API does allow disaggregate() to remove types from the type list. That feature is probably not desirable and may be deprecated in the future. So like… don't build your whole personality on it, okay?

🌈 aggregate

Title   : aggregate
Usage   : $features = $a->aggregate($features,$factory)
Function: aggregate a feature list into composite features
Returns : an array reference containing modified features
Args    : see below
Status  : Public

This is the glow-up method πŸ’… it takes a list of raw GFF features and turns them into the set of composite features. You hand it an array reference to a set of Bio::DB::GFF::Feature objects, it runs through the list, and it creates new composite features whenever that's the right move. The result? An array reference holding the composite features.

Arguments:

  • $features β€” reference to an array of Bio::DB::GFF::Feature objects
  • $factory β€” reference to the Adaptor object that is calling this method
NOTE: the reason the function result keeps the raw features alongside the aggregated ones is so queries like this one can work:
@features =  $segment->features('exon','transcript:curated');

Assuming "transcript" is the name of an aggregated feature and "exon" is one of its components, we do not want the transcript aggregator deleting features of type "exon", because the user literally asked for them by name. Respect the request, periodt ✨


πŸŽ€ method

Title   : method
Usage   : $string = $a->method
Function: get the method type for the composite feature
Returns : a string
Args    : none
Status  : Protected

Called to get the method that'll be assigned to the composite feature once it's all aggregated. It gets called when the user didn't explicitly pass a -method argument back when the aggregator was created.

This is the method you should override in your aggregator subclasses, bestie πŸ‘‘


πŸ’œ main_name

Title   : main_name
Usage   : $string = $a->main_name
Function: get the method type for the "main" component of the feature
Returns : a string
Args    : none
Status  : Protected

Gets you the method of the "main component" of the composite feature. Called when the user didn't explicitly supply a -main-method argument at aggregator-creation time.

Yeah, this is the one to override in your subclasses. Same energy.


🧚 part_names

Title   : part_names
Usage   : @methods = $a->part_names
Function: get the methods for the non-main various components of the feature
Returns : a list of strings
Args    : none
Status  : Protected

This one fetches the list of methods for the "main component" of the composite feature. It's called if the user didn't explicitly hand over a -main-method argument when the aggregator got created.

And yep β€” this is the method you should override in aggregator subclasses too. (That's what the original says, so that's what I'm telling you πŸ’€)


⭐ require_whole_object

Title   : require_whole_object
Usage   : $bool = $a->require_whole_object
Function: see below
Returns : a boolean flag
Args    : none
Status  : Internal

Returns true if the aggregator should flat-out refuse to aggregate an object unless both its main part and its subparts are present. All or nothing, iconic behaviour tbh.


πŸ”₯ match_sub

Title   : match_sub
Usage   : $coderef = $a->match_sub($factory)
Function: generate a code reference that will match desired features
Returns : a code reference
Args    : see below
Status  : Internal

Used internally to generate a code sub that quickly filters out the raw features we actually care about aggregating. The sub it hands back takes a Feature and returns true if we should aggregate it, false otherwise. Vibe check, but for features 🌸


πŸ“ strict_match

Title   : strict_match
Usage   : $strict = $a->strict_match
Function: generate a hashref that indicates which subfeatures
          need to be tested strictly for matching sources before
          aggregating
Returns : a hash ref
Status  : Internal

Generates a hash ref that tells you which subfeatures have to be tested strictly for matching sources before any aggregating happens. Picky on purpose πŸ’…


πŸ¦‹ components

Title   : components
Usage   : @array= $a->components([$components])
Function: get/set stored list of parsed raw feature types
Returns : an array in list context, an array ref in scalar context
Args    : new arrayref of feature types
Status  : Internal

Internal memory-keeper for the parsed list of raw features we're gonna aggregate. Why does this sub even exist? Because when a user asks for a composite feature of type "clone:cosmid", that generates a list of components where the source gets appended to the method β€” like "clone_left_end:cosmid" and "clone_right_end:cosmid". components() stashes that info for later use. So organised, we love her ✨


🌈 get_part_names

Title   : get_part_names
Usage   : @array = $a->get_part_names
Function: get list of sub-parts for this type of feature
Returns : an array
Args    : none
Status  : Internal

Internal fetch of the list of feature types that make up the components of the composite feature. Type names in "method:source" format are recognised, and so are "method" on its own and Bio::DB::GFF::Typename objects as well. It checks the instance variables first, and if those aren't defined it calls the part_names() method. Loyal to a fault 🫢


πŸ’– get_main_name

Title   : get_main_name
Usage   : $string = $a->get_main_name
Function: get the "main" method type for this feature
Returns : a string
Args    : none
Status  : Internal

Internal fetch for the type of the "main part" of the feature. Checks instance variables first, and if they're not defined it goes and calls the main_name() method.


πŸ‘‘ get_method

Title   : get_method
Usage   : $string = $a->get_method
Function: get the method type for the composite feature
Returns : a string
Args    : none
Status  : Internal

Internal fetch for the type of the method that gets assigned to the composite feature once it's been synthesized. Last one, we made it πŸŽ€


πŸ’€ BUGS

None known yet. Not a single one β€” she's flawless, apparently ✨


πŸ¦‹ SEE ALSO

  • Bio::DB::GFF
  • Bio::DB::GFF::Aggregator::alignment
  • Bio::DB::GFF::Aggregator::clone
  • Bio::DB::GFF::Aggregator::coding
  • Bio::DB::GFF::Aggregator::match
  • Bio::DB::GFF::Aggregator::processed_transcript
  • Bio::DB::GFF::Aggregator::transcript
  • Bio::DB::GFF::Aggregator::none

πŸ’œ AUTHOR

Lincoln Stein <lstein@cshl.org>.

Copyright (c) 2001 Cold Spring Harbor Laboratory.

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


And that's a wrap, bestie πŸŽ€ this whole page is from perl v5.30.0, dated 2020-01-13 β€” so yes, she's vintage, she's archival, she's still serving. Go aggregate something iconic πŸ’…βœ¨

πŸ“¦ where this page comes from