UIMA の概要と SDK のセットアップ

作成およびメンテナンス: Apache UIMA 開発コミュニティ

Version 2.4.0

ライセンスと免責。本ドキュメントは Apache License Version 2.0(「本ライセンス」)に基づいてライセンスされます。あなたがこのファイルを使用するためには、本ライセンスに従わなければなりません。本ライセンスのコピーは下記の場所から入手できます。

適用される法律または書面での同意によって命じられない限り、本ライセンスに基づいて頒布されるソフトウェアは、明示黙示を問わず、いかなる保証も条件もなしに「現状のまま」頒布されます。本ライセンスでの権利と制限を規定した文言については、本ライセンスを参照してください。

商標。本文中で言及され、商標またはサービスマークであることが知られているすべての用語については、大文字を用いた適切な表記にしています。本巻におけるこれらの用語の使用については、該当する商標またはサービスマークの有効性を損なうものと解釈しないでください。

2011 年 11月


目次

1. 概要
1.1. Apache UIMA プロジェクトドキュメント概要
1.1.1. 概要
1.1.2. Eclipse ツールのインストールとセットアップ
1.1.3. チュートリアルおよび開発者ガイド
1.1.4. ツールユーザーガイド
1.1.5. リファレンス
1.2. ドキュメントの使い方
1.3. 以前のメジャーバージョンからの変更点
1.3.1. IBM UIMA 2.0 から Apache UIMA 2.1 への変更点
1.3.2. UIMA バージョン 1.x からの変更点
1.4. IBM UIMA から Apache UIMA への移行
1.4.1. 移行ユーティリティの実行
1.4.2. 手作業での移行
1.5. Apache UIMA サマリー
1.5.1. 全般
1.5.2. プログラミング言語のサポート
1.5.3. マルチモーダルサポート
1.5.4. セマンティック検索コンポーネント
1.6. Apache UIMA の機能のまとめ
2. UIMA コンセプト概観
2.1. UIMA 序論
2.2. アーキテクチャ、フレームワーク、および SDK
2.3. 分析の基礎
2.3.1. 分析エンジン、アノテータ、結果
2.3.2. 分析結果の CAS での表現
2.3.3. CAS と外部リソースの操作
2.3.4. コンポーネントディスクリプタ
2.4. 集約分析エンジン
2.5. アプリケーションの構築とコレクション処理
2.5.1. アプリケーションからの UIMA フレームワークの使用
2.5.2. コレクション処理へ
2.6. 分析結果の活用
2.6.1. セマンティック検索
2.6.2. データベース
2.7. UIMA におけるマルチモーダル処理
2.8. 次のステップ
3. UIMA を使うための Eclipse IDE のセットアップ
3.1. インストール
3.1.1. Eclipse のインストール
3.1.2. UIMA Eclipse プラグインのインストール
3.1.3. 追加の Eclipse コンポーネントの手動インストール: EMF
3.1.4. UIMA SDK のインストール
3.1.5. UIMA Eclipse プラグインの手動インストール
3.1.6. Eclipse の起動
3.2. Eclipse によるサンプルコードの表示
3.3. jar ファイルへの UIMA ソースコードの追加
3.4. UIMA Javadoc の添付
3.5. Eclipse からの外部ツールの実行
4. UIMA FAQ
5. 既知の問題
用語集

第 1 章 UIMA の概要

UIMA (Unstructured Information Management Architecture) は、多種多様なマルチモーダル分析機能を作成、発見、合成、デプロイし、これらの分析機能を各種の検索技術と統合するためのアーキテクチャおよびソフトウェアフレームワークです。UIMA アーキテクチャは、OASIS の技術委員会によって UIMA 仕様として標準化が進められています。

Apache UIMA フレームワークは、この UIMA アーキテクチャの Apache ライセンスによるオープンソースの実装で、開発者が自分の開発した UIMA コンポーネントの実装をプラグインして実行することができる実行時環境を提供します。開発者は、Apache UIMA フレームワークが提供する実行時環境を使って、UIM アプリケーションを構築、デプロイすることができます。UIMA フレームワーク自体は、特定の IDE やプラットフォームに依存しません。

