Guidance on loading multiple assemblies, feature naming, etc.

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
I am loading a number of reference assemblies from UCSC and NCBI for
several primate and non-primate mammals. In some cases, I will be
loading multiple assemblies for the same species, e.g., hg18 and hg19
for H. sapiens. The intent is to then load a large volume of annotated
features from both third party and internal sources over this initial
"scaffold". We will then do ongoing curation and annotation of this
data as well as continually loading an even larger volume of variance
data from third parties and internal sequencing. Before I get too far
down this road, I am looking for guidance. Unfortunately, the Chado
"Best Practices" guide <http://gmod.org/wiki/Chado_Best_Practices> was
of only limited help.

One area of concern is feature naming especially in the presence of
multiple assemblies for a given species. It seems that calling
something just "chr1" isn't going to work, so do I need a unique
feature naming convention such as "hg18_chr1"? One species in
particular where feature renaming might be an issue is P. troglodytes
(the common chimpanzee): the reference assembly multiple sequence
FASTA file has well over 20,000 sections. Or do I create an "assembly"
sequence feature and the chromosomes, etc. will be children of the
assembly, thus requiring only a unique assembly name and letting
"part_of" relationships take care of the rest?

I've only poked around at the edges of the Sequence Ontology and the
Chado schema, but now realize I need to immerse myself in them.
Anything anyone can point me to for guidance on loading and
maintaining a multi-species, multi-assembly Chado database will be
appreciated.

Thanks,
Olen

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
[Dave, I'm cc'ing you on this email since I'm not sure if you are on
the GMOD schema mailing list and, in your former incarnation at the
GMOD help desk, you likely gained valuable insights. Feel free to
ignore it: I'm getting used to that. ;-)]

Folks,

I never received any input from the list on this post, so I'm at a bit
of a loss. I realize it was open-ended, but can anyone out there give
me some small level of understanding of the issues I know I will
encounter? I'm not looking for someone to walk me through things
step-by-step, but just set me on the right path since many of you must
have already traveled down it. I know a large part of this is simple
ignorance of the problem domain (I'm an IT guy with only two months of
bioinformatics experience), but even a response of "Olen, you ignorant
slut!" (my apologies to Dan Aykroyd) and a couple of pointers to
online sources would be helpful. :-)

I'm open to taking any discussion off-list if anyone feels too much of
the group's valuable bandwidth would be taken up and if list etiquette
allows it.

Thanks again,
Olen


On Tue, Apr 12, 2011 at 4:03 PM, Olen Vance Sluder Jr <[hidden email]> wrote:

> I am loading a number of reference assemblies from UCSC and NCBI for
> several primate and non-primate mammals. In some cases, I will be
> loading multiple assemblies for the same species, e.g., hg18 and hg19
> for H. sapiens. The intent is to then load a large volume of annotated
> features from both third party and internal sources over this initial
> "scaffold". We will then do ongoing curation and annotation of this
> data as well as continually loading an even larger volume of variance
> data from third parties and internal sequencing. Before I get too far
> down this road, I am looking for guidance. Unfortunately, the Chado
> "Best Practices" guide <http://gmod.org/wiki/Chado_Best_Practices> was
> of only limited help.
>
> One area of concern is feature naming especially in the presence of
> multiple assemblies for a given species. It seems that calling
> something just "chr1" isn't going to work, so do I need a unique
> feature naming convention such as "hg18_chr1"? One species in
> particular where feature renaming might be an issue is P. troglodytes
> (the common chimpanzee): the reference assembly multiple sequence
> FASTA file has well over 20,000 sections. Or do I create an "assembly"
> sequence feature and the chromosomes, etc. will be children of the
> assembly, thus requiring only a unique assembly name and letting
> "part_of" relationships take care of the rest?
>
> I've only poked around at the edges of the Sequence Ontology and the
> Chado schema, but now realize I need to immerse myself in them.
> Anything anyone can point me to for guidance on loading and
> maintaining a multi-species, multi-assembly Chado database will be
> appreciated.
>
> Thanks,
> Olen
>

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Robert Buels
Oh, it's a great question, it's just kind of hard.  Warnock's dilemma
definitely applies here.  SGN has some experience with this, and I've
had it tagged in my email client to write a substantive reply, but I
just haven't quite gotten to it.

At SGN, we prefix the names of the reference sequences with the build
name, e.g. SL2.40ch01 for chromosome 1 of build 2.40 of Solanum
lycopersicum (SL).  So yes, in your case hg18_chr1 would be quite
reasonable for chromosome 1 of hg18.

For the chimp sequences, are they organized by chromosome?  If so, you
could make chimp chromosome features and make the scaffolds (or whatever
they are) part_of those (feature_relationship).

