[Bioperl-l] default Bio::DB::SwissProt server broken?

[Chris Fields]

Hamish,

Thanks, but I already caught that and fixed it in main trunk where appropriate yesterday (specifically, both Bio::DB::SwissProt and Bio::DB::BioFetch).  

chris

On Oct 27, 2010, at 5:32 AM, Hamish McWilliam wrote:

> Hi Chris,
> 
> The dbfetch service at EBI has changed, see
> http://www.ebi.ac.uk/Tools/webservices/about/news#st_october_2010. On
> of the effects of this is the main endpoint used for dbfetch has
> changed from http://www.ebi.ac.uk/cgi-bin/dbfetch to
> http://www.ebi.ac.uk/Tools/dbfetch/dbfetch. With the old endpoints
> being supported via a HTTP redirect. It looks like the
> Bio::DB::SwissProt module does not support redirects and is thus
> getting an empty document back from the service. Looks like the URL
> used in the code needs to be updated.
> 
> All the best,
> 
> Hamish
> 
> On 26 October 2010 23:02, Chris Fields <cjfields at illinois.edu> wrote:
>> The default was changed recently in github to 'expasy'.  My guess is something changed on the EBI DBFetch end that isn't accepting certain identifiers anymore.
>> 
>> chris
>> 
>> On Oct 26, 2010, at 1:25 PM, Matthew Conte wrote:
>> 
>>> Hello,
>>> 
>>> I have a custom script for parsing out UniProt accessions from a GFF3 file
>>> and fetching the description of the UniProt entry using Bio::DB::SwissProt
>>> and *get_Seq_by_acc*.  This script has been working for months without any
>>> problems until now.  The script and the format of the input files has not
>>> changed at all.
>>> 
>>> I now get an error like this:
>>> 
>>> *------------- EXCEPTION: Bio::Root::Exception -------------*
>>> *MSG: acc O95342 does not exist*
>>> *STACK: Error::throw*
>>> *STACK: Bio::Root::Root::throw /Library/Perl/5.10.0/Bio/Root/Root.pm:368*
>>> *STACK: Bio::DB::WebDBSeqI::get_Seq_by_acc
>>> /Library/Perl/5.10.0/Bio/DB/WebDBSeqI.pm:195*
>>> *STACK: /Users/Matt/scripts/get_uniprot_names.pl:35*
>>> *-----------------------------------------------------------*
>>> 
>>> The relevant portion of my original code looks something like this:
>>> 
>>> *#!/usr/bin/perl*
>>> *use strict;*
>>> *use Bio::DB::SwissProt;*
>>> *#parse out accession number*
>>> *..*
>>> *my $acc_num = "**O95342";*
>>> *my $db_obj = Bio::DB::SwissProt->new;*
>>> *my $seq_obj = $db_obj->get_Seq_by_acc($acc_num);*
>>> *
>>> *
>>> Looking at the documentation for Bio::DB::SwissProt, I noticed you can
>>> specify -servertype and -hostlocation.  So I changed my code to look
>>> something like this:
>>> 
>>> *
>>> #!/usr/bin/perl
>>> use strict;
>>> use Bio::DB::SwissProt;
>>> #parse out accession number
>>> ..
>>> my $acc_num = "O95342";
>>> my $db_obj = Bio::DB::SwissProt->new('-servertype' => 'expasy',
>>>                                                           '-hostlocation'
>>> => 'us');
>>> my $seq_obj = $db_obj->get_Seq_by_acc($acc_num);
>>> *
>>> 
>>> This fixes my problem and my script works again.
>>> 
>>> The default *hostlocation *is http://www.ebi.ac.uk/cgi-bin/dbfetch and the
>>> 'us' *hostlocation *is http://us.expasy.org/cgi-bin/sprot-retrieve-list.pl.
>>>  Both of these urls work in a browser, though the default throws the error
>>> in my script. Interestingly, the 'us' url has a notice that says
>>> "*Notice:* This
>>> page will be replaced with www.uniprot.org. Please send us your
>>> feedback<http://www.uniprot.org/contact>
>>> !", so hopefully it doesn't break soon as well.  Perhaps the default ebi url
>>> was recently changed in some way?  Anyway, I figured I'd post here in case
>>> anyone else ran into this problem.
>>> 
>>> cheers,
>>> Matt
>>> _______________________________________________
>>> Bioperl-l mailing list
>>> Bioperl-l at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>> 
>> 
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>> 
> 
> 
> 
> -- 
> ----
> "Saying the internet has changed dramatically over the last five years
> is cliché – the internet is always changing dramatically" - Craig
> Labovitz, Arbor Networks.
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l