[DE | EN | FR | IT | JA | ES | KO | PT]

Brave GNU Worldの新しい号へようこそ。 前々から薄々感じてはいたのですが、 今号では次のことを証明します。 いわく、 Free Softwareはあなたの健康に望ましい!

Debian-Med

多くの分野同様、応用医学の分野には、大量のプロジェクトがあり、 そして、それらは時々非常に進んだものです。 しかし、それらを取り集めひとつの解法としてまとめ上げるのは、 「ふつう」の利用者の手に負えないことです。 これを解決するため、Andreas Tilleは、Debian-Med [5] プロジェクトを2002年のはじめに立ち上げました。これは、 医学や微生物学の領域の利用者向けにDebian配布物件をカスタム化し、 この分野のソフトウェア・プロジェクト群を統合することが、目的です。

Brave GNU Worldの常連読者の方なら、第23号 [6] で紹介したDebian-Jr. [7] プロジェクトのことを思い出したかもしれません。実際、Debian-Medの考えは、 ここから触発されたものです。

私的で高度に内密な人間生命の世界 (spheres) ―医者 (doctor) の場合― と相互に作用するソフトウェアにおいては特に、現在、 Free Softwareだけに可能なような、ある条件を満足する必要があります。

たとえば、患者データの安全性や秘匿性は、ちゃんと確保されている必要があります。 それには、Freeな開発過程を経て一番確実になるような、ある種の透過性が、 いります。

また、一部の検査は健康に有害なおそれがあり、繰り返せない場合もあるため、 データ喪失にたいする安全性は、かなり重要です。 もしデータが失われると、医療サービスの質は明らかに低下します。 と同時に、たいてい、患者から医師 (physician) への信頼が、失墜します。

したがって、この分野では、安全確実で、信頼がおけて、安定した基盤 (OS) と、同様のアプリケーションが必要になります。 自覚的な医師の間では、Free Softwareの利用が、だんだん必要とされつつあります。

驚くまでもなく、プライバシー、データ保護、信頼性、安全確実性は、 Debian-Medの第一目標になっています。

それ以外の中心課題には、使い易さ、インストールや管理のし易さがあるはずで、 実際そうです。

この分野では、誤りや、欲求不満は患者にたいし、不利に働きますが、 使いやすさはそれらのことを防ぎます。 また、簡単なインストールや管理によって、自覚的な医師にとっての、 Free Softwareへの移行上の問題が、減少していきます。 またそのことは、実践的な検討を促します。

Andreasをはじめ、興味をもった70人以上の人たちからなるこのプロジェクトは、 現在、すべてに共通な問題にたいする解法を見つけることと、 それをちゃんとインストールできるようにすることに、専念しています。

中期的展望としては、医師にたいする真の選択肢としてのDebian-Medの提供と、 生実演用のCDの作成があります。

手助けを最も必要としている分野は、文書化と翻訳なのですが、 ロゴもまだないのです。 Andreasは、Debianのロゴとヘビの組合せを考えているようです。

プロジェクト全体の許諾状態は、もちろんソフトウェア各個の許諾に従います。 Debian Free Software Guidelines (DFSG) に準拠した許諾が、選好されます。

残念ながら、このプロジェクトには、 無償で配布可能な独占的ソフトウェアをパッケージにする、という計画もありますが、 これは中長期的な展望に弱点を生むことになります。しかしここで、 長期的な点を考えよう、という願望を表明する人が十分多ければ、 取り返しのつかないことにはならないだろう、と私は思っています。

Free Softwareを医学分野で活用することは、 いつも私がかなり重要だと思っていたことで、 もし自分で入ってみるのに有用なプロジェクトをおさがしであれば、 Debian-Medはそうした選択肢として一番有望でしょう。

Gnumed

Debian-Medで使われているプログラムに、Gnumed [8] があります。 これはペーパーレス医療実務用の公式なGNUプロジェクトです。

このプロジェクトは、オーストラリアで誕生しました。オーストラリアは、2000年3月、 保健部門での独占的ソフトウェアについて、熱い論争が繰り広げられたところです。 医師らは、不透明 (intransparent) なアルゴリズムについて、 それを決定のよりどころにすることを拒否しました。 この論争の中で、Hors Herbは、非建設的な批評のかどで非難され、これがきっかけで、 彼がGnumedに取り組み始めることになりました。

