|  | 7 | Dear all, | 
                          |  | 8 |  | 
                          |  | 9 | Database Center for Life Science (DBCLS) is planning to have a BioHackathon | 
                          |  | 10 | for the Web Service in next January or February and hope to invite all of you to Japan | 
                          |  | 11 | (currently considering upto 20 developers from abroad and other 20 developers | 
                          |  | 12 | from Japan in total). We can offer your travel fare and accommodation fee | 
                          |  | 13 | by the DBCLS budget. | 
                          |  | 14 |  | 
                          |  | 15 | DBCLS (http://dbcls.jp/en/) is a non-profit research institution funded by | 
                          |  | 16 | MEXT (http://www.mext.go.jp/english/), established on the April 2007 and | 
                          |  | 17 | will continue for the 4 years. One of our goals is to integrate bioinformatics | 
                          |  | 18 | web services in a unified and convenient manner. | 
                          |  | 19 |  | 
                          |  | 20 | For this purpose, I'm planning to develop a proxy server which translate | 
                          |  | 21 | user's query for appropriate web service provider (e.g. EBI, KEGG, BioMOBY etc.) | 
                          |  | 22 | and formalize the returned data structures, so that user can easily build | 
                          |  | 23 | their own workflow without bothered by the data format conversion. | 
                          |  | 24 |  | 
                          |  | 25 | This view is partly based on the comment by Tom Oinn in BOSC2007 - even a sequence | 
                          |  | 26 | object in BioPerl is not compatible with other Bio* libraries - I strongly agree | 
                          |  | 27 | with it. We should define "50 basic bioinformatics data types" and implement them | 
                          |  | 28 | by refactoring current Bio* libraries, then use them in every web services. | 
                          |  | 29 |  | 
                          |  | 30 | BioMOBY has been served as a initial repository for various web services, however, | 
                          |  | 31 | there are hundreds of data types are listed and many of them are very similar. | 
                          |  | 32 | I think they need to be re-organized as the naming convention of the methods and | 
                          |  | 33 | data types currently used are extremely diverged. I suppose this situation restrict | 
                          |  | 34 | the interoperability of the services, and to develop any bioinformatics workflow, | 
                          |  | 35 | user needs to consult with (poor, in some cases) documentations. | 
                          |  | 36 |  | 
                          |  | 37 | So, I hope to gather as many developers as we can, from major web service providers, | 
                          |  | 38 | from Bio* developers, and other integrated service providers like BioMOBY and Taverna, | 
                          |  | 39 | to discuss and develop a new Open Bio* standard for the web-service-centric | 
                          |  | 40 | bioinformatics-nation (TM). | 
                          |  | 41 |  | 
                          |  | 42 | I'm preferentially writing you to hear any input to finalize our objectives of | 
                          |  | 43 | the web service hackathon, as my current knowledge on BioMOBY, myGrid, Taverna | 
                          |  | 44 | and other web services are very limited. | 
                          |  | 45 |  | 
                          |  | 46 | From my experience as a developer of the BioRuby library and the KEGG API service, | 
                          |  | 47 | I'm still stick on the SOAP/WSDL services even though the REST is the current trend. | 
                          |  | 48 | Because, | 
                          |  | 49 | * every SOAP server speaks the same language | 
                          |  | 50 | * cost to develop a client code can be minimal | 
                          |  | 51 | * user doesn't need any parser (cf. DAS spec etc.) | 
                          |  | 52 | * user can easily pass any complex data structure (including <ComplexType>) | 
                          |  | 53 | * we can also provide REST service if appropriate | 
                          |  | 54 |  | 
                          |  | 55 | On behalf of the DBCLS, | 
                          |  | 56 | Toshiaki Katayama | 
                          |  | 57 |  | 
            
                      
                        | 9 |  | == Attendee == | 
                      
                        |  | 60 | * Tokyo, Japan | 
                        |  | 61 | * Candidate dates | 
                        |  | 62 |  | 
                        |  | 63 | 1. 2008/02/10-02/16 | 
                        |  | 64 | 2. 2008/01/27-02/02 | 
                        |  | 65 | 3. 2008/02/03-02/09 | 
                        |  | 66 |  | 
                        |  | 67 | == Attendees == | 
                        |  | 68 |  | 
                        |  | 69 | * Toshiaki Katayama (Univ of Tokyo, Japan; BioRuby, KEGG API, KEGG DAS) | 
                        |  | 70 | * Alberto Labarga (Integromics, Spain; ex-EBI) | 
                        |  | 71 | * Matthew Pocock (Newcastle, UK; Taverna, BioJava) | 
                        |  | 72 | * Sophia Ananiadou (Manchester, UK; Text mining) | 
                        |  | 73 |  | 
                        |  | 74 | If you could recommend any appropriate persons from the following groups, please let me know: | 
                        |  | 75 | * NCBI web service developers | 
                        |  | 76 | * BioMOBY service developers (I found some interesting providers in Spain) | 
                        |  | 77 | * BioPerl, BioPython, and BioJava developers |