We are pleased to announce the availability of Biopython 1.53, a new stable release of the Biopython library, three months after the release of Biopython 1.52. This is our first release since migrating from CVS to git for source code control.

There have been some additions to our core objects – the Seq (and related UnknownSeq) objects gained upper and lower methods (like the string methods of the same name but alphabet aware) plus a new ungap method. The SeqFeature object now has an extract method to get the region of sequence it describes (useful for getting CDS nucleotide sequences from GenBank files). Also SeqRecord objects now support addition, giving a new SeqRecord with the combined sequence, all the SeqFeatures, and any common annotation.

SQLite support (built into Python 2.5+) was added to our BioSQL interface (Brad Chapman). This is still a little experimental as we are using a draft BioSQL SQLite schema, but this should be merged into the next BioSQL release.

Biopython now includes wrappers for the new NCBI BLAST C++ tools, which will be replacing the old NCBI “legacy” BLAST tools written in C. The plain text BLAST parser has been updated to cope as well. Nevertheless, we (and the NCBI) still recommend using the XML output for parsing.

Bio.Entrez includes the new (Jan 2010) DTD files from the NCBI for parsing MedLine/PubMed data.

The NCBI codon tables have been updated from version 3.4 to 3.9, which adds a few extra start codons, and a few new tables (Tables 16, 21, 22 and 23).

The restriction enzyme list in Bio.Restriction has been updated to the Nov 2009 release of REBASE.

The Bio.PDB parser and output code has been updated to understand the element column in ATOM and HETATM lines (based on patches contributed by Hongbo Zhu and Frederik Gwinner), and Bio.PDB.PDBList has been updated for recent changes to the PDB FTP site (Paul T. Bathen).

Finally, support for running Biopython under Jython (using the Java Virtual Machine) has been much improved (with input from Kyle Ellrott). Note that Jython does not support C code, and currently Jython does not parse DTD files (Jython Issue 1447; needed for the Bio.Entrez XML parser). However, most of the Biopython modules seem fine from testing with Jython 2.5.0 and 2.5.1.

Sources and Windows Installers are available from our downloads page.

Thanks to the Biopython development team and to everyone who has reported bugs or contributed patches since our last release.

(At least) 12 people contributed to this release, including 3 first timers:

• Bartek Wilczynski
• Brad Chapman
• Chris Lasher
• Cymon Cox
• Frank Kauff
• Frederik Gwinner (first contribution)
• Hongbo Zhu (first contribution)
• Kyle Ellrott
• Leighton Pritchard
• Michiel de Hoon
• Paul Bathen (first contribution)
• Peter Cock

This is a belated news entry announcing the second BioSQL v1.0 (code-named Tokyo) release, v1.0.1, which was made on August 2, 2008. It is available from the BioSQL downloads page.

This version of the schema should be fully backwards compatible with the v1.0.0 schema for nearly all software and queries. The only change is relaxing a column width constraint. Migration scripts are for those who want to simply upgrade their existing database.

In addition, the script load_ncbi_taxonomy.pl has been fixed to no longer require the taxon primary key and the NCBI taxon ID to be identical. The Bio* language bindings should not be affected by this change.

For full details, see Hilmar’s official announcement on the BioSQL mailing list

After a long wait and several earlier attempts, version 1.0.0 (code-named Tokyo, see below) of BioSQL has finally been released. The release can be downloaded at http://biosql.org/DIST/ as .tar.gz, .tar.bz, and Zip (which also has Windows-style end-of-line characters) archives. The full release announcement can be found in the BioSQL mailing list archives, and in the distribution itself.

This version of the schema has essentially been the same since November 2004. Software that worked with schema versions downloaded from CVS (or, as of lately, svn) after November 2004 should work with all 1.0.x releases. The release contains the core BioSQL schema for several RDBMSs (MySQL, PostgreSQL, Oracle, HSQLDB, and Apache Derby), accompanying documentation, and a Perl script to preload or update the NCBI taxonomy.

BioSQL is a generic, extensible relational model for sequences, sequence features, their annotation, and ontology terms. It is also designed as the interoperable persistence interface between the Bio* projects. Additional information regarding BioSQL, including links to language bindings, a roadmap to future releases and enhancements, and possible local optimizations is available from the BioSQL website.

This release and the accompanying work was irreversibly set in motion at the BioHackathon 2008 in Tokyo, and would not have happened without the active encouragement from several hackathon participants, especially Heikki Lehvähslaiho, Mark Schreiber, Richard Holland, and Raoul Bonnal. In recognition of this, and in keeping with an informal tradition held up since the first BioHackathon, I am code-naming the 1.0.x release series the Tokyo release series of BioSQL.

Enjoy!

I posted the slides for the Bioperl-db/BioSQL talk I gave at BOSC03.

-hilmar

Hi Everyone,

