SPARQLthon50/RDF-DB

提供:TogoWiki

(版間での差分)
移動: 案内, 検索
(RDFデータベースの未来を考える会 議事録)
(RDFデータベースの未来を考える会 議事録)
 
(間の1版分が非表示)
3行: 3行:
== RDFデータベースの未来を考える会 議事録 ==
== RDFデータベースの未来を考える会 議事録 ==
-
今後の RDF データベースを利活用するためには?
+
今後 RDF データベースを利活用するためには?
* RDF データの集積
* RDF データの集積
23行: 23行:
* どこまでをクラスに、どこからをインスタンスにするか
* どこまでをクラスに、どこからをインスタンスにするか
** データは各遺伝子まで全てクラスでインスタンスは実世界の物理的なもの、という考え方もあるし、OWL で推論できるレベルをプラクティカルに考えるか
** データは各遺伝子まで全てクラスでインスタンスは実世界の物理的なもの、という考え方もあるし、OWL で推論できるレベルをプラクティカルに考えるか
 +
 +
=== ソフトウェアの課題 ===
 +
 +
* トリプルストアの性能が足りない
 +
** 現状 150 億トリプルくらいまでなら Virtuoso7 でハンドリングできるが、複数のデータセットを1つのエンドポイントに集約しようとすると更新が難しい(ちなみにDDBJ は百数十億トリプル)
 +
** BlazeGraph は 500 億までスケールすると謳っているが、実際は 30 億トリプルくらいでスローダウンするという経験も
 +
** Oracle はどうか? Dydra はどうか? HDT で TPF を使った RDF の利用方法にシフトしていくべきか(これまでのスタンザなどの資産を考えると SPARQL も使い続けられるのが理想)
 +
* 推論のためのツールを使いやすく
 +
** 本来セマンティック・ウェブは推論が得意なはずだが、ほとんどの人はやっていない
 +
** なお、validation や clustering が主な用途
=== ユースケース ===
=== ユースケース ===
32行: 42行:
** :
** :
** 100回くらい引用されるような論文が生成できると良い(→ そのような論文を誰かが書いてみんながそれぞれ引用するほうが早い:)
** 100回くらい引用されるような論文が生成できると良い(→ そのような論文を誰かが書いてみんながそれぞれ引用するほうが早い:)
-
** 結局、SPARQLthon やバイオハッカソンに来ているメンバーがお互いのデータを使って研究をする中で、データの再利用性を高めアプリケーションを作るとともに論文を書いていくというのが順当か
 
-
=== 今後の課題 ===
+
→ 結局、SPARQLthon やバイオハッカソンに来ているメンバーがお互いのデータを使って研究をする中で、データの再利用性を高めアプリケーションを作るとともに論文を書いていくというのが順当か
-
 
+
-
* トリプルストアの性能が足りない
+
-
** 現状 150 億トリプルくらいまでなら Virtuoso7 でハンドリングできるが、複数のデータセットを1つのエンドポイントに集約しようとすると更新が難しい(ちなみにDDBJ は百数十億トリプル)
+
-
** BlazeGraph は 500 億までスケールすると謳っているが、実際は 30 億トリプルくらいでスローダウンするという経験も
+
-
** Oracle はどうか? Dydra はどうか? HDT で TPF を使った RDF の利用方法にシフトしていくべきか(これまでのスタンザなどの資産を考えると SPARQL も使い続けられるのが理想)
+
-
* 推論のためのツールを使いやすく
+
-
** 本来セマンティック・ウェブは推論が得意なはずだが、ほとんどの人はやっていない
+
-
** なお、validation や clustering が主な用途
+
== 50回記念で賞 ==
== 50回記念で賞 ==

2016年11月25日 (金) 01:27時点における最新版

SPARQLthon50 で開催した50回記念特別企画のログです。

目次

RDFデータベースの未来を考える会 議事録

