RDFization of biomedical databases

RDFization of biomedical databases

第6回生命医薬情報学連合大会 (IIBMP 2017) BoF "セマンティックウェブ時代におけるバイオデータベースとデータ解析の融合" 「生命科学DB構築におけるRDF化の実践」

991f3366d9cc17386e6a66ef4abc6dbc?s=128

Tazro Inutano Ohta

September 28, 2017
Tweet

Transcript

  1. 生命科学DB 構築におけるRDF 化の実践 IIBMP 2017 BoF: SemWeb 時代におけるバイオデー タベー スとデー

    タ解析の融合 ライフサイエンス統合デー タベー スセンター (DBCLS) 大田達郎 @inutano
  2. 話すこと 「 デー タをRDF 化する」 とは、 技術的に何をするのか 伝えたいこと 使いやすいデー タを共有してみんなで科学をやっていきましょう

    RDF はそれを助ける1 つの有力な選択肢だが、 真に大事なのは作法 伝えたい人 測定/ 解析したデー タを公開する人、DB を作る人 生物学的解釈が付与される余地のあるデー タを出力するソフトウェ アを作っている人
  3. 宣伝 第2 回 RDF 講習会「RDF の作り方」 10/6 ( 金) @

    JST 東京本部別館 ( 市ヶ谷) "RDF 講習会" で検索
  4. 問題: 公開されたデー タを使うと捗らない

  5. 公開DB を使うときに何をしますか 理想 URL 叩くと即、 自分の欲しい形でデー タが落ちてくる 現実 ウェブサイトを探す (

    が見つからないもしくは落ちている) とりあえずダウンロー ド ( サイトにそれ以外何もないので) 謎の.tar.gz が落ちてくる ( 一晩かかる) 雑に展開してみる ( たまに開かない) 何かが入っている ( が何かよくわからない) README を読んでデー タ構造を調べる ( が何も書いてない) パー サー を書いて必要な部分を取り出す ( 何度も例外で落ちる) デー タの意味を調べるのに再度ドキュメントを読む ( つらい)
  6. つらい 別ドメインのデー タをさらに結合するなんて考えたくもない

  7. デー タ作る方もつらい ユー スケー スは10^n 人10^n 色 マニアックな使い方をされてこその研究資源 その全てを予測することはできない 「

    自分でやれ」 ラインの見極めの難しさ なるべく柔軟なインター フェー ス、 柔軟な形式で用意したい と、 少なくとも思ってはいる
  8. 解決策: デー タ提供者が守るべきN 個のお作法

  9. どうあってほしいのか ウェブサイトに情報を載せてくれ ドキュメント書いてくれ エントリID を体系的に管理してくれ 関連リソー スへのリンクを張ってくれ 変な略語使うのをやめろ 文字コー ドちゃんとしろ

    特殊すぎる( 圧縮| 通信) プロトコルを使うな デー タ扱うのに特殊なソフトウェアを要求するな => どうすればデー タ提供者は従ってくれるのか?
  10. FAIR principles www.force11.org/group/fairgroup/fairprinciples be Findable be Accessible be Interoperable be

    Reusable => これらを突き詰めると Linked Data になる
  11. Linked Data: is a method of publishing structured data built

    upon standard Web technologies such as HTTP, RDF and URIs to share information in a way that can be read automatically by computers, from Wikipedia
  12. Linked Data: お行儀の良いデー タ養成ギプス URI を使え デー タはRDF で表現しろ URI

    にHTTP でアクセスされたらRDF も返せ
  13. RDF 化の機運が高まる みんなやってるよ、 怖くないよ NBDC/DBCLS/DDBJ/PDBj SIB EBI RDF NCBI PubChem/MeSH

    でもRDF 化って実際何をするの
  14. パター ンA: RDB に入った表形式のDB から作る 1. 行ごとにURI で一意なID を付与する 2.

    列のキー ワー ドを標準的な語彙 (predicates) に置き換える 3. 機械的に変換する 便利: D2RQ and D2RQ Mapper
  15. パター ンB: NoSQL に入ったドキュメント型DB から作る 1. エントリごとにURI で一意なID を付与する 2.

    適切なモデルを設計する 3. 必要な語彙を既存のオントロジー から選ぶ、 なければ作る 4. コンバー タ書いて変換する
  16. 実例: BioSamples w/ EBI‑RDF @ BH17 配列デー タをDDBJ に登録する際にサンプルの情報を書くアレ DDBJ,

    EBI, NCBI で交換されている 登録ユー ザが独自に key‑value を設定できる 元デー タはXML RDF モデルはEBI BioSamples API JSON の構造を流用 key‑value については適切な構造を設計した 語彙を決める ないものについては新規に作る コンバー タを書く API ‑> JSON ‑> RDF Turtle
  17. http://tinyurl.com/bh17final

  18. 実例: Quanto Available at inutano/sra‑quanto and RDF Portal エントリ単位は FASTQ

    ファイル単位 元デー タは FastQC の出力とそこから計算した値 テー ブルを内包するオブジェクト デー タモデルを作る bioruby‑fastqc で設計したオブジェクトの構造のままJSON に 必要な語彙を既存のオントロジー から選び、 ないものは作った コンバー タを書く JSON にcontext を追加してJSON‑LD に JSON‑LD からrdf/turtle に自動変換 txt ‑> JSON ‑> JSON‑LD ‑> RDF Turtle biogem になっています
  19. 元デー タ はただのテキストファイルなのでこれをパー スしてJSON オブ ジェクトに変換し、context を付与して JSON‑LD にする

  20. RDF モデル made with draw.io

  21. Quanto in RDF Portal bulk RDF data download, SPARQL endpoint

  22. ね、 簡単でしょ? 全然簡単じゃない 特に語彙を探す/ 選ぶ/ 作るところがつらい BioPortal, EBI OLS 等があるが、

    結局人に聞いている 独りでは難しい グルー プで取り掛かることでかなりコストを下げられる BioHackathon, SPARQLthon, etc.. いずれにせよ筋力の問題なのでやっていくしかない
  23. RDF にすることで全ての問題が解決したか ウェブサイトに情報を載せてくれ: 筋力 ドキュメント書いてくれ: 筋力 エントリID を体系的に管理してくれ: URI を使う

    関連リソー スへのリンクを張ってくれ: RDF でリンクを張る 変な略語使うのをやめろ: 適切な語彙を使う 文字コー ドちゃんとしろ: UTF‑8 or フォー マットの指定に従う 特殊すぎる( 圧縮| 通信) プロトコルを使うな: HTTP GET !!! デー タ扱うのに特殊なソフトウェアを要求するな !!! No Silver Bullet: RDF にすれば何もかも解決するとは誰も言ってない
  24. 特殊なソフトウェアを要求するな TripleStore, SPARQL は特殊か否か 依然扱える人は少ない 派閥 W3C 標準なんだからSPARQL 使おうよ派 いいからJSON

    返せ、 あとはこっちでなんとかするから派 Neo4J ではあかんのか派
  25. コストが十分下げられるなら提供する選択肢は増やすべき 元デー タ ‑> JSON ‑> JSON‑LD ‑> RDF の流れは比較的容易

    JSON‑LD は @context を無視すればただの JSON エンドポイント SPARQL RESTful API smart API that returns JSON‑LD Elasticsearch バルクダウンロー ド 作法に則ったデー タとこれらが揃えば別ドメインのデー タと繋ぐことも 難しくない( はず)
  26. 繋がったその先: グラフ解析手法にそのまま入力できるのか Heterogenous Network: ノー ド、 エッジにバリエー ションがある 異なるDB 間で同じ概念を表すために別の

    ontology term が使 われている場合がある => 別DB のRDF デー タを混ぜたグラフを作る際に、 語の使われ 方の違いが解析の精度に影響を及ぼすのでは? RDF 化されたデー タベー スはあらゆるものが繋がっている 不要なメタデー タ ( 登録の日付, デー タ登録者の所属, 文献ID, etc.) なども => 解析に必要なサブグラフをいかに簡単に取り出すか? そのデー タはグラフ化に向いているか bigBed をRDF にすることは技術的には可能だが…
  27. まとめ 作法に則ってデー タを作りましょう コミュニティに参加して協調すると捗る デー タ元がやってくれないなら自分でやる RDF 化とはすなわち「 ちゃんとする」 こと

    あなたとFAIR、 今すぐ実装 RDF とJSON‑LD, 目的に合ったものを使えるように デー タ解析にとっては異なる種類の前処理が必要になる可能性