第6回生命医薬情報学連合大会 (IIBMP 2017) BoF "セマンティックウェブ時代におけるバイオデータベースとデータ解析の融合" 「生命科学DB構築におけるRDF化の実践」
生命科学DB構築におけるRDF化の実践IIBMP 2017 BoF: SemWeb時代におけるバイオデータベースとデータ解析の融合ライフサイエンス統合データベースセンター (DBCLS)大田達郎 @inutano
View Slide
話すこと「データをRDF化する」とは、技術的に何をするのか伝えたいこと使いやすいデータを共有してみんなで科学をやっていきましょうRDFはそれを助ける1つの有力な選択肢だが、真に大事なのは作法伝えたい人測定/解析したデータを公開する人、DBを作る人生物学的解釈が付与される余地のあるデータを出力するソフトウェアを作っている人
宣伝第2回 RDF講習会「RDFの作り方」10/6 (金) @ JST東京本部別館 (市ヶ谷)"RDF講習会"で検索
問題:公開されたデータを使うと捗らない
公開DBを使うときに何をしますか理想URL叩くと即、自分の欲しい形でデータが落ちてくる現実ウェブサイトを探す (が見つからないもしくは落ちている)とりあえずダウンロード (サイトにそれ以外何もないので)謎の.tar.gzが落ちてくる (一晩かかる)雑に展開してみる (たまに開かない)何かが入っている (が何かよくわからない)READMEを読んでデータ構造を調べる (が何も書いてない)パーサーを書いて必要な部分を取り出す (何度も例外で落ちる)データの意味を調べるのに再度ドキュメントを読む (つらい)
つらい別ドメインのデータをさらに結合するなんて考えたくもない
データ作る方もつらいユースケースは10^n人10^n色マニアックな使い方をされてこその研究資源その全てを予測することはできない「自分でやれ」ラインの見極めの難しさなるべく柔軟なインターフェース、柔軟な形式で用意したいと、少なくとも思ってはいる
解決策:データ提供者が守るべきN個のお作法
どうあってほしいのかウェブサイトに情報を載せてくれドキュメント書いてくれエントリIDを体系的に管理してくれ関連リソースへのリンクを張ってくれ変な略語使うのをやめろ文字コードちゃんとしろ特殊すぎる(圧縮|通信)プロトコルを使うなデータ扱うのに特殊なソフトウェアを要求するな=>どうすればデータ提供者は従ってくれるのか？
FAIR principles www.force11.org/group/fairgroup/fairprinciplesbe Findablebe Accessiblebe Interoperablebe Reusable=>これらを突き詰めると Linked Dataになる
Linked Data: is a method of publishing structured data built uponstandard Web technologies such as HTTP, RDF and URIs to shareinformation in a way that can be read automatically by computers,from Wikipedia
Linked Data:お行儀の良いデータ養成ギプスURIを使えデータはRDFで表現しろURIにHTTPでアクセスされたらRDFも返せ
RDF化の機運が高まるみんなやってるよ、怖くないよNBDC/DBCLS/DDBJ/PDBjSIBEBI RDFNCBI PubChem/MeSHでもRDF化って実際何をするの
パターンA: RDBに入った表形式のDBから作る1.行ごとにURIで一意なIDを付与する2.列のキーワードを標準的な語彙 (predicates)に置き換える3.機械的に変換する便利: D2RQ and D2RQ Mapper
パターンB: NoSQLに入ったドキュメント型DBから作る1.エントリごとにURIで一意なIDを付与する2.適切なモデルを設計する3.必要な語彙を既存のオントロジーから選ぶ、なければ作る4.コンバータ書いて変換する
実例: BioSamples w/ EBI‑RDF @ BH17配列データをDDBJに登録する際にサンプルの情報を書くアレDDBJ, EBI, NCBIで交換されている登録ユーザが独自に key‑valueを設定できる元データはXMLRDFモデルはEBI BioSamples API JSONの構造を流用key‑valueについては適切な構造を設計した語彙を決めるないものについては新規に作るコンバータを書くAPI ‑> JSON ‑> RDF Turtle
http://tinyurl.com/bh17final
実例: QuantoAvailable 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 Turtlebiogemになっています
元データ はただのテキストファイルなのでこれをパースしてJSONオブジェクトに変換し、contextを付与して JSON‑LDにする
RDFモデル made with draw.io
Quanto in RDF Portal bulk RDF data download, SPARQL endpoint
ね、簡単でしょ？全然簡単じゃない特に語彙を探す/選ぶ/作るところがつらいBioPortal, EBI OLS等があるが、結局人に聞いている独りでは難しいグループで取り掛かることでかなりコストを下げられるBioHackathon, SPARQLthon, etc..いずれにせよ筋力の問題なのでやっていくしかない
RDFにすることで全ての問題が解決したかウェブサイトに情報を載せてくれ:筋力ドキュメント書いてくれ:筋力エントリIDを体系的に管理してくれ: URIを使う関連リソースへのリンクを張ってくれ: RDFでリンクを張る変な略語使うのをやめろ:適切な語彙を使う文字コードちゃんとしろ: UTF‑8 orフォーマットの指定に従う特殊すぎる(圧縮|通信)プロトコルを使うな: HTTP GET!!!データ扱うのに特殊なソフトウェアを要求するな !!!No Silver Bullet: RDFにすれば何もかも解決するとは誰も言ってない
特殊なソフトウェアを要求するなTripleStore, SPARQLは特殊か否か依然扱える人は少ない派閥W3C標準なんだからSPARQL使おうよ派いいからJSON返せ、あとはこっちでなんとかするから派Neo4Jではあかんのか派
コストが十分下げられるなら提供する選択肢は増やすべき元データ ‑> JSON ‑> JSON‑LD ‑> RDFの流れは比較的容易JSON‑LDは @contextを無視すればただの JSONエンドポイントSPARQLRESTful APIsmart API that returns JSON‑LDElasticsearchバルクダウンロード作法に則ったデータとこれらが揃えば別ドメインのデータと繋ぐことも難しくない（はず）
繋がったその先:グラフ解析手法にそのまま入力できるのかHeterogenous Network:ノード、エッジにバリエーションがある異なるDB間で同じ概念を表すために別の ontology termが使われている場合がある=>別DBのRDFデータを混ぜたグラフを作る際に、語の使われ方の違いが解析の精度に影響を及ぼすのでは？RDF化されたデータベースはあらゆるものが繋がっている不要なメタデータ (登録の日付,データ登録者の所属,文献ID,etc.)なども=>解析に必要なサブグラフをいかに簡単に取り出すか？そのデータはグラフ化に向いているかbigBedをRDFにすることは技術的には可能だが…
まとめ作法に則ってデータを作りましょうコミュニティに参加して協調すると捗るデータ元がやってくれないなら自分でやるRDF化とはすなわち「ちゃんとする」ことあなたとFAIR、今すぐ実装RDFとJSON‑LD,目的に合ったものを使えるようにデータ解析にとっては異なる種類の前処理が必要になる可能性
inutano
mhangyo
sensetime_japan
.png){kind=avatar}
researchconf
kosuken
ahspragu
emi0726
cheerfularge
smartfukushilab1
yuyay
yuki_koyama
kuanyi_n_n
philnash
chriscoyier
tmm1
zenorocha
lauravandoore
bkeepers
3n
morganepeng
addyosmani
danielanewman
pedronauck