このエントリは、CWL Advent Calendar 2017 - Qiitaの25日目です。

背景

f:id:otiai10:20171225123808p:plain

誰がエモ芸人や

CWL is 何？

データ解析が再現するということ、あるいは Common Workflow Language... - こんな時間ですがパスタを茹でます

異なる処理系の間で同一のワークフローの実行を可能にするために、ワークフローの内容を記述し、実行系の間で交換するための標準形式の策定を目的として Common Workflow Language (CWL) プロジェクトが発足した。

すげーざっくり言うと、バイオインフォのゲノム解析の手順書を統一規格で書こうぜ、という感じのブツです。

実際どうやって使うねん

% cwltool 1st-tool.cwl echo-job.yml

サンプルで、1st-tool.cwlと書かれているものが、いわゆるワークフローの定義であり、echo-job.ymlというのはパラメータとかサンプルとか呼ばれたりするらしいです。これ、なんで分割されているかというと、

世界のどこかで、とっても良い感じのワークフローを提唱したひとがいたとして、

f:id:otiai10:20171225131640p:plain

同じワークフローで別のサンプルで試してみたいと思うひとが出てきます。

f:id:otiai10:20171225132547p:plain

ということで、ワークフローの記述と実際のパラメータは分割されている必要があります。

CWLの初期衝動

ところが、論文に載っている手順に従っても、それが「再現」できないという問題が起きます。

f:id:otiai10:20171225133953p:plain

この点を解決しようと立ち上がったのが、CWLです（雑）。Repeat/Reproduce/Replicate/Reuseについては先述のinutanoさんのエントリが詳しいです。

CWLの実行エンジン

入力としてワークフロー（.cwl）とパラメータ（.jsonなど）を受取り、記載されたワークフローを実行するソフトウェアが必要です。これを公式では「implementation」、日本のコミュニティでは「エンジン」と呼んだりしています。

私もいちおうソフトウェアデベロッパーの端くれとして、manabuishii先輩と一緒に、Go言語でCWLのデコーダとimplementationを実装中です。

CWLの競合

同様の問題意識を持ち始まったプロジェクトは他にも複数あります。

// TODO: 競合のリストがここにくる
- WDLとか？
- nextflowとか？

CWLのここがよい

第１に、バイオインフォが抱える問題（とは言っても僕自身この分野の新参者なのであまり歴史的な背景とか精通してるわけじゃないんですけど）にスポットライトを当て、それを解決しようと立ち上がったのは、素晴らしいことかと思われます。

第２に、国際学会やカンファレンスで精力的にディスカッションやハッカソンをしたり、GitHubで仕様を管理したり、コミュニティ形成に力を入れており、提言やPull-Reqにたいしてもかなり柔軟に取り入れたりしているのは普及したポイントかなと思います。実際、我々が作成中のGo言語実装:yacleも実装例のひとつとして早くもリストされています。

第３に、実際多くの場面で使われていること。国際的に、ワークフローの共有といったらCWLファイルつくっとくかぁ〜みたいな雰囲気がすでに漂っており、また公開されたCWLで記述されたワークフローをクラウド上で動かすウェブサービスなども出てきております。

以上が、CWLもなかなかいいじゃん、というProsになります。

.....

....

...

f:id:otiai10:20091121210556j:plain

CWLのここが嫌い

そういう上っ面じゃねえんだ、アドベントカレンダーはよぉ！こっからが本題だ。

Webプログラマから見たCWLの罪過、罪過？むずかしい言葉使ってんじゃねえよ！嫌いなところについて！~~うらみつらみを~~列挙して行こうと思います。

まず名前が嫌い
- CommonWorkflowLanguageって言うからにはDSLかな？って思うじゃないですか？違うんですよこれ単なるYAML or JSONなんですよ
- あと何「Common」って！すべてをかいけつするソフトウェアはなにもかいけつしませんよ？
syntaxが嫌い
- で、YAML or JSON だと思った？残念！！！！
- さて、これはYAMLでしょうか！JSONでしょうか！！（公式repoより）
  - common-workflow-language/cat1-testcli.cwl at master · common-workflow-language/common-workflow-language · GitHub
- JSON-LD？じゃあせめてvalidなjs書いてくれでござる！！
Data Modelが嫌い
- みてくださいこの型！ array<CommandInputParameter> | map<CommandInputParameter.id, CommandInputParameter.type> | map<CommandInputParameter.id, CommandInputParameter> って！
  - つまり[]Model|map[string]string|map[string]Modelってことです
    - これCとかGoでどうやってstructにデコードしますかね
      - 血涙流しながら怒涛のtype switch書きまくりました！
表現方法が嫌い
- 百歩譲って、ある言語でデコードがたいへんなのはその言語のせいだとしましょう。しかしながら、ある１つのことを表現するのに、多くの表現方法があることは、規格として正しいあり方なんでしょうか。
表現方法が嫌い・その２
- なんやねん！その２て！！！！！
- Exrepssionsというclauseがあるんですけど、これがマジやっかい
- これねーJavaScriptなんですよ！！（しかもES5！）
  - ワークフロー定義の内部がJS要求するっていうのならまだ分かるんですが、ワークフローの記述の表現にある特定のランタイムを要求するのって筋悪すぎじゃないですか
  - しかも、あたりまえだけどめっちゃくちゃいろんなこと出来るので、ワークフロー記述規格としての治安が乱れまくる
哲学が嫌い
- 上にも書いたように、かなりいろいろディスカッションして、だいたいのものは取り入れちゃってるので、仕様がどんどん肥大化していって、エンジンの実装者が「どの機能をサポートしないべきか」とかまず考えなきゃいけないレベルになっている
- "All is nothing" を地で行ってて最高にクール
そして、すでにけっこう使われているのが何よりも嫌
- プラットフォームつくりました！という話しても「それ、CWL食える？」みたいな質問が普通に飛んでくるぐらいには普及してしまっている
- 過渡期に、パイ取った感じある
- もう避けては通れない

f:id:otiai10:20091009172516j:plain

提言と提案

ワークフローを記述する規格は
- DSLではなく、一般的なデータ構造フォーマットであるべきだ
  - JSONとか
- 静的型付けの厳しい言語であっても、多くの一般的な言語でデコードが容易であるべきだ
  - 多少冗長であっても、厳格な構造をしているべきで、型ゆるゆるでは嫌だ
- それ自身の解釈に特定のランタイムを要求するべきではない
- 表現を絞り、 具体的に解決したい問題 をメッセージとして発信し続ける
我々はバイオインフォマティシャンは*1
- CWL+cwltoolでもいいし、何かほかの方法でもいいが、自分が直面している問題を解決することにフォーカスしたワークフローの記述&実行を心がけるべき
  - 銀の弾丸を追わない
- そういった「ぼくのかんがえたさいきょうのわーくふろー大会」をやりましょう！
  - painを同じくする仲間が見つかれば、たのしいですね