I would load these by making nice gff3 files that encode all this stuff,
and then using gmod_bulk_load_gff3.pl to load them.

Chado can also represent very nicely the many locations of a single
gene/repeat/SNP/whatever in the various assemblies (with multiple
featurelocs for each features).  However, gmod_bulk_load_gff3.pl can't
be used to load stuff like this.  In fact, this is one of the things at
the top of my work pile right now, but don't wait for me!

To put in a plug for my own project, Bio::Chado::Schema makes it way
easier to load stuff.  DBIx::Class::Schema's populate() method is a very
powerful way to bulk-loading data into a bunch of tables and getting the
interconnections and foreign keys to come out right, and
Bio::Chado::Schema enables that.

How does all this sound?

Rob

On 04/18/2011 08:59 AM, Olen Vance Sluder Jr wrote:

> [Dave, I'm cc'ing you on this email since I'm not sure if you are on
> the GMOD schema mailing list and, in your former incarnation at the
> GMOD help desk, you likely gained valuable insights. Feel free to
> ignore it: I'm getting used to that. ;-)]
>
> Folks,
>
> I never received any input from the list on this post, so I'm at a bit
> of a loss. I realize it was open-ended, but can anyone out there give
> me some small level of understanding of the issues I know I will
> encounter? I'm not looking for someone to walk me through things
> step-by-step, but just set me on the right path since many of you must
> have already traveled down it. I know a large part of this is simple
> ignorance of the problem domain (I'm an IT guy with only two months of
> bioinformatics experience), but even a response of "Olen, you ignorant
> slut!" (my apologies to Dan Aykroyd) and a couple of pointers to
> online sources would be helpful. :-)
>
> I'm open to taking any discussion off-list if anyone feels too much of
> the group's valuable bandwidth would be taken up and if list etiquette
> allows it.
>
> Thanks again,
> Olen
>
>
> On Tue, Apr 12, 2011 at 4:03 PM, Olen Vance Sluder Jr<[hidden email]>  wrote:
>> I am loading a number of reference assemblies from UCSC and NCBI for
>> several primate and non-primate mammals. In some cases, I will be
>> loading multiple assemblies for the same species, e.g., hg18 and hg19
>> for H. sapiens. The intent is to then load a large volume of annotated
>> features from both third party and internal sources over this initial
>> "scaffold". We will then do ongoing curation and annotation of this
>> data as well as continually loading an even larger volume of variance
>> data from third parties and internal sequencing. Before I get too far
>> down this road, I am looking for guidance. Unfortunately, the Chado
>> "Best Practices" guide<http://gmod.org/wiki/Chado_Best_Practices>  was
>> of only limited help.
>>
>> One area of concern is feature naming especially in the presence of
>> multiple assemblies for a given species. It seems that calling
>> something just "chr1" isn't going to work, so do I need a unique
>> feature naming convention such as "hg18_chr1"? One species in
>> particular where feature renaming might be an issue is P. troglodytes
>> (the common chimpanzee): the reference assembly multiple sequence
>> FASTA file has well over 20,000 sections. Or do I create an "assembly"
>> sequence feature and the chromosomes, etc. will be children of the
>> assembly, thus requiring only a unique assembly name and letting
>> "part_of" relationships take care of the rest?
>>
>> I've only poked around at the edges of the Sequence Ontology and the
>> Chado schema, but now realize I need to immerse myself in them.
>> Anything anyone can point me to for guidance on loading and
>> maintaining a multi-species, multi-assembly Chado database will be
>> appreciated.
>>
>> Thanks,
>> Olen
>>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Don Gilbert-2-3
In reply to this post by Olen Vance Sluder Jr
Olen,

I've not done this, but think it would work with chado to handle multiple assemblies,
of one species:  give each assembly a new organism/species ID/name.  Since all the
chado features are tagged by organism id, that would let you go a simple route of
not changing chromosome, feature IDs, but only the organism id.
- Don

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Robert Buels
On 04/18/2011 11:10 AM, Don Gilbert wrote:
> I've not done this, but think it would work with chado to handle multiple assemblies,
> of one species:  give each assembly a new organism/species ID/name.  Since all the
> chado features are tagged by organism id, that would let you go a simple route of
> not changing chromosome, feature IDs, but only the organism id.

However, the downside of this is that you then have fake species in your
organism table.  If you wanted to, for example, query for a summary of
what features you have for a given organism, you would have to figure
out what those organism rows would be.

Perhaps you would need some sort of way of grouping organisms in that
case.  I seem to remember that idea being brought up before.

