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