BH16.12/DDBJ

提供：TogoWiki

2017年6月2日 (金) 08:31時点におけるJmashima (トーク | 投稿記録)による版
(差分) ←前の版 | 最新版 (差分) | 次の版→ (差分)
移動： 案内, 検索

真島、李、藤澤


目次

DDBJ rel. 105 に記載されている外部アノテーションリソースの収集・俯瞰・登録時確認への応用 

LOCUS       AP014946             4586237 bp    DNA     circular BCT 20-NOV-2015
DEFINITION  Variibacter gotjawalensis DNA, complete genome.
ACCESSION   AP014946
[snipped]
     CDS             281459..282517
                     /codon_start=1
                     /EC_number="4.1.2.48"
                     /gene="ltaE"
                     /inference="ab initio prediction:Prodigal:2.6"
                     /inference="similar to AA sequence:UniProtKB:O50584"
                     /locus_tag="GJW-30_1_00246"
                     /product="low specificity L-threonine aldolase"
                     /protein_id="BAT57738.1"
                     /transl_table=11
                     /translation="MNFASDNTAGIPAPILDAITAANEGYSLGYGNDDWTKRVEARLS
                     ELFEREVAAFLVPTGTVANSLALAHLSPPWGAVLCHVDSHVNDDESGAPEFFGGGLKL
                     LELPGQNAKIDPAVLTERLSRLRGAPHSVLPSVVSITQSTELGTVYSLSEIAALAEIA
                     RSRSLKLHMDGARFGNAIASLGCAPAEATWKTGVDALSFGATKGGALAAEAIVFFNPA
                     DAAGMSSRRKRGGALISKHRFIAAQFEAYLKDDLWLKLARHANAMAKRLSDGLSAAGE
                     PPMWPVEANEVFAILSNDADARLRKAGAAYYPWQAVALPEGRKVPQGHGLFRLVTSFA
                     TRADDVDAFLRIAHPTKP"
[snipped]

上記、実際の DDBJ データの feature 記載例から Prodigal version 2.6 を用いて予測し、UniProt O50584 とアミノ酸配列が似ていることを推論根拠としたこと、酵素番号 4.1.2.48 相当の酵素と推定していることがわかる。この例では記載に矛盾はない。実際の登録現場・公開データには不適切な記載・矛盾があるかもしれない。

/inference: feature 記載の推論根拠としての参照元を : 区切りで構造化して記述

/inference qualifier定義

"[CATEGORY:]TYPE[ (same species)][:EVIDENCE_BASIS]"

  • CATEGORY は省略可能、規定値、機械的検証が難しい分類名。今回は調査していない。
  • TYPE は後述、規定値。
  • (same species) は推論根拠が同種に由来する際につけるフラグ
  • EVIDENCE_BASIS 中を ":" で区切る、やや自由度の高い書式。
    • <database name>:<record id> # "," 区切りで列挙可
    • <algorithm name>(:<tool version>)(:<database name>:<record id>)

TYPE と呼ばれる推論根拠の分類に注目: 規定値 

"similar to sequence"
     "similar to AA sequence"
     "similar to DNA sequence"
     "similar to RNA sequence"
     "similar to RNA sequence, mRNA"
     "similar to RNA sequence, EST"
     "similar to RNA sequence, other RNA"
"profile"
     "nucleotide motif"
     "protein motif"
     "ab initio prediction"
"alignment"

EVIDENCE_BASIS には緩い規則がある。":" で区切り、database name, algorithm name の記載をする上では、record id, version などを それぞれ記載することを推奨。大きく分けて下記の2通り。

  • similar sequence 型; <database name>:<record id> # "," 区切りで列挙可
  • profile 型; <algorithm name>(:<tool version>)(:<database name>:<record id>)

TYPE と database name, algorithm name の組み合わせ

