TogoGenome/TextSearch

提供:TogoWiki

移動: 案内, 検索

目次

概要

現状のTogoGenomeはファセット検索からスタンザを表示するが、テキスト検索にも対応するためのデータの構築手順について記述する。

検索対象スタンザと項目の基準

対象スタンザの判定基準

  • ナノスタンザは対象外
  • 図のみ表示する可視化スタンザは対象外
  • 外部のエンドポイントを使用するスタンザは対象外(データの一括取得が難しい場合)

現状ではMBGDのエンドポイントを使った2スタンザ taxonomy_ortholog_profile_stanza, protein_orthologs_stanza

対象項目の判定基準

  • 数値データ、シーケンスデータは対象外
  • subClassOf*を使用して階層を表示している項目で、階層が深く上流のテキスト検索で大量ヒットする場合は対象外 (例: lineage_information_stanza)
  • 撮りうる文字列パターンが少ない項目は、大量にヒットする可能性があり対象外 (例: protein_attributes_stanzaのProtein existence)

対象データの範囲

現状では、TogoGenomeのファセット検索の対象となっているデータのみを対象としてテキスト検索用の文字列を抽出しているが、ファセット対象ではないデータもヒットするようにすべきか。 例えばOrganismではRefSeqデータにあるTaxonomyID(と上位の6614件)だけがファセット検索の対象となっているが、organism_nameのように全て(120万件)のTaxonomyIDに値が含まれるスタンザもある。この場合、大半の生物種名検索にヒットしない事になる。 同じようにphenotypeやpathogen,strain等もRefSeqで扱うTaxonomyID以外のデータを持つものも多くある。 geneの場合にはrecommendedNameを持つUniProtに紐づくgeneだけがファセット検索の対象となっており、現データでは180万程度だが、UniProtを介さなければ1000万程が対象となる。

データ構築の流れ

TogoGenomeのデータ更新のタイミングで、各スタンザで使用されている文字列を検索用のリストを出力し、検索エンジンが取り込めるようにする

  • 1. TogoGenomeのRDF更新
  • 2. DBファイルのコピー(テキスト検索用にリーズニングデータを追加するため、追加前の元ファイルを保存する)
  • 3. リーズニングデータの生成とロード(テキストデータ抽出用クエリを高速化する)
  • 4. テキストデータ抽出用クエリを実行
  • 5. 検索エンジン用に整形(JSON形式)
  • 6. 検索エンジンの全データ更新

リーズニングデータ生成

テキストデータ抽出用クエリの発行に先立ち、高速化のため(耐えうるスピードにするため)にリーズニングが必要になる場合がある。
主に次のケースで必要になる。

  • 大量のURIの一意リストを少ない条件で抽出する

検索対象とするgeneやproteinのリストはtgupグラフから取得できるが、トリプルパターン複数を経る必要があり速度が遅くなるため、あらかじめ一意なリストだけを抽出したグラフを用意する。
例: ファセット検索の対象となっているProteinIDの一覧を抽出するクエリ

DEFINE sql:select-option "order"
PREFIX up: <http://purl.uniprot.org/core/>
SELECT DISTINCT ?uniprot
WHERE {
  GRAPH <http://togogenome.org/graph/tgtax>
  {
    ?taxonomy_id rdfs:subClassOf <http://identifiers.org/taxonomy/1>
  }
  GRAPH <http://togogenome.org/graph/taxonomy>
  {
    ?taxonomy_id rdfs:label ?taxonomy_name .
  }
  GRAPH <http://togogenome.org/graph/tgup> {
  ?togo_gene rdfs:seeAlso ?taxonomy_id .
  ?togo_gene skos:exactMatch ?refseq_gene .
  ?togo_gene rdfs:seeAlso ?id_uniprot .
  ?id_uniprot a <http://identifiers.org/uniprot> .
  ?id_uniprot rdfs:seeAlso ?uniprot.
  }
  GRAPH <http://togogenome.org/graph/uniprot> {
  ?uniprot a up:Protein ;
    up:recommendedName/up:fullName ?recommended_name .
 }
}
  • プロパティパスで階層を辿っているものをフラットに繋げる