今後 RDF データベースを利活用するためには?

  • RDF データの集積
    • TPP の RDF を NBDC RDF ポータル に集積するだけでなく、EBI, NCBI や各所に設立されつつあるデータサイエンスのセンターと国際連携を進めていくのがよい
  • オントロジーの共通化
    • TPP が SPARQLthon に参加するようになって SPARQLthon21 くらいから検討をはじめた、分野ごとに扱っているコンセプトの一覧 TPP-DB を再検討し、オントロジーや ID (URI) の共通化をさらに促進する
    • オントロジー共通化の成果として、FALDO やオーソログの他、JCMとNBRCの連携があり、今後は jPOST と MassBank も連携できるかもしれない
  • URI の共通化
    • ID (URI) については、ハブとなるリンクセットをメンテナンスすることが重要
    • UniProt のようなリンクの多いデータもあわせてエンドポイントに入れておくのが便利だが、それに限らず国際的な枠組みで Bio2RDF や EdgeStore (TogoGenome) のようなものを identifiers.org や prefixcommons などの URI で整備する必要がある

RDF を作る際の課題

  • どこまでを RDF にして、どのようなデータは RDF にしてはいけないか
    • たとえば FASTQ → BAM → BED → FPKM などの階層でどこまでなら RDF 化すべきなのか
    • 指針の候補としては、ブラウザで表示するようなデータは RDF に、ブラウザでは見ないレベルの raw data はそのままに?
  • RDF で rdf:type に指定するコンセプトとして、「タンパク質」や「遺伝子」といったときにこれらのクラスはどのオントロジーで定義されているべきなのか
    • UniProt の up:Protein や他の DB の xx:Protein の上位概念として、一般的な :Protein クラスなどを定義するメタオントロジーを作る必要はないか?SNOMED-CT や MeSH で代用できるか?
  • どこまでをクラスに、どこからをインスタンスにするか
    • データは各遺伝子まで全てクラスでインスタンスは実世界の物理的なもの、という考え方もあるし、OWL で推論できるレベルをプラクティカルに考えるか

ソフトウェアの課題

  • トリプルストアの性能が足りない
    • 現状 150 億トリプルくらいまでなら Virtuoso7 でハンドリングできるが、複数のデータセットを1つのエンドポイントに集約しようとすると更新が難しい(ちなみにDDBJ は百数十億トリプル)
    • BlazeGraph は 500 億までスケールすると謳っているが、実際は 30 億トリプルくらいでスローダウンするという経験も
    • Oracle はどうか? Dydra はどうか? HDT で TPF を使った RDF の利用方法にシフトしていくべきか(これまでのスタンザなどの資産を考えると SPARQL も使い続けられるのが理想)
  • 推論のためのツールを使いやすく
    • 本来セマンティック・ウェブは推論が得意なはずだが、ほとんどの人はやっていない
    • なお、validation や clustering が主な用途

ユースケース

  • 今後 3 年の SPARQLthon で何が成し遂げられているとよいか
    • エンリッチメント解析に利用できるようなアプリケーション(好きな入力と出力を選べる)
    • 集積した RDF から機械学習などに利用するデータセットをさっと取り出せる SPARQL クエリ集や、それをラッピングしたサービスがほしい
    • 人工知能による RDF の活用で遺伝子と表現型を繋ぐなどの活用ができないか
    •  :
    • 100回くらい引用されるような論文が生成できると良い(→ そのような論文を誰かが書いてみんながそれぞれ引用するほうが早い:)

→ 結局、SPARQLthon やバイオハッカソンに来ているメンバーがお互いのデータを使って研究をする中で、データの再利用性を高めアプリケーションを作るとともに論文を書いていくというのが順当か

50回記念で賞

  • 川島さん:皆勤賞
  • 片山さん:司会お疲れさまで賞
  • 岡別府さん:肝臓お疲れさまで賞 && 女子で賞 && ミスSPARQL賞
  • 森さん:寡黙で賞
  • 千葉さん:独自で賞
  • 岡本さん:王子で賞
  • 山本さん:ベンチマークで賞
  • 永野さん:デザインが大事で賞
  • 山中さん:モテ季で賞
  • 桝屋さん:オントロジーが好きで賞
  • 藤澤さん:議論が好きで賞
  • 時松さん:荷物が重いで賞

(追記・編集・削除、ご自由にお願いします!)

個人用ツール