PubMedの怪

PubMed検索の利用例として、しばしば特定の論文のタイトルをそのまま貼り付けて書誌情報を取得することがあります。PubMedに収められている論文のタイトルを丸ごと入力して検索すると、「See 1 citation found by title matching your search:」という表示とともに、直接書誌情報が表示されます。これはつまりPubMedが、一つまたは複数のキーワードが入力された場合とは異なる、タイトルにマッチさせるための検索手法を、入力された内容に基づき暗黙のうちに選択していることを示しています。

さて、このタイトルマッチの検索を明示的にPubMedに伝えて行うこともでき、それには二通りの方法があるのですが、両者は同じ検索語であっても結果が異なる場合があるので記録しておきます。ここではプログラムからアクセスすることを想定して、NCBIの提供するAPIであるE-Utilitiesを用いるものとします。詳細はEntrez Programming Utilities Helpに記述されていますが、「field」の項目に以下の記述があります。

Search field. If used, the entire search term will be limited to the specified Entrez field. The following two URLs are equivalent:

esearch.fcgi?db=pubmed&term=asthma&field=title

esearch.fcgi?db=pubmed&term=asthma[title]

ここで、両者は「equivalent」と書いてあるのですが、上述の通り、実際は得られる結果が異なるときがあり、一方の検索方法では一件しかマッチしないにもかかわらず、他方では複数マッチしたり、一件もマッチしなかったりなどの事例を確認しています。

冒頭で記述したように、通常のウェブブラウザからPubMedにアクセスし、それなりの語数のあるタイトルをそのまま入力して検索するとタイトルマッチ検索が行われますが、これは実際には一部のストップワードを除き、入力されたすべての語に対して[title]フィールドオプションを暗黙のうちにつけることで実現しています。このような処理が行われていることは、右側のペーンにある「Search details」を見ることで確認できます。つまり、この場合はE-Utilitiesの説明における後者の手法が取られていることになります。

以上の理由により、求める論文のPubMedIDを一回で特定する可能性を高めるためには、両者を併用する必要があることがわかりました。

gitでコミット済のファイルを消去後に復活させる

最近は http://bitbacket.org/ を利用してプロジェクト関連のファイルを全てレポジトリに保存しているのだが、昨日コミット&プッシュの後に誤ってファイルを別の内容で上書きしてしまった。

はいはい、こういうときには簡単に復活できるんだよね、と思いその方法を探ってみると‥。

意外と手間のかかる操作ということが判明したので、備忘録を兼ねて記録しておくことにした。情報源はこちらこちら
一度コミット&プッシュすればレポジトリにその内容は保存されているので、復活させること自体は当然出来るのだが、そのために必要な処理は大きく分けると二つある。一つはファイルを復活させることであり、そしてもう一つは、復活後に引き続き作業結果を滞り無くコミット&プッシュするための準備作業である。これを忘れると、以後、コミットは問題無いが、プッシュしても「Everything up-to-date」と表示され続けることになる。

ファイルの復活

以下の要領で、消去したファイルの最後のコミットIDを取得する。

git rev-list -n 1 HEAD -- < 消去したファイルパス>

そのIDを利用して次のコマンドを発行する。

git checkout < コミットID>^ -- < 消去したファイルパス>

以上の2階の操作を一回で済ます方法は以下の通り。

git checkout $(git rev-list -n 1 HEAD -- "$file")^ -- "$file"

以上で無事復活。ただし、タイムスタンプは戻らないようだ。

その後の作業

そしてファイル復活後に忘れずに行う作業は以下の通り。

1. 最初に一時ブランチを作る。これでファイル復活時に行った、どこにも関連づいていないHEADという抽象的な名を持つコミットがこの一時ブランチに向けられる。

git branch temp
git checkout temp

上記二回の操作は以下の一度の操作に置き換え可能。

git checkout -b temp

2. 続いて本来のブランチとの比較をして問題ないことを確認する。

git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp
git diff master temp
git diff origin/master temp

3. そして本来のブランチが一時ブランチを指すようにする。

git branch -f master temp
git checkout master

上記二回の操作は以下の一度の操作に置き換え可能。

git checkout -B master temp

4. 最後に一時ブランチを削除して、

git branch -d temp

レポジトリにプッシュする。

git push origin master

オントロジーエディタprotégéを使う

