From hlapp at gmx.net Mon Feb 11 20:56:08 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Tue, 12 Feb 2008 10:56:08 +0900 Subject: [BioSQL-l] imminent release Message-ID: Hi all, I am at the BioHackathon 2008 in Japan and Heikki (who is here too, and so are Mark, Richard, and Jan Christian) reminds me that BioSQL still isn't released and that the hackathon would present a nice opportunity to correct that. So I intend to push out a release during the next 4 days, and as soon as possible within these. Let me know if you feel that any specific outstanding issue should be addressed before a release. I was going to call the release 1.0. Let me know if you find that premature and what should be fixed before we can call it that. We expect in fact some Bio* interoperability documentation to come out of the hackathon. This would then be released in a 1.0.x series. Schema updates would be incorporated into a 1.1.x or higher series. My vote is to leave the PhyloDB module out of the 1.0 release, it is simply still in flux (and in fact we might make some changes to it here). Cheers, -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at uiuc.edu Mon Feb 11 21:22:52 2008 From: cjfields at uiuc.edu (Chris Fields) Date: Mon, 11 Feb 2008 20:22:52 -0600 Subject: [BioSQL-l] imminent release In-Reply-To: References: Message-ID: Fantastic news! I think having a 1.0 release ands some docs would help tremendously. As for any fixes at the hackathon: there are a number of bioperl-db- related bugs in Bugzilla that would be nice to get fixed, but I think a BioSQL 1.0 release is more important. chris On Feb 11, 2008, at 7:56 PM, Hilmar Lapp wrote: > Hi all, > > I am at the BioHackathon 2008 in Japan and Heikki (who is here too, > and so are Mark, Richard, and Jan Christian) reminds me that BioSQL > still isn't released and that the hackathon would present a nice > opportunity to correct that. > > So I intend to push out a release during the next 4 days, and as > soon as possible within these. Let me know if you feel that any > specific outstanding issue should be addressed before a release. > > I was going to call the release 1.0. Let me know if you find that > premature and what should be fixed before we can call it that. > > We expect in fact some Bio* interoperability documentation to come > out of the hackathon. This would then be released in a 1.0.x series. > > Schema updates would be incorporated into a 1.1.x or higher series. > My vote is to leave the PhyloDB module out of the 1.0 release, it is > simply still in flux (and in fact we might make some changes to it > here). > > Cheers, > > -hilmar > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l Christopher Fields Postdoctoral Researcher Lab of Dr. Robert Switzer Dept of Biochemistry University of Illinois Urbana-Champaign From raoul.bonnal at itb.cnr.it Mon Feb 11 21:52:45 2008 From: raoul.bonnal at itb.cnr.it (Raoul Jean Pierre Bonnal) Date: Tue, 12 Feb 2008 11:52:45 +0900 Subject: [BioSQL-l] imminent release In-Reply-To: References: Message-ID: <1202784765.11896.1.camel@Graco> Hey Hilmar I'am behind ya :-), Cool, I'll check bioruby implementation immediately Il giorno mar, 12/02/2008 alle 10.56 +0900, Hilmar Lapp ha scritto: > Hi all, > > I am at the BioHackathon 2008 in Japan and Heikki (who is here too, > and so are Mark, Richard, and Jan Christian) reminds me that BioSQL > still isn't released and that the hackathon would present a nice > opportunity to correct that. > > So I intend to push out a release during the next 4 days, and as soon > as possible within these. Let me know if you feel that any specific > outstanding issue should be addressed before a release. > > I was going to call the release 1.0. Let me know if you find that > premature and what should be fixed before we can call it that. > > We expect in fact some Bio* interoperability documentation to come > out of the hackathon. This would then be released in a 1.0.x series. > > Schema updates would be incorporated into a 1.1.x or higher series. > My vote is to leave the PhyloDB module out of the 1.0 release, it is > simply still in flux (and in fact we might make some changes to it > here). > > Cheers, > > -hilmar > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From andreas.destefani at ucd.ie Wed Feb 13 04:39:35 2008 From: andreas.destefani at ucd.ie (Andreas De Stefani) Date: Wed, 13 Feb 2008 09:39:35 +0000 Subject: [BioSQL-l] update DBSeqRecords Message-ID: <47B2BAD7.9000109@ucd.ie> Hi Guys, I was wondering if it is possible to update a single DBSeqRecord, without having to delete the whole sub datbase first... I am using BioPython and BioSQL and what I intend todo is to create a local "cache" for protein informations which i get from the web, and after a month or so i would like to re-fetch the info from the web and update the local protein information "cache" (which uses BioSQL). It basically will work like this: if the user requests information for a certain protein the program queries the local DB using the accession number and sees if there is information about the protein, if not (or if the protein is expired, ie older than a month) it gets the info from the web (expasy) and loads (updates the protein information in) the local database. However, is a update of a single protein entry possible? when inserting the same protein i get the following error: (, IntegrityError(1062, "Duplicate entry 'P08317-1-0' for key 2"), ) i am just using db.load(...) again, but maybe there is another way to update entries? Hope somebody can help me with this, thanks very much in advance! Andy From biopython at maubp.freeserve.co.uk Wed Feb 13 05:55:21 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Wed, 13 Feb 2008 10:55:21 +0000 Subject: [BioSQL-l] update DBSeqRecords In-Reply-To: <47B2BAD7.9000109@ucd.ie> References: <47B2BAD7.9000109@ucd.ie> Message-ID: <320fb6e00802130255h1041733ax9514a8d76ab3e68d@mail.gmail.com> On Feb 13, 2008 9:39 AM, Andreas De Stefani wrote: > Hi Guys, > > I was wondering if it is possible to update a single DBSeqRecord, > without having to delete the whole sub database first... Can't you do this?: (1) start a new transaction (2) delete the out of date sequence (3) load the new sequence, e.g. with Biopython's load (4) commit the transaction I guess Biopython could have a method added to do this for you... maybe update instead of load? By the way - what version of Biopython are you using with BioSQL? I've made quite a few changes in CVS and I would be keen for any heavy users to try this (ideally before we make the next release of Biopython). Peter From hlapp at gmx.net Wed Feb 13 08:09:11 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Wed, 13 Feb 2008 22:09:11 +0900 Subject: [BioSQL-l] update DBSeqRecords In-Reply-To: <47B2BAD7.9000109@ucd.ie> References: <47B2BAD7.9000109@ucd.ie> Message-ID: <6B2BB40A-8F6A-4757-8A3E-944759298144@gmx.net> As Peter says this is easily possible, simply delete the sequence (protein) first that you want to update and then reload it. This is also called the 'refresh' mode of updating. -hilmar On Feb 13, 2008, at 6:39 PM, Andreas De Stefani wrote: > Hi Guys, > > I was wondering if it is possible to update a single DBSeqRecord, > without having to delete the whole sub datbase first... > > I am using BioPython and BioSQL and what I intend todo is to create > a local "cache" for protein informations which i get from the web, > and after a month or so i would like to re-fetch the info from the > web and update the local protein information "cache" (which uses > BioSQL). > > It basically will work like this: > > if the user requests information for a certain protein the program > queries the local DB using the accession number and sees if there > is information about the protein, if not (or if the protein is > expired, ie older than a month) it gets the info from the web > (expasy) and loads (updates the protein information in) the local > database. However, is a update of a single protein entry possible? > when inserting the same protein i get the following error: > > (, IntegrityError(1062, > "Duplicate entry 'P08317-1-0' for key 2"), 0xd6b170>) > > i am just using db.load(...) again, but maybe there is another way > to update entries? > > Hope somebody can help me with this, thanks very much in advance! > > Andy > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Wed Feb 13 20:54:28 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 10:54:28 +0900 Subject: [BioSQL-l] update DBSeqRecords In-Reply-To: <47B32040.1040400@ucd.ie> References: <47B2BAD7.9000109@ucd.ie> <6B2BB40A-8F6A-4757-8A3E-944759298144@gmx.net> <47B32040.1040400@ucd.ie> Message-ID: <69A88D1B-4462-4669-BA44-FFF869947437@gmx.net> Andreas - I really don't know anything about Biopython (but many others on the list may, especially the Biopython list, which I'm cc'ing too). So - I'm passing this on to Biopythonians to respond. -hilmar On Feb 14, 2008, at 1:52 AM, Andreas De Stefani wrote: > Thanks Hilmar, > > I kind of figured this and i am just using the adaptor to execute > the sql statement to delete the entry. > I also noticed that i cannot access all the information via > biopython/biosql, i would like to show the comments for each entry > but i cant find any attribute in the DBSeqRecord to access this > information. Is this something which will be added in the near future? > > My workaround is to use the adaptor from the record and just > execute a sql query ... but that might not be the ideal way to do it!? > > thanks again, > > Andreas > > > > Hilmar Lapp wrote: >> As Peter says this is easily possible, simply delete the sequence >> (protein) first that you want to update and then reload it. >> >> This is also called the 'refresh' mode of updating. >> >> -hilmar >> >> On Feb 13, 2008, at 6:39 PM, Andreas De Stefani wrote: >> >>> Hi Guys, >>> >>> I was wondering if it is possible to update a single DBSeqRecord, >>> without having to delete the whole sub datbase first... >>> >>> I am using BioPython and BioSQL and what I intend todo is to >>> create a local "cache" for protein informations which i get from >>> the web, and after a month or so i would like to re-fetch the >>> info from the web and update the local protein information >>> "cache" (which uses BioSQL). >>> >>> It basically will work like this: >>> >>> if the user requests information for a certain protein the >>> program queries the local DB using the accession number and sees >>> if there is information about the protein, if not (or if the >>> protein is expired, ie older than a month) it gets the info from >>> the web (expasy) and loads (updates the protein information in) >>> the local database. However, is a update of a single protein >>> entry possible? when inserting the same protein i get the >>> following error: >>> >>> (, IntegrityError(1062, >>> "Duplicate entry 'P08317-1-0' for key 2"), >> 0xd6b170>) >>> >>> i am just using db.load(...) again, but maybe there is another >>> way to update entries? >>> >>> Hope somebody can help me with this, thanks very much in advance! >>> >>> Andy >>> _______________________________________________ >>> BioSQL-l mailing list >>> BioSQL-l at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/biosql-l >> > > > -- > Biontrack - bioinformatics solutions > e: andreas.destefani at biontrack.com > w: www.biontrack.com > t: +353 (0)1 716 3760 > f: +353 (0)1 716 3709 > m: +353 85 141 9941 -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Wed Feb 13 22:11:34 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 12:11:34 +0900 Subject: [BioSQL-l] PhyloDB module updates Message-ID: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> Hi all, I am proposing the following schema updates to the PhyloDB module. Though I have committed these already, PhyloDB is pre-alpha and still quite heavily evolving, so changes can be made relatively easily. o Added tables tree_dbxref and node_dbxref tables to allow storing identifiers and cross-references for trees and nodes. Columns: node_id 'The node to which the database corss-reference is being assigned.' dbxref_id 'The database cross-reference being assigned to the node.' term_id 'The type of the database cross-reference as a controlled vocabulary or ontology term. The type of a node identifier should be primary identifier.' And analogous for tree. o Renamed edge_attribute_value and node_attribute_value to use 'qualifier' instead of 'attribute', for the sake of consistency with the core schema (though attribute sounds like the better name). o Added tree_qualifier_value table to capture metadata for trees. Columns: tree_id 'The tree with which the metadata is being associated.' term_id 'The name of the metadate element as a term from a controlled vocabulary (or ontology).' value 'The value of the metadata element.' rank 'The index of the metadata value if there is more than one value for the same metadata element. If there is only one value, this may be left at the default of zero.' o Replaced 1-n relationships (foreign keys) between bioentry and node and taxon and node, respectively, with n-n relationships (association tables). If the alignment is concatenated on molecular data, there may be more than one sequence, and these may not necessarily be from the same taxon (e.g., they might be from subspecies). Columns: node_id 'The node to which the taxon is being linked.' taxon_id 'The taxon being linked to the node.' rank 'The index of this taxon within the list of taxa being linked to the node, if the order is significant. Typically, this will be used to represent the position of the respective sequence within the concatenated alignment, or the partition index.' o Added tree_root table to allow storing of multiple roots (e.g., as resulting from Bayesian analysis). A phylogenetic analysis might suggest several alternative root nodes, with possible probabilities. Columns: tree_id 'The tree for which the referenced node is a root node.' node_id 'The node that is a root for the referenced tree.' is_alternate 'True if the root note is the preferential (most likely) root node of the tree, and false otherwise.' significance 'The significance (such as likelihood, or posterior probability) with which the node is the root node. This only has meaning if the method used for reconstructing the tree calculates this value.' Also, as an aside, none of these changes are yet reflected (or supported) in any of the scripts that have been written against the schema. Once these changes are accepted I'll start working on that though, and I'll also write a migration script. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Thu Feb 14 02:01:16 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 16:01:16 +0900 Subject: [BioSQL-l] Fwd: derby biosql schema References: <93b45ca50802131939s3b535e75xf9c67ad5956698b8@mail.gmail.com> Message-ID: <8633F596-DDA1-4AB4-8A1D-1A07E1FAC16A@gmx.net> Thanks to Mark Schreiber, we now also have a BioSQL version for Apache Derby, the Java-embedded RDBMS. I've committed the schema DDL to svn. (Note that there is no PhyloDB module for this dialect yet.) Cheers, -hilmar Begin forwarded message: > From: "Mark Schreiber" > Date: February 14, 2008 12:39:12 PM JST > To: "Hilmar Lapp" > Subject: derby biosql schema > > Hi Hilmar - > > The following DDL SQL seems to be able to construct the BioSQL > database in Derby. It has the same table structure as post-gres. > Can you put it in CVS? > > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Thu Feb 14 02:20:58 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 16:20:58 +0900 Subject: [BioSQL-l] license In-Reply-To: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> Message-ID: <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> I realized that the license is probably one of the few things we really need to sort out before release (though voice your opinion if you feel that shouldn't hold anything up). I haven't ever followed up on this since Oct. My current summary is: - It seems that there aren't any objections to Artistic 2.0. - There don't seem to be issues with LGPL either. It feels a bit odd to me to apply a license that takes about 'library' and 'application' all the time to a relational model, though that might be just fine. Also, there is in fact program code (perl only so far) in the BioSQL repository, so LPGL is most definitely applicable at least to some parts. - I've also wondered about using Creative Commons by Attribution. At any rate, I think using one license for the program source code and another one for the schema definitions seems overkill or even silly - though do speak up if you feel differently. Does anyone have any thoughts or concerns about this? -hilmar On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: > BioPerl distros just changed to specifically allow Artistic and > GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is > released, but I'm not sure. > > For BioSQL I think any of the specific licenses you mention (GPL, > LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. > > chris > > On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: > >> I realized that BioSQL is licensed under "the same terms as Perl >> itself", and then references the Perl Artistic License. >> >> First of all, Perl has changed its licensing terms to allow the GPL >> as an alternative, and the Artistic License for Perl will be upgraded >> to v2.0. >> >> Aside from all that, I'm not sure that it makes all that much sense >> to couple the license terms to those of Perl. Maybe a more >> technology- >> neutral license would be more appropriate, such as the GPL alone, >> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >> Licence v2.0? >> >> LGPL: http://www.opensource.org/licenses/lgpl-license.php >> MIT: http://www.opensource.org/licenses/mit-license.php >> BSD: http://www.opensource.org/licenses/bsd-license.php >> Artistic 2.0: http://www.opensource.org/licenses/artistic- >> license-2.0.php >> >> No action is probably not an option (b/c issues with Artistic v1.0 >> and changes in Perl licensing). Any thoughts, opinions? >> >> -hilmar >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> >> >> >> _______________________________________________ >> BioSQL-l mailing list >> BioSQL-l at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/biosql-l > > Christopher Fields > Postdoctoral Researcher > Lab of Dr. Robert Switzer > Dept of Biochemistry > University of Illinois Urbana-Champaign > > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From biopython at maubp.freeserve.co.uk Thu Feb 14 05:56:35 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Thu, 14 Feb 2008 10:56:35 +0000 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> Message-ID: <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> On Thu, Feb 14, 2008 at 3:11 AM, Hilmar Lapp wrote: > Hi all, > > I am proposing the following schema updates to the PhyloDB module. > Though I have committed these already, PhyloDB is pre-alpha and still > quite heavily evolving, so changes can be made relatively easily. > ... I may be showing my ignorance here, but how does this affect the existing taxon ID tables in BioSQL? Or will it replace them? Thanks Peter From biopython at maubp.freeserve.co.uk Thu Feb 14 06:07:56 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Thu, 14 Feb 2008 11:07:56 +0000 Subject: [BioSQL-l] license In-Reply-To: <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> Message-ID: <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> [Sorry if you got this twice Hilmar, I forgot to include the mailing list the first time] On Thu, Feb 14, 2008 at 7:20 AM, Hilmar Lapp wrote: > I realized that the license is probably one of the few things we > really need to sort out before release (though voice your opinion if > you feel that shouldn't hold anything up). Have you read the very short and very liberal Biopython license? I assume that what ever you pick would be compatible... although probably much more restrictive: http://www.biopython.org/DIST/LICENSE On a related note, are the bits of Biopython that deal with BioSQL considered part of the Biopython Project, the BioSQL project, or both? The python modules themselves don't actually contain any license information but as they are all under Biopython in CVS, so I presume the Biopython license is implied. See: http://cvs.biopython.org/cgi-bin/viewcvs/viewcvs.cgi/biopython/BioSQL/?cvsroot=biopython Peter From hlapp at gmx.net Thu Feb 14 06:17:42 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 20:17:42 +0900 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> Message-ID: <96505F3A-9843-424F-993D-BE498369F176@gmx.net> On Feb 14, 2008, at 7:56 PM, Peter wrote: > On Thu, Feb 14, 2008 at 3:11 AM, Hilmar Lapp wrote: >> Hi all, >> >> I am proposing the following schema updates to the PhyloDB module. >> Though I have committed these already, PhyloDB is pre-alpha and >> still >> quite heavily evolving, so changes can be made relatively easily. >> ... > > I may be showing my ignorance here, but how does this affect the > existing taxon ID tables in BioSQL? Or will it replace them? It doesn't. The taxon (and taxon_name) tables are in the core schema, not in the phyloDB module. Though speaking of which, what has been bugging me lately is that they only provide for a single taxonomy to be used (presumably the one from NCBI, since one column expressly refer to the NCBI_taxon_ID. I've been thinking about suggesting to generalize that a little, but the backwards compatibility issues might just outweigh the benefits. However, there is no guarantee that a phylogenetic tree refers only to taxa that are also in the NCBI taxonomy, so in the long inaction also isn't really an option. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at uiuc.edu Thu Feb 14 08:26:15 2008 From: cjfields at uiuc.edu (Chris Fields) Date: Thu, 14 Feb 2008 07:26:15 -0600 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <96505F3A-9843-424F-993D-BE498369F176@gmx.net> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> <96505F3A-9843-424F-993D-BE498369F176@gmx.net> Message-ID: <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> On Feb 14, 2008, at 5:17 AM, Hilmar Lapp wrote: > > On Feb 14, 2008, at 7:56 PM, Peter wrote: > >> On Thu, Feb 14, 2008 at 3:11 AM, Hilmar Lapp wrote: >>> Hi all, >>> >>> I am proposing the following schema updates to the PhyloDB module. >>> Though I have committed these already, PhyloDB is pre-alpha and >>> still >>> quite heavily evolving, so changes can be made relatively easily. >>> ... >> >> I may be showing my ignorance here, but how does this affect the >> existing taxon ID tables in BioSQL? Or will it replace them? > > > It doesn't. The taxon (and taxon_name) tables are in the core > schema, not in the phyloDB module. > > Though speaking of which, what has been bugging me lately is that > they only provide for a single taxonomy to be used (presumably the > one from NCBI, since one column expressly refer to the > NCBI_taxon_ID. I've been thinking about suggesting to generalize > that a little, but the backwards compatibility issues might just > outweigh the benefits. > > However, there is no guarantee that a phylogenetic tree refers only > to taxa that are also in the NCBI taxonomy, so in the long inaction > also isn't really an option. > > -hilmar > -- I think it would be better to generalize it within the schema. Is there a way to indicate what taxonomy was used (NCBI, custom, etc)? chris From aaron.j.mackey at gsk.com Thu Feb 14 10:32:47 2008 From: aaron.j.mackey at gsk.com (aaron.j.mackey at gsk.com) Date: Thu, 14 Feb 2008 10:32:47 -0500 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> Message-ID: > > Though speaking of which, what has been bugging me lately is that > > they only provide for a single taxonomy to be used (presumably the > > one from NCBI, since one column expressly refer to the > > NCBI_taxon_ID. I've been thinking about suggesting to generalize > > that a little, but the backwards compatibility issues might just > > outweigh the benefits. One approach would be to reuse the existing ontology framework (and perhaps include a NCBI-taxonomy-specific "view" to recapitulate the existing taxon tables). This would have the added advantage of allowing DAG-like taxonomies. "taxon_id" foreign keys would then instead be "term_id" (too bad there's no such thing as column-level aliases/views). -Aaron From hlapp at gmx.net Sat Feb 16 10:59:14 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Sat, 16 Feb 2008 10:59:14 -0500 Subject: [BioSQL-l] license In-Reply-To: <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> Message-ID: <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> On Feb 14, 2008, at 8:07 PM, Peter wrote: > On Thu, Feb 14, 2008 at 7:20 AM, Hilmar Lapp wrote: >> I realized that the license is probably one of the few things we >> really need to sort out before release (though voice your opinion if >> you feel that shouldn't hold anything up). > > Have you read the very short and very liberal Biopython license? I > assume that what ever you pick would be compatible... although > probably much more restrictive: > > http://www.biopython.org/DIST/LICENSE Is this effectively the MIT license? > > On a related note, are the bits of Biopython that deal with BioSQL > considered part of the Biopython Project, the BioSQL project, or both? Funny you ask, I just pondered that question myself the other day. I guess de-facto the language bindings have been part of the toolkits, not part of BioSQL. I don't see a good reason to change that, and in fact from the viewpoint of maintenance they probably better remain part of the respective toolkits. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Mon Feb 18 15:47:27 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 15:47:27 -0500 Subject: [BioSQL-l] release plan Message-ID: <3E7BBC90-F04B-4E9E-B181-A2E1F8AC21AA@gmx.net> I put up a v1.0 release plan on the BioSQL wiki: http://www.biosql.org/wiki/Releases It is posted for your convenience below. Please let me know any comments or suggestions that you have. There are a few open questions in there, if anyone has any suggestions or ideas towards those that'd be highly welcome: #1 Is the Apache Derby version of the schema ready for inclusion in the release (i.e., should it be tested more thoroughly than it has been at the hackathon? I'm assuming it has been instantiated there?) #2 Does anyone know whether there is a risk of the HSQLDB version not working on current releases of HSQLDB (HyperSonic)? Has anyone tested this recently, or can someone on the list make this test (i.e., instantiate the schema on HSQLDB and see what happens)? Cheers, -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== 1. Update license for BioSQL and all its DDL and software scripts. 2. Rename biosql-ora to biosqldb-ora for consistency with the other schema versions 3. Regenerate HTML documentation from schema DDL (using sqlt) 4. Create biosql-release-1.0 branch. 5. Remove from biosql-release-1.0 branch all schema modules or versions and all scripts that aren't release-ready yet, or are not yet or no longer supported. This includes the following: * phylodb module DDLs * phylodb ERD * phy* scripts (depend on phylodb, and not up-to-date) * load_itis_taxonomy.pl, tree-precompute.pl scripts (depend on phylodb, and not up-to-date) * phylodb-topo-queries.sql (depends on phylodb) 6. Write release announcement. 7. Package BioSQL for release, upload to download site. 8. Release: * Add download and release link to wiki on front page (also add Downloads page ot sidebar). * Post announcement to biosql-l and news.open-bio.org. From hlapp at gmx.net Mon Feb 18 16:18:03 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 16:18:03 -0500 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> <96505F3A-9843-424F-993D-BE498369F176@gmx.net> <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> Message-ID: <826A7D4D-4E2C-4AC5-9357-A0A96648D1FA@gmx.net> On Feb 14, 2008, at 8:26 AM, Chris Fields wrote: > > On Feb 14, 2008, at 5:17 AM, Hilmar Lapp wrote: > >> >> [...] >> Though speaking of which, what has been bugging me lately is that >> they only provide for a single taxonomy to be used (presumably the >> one from NCBI, since one column expressly refer to the >> NCBI_taxon_ID. I've been thinking about suggesting to generalize >> that a little, but the backwards compatibility issues might just >> outweigh the benefits. >> [...] >> > I think it would be better to generalize it within the schema. Is > there a way to indicate what taxonomy was used (NCBI, custom, etc)? Not at present, it is the NCBI Taxonomy by convention (and as that is what GenBank/DDBJ/EMBL sequences will refer to). To represent that, the taxon table would in essence need to receive a foreign key to biodatabase to indicate the namespace (which would be NCBI Taxonomy by default), and to allow for multiple taxonomies (each in a different namespace). (Generalizing the NCBI_Taxon_ID column is easy - it would just be a generic Identifier.) -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Mon Feb 18 16:39:59 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 16:39:59 -0500 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: References: Message-ID: <2AEB543F-D230-4E66-BCF0-D3F70896E738@gmx.net> On Feb 14, 2008, at 10:32 AM, aaron.j.mackey at gsk.com wrote: >>> Though speaking of which, what has been bugging me lately is that >>> they only provide for a single taxonomy to be used (presumably the >>> one from NCBI, since one column expressly refer to the >>> NCBI_taxon_ID. I've been thinking about suggesting to generalize >>> that a little, but the backwards compatibility issues might just >>> outweigh the benefits. > > One approach would be to reuse the existing ontology framework (and > perhaps include a NCBI-taxonomy-specific "view" to recapitulate the > existing taxon tables). This would have the added advantage of > allowing > DAG-like taxonomies. Indeed that's a strong possibility too, and in fact for example the NCBI taxonomy can be downloaded from the OBO foundry in OBO format (and also in OWL I believe). We are also converting another taxonomy (Eschmayer's Catalog of Fishes) into an ontology (Teleost Taxonomy Ontology - TTO - can also be downloaded from the NCBO). That said, most taxonomies aren't (yet?) available as an ontology, and for the exercise of converting there are a couple of gotchas that require manual review of the result. Maybe the ideal level of support for this (i.e., when a taxonomy doesn't come as an ontology to begin with) would be in the toolkit (s), mapping from a taxonomy model (Bio::Taxonomy, or Bio::Tree, for example?) to the ontology model (Bio::Ontology). (This is mostly a stream of thoughts, not clear arguments one way or another.) > "taxon_id" foreign keys would then instead be > "term_id" (too bad there's no such thing as column-level aliases/ > views). Indeed. But there's more than that needed. For example, ranks would be extra relationships ('has_rank') that would need to be joined in. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Mon Feb 18 16:34:41 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 16:34:41 -0500 Subject: [BioSQL-l] biosql logo Message-ID: <79AF6B6A-DDBC-4976-8DC7-0DE613F4D648@gmx.net> If you've been visiting the BioSQL wiki you may have noticed that not only is there content all of a sudden, but also a logo. I've sent this to the list last week for feedback but apparently the email got held up or lost somewhere along the line so I'm sending it again here. I've concocted the logo in a nice Cafe a while ago - I know already that I'm not an artist, so save that comment; but if you have any suggestions for how to make it better, feedback would be much appreciated. You may notice that there is some detail that is entirely lost in the smaller version on the wiki - but maybe that detail is distracting anyway and shouldn't be there in the larger version either? As I said, I'm definitely not an artist, so I'd encourage anyone who is and feels insulted by my concoction to take another stab at it. Cheers, -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: BioSQL.png Type: image/png Size: 25121 bytes Desc: not available URL: From hlapp at gmx.net Mon Feb 18 17:51:53 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 17:51:53 -0500 Subject: [BioSQL-l] license In-Reply-To: <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> Message-ID: <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> I'll summarize my considerations over the last couple days here: - Artistic 2.0: * Pro: Most in line with BioPerl and Perl. * Con: Only in line with BioPerl and Perl. I.e., not used by any other relevant project. - LGPL v3.0: * Pro: Widely used and accepted. Has standardized disclaimer for file headers. Supported by the FSF. Used by Biojava already. * Con: Talks a lot about executable code and library code, which feels a bit odd for a SQL schema. - CC by Attribution: * Pro: Possibly the most appropriate for the IP behind the model. * Con: Would be rather unusual, not used by any Bio* project, and rarely used for sw projects - MIT license: * Pro: Short and sweet, the disclaimer is the license. A variant seems to be used by Biopython. * Con: Not sure this is expressly used by any Bio* project yet. Not entirely clear whether it isn't too liberal (but probably not). Using the principles of least surprise, widest support, and simplicity, my first vote would be for LGPL, followed by MIT. If you have a strong leaning one way or the other do let me know, but unless I hear otherwise I think the license question just needs to be settled in a reasonable and conscious way so we can move on to more important issues. So, if putting BioSQL under LGPL v3.0 makes you uncomfortable, speak now, or forever hold your peace :-) -hilmar On Feb 14, 2008, at 2:20 AM, Hilmar Lapp wrote: > I realized that the license is probably one of the few things we > really need to sort out before release (though voice your opinion > if you feel that shouldn't hold anything up). > > I haven't ever followed up on this since Oct. My current summary is: > > - It seems that there aren't any objections to Artistic 2.0. > > - There don't seem to be issues with LGPL either. It feels a bit > odd to me to apply a license that takes about 'library' and > 'application' all the time to a relational model, though that might > be just fine. Also, there is in fact program code (perl only so > far) in the BioSQL repository, so LPGL is most definitely > applicable at least to some parts. > > - I've also wondered about using Creative Commons by Attribution. > > At any rate, I think using one license for the program source code > and another one for the schema definitions seems overkill or even > silly - though do speak up if you feel differently. > > Does anyone have any thoughts or concerns about this? > > -hilmar > > On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: > >> BioPerl distros just changed to specifically allow Artistic and >> GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is >> released, but I'm not sure. >> >> For BioSQL I think any of the specific licenses you mention (GPL, >> LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. >> >> chris >> >> On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: >> >>> I realized that BioSQL is licensed under "the same terms as Perl >>> itself", and then references the Perl Artistic License. >>> >>> First of all, Perl has changed its licensing terms to allow the GPL >>> as an alternative, and the Artistic License for Perl will be >>> upgraded >>> to v2.0. >>> >>> Aside from all that, I'm not sure that it makes all that much sense >>> to couple the license terms to those of Perl. Maybe a more >>> technology- >>> neutral license would be more appropriate, such as the GPL alone, >>> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >>> Licence v2.0? >>> >>> LGPL: http://www.opensource.org/licenses/lgpl-license.php >>> MIT: http://www.opensource.org/licenses/mit-license.php >>> BSD: http://www.opensource.org/licenses/bsd-license.php >>> Artistic 2.0: http://www.opensource.org/licenses/artistic- >>> license-2.0.php >>> >>> No action is probably not an option (b/c issues with Artistic v1.0 >>> and changes in Perl licensing). Any thoughts, opinions? >>> >>> -hilmar >>> -- >>> =========================================================== >>> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >>> =========================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> BioSQL-l mailing list >>> BioSQL-l at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/biosql-l >> >> Christopher Fields >> Postdoctoral Researcher >> Lab of Dr. Robert Switzer >> Dept of Biochemistry >> University of Illinois Urbana-Champaign >> >> > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at uiuc.edu Mon Feb 18 18:25:52 2008 From: cjfields at uiuc.edu (Chris Fields) Date: Mon, 18 Feb 2008 17:25:52 -0600 Subject: [BioSQL-l] license In-Reply-To: <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> Message-ID: <008FADB3-AEC1-4749-86DA-700493C16206@uiuc.edu> +1 for LGPL 3. chris On Feb 18, 2008, at 4:51 PM, Hilmar Lapp wrote: > I'll summarize my considerations over the last couple days here: > > - Artistic 2.0: > * Pro: Most in line with BioPerl and Perl. > * Con: Only in line with BioPerl and Perl. I.e., not used by any > other relevant project. > > - LGPL v3.0: > * Pro: Widely used and accepted. Has standardized disclaimer for > file headers. Supported by the FSF. Used by Biojava already. > * Con: Talks a lot about executable code and library code, which > feels a bit odd for a SQL schema. > > - CC by Attribution: > * Pro: Possibly the most appropriate for the IP behind the model. > * Con: Would be rather unusual, not used by any Bio* project, and > rarely used for sw projects > > - MIT license: > * Pro: Short and sweet, the disclaimer is the license. A variant > seems to be used by Biopython. > * Con: Not sure this is expressly used by any Bio* project yet. Not > entirely clear whether it isn't too liberal (but probably not). > > Using the principles of least surprise, widest support, and > simplicity, my first vote would be for LGPL, followed by MIT. > > If you have a strong leaning one way or the other do let me know, > but unless I hear otherwise I think the license question just needs > to be settled in a reasonable and conscious way so we can move on to > more important issues. > > So, if putting BioSQL under LGPL v3.0 makes you uncomfortable, speak > now, or forever hold your peace :-) > > -hilmar > > > On Feb 14, 2008, at 2:20 AM, Hilmar Lapp wrote: > >> I realized that the license is probably one of the few things we >> really need to sort out before release (though voice your opinion >> if you feel that shouldn't hold anything up). >> >> I haven't ever followed up on this since Oct. My current summary is: >> >> - It seems that there aren't any objections to Artistic 2.0. >> >> - There don't seem to be issues with LGPL either. It feels a bit >> odd to me to apply a license that takes about 'library' and >> 'application' all the time to a relational model, though that might >> be just fine. Also, there is in fact program code (perl only so >> far) in the BioSQL repository, so LPGL is most definitely >> applicable at least to some parts. >> >> - I've also wondered about using Creative Commons by Attribution. >> >> At any rate, I think using one license for the program source code >> and another one for the schema definitions seems overkill or even >> silly - though do speak up if you feel differently. >> >> Does anyone have any thoughts or concerns about this? >> >> -hilmar >> >> On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: >> >>> BioPerl distros just changed to specifically allow Artistic and >>> GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is >>> released, but I'm not sure. >>> >>> For BioSQL I think any of the specific licenses you mention (GPL, >>> LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. >>> >>> chris >>> >>> On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: >>> >>>> I realized that BioSQL is licensed under "the same terms as Perl >>>> itself", and then references the Perl Artistic License. >>>> >>>> First of all, Perl has changed its licensing terms to allow the GPL >>>> as an alternative, and the Artistic License for Perl will be >>>> upgraded >>>> to v2.0. >>>> >>>> Aside from all that, I'm not sure that it makes all that much sense >>>> to couple the license terms to those of Perl. Maybe a more >>>> technology- >>>> neutral license would be more appropriate, such as the GPL alone, >>>> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >>>> Licence v2.0? >>>> >>>> LGPL: http://www.opensource.org/licenses/lgpl-license.php >>>> MIT: http://www.opensource.org/licenses/mit-license.php >>>> BSD: http://www.opensource.org/licenses/bsd-license.php >>>> Artistic 2.0: http://www.opensource.org/licenses/artistic- >>>> license-2.0.php >>>> >>>> No action is probably not an option (b/c issues with Artistic v1.0 >>>> and changes in Perl licensing). Any thoughts, opinions? >>>> >>>> -hilmar >>>> -- >>>> =========================================================== >>>> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >>>> =========================================================== >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> BioSQL-l mailing list >>>> BioSQL-l at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/biosql-l >>> >>> Christopher Fields >>> Postdoctoral Researcher >>> Lab of Dr. Robert Switzer >>> Dept of Biochemistry >>> University of Illinois Urbana-Champaign >>> >>> >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l Christopher Fields Postdoctoral Researcher Lab of Dr. Robert Switzer Dept of Biochemistry University of Illinois Urbana-Champaign From biopython at maubp.freeserve.co.uk Tue Feb 19 04:51:57 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Tue, 19 Feb 2008 09:51:57 +0000 Subject: [BioSQL-l] license In-Reply-To: <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> Message-ID: <320fb6e00802190151o37b5e343h2077f9a74ae86baa@mail.gmail.com> > > Have you read the very short and very liberal Biopython license? I > > assume that what ever you pick would be compatible... although > > probably much more restrictive: > > > > http://www.biopython.org/DIST/LICENSE > > Is this effectively the MIT license? Yes > > On a related note, are the bits of Biopython that deal with BioSQL > > considered part of the Biopython Project, the BioSQL project, or both? > > Funny you ask, I just pondered that question myself the other day. I > guess de-facto the language bindings have been part of the toolkits, > not part of BioSQL. I don't see a good reason to change that, and in > fact from the viewpoint of maintenance they probably better remain > part of the respective toolkits. OK, good. I'll get round to updating the headers in Biopython's BioSQL bindings. As to the licence for BioSQL (your later email), I personally would be happy with either of LGPL v3.0 or MIT. I suspect using the MIT licence would be a little more popular with industry (if they want to make any changes to the schema, which is probably fairly common). Peter From MEC at stowers-institute.org Tue Feb 19 09:42:47 2008 From: MEC at stowers-institute.org (Cook, Malcolm) Date: Tue, 19 Feb 2008 08:42:47 -0600 Subject: [BioSQL-l] malformed RSS in http://www.biosql.org/wiki/Special:Recentchanges In-Reply-To: <79AF6B6A-DDBC-4976-8DC7-0DE613F4D648@gmx.net> References: <79AF6B6A-DDBC-4976-8DC7-0DE613F4D648@gmx.net> Message-ID: Hilmar, In trying to subscribe to the RSS feed off your RecentChanges wiki page (http://www.biosql.org/wiki/Special:Recentchanges) I get this error: XML Parsing Error: xml declaration not at start of external entity Location: http://www.biosql.org/w/index.php?title=Special:Recentchanges&hideminor= 1&feed=rss Line Number 2, Column 1: ^ Can fix? Malcolm Cook Database Applications Manager - Bioinformatics Stowers Institute for Medical Research - Kansas City, Missouri PS - I like the logo.... From hlapp at gmx.net Tue Feb 19 13:57:50 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Tue, 19 Feb 2008 13:57:50 -0500 Subject: [BioSQL-l] license In-Reply-To: <320fb6e00802190151o37b5e343h2077f9a74ae86baa@mail.gmail.com> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> <320fb6e00802190151o37b5e343h2077f9a74ae86baa@mail.gmail.com> Message-ID: On Feb 19, 2008, at 4:51 AM, Peter wrote: > As to the licence for BioSQL (your later email), I personally would be > happy with either of LGPL v3.0 or MIT. I suspect using the MIT > licence would be a little more popular with industry (if they want to > make any changes to the schema, which is probably fairly common). The LGPL shouldn't stop them from doing that. In fact, neither would GPL, or AFAIK any of the open-source licenses - after all, the ability to modify existing code is one of the whole points about open source. What GPL would mandate (but LGPL doesn't) is that code linking to it that is redistributed also have the source code available. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Thu Feb 21 20:22:27 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 21 Feb 2008 20:22:27 -0500 Subject: [BioSQL-l] biosql-accelerators-pg.sql Message-ID: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> Does the last BioJava release (or anyone out there using an older release of BioJava) still use the code defined in sql/biosql- accelerators-pg.sql in BioSQL? ThomasD created this back in 2002. Even though I updated it now to be compatible with the current 1.0 core schema (which has been stable since 2004), I think I'll rather remove it from the release (and possibly from the repository) as it's extremely unlikely that someone is using it (it would not have worked with the schema since 2004). -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From markjschreiber at gmail.com Thu Feb 21 20:31:11 2008 From: markjschreiber at gmail.com (Mark Schreiber) Date: Fri, 22 Feb 2008 09:31:11 +0800 Subject: [BioSQL-l] biosql-accelerators-pg.sql In-Reply-To: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> References: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> Message-ID: <93b45ca50802211731m88fd421w4f6d6f7adede647b@mail.gmail.com> Hi - I don't think so. But it depends on our Hibernate ORM mapping. Best person to answer that is Richard. - Mark On Fri, Feb 22, 2008 at 9:22 AM, Hilmar Lapp wrote: > Does the last BioJava release (or anyone out there using an older > release of BioJava) still use the code defined in sql/biosql- > accelerators-pg.sql in BioSQL? > > ThomasD created this back in 2002. Even though I updated it now to be > compatible with the current 1.0 core schema (which has been stable > since 2004), I think I'll rather remove it from the release (and > possibly from the repository) as it's extremely unlikely that someone > is using it (it would not have worked with the schema since 2004). > > -hilmar > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l > From hlapp at gmx.net Thu Feb 21 22:25:31 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 21 Feb 2008 22:25:31 -0500 Subject: [BioSQL-l] license In-Reply-To: <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> Message-ID: <7FF4F6DF-F358-44E1-AC6D-F7EC01C2B0A4@gmx.net> Just FYI, I have changed the license to LGPL now. The BioSQL schema (including phylodb extension) is now licensed under LGPL, in all versions. There are a few perl scripts developed by Jamie Estill during last years Summer of Code that are (still) under Perl/Artistic license (but these won't be in the release since they depend on the phylodb extension). All perl scripts that will be in the 1.0 release are also under LGPL. -hilmar On Feb 18, 2008, at 5:51 PM, Hilmar Lapp wrote: > I'll summarize my considerations over the last couple days here: > > - Artistic 2.0: > * Pro: Most in line with BioPerl and Perl. > * Con: Only in line with BioPerl and Perl. I.e., not used by any > other relevant project. > > - LGPL v3.0: > * Pro: Widely used and accepted. Has standardized disclaimer for > file headers. Supported by the FSF. Used by Biojava already. > * Con: Talks a lot about executable code and library code, which > feels a bit odd for a SQL schema. > > - CC by Attribution: > * Pro: Possibly the most appropriate for the IP behind the model. > * Con: Would be rather unusual, not used by any Bio* project, and > rarely used for sw projects > > - MIT license: > * Pro: Short and sweet, the disclaimer is the license. A variant > seems to be used by Biopython. > * Con: Not sure this is expressly used by any Bio* project yet. > Not entirely clear whether it isn't too liberal (but probably not). > > Using the principles of least surprise, widest support, and > simplicity, my first vote would be for LGPL, followed by MIT. > > If you have a strong leaning one way or the other do let me know, > but unless I hear otherwise I think the license question just needs > to be settled in a reasonable and conscious way so we can move on > to more important issues. > > So, if putting BioSQL under LGPL v3.0 makes you uncomfortable, > speak now, or forever hold your peace :-) > > -hilmar > > > On Feb 14, 2008, at 2:20 AM, Hilmar Lapp wrote: > >> I realized that the license is probably one of the few things we >> really need to sort out before release (though voice your opinion >> if you feel that shouldn't hold anything up). >> >> I haven't ever followed up on this since Oct. My current summary is: >> >> - It seems that there aren't any objections to Artistic 2.0. >> >> - There don't seem to be issues with LGPL either. It feels a bit >> odd to me to apply a license that takes about 'library' and >> 'application' all the time to a relational model, though that >> might be just fine. Also, there is in fact program code (perl only >> so far) in the BioSQL repository, so LPGL is most definitely >> applicable at least to some parts. >> >> - I've also wondered about using Creative Commons by Attribution. >> >> At any rate, I think using one license for the program source code >> and another one for the schema definitions seems overkill or even >> silly - though do speak up if you feel differently. >> >> Does anyone have any thoughts or concerns about this? >> >> -hilmar >> >> On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: >> >>> BioPerl distros just changed to specifically allow Artistic and >>> GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is >>> released, but I'm not sure. >>> >>> For BioSQL I think any of the specific licenses you mention (GPL, >>> LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. >>> >>> chris >>> >>> On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: >>> >>>> I realized that BioSQL is licensed under "the same terms as Perl >>>> itself", and then references the Perl Artistic License. >>>> >>>> First of all, Perl has changed its licensing terms to allow the GPL >>>> as an alternative, and the Artistic License for Perl will be >>>> upgraded >>>> to v2.0. >>>> >>>> Aside from all that, I'm not sure that it makes all that much sense >>>> to couple the license terms to those of Perl. Maybe a more >>>> technology- >>>> neutral license would be more appropriate, such as the GPL alone, >>>> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >>>> Licence v2.0? >>>> >>>> LGPL: http://www.opensource.org/licenses/lgpl-license.php >>>> MIT: http://www.opensource.org/licenses/mit-license.php >>>> BSD: http://www.opensource.org/licenses/bsd-license.php >>>> Artistic 2.0: http://www.opensource.org/licenses/artistic- >>>> license-2.0.php >>>> >>>> No action is probably not an option (b/c issues with Artistic v1.0 >>>> and changes in Perl licensing). Any thoughts, opinions? >>>> >>>> -hilmar >>>> -- >>>> =========================================================== >>>> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >>>> =========================================================== >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> BioSQL-l mailing list >>>> BioSQL-l at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/biosql-l >>> >>> Christopher Fields >>> Postdoctoral Researcher >>> Lab of Dr. Robert Switzer >>> Dept of Biochemistry >>> University of Illinois Urbana-Champaign >>> >>> >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From holland at ebi.ac.uk Fri Feb 22 03:01:57 2008 From: holland at ebi.ac.uk (Richard Holland) Date: Fri, 22 Feb 2008 08:01:57 +0000 Subject: [BioSQL-l] biosql-accelerators-pg.sql In-Reply-To: <93b45ca50802211731m88fd421w4f6d6f7adede647b@mail.gmail.com> References: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> <93b45ca50802211731m88fd421w4f6d6f7adede647b@mail.gmail.com> Message-ID: <47BE8175.2060106@ebi.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I didn't even know it existed. So the answer is no, we don't use it any more. Mark Schreiber wrote: > Hi - > > I don't think so. But it depends on our Hibernate ORM mapping. Best > person to answer that is Richard. > > - Mark > > On Fri, Feb 22, 2008 at 9:22 AM, Hilmar Lapp wrote: >> Does the last BioJava release (or anyone out there using an older >> release of BioJava) still use the code defined in sql/biosql- >> accelerators-pg.sql in BioSQL? >> >> ThomasD created this back in 2002. Even though I updated it now to be >> compatible with the current 1.0 core schema (which has been stable >> since 2004), I think I'll rather remove it from the release (and >> possibly from the repository) as it's extremely unlikely that someone >> is using it (it would not have worked with the schema since 2004). >> >> -hilmar >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> >> _______________________________________________ >> BioSQL-l mailing list >> BioSQL-l at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/biosql-l >> > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l > - -- Richard Holland (BioMart) EMBL EBI, Wellcome Trust Genome Campus, Hinxton, Cambridgeshire CB10 1SD, UK Tel. +44 (0)1223 494416 http://www.biomart.org/ http://www.biojava.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHvoF14C5LeMEKA/QRAhFYAJ46to9TgnyRBJDFzps+aVBTMB0UoACeJDpn mQ8Oc59xGrQYMm9AF4degMk= =EF/K -----END PGP SIGNATURE----- From HLAPP at GMX.NET Fri Feb 22 23:50:54 2008 From: HLAPP at GMX.NET (Hilmar Lapp) Date: Fri, 22 Feb 2008 23:50:54 -0500 Subject: [BioSQL-l] branched off 1.0 release Message-ID: <103CF6AB-7D09-47A3-BEE0-34A6654A2DC9@GMX.NET> FYI, I branched off the v1.0 release to biosql-release-1-0. Any further fixes that should be in the 1.0 release now need to also be merged to the release branch. Before you make any change to the biosql-release-1-0 branch before the release is tagged please speak with me first. Making progress ... -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Sun Feb 24 11:59:52 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Sun, 24 Feb 2008 11:59:52 -0500 Subject: [BioSQL-l] bj and biosql oracle Message-ID: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> I made a few minor updates to the BioJava and BioSQL Oracle document in doc/bj_and_bsql_oracle_howto.htm. Richard or Mark - you initiated migrating schema documentation to the wiki (which I think is a good idea) - do you want to do this too with this document? In particular, the far majority of it is in no way specific to Biojava but actually pertains to how to instantiate the Oracle version of the schema, so could readily form the basis of a http:// biosql.org/wiki/Oracle page. I used to be the probably heaviest user of the Oracle version, but at present we run PostgreSQL as our main RDBMS platform (not b/c Oracle sucked, but b/c I'm at a different place). Are there any current users of the Oracle version on the list, heavy or light, who could run tests on occasion? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From Wiepert.Mathieu at mayo.edu Wed Feb 27 06:18:40 2008 From: Wiepert.Mathieu at mayo.edu (Wiepert, Mathieu) Date: Wed, 27 Feb 2008 05:18:40 -0600 Subject: [BioSQL-l] BioSQL uses In-Reply-To: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: Hi, It's great to this coming to release 1.0, thanks very much for this work. I was wondering if I may ask how different users take advantage of BioSQL in daily work. We have a number of pressing issues, many which need a database of sequence for which we can overlay SNP, gene exp., Array CGH, etc type data. This seems like it would be a great start upon which we can add additional location specific information or any other feature. What do others use it for, and how does BioSQL work for you? -mat From lpritc at scri.ac.uk Wed Feb 27 08:03:17 2008 From: lpritc at scri.ac.uk (Leighton Pritchard) Date: Wed, 27 Feb 2008 13:03:17 +0000 Subject: [BioSQL-l] BioSQL uses In-Reply-To: References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: <1204117397.3884.14.camel@lplinuxdev.scri.sari.ac.uk> Hi, On Wed, 2008-02-27 at 05:18 -0600, Wiepert, Mathieu wrote: > It's great to this coming to release 1.0, thanks very much for this > work. I was wondering if I may ask how different users take advantage > of BioSQL in daily work. [...] > What do others use it for, and how does BioSQL work for you? We use BioSQL in a database of comparative genomic data for prokaryotes. This involved a small extension of the schema to accommodate mutual relationships between seqfeatures, but essentially it's all BioSQL under the hood. L. -- Dr Leighton Pritchard B.Sc.(Hons) MRSC D131, Plant Pathology Programme, SCRI Errol Road, Invergowrie, Perth and Kinross, Scotland DD2 5DA e:lpritc at scri.ac.uk w:http://www.scri.ac.uk/staff/leightonpritchard gpg/pgp: 0xFEFC205C tel:+44(0)1382 562731 x2405 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ SCRI, Invergowrie, Dundee, DD2 5DA. The Scottish Crop Research Institute is a charitable company limited by guarantee. Registered in Scotland No: SC 29367. Recognised by the Inland Revenue as a Scottish Charity No: SC 006662. DISCLAIMER: This email is from the Scottish Crop Research Institute, but the views expressed by the sender are not necessarily the views of SCRI and its subsidiaries. This email and any files transmitted with it are confidential to the intended recipient at the e-mail address to which it has been addressed. It may not be disclosed or used by any other than that addressee. If you are not the intended recipient you are requested to preserve this confidentiality and you must not use, disclose, copy, print or rely on this e-mail in any way. Please notify postmaster at scri.ac.uk quoting the name of the sender and delete the email from your system. Although SCRI has taken reasonable precautions to ensure no viruses are present in this email, neither the Institute nor the sender accepts any responsibility for any viruses, and it is your responsibility to scan the email and the attachments (if any). From MEC at stowers-institute.org Wed Feb 27 11:14:46 2008 From: MEC at stowers-institute.org (Cook, Malcolm) Date: Wed, 27 Feb 2008 10:14:46 -0600 Subject: [BioSQL-l] BioSQL uses In-Reply-To: References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: this would made a great topic for a page at http://www.biosql.org/wiki/Main_Page Malcolm Cook Database Applications Manager - Bioinformatics Stowers Institute for Medical Research - Kansas City, Missouri > -----Original Message----- > From: biosql-l-bounces at lists.open-bio.org > [mailto:biosql-l-bounces at lists.open-bio.org] On Behalf Of > Wiepert, Mathieu > Sent: Wednesday, February 27, 2008 5:19 AM > To: BioSQL > Subject: [BioSQL-l] BioSQL uses > > Hi, > > It's great to this coming to release 1.0, thanks very much > for this work. I was wondering if I may ask how different > users take advantage of BioSQL in daily work. We have a > number of pressing issues, many which need a database of > sequence for which we can overlay SNP, gene exp., Array CGH, > etc type data. This seems like it would be a great start > upon which we can add additional location specific > information or any other feature. > > What do others use it for, and how does BioSQL work for you? > > -mat > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l > From dicknetherlands at gmail.com Mon Feb 25 05:47:09 2008 From: dicknetherlands at gmail.com (Richard Holland) Date: Mon, 25 Feb 2008 10:47:09 +0000 Subject: [BioSQL-l] bj and biosql oracle In-Reply-To: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: I think you should be able to copy-and-paste from our wiki to the BioSQL wiki where it really belongs, then remove it from ours. As you say, it has no BJ-specific content. I don't know of any actual Oracle users at present. I don't use it myself any more - Ensembl is a MySQL shop. cheers, Richard On 24/02/2008, Hilmar Lapp wrote: > I made a few minor updates to the BioJava and BioSQL Oracle document > in doc/bj_and_bsql_oracle_howto.htm. > > Richard or Mark - you initiated migrating schema documentation to the > wiki (which I think is a good idea) - do you want to do this too with > this document? > > In particular, the far majority of it is in no way specific to > Biojava but actually pertains to how to instantiate the Oracle > version of the schema, so could readily form the basis of a http:// > biosql.org/wiki/Oracle page. > > I used to be the probably heaviest user of the Oracle version, but at > present we run PostgreSQL as our main RDBMS platform (not b/c Oracle > sucked, but b/c I'm at a different place). Are there any current > users of the Oracle version on the list, heavy or light, who could > run tests on occasion? > > -hilmar > > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > From hlapp at gmx.net Tue Feb 12 01:56:08 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Tue, 12 Feb 2008 10:56:08 +0900 Subject: [BioSQL-l] imminent release Message-ID: Hi all, I am at the BioHackathon 2008 in Japan and Heikki (who is here too, and so are Mark, Richard, and Jan Christian) reminds me that BioSQL still isn't released and that the hackathon would present a nice opportunity to correct that. So I intend to push out a release during the next 4 days, and as soon as possible within these. Let me know if you feel that any specific outstanding issue should be addressed before a release. I was going to call the release 1.0. Let me know if you find that premature and what should be fixed before we can call it that. We expect in fact some Bio* interoperability documentation to come out of the hackathon. This would then be released in a 1.0.x series. Schema updates would be incorporated into a 1.1.x or higher series. My vote is to leave the PhyloDB module out of the 1.0 release, it is simply still in flux (and in fact we might make some changes to it here). Cheers, -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at uiuc.edu Tue Feb 12 02:22:52 2008 From: cjfields at uiuc.edu (Chris Fields) Date: Mon, 11 Feb 2008 20:22:52 -0600 Subject: [BioSQL-l] imminent release In-Reply-To: References: Message-ID: Fantastic news! I think having a 1.0 release ands some docs would help tremendously. As for any fixes at the hackathon: there are a number of bioperl-db- related bugs in Bugzilla that would be nice to get fixed, but I think a BioSQL 1.0 release is more important. chris On Feb 11, 2008, at 7:56 PM, Hilmar Lapp wrote: > Hi all, > > I am at the BioHackathon 2008 in Japan and Heikki (who is here too, > and so are Mark, Richard, and Jan Christian) reminds me that BioSQL > still isn't released and that the hackathon would present a nice > opportunity to correct that. > > So I intend to push out a release during the next 4 days, and as > soon as possible within these. Let me know if you feel that any > specific outstanding issue should be addressed before a release. > > I was going to call the release 1.0. Let me know if you find that > premature and what should be fixed before we can call it that. > > We expect in fact some Bio* interoperability documentation to come > out of the hackathon. This would then be released in a 1.0.x series. > > Schema updates would be incorporated into a 1.1.x or higher series. > My vote is to leave the PhyloDB module out of the 1.0 release, it is > simply still in flux (and in fact we might make some changes to it > here). > > Cheers, > > -hilmar > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l Christopher Fields Postdoctoral Researcher Lab of Dr. Robert Switzer Dept of Biochemistry University of Illinois Urbana-Champaign From raoul.bonnal at itb.cnr.it Tue Feb 12 02:52:45 2008 From: raoul.bonnal at itb.cnr.it (Raoul Jean Pierre Bonnal) Date: Tue, 12 Feb 2008 11:52:45 +0900 Subject: [BioSQL-l] imminent release In-Reply-To: References: Message-ID: <1202784765.11896.1.camel@Graco> Hey Hilmar I'am behind ya :-), Cool, I'll check bioruby implementation immediately Il giorno mar, 12/02/2008 alle 10.56 +0900, Hilmar Lapp ha scritto: > Hi all, > > I am at the BioHackathon 2008 in Japan and Heikki (who is here too, > and so are Mark, Richard, and Jan Christian) reminds me that BioSQL > still isn't released and that the hackathon would present a nice > opportunity to correct that. > > So I intend to push out a release during the next 4 days, and as soon > as possible within these. Let me know if you feel that any specific > outstanding issue should be addressed before a release. > > I was going to call the release 1.0. Let me know if you find that > premature and what should be fixed before we can call it that. > > We expect in fact some Bio* interoperability documentation to come > out of the hackathon. This would then be released in a 1.0.x series. > > Schema updates would be incorporated into a 1.1.x or higher series. > My vote is to leave the PhyloDB module out of the 1.0 release, it is > simply still in flux (and in fact we might make some changes to it > here). > > Cheers, > > -hilmar > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From andreas.destefani at ucd.ie Wed Feb 13 09:39:35 2008 From: andreas.destefani at ucd.ie (Andreas De Stefani) Date: Wed, 13 Feb 2008 09:39:35 +0000 Subject: [BioSQL-l] update DBSeqRecords Message-ID: <47B2BAD7.9000109@ucd.ie> Hi Guys, I was wondering if it is possible to update a single DBSeqRecord, without having to delete the whole sub datbase first... I am using BioPython and BioSQL and what I intend todo is to create a local "cache" for protein informations which i get from the web, and after a month or so i would like to re-fetch the info from the web and update the local protein information "cache" (which uses BioSQL). It basically will work like this: if the user requests information for a certain protein the program queries the local DB using the accession number and sees if there is information about the protein, if not (or if the protein is expired, ie older than a month) it gets the info from the web (expasy) and loads (updates the protein information in) the local database. However, is a update of a single protein entry possible? when inserting the same protein i get the following error: (, IntegrityError(1062, "Duplicate entry 'P08317-1-0' for key 2"), ) i am just using db.load(...) again, but maybe there is another way to update entries? Hope somebody can help me with this, thanks very much in advance! Andy From biopython at maubp.freeserve.co.uk Wed Feb 13 10:55:21 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Wed, 13 Feb 2008 10:55:21 +0000 Subject: [BioSQL-l] update DBSeqRecords In-Reply-To: <47B2BAD7.9000109@ucd.ie> References: <47B2BAD7.9000109@ucd.ie> Message-ID: <320fb6e00802130255h1041733ax9514a8d76ab3e68d@mail.gmail.com> On Feb 13, 2008 9:39 AM, Andreas De Stefani wrote: > Hi Guys, > > I was wondering if it is possible to update a single DBSeqRecord, > without having to delete the whole sub database first... Can't you do this?: (1) start a new transaction (2) delete the out of date sequence (3) load the new sequence, e.g. with Biopython's load (4) commit the transaction I guess Biopython could have a method added to do this for you... maybe update instead of load? By the way - what version of Biopython are you using with BioSQL? I've made quite a few changes in CVS and I would be keen for any heavy users to try this (ideally before we make the next release of Biopython). Peter From hlapp at gmx.net Wed Feb 13 13:09:11 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Wed, 13 Feb 2008 22:09:11 +0900 Subject: [BioSQL-l] update DBSeqRecords In-Reply-To: <47B2BAD7.9000109@ucd.ie> References: <47B2BAD7.9000109@ucd.ie> Message-ID: <6B2BB40A-8F6A-4757-8A3E-944759298144@gmx.net> As Peter says this is easily possible, simply delete the sequence (protein) first that you want to update and then reload it. This is also called the 'refresh' mode of updating. -hilmar On Feb 13, 2008, at 6:39 PM, Andreas De Stefani wrote: > Hi Guys, > > I was wondering if it is possible to update a single DBSeqRecord, > without having to delete the whole sub datbase first... > > I am using BioPython and BioSQL and what I intend todo is to create > a local "cache" for protein informations which i get from the web, > and after a month or so i would like to re-fetch the info from the > web and update the local protein information "cache" (which uses > BioSQL). > > It basically will work like this: > > if the user requests information for a certain protein the program > queries the local DB using the accession number and sees if there > is information about the protein, if not (or if the protein is > expired, ie older than a month) it gets the info from the web > (expasy) and loads (updates the protein information in) the local > database. However, is a update of a single protein entry possible? > when inserting the same protein i get the following error: > > (, IntegrityError(1062, > "Duplicate entry 'P08317-1-0' for key 2"), 0xd6b170>) > > i am just using db.load(...) again, but maybe there is another way > to update entries? > > Hope somebody can help me with this, thanks very much in advance! > > Andy > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Thu Feb 14 01:54:28 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 10:54:28 +0900 Subject: [BioSQL-l] update DBSeqRecords In-Reply-To: <47B32040.1040400@ucd.ie> References: <47B2BAD7.9000109@ucd.ie> <6B2BB40A-8F6A-4757-8A3E-944759298144@gmx.net> <47B32040.1040400@ucd.ie> Message-ID: <69A88D1B-4462-4669-BA44-FFF869947437@gmx.net> Andreas - I really don't know anything about Biopython (but many others on the list may, especially the Biopython list, which I'm cc'ing too). So - I'm passing this on to Biopythonians to respond. -hilmar On Feb 14, 2008, at 1:52 AM, Andreas De Stefani wrote: > Thanks Hilmar, > > I kind of figured this and i am just using the adaptor to execute > the sql statement to delete the entry. > I also noticed that i cannot access all the information via > biopython/biosql, i would like to show the comments for each entry > but i cant find any attribute in the DBSeqRecord to access this > information. Is this something which will be added in the near future? > > My workaround is to use the adaptor from the record and just > execute a sql query ... but that might not be the ideal way to do it!? > > thanks again, > > Andreas > > > > Hilmar Lapp wrote: >> As Peter says this is easily possible, simply delete the sequence >> (protein) first that you want to update and then reload it. >> >> This is also called the 'refresh' mode of updating. >> >> -hilmar >> >> On Feb 13, 2008, at 6:39 PM, Andreas De Stefani wrote: >> >>> Hi Guys, >>> >>> I was wondering if it is possible to update a single DBSeqRecord, >>> without having to delete the whole sub datbase first... >>> >>> I am using BioPython and BioSQL and what I intend todo is to >>> create a local "cache" for protein informations which i get from >>> the web, and after a month or so i would like to re-fetch the >>> info from the web and update the local protein information >>> "cache" (which uses BioSQL). >>> >>> It basically will work like this: >>> >>> if the user requests information for a certain protein the >>> program queries the local DB using the accession number and sees >>> if there is information about the protein, if not (or if the >>> protein is expired, ie older than a month) it gets the info from >>> the web (expasy) and loads (updates the protein information in) >>> the local database. However, is a update of a single protein >>> entry possible? when inserting the same protein i get the >>> following error: >>> >>> (, IntegrityError(1062, >>> "Duplicate entry 'P08317-1-0' for key 2"), >> 0xd6b170>) >>> >>> i am just using db.load(...) again, but maybe there is another >>> way to update entries? >>> >>> Hope somebody can help me with this, thanks very much in advance! >>> >>> Andy >>> _______________________________________________ >>> BioSQL-l mailing list >>> BioSQL-l at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/biosql-l >> > > > -- > Biontrack - bioinformatics solutions > e: andreas.destefani at biontrack.com > w: www.biontrack.com > t: +353 (0)1 716 3760 > f: +353 (0)1 716 3709 > m: +353 85 141 9941 -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Thu Feb 14 03:11:34 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 12:11:34 +0900 Subject: [BioSQL-l] PhyloDB module updates Message-ID: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> Hi all, I am proposing the following schema updates to the PhyloDB module. Though I have committed these already, PhyloDB is pre-alpha and still quite heavily evolving, so changes can be made relatively easily. o Added tables tree_dbxref and node_dbxref tables to allow storing identifiers and cross-references for trees and nodes. Columns: node_id 'The node to which the database corss-reference is being assigned.' dbxref_id 'The database cross-reference being assigned to the node.' term_id 'The type of the database cross-reference as a controlled vocabulary or ontology term. The type of a node identifier should be primary identifier.' And analogous for tree. o Renamed edge_attribute_value and node_attribute_value to use 'qualifier' instead of 'attribute', for the sake of consistency with the core schema (though attribute sounds like the better name). o Added tree_qualifier_value table to capture metadata for trees. Columns: tree_id 'The tree with which the metadata is being associated.' term_id 'The name of the metadate element as a term from a controlled vocabulary (or ontology).' value 'The value of the metadata element.' rank 'The index of the metadata value if there is more than one value for the same metadata element. If there is only one value, this may be left at the default of zero.' o Replaced 1-n relationships (foreign keys) between bioentry and node and taxon and node, respectively, with n-n relationships (association tables). If the alignment is concatenated on molecular data, there may be more than one sequence, and these may not necessarily be from the same taxon (e.g., they might be from subspecies). Columns: node_id 'The node to which the taxon is being linked.' taxon_id 'The taxon being linked to the node.' rank 'The index of this taxon within the list of taxa being linked to the node, if the order is significant. Typically, this will be used to represent the position of the respective sequence within the concatenated alignment, or the partition index.' o Added tree_root table to allow storing of multiple roots (e.g., as resulting from Bayesian analysis). A phylogenetic analysis might suggest several alternative root nodes, with possible probabilities. Columns: tree_id 'The tree for which the referenced node is a root node.' node_id 'The node that is a root for the referenced tree.' is_alternate 'True if the root note is the preferential (most likely) root node of the tree, and false otherwise.' significance 'The significance (such as likelihood, or posterior probability) with which the node is the root node. This only has meaning if the method used for reconstructing the tree calculates this value.' Also, as an aside, none of these changes are yet reflected (or supported) in any of the scripts that have been written against the schema. Once these changes are accepted I'll start working on that though, and I'll also write a migration script. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Thu Feb 14 07:01:16 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 16:01:16 +0900 Subject: [BioSQL-l] Fwd: derby biosql schema References: <93b45ca50802131939s3b535e75xf9c67ad5956698b8@mail.gmail.com> Message-ID: <8633F596-DDA1-4AB4-8A1D-1A07E1FAC16A@gmx.net> Thanks to Mark Schreiber, we now also have a BioSQL version for Apache Derby, the Java-embedded RDBMS. I've committed the schema DDL to svn. (Note that there is no PhyloDB module for this dialect yet.) Cheers, -hilmar Begin forwarded message: > From: "Mark Schreiber" > Date: February 14, 2008 12:39:12 PM JST > To: "Hilmar Lapp" > Subject: derby biosql schema > > Hi Hilmar - > > The following DDL SQL seems to be able to construct the BioSQL > database in Derby. It has the same table structure as post-gres. > Can you put it in CVS? > > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Thu Feb 14 07:20:58 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 16:20:58 +0900 Subject: [BioSQL-l] license In-Reply-To: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> Message-ID: <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> I realized that the license is probably one of the few things we really need to sort out before release (though voice your opinion if you feel that shouldn't hold anything up). I haven't ever followed up on this since Oct. My current summary is: - It seems that there aren't any objections to Artistic 2.0. - There don't seem to be issues with LGPL either. It feels a bit odd to me to apply a license that takes about 'library' and 'application' all the time to a relational model, though that might be just fine. Also, there is in fact program code (perl only so far) in the BioSQL repository, so LPGL is most definitely applicable at least to some parts. - I've also wondered about using Creative Commons by Attribution. At any rate, I think using one license for the program source code and another one for the schema definitions seems overkill or even silly - though do speak up if you feel differently. Does anyone have any thoughts or concerns about this? -hilmar On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: > BioPerl distros just changed to specifically allow Artistic and > GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is > released, but I'm not sure. > > For BioSQL I think any of the specific licenses you mention (GPL, > LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. > > chris > > On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: > >> I realized that BioSQL is licensed under "the same terms as Perl >> itself", and then references the Perl Artistic License. >> >> First of all, Perl has changed its licensing terms to allow the GPL >> as an alternative, and the Artistic License for Perl will be upgraded >> to v2.0. >> >> Aside from all that, I'm not sure that it makes all that much sense >> to couple the license terms to those of Perl. Maybe a more >> technology- >> neutral license would be more appropriate, such as the GPL alone, >> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >> Licence v2.0? >> >> LGPL: http://www.opensource.org/licenses/lgpl-license.php >> MIT: http://www.opensource.org/licenses/mit-license.php >> BSD: http://www.opensource.org/licenses/bsd-license.php >> Artistic 2.0: http://www.opensource.org/licenses/artistic- >> license-2.0.php >> >> No action is probably not an option (b/c issues with Artistic v1.0 >> and changes in Perl licensing). Any thoughts, opinions? >> >> -hilmar >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> >> >> >> _______________________________________________ >> BioSQL-l mailing list >> BioSQL-l at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/biosql-l > > Christopher Fields > Postdoctoral Researcher > Lab of Dr. Robert Switzer > Dept of Biochemistry > University of Illinois Urbana-Champaign > > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From biopython at maubp.freeserve.co.uk Thu Feb 14 10:56:35 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Thu, 14 Feb 2008 10:56:35 +0000 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> Message-ID: <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> On Thu, Feb 14, 2008 at 3:11 AM, Hilmar Lapp wrote: > Hi all, > > I am proposing the following schema updates to the PhyloDB module. > Though I have committed these already, PhyloDB is pre-alpha and still > quite heavily evolving, so changes can be made relatively easily. > ... I may be showing my ignorance here, but how does this affect the existing taxon ID tables in BioSQL? Or will it replace them? Thanks Peter From biopython at maubp.freeserve.co.uk Thu Feb 14 11:07:56 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Thu, 14 Feb 2008 11:07:56 +0000 Subject: [BioSQL-l] license In-Reply-To: <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> Message-ID: <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> [Sorry if you got this twice Hilmar, I forgot to include the mailing list the first time] On Thu, Feb 14, 2008 at 7:20 AM, Hilmar Lapp wrote: > I realized that the license is probably one of the few things we > really need to sort out before release (though voice your opinion if > you feel that shouldn't hold anything up). Have you read the very short and very liberal Biopython license? I assume that what ever you pick would be compatible... although probably much more restrictive: http://www.biopython.org/DIST/LICENSE On a related note, are the bits of Biopython that deal with BioSQL considered part of the Biopython Project, the BioSQL project, or both? The python modules themselves don't actually contain any license information but as they are all under Biopython in CVS, so I presume the Biopython license is implied. See: http://cvs.biopython.org/cgi-bin/viewcvs/viewcvs.cgi/biopython/BioSQL/?cvsroot=biopython Peter From hlapp at gmx.net Thu Feb 14 11:17:42 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 14 Feb 2008 20:17:42 +0900 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> Message-ID: <96505F3A-9843-424F-993D-BE498369F176@gmx.net> On Feb 14, 2008, at 7:56 PM, Peter wrote: > On Thu, Feb 14, 2008 at 3:11 AM, Hilmar Lapp wrote: >> Hi all, >> >> I am proposing the following schema updates to the PhyloDB module. >> Though I have committed these already, PhyloDB is pre-alpha and >> still >> quite heavily evolving, so changes can be made relatively easily. >> ... > > I may be showing my ignorance here, but how does this affect the > existing taxon ID tables in BioSQL? Or will it replace them? It doesn't. The taxon (and taxon_name) tables are in the core schema, not in the phyloDB module. Though speaking of which, what has been bugging me lately is that they only provide for a single taxonomy to be used (presumably the one from NCBI, since one column expressly refer to the NCBI_taxon_ID. I've been thinking about suggesting to generalize that a little, but the backwards compatibility issues might just outweigh the benefits. However, there is no guarantee that a phylogenetic tree refers only to taxa that are also in the NCBI taxonomy, so in the long inaction also isn't really an option. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at uiuc.edu Thu Feb 14 13:26:15 2008 From: cjfields at uiuc.edu (Chris Fields) Date: Thu, 14 Feb 2008 07:26:15 -0600 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <96505F3A-9843-424F-993D-BE498369F176@gmx.net> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> <96505F3A-9843-424F-993D-BE498369F176@gmx.net> Message-ID: <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> On Feb 14, 2008, at 5:17 AM, Hilmar Lapp wrote: > > On Feb 14, 2008, at 7:56 PM, Peter wrote: > >> On Thu, Feb 14, 2008 at 3:11 AM, Hilmar Lapp wrote: >>> Hi all, >>> >>> I am proposing the following schema updates to the PhyloDB module. >>> Though I have committed these already, PhyloDB is pre-alpha and >>> still >>> quite heavily evolving, so changes can be made relatively easily. >>> ... >> >> I may be showing my ignorance here, but how does this affect the >> existing taxon ID tables in BioSQL? Or will it replace them? > > > It doesn't. The taxon (and taxon_name) tables are in the core > schema, not in the phyloDB module. > > Though speaking of which, what has been bugging me lately is that > they only provide for a single taxonomy to be used (presumably the > one from NCBI, since one column expressly refer to the > NCBI_taxon_ID. I've been thinking about suggesting to generalize > that a little, but the backwards compatibility issues might just > outweigh the benefits. > > However, there is no guarantee that a phylogenetic tree refers only > to taxa that are also in the NCBI taxonomy, so in the long inaction > also isn't really an option. > > -hilmar > -- I think it would be better to generalize it within the schema. Is there a way to indicate what taxonomy was used (NCBI, custom, etc)? chris From aaron.j.mackey at gsk.com Thu Feb 14 15:32:47 2008 From: aaron.j.mackey at gsk.com (aaron.j.mackey at gsk.com) Date: Thu, 14 Feb 2008 10:32:47 -0500 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> Message-ID: > > Though speaking of which, what has been bugging me lately is that > > they only provide for a single taxonomy to be used (presumably the > > one from NCBI, since one column expressly refer to the > > NCBI_taxon_ID. I've been thinking about suggesting to generalize > > that a little, but the backwards compatibility issues might just > > outweigh the benefits. One approach would be to reuse the existing ontology framework (and perhaps include a NCBI-taxonomy-specific "view" to recapitulate the existing taxon tables). This would have the added advantage of allowing DAG-like taxonomies. "taxon_id" foreign keys would then instead be "term_id" (too bad there's no such thing as column-level aliases/views). -Aaron From hlapp at gmx.net Sat Feb 16 15:59:14 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Sat, 16 Feb 2008 10:59:14 -0500 Subject: [BioSQL-l] license In-Reply-To: <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> Message-ID: <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> On Feb 14, 2008, at 8:07 PM, Peter wrote: > On Thu, Feb 14, 2008 at 7:20 AM, Hilmar Lapp wrote: >> I realized that the license is probably one of the few things we >> really need to sort out before release (though voice your opinion if >> you feel that shouldn't hold anything up). > > Have you read the very short and very liberal Biopython license? I > assume that what ever you pick would be compatible... although > probably much more restrictive: > > http://www.biopython.org/DIST/LICENSE Is this effectively the MIT license? > > On a related note, are the bits of Biopython that deal with BioSQL > considered part of the Biopython Project, the BioSQL project, or both? Funny you ask, I just pondered that question myself the other day. I guess de-facto the language bindings have been part of the toolkits, not part of BioSQL. I don't see a good reason to change that, and in fact from the viewpoint of maintenance they probably better remain part of the respective toolkits. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Mon Feb 18 20:47:27 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 15:47:27 -0500 Subject: [BioSQL-l] release plan Message-ID: <3E7BBC90-F04B-4E9E-B181-A2E1F8AC21AA@gmx.net> I put up a v1.0 release plan on the BioSQL wiki: http://www.biosql.org/wiki/Releases It is posted for your convenience below. Please let me know any comments or suggestions that you have. There are a few open questions in there, if anyone has any suggestions or ideas towards those that'd be highly welcome: #1 Is the Apache Derby version of the schema ready for inclusion in the release (i.e., should it be tested more thoroughly than it has been at the hackathon? I'm assuming it has been instantiated there?) #2 Does anyone know whether there is a risk of the HSQLDB version not working on current releases of HSQLDB (HyperSonic)? Has anyone tested this recently, or can someone on the list make this test (i.e., instantiate the schema on HSQLDB and see what happens)? Cheers, -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== 1. Update license for BioSQL and all its DDL and software scripts. 2. Rename biosql-ora to biosqldb-ora for consistency with the other schema versions 3. Regenerate HTML documentation from schema DDL (using sqlt) 4. Create biosql-release-1.0 branch. 5. Remove from biosql-release-1.0 branch all schema modules or versions and all scripts that aren't release-ready yet, or are not yet or no longer supported. This includes the following: * phylodb module DDLs * phylodb ERD * phy* scripts (depend on phylodb, and not up-to-date) * load_itis_taxonomy.pl, tree-precompute.pl scripts (depend on phylodb, and not up-to-date) * phylodb-topo-queries.sql (depends on phylodb) 6. Write release announcement. 7. Package BioSQL for release, upload to download site. 8. Release: * Add download and release link to wiki on front page (also add Downloads page ot sidebar). * Post announcement to biosql-l and news.open-bio.org. From hlapp at gmx.net Mon Feb 18 21:18:03 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 16:18:03 -0500 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> References: <4D78BD3D-C9EF-462F-888A-403EC7F906AA@gmx.net> <320fb6e00802140256u9a3c488ga5e9cfddb3257c63@mail.gmail.com> <96505F3A-9843-424F-993D-BE498369F176@gmx.net> <18B7F4A1-F094-4BAF-87B9-A67082F85817@uiuc.edu> Message-ID: <826A7D4D-4E2C-4AC5-9357-A0A96648D1FA@gmx.net> On Feb 14, 2008, at 8:26 AM, Chris Fields wrote: > > On Feb 14, 2008, at 5:17 AM, Hilmar Lapp wrote: > >> >> [...] >> Though speaking of which, what has been bugging me lately is that >> they only provide for a single taxonomy to be used (presumably the >> one from NCBI, since one column expressly refer to the >> NCBI_taxon_ID. I've been thinking about suggesting to generalize >> that a little, but the backwards compatibility issues might just >> outweigh the benefits. >> [...] >> > I think it would be better to generalize it within the schema. Is > there a way to indicate what taxonomy was used (NCBI, custom, etc)? Not at present, it is the NCBI Taxonomy by convention (and as that is what GenBank/DDBJ/EMBL sequences will refer to). To represent that, the taxon table would in essence need to receive a foreign key to biodatabase to indicate the namespace (which would be NCBI Taxonomy by default), and to allow for multiple taxonomies (each in a different namespace). (Generalizing the NCBI_Taxon_ID column is easy - it would just be a generic Identifier.) -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Mon Feb 18 21:39:59 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 16:39:59 -0500 Subject: [BioSQL-l] PhyloDB module updates In-Reply-To: References: Message-ID: <2AEB543F-D230-4E66-BCF0-D3F70896E738@gmx.net> On Feb 14, 2008, at 10:32 AM, aaron.j.mackey at gsk.com wrote: >>> Though speaking of which, what has been bugging me lately is that >>> they only provide for a single taxonomy to be used (presumably the >>> one from NCBI, since one column expressly refer to the >>> NCBI_taxon_ID. I've been thinking about suggesting to generalize >>> that a little, but the backwards compatibility issues might just >>> outweigh the benefits. > > One approach would be to reuse the existing ontology framework (and > perhaps include a NCBI-taxonomy-specific "view" to recapitulate the > existing taxon tables). This would have the added advantage of > allowing > DAG-like taxonomies. Indeed that's a strong possibility too, and in fact for example the NCBI taxonomy can be downloaded from the OBO foundry in OBO format (and also in OWL I believe). We are also converting another taxonomy (Eschmayer's Catalog of Fishes) into an ontology (Teleost Taxonomy Ontology - TTO - can also be downloaded from the NCBO). That said, most taxonomies aren't (yet?) available as an ontology, and for the exercise of converting there are a couple of gotchas that require manual review of the result. Maybe the ideal level of support for this (i.e., when a taxonomy doesn't come as an ontology to begin with) would be in the toolkit (s), mapping from a taxonomy model (Bio::Taxonomy, or Bio::Tree, for example?) to the ontology model (Bio::Ontology). (This is mostly a stream of thoughts, not clear arguments one way or another.) > "taxon_id" foreign keys would then instead be > "term_id" (too bad there's no such thing as column-level aliases/ > views). Indeed. But there's more than that needed. For example, ranks would be extra relationships ('has_rank') that would need to be joined in. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Mon Feb 18 21:34:41 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 16:34:41 -0500 Subject: [BioSQL-l] biosql logo Message-ID: <79AF6B6A-DDBC-4976-8DC7-0DE613F4D648@gmx.net> If you've been visiting the BioSQL wiki you may have noticed that not only is there content all of a sudden, but also a logo. I've sent this to the list last week for feedback but apparently the email got held up or lost somewhere along the line so I'm sending it again here. I've concocted the logo in a nice Cafe a while ago - I know already that I'm not an artist, so save that comment; but if you have any suggestions for how to make it better, feedback would be much appreciated. You may notice that there is some detail that is entirely lost in the smaller version on the wiki - but maybe that detail is distracting anyway and shouldn't be there in the larger version either? As I said, I'm definitely not an artist, so I'd encourage anyone who is and feels insulted by my concoction to take another stab at it. Cheers, -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: BioSQL.png Type: image/png Size: 25121 bytes Desc: not available URL: From hlapp at gmx.net Mon Feb 18 22:51:53 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Mon, 18 Feb 2008 17:51:53 -0500 Subject: [BioSQL-l] license In-Reply-To: <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> Message-ID: <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> I'll summarize my considerations over the last couple days here: - Artistic 2.0: * Pro: Most in line with BioPerl and Perl. * Con: Only in line with BioPerl and Perl. I.e., not used by any other relevant project. - LGPL v3.0: * Pro: Widely used and accepted. Has standardized disclaimer for file headers. Supported by the FSF. Used by Biojava already. * Con: Talks a lot about executable code and library code, which feels a bit odd for a SQL schema. - CC by Attribution: * Pro: Possibly the most appropriate for the IP behind the model. * Con: Would be rather unusual, not used by any Bio* project, and rarely used for sw projects - MIT license: * Pro: Short and sweet, the disclaimer is the license. A variant seems to be used by Biopython. * Con: Not sure this is expressly used by any Bio* project yet. Not entirely clear whether it isn't too liberal (but probably not). Using the principles of least surprise, widest support, and simplicity, my first vote would be for LGPL, followed by MIT. If you have a strong leaning one way or the other do let me know, but unless I hear otherwise I think the license question just needs to be settled in a reasonable and conscious way so we can move on to more important issues. So, if putting BioSQL under LGPL v3.0 makes you uncomfortable, speak now, or forever hold your peace :-) -hilmar On Feb 14, 2008, at 2:20 AM, Hilmar Lapp wrote: > I realized that the license is probably one of the few things we > really need to sort out before release (though voice your opinion > if you feel that shouldn't hold anything up). > > I haven't ever followed up on this since Oct. My current summary is: > > - It seems that there aren't any objections to Artistic 2.0. > > - There don't seem to be issues with LGPL either. It feels a bit > odd to me to apply a license that takes about 'library' and > 'application' all the time to a relational model, though that might > be just fine. Also, there is in fact program code (perl only so > far) in the BioSQL repository, so LPGL is most definitely > applicable at least to some parts. > > - I've also wondered about using Creative Commons by Attribution. > > At any rate, I think using one license for the program source code > and another one for the schema definitions seems overkill or even > silly - though do speak up if you feel differently. > > Does anyone have any thoughts or concerns about this? > > -hilmar > > On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: > >> BioPerl distros just changed to specifically allow Artistic and >> GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is >> released, but I'm not sure. >> >> For BioSQL I think any of the specific licenses you mention (GPL, >> LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. >> >> chris >> >> On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: >> >>> I realized that BioSQL is licensed under "the same terms as Perl >>> itself", and then references the Perl Artistic License. >>> >>> First of all, Perl has changed its licensing terms to allow the GPL >>> as an alternative, and the Artistic License for Perl will be >>> upgraded >>> to v2.0. >>> >>> Aside from all that, I'm not sure that it makes all that much sense >>> to couple the license terms to those of Perl. Maybe a more >>> technology- >>> neutral license would be more appropriate, such as the GPL alone, >>> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >>> Licence v2.0? >>> >>> LGPL: http://www.opensource.org/licenses/lgpl-license.php >>> MIT: http://www.opensource.org/licenses/mit-license.php >>> BSD: http://www.opensource.org/licenses/bsd-license.php >>> Artistic 2.0: http://www.opensource.org/licenses/artistic- >>> license-2.0.php >>> >>> No action is probably not an option (b/c issues with Artistic v1.0 >>> and changes in Perl licensing). Any thoughts, opinions? >>> >>> -hilmar >>> -- >>> =========================================================== >>> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >>> =========================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> BioSQL-l mailing list >>> BioSQL-l at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/biosql-l >> >> Christopher Fields >> Postdoctoral Researcher >> Lab of Dr. Robert Switzer >> Dept of Biochemistry >> University of Illinois Urbana-Champaign >> >> > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From cjfields at uiuc.edu Mon Feb 18 23:25:52 2008 From: cjfields at uiuc.edu (Chris Fields) Date: Mon, 18 Feb 2008 17:25:52 -0600 Subject: [BioSQL-l] license In-Reply-To: <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> Message-ID: <008FADB3-AEC1-4749-86DA-700493C16206@uiuc.edu> +1 for LGPL 3. chris On Feb 18, 2008, at 4:51 PM, Hilmar Lapp wrote: > I'll summarize my considerations over the last couple days here: > > - Artistic 2.0: > * Pro: Most in line with BioPerl and Perl. > * Con: Only in line with BioPerl and Perl. I.e., not used by any > other relevant project. > > - LGPL v3.0: > * Pro: Widely used and accepted. Has standardized disclaimer for > file headers. Supported by the FSF. Used by Biojava already. > * Con: Talks a lot about executable code and library code, which > feels a bit odd for a SQL schema. > > - CC by Attribution: > * Pro: Possibly the most appropriate for the IP behind the model. > * Con: Would be rather unusual, not used by any Bio* project, and > rarely used for sw projects > > - MIT license: > * Pro: Short and sweet, the disclaimer is the license. A variant > seems to be used by Biopython. > * Con: Not sure this is expressly used by any Bio* project yet. Not > entirely clear whether it isn't too liberal (but probably not). > > Using the principles of least surprise, widest support, and > simplicity, my first vote would be for LGPL, followed by MIT. > > If you have a strong leaning one way or the other do let me know, > but unless I hear otherwise I think the license question just needs > to be settled in a reasonable and conscious way so we can move on to > more important issues. > > So, if putting BioSQL under LGPL v3.0 makes you uncomfortable, speak > now, or forever hold your peace :-) > > -hilmar > > > On Feb 14, 2008, at 2:20 AM, Hilmar Lapp wrote: > >> I realized that the license is probably one of the few things we >> really need to sort out before release (though voice your opinion >> if you feel that shouldn't hold anything up). >> >> I haven't ever followed up on this since Oct. My current summary is: >> >> - It seems that there aren't any objections to Artistic 2.0. >> >> - There don't seem to be issues with LGPL either. It feels a bit >> odd to me to apply a license that takes about 'library' and >> 'application' all the time to a relational model, though that might >> be just fine. Also, there is in fact program code (perl only so >> far) in the BioSQL repository, so LPGL is most definitely >> applicable at least to some parts. >> >> - I've also wondered about using Creative Commons by Attribution. >> >> At any rate, I think using one license for the program source code >> and another one for the schema definitions seems overkill or even >> silly - though do speak up if you feel differently. >> >> Does anyone have any thoughts or concerns about this? >> >> -hilmar >> >> On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: >> >>> BioPerl distros just changed to specifically allow Artistic and >>> GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is >>> released, but I'm not sure. >>> >>> For BioSQL I think any of the specific licenses you mention (GPL, >>> LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. >>> >>> chris >>> >>> On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: >>> >>>> I realized that BioSQL is licensed under "the same terms as Perl >>>> itself", and then references the Perl Artistic License. >>>> >>>> First of all, Perl has changed its licensing terms to allow the GPL >>>> as an alternative, and the Artistic License for Perl will be >>>> upgraded >>>> to v2.0. >>>> >>>> Aside from all that, I'm not sure that it makes all that much sense >>>> to couple the license terms to those of Perl. Maybe a more >>>> technology- >>>> neutral license would be more appropriate, such as the GPL alone, >>>> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >>>> Licence v2.0? >>>> >>>> LGPL: http://www.opensource.org/licenses/lgpl-license.php >>>> MIT: http://www.opensource.org/licenses/mit-license.php >>>> BSD: http://www.opensource.org/licenses/bsd-license.php >>>> Artistic 2.0: http://www.opensource.org/licenses/artistic- >>>> license-2.0.php >>>> >>>> No action is probably not an option (b/c issues with Artistic v1.0 >>>> and changes in Perl licensing). Any thoughts, opinions? >>>> >>>> -hilmar >>>> -- >>>> =========================================================== >>>> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >>>> =========================================================== >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> BioSQL-l mailing list >>>> BioSQL-l at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/biosql-l >>> >>> Christopher Fields >>> Postdoctoral Researcher >>> Lab of Dr. Robert Switzer >>> Dept of Biochemistry >>> University of Illinois Urbana-Champaign >>> >>> >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l Christopher Fields Postdoctoral Researcher Lab of Dr. Robert Switzer Dept of Biochemistry University of Illinois Urbana-Champaign From biopython at maubp.freeserve.co.uk Tue Feb 19 09:51:57 2008 From: biopython at maubp.freeserve.co.uk (Peter) Date: Tue, 19 Feb 2008 09:51:57 +0000 Subject: [BioSQL-l] license In-Reply-To: <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> Message-ID: <320fb6e00802190151o37b5e343h2077f9a74ae86baa@mail.gmail.com> > > Have you read the very short and very liberal Biopython license? I > > assume that what ever you pick would be compatible... although > > probably much more restrictive: > > > > http://www.biopython.org/DIST/LICENSE > > Is this effectively the MIT license? Yes > > On a related note, are the bits of Biopython that deal with BioSQL > > considered part of the Biopython Project, the BioSQL project, or both? > > Funny you ask, I just pondered that question myself the other day. I > guess de-facto the language bindings have been part of the toolkits, > not part of BioSQL. I don't see a good reason to change that, and in > fact from the viewpoint of maintenance they probably better remain > part of the respective toolkits. OK, good. I'll get round to updating the headers in Biopython's BioSQL bindings. As to the licence for BioSQL (your later email), I personally would be happy with either of LGPL v3.0 or MIT. I suspect using the MIT licence would be a little more popular with industry (if they want to make any changes to the schema, which is probably fairly common). Peter From MEC at stowers-institute.org Tue Feb 19 14:42:47 2008 From: MEC at stowers-institute.org (Cook, Malcolm) Date: Tue, 19 Feb 2008 08:42:47 -0600 Subject: [BioSQL-l] malformed RSS in http://www.biosql.org/wiki/Special:Recentchanges In-Reply-To: <79AF6B6A-DDBC-4976-8DC7-0DE613F4D648@gmx.net> References: <79AF6B6A-DDBC-4976-8DC7-0DE613F4D648@gmx.net> Message-ID: Hilmar, In trying to subscribe to the RSS feed off your RecentChanges wiki page (http://www.biosql.org/wiki/Special:Recentchanges) I get this error: XML Parsing Error: xml declaration not at start of external entity Location: http://www.biosql.org/w/index.php?title=Special:Recentchanges&hideminor= 1&feed=rss Line Number 2, Column 1: ^ Can fix? Malcolm Cook Database Applications Manager - Bioinformatics Stowers Institute for Medical Research - Kansas City, Missouri PS - I like the logo.... From hlapp at gmx.net Tue Feb 19 18:57:50 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Tue, 19 Feb 2008 13:57:50 -0500 Subject: [BioSQL-l] license In-Reply-To: <320fb6e00802190151o37b5e343h2077f9a74ae86baa@mail.gmail.com> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <320fb6e00802140307p5c6fc0eei5df3c1b35a9e9685@mail.gmail.com> <2998AD08-B00B-4057-832D-7FC8F452AF52@gmx.net> <320fb6e00802190151o37b5e343h2077f9a74ae86baa@mail.gmail.com> Message-ID: On Feb 19, 2008, at 4:51 AM, Peter wrote: > As to the licence for BioSQL (your later email), I personally would be > happy with either of LGPL v3.0 or MIT. I suspect using the MIT > licence would be a little more popular with industry (if they want to > make any changes to the schema, which is probably fairly common). The LGPL shouldn't stop them from doing that. In fact, neither would GPL, or AFAIK any of the open-source licenses - after all, the ability to modify existing code is one of the whole points about open source. What GPL would mandate (but LGPL doesn't) is that code linking to it that is redistributed also have the source code available. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Fri Feb 22 01:22:27 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 21 Feb 2008 20:22:27 -0500 Subject: [BioSQL-l] biosql-accelerators-pg.sql Message-ID: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> Does the last BioJava release (or anyone out there using an older release of BioJava) still use the code defined in sql/biosql- accelerators-pg.sql in BioSQL? ThomasD created this back in 2002. Even though I updated it now to be compatible with the current 1.0 core schema (which has been stable since 2004), I think I'll rather remove it from the release (and possibly from the repository) as it's extremely unlikely that someone is using it (it would not have worked with the schema since 2004). -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From markjschreiber at gmail.com Fri Feb 22 01:31:11 2008 From: markjschreiber at gmail.com (Mark Schreiber) Date: Fri, 22 Feb 2008 09:31:11 +0800 Subject: [BioSQL-l] biosql-accelerators-pg.sql In-Reply-To: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> References: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> Message-ID: <93b45ca50802211731m88fd421w4f6d6f7adede647b@mail.gmail.com> Hi - I don't think so. But it depends on our Hibernate ORM mapping. Best person to answer that is Richard. - Mark On Fri, Feb 22, 2008 at 9:22 AM, Hilmar Lapp wrote: > Does the last BioJava release (or anyone out there using an older > release of BioJava) still use the code defined in sql/biosql- > accelerators-pg.sql in BioSQL? > > ThomasD created this back in 2002. Even though I updated it now to be > compatible with the current 1.0 core schema (which has been stable > since 2004), I think I'll rather remove it from the release (and > possibly from the repository) as it's extremely unlikely that someone > is using it (it would not have worked with the schema since 2004). > > -hilmar > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l > From hlapp at gmx.net Fri Feb 22 03:25:31 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Thu, 21 Feb 2008 22:25:31 -0500 Subject: [BioSQL-l] license In-Reply-To: <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> References: <780BB4F4-343D-488F-A27D-D5D36014A3DF@uiuc.edu> <98234BD0-EC88-4380-AC72-B69E7AB0446B@gmx.net> <3FD9BD40-7DA8-4D41-A4BE-00744638A3AB@gmx.net> Message-ID: <7FF4F6DF-F358-44E1-AC6D-F7EC01C2B0A4@gmx.net> Just FYI, I have changed the license to LGPL now. The BioSQL schema (including phylodb extension) is now licensed under LGPL, in all versions. There are a few perl scripts developed by Jamie Estill during last years Summer of Code that are (still) under Perl/Artistic license (but these won't be in the release since they depend on the phylodb extension). All perl scripts that will be in the 1.0 release are also under LGPL. -hilmar On Feb 18, 2008, at 5:51 PM, Hilmar Lapp wrote: > I'll summarize my considerations over the last couple days here: > > - Artistic 2.0: > * Pro: Most in line with BioPerl and Perl. > * Con: Only in line with BioPerl and Perl. I.e., not used by any > other relevant project. > > - LGPL v3.0: > * Pro: Widely used and accepted. Has standardized disclaimer for > file headers. Supported by the FSF. Used by Biojava already. > * Con: Talks a lot about executable code and library code, which > feels a bit odd for a SQL schema. > > - CC by Attribution: > * Pro: Possibly the most appropriate for the IP behind the model. > * Con: Would be rather unusual, not used by any Bio* project, and > rarely used for sw projects > > - MIT license: > * Pro: Short and sweet, the disclaimer is the license. A variant > seems to be used by Biopython. > * Con: Not sure this is expressly used by any Bio* project yet. > Not entirely clear whether it isn't too liberal (but probably not). > > Using the principles of least surprise, widest support, and > simplicity, my first vote would be for LGPL, followed by MIT. > > If you have a strong leaning one way or the other do let me know, > but unless I hear otherwise I think the license question just needs > to be settled in a reasonable and conscious way so we can move on > to more important issues. > > So, if putting BioSQL under LGPL v3.0 makes you uncomfortable, > speak now, or forever hold your peace :-) > > -hilmar > > > On Feb 14, 2008, at 2:20 AM, Hilmar Lapp wrote: > >> I realized that the license is probably one of the few things we >> really need to sort out before release (though voice your opinion >> if you feel that shouldn't hold anything up). >> >> I haven't ever followed up on this since Oct. My current summary is: >> >> - It seems that there aren't any objections to Artistic 2.0. >> >> - There don't seem to be issues with LGPL either. It feels a bit >> odd to me to apply a license that takes about 'library' and >> 'application' all the time to a relational model, though that >> might be just fine. Also, there is in fact program code (perl only >> so far) in the BioSQL repository, so LPGL is most definitely >> applicable at least to some parts. >> >> - I've also wondered about using Creative Commons by Attribution. >> >> At any rate, I think using one license for the program source code >> and another one for the schema definitions seems overkill or even >> silly - though do speak up if you feel differently. >> >> Does anyone have any thoughts or concerns about this? >> >> -hilmar >> >> On Oct 1, 2007, at 8:15 AM, Chris Fields wrote: >> >>> BioPerl distros just changed to specifically allow Artistic and >>> GPL. I think Artistic v2 kicks in when Perl 5.10 or Perl6 is >>> released, but I'm not sure. >>> >>> For BioSQL I think any of the specific licenses you mention (GPL, >>> LGPL, BSD, Artistic 2) would be fine. I'm a fan of GPL myself. >>> >>> chris >>> >>> On Sep 30, 2007, at 5:24 PM, Hilmar Lapp wrote: >>> >>>> I realized that BioSQL is licensed under "the same terms as Perl >>>> itself", and then references the Perl Artistic License. >>>> >>>> First of all, Perl has changed its licensing terms to allow the GPL >>>> as an alternative, and the Artistic License for Perl will be >>>> upgraded >>>> to v2.0. >>>> >>>> Aside from all that, I'm not sure that it makes all that much sense >>>> to couple the license terms to those of Perl. Maybe a more >>>> technology- >>>> neutral license would be more appropriate, such as the GPL alone, >>>> LGPL, or simply MIT (or new BSD) license. Or just the Artistic >>>> Licence v2.0? >>>> >>>> LGPL: http://www.opensource.org/licenses/lgpl-license.php >>>> MIT: http://www.opensource.org/licenses/mit-license.php >>>> BSD: http://www.opensource.org/licenses/bsd-license.php >>>> Artistic 2.0: http://www.opensource.org/licenses/artistic- >>>> license-2.0.php >>>> >>>> No action is probably not an option (b/c issues with Artistic v1.0 >>>> and changes in Perl licensing). Any thoughts, opinions? >>>> >>>> -hilmar >>>> -- >>>> =========================================================== >>>> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >>>> =========================================================== >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> BioSQL-l mailing list >>>> BioSQL-l at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/biosql-l >>> >>> Christopher Fields >>> Postdoctoral Researcher >>> Lab of Dr. Robert Switzer >>> Dept of Biochemistry >>> University of Illinois Urbana-Champaign >>> >>> >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From holland at ebi.ac.uk Fri Feb 22 08:01:57 2008 From: holland at ebi.ac.uk (Richard Holland) Date: Fri, 22 Feb 2008 08:01:57 +0000 Subject: [BioSQL-l] biosql-accelerators-pg.sql In-Reply-To: <93b45ca50802211731m88fd421w4f6d6f7adede647b@mail.gmail.com> References: <9615F30D-DB56-4418-B195-BCD29FD6A766@gmx.net> <93b45ca50802211731m88fd421w4f6d6f7adede647b@mail.gmail.com> Message-ID: <47BE8175.2060106@ebi.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I didn't even know it existed. So the answer is no, we don't use it any more. Mark Schreiber wrote: > Hi - > > I don't think so. But it depends on our Hibernate ORM mapping. Best > person to answer that is Richard. > > - Mark > > On Fri, Feb 22, 2008 at 9:22 AM, Hilmar Lapp wrote: >> Does the last BioJava release (or anyone out there using an older >> release of BioJava) still use the code defined in sql/biosql- >> accelerators-pg.sql in BioSQL? >> >> ThomasD created this back in 2002. Even though I updated it now to be >> compatible with the current 1.0 core schema (which has been stable >> since 2004), I think I'll rather remove it from the release (and >> possibly from the repository) as it's extremely unlikely that someone >> is using it (it would not have worked with the schema since 2004). >> >> -hilmar >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : >> =========================================================== >> >> >> >> _______________________________________________ >> BioSQL-l mailing list >> BioSQL-l at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/biosql-l >> > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l > - -- Richard Holland (BioMart) EMBL EBI, Wellcome Trust Genome Campus, Hinxton, Cambridgeshire CB10 1SD, UK Tel. +44 (0)1223 494416 http://www.biomart.org/ http://www.biojava.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHvoF14C5LeMEKA/QRAhFYAJ46to9TgnyRBJDFzps+aVBTMB0UoACeJDpn mQ8Oc59xGrQYMm9AF4degMk= =EF/K -----END PGP SIGNATURE----- From HLAPP at GMX.NET Sat Feb 23 04:50:54 2008 From: HLAPP at GMX.NET (Hilmar Lapp) Date: Fri, 22 Feb 2008 23:50:54 -0500 Subject: [BioSQL-l] branched off 1.0 release Message-ID: <103CF6AB-7D09-47A3-BEE0-34A6654A2DC9@GMX.NET> FYI, I branched off the v1.0 release to biosql-release-1-0. Any further fixes that should be in the 1.0 release now need to also be merged to the release branch. Before you make any change to the biosql-release-1-0 branch before the release is tagged please speak with me first. Making progress ... -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From hlapp at gmx.net Sun Feb 24 16:59:52 2008 From: hlapp at gmx.net (Hilmar Lapp) Date: Sun, 24 Feb 2008 11:59:52 -0500 Subject: [BioSQL-l] bj and biosql oracle Message-ID: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> I made a few minor updates to the BioJava and BioSQL Oracle document in doc/bj_and_bsql_oracle_howto.htm. Richard or Mark - you initiated migrating schema documentation to the wiki (which I think is a good idea) - do you want to do this too with this document? In particular, the far majority of it is in no way specific to Biojava but actually pertains to how to instantiate the Oracle version of the schema, so could readily form the basis of a http:// biosql.org/wiki/Oracle page. I used to be the probably heaviest user of the Oracle version, but at present we run PostgreSQL as our main RDBMS platform (not b/c Oracle sucked, but b/c I'm at a different place). Are there any current users of the Oracle version on the list, heavy or light, who could run tests on occasion? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : =========================================================== From Wiepert.Mathieu at mayo.edu Wed Feb 27 11:18:40 2008 From: Wiepert.Mathieu at mayo.edu (Wiepert, Mathieu) Date: Wed, 27 Feb 2008 05:18:40 -0600 Subject: [BioSQL-l] BioSQL uses In-Reply-To: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: Hi, It's great to this coming to release 1.0, thanks very much for this work. I was wondering if I may ask how different users take advantage of BioSQL in daily work. We have a number of pressing issues, many which need a database of sequence for which we can overlay SNP, gene exp., Array CGH, etc type data. This seems like it would be a great start upon which we can add additional location specific information or any other feature. What do others use it for, and how does BioSQL work for you? -mat From lpritc at scri.ac.uk Wed Feb 27 13:03:17 2008 From: lpritc at scri.ac.uk (Leighton Pritchard) Date: Wed, 27 Feb 2008 13:03:17 +0000 Subject: [BioSQL-l] BioSQL uses In-Reply-To: References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: <1204117397.3884.14.camel@lplinuxdev.scri.sari.ac.uk> Hi, On Wed, 2008-02-27 at 05:18 -0600, Wiepert, Mathieu wrote: > It's great to this coming to release 1.0, thanks very much for this > work. I was wondering if I may ask how different users take advantage > of BioSQL in daily work. [...] > What do others use it for, and how does BioSQL work for you? We use BioSQL in a database of comparative genomic data for prokaryotes. This involved a small extension of the schema to accommodate mutual relationships between seqfeatures, but essentially it's all BioSQL under the hood. L. -- Dr Leighton Pritchard B.Sc.(Hons) MRSC D131, Plant Pathology Programme, SCRI Errol Road, Invergowrie, Perth and Kinross, Scotland DD2 5DA e:lpritc at scri.ac.uk w:http://www.scri.ac.uk/staff/leightonpritchard gpg/pgp: 0xFEFC205C tel:+44(0)1382 562731 x2405 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ SCRI, Invergowrie, Dundee, DD2 5DA. The Scottish Crop Research Institute is a charitable company limited by guarantee. Registered in Scotland No: SC 29367. Recognised by the Inland Revenue as a Scottish Charity No: SC 006662. DISCLAIMER: This email is from the Scottish Crop Research Institute, but the views expressed by the sender are not necessarily the views of SCRI and its subsidiaries. This email and any files transmitted with it are confidential to the intended recipient at the e-mail address to which it has been addressed. It may not be disclosed or used by any other than that addressee. If you are not the intended recipient you are requested to preserve this confidentiality and you must not use, disclose, copy, print or rely on this e-mail in any way. Please notify postmaster at scri.ac.uk quoting the name of the sender and delete the email from your system. Although SCRI has taken reasonable precautions to ensure no viruses are present in this email, neither the Institute nor the sender accepts any responsibility for any viruses, and it is your responsibility to scan the email and the attachments (if any). From MEC at stowers-institute.org Wed Feb 27 16:14:46 2008 From: MEC at stowers-institute.org (Cook, Malcolm) Date: Wed, 27 Feb 2008 10:14:46 -0600 Subject: [BioSQL-l] BioSQL uses In-Reply-To: References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: this would made a great topic for a page at http://www.biosql.org/wiki/Main_Page Malcolm Cook Database Applications Manager - Bioinformatics Stowers Institute for Medical Research - Kansas City, Missouri > -----Original Message----- > From: biosql-l-bounces at lists.open-bio.org > [mailto:biosql-l-bounces at lists.open-bio.org] On Behalf Of > Wiepert, Mathieu > Sent: Wednesday, February 27, 2008 5:19 AM > To: BioSQL > Subject: [BioSQL-l] BioSQL uses > > Hi, > > It's great to this coming to release 1.0, thanks very much > for this work. I was wondering if I may ask how different > users take advantage of BioSQL in daily work. We have a > number of pressing issues, many which need a database of > sequence for which we can overlay SNP, gene exp., Array CGH, > etc type data. This seems like it would be a great start > upon which we can add additional location specific > information or any other feature. > > What do others use it for, and how does BioSQL work for you? > > -mat > > _______________________________________________ > BioSQL-l mailing list > BioSQL-l at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biosql-l > From dicknetherlands at gmail.com Mon Feb 25 10:47:09 2008 From: dicknetherlands at gmail.com (Richard Holland) Date: Mon, 25 Feb 2008 10:47:09 +0000 Subject: [BioSQL-l] bj and biosql oracle In-Reply-To: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> References: <5C57BAC6-974F-4E75-93E6-36BE2A58E980@gmx.net> Message-ID: I think you should be able to copy-and-paste from our wiki to the BioSQL wiki where it really belongs, then remove it from ours. As you say, it has no BJ-specific content. I don't know of any actual Oracle users at present. I don't use it myself any more - Ensembl is a MySQL shop. cheers, Richard On 24/02/2008, Hilmar Lapp wrote: > I made a few minor updates to the BioJava and BioSQL Oracle document > in doc/bj_and_bsql_oracle_howto.htm. > > Richard or Mark - you initiated migrating schema documentation to the > wiki (which I think is a good idea) - do you want to do this too with > this document? > > In particular, the far majority of it is in no way specific to > Biojava but actually pertains to how to instantiate the Oracle > version of the schema, so could readily form the basis of a http:// > biosql.org/wiki/Oracle page. > > I used to be the probably heaviest user of the Oracle version, but at > present we run PostgreSQL as our main RDBMS platform (not b/c Oracle > sucked, but b/c I'm at a different place). Are there any current > users of the Oracle version on the list, heavy or light, who could > run tests on occasion? > > -hilmar > > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- hlapp at gmx dot net : > =========================================================== > > > >