Rob

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
On Mon, Apr 18, 2011 at 1:50 PM, Robert Buels <[hidden email]> wrote:

> On 04/18/2011 11:10 AM, Don Gilbert wrote:
>> I've not done this, but think it would work with chado to handle multiple assemblies,
>> of one species:  give each assembly a new organism/species ID/name.  Since all the
>> chado features are tagged by organism id, that would let you go a simple route of
>> not changing chromosome, feature IDs, but only the organism id.
>
> However, the downside of this is that you then have fake species in your
> organism table.  If you wanted to, for example, query for a summary of
> what features you have for a given organism, you would have to figure
> out what those organism rows would be.
>
> Perhaps you would need some sort of way of grouping organisms in that
> case.  I seem to remember that idea being brought up before.

Don,

I considered that approach based upon a comment in the GMOD wiki on
the Organism module <http://gmod.org/wiki/Chado_Organism_Module>:

"If a particular strain or subspecies is to be represented, this is
appended onto the species name."

I could consider each assembly a new "strain", but then I reconsidered
for exactly Rob's reasoning. That's when I started to dig into the SO
and came across CV terms for assemblies, golden_paths, etc., got
really confused, and wrote my original email.

The feature naming issue is also related to a bug in Apollo accessing
Chado that was discussed at the recent GMOD spring training and
subsequent email with Ed Lee where Apollo does not properly handle
multiple organisms (or assemblies) with non-unique feature names.

I'm unsure how this will all work as far as configuring GBrowse2, but
I haven't dug into that yet.
--
Olen

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Robert Buels
On 04/18/2011 02:30 PM, Olen Vance Sluder Jr wrote:
> I'm unsure how this will all work as far as configuring GBrowse2, but
> I haven't dug into that yet.

Usually, I make one GBrowse configuration (and
Bio::DB::SeqFeature::Store database on the back end) per assembly.

For example, for the ITAG1, ITAG2, and ITAG2.3, and development versions
of the tomato genome, I have databases sfs_itag1_genomic,
sfs_itag1_protein, sfs_itag2.3_genomic, sfs_itag2.3_protein,
sfs_itag2_genomic, sfs_itag2_protein, sfs_itag_devel_genomic, and
sfs_itag_devel_protein.

With the 'sfs' prefix standing for 'SeqFeature::Store'.

Rob

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
On Mon, Apr 18, 2011 at 5:12 PM, Robert Buels wrote:

> On 04/18/2011 02:30 PM, Olen Vance Sluder Jr wrote:
>> I'm unsure how this will all work as far as configuring GBrowse2, but
>> I haven't dug into that yet.
>
> Usually, I make one GBrowse configuration (and
> Bio::DB::SeqFeature::Store database on the back end) per assembly.
>
> For example, for the ITAG1, ITAG2, and ITAG2.3, and development versions
> of the tomato genome, I have databases sfs_itag1_genomic,
> sfs_itag1_protein, sfs_itag2.3_genomic, sfs_itag2.3_protein,
> sfs_itag2_genomic, sfs_itag2_protein, sfs_itag_devel_genomic, and
> sfs_itag_devel_protein.
>
> With the 'sfs' prefix standing for 'SeqFeature::Store'.

So you have multiple copies of data in different databases depending
upon the tool accessing it? I had intended to use a single Chado
instance as the data store and "hang" all the tools (e.g., Apollo,
GBrowse / GBrowse_syn, Tripal, etc.) off it.
--
Olen

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
In reply to this post by Robert Buels
On Mon, Apr 18, 2011 at 11:46 AM, Robert Buels wrote:
> Oh, it's a great question, it's just kind of hard.  Warnock's dilemma
> definitely applies here.  SGN has some experience with this, and I've
> had it tagged in my email client to write a substantive reply, but I
> just haven't quite gotten to it.

Warnock's Dilemma indeed and I tended towards the answer to my post
was absurdly obvious, but I couldn't see it. ;-)

> At SGN, we prefix the names of the reference sequences with the build
> name, e.g. SL2.40ch01 for chromosome 1 of build 2.40 of Solanum
> lycopersicum (SL).  So yes, in your case hg18_chr1 would be quite
> reasonable for chromosome 1 of hg18.

Because of a bug in Apollo, I may have to go this route too. My only
concern is then having to tweak every third party annotation or
variant dataset that relies upon that original naming. Not difficult,
but a maintenance issue. I guess I need to understand better the name
versus uniquename columns in the feature table and exactly where which
data loader places what or where what tool looks for what.

> For the chimp sequences, are they organized by chromosome?  If so, you
> could make chimp chromosome features and make the scaffolds (or whatever
> they are) part_of those (feature_relationship).