TYPE と database or algorithm の組み合わせを DDBJ rel. 105 から抽出したところ、483 組; 表記揺らぎ、間違いを除くともっと少ない。

  • UniProtKB ならば、基本は、similar to AA sequence であろう、といった組み合わせの整合性。
  • 例えば、RefSeq ならば、RefSeq accession numbers and molecule types に応じた組み合わせの整合性
  • database と record id --> /gene, /product の記載整合性
    • 例えば UniProt RDF 経由で比較
    • その他、RDF 経由で比較・検証できるものが増えれば...という視点。 
参照先 db name と record id を記載するが、sequence で feature 領域の「推論根拠」
FASTA or BLAST, coverage, 閾値 などを問題にしないし、検索対象データセットも記載対象にしていない。
この analogy で例えば、InterPro scan or HMMPFAM といったツール・手法を問区別しない？
PFAM にヒットなら、それだけを記載するのか？
# protein motif:PFAM:pfam12345
# protein motif:HMMPFAM:PFAM:pfam12345
# protein motif:InterPro-Scan:PFAM:pfam12345
# protein motif:InterPro-Scan:InterPro:pfam12345
# どれでも可？どれが推奨？
参照データのある profile では database name と record id があれば、こだわらない？
record を指すことができないケースでは、ツール名を記載。
実際の解析フローの記載は Structured_COMMENT, 論文の methods に記載を推奨する。

/EC_number 酵素番号

EC番号 酵素番号、Enzyme Commission numbers　酵素を整理すべく反応形式に従ってECに続く4組の数字で表したもの。

ExPasy ENZYME の FTP から database を取得、EC number ID と Name 抽出 -> enzyme.dat (ID & DE line) + enzyme_class 

7376 IDs
 957 (transferred names)
 153 (deleted names)

/EC_number 記載状況 DDBJ rel. 105 から抽出 

-> 4460 IDs
-> 246 (transferred names): データの更新が必要
     例、
     1.1.1.63 ->    Transferred entry: 1.1.1.239.
-> 10 (deleted names): データの更新が必要
     例、
      1.1.1.74 ->    Deleted entry.
-> 11 (black list)
     例、
      -.-.-.-
      1.6.99.14
      3.2.24.55
      3.4.6.12
      4.4.99.-

応用の方向性

  • /EC_number 記載の有効性チェック
  • /product との整合性チェック 
業界の実情とは異なると思いますが、理想を言えば、

/EC_number の記載が最も確からしいケース: 
0) 配列の登録者自身が生化学的に同定している場合、酵素番号、class - 、申請中 n の どの記載も可能
これは受け入れることに一切、抵抗がありません。

ただ、それ以外は許さない、とまでは、実情を考えると言えません。
 # 一応、n の記載は新規酵素の申請者本人以外には許可しなくて良いと考えていますが。

次善として、どのような場合が(ゲノムアノテーションなどにおいて)確からしいか: 
1) 配列の類似度から、既報の酵素と orthologue (or それに準ずる) と評価し、参照対象から引用
2) domain profile 系で活性を評価し、参照対象から引用
くらいまでは、抵抗が少ないと思います。

さらに
3) 配列の類似箇所が活性部位をカバーすると評価し、参照対象から引用
くらいまでは許されると思います。

これ以下になりますと、番号でも class でも記載意義を評価しづらく書いて欲しくない、というのが本音です。

実際には
4) 配列が類似している参照対象の /EC_number を特に評価せず引用する
が大多数でデータとして氾濫しています。

番号か class か で記載の妥当性の評価が変わることはなく、記載根拠が問題と考えています。
さらに参照対象の確からしさ自体もあやしい世の中なので、まじめに考えるとつらくなります。

チェックを自動化するとすれば、推論根拠と矛盾していないことのチェックぐらい？

memo:

Trad, Assembly (BioSample) 組み合わせの バリデーションルール

その他の関連情報

謝辞

NBDC RDF Portal/DDBJのSPARQL ep.（未公開）をDBCLS 川島さんに利用させていただきました。

「/mw/BH16.12/DDBJ」より作成