2013年10月8日に行われた第7回LinkedData勉強会にて「オントロジーエディタprotégéを使う」と題してprotégéの使い方を簡単に紹介しました。時間がおしていたことなどから非常に駆け足の説明となり、分かりにくい点が多々あったと思います。その後、スライドを見るだけでもなるべく分かるようにするために若干加筆修正をしてslideshareにアップしました。


protégé全体の説明を詳細にすることは困難なので、ひとまず、起動して何をしていいのか分からない、という状況にならないような紹介にしようと思いました。非常に簡単な事例を除いて、最初から思い描いていた通りのオントロジーを構築することはほぼ無理なので、実際の作業としては、オントロジーを作る → それを利用したデータセットを構築する → アプリケーションなどから利用する → 問題を見つける → オントロジーを更新する、の繰り返しが何度か続くことになると思います。なお、今回の資料では推論について全く触れていません。これはprotégéを使い始めるにあたり、推論の知識は必ずしも必要ではないとの判断からです。

また、プロパティの特徴としてFunctional以外については説明を省略しています。これについては、W3CのOWLリファレンスを参照して頂ければと思います。日本語訳もあります。本リファレンスは文字通りOWLについて、プロパティの特徴だけでなく、OWLについて全般的に書かれており、勉強会で紹介したprotégéがOWL2オントロジーをサポートし、Protege-OWLと呼ばれていることも併せて、protégéの提供する編集機能がOWLの仕様と非常によく対応づけられていることが分かります。protégéを利用する際にはこちらを参照するとその操作方法について理解が深まると思います。

参考資料として、スライド中で紹介したもののほかに、古いものもありますが、開発元のサイトに載せられている文書も読んでみると良いと思います。

とはいえ、オントロジーを作るという課題は資料を読むだけでなく、実際に自分で手を動かしてみないと理解しにくいものなのでしょうね。

なお、protégéのダウンロードはここから出来ます。

トリプルストア内の情報を得るサンプルクエリ集

CodeMirrorを使って幾つかのSPARQLクエリのサンプルを列挙してみることにした。

グラフ一覧と各グラフに含まれるトリプル数を取得する
実際にインスタンスをもつクラス一覧と、クラス定義があればその情報も含め、各クラスに含まれるインスタンス数を取得する

トリプルには重複が含まれていることがあるので、念のために distinct を入れている。また、Virtuoso関連クラスを除外するためのフィルタを加えている。

実際に述語としてトリプルを構成する述語一覧と、そのクラス定義があればその情報も含め、各述語が含まれるトリプル数を取得する

なお、ここで使用している distinct * のカウントはVirtuosoでは受け付けられないことが判明したので注意。今後発表されるバージョンでは使えるようになるかもしれない。


今回、相当数のトリプルを検索するSPARQLクエリを様々なエンドポイントに対して試してみたが、実際の結果が得られることは皆無であった。
より検索範囲の小さなものであれば問題無いだろうが、検索対象のデータベースの特徴をある程度ここに掲載したような方法で取得できる統計データなどとともに概観できたほうがより効率的な検索が出来るようになると思う。その他に各クラスの取る代表的な述語や各述語に対する主語や目的語のクラスなども簡単に分かるようになっていると助かる。というのもデータベース提供者以外はそこにあるデータの特徴や構造を通常よく知らないわけなので、どのようなクラスがあり、そこにどれだけのインスタンスがあるかという情報は貴重な参考情報になるからだ。もっともオントロジーがしっかり定義されていたり、voIDなどのデータが用意されていれば、分かることも多いが。また、データ提供者側においても生成されたデータが期待通りになっているのかを確認するため、あるいは、voIDなどのメタデータの生成も含め、得られた情報を予めエンドポイントに表示するためなどの目的で使うと有益だろう。
同様の統計データを取得するSPARQLクエリ集としてこちらのサイトがある。

SPARQL editor test

CodeMirrorを使ったSPARQLクエリのハイライト表示を試すついでに、実際にSPARQLエンドポイントに投げられるようにしてみた。ソースコードは下にある通りで、とても簡単にブログやサイトに埋め込めることから、サンプルクエリを提示する時に使うのも良いと思う。

Endpoint:

<link rel="stylesheet" href="http://codemirror.net/lib/codemirror.css">
<script src="http://codemirror.net/lib/codemirror.js"></script>
<script src="http://codemirror.net/addon/edit/matchbrackets.js"></script>
<script src="http://codemirror.net/mode/sparql/sparql.js"></script>
<style>.CodeMirror {border-top: 1px solid black; border-bottom: 1px solid black;}</style>