I'm not totally certain: Here's a snippet pulled from the FASTA file:

[root@gmod panTro3]# grep '>' panTro3.fa | wc -l
24132
[root@gmod panTro3]# grep '>' panTro3.fa | head

>chr1
>chr10
>chr10_AACZ03165646_random
>chr10_AACZ03166815_random
>chr10_AACZ03166816_random
>chr10_GL391254_random
>chr10_GL391255_random
>chr10_AACZ03165652_random
>chr10_AACZ03165653_random
>chr10_AACZ03166817_random
[root@gmod panTro3]#

I haven't pulled down the data yet, but the baboon is even more
fragmented (by an order of magnitude) since it's a draft assembly.
Human and rhesus are pretty good: mostly complete chromosomes. I'm not
sure about the rodentia yet.

> I would load these by making nice gff3 files that encode all this stuff,
> and then using gmod_bulk_load_gff3.pl to load them.

I had hoped to minimize any preprocessing of the data, but that looks
unavoidable. Tripal has a FASTA loader, but I haven't tried it other
than at the spring training session with a small fruitfly dataset.

> Chado can also represent very nicely the many locations of a single
> gene/repeat/SNP/whatever in the various assemblies (with multiple
> featurelocs for each features).  However, gmod_bulk_load_gff3.pl can't
> be used to load stuff like this.  In fact, this is one of the things at
> the top of my work pile right now, but don't wait for me!
>
> To put in a plug for my own project, Bio::Chado::Schema makes it way
> easier to load stuff.  DBIx::Class::Schema's populate() method is a very
> powerful way to bulk-loading data into a bunch of tables and getting the
> interconnections and foreign keys to come out right, and
> Bio::Chado::Schema enables that.

So Bio::Chado::Schema is a library that has to be used
programmatically? Not a problem, but any chance there's a Python
version? ;-)

> How does all this sound?

Great! I really appreciate the input.
--
Olen

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Robert Buels
In reply to this post by Olen Vance Sluder Jr
On 04/18/2011 03:27 PM, Olen Vance Sluder Jr wrote:
 > So you have multiple copies of data in different databases depending
 > upon the tool accessing it? I had intended to use a single Chado
 > instance as the data store and "hang" all the tools (e.g., Apollo,
 > GBrowse / GBrowse_syn, Tripal, etc.) off it.

Well, we do it that way right now for a couple of reasons, some of which
may not be valid anymore:

1.) the Bio::DB::SeqFeature store backend (running on Postgres) is way
     faster than the Chado backend.  I don't know whether this is still
     true, I haven't tested the Chado backend in a while, and Scott's
     been working on it lately.

2.) We don't actually need the level of detail and tracking provided by
     Chado for many of the features that we display in GBrowse, we
     currently only load the official gene models, and
     pseudomolecules, scaffolds, and contigs, into Chado.  This keeps
     the size of our Chado DB down, making it easier to keep query
     performance up on our gene pages and so forth.


Rob

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Robert Buels
In reply to this post by Olen Vance Sluder Jr
On 04/18/2011 04:12 PM, Olen Vance Sluder Jr wrote:
> So Bio::Chado::Schema is a library that has to be used
> programmatically? Not a problem, but any chance there's a Python
> version? ;-)

Ah, you should make the SQLAlchemy equivalent of Bio::Chado::Schema
then, and push it to whatever Python's equivalent of CPAN is, and make
it a GMOD project.

Rob

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
In reply to this post by Olen Vance Sluder Jr
Well, after a little more study of the Sequence Ontology (SO) and the
Chado schema, I decided I can't precisely represent what I want in
Chado currently, i.e., a SO sequence_collection or reference_genome.
Though Don's recommendation has its attractions, I will go the route
of encoding the reference genome in the uniquename of the feature per
Rob as it gets me around the bug in Apollo too.

This does lead me to a question about extending the schema to store
information about a SO sequence_collection. Would such an extension
make sense as part of the existing Sequence module or a separate
module, e.g., Sequence_Collection? I'm leaning towards the latter and,
if it has utility beyond me, I can put together some DDL or an ERD for
comment.
--
Olen


On Mon, Apr 18, 2011 at 4:30 PM, Olen Vance Sluder Jr wrote:

