[Bioperl-l] Request for comments: Bio::DB::GFF3 namespace

[Hilmar Lapp]

I would suggest under the Bio::DB namespace (e.g.,
Bio::DB::SeqFeature), that keeps all the database access
interfaces/implementations in one place.

Alternatively, go with along with the Bio::SeqFeature::CollectionI
name as the base interface, i.e., implementations would then go under
the Bio::SeqFeature::Collection namespace. If this is the critical
interface being implemented (it sounds like it is?), the naming would
be in line with the pattern used elsewhere (Bio::LocationI and
Bio::Location::*, Bio::SeqFeatureI and Bio::SeqFeature::*, Bio::SeqI
and Bio::Seq::*).

My few cents ...

     -hilmar

On 3/21/06, Lincoln Stein <lstein at cshl.edu> wrote:
> Hi All,
>
> I'm pretty much ready to check in the replacement for the Bio::DB::GFF
> database. What I ended up writing has only a remote relationship to gff3
> files -- it is more like a general storage engine for Bio::SeqFeatureI
> objects. So I don't want to call the thing Bio::DB::GFF, but want to place it
> somewhere else in the namespace hierarchy.
>
> Here are my current classes and what they do; the names are placeholders so
> don't get hung up on what they're called now:
>
>         Bio::SeqFeature::Store
>                 - implements the Bio::SeqFeature::CollectionI interface. You can
>                 store any Bio::SeqFeatureI into a database (mysql, berkeleydb, in-memory)
>                 and fetch it out using a variety of queries.
>
>         Bio::SeqFeature::Store::DBI
>                 - base class for DBI databases
>
>         Bio::SeqFeature::Store::DBI::mysql
>                 - mysql storage implementation
>
>         Bio::SeqFeature::Store::DBI::mysql::Iterator
>                 - helper class for the mysql adaptor. Implements
>                         (part of) the Bio::SeqIO interface
>
>         Bio::SeqFeature::Store::memory
>                 - in-memory storage implementation
>
>         Bio::SeqFeature::Store::bdb
>                 - Berkeley DB storage implementation
>
>         Bio::SeqFeature::Store::Cacher
>                 - An in-memory cache for the store; uses an LRU cache
>                         to avoid going to the database for frequently used
>                         objects. Also implements  scheme that lets features
>                         share the same in-memory subfeatures (like shared
>                         exons).
>
>         Bio::SeqFeature::LazyFeature
>                 - A Bio::SeqFeatureI class that stores its subfeatures in an
>                         underlying Bio::SeqFeature::Store and fetches them
>                         in a lazy fashion as needed.
>
>         Bio::SeqFeature::LazyTableFeature
>                 - A Bio::SeqFeatureI class that stores its subfeatures in
>                         an underlying Bio::SeqFeature::Store, AND stores
>                         the parent/child relationship data in the Store as
>                         well. Fetches subfeatures as needed in a lazy fashion.
>
> A utility script, currently called gff3_load.pl, parses a gff3 file, creates
> the proper objects, and stores them in the Store. Eventually some of this
> functionality will be moved into Bio::Tools::GFF.
>
> So where should I put these files? The Bio::DB namespace? A new
> Bio::Collection namespace? A Bio::SeqFeature::Collection namespace?
>
> Lincoln
>
>
> --
> Lincoln D. Stein
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724
> FOR URGENT MESSAGES & SCHEDULING,
> PLEASE CONTACT MY ASSISTANT,
> SANDRA MICHELSEN, AT michelse at cshl.edu (516 367-5008)
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
>


--
----------------------------------------------------------
: Hilmar Lapp -:- San Diego, CA -:- hlapp at gmx dot net :
----------------------------------------------------------