<form>Endpoint:<input type="text" size="50" id="epuri"></input><br />
<textarea id="code" name="code"></textarea>
<button type="button" onclick="iq();"><b>Issue Query</b></button></form>
<script>
var editor = CodeMirror.fromTextArea(document.getElementById("code"), {
mode: "application/x-sparql-query",
tabMode: "indent",
matchBrackets: true
});
var iq=function(){
  window.location.assign(document.getElementById("epuri").value+"?query="+encodeURIComponent(editor.getValue()));
}
</script>

ハッカソンとバイオハッカソン

最近ハッカソンという言葉が巷で広がり始めているようなので、まとめておくことに。なお、ここに書かれている内容は筆者の個人的な思いであり、バイオハッカソンのオーガナイザーや主催者を代表しているものではないことを予めお断りしておく。

さて、日経ビジネスwebR25の記事を読んでみると、これまでDBCLSが中心として進めてきたそれとは少々スタイルが異なるものであることが分かる。DBCLSでは、様々な組織の協力を頂きながら、バイオハッカソンという名称で2008年から毎年ハッカソンを開催している。バイオハッカソンでは約一週間、原則として朝から晩まで食事以外は全て開発もしくは開発のための議論に時間が充てられる。開発成果に対する優劣はつけず、また賞品の授与も無い。ハッカソン全体の進み方はこうだ。最初に参加者間で課題を幾つか出し合い、それぞれに対応したチームが構成され作業が開始される。その後は適宜情報共有のためのセミナー的な場が同時並行的に、興味のある人が集まる形で開催されながら開発や議論が続く。そして最終日に成果を報告する形式となっている。なお、ハッカソンに先立ち、シンポジウムが行われているが、ハッカソンではないのでここでは記述しない。参加者については、2008年の第一回から数回はハッカソンのオーガナイザーが国内外を問わずにテーマに沿う活動を進めていると判断される招聘者を決定し、招待に応じて頂いた方に参加して頂いていたが、最近は予算の都合もあり、原則海外居住者は招聘で国内からの参加については事前登録さえすれば自費で誰でも自由という方針で運営されている。参加者の多くは学術機関に所属する研究者やシステム開発者である。
Read more »

Linked Open Dataの構築に関する論文の出版

2013年の3月13日にLinked Open Dataの構築についての論文が出版されました。これは、生命科学分野の略語に関するデータベースAllieとRDF化されたWikipediaのデータベースDBpediaの間のリンクを自動生成する試みを報告したものです。

Allieを検索すると分かりますが、1つの略語に対して、その本来の表現である展開形が複数存在することは多く(略語の多義性、例えばSPF)、複数の候補が提示された場合には、実際に自分が求めている展開形がそれらのうちのどれに当たるのかを簡単に知ることが出来れば有益であると思います。しかし現時点ではAllieで略語を検索しても、各展開形の意味は書かれていません。本機能を実現するためには各展開形の辞書が必要となるわけですが、その数は180万弱と膨大で全てを我々が構築することは不可能です。しかも、既に同様の資源があり、それを適切に利用できるならば、新たに手間と暇をかける必要は無いわけです。そしてDBpediaがまさにそれに当たるものと考えました。何故ならば、自由にデータベースを丸ごとダウンロード可能だからです。首尾よくAllie中の展開形に対応するDBpediaのエントリがあれば、そこには解説記事が書かれていることになり、Allieの利用者は効率的に自身の求めている略語の意味を知ることが出来るようになるでしょう。
Read more »

セマンティックWebコンファレンス2013での発表

先日、2013年3月7日(木)に開催されましたセマンティックWebコンファレンス2013にて発表する機会を頂きました。関係者の皆様、どうもありがとうございます。
コンファレンスのページからでもPDFファイルとして発表資料を取得できますが、slideshareにもアップしましたのでこちらに告知します。引き続きLODが普及し、様々な知識の再利用性が高まるよう、出来ることを行っていきたいとお思います。

発表時間としてはギリギリだったので、詳しく説明しませんでしたが、LODを基盤として知のReduce、Reuse、Recycleが進むことを願っています。
これは、すなわち、LODの普及に伴い、車輪の再発明を減らし(Reduce)、先人の知恵を再利用し(Reuse)、それに基づく新しい知識を生み出す(Recycle)ことが以前よりも増して効率的に実現されれば、という私の考えです。