初期作業の後、ロンドンのMedInfo2001でα版が出され、 Gnumedにたいする国際的な興味により、内部構造の全面的な再設計が、 必要となりました。この新しい構造の実装は現在、プロジェクトの主要課題で、 コーディネータのHorst HerbとKarsten Hilbertは、17人の開発者と、 多くのボランティアとともにこれに取り組んでいます。

もう役に立つだろうという期待のある極小版の完成後、Gnumedを、 意思決定支援をふくめて完結した医療解法にすることが、予定されています。

その前に立ちはだかる問題には、自由な薬学データベースのないこと、 さまざまな規制のあるさまざまな保健体系、データ形式のないこと、転送標準、 標準化済みメッセージング・プロトコル、そして、 患者にたいして全体的に一意なIDを作成する体系のないことがあります。

このプロジェクトのプログラミング言語は、信頼性と安全確実性を最重要の規範とし、 クライアント側でPython、C/C++、サーバー側でPgSql、C、Pythonを使っています。 Gnumedチームによれば、独占的な解法だと、 (規範の) どちらもまっとうに処理されていません。

ところで、Gnumedチームは、さまざまな領域の医師らを中心に構成されていますので、 必要なことはとてもよく知っていますが、往々にして、 それをどう実装するのかは知りません。 したがって、経験を積んだ開発者のチームへの加入は、大歓迎です。

Gnumedは、簡単で、人間工学的で、高度に柔軟なGUI、 さまざまな言語や保健体系のサポート、 相対的なプラットホーム独立性を最終的に追求し、 GNU General Public Licenseの下、Free Softwareとして公開されています。

もしあなたがこの部門で活躍したいのであれば、 Gnumedは確かにそうすべきプロジェクトです。

OIO

"Open Infrastructure for Outcomes" (OIO) [9] は、 作者Andrew Hoが呼ぶところの、データの可搬性における「聖杯 (*1) の捜索」です。 Nandalal GunaratneやAlesander Chelnokovらが、彼とともに探求に加わっています。

---

訳注: *1 (the holy grail) 中世の伝説で、キリストが最後の晩餐で用い、 後に十字架上のキリストの体から流れた血を受けたとされる酒杯。 その探求は、アーサー王の円卓の騎士など、しばしば文学作品の主題となっている。

OIOは、GNU General Public Licenseの下、 Free Softwareとして公開された2000年8月よりずっと前の3月から、 Harbor-UCLA Medical Centerで生成に使用されていました。9月には、 もう千名以上の患者のデータを扱い、 2002年2月には、院内情報システムに成長しました。ですので、 OIOは日常活用の準備ができていると証明済み、といえるでしょう。

OIOの主な構成要素には、HTMLでブラウザを経由してアクセスするサーバーと、 OIOのライブラリーがあります。サーバーは融通のきく、 ウェブ・ベースのデータ管理システムで、利用者、患者およびその情報を管理します。 これはもちろん、顧客、送り状、配達、口座に使うこともできます。

OIOライブラリーは高次元データの集積場であり、 サーバーと利用者の間でプロジェクトの説明や、 プラグアンドプレーのウェブ書式といった、高次元データの交換が、これでできます。

OIOの利用者は、ウェブ・ブラウザ経由で書式を作ったり直したりでき、 その書式はその後すぐにウェブ上でデータ収集に使えます。

書式は後々、XMLデータとして取り出して、 OIOライブラリーといった高次元データ集積場に転送したり、 別なOIOサーバーにアップロードしたりできます。

もちろん別々な書式からデータを集めて、単一のデータ集合にし、 論理演算子の助けを借りてそれを検索したり、問い合せたりできます。

OIOは使われてから既にしばらくたっていますが、開発はまだ終わっていません。 将来リリース予定の機能には、無線PDAのサポートがあり、 プラグアンドプレー・プロトコルもサポートされるでしょう。 現在、一番役立つことは、より多くの利用者、より多くのフィードバック、 よりよいパッケージングです。

少なくとも最後の点でいえば、Debian-Medが手助けになるはずです。

Res Medicinae

Christian HellerによるRes Medicinae [10] も、 Debian-Medプロジェクトで使われています。彼は、Karsten Hilbertとともに、 Res Medicinaeを、医学分野における拡張可能なソフトウェア解法にすべく、 取り組んでいます。

