Skip to content

meeting_20160512

Jump to bottom
Takatomo Fujisawa edited this page May 16, 2016 · 31 revisions

2016年05月12日打合せ

  • 日時: 2016年05月12日（木） 10:00-
  • 場所: W207
  • メンバ: 児玉、福田、向田、李、藤澤、大石、岡別府（順不同、敬称略）

アジェンダ

質問

  • DDBJ (trad と BioSample) では strain-level taxonomy の使用を discourage (マージされる可能性大、type strain 情報とのリンク) しており、strain-level → species-level への修正をしている。機械的に検出可能でしょうか？
    • => 出来ると思いますが、Taxonomyオントロジーではstrainの系統ランクは基本的にNoRankになっているようで、どういう条件でstrain-levelと判断するか当日相談させてください。Speciesより下位のRankは次の４つ。[Subspecies,Varietas,Forma,NoRank(の一部)] 系統ランク一覧
  • pathogen package の species-level taxonomy のチェックは RDF でどのように実装されるのでしょうか？
    • => TaxonomyオントロジーでSpeciesランクまたはその下位のランクを持つtax_idかどうかをチェックしています。RDFへのクエリ(SPARQL)の内容については当日簡単にご説明します。コード、 SPARQL

お知らせ

  • DDBJ データベース運用チーム全員を dbt チームメンバーとして追加。dbt チームに本レポジトリの閲覧権限を付与。

アノテータ todo

  • 変数埋め込みを無くす方向でメッセージを見直す ※検討1
  • → rule シートでハイライトされていた埋め込み付きメッセージから変数プラスアルファを削除しました（児玉）。
  • NCBI のように automatically generated correction will be applied とメッセージで明示する。Auto-annotated 　→ Suggested ※検討資料p7
  • → rule シートで auto-annotation フラグ付きルールメッセージに一律 An automatically-generated correction will be applied. を追加　（児玉）。
  • エラーの場合に provide のようなオリジナルを直す、というアクションを明確にしたメッセージにする
  • → 適宜 provide など記載あるのでメッセージ修正は実施せず。オリジナルの tsv xml 直すというのはマニュアルなどで周知。
  • Suggested にはユーザが選択肢から選ぶタイプ (BioSample では strain-level tax id のみ)、と、半強制的な修正 (BioSample ではほとんどこちら)、に二通りがある。 json で is_suggested, auto-correction フラグ名の見直し？
  • → グループ化した場合の表カラム名は "Auto-annotated value" から "Suggested value" に変更お願いします。Suggest で半強制置換だがメッセージ "An automatically-generated correction will be applied" でユーザは理解できる。

BioProject ID　関連

  • bioproject_id PSUB 記入しているのにエラーで suggest は違和感。PSUB 記入廃止する方向でルール自体を見直す。ID 連携で配列データからの自動埋め込み可能なので。 ※検討資料p7

  • → フォーマットチェックと PSUB の自動変換が rule5 として一体であることが問題なので、分離しました。 rule 5 単なるフォーマットチェック auto-annotation なし、に変更。INSDC BioProject 番号 PRJ[D|E|N]xxxxx もしくは PSUBxxxxxx。レベル = エラー rule 6 BioProject not found ユーザのアカウントで取得された BioProject 番号 (PRJD と PSUB) かどうかチェック、外部参照もあり得るので レベルを error から warning に変更 rule 95 PSUB から PRJD への自動変換は 95 として rule 5 から分離 (ルールの追加実装をお願いします)

  • rule61 Primary value は表示しない。最初の属性で後続のチェックしましたよ、をメッセージに追加 ※検討7

  • → メッセージに " First value was used for subsequent validation." を追加。

  • rule13 に改行の除去も含める。これに伴い rule 29 を廃止 ※検討22

  • → rule 13 の comment@ja に改行の除去を追加(実装をお願いします)、rule 29 を killed （廃止）

strain level tax id 関連

  • strain level tax 岡別府さん作成のリストをアノテータがチェックする

  • 抽出ロジック: lineage bacteria、fungi、古細菌、species 以下を RANK 情報と共に列挙

  • species-level の判定は、sparql で rank = species であること

  • 結果ファイルはサイズが大きくなるので、コマンドで sparql たたく。ファイルを岡別府さんからもらう。

  • いけそうならルールとして追加

  • 実装するときはメッセージに An automatically-generated correction will be applied を含めない。species level を suggest