フレームワークには、UIMA コンポーネントとアプリケーションの開発、記述、合成、およびデプロイするための UIMA フレームワークをすべて Java で実装したものが含まれています。また、開発者向けに Eclipse ベース (http://www.eclipse.org/) の開発環境が提供されており、UIMA を使うための各種ツールやユーティリティが用意されています。Apache UIMA フレームワークには、C++ バージョンのフレームワーク、さらに Perl、Python、TCL で記述されたアノテータ用のイネーブルメントも含まれています。

この章は、Apache UIMA プロジェクトに初めて触れる読者にふさわしい解説となることを意図して書かれています。本章には、この序の部分と以下のセクションがあります。

Apache UIMA のメイン Web サイトは http://uima.apache.org です。サイトでは、次のものをはじめとするさまざまな情報を入手できます。

  • ダウンロード方法 (バイナリおよびソースディストリビューション)

  • 開発に参加する方法

  • メーリングリスト - 質問と回答が寄せられるフォーラムのように使われているユーザー向けリストなど

  • ヒントやベストプラクティスなど、あらゆる種類の情報を参照、コントリビュートできる Wiki

  • sandbox - Apache UIMA またはそのサブプロジェクトへの機能追加の可能性を試すサブプロジェクト。ここにあるものは、作業が進行中のものなので、リリースに含まれるとは限りません。

  • さまざまなカンファレンスへのリンク

1.1. Apache UIMA プロジェクトドキュメント概要

UIMA のユーザードキュメントは、以下のいくつかの部分に分かれています。

  • 概要 - このドキュメント

  • Eclipse ツールのインストールとセットアップ - 同じくこのドキュメントにあります

  • チュートリアルおよび開発者ガイド

  • ツールユーザーガイド

  • リファレンス

最初の 2 つの部分が本巻を構成しており、残りの 3 つの部分はそれぞれ独立した巻になっています。各巻は、ブラウザでそのまま表示可能な (若干サイズの大きい) html ファイルのほか、PDF ファイルでも提供されています。ドキュメントは完全にハイパーリンクに対応しており、目次が用意されています。PDF バージョンは印刷に適したレイアウトが採用されていて、各巻内の相互参照部分にはページ番号が表示されるようなっています。

PDF のブラウザ内表示をサポートしているブラウザで PDF ファイルを表示すれば、異なる巻の間のハイパーリンクも機能すると思われます (すべてのブラウザでテストされているわけではありません…)。

以下では、ドキュメントの各部について、より詳細な概要を表形式で示します。

1.1.1. 概要

ドキュメントの概要

現在読んでいるこの文書のことです。Apache UIMA ドキュメントセットに含まれているドキュメントのリストを示し、UIMA を使えるようになるためにはどのようにドキュメントを読み進めていけばよいかについて説明しています。リリースノートのほか、Apache UIMA プロジェクトに含まれるさまざまなソフトウェアモジュールについての簡単な説明もあります。「セクション 1.1 Apache UIMA プロジェクトドキュメント概要」を参照してください。

コンセプト概観 UIMA コンポーネントアーキテクチャの大まかなコンセプト概観を示します。ドキュメントセットのほかの部分への参照が含まれており、さらに詳しい情報を得ることができるようになっています。「第 2 章 UIMA コンセプト概観」参照してください。
UIMA FAQ UIMA のコンセプト全般に関する FAQ。(プログラミングリソースではありません。) 「第 4 章 UIMA FAQ」を参照してください。
既知の問題 UIMA SDK の既知の問題です。「第 5 章 既知の問題」を参照してください。
用語集 UIMA の用語とコンセプト、および基本的な定義。「用語集」を参照してください。

1.1.2. Eclipse ツールのインストールとセットアップ

Apache UIMA を Eclipse IDE にインストールする手順について説明しています。「第 3 章 UIMA を使うための Eclipse IDE のセットアップ」を参照してください。

1.1.3. チュートリアルおよび開発者ガイド

アノテータおよび分析エンジン UIMA のアノテータおよび分析エンジンを作成するためのチュートリアル形式のガイド。この章では、型システムの作成と、UIMA の共通データ構造である CAS (Common Analysis Structure) の使い方について説明しています。組み込みツールを使ってベーシックな UIMA 分析コンポーネントを指定、作成する方法を実例を使って説明しています。「第 1 章 アノテータおよび分析エンジン開発者ガイド」を参照してください。
UIMA CPE の構築 UIMA CPE (Collection Processing Engine) を構築するためのチュートリアル形式のガイド。CPE は、ソースからシンクまで、ドキュメントのコレクションの分析を管理します。「第 2 章 CPE 開発者ガイド」を参照してください。
完全なアプリケーションの開発 UIMA API を使ってアプリケーションから UIMA コンポーネントを作成、実行、管理する方法について説明したチュートリアル形式のガイド。XMI® と呼ばれる XML 形式を使って CAS の内容を保存、復元するための API についても説明しています。「第 3 章 アプリケーション開発者ガイド」を参照してください。
フローコントローラ (Flow Controller) 複数のコンポーネントが 1 つの集約分析エンジンにまとめられている場合、各 CAS はさまざまなコンポーネントを経由していきます。UIMA では 2 つの組み込みフローを提供していますが、カスタムフローを実装することもできます。「第 4 章 フローコントローラ開発者ガイド」を参照してください。
複数の Sofa を使ったアプリケーションの開発 単一の CAS に複数の Sofa (subjects of analysis) が関連付けられていることがあります。これらの Sofa は、同じドキュメントの異なる形式や翻訳を表現して分析するときに便利です。マルチモーダル分析の場合、Sofa は同一ストリームの異なるモーダル表現 (音声と字幕など) に向いています。この章では、アプリケーション内で複数の Sofa を使う方法について説明しています。「第 5 章 アノテーション、アーティファクト、Sofa」を参照してください。
1 つのアーティファクトに対する複数の CAS ビュー UIMA では、CAS 基本モデルの拡張を提供しており、この拡張によって、CAS に含まれている同一アーティファクトの複数のビューの分析をサポートしています。この章では、このようなサポートを可能にするためのコンセプト、用語、および API と XML 拡張について説明しています。「第 6 章 1 つのアーティファクトに対する複数の CAS ビュー」を参照してください。
CAS マルチプライヤ (CAS Multiplier) コンポーネントは、追加の CAS をワークフローに加えることができます。これは、大規模なアーティファクトをより小さな単位に分割したり、ほかの複数の CAS からデータを収集する新しい CAS を作成したりするときに便利です。「第 7 章 CAS マルチプライヤ開発者ガイド」を参照してください。
XMI と EMF の相互運用性 UIMA の型システムと CAS それ自体の内容は、XML メタデータのための XMI 標準を使って外部化することができます。EMF (Eclipse Modeling Framework) ツールを使えば、この情報を使うアプリケーションを開発することができます。「第 8 章 XMI と EMF の相互運用性」を参照してください。

1.1.4. ツールユーザーガイド

コンポーネントディスクリプタエディタ (Component Descriptor Editor) コンポーネントディスクリプタエディタの機能について説明しています。コンポーネントディスクリプタエディタは、分析エンジン (プリミティブまたは集約の両方) やコレクションリーダー、CAS コンシューマ、型システムなど、UIMA コンポーネントディスクリプタの詳細を指定するための GUI を提供します。「第 1 章 コンポーネントディスクリプタエディタ ユーザーガイド」を参照してください。
CPE コンフィギュレータ (Collection Processing Engine Configurator) CPE コンフィギュレータツールのユーザーインタフェースと機能について説明しています。CPE コンフィギュレータツールでは、CPE コンポーネントの選択と構成を行って、CPE を実行することができます。「第 2 章 CPE コンフィギュレータ ユーザーガイド」を参照してください。
PEAR パッケージャ (PEAR Packager) PEAR パッケージャユーティリティの使い方について説明しています。このユーティリティを使うと、分析エンジンをほかの UIMA 環境にインストールするのに必要なすべてのリソースも含めて、分析エンジンのアーカイブを作成することができます。「第 9 章 PEAR パッケージャ ユーザーガイド」を参照してください。
PEAR インストーラ (PEAR Installer) PEAR インストーラユーティリティの使い方について説明しています。このユーティリティは、アーカイブファイル (PEAR) から分析エンジンとそのリソースを適切な場所にインストールして検証し、分析エンジンを実行できるようにします。「第 11 章 PEAR インストーラ ユーザーガイド」を参照してください。
PEAR マージャ (PEAR Merger) 複数の PEAR パッケージを 1 つにマージする PEAR マージャユーティリティの使い方について説明しています。「第 12 章 PEAR マージャ ユーザーガイド」を参照してください。
ドキュメントアナライザ (Document Analyzer) 一連のドキュメントに対して UIMA 分析エンジンを適用して結果を表示するためのツールの機能について説明しています。「第 3 章 ドキュメントアナライザ ユーザーガイド」を参照してください。
CAS ビジュアルデバッガ (CAS Visual Debugger) CAS の詳細な構造と内容を表示するためのツールの機能について説明しています。デバッグ時に便利です。「第 5 章 CAS ビジュアルデバッガ」を参照してください。
JCasGen 特定の CAS 型システムに対応する Java クラスを自動的に構築する JCasGen ユーティリティの実行方法について説明しています。「第 8 章 JCasGen ユーザーガイド」を参照してください。
XML CAS ビューワ (XML CAS Viewer) 外部化された XML 形式の CAS を表示する付属ビューワの実行方法について説明しています。このビューワはサンプルで使われています。「第 4 章 アノテーションビューワ」を参照してください。

1.1.5. リファレンス

UIMA API Javadoc の説明 UIMA プログラミングインタフェースについて詳細に説明した Javadoc です。「第 1 章 Javadoc」を参照してください。
XML: コンポーネントディスクリプタ CPE を除くすべての UIMA コンポーネントの XML 形式について詳細に説明しています (CPE については下記を参照)。「第 2 章 コンポーネントディスクリプタリファレンス」を参照してください。
XML: CPE ディスクリプタ CPE ディスクリプタの XML 形式について詳細に説明しています。「第 3 章 CPE ディスクリプタリファレンス」を参照してください。
CAS 主な CAS インタフェースについて詳細に説明しています。「第 4 章 CAS リファレンス」を参照してください。
JCas CAS へのネイティブ Java インタフェースである JCas について詳細に説明しています。「第 5 章 JCAS リファレンス」を参照してください。
PEAR リファレンス UIMA コンポーネントのデプロイ可能アーカイブ形式について詳細に説明しています。「第 6 章 PEAR リファレンス」を参照してください。
XMI CAS シリアル化リファレンス UIMA コンポーネントのデプロイ可能アーカイブ形式について詳細に説明しています。「第 7 章 XMI CAS シリアル化リファレンス」を参照してください。

1.2. ドキュメントの使い方

  1. 本章を読んで、Apache UIMA に付属しているさまざまなドキュメントの概要を把握してください。

  2. 第 2 章 UIMA コンセプト概観」読んで、UIMA の基本的なコンセプトや考え方について理解してください。この章にはドキュメントセットのほかの部分への参照も含まれており、必要に応じて詳しい情報を得ることができるようになっています。

  3. UIMA アーキテクチャ、およびこのアーキテクチャがどのように使われてきたかについての全般的な情報については、オンラインで読める IBM Systems Journal の非構造化情報に関する特集号 http://www.research.ibm.com/journal/sj43-3.html を参照するか、Apache Web サイトの UIMA プロジェクトサイトで、ほかの刊行物の一覧を掲載している部分を参照してください。

  4. Apache UIMA を Eclipse 環境にセットアップします。具体的な手順は、「第 3 章 UIMA を使うための Eclipse IDE のセットアップ」で説明しています。

  5. サンプル UIMA アノテータを開発し、アノテータを実行して結果を確認します。「第 1 章 アノテータおよび分析エンジン開発者ガイド」をチュートリアルとして読んで、初めての UIMA アノテータを作成する方法、初めての UIMA 分析エンジンをセットアップして実行する方法について学んでください。

  6. アプリケーションの一部として UIMA 分析エンジンを作成、実行、管理する方法を学んでください。作成した分析エンジンを、提供されているセマンティック検索エンジンとつなげて、Apache UIMA を使って完全な分析、検索アプリケーションを構築する方法を学んでください。「第 3 章 アプリケーション開発者ガイド」は、このプロセスを実行するときに参考になります。

  7. お疲れさまでした。ここまでくればしめたもの。問題なくこの手順まで実行できたら、UIMA 分析エンジンのアーキテクチャについてはすでにかなり理解が深まっているはずです。シンプルながらも完全なアプリケーションの一部として、サンプルアノテータをいくつか作成し、UIMA 分析エンジンをデプロイしてドキュメントをいくつか分析し、付属のセマンティック検索エンジンを使って結果を検索し、付属のビューワを使って結果を表示していることでしょう。

  8. ドキュメントのコレクション全体を分析して結果を収集するために、CPE (Collection Processing Engine) を開発して実行してください。「第 2 章 CPE 開発者ガイド」は、このプロセスを実行するときに参考になります。

  9. 分析エンジンをパッケージ化してほかの UIMA 環境に簡単にインストールできるようにする方法を学んでください。「第 9 章 PEAR パッケージャ ユーザーガイド」と「第 11 章 PEAR インストーラ ユーザーガイド」では、UIMA 分析エンジンアーカイブを作成して、作成したコンポーネントをコミュニティの多くのユーザーと簡単に共有する方法について説明しています。

1.3. 以前のメジャーバージョンからの変更点

IBM の alphaWorks から入手可能な UIMA には、バージョン 1.4.x とバージョン 2.x の 2 つの以前のバージョンがあります (2.0 バージョンは "beta" のみのリリースです)。このセクションでは、これら 2 つのリリースの両方に関連する変更点について説明します。すでに作成済みの Java コードとディスクリプタをこのリリースで必要となる状態にアップデートするための移行ユーティリティが用意されています。移行ユーティリティの実行方法については、「セクション 1.4 IBM UIMA から Apache UIMA への移行」を参照してください。

注意

Apache UIMA の各リリースには、そのリリースでの変更点について説明した RELEASE_NOTES および RELEASE_NOTES.html ファイルが付属しています。Apache UIMA の各リリースでの具体的な変更については、これらのファイルを参照してください。

1.3.1. IBM UIMA 2.0 から Apache UIMA 2.1 への変更点

このセクションでは、UIMA のバージョン 2.0 とバージョン 2.1 の間で何が変わったのかについて説明します。次のセクションでは、バージョン 1.4 とバージョン 2.1 の違いについて説明します。

1.3.1.1. Java パッケージ名の変更

Apache UIMA では、UIMA Java パッケージ名がすべて変更されました。新しいパッケージ名は、com.ibm ではなく、org.apache から始まります。その他にも変更があります。パッケージ名セグメント reference_implimpl に短縮され、一部のセグメントは順序が変更されています。たとえば、com.ibm.uima.reference_impl.analysis_engineorg.apache.uima.analysis_engine.impl になりました。ツールは org.apache.uima.tools の下にまとめられ、サービスアダプタは org.apache.uima.adapter の下にまとめられました。

移行ユーティリティは、使われているすべての IBM UIMA パッケージ名を対応する Apache UIMA パッケージ名で置き換えます。パッケージ名のプリフィックスは置き換えないので、コードの中で com.ibm.uima.myproject という名前のパッケージを使っている場合 (これは推奨されませんが)、このパッケージ名は置き換えられません。

1.3.1.2. XML ディスクリプタの変更

UIMA コンポーネントディスクリプタにおける XML 名前空間は、http://uima.watson.ibm.com/resourceSpecifier から http://uima.apache.org/resourceSpecifier に変更されています。<frameworkImplementation> の値は、現在は org.apache.uima.java または org.apache.uima.cpp でなければなりません。移行スクリプトはこれらの置換を行います。

1.3.1.3. TCAS は CAS によって置き換えられました

Apache UIMA では、TCAS インタフェースは削除されました。このインタフェースを使っている場合は、すべて CAS インタフェースで置き換える必要があります。(TCAS で定義されていたすべてのメソッドは、v2.0 では CAS に移動しました。) メソッド CAS.getTCAS()CAS.getCurrentView() で置き換えられ、CAS.getTCAS(String)CAS.getView(String) で置き換えられています。次のものも削除され、相当する "CAS" のものに置き換えられています: TCASExceptionTCASRuntimeExceptionTCasPool、および CasCreationUtils.createTCas(...)

必要な置換は、移行スクリプトによって実行されます。

1.3.1.4. JCas はインタフェースになりました

以前のバージョンでは、ユーザーコードで直接 JCas クラスにアクセスしていました。Apache UIMA ではインタフェース org.apache.uima.jcas.JCas が用意され、JCas ベースのユーザーコードはすべてこのインタフェースを使わなければなりません。以前 JCas クラスにあった (JCasGen によって生成された JCas cover クラスによって呼び出される) static メソッドは、新しい org.apache.uima.jcas.JCasRegistry クラスに移されています。ユーザーのコードベースに含まれる JCas cover クラスも含めて、コードの中で必要な置換は、移行スクリプトによって実行されます。

1.3.1.5. JAR ファイル名が変更されています

UIMA JAR ファイル名が若干変更されています。Apache の名前付け規約に準拠させるため、アンダースコアはハイフンに置き換えられています。たとえば、uima_core.jaruima-core.jar になりました。また、uima_jcas_builtin_types.jar の名前は uima-document-annotation.jar に変更されています。さらに、jVinci.jar ファイルは、以前は lib/vinci ディレクトリにありましたが、現在では lib ディレクトリにあります。スクリプトファイルや Eclipse 起動構成などに対する必要な置換は、移行スクリプトによって実行されます。(移行ユーティリティがデフォルトで処理するファイル拡張子のリストについては、「セクション 1.4.1 移行ユーティリティの実行」を参照してください。)

1.3.1.6. セマンティック検索エンジンのパッケージ方法の変更

Apache に移行する前のバージョンの UIMA SDK には、セマンティック検索エンジンが付属していました。Apache バージョンにはこの検索エンジンは含まれていません。この検索エンジンはパッケージ方法が変更され、http://www.alphaworks.ibm.com/tech/uima から別に入手する形になりました。これは、Apache の Lucene 検索エンジンプロジェクトなど、オープンソースの検索エンジンを (いずれは) 採用することを念頭においたものです。

1.3.2. UIMA バージョン 1.x からの変更点

UIMA のバージョン 2.x では、新しい機能を提供するとともに、バージョン 1 と比べ、UIMA アーキテクチャの一部をより洗練されたものにしています。

1.3.2.1. 新機能

新しいプリミティブデータ型。UIMA は、Boolean (ビット)、Byte、Short (16 ビット整数)、Long (64 ビット整数)、および Double (64 ビット浮動小数点) のプリミティブ型、およびこれらの配列をサポートするようになりました。これらの型は、ほかのすべてのプリミティブ型と同様に使用できます。

よりシンプルになった分析エンジンと CAS。バージョン 1.x では、分析エンジンとテキスト分析エンジンを区別していました。バージョン 2 ではこの区別がなくなり、新しいコードでは分析エンジンを参照するだけで済むようになっています。分析エンジンは、テキストを含むさまざまな種類のアーティファクトを処理できます。

よりシンプルになった Sofa と CAS ビュー。複数の Sofa および Sofa に対応する CAS ビューを操作するための API がよりシンプルになっています。

複数の新しい CAS 出力をサポートするよう分析コンポーネントを一般化。一般に分析コンポーネントは新しい機能を使って、渡された元の CAS に加えて、複数の新しい CAS を返すことができます。これによって、コンポーネントにコレクションリーダーのような機能を持たせることができ、さらにフローの中の任意の場所にコンポーネントを置くことができるようになっています。「第 7 章 CAS マルチプライヤ開発者ガイド」を参照してください。

ユーザーのカスタマイズしたフローコントローラ。新しいコンポーネントであるフローコントローラをユーザーが用意して、集約分析エンジン内の CAS を対象に任意のフローコントロールを実装することができます。このフローコントロールは、組み込みの 2 つのフローコントロールである直線的 (リニア) なフローと言語機能によるフローとに加えて利用できます。「第 4 章 フローコントローラ開発者ガイド」を参照してください。

1.3.2.2. その他の変更点

新しい追加のアノテータ API ImplBase。2.1 以降、UIMA には新しい一連のアノテータインタフェースが追加されています。アノテータは今後、v1.x の TextAnnotator_ImplBase と JTextAnnotator_ImplBase の代わりに、CasAnnotator_ImplBase または JCasAnnotator_ImplBase を継承する必要があります。v1.x のアノテータインタフェースに変更はなく、後方互換性のために依然としてサポートされます。

新しいアノテータインタフェースは、ResultSpecifications に対する変更されたアプローチと、変更された例外名 (下を参照) をサポートしており、CollectionProcessComplete と BatchProcessComplete も含めて、CAS コンシューマが持つすべてのメソッドを持っています。

合理化された UIMA 例外。バージョン 1 では、AnalysisEngine のメソッドと、アノテータの対応するメソッドとで例外が異なっていましたが、バージョン 2 でこれらはマージされました。

  • AnnotatorProcessException (v1) AnalysisEngineProcessException (v2)

  • AnnotatorInitializationException (v1) ResourceInitializationException (v2)

  • AnnotatorConfigurationException (v1) ResourceConfigurationException (v2)

  • AnnotatorContextException (v1) ResourceAccessException (v2)

以前の例外も依然として利用可能ですが、新しいコードでは新しい例外を使う必要があります。

注意

typeSystemInit のシグニチャは throws 節が変わって AnalysisEngineProcessException をスローするようになっています。以前の基本クラスを継承するアノテータでは、後方互換性のために以前の typeSystemInit の定義でも動作するようになっています。

結果仕様の変更。バージョン 1 では、process(...) メソッドは 2 番目の引数として ResultSpecification を取っていました。現在では、結果仕様は変更があった場合にセットされるようになっており、これをローカルフィールドに格納して必要なときに利用できるようにするのはアノテータの役割になっています。このアプローチによって、アノテータは結果仕様が変更されたときに特定のシグナル (メソッド呼び出し) を受け取ることができます。以前は、変更があったかどうかを呼び出しのたびにチェックする必要がありました。デフォルトの impl base クラスにはそのための set/getResultSpecification(...) メソッドが用意されています。

機能セットは 1 つだけ。バージョン 1 では、複数の機能セットを定義できます。これらの機能セットは十分にはサポートされておらず、バージョン 2 ではシンプルになって、使用できる機能セットは 1 つだけになりました。(後方互換性のために、機能セットを複数使っている場合でも、当面は問題は生じません。)

TextAnalysisEngine は非推奨になりました。代わりに AnalysisEngine を使ってください。TextAnalysisEngine は非推奨になりました。現在では TextAnalysisEngine と AnalysisEngine に違いはありません。ただし、TextAnalysisEngine を使っている以前のコードは引き続き動作します。

アノテータコンテキストは非推奨になりました。代わりに UimaContext を使ってください。アノテータのコンテキストは、全体的な UIMA コンテキストと同じです。impl base クラスが提供する getContext() メソッドは、現在では UimaContext オブジェクトを返します。

ドキュメントアナライザツールは XMI 形式を使用します。ドキュメントアナライザツールは、新しい XMI シリアル化形式で出力を保存します。アノテーションビューワツールとセマンティック検索 GUI ツールは、新しい XMI 形式と以前の XCAS 形式のどちらも読み取ることができます。

CAS イニシャライザは非推奨になりました。CAS イニシャライザを使ったサンプルコードは、これを使わないように書き直されています。

1.3.2.3. 後方互換性

上に説明した IBM UIMA から Apache UIMA への変更点を除けば、ほとんどの UIMA 1.x アプリケーションは追加の変更を行うことなく、UIMA 2.x にアップグレードできるはずです。ただし、UIMA 1.x ユーザーが注意しておく必要のある例外がいくつかあります。

  • ResultSpecification にはいくつか変更点があります。ResultSpecification を使っているアプリケーションについては 100% の後方互換性は保証しません。ただし、ほとんどのケースでは問題ないはずです。

  • 複数の Sofa を扱うアプリケーションでは、コンポーネントがマルチビューかシングルビューかを判断するルールがより一貫したものになっています。コンポーネントは、そのコンポーネントがディスクリプタにおいて少なくとも 1 つの inputSofa または outputSofa を宣言している場合、かつその場合にのみ、マルチビューであるとみなされます。このため、まれなケースですが、次のような非互換性が生じることがあります。

    • TextAnnotator または JTextAnnotator インタフェースを実装しているアノテータが、ディスクリプタで inputSofa または outputSofa も宣言している場合にはエラーになります。このようなアノテータは、シングルビューでなければなりません。

    • GenericAnnotator を実装していて、inputSofa または outputSofa を 1 つも宣言していないアノテータには、今後はベース CAS ではなく、デフォルト Sofa のビューが渡されます。

1.4. IBM UIMA から Apache UIMA への移行

Apache UIMA では、ユーザーコードとディスクリプタの修正が必要となる変更点がいくつかあります。Apache UIMA には、ファイルに対して必要な更新を行う移行ユーティリティが付属しています。最も大きな変更点は、UIMA クラスとインタフェースのすべての Java パッケージ名が、IBM UIMA で使われていたものから変更されたことです。具体的には、すべてのパッケージ名がプリフィックス org.apache で始まるようになりました。

1.4.1. 移行ユーティリティの実行

注意

移行ユーティリティを実行する前に、問題が起きたときのことを考えて、ファイルを必ずバックアップしておいてください。移行ユーティリティは、ディレクトリ内で見つかったファイルをインプレイスで更新します。

移行ユーティリティを動作させるには、スクリプトファイル apache-uima/bin/ibmUimaToApacheUima.bat (Windows) または apache-uima/bin/ibmUimaToApacheUima.sh (UNIX) を実行します。移行の対象となるファイルを含むディレクトリを 1 つの引数として渡さなければなりません。指定されたディレクトリのサブディレクトリも再帰的に処理されます。

スクリプトはファイルを走査して必要な更新を適用します。たとえば、com.ibm パッケージ名を新しい org.apache パッケージ名で置き換えます。UIMA API で何が変わったか、また移行スクリプトでどのような変更が行われるかの詳細については、「セクション 1.3.1 IBM UIMA 2.0 から Apache UIMA 2.1 への変更点」を参照してください。

スクリプトが修正対象とするファイルは、拡張子が java, xml, xmi, wsdd, properties, launch, bat, cmd, sh, ksh, または csh のファイル、および拡張子を持たないファイルだけです。また、サイズが 1,000,000 バイトを超えるファイルもスキップされます。(上記以外の拡張子を持つファイルをスクリプトで修正したい場合は、スクリプトファイルを編集し、目的に応じて -ext 引数を変更してください。)

移行ツールから警告が報告された場合には、いくつか追加の手順が必要になることがあります。以下の 2 つのセクションでは、手作業でコードに加える必要のある簡単な変更について説明します。

1.4.1.1. DocumentAnnotation の JCas cover クラス

JCasGen を実行している場合、おそらくコードの中にクラス com.ibm.uima.jcas.tcas.DocumentAnnotation および com.ibm.uima.jcas.tcas.DocumentAnnotation_Type があると思われます。このパッケージ名は現在では無効ですが、移行ユーティリティはディレクトリ間でのファイルの移動を行わないため、この問題を修正することはできません。

これらのクラスに手作業での変更を加えていない場合、最善の一般的な解決策は、これら 2 つのファイル (およびこれらを含むパッケージ) を削除することです。Apache UIMA に付属する uima-document-annotation.jar ファイルにはデフォルトのバージョンが含まれています。一方、独自の変更を加えている場合には、ファイルを削除するのではなく、正しいパッケージ org.apache.uima.jcas.tcas にファイルを移動してください。JCas と DocumentAnnotation の詳細については、「セクション 5.5.4 DocumentAnnotation への特性の追加」を参照してください。

1.4.1.2. JCas.getDocumentAnnotation

非推奨のメソッド JCas.getDocumentAnnotation は削除されました。このメソッドを使っている場合は、代わりに JCas.getDocumentAnnotationFs を使う必要があります。メソッド JCas.getDocumentAnnotationFs() は型 TOP を返すので、コードではこれを型 DocumentAnnotation にキャストする必要があります。この理由については、「セクション 5.5.4 DocumentAnnotation への特性の追加」で説明しています。

1.4.2. 手作業での移行

以下で取り上げるのは、コードを移行させるのに、ほかにも手順が必要となるまれなケースです。このセクションを読む必要があるのは、移行ツールから警告が報告されたり、移行後にコードがコンパイルできない、実行できないなどの問題に遭遇した場合だけです。ほとんどのユーザーは、ここで取り上げる問題に留意する必要はありません。

1.4.2.1. xi:include

UIMA コンポーネントディスクリプタでの <xi:include> の使用は以前から推奨されていませんでしたが、Apache UIMA ではサポートが打ち切られました。<xi:include> を使用しているディスクリプタがある場合は、UIMA の <import> 構文を使うよう修正しなければなりません。正しい構文については、「セクション 2.2 インポート」で説明しています。

1.4.2.2. CAS と TCAS を引数に取る重複したメソッド

TCASCAS によって置き換えられたため、引数の型が TCASCAS かだけが異なる 2 つのメソッドがある場合、移行ツールによってこれらのメソッドはシグニチャが同じになり、コンパイルエラーが発生します。この場合は、まず 2 つの変種が必要な理由を考えてみてください。しばしば、一方のメソッドを削除するだけで動作するようになるはずです。

1.4.2.3. com.ibm.uima.util パッケージのドキュメント化されていないメソッドの使用

以前の UIMA のバージョンでは、com.ibm.uima.util パッケージの中に、内部使用のために用意されていて、Javadoc としてドキュメント化されていないメソッドがいくつかありました。(このパッケージにはドキュメント化されているメソッドも多数あり、これらの使用についてはまったく問題ありません。) ドキュメント化されていないメソッドを使うことは推奨されません。ドキュメント化されていないメソッドを使っている場合、移行スクリプトではこれらのメソッドは適切に処理されません。ドキュメント化されていないメソッドは現在は org.apache.uima.internal.util に移されており、この場所から import するよう、コードを手作業で修正する必要があります。

1.4.2.4. ユーザーコードでの UIMA パッケージ名の使用

自分で作成したクラスを UIMA パッケージのいずれかと正確に同じ名前を持つパッケージに入れている場合 (これは推奨されません)、移行スクリプトを実行したときに問題が生じます。スクリプトは UIMA パッケージ名を置き換えるので、自分の作成したクラスを参照する import 文はすべて置き換えられ、コードはコンパイルできなくなります。この場合は、コードを新しい Apache UIMA パッケージ名の場所 (すなわち、置き換えられた import 文で指定されている場所) に手作業で移動することで問題を解決できます。ただし、自分の作成したコードでは、Apache UIMA パッケージ名を使用しないことを推奨します。

もっとまれなケースとして、大文字で始まるパッケージ名 (好ましくない Java スタイル) があって、そのパッケージ名に UIMA パッケージ名のいずれかがプリフィックスとして使われている場合、たとえば、com.ibm.uima.MyPackage のような名前のパッケージがある場合も問題が生じます。これはクラス名として扱われ、見つかったすべての箇所で org.apache.uima.MyPackage に置き換えられます。

1.4.2.5. CASException と CASRuntimeException は UIMA(Runtime)Exception を継承するようになりました

この変更点はユーザーコードに若干の影響があるかもしれません。CASExceptionCASRuntimeException に対する API の一部が存在しなくなっているからです。逆によい点は、すべての UIMA 例外が同じ基本クラスから派生していて、同じようにふるまうようになった点です。最も重要な変更点は、特定の例外のタイプを従来と同様の方法ではチェックできなくなった点です。たとえば、次のようなコードを使っていた場合、

catch (CASRuntimeException e) {
  if (e.getError() == CASRuntimeException.ILLEGAL_ARRAY_SIZE) {
  // このエラーをキャッチした場合の処理

次のように書き直す必要があります。

catch (CASRuntimeException e) {
  if (e.getMessageKey().equals(CASRuntimeException.ILLEGAL_ARRAY_SIZE)) {
  // このエラーをキャッチした場合の処理

これは、メッセージキーが現在は文字列になっているためです。この変更点については、移行スクリプトでは対応できません。

1.5. Apache UIMA サマリー

1.5.1. 全般

UIMA は、構造化されていない情報のマルチモーダル分析の開発、発見、合成、およびデプロイメントと、こうした分析と各種検索技術との統合をサポートします。

Apache UIMA には、分析コンポーネントを作成するための API とツール群が含まれています。分析コンポーネントのサンプルには、トークナイザ、サマライザ、カテゴライザ、パーサー、名前付きエントリディテクタなどが含まれています。Apache UIMA にはチュートリアル用のサンプルが付属しています。ほかにもコミュニティから追加のコンポーネントを手に入れることができます。

Apache UIMA 自体には、セマンティック検索エンジンは含まれていません。分析結果をインデックス化する IBM の alphaWorks のセマンティック検索 SDK を組み込む方法、およびこのセマンティックインデックスを使って高度な検索を実行する方法の手順は、Apache UIMA に含まれています。

1.5.2. プログラミング言語のサポート

UIMA はさまざまなプログラミング言語での分析アルゴリズムの開発および統合をサポートしています。

Apache UIMA プロジェクトには、Java フレームワークと、これに対応する C++ イネーブルメントレイヤが含まれています。C++ イネーブルメントレイヤは、C++ でのアノテータの記述および C++ バージョンの CAS へのアクセスを可能にします。また、C++ イネーブルメントレイヤは、アノテータを Perl、Python、および TCL で記述することを可能にし、ほかの言語で記述されたアノテータとの相互運用を可能にします。

1.5.3. マルチモーダルサポート

UIMA アーキテクチャは、テキストや音声、動画を含むマルチモーダル分析の開発、発見、合成、およびデプロイメントをサポートしています。詳細については、「第 5 章 アノテーション、アーティファクト、Sofa」を参照してください。

1.5.4. セマンティック検索コンポーネント

このドキュメントの執筆時点 (2006 年 11 月) では、Lucene 検索エンジンはアノテーションを使った検索をサポートしていません。ただし、IBM のサイト http://www.alphaworks.ibm.com/tech/uima では、セマンティック検索エンジン、簡単なデモクエリツール、セマンティック検索エンジンに関する一定のドキュメント、および UIMA 分析の結果をインデクサに結び付けて、アノテーションとキーワードをインデックス化できるようにするコンポーネントをダウンロードすることができます。

以前のバージョンの UIMA SDK (Apache バージョンより前のもの) は、IBM の alphaWorks から入手できます。メイン UIMA フレームワークの以前のバージョンのソースコードは、SourceForge にあります。

1.6. Apache UIMA の機能のまとめ

モジュール説明
UIMA フレームワークコア

分析エンジンや CPE などの UIMA コンポーネントを作成し、一箇所にまとめて、または分散構成でデプロイ、実行、管理するためのコア機能をまとめたフレームワーク。

UIMA フレームワークには、トランスポート層アダプテーション、CAS 管理、宣言的仕様に基づくワークフロー管理、リソース管理、構成管理、ロギングその他の機能のためのコアコンポーネントの実装が含まれています。

C++ およびその他のプログラミング言語との相互運用性

C++ CAS が含まれており、UIMA 準拠の C++ コンポーネントの作成をサポートしています。これらのコンポーネントは、組み込みの JNI アダプタを通じて UIMA 実行時環境にデプロイすることができます。これには高速なバイナリシリアル化が含まれています。

サービスベースの UIMA エンジン作成のサポートが含まれています。ほかの言語で記述された既存のコードをラッピングする場合に理想的です。

フレームワークのサービスと API開発者はこれらのコンポーネントのインタフェースを利用できますが、UIMA フレームワークの異なる実装では、別の実装も可能であることに注意してください。
CASこれらのクラスは、型システムのスキーマ、要素、Sofa、インデックスなどを含む CAS (Common Analysis Structure) への型付きアクセスを提供します。複数の Sofa (subjects of analysis) を持つことができるしくみは、同じアーティファクト (ドキュメントなど) の複数のビューを独立して、または並行して分析することを可能にし、多言語およびマルチモーダル分析をサポートします。
JCasCAS に対する代替インタフェースで、Java ベースの UIMA 分析コンポーネントに対し、getter および setter による JavaBeans の規約に従って CAS の型およびその属性または特性に対するネイティブな Java オブジェクトアクセスを提供します。
CPM (Collection Processing Management)UIMA CPE (Collection Processing Engine) を一箇所にまとめて、または分散構成で実行するためのコア機能です。CPM は、並列処理パイプラインによるスケーラビリティの実現、チェックポイント機能、パフォーマンスモニタ、回復可能性を提供します。
リソースマネージャUIMA コンポーネントに対し、リソースの名前付け、共有、キャッシュといった外部リソース処理機能への実行時アクセスを提供します。
コンフィギュレーションマネージャUIMA コンポーネントに対し、構成パラメータ設定への実行時アクセスを提供します。
Loggerよく使われるロギング機能へのアクセスを提供します。
ツールとユーティリティ
JCasGenUIMA XML 型システム定義から CAS 型の Java オブジェクトモデルを生成するユーティリティ。
CAS の内容の保存と復元コアフレームワークの API は、XMI 形式によって CAS の内容をストリームに保存、復元するしくみをサポートしています。
Eclipse 用 PEAR パッケージャコンポーネントの移植、登録、インストール、およびテストを容易にする UIMA コンポーネントアーカイブを作成するためのツール。
PEAR インストーラUIMA コンポーネントアーカイブを UIMA 環境にインストールして検証するためのツール。
PEAR マージャ複数の PEAR を 1 つにまとめるユーティリティ。
コンポーネントディスクリプタエディタ (Component Descriptor Editor)UIMA 分析エンジンに加え、コレクションリーダーや CAS コンシューマといったその他の UIMA コンポーネントのコンポーネントディスクリプタを指定、構成するための Eclipse プラグイン。
CPE コンフィギュレータCPE (Collection Processing Engine) を構成し、これをドキュメントのコレクションに適用するためのグラフィカルツール。
Java アノテーションビューワアノテーションおよび関連 CAS データを確認するためのビューワ。
CAS ビジュアルデバッガ (CAS Visual Debugger)CAS の内容を詳細にビジュアル化して示す GUI Java アプリケーション。
ドキュメントアナライザ (Document Analyzer)分析エンジンを一連のドキュメントに適用し、結果をビューワに表示する GUI Java アプリケーション。
サンプル分析コンポーネント
データベースライター (Database Writer)選択された CAS 型の内容を JDBC を使ってリレーショナルデータベースに書き出す CAS コンシューマ。このコードは cpe/PersonTitleDBWriterCasConsumer にあります。
各種のアノテータ 学習用に用意された一連の簡単なアノテータ。日付と時刻 (date/time)、ルームナンバー (room-number)、正規表現 (regular expression), トークナイザ (tokenizer)、およびミーティング検索 (meeting-finder) の各アノテータがあります。サンプル CAS マルチプライヤもあります。
フローコントローラ まだ CAS を処理していない任意のアノテータに対し、そのアノテータへの入力が CAS で利用可能になったときに CAS を送信するという単純なコンセプトに基づくサンプルフローコントローラ。
XMI コレクションリーダー、CAS コンシューマCAS を XMI 形式で読み書きします。
ファイルシステムコレクションリーダー ファイルからドキュメントを取り込んで CAS を初期化するシンプルなコレクションリーダー。
www.alphaworks.ibm.com/tech/uima から入手可能なコンポーネント
セマンティック検索 CAS インデクサセマンティック検索エンジンインデクサを使って CAS のストリームからインデックスを構築する CAS コンシューマ。セマンティック検索エンジンが必要です (同じ場所から入手できます)。

第 2 章 UIMA コンセプト概観

UIMA は、テキストやマルチモーダル対応の強力な分析、検索コンポーネントを利用して非構造化情報管理ソリューションを作成、統合、デプロイするための、オープンで商業利用に堪える、スケーラブルかつ拡張可能なプラットフォームです。

Apache UIMA プロジェクトは、Apache ライセンスの下で利用可能な Java UIMA フレームワークの実装です。拡大してやまない今日の情報源の中から重要な知見を見い出すのに不可欠な各種技術を、産学が協力して世界全体で迅速に開発するための共通基盤を提供します。

この章では、UIMA の基本コンセプトを数多く紹介します。この章は、UIMA のアーキテクチャに対する基本的な考え方、および UIMA SDK の機能について大まかに把握してもらうことを意図して書かれています。

この章では UIMA の概要を示すとともに、UIMA SDK ドキュメントセットのほかの章への参照もふんだんに取り入れて、重要なコンセプトや開発作業についてもっと詳しく知りたい読者の要望にも応えられるようになっています。この章で使われている用語で、もしわからないものがあったら、巻末の「用語集」を参照してください。

2.1. UIMA 序論

非構造化情報アーティファクトと、これらのアーティファクトに関する構造化メタデータとの間を結ぶ橋の図

図 2.1. 構造化されていない世界と構造化された世界の間を結ぶ橋の構築を支援する UIMA


非構造化情報は、企業や政府がともに利用可能な最大、最新、かつ最も増加の著しい情報源です。ウェブは氷山の一角に過ぎません。企業、そして世界各地では、テキストや音声、動画など、さまざまな媒体を通じて膨大な情報が蓄積されています。これらの膨大な非構造化情報に含まれる高い価値を持ったコンテンツは、残念ながら多くのノイズの中に埋まってしまっています。そのため、非構造化情報の中から必要なものを探し出すこと、非構造化情報を対象に高度なデータマイニングを実行することが、新たな課題になっています。

非構造化情報管理 (UIM) アプリケーションの特徴を一般化して表せば、膨大な量の非構造化情報 (テキスト、音声、動画、画像など) を分析し、適切な情報を発見、構造化して、クライアントまたはアプリケーションのエンドユーザーに渡すソフトウェアシステムと言うことができます。数百万本の医学文献を処理して重大な薬物相互作用を見つけるアプリケーションは、その 1 つの例です。また、数千万個の文書を処理して、その中から競合他社の脅威を示す重要な事実を引き出すアプリケーションも、UIMA アプリケーションの 1 つの例です。

まず何より、非構造化データを分析して、興味の対象となる概念を解釈、検出、特定する必要があります。興味の対象となる概念とは、たとえば人や組織、場所、施設、製品など、名前を持ったエンティティで、元のアーティファクトでは明示的にタグ付けまたは注釈付けがなされていないもののことです。より高度な分析では、主張、苦情、危険、あるいは事実を検索することもできるでしょう。また、財務、サポート業務、購買、修理保守などでは、関係に着目したいこともあります。アプリケーションを使って非構造化コンテンツの中から発見する必要のある概念は、数も膨大で多岐にわたり、しばしばドメインに固有です。全体の分析作業のさまざまな部分は、多くのコンポーネント分析によって分担して実行できます。ただしその場合、これらのコンポーネント分析に相互運用性があって、簡単に組み合わせることができ、UIM アプリケーションの開発を容易にするものでなければなりません。

分析の結果を使ってデータを構造化された形式にすることで、検索エンジンやデータベースエンジン、あるいは OLAP (On-Line Analytical Processing、またはデータマイニング) エンジンといった従来のデータ処理・検索技術は、クライアントからの要求や問い合わせに応じて、新たに発見されたコンテンツを効率的に提示することができます。

UIM アプリケーションは、非構造化コンテンツの分析にあたって、次のようなさまざまな分析技術を利用します。

  • 統計的およびルールベースの自然言語処理 (NLP)

  • 情報検索 (IR)

  • 機械学習

  • オントロジ

  • 自動推論

  • ナレッジソース (CYC、WordNet、FrameNet など)

これらの技術を用いた具体的な分析機能は、それぞれ異なる技術、インタフェース、プラットフォームを使って個別に開発されます。

構造化されていない世界と構造化された世界の間を結ぶ橋は、これらの分析機能の合成とデプロイを通じて構築されます。この統合作業は、しばしば非常に手間のかかる作業です。

UIMA (Unstructured Information Management Architecture) は、この橋の構築を支援するアーキテクチャおよびソフトウェアフレームワークです。UIMA は、多種多様な分析機能の作成、発見、合成、デプロイ、さらにこれらを各種の構造化情報サービスへと結び付ける作業を支援します。

開発する側からみれば、UIMA を利用することで、あるソリューションの適切な部分を適切なスキルを持った人員に任せることができます。また UIMA は、さまざまなデプロイメントオプションを用意しており、多くの技術やプラットフォームを対象とした迅速な統合を可能にします。たとえば高性能シングルマシンによる埋め込みソリューション向けの密結合デプロイメントから、非常に柔軟でスケーラブルなソリューション向けのパラレル型完全分散デプロイメントまで、幅広いデプロイメントに対応しています。

2.2. アーキテクチャ、フレームワーク、および SDK

UIMA は、マルチモーダル分析機能の作成、記述、発見、合成、およびデプロイを行うためのコンポーネントインタフェース、データ表現、デザインパターン、開発ロールについて定めたソフトウェアアーキテクチャです。

UIMA フレームワークが提供する実行時環境では、開発者は自分の開発した UIMA コンポーネントの実装をプラグインすることができます。また、開発者は、UIMA フレームワークが提供する実行時環境を使って、UIM アプリケーションを構築、デプロイすることができます。UIMA フレームワークは、特定の IDE やプラットフォームに依存しません。Apache では、UIMA フレームワークの Java と (間もなく) C++ による実装を用意しています。

UIMA ソフトウェア開発キット (SDK) には、UIMA フレームワークに加え、UIMA を使用するための各種ツールとユーティリティが含まれています。一部のツールは Eclipse ベース (http://www.eclipse.org/) の開発環境をサポートしています。

2.3. 分析の基礎

このセクションで紹介する主な UIMA のコンセプト

分析エンジン、ドキュメント、アノテータ、アノテータ開発者、型、型システム、特性 (Feature)、アノテーション、CAS、Sofa、JCas、UIMA コンテキスト。

2.3.1. 分析エンジン、アノテータ、結果

何らかのテキストの図。テキスト中の語について発見されたメタデータの階層構造。人物の画像がその名前に関するメタデータとして含まれる。

図 2.2. CAS (Common Analysis Structure) で表現されたオブジェクト群


UIMA は、分析エンジン (Analysis Engine: AE) と呼ぶ基本構成要素を組み合わせてドキュメントを分析し、全体としてのドキュメント、あるいはドキュメントの中のリージョンに関する説明的属性値を推論、記録するためのアーキテクチャです。分析エンジンによって生成されるこの説明的な情報は、一般に分析結果と呼ばれます。通常、分析結果はドキュメントの内容に関するメタデータを表します。分析エンジンは、オリジナルコンテンツに関するメタデータを自動的に発見、記録するソフトウェアエージェントと考えることもできます。

UIMA は、テキストや音声、動画を含むさまざまなモダリティの分析をサポートしています。ここで取り上げるほとんどの例は、テキストを対象としています。したがって、テキストドキュメントであれ、音声の一部であれ、分析エンジンが処理する内容の任意の単位を指すのに、ドキュメントという用語を使用します。UIMA におけるマルチモーダル処理の詳細については、「第 6 章 1 つのアーティファクトに対する複数の CAS ビュー」を参照してください。

分析結果には、ドキュメントの内容に関するさまざまな文 (statement) が含まれています。たとえば、次の文はドキュメントのトピックに関するアサーションです。

(1) ドキュメント D102 の Topic は、"CEOs and Golf" である。

分析結果には、ドキュメント全体よりも小さなリージョンについて記述した文が含まれることがあります。あるテキストドキュメント内の一連の文字を指すのに、スパン (span) という用語を使用します。たとえば、ID が D102 のドキュメントの文字位置 101 から、"Fred Centers" というスパンが含まれていたとします。テキストから人物を検出する分析エンジンは、次のような文を分析結果として表現するかもしれません。

(2) ドキュメント D102 の位置 101 から 112 までのスパンは Person を表している。

上の文 1 と文 2 には、特別な定義済みの用語、すなわち UIMA で言うところの (Type) が含まれています。具体的には、それぞれ TopicPerson が該当します。UIMA の型は、分析エンジンが生成する結果の種類を特徴付けるものです。型については、あとで詳しく説明します。

分析結果の中には、2 つの文を関連付けるものもあります。たとえば、2 つのスパンがどちらも同じ人物を表していることを分析エンジンが結果に記録することがあります。

(3) スパン 101 から 112 までが表す Person と、 
  スパン 141 から 143 までが表す Person は、 
  同じ Entity を指している。

これまでに示した文は、分析エンジンが分析対象のドキュメントの内容について記録する結果の例です。これらの文は、分析結果が UIMA に取り込まれる際の形式や構文を示すものではありません。詳細については、この概要のあとの方で説明します。

UIMA フレームワークは、分析エンジンをプラガブルで合成可能、発見可能な管理されたオブジェクトとして扱います。分析エンジンの核にあるのは、ドキュメントを分析して分析結果を記録するのに必要なすべての作業を行う分析アルゴリズムです。

UIMA は、分析エンジン内部で実行される中核的な分析アルゴリズムを収めるための基本的なコンポーネントタイプを提供しています。このコンポーネントのインスタンスは、アノテータ (Annotator) と呼ばれます。したがって、分析アルゴリズム開発者が第一に目指すべきことは、アノテータの開発です。UIMA フレームワークは、アノテータを受け取って分析エンジンを作成するのに必要なメソッドを提供しています。

UIMA では、分析アルゴリズムのコーディングを行う人が、アノテータ開発者 (Annotator Developer) のロールを引き受けます。「第 1 章 アノテータおよび分析エンジン開発者ガイド」では、UIMA のアノテータおよび分析エンジンの作成について詳しく説明しています。

最もプリミティブなレベルでは、分析エンジンは、1 つのアノテータをラップし、UIMA フレームワーク内でアノテータを合成、デプロイするのに必要な API とインフラを追加します。最も単純な分析エンジンは、その中核にアノテータを 1 つしか持たない分析エンジンです。複合的な分析エンジンでは、ほかの分析エンジンのコレクションがその中に含まれていることがあり、さらにこれらの分析エンジンの中に、また別の分析エンジンが含まれていることもあります。

2.3.2. 分析結果の CAS での表現

アノテータが結果をどのように表現して公開するかは、UIMA アーキテクチャの重要な部分です。UIMA では、まさにそのために CAS (Common Analysis Structure) というものを定義しています。

CAS は、オブジェクト、プロパティ、および値の表現を可能にするオブジェクトベースのデータ構造です。さまざまなオブジェクトの型を、単一継承の階層構造の中で互いに関連付けることができます。CAS は (物理的ではないにせよ) 論理的には、分析対象のドキュメントを含んでいます。分析エンジン開発者は、CAS のオブジェクトモデルの形で分析結果を公開、記録します。[1]

UIMA フレームワークには、CAS の実装と CAS へのインタフェースが含まれています。CAS とそのインタフェースの詳細については、「第 4 章 CAS リファレンス」を参照してください。

文 2 (便宜的に再掲します) を論理的に含んでいる CAS は、

(2) ドキュメント D102 の位置 101 から 112 までのスパンは Person を表している。

Person 型のオブジェクトを含んでいることになります。分析エンジンは、ドキュメント本体の中で見つかった各人物について CAS に Person オブジェクトを作成し、該当する人物がドキュメント内で言及されているテキストスパンにこれを関連付けます。

CAS は汎用データ構造ですが、UIMA ではいくつか基本的な型を定義しており、開発者がこれらの型を拡張して任意の柔軟な型システムを定義できるようにしています。型システムは CAS のオブジェクトスキーマと考えることができます。

型システムでは、この型システムに参加する分析エンジンがドキュメント内で発見する可能性のあるさまざまなオブジェクトの型を定義します。

すでに例でみたように、Person は型として定義できます。型は、プロパティまたは特性 (feature) を持ちます。たとえば、Person 型の特性として Age (年齢) や Occupation (職業) を定義することができます。

その他の型として、Organization、Company、Bank、Facility、Money、Size、Price、Phone Number、Phone Call、Relation、Network Packet、Product、Noun Phrase、Verb、Color、Parse Node、Feature Weight Array などが考えられるでしょう。

ある型システムで定義できる型に制限はありません。型システムは、ドメインおよびアプリケーションに固有です。

UIMA の型システムのさまざまな型は、タクソノミとしてまとめることができます。たとえば、CompanyOrganization のサブタイプとして定義できます。NounPhraseParseNode のサブタイプとして定義できます。

2.3.2.1. アノテーション型

アーティファクトの分析で使われ、しばしば追加の型の派生元となる一般的な型として、アノテーション型があります。

アノテーション型は、アーティファクトのリージョンにアノテーション、すなわちラベルを付けるのに使われます。よくあるアーティファクトはテキストドキュメントですが、音声ストリームなど、ほかのものがアーティファクトであることもあります。テキスト用のアノテーション型には 2 つの特性、すなわち、beginend があります。これらの特性の値は、アーティファクト内でのオフセットを示す整数値で、スパンの区切りを表します。個別のアノテーションオブジェクトはいずれも、アノテーション対象のスパンを begin 特性と end 特性によって特定します。

要するに、アノテーション型は、アーティファクトの特定のリージョンを特定してラベルを付ける、すなわちアノテーションを付けるために使われます。

Person 型がアノテーションのサブタイプとして定義されているとします。たとえばこの場合、あるアノテータは、ドキュメント D102 の位置 141 から 143 の間で、ある人物に関する言及を発見したことを記録するために、Person アノテーションを作成することができます。同じアノテータは、位置 101 と 112 の間のスパンで、ある人物に関する言及を発見したことを記録するために、別の Person アノテーションを作成することができます。

2.3.2.2. アノテーション以外の型

アノテーション型は、ドキュメントのリージョンにアノテーションを付けるのに便利な型ですが、CAS に含まれる型の種類はアノテーションだけではありません。CAS は一般的な表現スキームであり、CAS にはドキュメントの分析を表現するための任意のデータ構造を格納することができます。

たとえば、すでに取り上げた文 3 に注目してみましょう (便宜的に再掲します)。

(3) スパン 101 から 112 までが表す Person と、 
  スパン 141 から 143 までが表す Person は、 
  同じ Entity を指している。

この文は CAS 内の人物に関するアノテーション 2 つに言及していて、最初のアノテーション (以下 P1 といいます) のスパンの区切りは 101 から 102 まで、2 番目のアノテーション (以下 P2 といいます) のスパンの区切りは 141 から 143 までです。文 3 は、これら 2 つのスパンが同一のエンティティを指していることを明示的にアサートしています。これは、テキスト内にはアノテーション P1 と P2 によって表される 2 つの表現があって、これらの表現がいずれも同一の人物を指していることを意味しています。

この種の情報を取り込むために、型システムに Entity 型というものを導入することができます。Entity 型はアノテーションではありません。Entity 型は、1 つのドキュメントで (あるいはドキュメントのコレクション内で複数のドキュメントにまたがって) 複数回出現するさまざまな表現 (または言及) が指すドメイン内のオブジェクトを表すためのものです。Entity 型には occurrences という名前の特性があります。この特性は、同一のエンティティについての言及にラベルを付けていると思われるすべてのアノテーションを示すのに使われます。

P1 と P2 によってアノテーションが付けられたスパンが、それぞれ "Fred Center""He" だったとしましょう。この場合、アノテータは、FredCenter という名前の新しい Entity オブジェクトを作成することができます。上の文 3 の関係を表すために、アノテータは P1 と P2 のスパンを occurrences 特性の値とすることによって、FredCenter を P1 と P2 の両方に関連付けることができます。

図 2.2 「CAS (Common Analysis Structure) で表現されたオブジェクト群」では、画像ドキュメントのリージョンを指すアノテーションにもエンティティを関連付けることができることを示しています。このような関連付けを行うには、画像のリージョンを指すことができるよう、アノテーション型を拡張して適切な特性を持たせる必要があるでしょう。

2.3.2.3. 1 つの CAS 内の複数のビュー

UIMA は、1 つのドキュメントの複数のビューを同時に分析することをサポートしています。これは、スピーチストリームの音声のビューと字幕のビューや、HTML ドキュメントのタグ付きビューとタグなしビューなど、1 つのアーティファクトの複数の形式を処理するときに便利です。

分析エンジンは、1 つのドキュメントの 1 つまたは複数のビューを分析します。各ビューには固有の Sofa (Subject of Analysis) があり、これに加えて、そのビューによってインデックス化されたメタデータを保持する一連のインデックスが含まれています。CAS は全体では 1 つまたは複数のビューを持ち、さらに各ビューの分析結果を表す説明的オブジェクトを保持しています。

CAS のビューを複数使用する別の例としてよくあるのが、1 つのドキュメントに対する複数の翻訳です。各翻訳は、異なる CAS ビューによって表すことができます。各翻訳は、異なる分析結果のセットによって記述することができます。CAS のビューと Sofa の詳細については、「第 6 章 1 つのアーティファクトに対する複数の CAS ビュー」および「第 5 章 アノテーション、アーティファクト、Sofa」を参照してください。

2.3.3. CAS と外部リソースの操作

UIMA コンポーネント開発者が操作する 2 つの主要インタフェースが、CAS と UIMA コンテキストです。

UIMA は、複数のプログラミングインタフェースを備えた CAS の効率的な実装を提供しています。アノテータ開発者はこれらのインタフェースを介してドキュメントを操作し、分析結果を読み書きすることができます。CAS のインタフェースが提供する一連のアクセスメソッドを使えば、開発者は CAS 内のさまざまなオブジェクトに対するインデックス付きイテレータを取得することができます。「第 4 章 CAS リファレンス」を参照してください。1 つの CAS には多くのオブジェクトが存在することがありますが、アノテータ開発者は、たとえば、特定のビューと関連付けられたすべての Person オブジェクトに対する固有のイテレータを取得することができます。

UIMA は、Java アノテータ開発者向けに JCas を提供しています。このインタフェースは、Java 開発者に対し、CAS オブジェクトへのネイティブインタフェースを提供します。型システムで宣言された各システムは、Java のクラスに見えます。UIMA フレームワークは Person 型を Java の Person クラスとして提示します。分析アルゴリズムがドキュメント内で人物に関する言及を検出すると、分析アルゴリズムは CAS 内に Person オブジェクトを作成することができます。JCas インタフェースを使った CAS の操作方法の詳細については、「第 5 章 JCas リファレンス」を参照してください。

コンポーネント開発者は、CAS の操作のほかにも、UIMA コンテキストと呼ばれる UIMA フレームワークのリソースマネージャインタフェースを介して外部のリソースにアクセスすることができます。このインタフェースの主な役割は、1 つの集約フローの中で共に動作するさまざまなアノテータが、外部のファイルや、URL を介してアクセスされるリモートリソースの同一のインスタンスを共有できるようにすることです。UIMA コンテキストの使い方の詳細については、「第 1 章 アノテータおよび分析エンジン開発者ガイド」を参照してください。

2.3.4. コンポーネントディスクリプタ

UIMA は、少数のコアコンポーネントのインタフェースを定義しており、UIMA フレームワークのユーザーはこれを実装して提供することになります。すでに何度か取り上げているアノテータと分析エンジンも、UIMA アーキテクチャによって指定されている基本構成要素のうちの 2 つです。開発者はこれらの構成要素を実装して、分析機能を作成、合成し、最終的にアプリケーションを構築します。

コンポーネントはこのほかにもあり、それぞれについてはあとで学んでいきますが、UIMA で指定されているあらゆるコンポーネントの場合、その実装では次の 2 つの部分が不可欠です。

  1. 宣言部

  2. コード部

宣言部には、コンポーネント、コンポーネントの ID、構造、およびふるまいについて記述したメタデータが含まれており、これをコンポーネントディスクリプタと呼びます。コンポーネントディスクリプタは XML で表現されます。コード部ではアルゴリズムを実装します。コード部は Java のプログラムにすることができます。

UIMA SDK を使用する開発者が UIMA コンポーネントを実装するには、必ずコード部とコンポーネントディスクリプタの 2 つの部分を提供します。一方、分析エンジンを合成する場合には、コードはすでに再利用可能なサブコンポーネントで用意されている場合もあることに注意してください。この場合、開発者は新しいコードを開発するのではなく、目的のコードがすでに含まれているほかのコンポーネントを指し示すことによって、集約分析エンジンを合成することになります。

コンポーネントディスクリプタは XML で表現され、コンポーネントの発見、再利用、合成、および開発ツールの使用を容易にします。UIMA SDK では、開発者が直接 XML を編集しなくてもよいように、コンポーネントディスクリプタを簡単に作成、保守するためのツールを用意しています。このツールについては、「第 1 章 アノテータおよび分析エンジン開発者ガイド」で簡単に説明しているほか、「第 1 章 コンポーネントディスクリプタエディタ ユーザーガイド」で詳しく取り上げています。

コンポーネントディスクリプタには、コンポーネントの名前、作成者、バージョン、そのコンポーネントを実装しているクラスへの参照などを含む標準的なメタデータが収められています。

これらの標準フィールドに加え、コンポーネントディスクリプタでは、そのコンポーネントが使用する型システム、およびそのコンポーネントが入力 CAS で必要とする型、そのコンポーネントが出力 CAS で生成する予定の型を指定します。

たとえば、Person 型を検出する分析エンジンでは、ドキュメントのトークン化と深い解析を含んだ CAS を入力として要求することになるでしょう。コンポーネントディスクリプタは、ある型システムを指定して、コンポーネントの入力要件と出力の型を明示的に示します。実際には、コンポーネントディスクリプタにはそのコンポーネントのふるまいに関する宣言的記述が含まれており、これを利用することで、望まれる結果に基づいたコンポーネントの発見と合成を容易にすることができます。UIMA 分析エンジンは、ディスクリプタで表現されたコンポーネントのメタデータにアクセスするためのインタフェースを提供しています。UIMA コンポーネントディスクリプタの構造の詳細については、「第 2 章 コンポーネントディスクリプタリファレンス」を参照してください。

2.4. 集約分析エンジン

このセクションで紹介する主な UIMA のコンセプト

集約分析エンジン、委譲分析エンジン、密結合、疎結合、フロー指定、分析エンジンアセンブラ。

複数の部分 (言語検出、トークナイザ、スピーチ部分検出アノテータ、浅い解析、名前付きエンティティ検出) がつながって 1 つのフローを形成し、これらの部分のすべてが単一の集約オブジェクトにラップされた状態を示した図。この 1 つの集約オブジェクトが、各アノテータコンポーネントのすべての結果 (トークン、スピーチ部分、名前、組織、場所、人物など) をまとめたものをアノテーションとして生成する。

図 2.3. 集約分析エンジンの例


単純な、すなわちプリミティブな UIMA 分析エンジンに含まれているアノテータは 1 つです。しかし、分析エンジンは、1 つのワークフローの形にまとめた複数の分析エンジンを含むように定義することができます。このようなより複雑な分析エンジンのことを集約分析エンジン (Aggregate Analysis Engine) と呼びます。

各種アノテータは、言語の検出、トークン化、スピーチ部分の検出など、かなり細かい作業を実行します。一般にこれらの作業が対象とするのは、全体の分析作業のほんの一部分です。コンポーネントエンジンをワークフローとしてまとめると、もっと複雑な作業を実行することができます。

たとえば、名前付きエンティティの検出を行う分析エンジンには、まず言語検出から始まって、トークン化、スピーチ部分の検出、ついで深い文法解析、最後に名前付きエンティティ検出を実行するアノテータのパイプラインを含めることができます。パイプライン中の各ステップは、それ以降の分析で必要となる作業を行います。たとえば、最後の名前付きエンティティアノテータは、その前の深い文法解析が CAS にすでに記録されている場合にのみ、分析作業を行うことができます。

集約分析エンジンを構築すると、潜在的には複雑な内部構造をカプセル化し、これを分析エンジンのユーザーから隠蔽することができます。上の例では、集約分析エンジン開発者は内部コンポーネントを入手し、これらの間で必要になるフローを定義し、その結果として出来上がった分析エンジンを公開します。図 2.3の「集約分析エンジンの例」に示した簡単な例では、集約分析エンジン "MyNamed-EntityDetector" は、よりプリミティブな複数の分析エンジンを順に並べた直線的 (リニア) なフローから構成されています。

この集約分析エンジンを利用するユーザーは、それが内部的にどのように構築されているかを知る必要はありません。知る必要があるのは、名前と、公開されている入力要件、および出力の型だけです。これらのものは、集約分析エンジンのディスクリプタで宣言しなければなりません。集約分析エンジンのディスクリプタでは、その中に含まれるコンポーネントとフロー指定を宣言します。フロー指定では、内部コンポーネント分析エンジンの実行順序を指定します。集約分析エンジンで指定された内部分析エンジンは、委譲分析エンジン (delegate analysis engine) とも呼ばれます。「委譲 (delegate)」という言葉を使うのは、集約分析エンジンが内部分析エンジンに作業を「委譲」しているとみなされるからです。

UIMA 2.0 では、開発者は「フローコントローラ」を実装し、これを集約分析エンジンのディスクリプタに記述することで、集約分析エンジンの一部にフローコントローラを含めることができます。フローコントローラは、「フロー」の計算を担当します。すなわち、委譲分析エンジンが CAS を処理する順序を決定します。フローコントローラは、CAS に加えて、フローを決定するのに必要な外部リソースにアクセスすることができます。フローコントローラはこの作業を実行時に動的に行うことができ、多段階の決定を行ったり、集約分析エンジンのディスクリプタに記述されたあらゆる種類のフロー指定を考慮したりすることができます。UIMA フローコントローラのインタフェースの詳細については、「第 4 章 フローコントローラ開発者ガイド」を参照してください。

委譲分析エンジンから集約分析エンジンを構築する作業に関連する開発ロールのことを、分析エンジンアセンブラ (Analysis Engine Assembler) と呼びます。

UIMA フレームワークは、集約分析エンジンディスクリプタの指定に従って、すべての委譲分析エンジンを実行し、フローコントローラが生成した順序で各委譲分析エンジンが CAS にアクセスするようにします。UIMA フレームワークには、委譲分析エンジンが密結合 (同一プロセス内で実行される) や疎結合 (別のプロセスまたは別のマシン上で実行される) の場合など、さまざまなデプロイメントに対応できるしくみが用意されています。UIMA フレームワークは、集約分析エンジンの疎結合デプロイメントで使われるさまざまなリモートプロトコルをサポートしており、SOAP もその中に含まれています (SOAP は Simple Object Access Protocol の略で、標準の Web Servies コミュニケーションプロトコルです)。

UIMA フレームワークは、コンポーネントのディスクリプタでの宣言に応じて必要なインフラを自動的に作成するアダプタを使うことで、分析エンジンのリモートサービスとしてのデプロイメントを容易にしています。集約分析エンジンの作成方法の詳細については、「第 2 章 コンポーネントディスクリプタリファレンス」を参照してください。コンポーネントディスクリプタエディタツールは、利用可能な分析エンジンのリポジトリから集約分析エンジンを指定する作業を支援します。コンポーネントディスクリプタエディタの詳細については、「第 1 章 コンポーネントディスクリプタエディタ ユーザーガイド」を参照してください。

UIMA フレームワークの実装では、2 つのフローの実装があらかじめ組み込まれています。1 つはコンポーネント間での直線的 (リニア) なフローをサポートするもの、もう 1 つはドキュメントの言語に基づいて条件分岐を行うものです。また、ユーザーが作成したフローコントローラもサポートしています。詳細については、「第 4 章 フローコントローラ開発者ガイド」を参照してください。アプリケーション開発者は、複数の分析エンジンを作成し、これらを任意の複雑なフローで組み合わせて使うロジックを提供することができます。詳細については、「3.2 分析エンジンの使用」を参照してください。

2.5. アプリケーションの構築とコレクション処理

このセクションで紹介する主な UIMA のコンセプト

process メソッド、コレクション処理アーキテクチャ、コレクションリーダー、CAS コンシューマ、CAS イニシャライザ、CPE (Collection Processing Engine)、CPM (Collection Processing Manager)。

2.5.1. アプリケーションからの UIMA フレームワークの使用

UIMA ファクトリと対話して、さまざまなアノテータのコンテナとなる分析エンジンを作成するアプリケーションと、process メソッドおよび getMetaData メソッドを介したアプリケーションとのインタフェースの図

図 2.4. UIMA フレームワークを使った分析エンジンの作成と操作


すでに説明したように、基本的な分析エンジンのインタフェースは、単純に CAS の出入りと考えることができます。

アプリケーションの役割は、UIMA フレームワークを操作して、分析エンジンをインスタンス化し、入力 CAS を作成または取得し、入力 CAS をドキュメントで初期化した後、これを process メソッドを介して分析エンジンに渡すことです。この UIMA フレームワークの操作を図示したのが、図 2.4 「UIMA フレームワークを使った分析エンジンの作成と操作」です。

UIMA 分析エンジンファクトリは、コンポーネントディスクリプタと、アノテータを実装したクラスファイルの宣言情報を受け取って、分析エンジンをインスタンス化し、CAS と UIMA コンテキストをセットアップします。

分析エンジンは、場合によっては内部で複数の委譲分析エンジンを呼び出し、全体の分析を実行し、分析エンジンの process メソッドは、新しい分析結果を含む CAS を返します。

アプリケーションでは、この返された CAS をどう扱うかを決定します。さまざまな可能性が考えられます。たとえば、アプリケーションで結果を表示したり、あとで処理するために CAS をディスクに格納したり、検索アプリケーションまたはデータベースアプリケーションの一部として分析結果を抽出してインデックス化を行ったりすることができます。

UIMA フレームワークは、アプリケーション開発者による CAS の作成と管理、分析エンジンのインスタンス化、実行、および管理をサポートするさまざまなメソッドを提供しています。詳細については、「第 3 章 アプリケーション開発者ガイド」を参照してください。

2.5.2. コレクション処理へ

ソースからシンクまでのハイレベルな UIMA コンポーネントアーキテクチャ

図 2.5. ソースからシンクまでのハイレベルな UIMA コンポーネントアーキテクチャ


多くの UIM アプリケーションは、ドキュメントのコレクション全体を分析します。このような UIM アプリケーションはドキュメントソースに接続し、さまざまな方法で結果を処理します。しかし、典型的なケースでは、アプリケーションは一般に次の論理的な手順に従わなければなりません。

  1. 物理ソースに接続する。

  2. ソースからドキュメントを取得する。

  3. 分析対象のドキュメントで CAS を初期化する。

  4. CAS を一連の特定の分析エンジンに送る。

  5. 結果の CAS を処理する。

  6. コレクションが処理されるまで、上の 2. へ戻る。

  7. コレクション内のすべてのドキュメントの分析が終わった後、必要な最終処理があれば、それを実行する。

UIMA は、コレクション処理アーキテクチャ (Collection Processing Architecture) を通じて、こうした一般的な処理を行う UIM アプリケーション開発を支援します。

UIMA では、コレクション処理アーキテクチャの一部として、アノテータと分析エンジンのほかに、2 つの基本コンポーネントが導入されています。それはコレクションリーダー (Collection Reader) と CAS コンシューマ (CAS Consumer) です。ソースからドキュメントの分析を経て、CAS コンシューマに至る、UIMA のサポートしているフロー全体を図示したのが、図 2.5.「ソースからシンクまでのハイレベルな UIMA コンポーネントアーキテクチャ」です。

コンポーネントリーダーの役割は、ソースコレクションに接続して繰り返し処理を行い、ドキュメントを取得して、分析のために CAS を初期化することです。

CAS コンシューマは、その名前が示すように、フローの最後の処理を受け持ちます。CAS コンシューマの役割は、最終的な CAS 処理を行うことです。たとえば、検索エンジンで CAS の内容をインデックス化する、重要な要素を抽出してリレーショナルデータベースに保存する、以後の分析で利用するために分析結果をディスクに格納するといった目的で、CAS コンシューマを実装することができます。

UIMA で動作するセマンティック検索エンジンが IBM の alphaWorks サイトにあります。この検索エンジンを使うと、分析結果のインデックス化と、CAS 内のすべてのアノテーションに基づいたドキュメントに対する問い合わせを試してみることができます。テキストの分析と検索の統合については、「第 3 章 アプリケーション開発者ガイド」を参照してください。

UIMA CPE (Collection Processing Engine: コレクション処理エンジン) は、コレクションリーダーから、一連の分析エンジンを経由して、一連の CAS コンシューマへと至るソースからシンクまでのフローを定める集約コンポーネントです。

CPE は、CPE ディスクリプタと呼ばれる XML ファイルによって指定されます。CPE ディスクリプタは、中に含まれるコンポーネント (コレクションリーダー、分析エンジン、および CAS コンシューマ) を示し、これらのコンポーネント間のフローを定める宣言的仕様です。フロー指定によって、CAS の内容に基づいて分析エンジンをスキップするといったフィルタリング機能が可能になります。CPE ディスクリプタの書式の詳細については、「第 3 章 CPE ディスクリプタリファレンス」を参照してください。

CPE ファクトリを使って CPE をインスタンス化するアプリケーション、および CPE がアプリケーションと対話する様子を示した図

図 2.6. UIMA フレームワークにおける CPM


UIMA フレームワークには、CPM (Collection Processing Manager: コレクション処理マネージャ) が含まれています。CPM は、CPE ディスクリプタを読み取って、指定された CPE をデプロイして実行することができます。図 2.6 「UIMA フレームワークにおける CPM」は、UIMA フレームワークにおける CPM の役割を示したものです。

CPM がになう主な機能は、障害回復、CAS 管理、およびスケールアウトです。

コレクションは規模が大きいと分析に膨大な時間がかかります。CPM の構成可能な動作として、単一ドキュメントの障害では失敗を記録して、コレクションの処理は続けるというものがあります。これは一般にもよく利用される動作です。なぜなら鎖の中で最も弱い部分は分析コンポーネントで、形式が異常な内容を処理したときに動作がおかしくなることが多いからです。

このようなデプロイメントオプションでは、CPM を独立したプロセスで実行するか、または CPE コンポーネントのあるマシンとは別のマシンで CPM を実行する必要があります。CPE は、CPM の提供機能をコントロールするさまざまなデプロイメントオプションの下で実行するよう、構成することができます。詳細については、「第 3 章 CPE ディスクリプタリファレンス」を参照してください。

UIMA SDK では、CPE コンフィギュレータと呼ばれるツールも提供しています。CPE コンフィギュレータは、CPE で組み合わせるすべてのコンポーネントをつなぐプロセス、およびその結果の実行を開発者が簡単に行えるようなユーザーインタフェースを提供します。CPE コンフィギュレータの使い方の詳細については、「第 2 章 CPE コンフィギュレータ ユーザーガイド」を参照してください。現在のところ、CPE コンフィギュレータでは、CPM がサポートする CPE デプロイメントオプションのすべてを完全に管理できるわけではありませんが、CPE コンフィギュレータで指定できない部分については、CPE ディスクリプタを直接編集することで構成できます。CPE の作成、実行方法の詳細については、「第 3 章 CPE 開発者ガイド」を参照してください。

2.6. 分析結果の活用

このセクションで紹介する主な UIMA のコンセプト

セマンティック検索、XML フラグメントクエリ。

シンプルな UIMA CPE (Collection Processing Engine) では、コレクションリーダーがファイルシステムからドキュメント群を読み取って、その内容を使って CAS を初期化します。これらの CAS を渡された分析エンジンは、トークンとセンテンスにアノテーションを付けます。ついで、これらトークンおよびセンテンス情報を付加されて情報量の増えた CAS は、CAS コンシューマに渡され、CAS コンシューマは検索エンジンインデックスにデータを収めます。

検索エンジンクエリプロセッサは、トークンインデックスを使ってベーシックなキーワード検索を提供します。たとえば、"center" というクエリが与えられると、検索エンジンは "center" という語を含むすべてのドキュメントを返します。

セマンティック検索は、UIMA CPE のような分析によって生成される追加のメタデータを利用できる検索パラダイムです。

たとえば、上の CPE ディスクリプタに名前付きエンティティレコグナイザをプラグインしたとします。この名前付きエンティティレコグナイザは、ドキュメントから人物と組織に関する言及を検出して、CAS にアノテーションを付けることができる分析エンジンだとしましょう。

名前付きエンティティレコグナイザの追加に合わせて、トークンおよびセンテンスのアノテーションのほかに、名前付きエンティティレコグナイザによって CAS に追加された人物と組織を抽出する CAS コンシューマを追加します。この CAS コンシューマは、これらの人物と組織を検索エンジンのインデックスに収めます。

たとえば、UIMA SDK に付属するセマンティック検索エンジンでは、CAS からのこうした追加情報を活用して、より強力なクエリをサポートします。例として、"center" という語で組織に言及しているドキュメントを探すユーザーがいたとしましょう。この語は名前ですが、組織のフルネームなのか、正確な名称なのかはわかりません。"center" を指定したキーワード検索では、"center" があまりに一般的で曖昧な語であるために、結果として出力されるドキュメントの数は多過ぎてしまうでしょう。http://www.alphaworks.ibm.com/tech/uima から入手できるセマンティック検索エンジンは、XML フラグメントと呼ばれるクエリ言語をサポートしています。このクエリ言語は、インデックスに入力された CAS アノテーションを利用できるよう設計されています。たとえば、次のような XML フラグメントクエリは、

<organization> center </organization>

名前付きエンティティレコグナイザによって組織としてアノテーションの付けられた言及の一部に "center" を含むドキュメントだけを結果として返すことになります。これは、ユーザーの求めていたものにより近い、簡潔なドキュメントのリストになるでしょう。

この処理をもう一歩先に進めてみましょう。CEO-of (組織の CEO である) という関係に関する言及にアノテーションを付ける関係レコグナイザを追加します。CAS コンシューマを適切に構成し、関係に関するこれらの新しいアノテーションも同じセマンティック検索インデックスに送られるようにします。インデックスに新たに追加された分析結果を利用すれば、次のようなクエリを実行することができます。

<ceo_of>
    <person> center </person>
    <organization> center </organization>
<ceo_of>

このクエリは、その名前の一部に "center" を含む組織に関する言及があって、その組織が関係レコグナイザによって CEO-of 関係の一部として言及されているドキュメントだけを取り出します。

UIMA とセマンティック検索の使い方の詳細については、「第 3 章 アプリケーション開発者ガイド」のテキストの分析と検索の統合について説明したセクションを参照してください。

2.6.2. データベース

分析結果の格納先としてアプリケーションが使用するのは、検索エンジンのインデックスばかりではありません。データベースもよく使われます。どのような柔軟性やパフォーマンスを実現するかによってアプローチはたくさん考えられますが、どのアプローチもアプリケーション固有の要素に大きく左右されます。SDK には、分析結果をリレーショナルデータベースに収めるための基本操作を提供する簡単な CAS コンシューマのサンプルが含まれています。この CAS コンシューマは、CAS からアノテーションを抽出し、抽出したアノテーションを、オープンソースの Apache Derby データベースを使ったリレーショナルデータベースに書き出します。

2.7. UIMA におけるマルチモーダル処理

これまでのセクションでは、CAS がアーティファクトで初期化され、続いて分析エンジンによって分析され、CAS コンシューマによって処理されるしくみについて説明してきました。最初の分析エンジンは、たとえばアノテーションの形でアーティファクトに関する何らかのアサーションを行います。その後の分析エンジンでは、アーティファクトとそれまでの分析結果の両方に対してさらにアサーションを行い、最後に 1 つまたは複数の CAS コンシューマが、構造化された情報ストレージ用に CAS から情報を抽出します。

左の音声がセグメンテーションコンポーネントによっていくつかのセグメントに分割され、これが raw オーディオを処理したり、テキストとして認識されたスピーチを処理したりする複数の分析パイプラインに並行して送られるようすを示した図

図 2.7. 音声ストリームのマルチモーダル分析をサポートする複数の Sofa。音声「ビュー」を対象とするエンジンもあれば、テキスト「ビュー」を対象とするエンジン、その両方を対象とするエンジンがある。


たとえば、図 2.7 「音声ストリームのマルチモーダル分析をサポートする複数の Sofa。音声「ビュー」を対象とするエンジンもあれば、テキスト「ビュー」を対象とするエンジン、その両方を対象とするエンジンがある」に示した処理パイプラインがあるとします。このパイプラインは会話の音声録音からスタートしていて、音声を文字に起こし、ついで文字に起こされたテキストから情報を抽出します。パイプラインの最初の方にある分析エンジンは、音声の分析テーマを分析し、後の方にある分析エンジンではテキストの分析テーマを分析します。CAS コンシューマでは、テキスト内で見つかった概念からその概念に該当する元の音声セグメントを指し示すような検索インデックスを作成できると便利です。

こうした比較的シンプルなシナリオから明らかにわかるのは、CAS は同時に複数の分析テーマを保持できなければならないということです。分析エンジンによっては 1 つの分析テーマしか分析せず、別の分析エンジンは 1 つの分析テーマを分析して別の分析テーマを作成し、ほかの分析エンジンは同時に複数の分析テーマにアクセスする必要があるといったケースもあります。

UIMA における複数の分析テーマのサポートは、Sofa サポートと呼ばれます。Sofa とは Subject of Analysis (分析テーマ) の頭字語で、アーティファクトの物理的表現形式のことです (たとえば Web ページのタグ付きテキスト、同じ Web ページの HTML テキスト、動画の音声セグメント、同じ音声セグメントの字幕テキストなど)。1 つの Sofa は複数の CAS ビューと関連付けることができます。1 つの CAS は 1 つまたは複数のビューを持ち、各ビューが特定の分析テーマに対応し、そのビューで作成されたメタデータをインデックス化した一連の定義済みインデックスを保持しています。

分析結果は、特定のビューでインデックス化すること、すなわち特定のビューに「所属」することができます。UIMA コンポーネントは、複数の Sofa を同時に作成、アクセスできる「マルチビュー」モードで記述することもできれば、単一の Sofa に対応する、CAS の特定のビューを受け取る「シングルビュー」モードで記述することもできます。シングルビューモードコンポーネントでは、そのコンポーネントを作成する開発者が、実行時に特定のビューがそのコンポーネントに渡されるよう、必要な情報を提供する必要があります。それには Sofa マッピング用の XML ディスクリプタを使います (「6.4 Sofa 名のマッピング」を参照してください)。

マルチビュー機能は、テキストのみの処理の場合でも利点があります。入力ドキュメントをある形式から別の形式に変換することができるからです。たとえば、HTML のテキストをプレーンテキストに変換したり、ある自然言語を別の自然言語に変換したりといった例が考えられます。

2.8. 次は

この章では、UIMA のさまざまなコンセプトを取り上げて、その概要を説明しました。また、これらのコンセプトを実際に UIMA SDK を使ったアプリケーション構築に応用する方法についても、読者が必要な情報を入手できるよう、UIMA SDK ドキュメントセットのほかの章へのリンクを示しました。

このあとは、セクション 1.2 の「このドキュメントの使い方」に戻り、UIMA を使った開発の始め方について学ぶとよいでしょう。

UIMA アーキテクチャ、フレームワーク、開発ロールについてのより詳しい情報が必要な場合は、次の論文を参照してください。

D. Ferrucci and A. Lally, Building an example application using the Unstructured Information Management Architecture, IBM Systems Journal 43, No. 3, 455-475 (2004).

この論文は http://www.research.ibm.com/journal/sj43-3.html でオンラインで読めます。



[1] 私たちは、CAS の表現機能を拡張し、CAS のセマンティクスを OMG の Essential Meta-Object Facility (EMOF) のセマンティクスと揃え、さらに Eclipse Modeling Framework (http://www.eclipse.org/emf/) の Ecore セマンティクスおよび XMI ベースの表現とも揃えることを計画しています。

第 3 章 UIMA を使うための Eclipse IDE のセットアップ

この章では、Eclipse で UIMA SDK を使うためのセットアップ方法について説明します。Eclipse (http://www.eclipse.org) は、Java をはじめとする多数の言語に対応した人気のあるオープンソースの統合開発環境 (IDE) です。UIMA SDK は Eclipse がなくても使用できます。しかし、便利な UIMA SDK のツールの一部は Eclipse プラットフォームのプラグインとして動作するほか、UIMA SDK のサンプルは Eclipse 環境に簡単にインポートできる形式で提供されているので、Eclipse を使うことを推奨します。

UIMA SDK を Eclipse で使う予定がない場合は、この章をスキップして「第 1 章 アノテータおよび分析エンジン開発者ガイド」へ進んでください。

この章では、次の操作について説明しています。

  • Eclipse のインストール

  • Eclipse 環境への UIMA SDK の Eclipse プラグインのインストール

  • UIMA サンプルコードの Eclipse プロジェクトへのインポート

UIMA Eclipse プラグインは、バージョン 3.1 またはそれ以降の Eclipse で使用することを前提に設計されています。

注意

UIMA Eclipse プラグインを使用するには、バージョン 1.5 またはそれ以降の Java で Eclipse を実行する必要があります。

3.1. インストール

3.1.1. Eclipse のインストール

  • http://www.eclipse.org にアクセスし、指示に従って Eclipse をダウンロードします。

  • 最新のリリースレベル ("Integration level" ではなく) を使用することを推奨します。目的の Eclipse リリースバージョンに移動し、使用するプラットフォームに適したアーカイブをダウンロードします。

  • アーカイブを解凍して Eclipse を c:\ などの適当な場所にインストールします。

  • Eclipse を使うには、ちょっと慣れが必要です。Eclipse を今後よく使う場合は、ヘルプメニューのチュートリアルに目を通しておくとよいでしょう。読んでおくだけの価値はあります。Eclipse とその使い方について解説した書籍も数多くあります。

初めて Eclipse を起動するときは、インストール作業が完了するまで、いくらか時間がかかります。その後 "Welcome" ページが表示されます。画面に表示された情報に目を通したら、矢印をクリックして Welcome ページを閉じ、Eclipse のメイン画面に移動します。

3.1.2. UIMA Eclipse プラグインのインストール

UIMA Eclipse プラグインをインストールする最善の方法は、Eclipse の更新機能を利用することです。Eclipse の更新機能を利用すれば、必要なものすべてが一緒にインストールされます。以下に示すのは、これとは別の、手作業でインストールする方法です。

注意

使用しているコンピュータがプロキシサーバーを介したインターネット接続を利用している場合は、そのことを Eclipse に知らせてください。[Window] メニューから [Preferences...] → [Install/Update] とたどってプロキシに関する設定を Eclipse に入力し、[Proxy Settings] でプロキシに関する情報を設定して HTTP プロキシ接続を有効にします。

Eclipse の更新機能を利用するには、Eclipse を起動し、[Help] [Software Updates] [Find and Install....] の順にメニューをクリックします。 次のページで、[Search for new features to install] を選択し、 [Next] ボタンをクリックします。次の [Update sites to visit] パネルで、[Add a new remote site] ボタンをクリックして、[URL] に「http://www.apache.org/dist/uima/eclipse-update-site」と入力し、[OK] をクリックします。新しく指定したサイトが前のページに表示されます。追加したサイトのチェックボックスはオンになっているはずです。

[Europa (または Callisto) Discovery Site] もチェックしてください。ここには EMF コアプラグインが置いてあります (EMF とは Eclipse Modeling Framework のことで、Eclipse のアドオンです。UIMA Eclipse ツールの一部で使用します)。

[Finish] をクリックし、画面の指示に従って UIMA プラグインをインストールします。インストールされた EMF の互換レベルが足りない場合、UIMA プラグインを選択したときに、EMF が必要ですというメッセージが表示されます。ダウンロードするプラグインのリストに EMF を追加するには、該当する [Discovery Site] の [+] 記号をクリックしてエントリを開き、パネル右の [Select Required] ボタンをクリックします。これで、必要な EMF の部分が選択されます。

3.1.3. 追加の Eclipse コンポーネントの手動インストール: EMF

上の手順に従って EMF をインストールした場合、このセクションはスキップできます。

警告

EMF には多くのバージョンがありますが、実行している Eclipse のレベルに対応したバージョンの EMF をインストールしなければなりません。下に説明する Eclipse の更新機能を利用して EMF をインストールする場合、この操作は自動的に行われます。EMF パッケージを別にダウンロードする場合は、EMF をインストールする前に、実行している Eclipse のレベルに対応したバージョンの EMF であることを確認する必要があります。

ここで説明している手順に従って EMF をインストールする前に、http://www.eclipse.org/emf にアクセスしてインストールに関する指示を読み、"Update Manager" のリンクをクリックして、新規フィーチャーを検索してインストールするための Eclipse の組み込み機能では、どのような URL を使用するのかチェックしておいてください。

EMF をインストールする方法は、随時変更されています。以下では、ほとんどのバージョンで動作すると思われる手順を示します。Eclipse の最新のバージョン (このドキュメントの執筆時点では 3.3) を対象とした簡単な手順については、このセクションの最後を参照してください。

[Help] [Software Updates] [Find and Install] とメニューをたどって、ソフトウェアフィーチャー検索をアクティベートします。[Search for new features to install] を選択し、[Next] をクリックします。EMF を検索するのに使う更新サイトを指定します。このとき、(ダイアログボックス下部の) [Ignore features not applicable to this environment] ボックスがオンになっていることを確認し、[Finish] をクリックします。サイトには、Discovery Site (Callisto、Europa など) のいずれかを使用するとよいでしょう。EMF をはじめ、Eclipse のコンポーネントが揃っています。

Eclipse の更新の検索が始まります。更新サイトのミラーのリストが表示されるかもしれません。[OK] をクリックします。検索が終わると、展開可能なツリー形式で更新のリストが表示されます。ツリーのノードを展開して EMF SDK を探します。どのレベルに表示されるかは、新しいバージョンもリリースされているため、下の図と異なるかもしrません。

EMF の検索結果を示したスクリーンショット

[Next] をクリックします。[Eclipse Modeling Framework (EMF)] を選択して [Next] をクリックし、インストールが完了するまで、使用条件の条項に同意する操作など、求められた操作を行います。場合によっては「unsigned feature」というメッセージが表示されることがあります。この場合は、[Install] をクリックしてください。再起動を促すメッセージが表示されたら、再起動します。

これで、EMF 単体がインストールされます。(ソースとドキュメントを含む EMF システム全部が必要な場合は、[EMF SDK] と [Examples for Eclipse Modeling Framework] を選択してください。)

3.1.3.1. Eclipse 3.2 での EMF のインストール手順

Eclipse 3.2 以降、すべての主要な Eclipse のサブプロジェクトは、リリースのタイムフレームについて協調して作業を行っており、リリースを同期させています。3.2 のコードネームは Callisto でしたが、3.3 のコードネームは Europa です。EMF は、リリース Discovery Site を使って以下の要領で簡単にインストールできます。

  1. Eclipse の [Help] メニューで [Software Updates]、[Find and Install...]、[Search for new features to install] の順にクリックします。

  2. [(リリース名) Discovery Site] を選択し、[Next] をクリックします。

  3. 適切なミラーサイトを選択します。

  4. [Models and model development] の [EMF] を選択します。

  5. あとは画面の指示に従って操作します。

3.1.4. UIMA SDK のインストール

UIMA SDK をまだインストールしていない場合は、http://incubator.apache.org/uima から UIMA SDK をダウンロードしてインストールしてください。UIMA SDK をインストールしたら、インストール先のルートを指すよう、環境変数 UIMA_HOME を設定し、README に説明に従って adjustExamplePaths.bat または adjustExamplePaths.sh スクリプトを実行します。

環境変数 UIMA_HOME は、%UIMA_HOME%/bin ディレクトリにあるさまざまなコマンドラインスクリプトと uimaj-examples サンプルプロジェクトの eclipse 実行構成で使われます。

3.1.5. UIMA Eclipse プラグインの手動インストール

上で説明した Eclipse の更新機能を使って UIMA プラグインをインストールした場合、このセクションはスキップできます。

Eclipse の更新機能を使って UIMA プラグインをインストールすることができない場合は、UIMA プラグインを手作業でインストールすることができます。%UIMA_HOME%/eclipsePlugins (環境変数 %UIMA_HOME% は UIMA SDK のインストール先です) には、一連のファイルがあります。これらのファイルを %ECLIPSE_HOME%/eclipse/plugins ディレクトリ (%ECLIPSE_HOME% は Eclipse のインストール先です) にコピーしてください。

3.1.6. Eclipse の起動

Eclipse をすでに実行している場合は、-clean オプションを使って Eclipse を再起動 (シャットダウンしてから再度起動) します。具体的には、Eclipse のインストール先ディレクトリでコマンド eclipse -clean を実行します (オプションの説明については次のセクションを参照してください)。デスクトップのショートカットが必要な場合は、ここで作成しておくとよいでしょう。

3.1.6.1. Eclipse の特別な起動時パラメータ: -clean

Eclipse 3.x では、Eclipse を初めて起動した後、(ファイルシステム上のディレクトリにファイルを直接コピーするなどの操作を行って) プラグインの構造を変更した場合は、(プラグイン変更後の) Eclipse の起動時に 1 回だけ "-clean"パラメータ を指定して Eclipse を起動してください。この操作を行わないと、Eclipse 側では変更があったことを認識できません。このパラメータを指定すると、Eclipse は起動時にすべてのプラグインを調べ直し、プラグインのキャッシュ情報を再作成します。

3.2. Eclipse によるサンプルコードの表示

あとの章ではサンプルコードを参照しています。Eclipse では、サンプルを保持するための特別なプロジェクトを作成できます。次に示すのはその方法です。

  • Eclipse で、Java パースペクティブが開かれていない場合は、[Window] [Open Perspective] [Java] をクリックし、Java パースペクティブに切り替えます。

  • UIMA_HOME という名前のクラスパス変数を作成し、値に UIMA SDK のインストール先を設定します。手順は次のとおりです。

    • [Window] [Preferences] [Java] [Build Path] [Classpath Variables] の順にクリックします。

    • [New] をクリックします。

    • [Name] フィールドに「UIMA_HOME」(すべて大文字で左のとおりに入力します) と入力します。

    • [Path] フィールドにインストール先ディレクトリ (C:/Program Files/apache-uima など) を入力します。

    • [New Variable Entry] ダイアログボックスで [OK] をクリックします。

    • [Preferences] ダイアログボックスで [OK] をクリックします。

    • フルビルドを行うかどうか尋ねられたら [Yes] をクリックします。

  • [File] [Import] の順にクリックします。

  • [General] の [Existing Project into Workspace] を選択し、[Next] ボタンをクリックします。

  • [Browse] をクリックし、%UIMA_HOME%/ ディレクトリに移動します。

  • [Finish] をクリックします。これで、[uimaj-examples] という名前の新しいプロジェクトが Eclipse ワークスペースに作成されます。コンパイルエラーは発生しないはずです。

プロジェクトが適切にセットアップされたかどうかを調べるには、[Problems] ビューにエラーメッセージが表示されていないことを確認してください。

3.3. jar ファイルへの UIMA ソースコードの追加

Eclipse から UIMA ソースコードにジャンプしたり、デバッガでソースコードをステップ実行したい場合は、UIMA ソースコードを jar ファイルに追加してください。この作業を行うためのシェルスクリプトがソースディストリビューションに付属しています。ソースコードを jar ファイルに追加するには、次の手順を実行する必要があります。

  • UIMA ソースディストリビューションをダウンロードして展開します。

  • UIMA バイナリディストリビューションをダウンロードしてインストールします (環境変数 UIMA_HOME が UIMA バイナリディストリビューションのインストール先を指している必要があります)。

  • ソースディストリビューションのルートディレクトリにある addSourceToJars スクリプトを実行します。

これで、ソースコードが jar ファイルに追加され、Eclipse から利用できるようになります。Eclipse の側ではこれ以外にセットアップを行う必要はありません。

3.4. UIMA Javadoc の添付

バイナリディストリビューションには UIMA の Javadoc も含まれています。これらの Javadoc は、上に説明した uima-examples プロジェクト の UIMA ライブラリ jar ファイルに添付されています。Javadoc は自分のプロジェクトに添付することもできます。

注意

前のセクションで説明した手順に従ってソースを添付している場合は、Javadoc を添付する必要はありません。ソースに Javadoc のコメントが含まれているからです。

Javadoc を添付すると、UIMA API の Javadoc ヘルプを参照できるようになります。Javadoc を添付した後、UIMA API の要素をマウスでポイントすると、対応する Javadoc が表示されます。[F2] キーを押すと吹き出しを表示したままにすることができます。[Shift] + [F2] キーを押すと、システムのデフォルトの Web ブラウザで、その要素の Javadoc 情報の全体を表示することができます。

吹き出しを表示したくない場合は、[Window] [Preferences] [Java] [Editors] [hovers] の順にクリックして設定を変更してください。

Eclipse には Javadoc "ビュー" もあり、[Window] [Show View] [Javadoc] の順にクリックすれば表示できます。

Eclipse ワークスペースのほかのプロジェクトで再利用できるよう、Javadoc を添付した UIMA "ライブラリ" をセットアップする方法については、「セクション 1.1 Eclipse のユーザーライブラリの使用」を参照してください。

Javadoc は、自分が興味を持つ可能性があるどの UIMA ライブラリ jar にも添付することができます。有益なのは uima-core.jar でしょう。コア API は最も頻繁に使うものだからです。

次に示すのは、ソースコード中のクラス名 "CAS" をポイントしたときに表示された吹き出しです。

UIMA API の吹き出しのスクリーンショット

3.5. Eclipse からの外部ツールの実行

UIMA SDK の bin ディレクトリにあるシェルスクリプトを使えば、Eclipse をまったく使わなくても、さまざまなツールを実行することができます。また、多くのツールは Eclipse の内部から実行することができます。例を挙げれば、ドキュメントアナライザ、CPE コンフィギュレータ、CAS ビジュアルデバッガ、JCasGen などです。uimaj-examples プロジェクトでは、この操作を簡単に行えるよう、Eclipse 実行構成が用意されています。

Eclipse からツールを実行するには、次の手順に従ってください。

  • Java パースペクティブが開かれていない場合は、[Window] [Open Perspective] [Java] をクリックし、Java パースペクティブに切り替えます。

  • [Run] [Run...] の順にクリックします。

  • 表示されるウィンドウで、左の実行構成のリストから [UIMA CPE GUI]、[UIMA CAS Visual Debugger]、[UIMA JCasGen]、または [UIMA Document Analyzer] を選択します。(項目が表示されない場合は、uimaj-examples プロジェクトを選択し、[Menu] [File] [Refresh] の順にクリックしてください。)

  • [Run] ボタンをクリックします。ツールが起動します。ウィンドウ右上隅の [X] をクリックしてツールを閉じます。

ドキュメントアナライザおよび CPE コンフィギュレータの使い方については、「第 3 章 ドキュメントアナライザ ユーザーガイド」と「第 2 章 CPE コンフィギュレータ ユーザーガイド」を参照してください。CAS ビジュアルデバッガおよび JCasGen の使い方については、「第 5 章 CAS ビジュアルデバッガ」と「第 8 章 JCasGen ユーザーガイド」を参照してください。

第 4 章 UIMA FAQ

UIMA とは

UIMA は、Unstructured Information Management Architecture の略です。UIMA は、構造化されていない情報、すなわち非構造化情報のマルチモーダル分析を開発、発見、合成、およびデプロイするためのコンポーネントソフトウェアアーキテクチャです。

UIMA の処理は、分析エンジンと呼ばれる一連のモジュールを通じて行われます。分析の結果は、非構造化データへのセマンティクスの割り当てです。たとえば、"Washington" は人の名前を表している、または場所を表している、などです。

分析エンジンの出力は、リレーショナルデータベースや検索エンジンインデックスなど、従来からある構造に保存することができ、推論されたセマンティクスをたよりに、元の構造化されていない情報の内容に効率的にアクセスすることができます。

UIMA は、異なるプラットフォーム間や分散チーム間でもコンポーネントを作成、統合、デプロイできるようにし、UIM アプリケーションの開発を支援します。

UIMA はどう発音するのですか?

You – eee – muh (ユー - イー - マー)。

UIMA と Apache UIMA はどう違うのですか?

UIMA は、コンポーネントインタフェース、デザインパターン、データ表現、開発ロールについて定めたアーキテクチャです。

Apache UIMA は、Apache.org で現在インキュベーション段階になっている Apache ライセンスのソフトウェアプロジェクトです。Apache UIMA には、Java と C++ の実行時フレームワーク、API、および UIMA コンポーネントを実装、合成、パッケージ化、デプロイするための各種ツールが含まれています。

開発者は UIMA 実行時フレームワークを利用することで、作成したコンポーネントとアプリケーションをプラグインし、これらをさまざまなプラットフォームで実行できます。また、密結合 (同一プロセス空間内での実行) から疎結合 (スケーラビリティ、柔軟性、回復可能性を高めるために、異なるプロセスまたはマシンで分散して実行) まで、さまざまなデプロイメントオプションを利用できます。

UIMA にセマンティック検索エンジンは含まれていますか?

Apache UIMA プロジェクト自体には、セマンティック検索エンジンは含まれていません。Apache UIMA は、(www.alphaworks.ibm.com/tech/uima で入手可能な) セマンティック検索エンジンコンポーネントを使って、分析結果を対象とするインデックス化やクエリを行うことができます。開発チームでは、今後、検索エンジンがさらに追加され、セマンティック検索のサポートが増えることを期待しています。

アノテーションとは?

アノテーション (注釈) とは、ドキュメントのリージョンに関連付けられたメタデータのことです。アノテーションはしばしばラベルで、通常、文字列で表現されます。リージョンが文書全体であることもあります。

テキストのスパン "George Washington" に関連付けられたラベル "Person" は、アノテーションの例です。すなわち、"Person" は、"George Washington was the first president of the United States." という文のなかの "George Washington" にアノテーションを付けています。ラベル "Person" を特定スパンのテキストに関連付けること、これがアノテーションです。"American Presidents" のようにトピックを表すアノテーションもあり、この場合はドキュメント全体にラベルを付けるために使われています。

アノテーションの対象は、テキストのリージョンだけに限りません。画像のリージョンや音声のセグメントに対しても、アノテーションを付けることができます。この場合も、考え方は同じです。

CAS とは?

CAS は、Common Analysis Structure の略です。CAS は、協調して動作する UIMA コンポーネントに対し、分析対象のアーティファクト (ドキュメント、音声ファイル、動画ストリームなど) および現在の分析結果の共通の表現を提供し、これらにアクセスできるようします。

CAS には何が含まれているのですか?

CAS はデータ構造で、UIMA はこのデータ構造に対し、さまざまなインタフェースを用意しています。CAS は分析アルゴリズムを含んでおり、次のものへのアクセスをアプリケーション開発者に提供します。

  • Sofa (Subject of Analysis: 分析テーマ) (ドキュメントなどの分析対象のアーティファクト)

  • 分析結果またはメタデータ (アノテーション、解析ツリー、関係、エンティティなど)

  • 分析結果に対するインデックス

  • 型システム (分析結果のスキーマ)

CAS は分析対象のアーティファクトの複数のバージョン (raw 形式の html ドキュメントとそのタグなしバージョン、または英語バージョンと対応するドイツ語バージョン、あるいは音声サンプルと対応するテキストなど) を保持できます。分析結果のインスタンスは、各バージョンで別に存在します。

CAS に含まれているのはアノテーションだけですか?

いいえ。CAS には分析対象のアーティファクトに加え、分析結果が含まれています。分析結果とは、分析エンジンによって CAS に記録されたメタデータです。分析結果で最も一般的なのは、アノテーションの追加です。しかし、分析エンジンは、CAS の型システムに合致する任意の構造を CAS に書き込むことができます。これらは、アノテーションではなくて他のものであってもかまいません。たとえば、複数のアノテーション間のつながりや、アノテーションに関連付けられたオブジェクトのプロパティであってもかまいません。

CAS は分析対象のアーティファクトの複数の表現を持つことができ、そのそれぞれは CAS 内では個々の分析テーマ (Sofa) として表現されます。

CAS は単なる XML ではないのですか?

いいえ、単なる XML ではありません。CAS はさまざまな表現が可能です。すべての分析エンジンが同一プロセス内で実行される場合には、効率的なインメモリデータオブジェクトが使われます。CAS をリモートマシン上の別の分析エンジンに送る必要がある場合、XML を介するか、または CAS をバイナリシリアル化することで、この処理を行うことができます。

UIMA フレームワークでは、XMI と呼ばれる CAS の XML 表現に対応したシリアル化メソッドおよび逆シリアル化メソッドを提供しています。

型システムとは?

型システムは CAS のスキーマまたはクラスモデルと考えることができます。型システムは、CAS 内でインスタンス化することができるオブジェクトの型およびプロパティ (または特性 (feature)) を定義します。個々の CAS は特定の型システムに従っています。UIMA コンポーネントは、その入力と出力をある型システムに従って宣言します。

型システムには、型の定義、型のプロパティ、範囲型 (プロパティの値をほかの型に制限できます)、および型の単一継承の階層構造が含まれています。

Sofa とは?

Sofa は、Subject of Analysis (分析テーマ) の略です。CAS は、UIMA 分析エンジンのコレクションによって分析される単一のアーティファクトと関連付けられています。しかし、単一のアーティファクトは複数の独立したビューを持つことができ、各ビューは、異なる一連の分析エンジンによって別個に分析することができます。たとえば、あるドキュメントがあったとすると、このドキュメントはさまざまな翻訳を持つことができます。この場合、それぞれの翻訳は元のドキュメントと関連付けられていますが、潜在的にはそれぞれを異なるエンジンで分析することができます。CAS は複数のビューを持つことができ、各ビューは、元のアーティファクトの何らかのバージョンに対応する分析テーマ (Subject of Analysis: Sofa) を含んでいます。このしくみはマルチモーダル分析を行うときに威力を発揮します。たとえば、動画ストリームのビデオフレームも 1 つのビューなら、字幕も 1 つのビューです。

アノテータと分析エンジンはどう違うのですか?

UIMA の用語では、アノテータとは単に、ドキュメントを分析してドキュメントの内容についてのアノテーションを出力する何らかのコードを指します。UIMA フレームワークは、アノテータ、およびアノテータの入力要件や出力の型などについて記述したメタデータを受け取って、分析エンジンを生成します。

分析エンジンには、UIMA フレームワークが提供するインフラが含まれており、このインフラが存在することによって、さまざまなフローや多様なデプロイメントオプション (1 箇所にまとめて配置 (collocated)、または Web サービスとして配置など) に従って、分析エンジンをほかの分析エンジンと簡単に組み合わせることができるようになっています。

分析エンジンはフレームワークが生成するオブジェクトであり、アプリケーションはこのオブジェクトを操作することになります。アノテータは、サポートされているアノテータインタフェースのいずれかを実装したユーザー作成クラスです。

UIMA 分析エンジンは Web サービスですか?

Web サービスとしてデプロイすることもできます。Web サービスとしての分析エンジンのデプロイは、UIMA フレームワークがサポートしているデプロイメントオプションの 1 つです。

分析エンジンは「ステートレス」である必要がありますか?

それはユーザーが指定できます。コンポーネントの XML メタデータには operationalProperties 要素が含まれており、該当する分析エンジンを複数デプロイメントできるかどうかをこの要素で指定できます。値が true の場合、分析エンジンの特定の 1 つのインスタンスからは、処理される CAS の一部が見えない場合があります。値が false の場合、そのコンポーネントからは、処理されるすべての CAS が見えます。この場合、コンポーネントはすべての CAS を通じて状態情報を蓄積することができます。通常、メインの分析パイプラインの分析エンジンは multipleDeploymentAllowed = true とマークされています。一方、CAS コンシューマコンポーネントは、デフォルトでこのプロパティが false に設定されており、コレクション全体の分析結果を集約する (データベースや検索エンジンなどの) リソースと関連付けられているのがふつうです。

分析エンジンの開発者は、並列環境で使われた場合に分析エンジンが規定どおりに動作しなくなるような複数ドキュメント間での状態の保持は行わないようにしてください。

エンジンのメタデータは Web サービスおよび UDDI と互換性がありますか?

すべての UIMA コンポーネントの実装は、コンポーネントディスクリプタと関連付けられています。コンポーネントディスクリプタは、コンポーネントの発見、再利用、有効性確認、自動合成、および開発ツールをサポートするためのさまざまなプロパティについて記述したメタデータを表します。原則として、UIMA コンポーネントディスクリプタは Web サービスおよび UDDI と互換性があります。ただし、UIMA フレームワークでは現在、コンポーネントメタデータ用に独自の XML 表現を使用しています。UIMA の XML 表現と WSDL 標準および UDDI 標準との間で変換を行うのは、むずかしくはないでしょう。

UIMA アプリケーションのスケーリングはどのように行うのですか?

UIMA フレームワークでは、分析エンジンや CAS コンシューマなどのコンポーネントをサービスとしてデプロイしたり、ほかのコンテナにデプロイしたりすることが簡単に行えるようになっており、スケーリングを目的として設計されたシステムミドルウェアでこれらのコンポーネントを容易に管理できます。UIMA アプリケーションは本質的に複数のドキュメントにまたがってスケールアウトするように作られており、多数のドキュメントを並行して分析できるようになっています。

UIMA フレームワークの CPM (Collection Processing Manager) と呼ばれるコンポーネントには、UIMA アプリケーションをスケーリングしてそのスループットと回復可能性を向上するための数多くの機能と構成が用意されています。

システムミドルウェアに UIMA を埋め込むというのはどういう意味ですか?

IBM WebSphere などのアプリケーションサーバーに Enterprise Java Bean として UIMA 分析エンジンをデプロイするのは、埋め込みの 1 つの例です。こうした埋め込みにより、デプロイを行うユーザーは WebSphere の提供する各種機能やツールを使用して、スケーラビリティやサービス管理、回復可能性などを実現することができます。UIMA はあらゆる特定のシステムミドルウェアから独立しているので、分析エンジンはほかのアプリケーションサーバー上にもデプロイすることができます。

CPM は CPE とどう違うのですか?

CPM と CPE は、コレクション処理のうち、互いに相補う側面を表しています。CPM (Collection Processing Manager) は UIMA フレームワークの一部で、ドキュメントの大規模なコレクションを分析するためにワークフローの形で UIMA コンポーネントがまとめられている場合に、このワークフローの実行を管理します。UIMA の開発者が、CPM を実装したり記述したりすることはありません。CPM はインフラコードの一部になっていて、コレクション処理のワークフローの実行において、CAS の受け渡し、インスタンス管理、バッチ処理、チェックポイント機能、統計情報の収集、および障害回復を引き受けます。

一方、CPE (Collection Processing Engine) は、CPE ディスクリプタからフレームワークによって作成されるコンポーネントです。CPE ディスクリプタは、コレクションリーダー、CAS イニシャライザ、分析エンジン、および CAS コンシューマを含む一連の UIMA コンポーネントについて記述したものです。これらのコンポーネントがワークフローの形にまとめられて、コレクション分析ジョブすなわち CPE が定義されます。CPE は、ソースコレクションからドキュメントを取得し、ドキュメントの内容で CAS を初期化し、ドキュメントの分析を実行して、コレクションレベルでの結果 (検索エンジンインデックス、データベースなど) を生成します。CPM は、CPE の実行エンジンです。

セマンティック検索とは何ですか? UIMA とどのような関係があるのですか?

セマンティック検索とは、ドキュメントに含まれるキーワードだけでなく、分析エンジンによってテキストと関連付けられたセマンティクスに基づいてユーザーが検索を行うことができるドキュメント検索パラダイムです。UIMA アプリケーションはテキストドキュメントに対して分析を実行し、テキストのリージョンへのアノテーションの形でセマンティクスを生成します。たとえば、UIMA 分析エンジンは、テキスト First Financial Bank が組織について言及していることを発見し、そうした内容のアノテーションを付けることができます。従来のキーワード検索では、first というクエリを実行すると、この語を含むすべてのドキュメントが返されます。first はよく使われる曖昧な用語で、大量に出現するだけでなく、文脈によって異なる意味を持ちます。名前に first を含む組織をユーザーが検索する場合、さまざまな意味で使われた first という語を含む膨大な数のドキュメントをふるいにかける必要があります。セマンティック検索では、分析結果を利用してもっと正確なクエリを実行することができます。たとえば、<organization> first </organization> というセマンティック検索クエリは、組織名の一部に first という語を含むドキュメントの優先順位を高めます。UIMA SDK ドキュメントでは、どうすればセマンティック検索を使って UIMA アプリケーションを構築できるかについて説明しています。UIMA SDK ドキュメントには、XML フラグメントクエリ言語に関する詳しい説明があります。SDK 付属のセマンティック検索エンジンによって使われる具体的なクエリ言語が、この XML フラグメントクエリです。

XML フラグメントクエリは有効な XML ですか?

必ずしも有効な XML になっているわけではありません。XML フラグメントクエリ構文は、UIMA SDK 付属のセマンティック検索エンジンによって解釈されるクエリを記述するのに使われます。このクエリ言語は、ベーシックな XML 構文を直感的手段として用いて、CAS 内に存在している可能性のあるアノテーションの階層パターンを記述します。このクエリ言語は、オーバラップ (overlapping) または クロスオーバー (cross-over) アノテーションを対象とするクエリや、クエリプロセッサによるクエリの解釈に影響を及ぼすその他の特性をサポートするために、有効な XML から逸脱しています。たとえば、ドキュメントとマッチするかどうかを調べるときに、あるキーワードやアノテーションが必須か省略可能かを指定できる記法をクエリ内で使用することができます。

UIMA はテキスト以外のマルチモーダル処理をサポートしていますか?

UIMA アーキテクチャは、テキストや音声、動画を含むマルチモーダル分析の開発、発見、合成、およびデプロイをサポートしています。これまでに、テキスト、スピーチ、および動画を処理するさまざまなアプリケーションが UIMA を使って開発されています。ただし、SDK の現在のリリースには、こうしたマルチモーダルアプリケーションのサンプルは含まれていません。

その代わり SDK にはマルチモーダルアプリケーションの構築に必要な主な機能の使い方の説明とプログラミング例が含まれています。UIMA は複数の分析テーマ (Sofa) をサポートしています。このしくみによって、CAS と関連付けられた単一のアーティファクトが複数のビューを持つことができるようになっています。たとえば、アーティファクトが動画ストリームだったとすると、ある Sofa をビデオフレームに関連付け、別の Sofa は字幕テキストに関連付けるといったことができます。複数の Sofa を持つことができるという UIMA の機能は、SDK の現在のリリースに含まれていて、説明もあります。

UIMA にはほかにも類似のフレームワークがありますか?

自然言語処理のためのフレームワークは、UIMA の前にも数多く存在しています。このうち 2 つは IBM Research で開発されたもので、UIMA の初期のルーツになりました。詳細については、IBM Systems Journal Vol. 43, No. 3 (http://www.research.ibm.com/journal/sj/433/ferrucci.html ) に掲載された UIMA の記事を参照してください。

UIMA はこのときの技術をさまざまな次元でさらに洗練させています。具体的には、さまざまなミドルウェア環境への分散デプロイのサポート、各種ソフトウェア製品プラットフォームへのフレームワーク埋め込みが容易 (商用アプリケーションにとって重要)、コレクション処理アーキテクチャによって幅広いアーキテクチャをカバー、マルチモーダル分析のサポート、異なるプログラミング言語間での効率的な統合のサポート、UIMA を用いたアプリケーションの開発においてさまざまなロールを呼び出す最新ソフトウェア工学の手法をサポート、説明的なコンポーネントメタデータの徹底使用によって開発ツールをサポート、コンポーネントの発見と合成、などです。(これらの機能のすべてが現在のリリースの SDK で利用可能であるわけではない点に注意してください。)

UIMA はオープンソースですか?

はい。UIMA の開発はバージョン 2 から Apache へと移され、Apache オープンソースプロセスの中で開発が行われています。UIMA は、Apache バージョン 2 ライセンスの下でライセンスされています。以前のバージョンは IBM alphaWorks サイト (http://www.alphaworks.ibm.com/tech/uima) で入手することができ、以前のバージョンのソースコードは SourceForge ( http://uima-framework.sourceforge.net/) にあります。

UIMA SDK で必要な Java のバージョンと OS について教えてください。

リリース 2.2.1 以降の UIMA SDK では、Java 1.5 (またはそれ以降) が必要です。2.2.1 より前のリリースでは、少なくとも Java 1.4 が必要で、Java 1.3 (またはそれ以前のバージョン) では動作しません。リリースは、Java 5 と 6 でテストされています。また、主に Windows XP プラットフォームと Linux Intel 32 ビットプラットフォームでテストされており、MacOSX 上でも若干テストが行われています。その他のプラットフォームや JDK の実装でも動作すると思われますが、きちんとテストされているわけではありません。

自分の UIMA アプリケーションを UIMA にかぶせる形で構築することはできますか?

できます。Apache UIMA は Apache バージョン 2 ライセンスの下でライセンスされており、ユーザーはフレームワークまで含めてアプリケーションを構築、配布することができます。

UIMA フレームワークをサポートしている商用製品、または製品の一部として UIMA フレームワークを含む商用製品はありますか?

あります。IBM の WebSphere Information Integration Omnifind Edition 製品 (http://www.ibm.com/developerworks/db2/zones/db2ii または http://www-306.ibm.com/software/data/integration/db2ii/editions_womnifind.html ) は UIMA を内部に 持っており、処理パイプラインへの UIMA アノテータの追加をサポートしています。開発チームでは、ほかの製品への埋め込みについても積極的に働きかけを行っています。

第 5 章 既知の問題

Sun Java 1.4.2_12 が CR 文字を XML にシリアライズしない

(注: Apache UIMA は現在では Java 1.5 を必要としているので、これは問題としては存在しなくなりました。) Sun Java 1.4.2_12 の XML シリアル化サポートは、CR 文字を XML にシリアル化しません。そのため、ドキュメントのテキストに CR 文字が含まれている場合、XCAS または XMI シリアル化で CR 文字が失われ、結果としてアノテーションのオフセットがずれてしまいます。この問題はドキュメントアナライザで目に見える形となって表われ、入力ドキュメントに CR 文字が含まれている場合はハイライトの位置がずれます。

JCasGen のマージ機能がサポートしているのは、1.4 またはそれ以前の Java だけ

JCasGen には、ユーザーの (ハンドコーディングによる) 変更を、JCasGen の生成したコードとマージする機能があります。このマージでサポートされているのは、Java 1.4 の構成要素だけです。JCasGen は、ユーザーの変更したコードに含まれている構成要素が Java 1.4 のものだけである場合は Java 1.4 に準拠したコードを生成し、使用している Java がたとえ 5 またはそれ以降であってもマージは機能します。Java 5 またはそれ以降に固有の構文要素を使うと、マージ作業で適切なマージが行われない可能性があります。

Eclipse ツールのディスクリプタエディタが libgcj 4.1.2 では動作しない

Eclipse ツールのディスクリプタエディタは、libgcj 4.1.2、およびおそらくはその他のバージョンの libgcj でも動作しません。これは libgcj の XML ライブラリの実装のバグが原因と考えられ、クラスキャストエラーが発生します。libgcj は Ubuntu (およびその他の Linux ディストリビューション?) の Eclipse のデフォルト JVM として使われています。問題を回避する方法は、ほかの JVM を使って Eclipse を起動することです。

用語集: 主な用語とコンセプト

集約分析エンジン (Aggregate Analysis Engine)

1 つのフローにまとめられた複数のサブコンポーネント分析エンジンからなる分析エンジン。フローは 2 つの組み込みフローのいずれかであるか、またはユーザーが提供したカスタムフローである場合があります。

分析エンジン (Analysis Engine)

アーティファクト (ドキュメントなど) を分析してアーティファクトに関する情報を推論するプログラムのことで、UIMA 分析エンジンインタフェース仕様を実装しているものをいいます。プログラムがどんなフレームワークを使ってどのように構築されているか、コンポーネント (サブ) 分析エンジンを含むかどうかは問いません。

アノテーション (注釈) (Annotation)

ラベルなどのメタデータと、テキスト (またはその他のタイプのアーティファクト) のリージョンとの関連付けのことです。たとえば、John Doe というテキストと関連付けられた Person というラベルはアノテーションです。すなわち、Person は、John Doe を含んでいる X から Y までのテキストのスパンにアノテーションをつけています。アノテーションは、UIMA の型システムの中で特別なとして表現されます。この型は、Sofa のリージョンへのラベル付けを記録するのに使われます。

アノテータ (Annotator)

UIMA アノテータインタフェースを実装するソフトウェアコンポーネントです。アノテータは、アーティファクト (テキストドキュメント、音声、動画など) のリージョンに対してアノテーションを生成、記録することを目的として実装されます。

アプリケーション

アプリケーションとは、UIMA フレームワークの機能を呼び出して特定のディスクリプタから分析エンジンまたは CPE (Collection Processing Engine) をインスタンス化し、これを実行する処理を包み込んでいる外側のコードのことです。

Apache UIMA Java フレームワーク

UIMA アーキテクチャの Java ベースの実装です。Apache UIMA Java フレームワークが提供する実行時環境では、開発者は自分の開発した UIMA コンポーネントの実装をプラグインすることができます。また、開発者は、UIMA フレームワークが提供する実行時環境を使って、UIM アプリケーションを構築、デプロイすることができます。このフレームワークは、Apache UIMA SDK のコアとなる部分です。

Apache UIMA ソフトウェア開発キット (SDK)

現在あなたが読んでいるこのドキュメントが対象としている SDK のことです。SDK には、フレームワークのほか、ツール群やサンプルなどの追加コンポーネントが含まれています。一部のツールは、Eclipse ベース (http://www.eclipse.org/) です。

CAS

UIMA Common Analysis Structure、すなわち CAS は、UIMA 分析コンポーネントが分析結果を表現して公開するために使う基本的なデータ構造です。CAS には次のものが含まれています。

  • アーティファクト。これは、テキストドキュメントや音声、動画ストリームなどの分析対象のオブジェクトです。CAS は、アーティファクトの 1 つ以上のビューを提示します。各ビューは、Sofa と呼ばれます。

  • 型システムの記述 – 型、サブタイプ、およびその他の特性 (feature) を示します。

  • 分析メタデータ – アーティファクトまたはアーティファクトの 1 つのリージョンについて記述した スタンドオフ アノテーションです。

  • 分析結果に対する効率的アクセスと繰り返し処理をサポートするインデックスリポジトリ。

CAS に対する UIMA のプライマリインタフェースは、Common Analysis System と呼ばれるクラスによって提供されます。CAS という用語は、構造とこのシステムのどちらを表すのにも使われます。Common Analysis Structure はさまざまなインタフェースを通じて使われますが、具体的な実装を示す用語があります。たとえば、JCas は、Common Analysis Structure の内容を表すネイティブ Java オブジェクト表現です。

CAS は複数のビューを持つことができます。各ビューは、アーティファクトの 1 つの表現で、この表現は重複することがありません。各ビューは、それぞれのビューの分析結果を表す独自のインデックスリポジトリを持っています。

CAS コンシューマ (CAS Consumer)

一般に分析エンジンによって処理された後、コレクション内の各 CAS を受け取るコンポーネント。CAS コンシューマは、CAS から分析結果を受け取り、結果を選択してデータベースに格納するなど、受け取った分析結果を何らかの目的のために使う役割を果たします。CAS コンシューマでは、コレクションレベルで分析を行って、結果をアプリケーション固有の集約データ構造に保存するといったこともできます。

CAS イニシャライザ (CAS Initializer) (非推奨)

バージョン 2 以前では、これは未定義入力形式を受け取って特定の Sofa を生成するコンポーネントでした。バージョン 2 では、これは任意の分析エンジンを使う方法に置き換えられており、分析エンジンが特定の CAS ビューを受け取って、新しく出力 Sofa を作成します。たとえば、ドキュメントが HTML だとすると、分析エンジンでは入力 CAS ビューのタグなしバージョンに相当する Sofa を作成し、タグを基にアノテーションを作成するといった処理が考えられます。たとえば、<p> タグは CAS では Paragraph アノテーションへと変換することができるでしょう。

CAS マルチプライヤ (CAS Multiplier)

UIMA 開発者が実装し、CAS を入力として受け取って 0 個以上の新しい CAS を出力として生成するコンポーネントです。CAS マルチプライヤの一般的なユースケースとして、入力 Sofa (CAS イニシャライザ を参照) の代替バージョンを作成する、大規模な CAS を小さな部分に分割して、それぞれを別個の出力 CAS として出力する、といった処理があります。また、複数の入力 CAS を単一の出力 CAS に集約するといった使い方もあります。

CAS プロセッサ (CAS Processor)

CAS を入力として受け取って CAS を出力として返す CPE (Collection Processing Engine) のコンポーネントです。CAS プロセッサには、分析エンジン CAS コンシューマという 2 つの種類があります。

CAS ビュー (CAS View)

ベースになる CAS と型システム定義およびインデックス仕様を共有する一方で、固有のインデックスリポジトリと特定の Sofa を持つ CAS オブジェクト。ビューには名前があり、アプリケーションとアノテータは、必要な場合はいつでも、追加のビューを動的に作成することができます。アノテーションは特定の 1 つのビューに対して作成されます。特性 (feature) 構造は、必要な場合にはほかのビューでインデックス化された特性構造への参照を持つことができます。

CDE

コンポーネントディスクリプタエディタ (Component Descriptor Editor)。UIMA ディスクリプタを簡単に編集できるようにする Eclipse ツールです。「第 1 章 コンポーネントディスクリプタエディタ ユーザーガイド」を参照してください。

CPE (Collection Processing Engine)

1 つのコレクションリーダー、0 個以上の分析エンジン、および 0 個以上の CAS コンシューマの組み合わせを通じて、コレクション処理を実行します。CPM (Collection Processing Manager) は、CPE の実行を管理します。

CPM は CPE の XML 仕様も参照します。CPM は CPE の仕様を読み取って、この仕様から CPE をインスタンス化して実行します。

CPM (Collection Processing Manager)

UIMA フレームワークの一部で、CAS をコレクションリーダーから 0 個以上の分析エンジン、ついで 0 個以上の CAS コンシューマへと渡し、コレクション処理の実行を管理します。CPM は、パフォーマンスに関する統計情報やエラー報告などのフィードバック機能を持つほか、並行処理やエラー処理などの機能もサポートしています。

コレクションリーダー (Collection Reader)

ファイルやデータベースなどの何らかのソースからドキュメントを読み取るコンポーネント。コレクションリーダーは、このドキュメントを用いて CAS を初期化します。各ドキュメントは CAS として返され、返された CAS は続いて分析エンジンによって処理することができます。ドキュメントから CAS を作成する作業が複雑になる場合、任意に組み合わせた一連の分析エンジンを使用して、最後の分析エンジンで、新しい Sofa を作成、初期化するといったこともできます。

ファクト検索 (Fact Search)

ファクトパターンが与えられると、このファクトパターンに一致するファクトを分析エンジンによってドキュメントのコレクションから抽出して返す検索。

特性 (Feature)

ある型のデータメンバまたは属性。各特性は、その特性と関連付けられた範囲型を持っています。範囲型とは、保持することができる値の型です。データベースの比喩を使えば、型はテーブルで、特性は列です。構造化データ型の世界では、各特性は 1 つのフィールド またはデータメンバです。

フローコントローラ (Flow Controller)

集約分析エンジン内部でカスタムフローを指定するのに必要なインタフェースを実装したコンポーネント。

ハイブリッド分析エンジン (Hybrid Analysis Engine)

集約分析エンジンのうち、2 つ以上のコンポーネント分析エンジンが同一アドレス空間にデプロイされ、さらに 1 つ以上のコンポーネント分析エンジンがリモートでデプロイされるものをいいます (コンポーネントの一部が密結合で、別の一部が疎結合)。

インデックス (Index)

CAS 内のデータはインデックスを使ってのみ取得することができます。インデックスは、データベースのテーブルに対して指定されるインデックスに類似しています。インデックスはインデックスリポジトリに属しており、CAS のビューごとに 1 つのリポジトリがあります。何らかの CAS 型 (そのサブタイプも含む) のインスタンスを取得するにはインデックスを指定します。オプションとして、ユーザー定義可能な方法でインデックスをソートすることもできます。たとえば、UIMA の組み込みの型 uima.tcas.Annotation には、アノテーションが付けられたテキストの始まりのオフセットと終わりのオフセットを示す begin 特性と end 特性が含まれています。UIMA では、アノテーションの組み込みのインデックスがあり、このインデックスを使うと、まず begin 特性の値で (昇順に) ソートし、次に end 特性の値で (降順に) ソートされたアノテーションを順番に取得することができます。この場合、アノテーションに対して繰り返し処理を行うと、まずテキスト内で最初に出現するアノテーションが最初に取得される一方、同一のオフセットから始まるアノテーションが複数ある場合は、長いアノテーションの方が優先されます。ユーザーが独自のインデックスを定義することもできます。

JCas

CAS の内容に対する Java オブジェクトインタフェース。このインタフェースは、追加の生成された Java クラスを使用します。CAS の各型は同じ名前の Java クラスによって表現され、各特性は getter および setter メソッドで表現され、ある型のインスタンスは、対応する Java クラスの Java オブジェクトとして表現されます。

キーワード検索 (Keyword Search)

語句 (すなわち キーワード) を指定すると、候補となるドキュメントが返される標準的な検索方法です。

ナレッジベース (Knowledge Base)

ある可能世界において真とみなされる一連のファクトおよびルールとして解釈することができるデータのコレクション。

疎結合分析エンジン (Loosely-Coupled Analysis Engine)

集約分析エンジンのうち、コンポーネント分析エンジンのどの 2 つをとっても同一アドレス空間で実行されるものがなく、各コンポーネント分析エンジンが、その集約分析エンジンを構成するほかのすべてのコンポーネント分析エンジンに対して、リモートでデプロイされるものをいいます。疎結合エンジンは、ローカルで利用可能ではないリモート分析エンジンを使う場合や、異なる言語、異なるプラットフォームによる分散環境において迅速なアセンブル、テスト機能がほしい場合に最適です。また疎結合エンジンは、分析速度よりも、速やかな回復可能性の方が全体のスループットに与える影響が大きいスケーラブルな分散実装を可能にします。

オントロジ ナレッジベースの一部。データのセマンティクスを明確に定義します。

PEAR

UIMA コンポーネントをパッケージ化したアーカイブファイル。コンポーネントのコード、ディスクリプタファイル、およびほかの環境にコンポーネントをインストールして実行するのに必要なその他のリソースも一緒にパッケージ化されます。PEAR ファイルは、UIMA SDK 付属のユーティリティを使って作成できます。

プリミティブな分析エンジン (Primitive Analysis Engine)

単一のアノテータから構成される分析エンジンで、その中にコンポーネント (または サブ) 分析エンジンを含まないものをいいます。集約分析エンジンと対になる用語です。

セマンティック検索 (Semantic Search)

クエリのセマンティックな意図を 1 つ以上のエンティティまたは関係を使って指定する検索。たとえば、Bush という名前の人物を検索することを指定することができます。このクエリは、「茂み」という意味の bush に関係のある結果は返さず、Bush という名前の人物に関係する結果を返します。

構造化情報、構造化された情報 (Structured Information)

検索エンジンインデックス、データベース、ナレッジベースなどの構造化リソースに格納されているアイテム。データベースのテーブルは、構造化情報のよい例です。データベース内の各情報要素が関連付けられているのは正確に定義されたスキーマで、そこでは各テーブル列見出しが明確に意味を示し、コンピュータまたはエンドユーザーが情報をどのように解釈する必要があるかが正確に定義されています。

Sofa (Subject of Analysis: 分析テーマ)

UIMA 分析コンポーネントの分析対象となる、データの 1 つの断片 (テキストドキュメント、画像、音声セグメント、またはビデオセグメントなど)。Sofa は 同じ名前を持つ CAS ビューに属しています。Sofa と CAS ビューの間には 1 対 1 対応の関係があります。1 つの CAS 内には複数の Sofa が含まれていることがあり、各 Sofa それぞれは元のアーティファクトの異なるビューを表します。たとえば、音声ファイルが元のアーティファクトだったとすると、これが 1 つの Sofa にもなり、また音声認識コンポーネントの出力も別の Sofa になります。後者の Sofa は、対応するテキストドキュメントになります。Sofa はそれぞれを別個に分析することもできれば、同時に分析することもできます。Sofa はすべて CAS 内に共存しています。

密結合分析エンジン (Tightly-Coupled Analysis Engine)

集約分析エンジンのうち、そのすべてのコンポーネント分析エンジンが同一アドレス空間で実行されるものをいいます。

型 (Type)

分析結果を格納するのに使われる CAS 内のオブジェクトの仕様。型は継承を使って定義されます。そのため、一部の型は純粋にほかの型を定義する目的でのみ定義され、その意味では、これらの型は抽象型 です。通常、型には特性が含まれています。特性は属性であり、型のプロパティです。型は、オブジェクト指向プログラミング言語におけるクラス、あるいはデータベースのテーブルに相当します。CAS 内の型のインスタンスは、情報を取得するためにインデックス化することができます。

型システム (Type System)

関連するのコレクションです。アプリケーションをはじめ、 分析エンジンコレクションリーダーフローコントローラCAS コンシューマなど、CAS にアクセスできるすべてのコンポーネントは、使用する型システムを宣言します。型システムは分析エンジン相互間で共有され、ある分析エンジンの出力を別の分析エンジンの入力として読み込めるようになっています。型システムは、オブジェクト指向プログラミングにおける関連クラスの集合、あるいはデータベースにおける関連テーブルの集合に相当します。型システム / 型 / 特性という用語は、計算言語学から取られたものです。

非構造化情報、構造化されていない情報 (Unstructured Information)

自然言語のテキストドキュメントは、非構造化情報のよい例です。ドキュメントの内容が意図している意味は暗黙的に示されているのみで、コンピュータプログラムによるその正確な解釈には、ドキュメントのセマンティクスについて説明するための一定の分析が必要です。その他の例として、音声、動画、画像があります。構造化情報と対になる用語です。

UIMA

UIMA は、Unstructured Information Management Architecture の略です。UIMA は、マルチモーダル分析機能の作成、記述、発見、合成、およびデプロイを行うためのコンポーネントインタフェース、デザインパターン、開発ロールについて定めたソフトウェアアーキテクチャです。UIMA 仕様は OASIS の技術委員会で開発されています。

UIMA Java フレームワーク

Apache UIMA Java フレームワークを参照してください。

UIMA SDK

Apache UIMA SDK を参照してください。

XCAS

CAS の XML 表現。XCAS を使うと、CAS をストリームに、またストリームを CAS に保存したり復元したりできます。UIMA SDK では、CAS 用の XCAS シリアル化メソッドおよび逆シリアル化メソッドを提供しています。これは古いシリアル化形式で、新しい UIMA のコードでは、標準の XMI 形式を代わりに使う必要があります。

XML Metadata Interchange (XMI)

XML でオブジェクトグラフを表現するための OMG 標準です。UIMA は XMI を使って、分析結果を CAS から XML 表現へとシリアル化します。UIMA SDK では、CAS 用の XMI シリアル化メソッドおよび逆シリアル化メソッドを提供しています。