最大の移植性を達成するため、Res Medicinaeは、CORBA/IDLやSOAP/XMLも使いつつ、 Java (API/Swing、Servlets/JSP、JDBC) を基本にしています。 Free Softwareによる完全装備のJava実装がないため、GNU General Public Licenseや、 GNU Free Documentation Licenseの下でのFree Softwareプロジェクト最大の問題を、 これは既に表わしています。 そのため、プロジェクトの自由は、危機に直面しています。

しかし、Christianにとって自由は、 Res Medicinaeへの取組を開始する動機のうえでの主要因子でした。 彼は、非常に高価で、独占的な医療情報システムの状況に勝利し、 特権のない国ぐににいる利用者たちに、自由で、安定し、安全で、 プラットホームによらず、拡張可能なシステムを与えることができたようです。

プロジェクトはまだ若く、計画によれば、2002年末には、 ResMedLibフレームワークが合併整理され、 2つの完結したモジュールのプロトタイプができるはずです。 2003年には、管理用モジュール、書式の印刷、報告書の生成がうごくはずです。

最終的には、画像処理、請求書の管理と作成、 統計モジュールが追加されるはずです。意思決定支援と同様、 トレーニング用モジュールの追加で、プロジェクトは完成です。

ですので、おそらく日常生活でこのプロジェクトを使おうと試すべきではないですが、 医療権能、翻訳、Javaプログラミング、 ウェブページ設計をプロジェクトに持ち込むことに興味のある人たちは、 Res Medicinaeから暖かい歓迎を受けることでしょう。

作者の知るかぎり、Res Medicinaeは、 医学分野で唯一のJavaベースのGPLプロジェクトであり、 BSD許諾の下、 同様のJavaプロジェクトであるOpenEMedや、 前述のGnumedプロジェクトと協力して、相互運用性を達成する計画です。

本日の健康コーナーはこのへんで。 もしこの分野に他のプロジェクトがあれば、後の号で紹介したいと思います。 電子メール [1] が、お知らせいただくのにお手頃な方法でしょう。

Romance

Bertrand LamyとJean-Baptiste LamyによるRomance [11] は、 Microsoftの.NETにたいする真にFreeな代替をFree Softwareに与えよう、 という試みです。

Bertrandによると、 おそらくXimianが.NETのFreeな実装を果たすことができないだろう、ということから、 2人の動機がきています。 ソフトウェア特許を使ってFreeな代替と闘争する、 とMicrosoftが既に約束したことにより、 それはまさにもっともらしいことだといえます。

会社により制御される、Freeな参照実装ぬきの標準では、 常にその会社が数歩先んじる一方、 Freeなプロジェクトが後をつけるのに多くの問題があります。 Javaにまつわる状況は、まさにこの効果による苦痛を被っています。

答えは明らかです。我々に必要なのは、Freeな実装のあるFreeな標準で、 それが、Romanceの提供しようと模索しているものです。

第1の部分、そして開発の始まりは、Rose、すなわち、 "Romance Object System rosE"です。 Roseは、さまざまなプログラミング言語間で、 オブジェクトを共有するプロトコルを提供します。

次の段階はWiSe、すなわち、"Romance Widget Server"の開発です。 Romanceサーバーを経由したすべてのRomanceアプリケーションにおける、 GUIのツールキット・ライブラリーとして、これが有効になるでしょう。 WiSEで採用されている規範は、すべてのウイジットが、 別々なアプリケーションの属性ではなく、WiSeプロセスの属性になる、という点です。 それにより、Romanceでは、ウイジットの共有が非常に高速かつ単純になります。

BertrandとJean-Baptisteは、全デスクトップ・アプリケーションの75%が、 スクリプト言語で書けるはずだ、と信じ、まずPython、Guile、 Cのサポートに集中しています。2人の予定だと、Roseは、Perl、Ruby、Lisp、 Scheme、そして他の動的な言語を将来サポートするつもりです。

Romanceの使える例は、たくさんあります。

大きなアプリケーションではたいてい、拡張用に言語を定義するのが、よいことです。 ある言語を択一する代わり、 一連のオブジェクトをRomance経由で使えるようにしておけば、 Romanceのサポートする言語いずれかでアプリケーションを組むことが、 できるようになります。

ネットワークのアプリケーションでは、往々にして通信プロトコルが必須ですが、 これもRomanceで応じることができます。これはCORBAより軽く、 JavaのRMIにくらべてより多くの言語をサポートし、 動的かつ、非静的なオブジェクトでもうごきますので、 そういった点からもRomanceには若干の利点があります。

