From hlapp at drycafe.net Fri Aug 19 23:45:33 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Fri, 19 Aug 2011 22:45:33 -0500 Subject: [BioSQL-l] Gene Ontology get_secondary_ids (bioperl) In-Reply-To: <88996CC3-38DE-42A1-9279-32705D36E94C@sgul.ac.uk> References: <88996CC3-38DE-42A1-9279-32705D36E94C@sgul.ac.uk> Message-ID: Hi Adam - I'm not sure whether you've ever received a response to this - this and a bunch of other posts at that time fell through the cracks, sorry about that. Based on the code in bioperl-db, only dbxrefs and synonyms are stored at present, not secondary accessions. The module that does this is TermAdaptor.pm. -hilmar Sent with a tap. On Jul 26, 2011, at 2:15 PM, Adam Witney wrote: > > When loading the Gene Ontology (gene_ontology.1_2.obo using bioperl) into biosql, do secondary_ids ('xref', 'alt_id') get stored anyway? > > thanks > > adam > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l From hlapp at drycafe.net Fri Aug 19 23:38:51 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Fri, 19 Aug 2011 22:38:51 -0500 Subject: [BioSQL-l] How is is_circular recorded in BioSQL (by BioPerl)? In-Reply-To: <4E2D79D6.6020108@gmail.com> References: <4E2D5000.30305@gmail.com> <4E2D5314.5090107@gmail.com> <4E2D5BAC.8020001@gmail.com> <4E2D79D6.6020108@gmail.com> Message-ID: <59AF5708-AECD-4375-9EB8-6E79D4B21C26@drycafe.net> I realize I'm chiming in here late, but the below sums it up quite well. In fact, biosequence.alphabet column was originally (pre-2002) called molecule, and the BioPerl Genbank writer defaults to alphabet() if molecule() is not defined. -hilmar Sent with a tap. On Jul 25, 2011, at 9:12 AM, Roy Chaudhuri wrote: > As with the is_circular hack, you could store the molecule type by adding it as an annotation in the SequenceProcessor (it's stored as $seq->molecule by BioPerl). > > Actually, when round-tripping a GenBank file through BioSQL, the LOCUS line molecule type ends up in lower case, which makes me wonder if it is coming from alphabet in the biosequence table. From hlapp at drycafe.net Fri Aug 19 21:06:24 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Fri, 19 Aug 2011 20:06:24 -0500 Subject: [BioSQL-l] NOT NULL on seqfeature_qualifier_value.value Message-ID: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> There is a NOT NULL constraint on seqfeature_qualifier_value.value, which prevents simple ontology term associations to seqfeatures. The only other metadata association table in BioSQL that does this is location_qualifier_value. In the latter case there is arguably some sense to that (at least originally for locations the purpose of that table was pretty much to store the fuzzy location start/end properties), but for seqfeatures this looks like a bug to me. Any objections to or concerns with removing the NOT NULL constraint on that column? -hilmar Sent with a tap. From p.j.a.cock at googlemail.com Sat Aug 20 04:33:37 2011 From: p.j.a.cock at googlemail.com (Peter Cock) Date: Sat, 20 Aug 2011 09:33:37 +0100 Subject: [BioSQL-l] NOT NULL on seqfeature_qualifier_value.value In-Reply-To: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> References: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> Message-ID: On Sat, Aug 20, 2011 at 2:06 AM, Hilmar Lapp wrote: > There is a NOT NULL constraint on seqfeature_qualifier_value.value, which prevents simple ontology term associations to seqfeatures. The only other metadata association table in BioSQL that does this is location_qualifier_value. In the latter case there is arguably some sense to that (at least originally for locations the purpose of that table was pretty much to store the fuzzy location start/end properties), but for seqfeatures this looks like a bug to me. > > Any objections to or concerns with removing the NOT NULL constraint on that column? > > -hilmar How are things like /psuedo and /trans_splicing from GenBank files currently stored in BioSQL? i.e. GenBank or EMBL feature table entries with no values. Would they also benefit from allowing a null value? Peter From hlapp at drycafe.net Sat Aug 20 07:38:14 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Sat, 20 Aug 2011 20:38:14 +0900 Subject: [BioSQL-l] NOT NULL on seqfeature_qualifier_value.value In-Reply-To: References: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> Message-ID: <96ED8835-C21A-4B3D-BFE7-5F2F2B27DEBD@drycafe.net> On Aug 20, 2011, at 5:33 PM, Peter Cock wrote: > How are things like /psuedo and /trans_splicing from GenBank files > currently stored in BioSQL? i.e. GenBank or EMBL feature table > entries with no values. Great question. In theory they should be simple value-less term associations. I was rather surprised actually to find the constraint in the current version (my first impulse was to say this must be an old version) and this is the first time it's been reported. Perhaps that means that most people are using the MySQL version (MySQL auto- converts NULL into an empty string for NOT NULL columns). -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at drycafe dot net : =========================================================== From hlapp at drycafe.net Sat Aug 20 03:45:33 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Fri, 19 Aug 2011 22:45:33 -0500 Subject: [BioSQL-l] Gene Ontology get_secondary_ids (bioperl) In-Reply-To: <88996CC3-38DE-42A1-9279-32705D36E94C@sgul.ac.uk> References: <88996CC3-38DE-42A1-9279-32705D36E94C@sgul.ac.uk> Message-ID: Hi Adam - I'm not sure whether you've ever received a response to this - this and a bunch of other posts at that time fell through the cracks, sorry about that. Based on the code in bioperl-db, only dbxrefs and synonyms are stored at present, not secondary accessions. The module that does this is TermAdaptor.pm. -hilmar Sent with a tap. On Jul 26, 2011, at 2:15 PM, Adam Witney wrote: > > When loading the Gene Ontology (gene_ontology.1_2.obo using bioperl) into biosql, do secondary_ids ('xref', 'alt_id') get stored anyway? > > thanks > > adam > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l From hlapp at drycafe.net Sat Aug 20 03:38:51 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Fri, 19 Aug 2011 22:38:51 -0500 Subject: [BioSQL-l] How is is_circular recorded in BioSQL (by BioPerl)? In-Reply-To: <4E2D79D6.6020108@gmail.com> References: <4E2D5000.30305@gmail.com> <4E2D5314.5090107@gmail.com> <4E2D5BAC.8020001@gmail.com> <4E2D79D6.6020108@gmail.com> Message-ID: <59AF5708-AECD-4375-9EB8-6E79D4B21C26@drycafe.net> I realize I'm chiming in here late, but the below sums it up quite well. In fact, biosequence.alphabet column was originally (pre-2002) called molecule, and the BioPerl Genbank writer defaults to alphabet() if molecule() is not defined. -hilmar Sent with a tap. On Jul 25, 2011, at 9:12 AM, Roy Chaudhuri wrote: > As with the is_circular hack, you could store the molecule type by adding it as an annotation in the SequenceProcessor (it's stored as $seq->molecule by BioPerl). > > Actually, when round-tripping a GenBank file through BioSQL, the LOCUS line molecule type ends up in lower case, which makes me wonder if it is coming from alphabet in the biosequence table. From hlapp at drycafe.net Sat Aug 20 01:06:24 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Fri, 19 Aug 2011 20:06:24 -0500 Subject: [BioSQL-l] NOT NULL on seqfeature_qualifier_value.value Message-ID: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> There is a NOT NULL constraint on seqfeature_qualifier_value.value, which prevents simple ontology term associations to seqfeatures. The only other metadata association table in BioSQL that does this is location_qualifier_value. In the latter case there is arguably some sense to that (at least originally for locations the purpose of that table was pretty much to store the fuzzy location start/end properties), but for seqfeatures this looks like a bug to me. Any objections to or concerns with removing the NOT NULL constraint on that column? -hilmar Sent with a tap. From p.j.a.cock at googlemail.com Sat Aug 20 08:33:37 2011 From: p.j.a.cock at googlemail.com (Peter Cock) Date: Sat, 20 Aug 2011 09:33:37 +0100 Subject: [BioSQL-l] NOT NULL on seqfeature_qualifier_value.value In-Reply-To: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> References: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> Message-ID: On Sat, Aug 20, 2011 at 2:06 AM, Hilmar Lapp wrote: > There is a NOT NULL constraint on seqfeature_qualifier_value.value, which prevents simple ontology term associations to seqfeatures. The only other metadata association table in BioSQL that does this is location_qualifier_value. In the latter case there is arguably some sense to that (at least originally for locations the purpose of that table was pretty much to store the fuzzy location start/end properties), but for seqfeatures this looks like a bug to me. > > Any objections to or concerns with removing the NOT NULL constraint on that column? > > -hilmar How are things like /psuedo and /trans_splicing from GenBank files currently stored in BioSQL? i.e. GenBank or EMBL feature table entries with no values. Would they also benefit from allowing a null value? Peter From hlapp at drycafe.net Sat Aug 20 11:38:14 2011 From: hlapp at drycafe.net (Hilmar Lapp) Date: Sat, 20 Aug 2011 20:38:14 +0900 Subject: [BioSQL-l] NOT NULL on seqfeature_qualifier_value.value In-Reply-To: References: <32E630F9-E47B-47BE-8022-CA7D618D4DB3@drycafe.net> Message-ID: <96ED8835-C21A-4B3D-BFE7-5F2F2B27DEBD@drycafe.net> On Aug 20, 2011, at 5:33 PM, Peter Cock wrote: > How are things like /psuedo and /trans_splicing from GenBank files > currently stored in BioSQL? i.e. GenBank or EMBL feature table > entries with no values. Great question. In theory they should be simple value-less term associations. I was rather surprised actually to find the constraint in the current version (my first impulse was to say this must be an old version) and this is the first time it's been reported. Perhaps that means that most people are using the MySQL version (MySQL auto- converts NULL into an empty string for NOT NULL columns). -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at drycafe dot net : ===========================================================