メモ

  • BioSample sample_title etc 以外の属性が同一。sample_title etc 以外の属性値列挙ではなく、Sample name - Samples with identical attributes ペアで列挙。 A - B, B - A sample_name をキーにしているため全ての組み合わせを列挙 ※検討10 rule24

  • tax id ベースではなく organism name ベースに変更したとしても、完全一致検索なら sparql の速度はあまり落ちない。

  • アカウント内での sample_title の重複チェック。結果テーブルに SSUB 番号を Submission ID として挿入。SSUB なければ空。 ※検討13, rule3

  • XML submit の場合、前処理で submitter id と submission id を XML に埋め込む必要あり。

  • pathogen で species-level tax id であること = species 以下であること (subsp は OK なので)、で当初の回答通りに実装。

##　検討結果　 エラー画面仕様検討資料

  • 検討1) グループ化表示の際のエラーメッセージへの変数埋め込みについて
  • → 変数埋め込みはやめる方向にして、メッセージを検討し直す
  • 検討2) sample_nameをキーとしてよいか
  • → 基本的に抜けたり重複することはないのでsample_nameをキーとしてよい
  • 検討3) rule29のエラー内容とメッセージが合っていない
  • → 改行が含まれているチェックはrule13に組み込まれ本ルールは廃止
  • 検討4) Attributesが空白表示になる場合があるがよいか
  • → OK
  • 検討5) "Message"などの独自項目がある
  • → 他のValidationとも統合することを考えて独自項目は極力避けたい。WebAPIが複雑になるのではないか?(藤澤)
  • → "Message"だけでなくValidator側は実装が複雑になりここのメタプログラミンは出来なくなる。逆にWebAPI側は何も考えずに表示するだけになる。APIは次を参照のこと(岡別府) Validator API
  • 検討6) 属性名の重複については、値を列挙する形式でよいか?
  • → OK
  • 検討7) 属性名の重複については、先に出てきた値を優先させることを"Priority value"として表示している
  • → 個別表示は不要で、メッセージに"最初の値を優先します"と付け足す。
  • 検討8) 複数属性の組合せの場合には提案内容の表示でよいか？
  • → Attribute Name1,Attribute Value1,Attribute Name2,Attribute Value2 という表記でもよいのでは？
  • → packageなどAttributeでないものも含むのでそれはできない
  • 検討9) 複数属性の値にAuto-annotation(Suggest)は発生するか?
  • → 複雑になるのでそのケースはないものとする
  • 検討10) Sampleの基本情報以外の属性が同一である場合の表示 (rule24)
  • → 一致している属性を全て出力する必要はない。あるサンプルについて属性が同一であるサンプル名を列挙すればよい。
  • → p11の下の表示のように実装する
  • 検討11) パッケージに対応したメッセージの表示
  • → OK
  • 検討12) sample_titleという項目で表示した例としているが、Attribute項目を使うことも可能
  • → これでよい
  • 検討13) アカウント内のどのサンプルと重複しているか情報がないが大丈夫か?
  • → SubmissionIDがあれば表示するようにして欲しい
  • 検討14) sample_nameが重複しているケースにおいて、sample_titleも重複していればエラーメッセージでどのサンプルのエラーか区別がつかない
  • → レアケースなのでsample_titleを表示するこの提案内容でOK
  • 検討15) 何件のエラーがあったかをメッセージで変数に埋め込んでしまうと、テーブル表示するものがなくなる。
  • → COUNTの埋め込みはやめる。検討1の変数廃止対応で解消される。
  • 検討16) sample_nameが重複しているケースにおいて、sample_titleも重複していればエラーメッセージでどのサンプルのエラーか区別がつかない
  • → 検討14と同様に提案内容どおりでOK。検討1の変数廃止対応で解消される。
  • 検討17) organismが抜けているものを空白表示する
  • → OK
  • 検討18) エラーのある属性名についてはカンマ区切りで列挙する
  • → OK
  • 検討19) tsvを前提としたメッセージになっている
  • → 対応済み
  • 検討20) どちらか一方の入力が必須な項目についてどのように列挙するか
  • → 配列のような表示でよい。[strain, isolate],[attr1, attr2]
  • 検討21) エラーメッセージへの変数埋め込みは冗長になる
  • → 埋め込みはなくすのでOK
  • 検討22) 改行コードが含まれている場合にはリスト表示の場合見辛くなる
  • → DDBJとして改行コードの入力は避けたいところ。rule13のformat補正に追加するため、このケースは発生しない。

環境構築

運用サーバ

  • ホスト名 ddbjs4 (ddbjs4.genes.nig.ac.jp)
  • 機種 HP Z840
  • Xeon(R) CPU E5-2620 v3 X 2 cpu
  • 64 Gb memory
  • os: ubuntu 14.04 LTS (desktop)

手順

submission/validation api

Clone this wiki locally