> On Mon, Apr 18, 2011 at 1:50 PM, Robert Buels wrote:
>> On 04/18/2011 11:10 AM, Don Gilbert wrote:
>>> I've not done this, but think it would work with chado to handle multiple assemblies,
>>> of one species:  give each assembly a new organism/species ID/name.  Since all the
>>> chado features are tagged by organism id, that would let you go a simple route of
>>> not changing chromosome, feature IDs, but only the organism id.
>>
>> However, the downside of this is that you then have fake species in your
>> organism table.  If you wanted to, for example, query for a summary of
>> what features you have for a given organism, you would have to figure
>> out what those organism rows would be.
>>
>> Perhaps you would need some sort of way of grouping organisms in that
>> case.  I seem to remember that idea being brought up before.
>
> Don,
>
> I considered that approach based upon a comment in the GMOD wiki on
> the Organism module <http://gmod.org/wiki/Chado_Organism_Module>:
>
> "If a particular strain or subspecies is to be represented, this is
> appended onto the species name."
>
> I could consider each assembly a new "strain", but then I reconsidered
> for exactly Rob's reasoning. That's when I started to dig into the SO
> and came across CV terms for assemblies, golden_paths, etc., got
> really confused, and wrote my original email.
>
> The feature naming issue is also related to a bug in Apollo accessing
> Chado that was discussed at the recent GMOD spring training and
> subsequent email with Ed Lee where Apollo does not properly handle
> multiple organisms (or assemblies) with non-unique feature names.
>
> I'm unsure how this will all work as far as configuring GBrowse2, but
> I haven't dug into that yet.
> --
> Olen
>

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Andy Schroeder
Have you considered using the library module to store info about the
assemblies and use library_feature to link to the various features of
the assembly?

At FlyBase we're using these tables to store info about collections of
features some of which fall outside the usual sense of a library - this
allows us to store high level experimental info and other 'meta data'
that pertains to collections of features and might work for your purposes.

We've added a few tables to this module to allow more flexibility that
haven't yet made it into the gmod schema including:

library_expression
library_expressionprop
library_featureprop
library_relationship
library_relationship_pub

cheers,
Andy

On 4/21/11 11:17 AM, Olen Vance Sluder Jr wrote:

> Well, after a little more study of the Sequence Ontology (SO) and the
> Chado schema, I decided I can't precisely represent what I want in
> Chado currently, i.e., a SO sequence_collection or reference_genome.
> Though Don's recommendation has its attractions, I will go the route
> of encoding the reference genome in the uniquename of the feature per
> Rob as it gets me around the bug in Apollo too.
>
> This does lead me to a question about extending the schema to store
> information about a SO sequence_collection. Would such an extension
> make sense as part of the existing Sequence module or a separate
> module, e.g., Sequence_Collection? I'm leaning towards the latter and,
> if it has utility beyond me, I can put together some DDL or an ERD for
> comment.
> --
> Olen
>
>
> On Mon, Apr 18, 2011 at 4:30 PM, Olen Vance Sluder Jr wrote:
>> On Mon, Apr 18, 2011 at 1:50 PM, Robert Buels wrote:
>>> On 04/18/2011 11:10 AM, Don Gilbert wrote:
>>>> I've not done this, but think it would work with chado to handle multiple assemblies,
>>>> of one species:  give each assembly a new organism/species ID/name.  Since all the
>>>> chado features are tagged by organism id, that would let you go a simple route of
>>>> not changing chromosome, feature IDs, but only the organism id.
>>>
>>> However, the downside of this is that you then have fake species in your
>>> organism table.  If you wanted to, for example, query for a summary of
>>> what features you have for a given organism, you would have to figure
>>> out what those organism rows would be.
>>>
>>> Perhaps you would need some sort of way of grouping organisms in that
>>> case.  I seem to remember that idea being brought up before.
>>
>> Don,
>>
>> I considered that approach based upon a comment in the GMOD wiki on
>> the Organism module<http://gmod.org/wiki/Chado_Organism_Module>:
>>
>> "If a particular strain or subspecies is to be represented, this is
>> appended onto the species name."
>>
>> I could consider each assembly a new "strain", but then I reconsidered
>> for exactly Rob's reasoning. That's when I started to dig into the SO
>> and came across CV terms for assemblies, golden_paths, etc., got
>> really confused, and wrote my original email.
>>
>> The feature naming issue is also related to a bug in Apollo accessing
>> Chado that was discussed at the recent GMOD spring training and
>> subsequent email with Ed Lee where Apollo does not properly handle
>> multiple organisms (or assemblies) with non-unique feature names.
>>
>> I'm unsure how this will all work as far as configuring GBrowse2, but
>> I haven't dug into that yet.
>> --
>> Olen
>>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Naama Menda
In reply to this post by Olen Vance Sluder Jr
there's been a lot of talking on this list on how to  group different objects.
Projects, evidences, gene families, organisms, properties, and now sequence.

Probably a good idea to start a new chado module for grouping objects.

-Naama