Apologies for the mass cross-posting but this email is about server and IP changes that will affect all of our projects and servers.

Simply put — Wyeth, the company that provides us with our hosting and wonderful T3 connection to the internet is cutting their internet connection circuits over from one ISP to a different Tier 1 internet backbone.

Technically the changeover will be swift as the circuit and new routers/firewalls are already in place. Should be a matter of bringing down the old gear and lighting up the new stuff.

The backbone change will have a significant affect on us though — all of our server IP addresses will change.

The change is scheduled for the evening (EST/EDT timezone) of September 2nd 2003. I’ll be onsite at Wyeth in the datacenter as the change occurs so that I can bring down our servers and plug in the new IP addresses.

The really nice thing is that all of our primary and secondary DNS nameservers are hosted at places other than Wyeth. This means that we can almost instantly be pushing out the new correct IP addresses for all of our open-bio.org, biojava.org etc. domain names.

If I can get my act together during the day on Tuesday I’ll start seeding our DNS servers with shorter TTL values which will speed up the spread of the new information.

For people with ‘fresh’ DNS data our servers will appear back on the internet within 30 minutes or so. For people behind nameserver caches that do not refresh all that often please expect our servers to “vanish” from the internet for a period of about 8-24 hours while the new information propagates out through the internet.

Regards,
Chris
open-bio.org

Do you need to access sequences from multiple places? Would you like
to easily retrieve your own local sequences from indexed flat files,
all other sequences on species X from department wide raletional
database and the rest from global internet servers?

The Open Biological Database Access (OBDA) System was designed so that
one could use the same application code to access data from all three
of the database types by simply changing a few lines in a
“configuration file”. This makes application code more portable and
easier to maintain.

This document gives an overview and shows how to use it in BioPerl:

http://www.bioperl.org/HOWTOs/html/OBDA_Access.html

http://www.bioperl.org/HOWTOs/pdf/OBDA_Access.pdf

OBDA System is also implemented in BioJava, BioPython and BioRuby.

Hilmar writes:

I got the Oracle version of the biosql schema fully migrated, at least as far as I can tell from here. I’m going to commit the new version some time today. There will also be a sql*plus migration script from pre-Singapore to the current version that supposedly keeps your data intact (be sure to read the disclaimer though).

This means we’re getting ready to release Biosql 1.0, possibly as early as next week. If anyone sees any problems with the current schema that he/she thinks should be corrected before this release, please speak up now. I guess I should make an effort and generate an updated ERD before release; the dated ones are confusing wrt the current schema. If there is consensus I’ll put out a release candidate early next week.

Bioperl-db should be working against the mysql, PostgreSQL, and Oracle versions (once I’ve committed that one). The major deficiency here is POD documentation of the modules, specifically updating old modules, and adding/updating the SYNOPSIS sections. I guess a programmer’s guide would also be helpful. For the next weeks to come I’m unfortunately not in a position to be able to spend the time it would require to bring the POD documentation up to speed. Would anyone else care to help out? What is generally people’s take on how good the documentation should be before we release this? Maybe not care too much and just go ahead to have something officially blessed that can be downloaded?

Jason, with respect to the marker database in bioperl-db, what is your vote on keeping it in the distribution? The problem is that the schema is MySQL-specific, so if someone wants biosql on Pg or Oracle you still have to set up Mysql in order to make all tests pass. An option could be to check the driver in the markerdb-related tests and skip everything if it’s not mysql.

The next feature I’m going to add to biosql is a table for expression data that basically resembles the data cube with various dimensions (roughly, bioentry, term [quantitation type], term [sample annotation]). No LIMS info (yet) other than sample annotation as far as it fits the term table. In my view, this would be a post-1.0 thing. Do people agree?

Hilmar writes:

Here’s the background.

The current code in the bioperl-db adaptors to biosql run the connection with AutoCommit off, which means the client determines the transaction. Load_seqdatabase.pl (the main script for loading databases into biosql) treats one sequence entry as one transaction. If any sql statement required for loading the sequence fails unexpectedly, the whole transaction is rolled back, otherwise it is committed once the entry and all its annotation went in successfully. The emphasis rests on ‘unexpectedly’: INSERTs may fail due to unique key violations, which is caught and triggers a look-up of the affected entry by unique key. E.g. a dbxref may already exist; if so, it needs to be looked up in order to establish the association with the bioentry.

Here’s the problem.

If within a transaction a particular statement fails, in Oracle and MySQL/InnoDB only that particular statement fails, not the previous ones in the same transaction, nor the subsequent ones. If you commit the transaction, all the succeeded statements’ results get committed. In PostgreSQL, however, the entire transaction fails and is invalidated, making all previous and all subsequent statements fail until you call rollback (you cannot call commit on a failed transaction).

The fulll message and email discussion thread can be read at:
http://bioperl.org/pipermail/bioperl-l/2003-February/011343.html