スタンザクエリの中でsubClassOf*等のプロパティパスを使って再帰的に階層を辿るクエリが書かれている場合、検索対象件数が膨らむとエラーになったりサーバメモリを使い切ったりする挙動がみられる。これらは予め展開したデータを持つグラフを用意する
例: UniProtのアノテーションの階層情報を展開したトリプルを生成するクエリ

PREFIX up: <http://purl.uniprot.org/core/>

CONSTRUCT
{
  ?type rdfs:subClassOf ?parent_type
}
FROM <http://togogenome.org/graph/uniprot>
WHERE
{
  {
    SELECT DISTINCT ?type
    {
      ?protein up:annotation ?annotation .
      ?annotation rdf:type ?type .
    }
  }
  ?type rdfs:subClassOf* ?parent_type .
}

テキストデータ抽出用クエリ

テキストデータ抽出用クエリの発行

検索速度、結果行数によって発行方法を変更する。以下の候補の上から優先的に検討する

  • エンドポイント経由(HTTPリクエスト)

クエリの速度が十分に速く、結果件数が設定最大行数(デフォルトで1万行)を超えない場合には、エンドポイント経由で問い合わせる

  • ODBC経由

エンドポイントではタイムアウトしたり(デフォルト1分)検索結果行数オーバーで一部しか返ってこなかったりする場合には、ODBC経由で問い合わせる
この方法ではクエリが終わった後にRubyオブジェクトに格納する際に、非常に時間とメモリを消費する(Rubyのsequel使用時)。何時間も掛かる場合にはisqlでの出力を検討する

  • isql経由

ODBC経由でクエリの結果を処理するRuby側でメモリ消費量が酷い場合にはisql経由で結果を取得した方がメモリ量も抑えられ速度も速い
ただし、クエリはプレーンテキストで返って来るため、項目の区切り文字となるカラムを差し挟んでやる必要がある

SELECT ?protein ("   -||-   " AS ?delimit1)
  GROUP_CONCAT(DISTINCT ?category; separator = ",") AS ?xref_categories  ("   -||-   " AS ?delimit2)
  GROUP_CONCAT(DISTINCT ?abbr; separator = ",") AS ?xref_abbrs  ("   -||-   " AS ?delimit3)
  GROUP_CONCAT(DISTINCT ?ref; separator = "||") AS ?xref_uris

その後、区切り文字で分割して項目を整形する。


検索エンジン用JSON形式

※検討中!

検索用テキストデータ

カテゴリ毎(Organism,Environment等)に出現するテキストデータを含んだjsonファイル。カテゴリのID単位の配列(orハッシュ)で出力される。

  • Organismのテキストデータ(抜粋)

項目データがない場合には空白文字を出力

  {
    "tax_no": "135616",
    "refseq_definitions": "",
    "bioproject_ids": "",
    "refseq_ids": "",
    "xref_ids": "",
    "gold_ids": "",
    "name": "Piscirickettsiaceae",
    "synonyms": "Piscirickettsia group,Piscirickettsiaceae,Piscirickettsiaceae Fryer and Lannan 2005",
    "phenotypes": "",
    "strain_numbers": "",
    "strain_names": "",
    "culture_isolations": "",
    "culture_environments": "",
    "culture_applications": "",
    "other_cultures": "",
    "pathogen_strain_names": "",
    "disease_names": "",
    "infectious_types": "",
    "pathogen_strain_types": ""
  },

スタンザ対応一覧

検索用テキストデータの項目がどのスタンザに含まれているかを定義する設定ファイル。

  • Organismの対応データ(抜粋)

値が["id"]となっているものはキー項目を表し、その他はスタンザ名を配列で記述している。

{
    "tax_no": ["id"],
    "name": ["organism_names”],
    "synonyms": ["organism_names"],
    "refseq_definitions": ["genome_cross_references","genome_information"],
    "bioproject_ids": ["genome_cross_references","organism_cross_references"],
    "refseq_ids": ["genome_cross_references","organism_cross_references","genome_information"],
    "xref_ids": ["genome_cross_references","organism_cross_references"],
    ・・・
}

課題・懸案

検索範囲

現状はファセット検索対象だけのデータに絞っているが、範囲を広げるべきか See

TogeGenomeエンドポイント以外のデータ

スタンザ内で別のエンドポイントにクエリを投げている場合、そのデータをあらかじめ取得するのが困難(できなくはないが、相手サーバに負荷が掛かる)See

個人用ツール