On Thu, Apr 21, 2011 at 11:17 AM, Olen Vance Sluder Jr <[hidden email]> wrote:
Well, after a little more study of the Sequence Ontology (SO) and the
Chado schema, I decided I can't precisely represent what I want in
Chado currently, i.e., a SO sequence_collection or reference_genome.
Though Don's recommendation has its attractions, I will go the route
of encoding the reference genome in the uniquename of the feature per
Rob as it gets me around the bug in Apollo too.

This does lead me to a question about extending the schema to store
information about a SO sequence_collection. Would such an extension
make sense as part of the existing Sequence module or a separate
module, e.g., Sequence_Collection? I'm leaning towards the latter and,
if it has utility beyond me, I can put together some DDL or an ERD for
comment.
--
Olen


On Mon, Apr 18, 2011 at 4:30 PM, Olen Vance Sluder Jr wrote:
> On Mon, Apr 18, 2011 at 1:50 PM, Robert Buels wrote:
>> On 04/18/2011 11:10 AM, Don Gilbert wrote:
>>> I've not done this, but think it would work with chado to handle multiple assemblies,
>>> of one species:  give each assembly a new organism/species ID/name.  Since all the
>>> chado features are tagged by organism id, that would let you go a simple route of
>>> not changing chromosome, feature IDs, but only the organism id.
>>
>> However, the downside of this is that you then have fake species in your
>> organism table.  If you wanted to, for example, query for a summary of
>> what features you have for a given organism, you would have to figure
>> out what those organism rows would be.
>>
>> Perhaps you would need some sort of way of grouping organisms in that
>> case.  I seem to remember that idea being brought up before.
>
> Don,
>
> I considered that approach based upon a comment in the GMOD wiki on
> the Organism module <http://gmod.org/wiki/Chado_Organism_Module>:
>
> "If a particular strain or subspecies is to be represented, this is
> appended onto the species name."
>
> I could consider each assembly a new "strain", but then I reconsidered
> for exactly Rob's reasoning. That's when I started to dig into the SO
> and came across CV terms for assemblies, golden_paths, etc., got
> really confused, and wrote my original email.
>
> The feature naming issue is also related to a bug in Apollo accessing
> Chado that was discussed at the recent GMOD spring training and
> subsequent email with Ed Lee where Apollo does not properly handle
> multiple organisms (or assemblies) with non-unique feature names.
>
> I'm unsure how this will all work as far as configuring GBrowse2, but
> I haven't dug into that yet.
> --
> Olen
>

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Stephen Ficklin-3

I would consider each assembly an “analysis” so would it be best to use the analysisfeature table to group features together by their respective analysis (i.e. assembly)?

 

But in general… I’ve not been in on this topic until now, so forgive me if I’m stating something already brought up.  But for organizing items (e.g. properties, sequences organisms) into groups would it be best to use the relationship ontology?  Specifically the ‘contained_in’ term?

 

Stephen

 

From: Naama Menda [mailto:[hidden email]]
Sent: Thursday, April 21, 2011 11:43 AM
To: Olen Vance Sluder Jr
Cc: GMOD Schema List
Subject: Re: [Gmod-schema] Guidance on loading multiple assemblies, feature naming, etc.

 

there's been a lot of talking on this list on how to  group different objects.
Projects, evidences, gene families, organisms, properties, and now sequence.

Probably a good idea to start a new chado module for grouping objects.

-Naama

On Thu, Apr 21, 2011 at 11:17 AM, Olen Vance Sluder Jr <[hidden email]> wrote:

Well, after a little more study of the Sequence Ontology (SO) and the
Chado schema, I decided I can't precisely represent what I want in
Chado currently, i.e., a SO sequence_collection or reference_genome.
Though Don's recommendation has its attractions, I will go the route
of encoding the reference genome in the uniquename of the feature per
Rob as it gets me around the bug in Apollo too.

This does lead me to a question about extending the schema to store
information about a SO sequence_collection. Would such an extension
make sense as part of the existing Sequence module or a separate
module, e.g., Sequence_Collection? I'm leaning towards the latter and,
if it has utility beyond me, I can put together some DDL or an ERD for
comment.
--
Olen



On Mon, Apr 18, 2011 at 4:30 PM, Olen Vance Sluder Jr wrote:


> On Mon, Apr 18, 2011 at 1:50 PM, Robert Buels wrote:
>> On 04/18/2011 11:10 AM, Don Gilbert wrote:
>>> I've not done this, but think it would work with chado to handle multiple assemblies,
>>> of one species:  give each assembly a new organism/species ID/name.  Since all the
>>> chado features are tagged by organism id, that would let you go a simple route of
>>> not changing chromosome, feature IDs, but only the organism id.
>>
>> However, the downside of this is that you then have fake species in your
>> organism table.  If you wanted to, for example, query for a summary of
>> what features you have for a given organism, you would have to figure
>> out what those organism rows would be.
>>
>> Perhaps you would need some sort of way of grouping organisms in that
>> case.  I seem to remember that idea being brought up before.
>
> Don,
>
> I considered that approach based upon a comment in the GMOD wiki on
> the Organism module <http://gmod.org/wiki/Chado_Organism_Module>:
>
> "If a particular strain or subspecies is to be represented, this is
> appended onto the species name."
>
> I could consider each assembly a new "strain", but then I reconsidered
> for exactly Rob's reasoning. That's when I started to dig into the SO
> and came across CV terms for assemblies, golden_paths, etc., got
> really confused, and wrote my original email.
>
> The feature naming issue is also related to a bug in Apollo accessing
> Chado that was discussed at the recent GMOD spring training and
> subsequent email with Ed Lee where Apollo does not properly handle
> multiple organisms (or assemblies) with non-unique feature names.
>
> I'm unsure how this will all work as far as configuring GBrowse2, but
> I haven't dug into that yet.
> --
> Olen
>

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema

 


------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
In reply to this post by Andy Schroeder
On Thu, Apr 21, 2011 at 10:40 AM, Andy Schroeder wrote:

> Have you considered using the library module to store info about the
> assemblies and use library_feature to link to the various features of
> the assembly?
>
> At FlyBase we're using these tables to store info about collections of
> features some of which fall outside the usual sense of a library - this
> allows us to store high level experimental info and other 'meta data'
> that pertains to collections of features and might work for your purposes.
>
> We've added a few tables to this module to allow more flexibility that
> haven't yet made it into the gmod schema including:
>
> library_expression
> library_expressionprop
> library_featureprop
> library_relationship
> library_relationship_pub


Thanks, Andy. I had only given the Library module a cursory glance,
but I'll look at it more closely.
--
Olen

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
In reply to this post by Naama Menda
On Thu, Apr 21, 2011 at 10:43 AM, Naama Menda wrote:
> there's been a lot of talking on this list on how to  group different
> objects.
> Projects, evidences, gene families, organisms, properties, and now sequence.
>
> Probably a good idea to start a new chado module for grouping objects.

That makes a lot of sense to me: A more abstract representation of
collections would have more utility than something specifically tied
to the Sequence Ontology (SO) sequence_collection. Would the SO or
other ontologies be used to define the type of collection or is a new
collection ontology required?
--
Olen

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Scott Cain
In reply to this post by Robert Buels
Hi Rob and Olen,

The Chado adaptor will always be slower than SeqFeature::Store, unless
I write a sophisticated view that creates and stores BioPerl
SeqFeature objects in the Chado database (that is, completely recreate
the SeqFeature::Store schema in Chado).  The question for any given
user is whether they want to trade that slowness for running off the
same database that is used for other tasks.  For some people, that
answer is yes (and sometimes because they can throw enough computing
power at the problem that it doesn't matter), and for others its no.

Scott


On Mon, Apr 18, 2011 at 8:04 PM, Robert Buels <[hidden email]> wrote:

> On 04/18/2011 03:27 PM, Olen Vance Sluder Jr wrote:
>  > So you have multiple copies of data in different databases depending
>  > upon the tool accessing it? I had intended to use a single Chado
>  > instance as the data store and "hang" all the tools (e.g., Apollo,
>  > GBrowse / GBrowse_syn, Tripal, etc.) off it.
>
> Well, we do it that way right now for a couple of reasons, some of which
> may not be valid anymore:
>
> 1.) the Bio::DB::SeqFeature store backend (running on Postgres) is way
>     faster than the Chado backend.  I don't know whether this is still
>     true, I haven't tested the Chado backend in a while, and Scott's
>     been working on it lately.
>
> 2.) We don't actually need the level of detail and tracking provided by
>     Chado for many of the features that we display in GBrowse, we
>     currently only load the official gene models, and
>     pseudomolecules, scaffolds, and contigs, into Chado.  This keeps
>     the size of our Chado DB down, making it easier to keep query
>     performance up on our gene pages and so forth.
>
>
> Rob
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>



--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Olen Vance Sluder Jr
In reply to this post by Stephen Ficklin-3
On Thu, Apr 21, 2011 at 10:50 AM, Stephen Ficklin wrote:
> I would consider each assembly an “analysis” so would it be best to use the
> analysisfeature table to group features together by their respective
> analysis (i.e. assembly)?

