gmane.science.biology.gmod.schema

Re: chado question BLAST

Scott Cain — 2013-05-16T18:01:36

Hi Krzysztof,

There is something about security and how callbacks are evaluated that I
can only hazily remember, but I think if you add

  require DBI;
  DBI->import;

Your callback might work.  I don't know about the structure of your data,
but I also wonder if the Feature target method might help, as in:

  $name = $feature->target->display_name;

I feel like that should work.

Scott



On Wed, May 15, 2013 at 7:13 PM, Krzysztof Lubieniecki <klubien< at >sfu.ca>wrote:

Re: chado question BLAST

Krzysztof Lubieniecki — 2013-05-15T23:13:49

Hi Scott, 
Our "name" column for the blast results in the feature table does not have any values and needs to be referenced to another feature_id through featureloc table to retrieve actual name.
To resolve the problem we tried to use the following subroutine in *.conf file:

[BAC ends]
feature        = match:blastn
glyph          = segments
no_arrows      = 1
base           = 0
label          = sub {

      my $feature = shift;
      my $feature_id = $feature;
                      my $dbh = DBI->connect('DBI:Pg:dbname=asalbasev0.7');
      my $sql = qq(SELECT f.name from feature f JOIN featureloc floc ON (f.feature_id=floc.srcfeature_id) JOIN cvterm t on (f.type_id=t.cvterm_id) JOIN feature f2 ON (floc.feature_id=f2.feature_id) WHERE floc.feature_id=? AND t.name='BAC_end';);
                      my $sqlQuery = $dbh->prepare($sql);

                      my $rv = $sqlQuery->execute($feature);
      my < at >bacNames = $rv->fetchrow_array();
      my $bacName = $bacNames[0];
              return $ba

Chado genomic rearangement

clement fanteria — 2013-05-15T14:35:26

Hello,

I'm trying to store genomic rearangement like insertion, deletion, CNV or trisomy in the Chado database.
I have some problems with the CNV and the trisomy where I want store something like a "gain" to express this genomic variation.

The feature and featureloc tables doesn't allow this kind of information. Unfortunately the section about the Genomic Rearrangements is empty for this specific genomic rearangement : 

http://gmod.org/wiki/Chado_Best_Practices#xxx_Genomic_Rearrangements


Thank you for your help

Clément
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: chado question BLAST

Scott Cain — 2013-05-15T14:12:56

Hi Krzysztof,

What are you trying to set the name to?  What callback have you tried in
the configuration file that hasn't worked?

Scott



On Tue, May 14, 2013 at 1:24 AM, Krzysztof Lubieniecki <klubien< at >sfu.ca>wrote:

Re: chado question BLAST

Krzysztof Lubieniecki — 2013-05-14T05:24:31

Hi Scott, 
As you suggested I start to use gmod-schema mailing list.
The data were loaded as GFF3 according "chado best practice - results from BLAST" , we do not use Tripal.
I was able to display blast results on Gbrowse but the problem I still have is the label - I can display only uniquenames. I can pull out appropriate name related to the uniquename using mysql query (table joining) but it does not work if I do it as a subroutine in Gbrowse.conf file. 

Thanks

Krzysztof






Hi Krzysztof, 

First let me suggest that we take this conversation to the Chado mailing list, gmod-schema< at >lists.sourceforge.net . Subsequent replies can trim Lincoln off the cc list and and add the schema mailing list. 

Do you knowhow the data were loaded? A typical way to load the data would be via GFF (where the blast reports were converted to GFF3). Another way would be via Tripal, but it doesn't like ASalBase uses Tripal. If you used GFF, the cigar string typically isn't saved, so the exact alignment generally can't be recove

Re: Assigning feature relationships in Chado

Akiff Manji — 2013-05-06T23:10:00

That's perfect.. Solved everything. Btw, really impressed with the prompt
responses.

Thanks again for your help

Akiff
On 2013-05-06 2:48 PM, "Akiff Manji" <akiff.manji< at >gmail.com> wrote:

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Assigning feature relationships in Chado

Scott Cain — 2013-05-06T21:18:10

Hi Akiff,

Generally, the only relationships that get created automatically by the GFF
bulk loader are those that are defined in the GFF file using the Parent and
Derives_from tags.  If all you want is a part_of relationship, you could
use the Parent tag to make that happen.  If you want something else, you
could use a custom tag (whose value would end up in featureprop) and then
write a pgsql function to make the changes after the loading is done.  If
you have Tripal, it is also possible that you could use the generic table
loader in Tripal to do it in one go, but I'm not sure.

Scott



On Mon, May 6, 2013 at 4:48 PM, Akiff Manji <akiff.manji< at >gmail.com> wrote:

Assigning feature relationships in Chado

Akiff Manji — 2013-05-06T20:48:00

Hi everyone,

I've recently put together a Chado database to store bacterial genome
sequences in the form of multi fasta files. I've been using the perl bulk
loader scripts (gmod_fasta2gff3.pl gmod_bulkoad_gff3.pl) to upload the
sequences to the database. Everything works pretty well and I'm able to tag
attributes into the feature property tables. In fact currently we have been
using only the feature prop table to assign contigs from an mfasta file to
a genome. This essentially creates the same name entry for every single
contig we upload for a particular genome.

I realize this is not the approach to be taking, and rather we should be
defining relationships according to the RDF model and the
feature_relationship table. My question is, how exactly can we add these
relationships on the sequence file uploads (ie. without having to later
define the relationships with SQL)? What is the usual approach to
implementing relationships within the Chado database? Is there a bulk
uploader that does this?

Cheers,

Akiff

Re: Proposed changes to map module

Siddhartha Basu — 2013-05-03T15:28:56

Hi Scott,
Somehow related and have some generic questions,
what's the current practice to submit changes to chado schema in
general. What generally goes to contrib section or add ons or plugins.
Say, if the changes are in the core table, should it go to contrib
section. And of course how do somebody submit changes/patches, which
repository.

thanks,
-siddhartha

On Thu, 02 May 2013, Scott Cain wrote:





------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

FW: Proposed changes to map module

Cannon, Ethalinda K [GDCBA] — 2013-05-03T13:57:09

Sorry, I sent the response below directly to Josh by accident but would like to see if there are additional reactions, so reposting to the list.

After some more talk amongst ourselves, we're proposing taking this a step further and making two changes to featurepos: 
  - add a type_id field
  - change the type of mappos to numeric

I think we could also accept the featureposprop solution that Sook uses, but would then like to see that table become part of the chado schema and rather than an add-on table that everyone who needs to store start and end genetic coordinates will have to create.

In either case, changing the type of featurepos.mappos may be advisable as one of our objectives is to be able to retrieve features within a range of coordinates, which will mean numeric comparisons. It sounds like there's a trade-off regarding the data type, with numeric fields being more accurate and arbitrary precision fields being the faster of the two. I suggest that while speed is desirable, accuracy is more importa

Re: Proposed changes to map module

Josh Goodman — 2013-05-03T01:38:37

Hi all,

My main concern was with changing the featureloc table.  That seems
like the least favorable of the three options for a variety of
reasons.  I can't really speak to the merits of the other two, since
we don't use the map module at FlyBase.  My only suggestion would be
to not use the float point type (double precision) in option 3, since
what you put in isn't necessarily what you get out.  We already have a
handful of these in Chado and I think we would be better off by not
perpetuating them if possible.

Cheers,
Josh

On Thu, May 2, 2013 at 6:55 PM, Scott Cain <scott< at >scottcain.net> wrote:

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

Re: Proposed changes to map module

Sook Jung — 2013-05-03T00:11:23

Hi,
We (in GDR, CottonGEN etc) use map module for genetic maps and we do it
another way which is similar to #2. We have a custome table featureposprop
and store positions like start, stop, and QTL peak.
I think, in general, adding prop table is better than changing the base
table since it has less chance of breaking anyone else's code who already
uses the table..
Sook


On Thu, May 2, 2013 at 1:52 PM, Cannon, Ethalinda K [GDCBA] <
ekcannon< at >iastate.edu> wrote:

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

Re: Proposed changes to map module

Scott Cain — 2013-05-02T22:55:58

Hi Josh,

Does FlyBase use the map module?  I think the main thing they'd like to do
is represent coordinates using inexact values (like cM).  I feel like this
ought to be done in the map module, but I don't know of a working example
of doing that.  Additionally, the map module itself is very poorly
documented :-/

Scott



On Thu, May 2, 2013 at 3:10 PM, Josh Goodman <jogoodma< at >indiana.edu> wrote:

Re: Proposed changes to map module

Josh Goodman — 2013-05-02T19:10:23

Hi Ethy, Naama and Steven,

How does the existing one to many relationship between feature and
featureloc not meet your needs for modeling ranges or multi genetic or
cytological positions?  In FlyBase, we have many features that have
multiple locations, so I'm not sure I understand what it is you are
trying to address.  Perhaps you can give us a use case?

What is your reason for wanting to convert fmin/fmax in featureloc
from an integer to a float?  Float types in PostgreSQL come with very
dire warnings about their use.

http://www.postgresql.org/docs/9.1/static/datatype-numeric.html#DATATYPE-FLOAT

8.1.3. Floating-Point Types
The data types real and double precision are inexact,
variable-precision numeric types....
Inexact means that some values cannot be converted exactly to the
internal format and are stored as approximations, so that storing and
retrieving a value might show slight discrepancies.
...
*Comparing two floating-point values for equality might not always
work as expected.*

That last stateme

Proposed changes to map module

Cannon, Ethalinda K [GDCBA] — 2013-05-02T17:52:09

Since storing a range, or multiple genetic or cytological positions per feature is so common, 
we'd like to propose one of the following changes:

1. Change data type for fmin and fmax in featureloc to float.

    + table is already set up for min/max coordinates
    - table is not tied to a featuremap and therefore coordinate unit is unknown

2. Add a field to existing featurepos, type_id, to indicate what sort of
   position (e.g. start, end).
   
    + takes advantage of existing table, minimal change, adding a field 
      shouldn't break existing code, views, triggers, et cetera.
    - ?

3. Create a new table, featureinterval with these fields:
     featureinterval_id
     featuremap_id (map set, to get coordinate units)
     feature_id (object feature being placed)
     srcfeature_id (target feature)
     startpos (double precision)
     endpos (double precision)
     
    + straight-forward to help newbies get started
    - duplicates some information already provided by featurepos table


Ethy Canno

Re: Saving QTL data in Chado

Siddhartha Basu — 2013-05-02T15:54:35

Hi,

On Wed, 01 May 2013, Cannon, Steven wrote:

It might break but i am not aware of any systematic or uniform way to get a
report/breakage of chado database triggers/functions/application code(other than
tripal). If its there somewhere then we need to run it or if its not
there we might need to have it to test all table modification/table
addition suggestions that comes up frequently.
Anyway, I would recommend to add any core changes as a contrib module or as
plugin that could be added on demand and should be available with core
chado release. And may be add a note to featureloc wiki page saying when
and why these changes could be applied.


thanks,
-siddhartha







------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minu

Re: Saving QTL data in Chado

Stephen Ficklin — 2013-05-02T13:57:33

Hi Steven,

As far as Tripal is concerned, it knows about each table in Chado as 
well as their fields and types.  Right now I don't think you would have 
problems with Tripal if you changed featureloc.fmin and featureloc.fmax 
to floats,  except if you want to use any of the Chado tables in Drupal 
Views.   Then you would also need to manually change the handlers for 
that field.   However,  I would not recommend changing any of the Chado 
tables because Tripal is programmed to handle each field by it's data 
type which may cause problems in the future.   Tripal supports creating 
of custom tables in Chado, through a web form (it's quite easy to do), 
and then treats these custom tables as if they are Chado tables with all 
the same functionality that Tripal gives to the Chado tables (support in 
Drupal Views, access to data in templates, interaction with API 
functions, etc.).   So, my suggestion would be to keep Chado as it is 
and if you need customizations  you can add custom tables specific to 
your ne

Re: Saving QTL data in Chado

Cannon, Steven — 2013-05-01T21:30:55

Hi all,

Naama is visiting here. Her suggestion is to change the constraint in featureloc to allow floats. That seems pretty straightforward, since markers really do seem like "features." Would this break things in Chado or Tripal?

Steven

From: Sook Jung <sookjc< at >gmail.com<mailto:sookjc< at >gmail.com>>
Date: Wednesday, May 1, 2013 3:05 PM
To: Ethalinda Cannon <ekcannon< at >iastate.edu<mailto:ekcannon< at >iastate.edu>>
Cc: GMOD Schema/Chado List <gmod-schema< at >lists.sourceforge.net<mailto:gmod-schema< at >lists.sourceforge.net>>
Subject: Re: [Gmod-schema] Saving QTL data in Chado

Hi,
We store the start/stop position in our custom table featureposprop.
The map_feature_id is for linkage group (map in CMap) and featuremap_id is for the map (map set as in CMap).
Cheers
Sook

On Wed, May 1, 2013 at 2:47 PM, Cannon, Ethalinda K [GDCBA] <ekcannon< at >iastate.edu<mailto:ekcannon< at >iastate.edu>> wrote:
Thanks Sook!

I realized I was planning to store cM values in featureloc, which holds integers, not floats. How then should one handle loc

Re: Saving QTL data in Chado

Sook Jung — 2013-05-01T20:05:15

Hi,
We store the start/stop position in our custom table featureposprop.
The map_feature_id is for linkage group (map in CMap) and featuremap_id is
for the map (map set as in CMap).
Cheers
Sook


On Wed, May 1, 2013 at 2:47 PM, Cannon, Ethalinda K [GDCBA] <
ekcannon< at >iastate.edu> wrote:

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1

Re: Saving QTL data in Chado

Cannon, Ethalinda K [GDCBA] — 2013-05-01T18:47:02

Thanks Sook! 

I realized I was planning to store cM values in featureloc, which holds integers, not floats. How then should one handle locations that are a range of cMs? (I'd prefer to not just multiple by 100.) This applies to both the linkage group maps and the QTL positions. The featurepos table records only one position where the featurerange takes feature ids (two for each end of the range), not cM values.

Looking more closely at featuremap and the map module I noted that featurepos appears to refer to a map represented by both featurepos.featuremap_id (a featuremap record) and featurepos.map_feature_id (a feature record). It seems that this means having records in two different tables that both define the same linkage group map ... which is considered to represent the actual linkage group map and which is adding information (or a hook to attach it to additional tables)?

Ethy


________________________________________
From: Sook Jung [sookjc< at >gmail.com]
Sent: Thursday, April 25, 2013 2:48 PM
To: Canno

Re: newbie help

Scott Cain — 2013-05-01T18:30:05

Hi Susanne,

I would suggest against using Chado for storing reads; I just don't think
you'd get much value from doing that.  Chado isn't really a database for
storing "raw materials" like reads; rather it is a data warehouse for
storing results in a safe and consistent way.  That's why you didn't find
any tutorials for importing fastq into Chado--I don't think anybody does
it.  People do import fasta, but generally only for larger features like
scaffolds or chromosomes or other assemblies, like from a transcriptome.
And when that sort of fasta is imported, its usually in the context of a
feature that is being created from GFF3, where the feature is fully defined
in GFF3 and the fasta is provided as "supplemental" information, like this:

scaffold1    .    scaffold    1    123456    .    .    .
ID=scaffold1;Name=scaffold1
##FASTA
atgcatgc....

Scott



On Wed, Apr 24, 2013 at 11:04 AM, Amelia Ireland <amelia.ireland< at >gmod.org>wrote: