meeting_20190226

2019-02-26 打合せ

日時: 2019-02-26 10:30-12:00
場所: W207
参加: 小菅、児玉、真島、畠山(遠隔)、藤澤、岡別府(順不同敬称略)

D-easyでのルールの説明

現状のAnnotation編集画面のTemplate生成に関連する説明(畠山)

Templete画面

画面イメージ

• プルダウンで選ぶのはDivisionではなく、生物種を細かく定義した拡張Divisionであり、これはD-easyで独自に定義しているもの。
• 選択した拡張Divisionに応じたAnnotationの種類がリストが選択できる。

common_rules.rb

• ソースコード
• 各featureに対してqualifierのリストと必須/オプションの定義をしている。

templates.rb

• [ソースコード](https://github.com/ddbj/sakura/blob/develop/config/templates.rb.local）
• define_extended_divisionで、それぞれの拡張Divisionで、選択できるfeatureとqualifierの必須・オプション項目を定義している。
• さらに、annotation_type XXX で選択できるan"notationタイプを記載(拡張Divisionをプルダウン選択した際に表示されるラジオボタングルーぷに相当)
• それぞれのannotationタイプはdefine_annotation_type(3221行以降)で規定し、どのルール(define_ruleで規定)を使用しているか、各qualifierのデフォルト値を決めている。 ＊ common_rules.rbとtemplates.rbについてはPRのログで参考になる部分があるかも参照

パーサ

• これらのパーサーはmodelsのschema.rbで行なっている。ソースコード
• 拡張Divisionとannotationタイプを引数に渡すと、annotation編集画面に必要な情報が返ってくる。

Schema::Templates.select("BCT", "cds_2to3")

確認と質問

common_rules.rbの記述式が分からない。Rubyなのか？(岡別府)
=> これは設定ファイルを記述する時に使われるRubyの標準の記法。Rakeファイルでも使用されている(畠山)

templates.rbのdefine_extended_divisionの部分はcommon_rules.rbの内容とやや重複している気がする。(岡別府)

D-easyのValidation

拡張Divisionルール

• 拡張Divisionを選んだ時点で、D-easy上で追加できるqualifierや削除できないqualifierがハンドリングされる。(小菅)
• この制御は画面表示に使用しているだけで、Validationの段階では使用されていないように思うが、それで間違いないか(岡別府)
  => Validation時にこの定義を使ってはいない(畠山)
  => D-easyの登録では画面で制御されているのでルールを逸脱したデータが送られることはないが、MSSでは拡張Divisionさえ使用しておらず、 Validationの精度が異なっている。MSS側の精度も上げたい。(小菅)
• 拡張Division定義を使ったルールはJParserValidatorではvalidationしないのか(岡別府)
  => JParserValidatorはフォーマットチェックであるため、Biologicalな意味合いのチェックは一切行なっていない。(小菅)

Validationの実行コード

• 以前はRSpecを使ってValidationしていたように思う(藤澤)
  => 現在は行なっていない。JParserValidatorAPIを呼び出し、TransCheckerのモージュールを直接叩いている(畠山)

編集画面のインラインValidation

• annotation編集画面で個別にエラーを出力する部分のルールはどこに記述されているのか(藤澤)
  => 直接JSで記述していると思う。そのコードの場所を示す(畠山) //TODO

国名リストなどのデータを使用したValidation

• 入力できる国名リスト等はどこで制御しているのか(岡別府)
  => 国名リストはNCBI、国名にあった電話番号のPrefixをKDDIのサイトから取得してCSVに直してMongoDBのロードしている。
  => 他にTaxonomy DumpとJournal名も取得してDBロードしている。Taxonomy(Public版)は日次、それ以外は月次でcron更新。ソースコード

JParserとの重複

• JParserが行なっているとされる、正規表現等で行えそうなフォーマットチェックをD-easy側でも実装していることはないか(岡別府)参照 => 数字であるべき、という程度のことはformチェックで行なっているが、それ以上のことはしていないと思う(畠山)

BioRubyの使用

• BioRubyを使ってflatファイルをロードするような処理を書いているか。いるならValidatorも同様に使いたい(岡別府)
  => D-easyではflatファイルは扱わない。D-easyで登録されたものをflatファイルに変換するフェーズは後にある(小菅)
• Locationの記述チェックが妥当であるかはBioRubyなどのようなツールを使いたい、自前実装は困難(岡別府)
  => BioRubyのflatファイルパース機能ではなく、その一部であるlocation用モジュールを使えば良いと思う(藤澤)

実装関連

• sakuraのコードはmasterブランチがなくdevelopがメインと考えて良いか(藤澤)
  => 本番環境稼働中のものもdevelopを使っているので、これがメインブランチとして運用している(畠山)
• JParserValidatorのAPI仕様書はあるか(岡別府)
  => 現状は遺伝研内部からしかアクセスできない位置にある。ドキュメント(児玉)

今後の進め方

• まずはJParserのValidatorをValidationAPI側でラップをする。
• D-easy側で実装されているがJParserでは対応できていないようなルールを整理する(common_rules.rb, templates.rb, DB, JS周り)。