Thanks, Stephen. I had not considered using the Companalysis module. I
will look more closely at it as well as Andy's recommendation of the
Library module.

> But in general… I’ve not been in on this topic until now, so forgive me if
> I’m stating something already brought up.  But for organizing items (e.g.
> properties, sequences organisms) into groups would it be best to use the
> relationship ontology?  Specifically the ‘contained_in’ term?

It hadn't come up yet, so a good point to me. Is that not the ontology
currently used to define the type of relationship in existing "linking
tables", e.g., feature_relationship?
--
Olen

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
Reply | Threaded
Open this post in threaded view
|

Re: Guidance on loading multiple assemblies, feature naming, etc.

Scott Cain
In reply to this post by Naama Menda
Hi Naama,

Interesting idea--how would you see that working?  Would there be a
"collections" module that would consist of any "thingies" from
somewhere else in the database (identified by table and table_id) and
a relationship term tying them to the collection_id that groups them
together?

Scott


On Thu, Apr 21, 2011 at 11:43 AM, Naama Menda <[hidden email]> wrote:

> there's been a lot of talking on this list on how to  group different
> objects.
> Projects, evidences, gene families, organisms, properties, and now sequence.
>
> Probably a good idea to start a new chado module for grouping objects.
>
> -Naama
>
>
> On Thu, Apr 21, 2011 at 11:17 AM, Olen Vance Sluder Jr <[hidden email]> wrote:
>>
>> Well, after a little more study of the Sequence Ontology (SO) and the
>> Chado schema, I decided I can't precisely represent what I want in
>> Chado currently, i.e., a SO sequence_collection or reference_genome.
>> Though Don's recommendation has its attractions, I will go the route
>> of encoding the reference genome in the uniquename of the feature per
>> Rob as it gets me around the bug in Apollo too.
>>
>> This does lead me to a question about extending the schema to store
>> information about a SO sequence_collection. Would such an extension
>> make sense as part of the existing Sequence module or a separate
>> module, e.g., Sequence_Collection? I'm leaning towards the latter and,
>> if it has utility beyond me, I can put together some DDL or an ERD for
>> comment.
>> --
>> Olen
>>
>>
>> On Mon, Apr 18, 2011 at 4:30 PM, Olen Vance Sluder Jr wrote:
>> > On Mon, Apr 18, 2011 at 1:50 PM, Robert Buels wrote:
>> >> On 04/18/2011 11:10 AM, Don Gilbert wrote:
>> >>> I've not done this, but think it would work with chado to handle
>> >>> multiple assemblies,
>> >>> of one species:  give each assembly a new organism/species ID/name.
>> >>>  Since all the
>> >>> chado features are tagged by organism id, that would let you go a
>> >>> simple route of
>> >>> not changing chromosome, feature IDs, but only the organism id.
>> >>
>> >> However, the downside of this is that you then have fake species in
>> >> your
>> >> organism table.  If you wanted to, for example, query for a summary of
>> >> what features you have for a given organism, you would have to figure
>> >> out what those organism rows would be.
>> >>
>> >> Perhaps you would need some sort of way of grouping organisms in that
>> >> case.  I seem to remember that idea being brought up before.
>> >
>> > Don,
>> >
>> > I considered that approach based upon a comment in the GMOD wiki on
>> > the Organism module <http://gmod.org/wiki/Chado_Organism_Module>:
>> >
>> > "If a particular strain or subspecies is to be represented, this is
>> > appended onto the species name."
>> >
>> > I could consider each assembly a new "strain", but then I reconsidered
>> > for exactly Rob's reasoning. That's when I started to dig into the SO
>> > and came across CV terms for assemblies, golden_paths, etc., got
>> > really confused, and wrote my original email.
>> >
>> > The feature naming issue is also related to a bug in Apollo accessing
>> > Chado that was discussed at the recent GMOD spring training and
>> > subsequent email with Ed Lee where Apollo does not properly handle
>> > multiple organisms (or assemblies) with non-unique feature names.
>> >
>> > I'm unsure how this will all work as far as configuring GBrowse2, but
>> > I haven't dug into that yet.
>> > --
>> > Olen
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Benefiting from Server Virtualization: Beyond Initial Workload
>> Consolidation -- Increasing the use of server virtualization is a top
>> priority.Virtualization can reduce costs, simplify management, and improve
>> application availability and disaster protection. Learn more about
>> boosting
>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>> _______________________________________________
>> Gmod-schema mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Gmod-schema mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-schema
>
>



--
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   scott at scottcain dot net
GMOD Coordinator (http://gmod.org/)                     216-392-3087
Ontario Institute for Cancer Research

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Gmod-schema mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-schema
12