Romanceは、 別々なプログラミング言語で書かれたプログラムのさまざまな部分の間の 「接着剤 ("glue")」としてもはたらき、SWIGの代替をあたえます。 Romanceは、動的であることから、インターフェースを自動的に 「ロマンチック ("Romantic")」な言語群で有効にするわけです。

Romanceには、WiSE経由で、GUIのウイジットも提供します。 このことは、軽く効果的な方法により、 別々のプロセス間でこれを共有できます。ですので、 グラフィカルなツールキットのリンクは、不必要となり、利用者は、Romanceをとおし、 全アプリケーションの見た目と感じを選択できます。

このような能力を提供しながら、Roseはとても小さく、 Python/Schemeで500行未満に押さえられています。

GNU General Public Licenseの下でリリースされたこのプロジェクトは、 ほとんど開発者向けではありますが、開発者でない人たちにも、 興味深い未来への展望をあたえてくれるはずです。

JavaRisk

Riskゲームのクローンの話をした第39号 [12] の付足しとして、Christian Domsch、Sebastian Kirsch、Andreas HabelによるJavaRisk [13] をご紹介したいと思います。

JavaRiskは、GNU General Public Licenseの下で、 おなじみのボード・ゲームであるRiskをJavaで実装したもので、 ドイツ版のゲームのルールに基づいています。 JavaRiskはコンピュータ・ゲームではあるのですが、 作者は、ネットワーク・サポートや人工プレーヤ (artificial intelligence) の実装をしませんでした。

しかしそのグラフィックスは断トツで、第39号で紹介したゲームのJ-TEGが、 テーマのひとつとして採用したほどのすばらしさです。

JavaRiskは、典型的な学生プロジェクトで、つまりそれは、 作者3人の担当教官がまわりにいる間でさえ、ずっとプレーをやめられなかった、 ということです。

このゲームを初めて見たとき、彼は一瞬で好きになりました。 彼は、第5学期の学生プロジェクトとして、 そのゲーム用の人工プレーヤの実装を3人に勧めました。 また、彼は何でも東洋好みだったので、中国や日本が攻撃されるときはいつも、 武士 (Samurai-fighter) が動いて表示されるように実装するよう、指示しました。

現在、Christian、Sebastian、Andreasは、Empireのような戦略戦争ゲームによく似た、 JavaRiskの新版への取組で忙しくしています。 JavaRisk v2では、最初からネットワーク・プレーのサポートもするでしょう。

EmacsChess

Mario Langは、第39号への反響を私に書き送って、 John WiegleyによるEmacs Chess [14] プロジェクトについて書くことを、 勧めてくれました。

Emacs Chessには、3つの主要部分があります。第1の部分は、 Emacsでさまざまな盤面を表示するためのフロントエンド機能です。第2は、 GNU Chessや、Craftyといった、さまざまなチェス・エンジンとの通信部分です。 第3の部分は、ゲームや定石のライブラリーで、これは、指し手の有効性検査や、 ゲーム・データベースの管理を含んでいます。

Emacs Chessのとてもご機嫌な機能の中に、 Emacs IRC Client (ERC) [15] がEmacs Chessをサポートしていることがあります。 もしIRCにいる誰かがEmacs ChessとERCを使っていれば、 その人とゲームを始めることができるわけです。

IRCのチェスプロトコルは、CTCPに基づいているので、 他のクライアントでも互換性のある機能を実装できます。

Emacsはコンソールでもうごくので、画像の使えない利用者にたいしても、 Emacs Chessは「ナイトをaの4に」といった形で指し手をあらわして、 良好な「チェス」のフロントエンドをあたえます。 もちろん、画像の使える人たちでも、このご機嫌な機能を使うことができます。

何しろEmacs Chessですから、Emacsを使っていない人たちは、 おそらくこれを使い始めることはないでしょうが、 Emacs仲間なら誰でも、本当に試す価値のあるものです。

Emacs Chessは、Emacs-Lispで書いてあり、GNU General Public Licenseの下で、 βテスト・ソフトウェアとして公開されていますので、若干の困難性が予想されます。

おしまい

今月のBrave GNU Worldはここまで。 お考え、ご提案、コメント、興味深いプロジェクトのお知らせは、 おなじみのアドレス [1] でいつでも歓迎しています。