SPARQLを使い込む 補足

第5回LinkedData勉強会が先日開かれて「SPARQLを使い込む」と題した発表をさせていただきました。


ここでは発表中に口頭でのみお伝えした点やお伝えしきれなかった点について補足しておきます。
SERVICEキーワードを利用したfederated queriesではリモートのSPARQLエンドポイントに対して容易に大量のデータを返す様なクエリを発行出来てしまいます。従ってこの便利な機能を使う際には、実際にリモートに投げられるクエリを想定して行うのが良いと思います。
クエリの構造として同じスコープにある変数の場合、実際にクエリに書かれている順番にバインドされていくわけではないので、リモートに投げられる時点で、記述したクエリの変数のいずれかがバインドされていることを想定することが出来ません。従って、探索空間が非常に広くなりえることに注意が必要と思います。

SELECT * WHERE {
  ?s ?p ex:obj1213 .
  SERVICE  {
    ?s xe:pred22 ?o .
  }
}

このような場合で、仮に ex:obj1213 を目的語にもつ主語が一つしかなかったとしても、リモートに投げられるクエリには ?s に当該主語がバインドされているとは限らないので、xe:pred22 を述語にもつ全ての主語と目的語の組を探すことになり得ます。

それから、SPARQL1.1で加わった機能のうち、発表中に触れなかった主な項目としてデータベースの更新系があります。CRUDの、Create / Update / Delete が出来るようになっています (参考)。その他、クエリに関しては、以下の機能が1.1になり新たに加わっています (参考)。

このうち、まず、Aggregatesについては、数値処理の集合演算であるCOUNTSUMなどを除いて紹介していませんが、これらに加え、SQLでお馴染みのGROUP BYHAVINGが使えるようになっています。
また、一つのクエリ表現で複数の述語にマッチさせられる表記法法、Property Pathsについて全く触れておりません。これについては去年の第2回LinkedData勉強会で加藤さんがSPARQLの基礎と題して説明されていますのでご参照願います。
その他、CONSTRUCTの短縮表現についても扱っていません。これはCONSTRUCT WHEREと記述するもので、CONSTRUCTキーワード後のグラフパターンを省略出来る表現方法です。これは、WHERE直後のグラフパターンが単純であるときに使えます。つまり、FILTERキーワードや複雑なグラフパターンが含まれてなく、そのパターンがそのままトリプルとして取り出せる様なクエリであることが条件になります。詳細は上記リンク先をご確認ください。

Perlでutf8 – パイプとmysql (DBI)

Perlで標準入出力を使うことはよくあることで、use Encode;宣言をした後に、binmode STDIN, “encoding(utf8)” や open($fh, “:encoding(utf8)”, $fn) とするなどしてutf8文字が適切に処理されるようにするが、パイプを利用する場合、STDIN/STDOUT に対する binmode では適切に処理がなされないので、open関数に対する設定を用いる必要がある。たとえば、

open($fh, "-|:encoding(utf8)", $command);

とする。

また、DBIモジュールを用いたMySQLとのやりとりで適切にutf8文字を処理させるためには、DBI->connectを行う際に、mysql_enable_utf8 => 1を明示する必要がある。すなわち、

my $dbh = DBI->connect("dbi:mysql:$dbname;$host:$port", $user, $pass,
{mysql_enable_utf8 => 1});

といったイメージ。なお、これはMySQLサーバーに対するutf8の設定も適切に行われていることが条件。
MySQLコンソールで下記のコマンドを発行すると状況が確認出来る。

show variables like "char%";

これに対して以下の様な結果が得られれば問題無し。

+--------------------------+--------------------------------------------------------+
| Variable_name            | Value                                                  |
+--------------------------+--------------------------------------------------------+
| character_set_client     | utf8                                                   | 
| character_set_connection | utf8                                                   | 
| character_set_database   | utf8                                                   | 
| character_set_filesystem | binary                                                 | 
| character_set_results    | utf8                                                   | 
| character_set_server     | utf8                                                   | 
| character_set_system     | utf8                                                   | 
| character_sets_dir       | /usr/local/mysql/5.0.91/share/mysql/charsets/          | 
+--------------------------+--------------------------------------------------------+

参考サイト