トピックマップ、RDF、DAML、OIL

A comparison

By:	Lars Marius Garshol
所属	Ontopia
Email:	larsga@ontopia.net
Web:	http://www.ontopia.net/

（訳者注） 以下は、http://www.ontopia.net/topicmaps/materials/tmrdfoildaml.html

の翻訳です。訳文上の誤りなどの可能性があります。

RDFとTopic Mapsの関係については、Steve Pepperの Ten Theses on Topic Maps and RDF 　にも簡単な解説がある。

要約

RDF、OIL、DAML、およびトピックマップという用語は、セマンティックWebやKM、情報管理が議論される際に良く使われる技術である。しかし、これらのうち２つ以上を知っている人はほとんどいない。本論文では、これらの技術を簡単に説明し、類似点/相違点を明らかにすることで、そうした状況を改善していこうと思う。これらの技術は全く異なったバックグラウンドから来ており、表現形式も全く違う。しかし、よく調べてみればこれらの中身は驚くほど似ている。

まず、これらが限定的ではあるものの、世界における何かを述べる技術であることからはじめよう。これらの技術により、どのように、「もの」、「ものの性質」、「もののタイプ」、「ものの名前」、「ものの種類」などの概念がどのように記述されるだろうか。技術を比較した後で、これらがどう関連し、依存し、競合しているかを見ることにする。また、現実に重要な点として、データをある表現から別の表現にどう変換できるか、そして、これら技術のツールをどのように組み合わせて動かせるかについて述べる。

著者紹介

Lars Marius Garsholは、現在トピックマップのソフトウェアベンダであるOntopi社の開発マネージャである。彼は何年間もXMLやトピックマップコミュニティにおいて、発表者や、コンサルタント、およびオープン・ソース開発者として活動している。

Lars MariusはOperaウェブブラウザのUnicodeサポートの責任者でもある。現在、彼は、「XMLアプリケーションの開発」という本を書き上げた所で、まもなく今年中にはPrentice-Hall社からChales Goldfarbシリーズとして出版される。Lars MariusはISO Topic Map Query Languageスタンダードのエディタのひとりである、そして、Topic Mapのデータモデルの共同エディタでもある。

1.　規格間の相互運用性

「標準規格の良い所は、沢山のものから選べることである。」というような、古いジョークがある。標準規格が多く存在することが本当に良いかどうかは別として、このジョークは少なくともRDF、トピックマップ、 DAML, OIL について当てはまる。標準規格を作る主な目的は、データやアプリケーション間での相互運用を可能にすることである。しかし、データやアプリが固有技術を使っている場合には、これは難しいことが多い。

本論文が何よりも役立つのは、読者がこうした標準化の間でどのくらい機能がオーバーラップしているか分かるようになることである。目的にあわせて正しい標準を選べることができるように、これらの規格を比較し、どのように規格間でデータを変換できるかを見ていこう。

1.1.　標準化の背景

トピックマップの歴史は長く複雑である。それは、ダヴェンポートグループが1991年にソフトウェアドキュメンテーションのために標準SGML DTDを作成する過程から始まった。このグループは、まもなくCApH (Conventions for the Application of HyTime)という副産物を生み出した。CApHとは、本の末尾にあるようなインデックスを計算機で扱うアプリケーションを設計することが一つの仕事であった。このインデックスにはある新しい特徴として、「インデックスのマージが自動的にできること」があった。この考えがその後トピックマップに発展した。CApHは長い間、概念の記述に取り組み、1996年にトピックマップはISOのSGMLワーキンググループによって新しいワークアイテムとなった。 ISOでは標準化に4年かけて、2000年1月にISO/IEC13250:2000が承認された([ISO13250]　なお、このときのトピックマップは、HyTimeによるSGMLベースであった)。その後、TopicMaps.Orgという非公式組織で、XTM (XML Topic Maps)構文が作られた([XTM1.0])　これはXLinkに基づきXML構文によるトピックマップの再定式化であった。この構文はISOに受け入れられ、ISO13250の添付書類になった。XTM構文は今日ほとんど全てのトピックマップソフトウェアによって使われており、むしろオリジナルのSGML構文を扱えるものはまれである。

トピックマップには、多くの応用があるが、1つの大きな応用は、情報の「findability問題」を解決することである。つまり、大量の情報の中からどのように人が欲しい情報を見つけるか、である。 またトピックマップは、KM、ウェブポータルの開発、コンテンツマネジメント、および企業内アプリケーション統合(EAI)にも利用することができる。また、トピックマップはセマンティックWebを可能とする技術でもある。

(注：この章では、各技術の提案者がこれができると主張していることをそのまま書いている。実際にできるかどうか私が検証しているわけではない。)

RDF (Resource Description Framework)[RDF]は、W3C(WWW Consortium)のセマンティックWeb活動の一部として開発された。RDFはPICSのコンテンツ記述技術[PICS] (これもW3C技術))の拡張として始まった。初期の頃は、マイクロソフトとNetscapeからの提案に影響を受けてかなり発展した。RDFの最初のワーキングドラフトは1997年10月に発表され、そして1999年2月にW3C勧告になった。RDFはティム・バーナーズ・リーによるセマンティックWebのビジョンを実現するための一部の技術である。情報管理技術として、RDFには、多くの応用分野が考えられる。セマンティックWebにおける利用が主であるが、さらにコンテンツ管理技術、ナレッジマネジメント、ポータル構築技術、さらに電子商取引にも適用可能である。

DAML(DARPA Agent Markup Language)は2000年8月にDARPA（米政府の研究組織）により開始した研究プロジェクトの一部として、大きな研究チームによって開発されている。DAMLは標準化団体により規定されてはいないが、DAMLプログラムで運営されているdaml.orgから公開されている。DAMLは、セマンティックWebをサポートすることに注力しているように見えるが、他の用途も考えられるだろう。DAMLはOILと似ているため、findability問題の解決や、電子商取引、KMでも利用できるだろう。

OIL(Ontology Inference Layer)は、EUのIST (Information Society Technologies)プログラムのある研究プロジェクトから資金を供給されて作られた(訳注: On-To-Knowledge プロジェクト)。これらのプロジェクトの関係者により研究成果としての言語仕様も発表されている。OILは明らかにセマンティックWebのための技術である。また、OIL FAQによると、OILはfindability問題の解決、電子商取引のサポート、KMを可能にする技術という位置づけである。

これらの技術の利用分野を比較したものが以下の表になる。

分野	TM	RDF	DAML	OIL
Findability	Yes	Yes	Yes	Yes
ポータル	Yes	Yes	Yes	Yes
コンテンツマネジメント	Yes	Yes	Yes	Yes
EAI	Yes
E-commerce	Yes	Yes	Yes	Yes
KM	Yes	Yes	Yes	Yes
セマンティックWeb	Yes	Yes	Yes	Yes

こう比べてみると、各技術の提案者が示している応用分野は似たりよったりであることは、明確である。唯一の違いとして、RDF、DAML、OILにはEAI分野は入っていない。しかし、これは、EAIの目的にそれらが使用できないということではない。要するに、これらの分野の応用で情報のやり取りをする際に、自分がある規格を選んでも、相手先は別の規格を選ぶかもしれない。しかし、これは以下に示すように必ずしも問題になるわけでもない。

1.2.　解決すべき課題

解決すべき課題はこれらの4つの標準規格を相互流通させることである。最も低レベルでは、これらのデータをシステム間でやりとりさせることである。より望ましい目標は、異なった標準規格を同じプロダクションシステムで動かすソフトウェアを実装することである。たとえば、一つのモデルで定義されたクエリ言語やスキーマ言語で、他モデルのデータも扱えるようになればよい。本論文では、複数の表現によるデータ交換について主に扱い、どう統合するソフトウェアを実装するかについては深くは述べない。例えば、アプリAでトピックマップによる機能Xが提供され、アプリBではRDFにより機能Xが提供されるかもしれない。解決すべき課題はAがBのデータを使用したり、その逆ができたりすることである。

異なる表現間でデータを対応づける手法を考える前に、こういった手法の評価基準を考えておこう。以下が、その基準である。

· その手法には、モデルを変更することが必要か?
他モデルとの間でマッピングをよりうまく行なうために、モデルの一部を変更することは考えられるだろう。少しの変更で、変換結果が非常に良くなるような手法は極めて有用な可能性がある。しかし、そうした変更は非常に慎重に行われる必要があり、変換結果の改善度も非常に高いものでなければならない。

· 手法は完全か?
元データを相手データに変換したら、逆変換もでき、さらに元のデータと論理的に同等に戻るならば、基準を満たしている。
この評価基準は最も重要な評価基準であるが、それは絶対でない。変換に失敗するデータ種類が極めて少なければ、他の基準をうまく満たす手法でも良いかもしれない。

· 手法を適用するのにどのくらいの努力が必要か?
実装された汎用ソフトウェアと元データから、特定の1組のアプリケーションAとBの間で必要な結果を得るアプリを作るのにどのくらいの努力が必要だろうか？ これは手法の利用者の工数がどのくらいかかるかが決まるので、この基準は非常に重要である。利用者が面倒な手法はユーザコミュニティに受け入れられないというリスクがある。

· 手法の実装にはどのくらい努力が必要か。実装が難し過ぎる手法は、現実の実装の数も少なくなるので、この評価基準は重要である。

一般に、1つの表現を別の表現に変換するには、二種類の手法がある。一つは、スキーマ独立(モデルベース)の方法、もう一つは、スキーマベースの方法である。モデルベースの手法では、ある表現のモデルを直接他方のモデルに変換するか、一方で他方のモデルをモデル化してもよい。こうすることで、後は何もしなくても、あるモデルのすべてのデータを他方のデータに自動的に変換できる。スキーマベースの方法では、スキーマ毎に別々に変換を開発しなければならない。しかし、一旦作ってしまえば、変換作業は自動である。

これら２つの手法を比較すると、スキーマベースではセットアップの苦労が必要なのに対し、モデルベースではそれが不用という利点がある。しかし、モデルベースには、変換された相手フォーマットのデータが、しばしば望ましい形式になっておらず後処理で手直しが必要という欠点もある。完全性という点では、どちらの手法も満たしているが、一般に、モデルベースのマッピングは実装がより容易である。要するに、どちらの変換手法が他方よりすぐれているということはない。個々の案件で、どれが適切かを調べなければならない。

1.3.　どう変換手法を実装するか

モデル間のデータ変換の実装には2つの一般的な手法がある:

· 静的マッピング:
本質的には変換かエクスポートである。ソースモデルによる1セットのデータから、ターゲットモデルに変換されたデータを作成し、 シリアルまたは永続ストレージにしまう。

· ダイナミックマッピング
より洗練されており、元のモデルによるデータを、それらがあたかもターゲットモデルで格納されているかのようにダイナミックに見ることができるAPIを提示する。元データへのどんなアップデートもマッピングインタフェースを通して即座に反映される。

これらの手法のどちらが良いかは、それぞれのアプリの要求次第である。静的マッピングは実行するのが断然簡単である。しかし、ダイナミックマッピングは状況次第では実装に値する。また、ダイナミックマッピングはソフトウェア統合を行なうには必要である。一般に、2つのデータモデルの間のマッピングの形式は、その実装とは独立である。しかし、データモデルの中には、ダイナミックマッピングを実装するのは難しいものもあるかもしれない。

2.モデルの比較

特定のマッピング手法を説明する前に、異なったモデルを比較し、それらの間の関係を説明しよう。

2.1.'Things' （「もの」）

RDFとトピックマップは、どちらも「もの」についての言明を行うことが基本である。「もの」とは、人　'Lars Marius Garshol'　や　会社'Ontopia'　のようなものである。
トピックマップでは、それらは「トピック」、RDFでは「リソース」として扱われる。これらの構造は本質的には同じで、「もの」を明確に表す何らかのデジタルシンボルを使用する。

RDFでは、各リソースは一つのURI(Universal Resource Identifier)によって表される。ドキュメントやファイルについて述べたRDFモデルでは、URIはドキュメントかファイルを指し示す。抽象的なものについて述べたRDFモデルでは、URIはそのリソースを示すシンボリックな識別子である。

トピックマップでは、トピックが表す実世界のものは「主題 (サブジェクト)」と呼ばれる。トピックは主題を特定する色々な方法がある。例えば、トピックの主題であるリソースをURIで特定する方法である。これはちょうどドキュメントやファイルを表すRDFリソースに対応している。また、トピックは「主題指示子(subject indicator)」であっても良い。これはそのトピックがどのような主題であるかを(人に)示すリソースをさすURLに相当する。これはちょうど抽象概念を表すRDFリソースに対応している。 [この議論は十分でない: URIsの解釈はこれより複雑である]

RDFかトピックマップかに関わらず、URIで３種類のものを指すことがある。
mailto: larsga@ontopia.net は' Lars Marius Garshol'というリソースのURIというのは良いだろう。
トピックマップでは、これは主題アドレスではなく、主題指示子になる。
http://www.ontopia.net はOntopia社のURIで、トピックマップでは、それは主題指示子である。http://www.ontopia.net/topicmaps/materials/tmrdfoildaml.html は本論文のURIだが、トピックマップでは、これは主題アドレスである。

以下に、これらの3つのものをRDFとトピックマップで並べて比較してみる。

3つのもの

これでわかるように、トピックマップとRDFでは主要な概念はほぼ同じだが、わずかに扱いが異なっている。RDFモデルには、リソースが抽象的であるか、または具体的であるかについて、アプリケーションに依存せずに区別する方法はない。トピックマップでは、主題アドレスであるか、主題指示子であるかによって区別ができる。

これらのモデルとXMLを比較すると、大きな違いはXMLには「もの」の概念がないということである。XMLでは、各要素は必ず実世界「もの」を表すということはなく、その「もの」の特定するのを宣言する手続きもない。このような理由で、残りの章ではXMLには言及しない。こうした「もの」についての議論が主になり、XMLではそうした「もの」は表現できないからである。

2.2.　関係

「もの」を含む世界のモデルを作るのは、しばしば、そうした「もの」について何かを言いたいからである。その場合、そうした言明は主として、そうした「もの」達が互いにどのような関係があるかということである。RDFとトピックマップではどちらもそうしたことが可能である。しかし、そのメカニズムは全く異なる。

RDFでは、ステートメントによって、リソースにプロパティを割り当てることができる。ステートメントは3つ組: （1）プロパティが割り当てられるリソース、(2)プロパティタイプ(URIによって表される)、(3) プロパティの値またはURIである。プロパティの値にURLを使うことで、このステートメントでものの間の関係が表現できる。

例えば、私がOntopia社に雇われていることは、次のような簡単なRDFステートメントで表現できる。
(mailto:larsga@ontopia.net, employed-by, http://www.ontopia.net.).

トピックマップでは、「関連(アソシエーション)」によって、ものの間の関係を表現することができる。関連はRDFステートメントのように型(タイプ)があり、タイプ自身がまたトピックである。一つの関連には何個のトピックが入っていてもよく、それは関連における役割のタイプ(これ自身がトピック)で定義される。私とOntopia社との関係は、employed-byというタイプの関連で表され、私はemployeeでOntopia社はemployerという役割をはたす。以下の図は、トピックマップにおける関連をグラフィカルに表現したものである。

トピックマップにおける関係づけ

同じ関係をRDFによって表現すると次のような図になる。明らかに簡単にはなっているが、こちらは拡張が難しく、スキーマについて知らないソフトウェアにとってこれらが関係であることは明白ではない。

RDFでの同じ関係づけ

RDFとトピックマップには、関係の表現で３つの主要な違いがある:

· 最も明らかなのは、表現の構造の違いである。RDFは一つのものと別のもの２つを関連づけるが、トピックマップはいくつものものを関係づけることができ、それらがどういう関係にあるかをも記述できる。RDFで同様のことも可能だが、概念的にも実装的にも外付けである。

· もう一つの違いは、トピックマップでは、関係が最初から双方向であるということである。
すなわち、「私がOntopia社で働いている」というと「Ontopia社が私を雇っている」を同時に表現できるということである。RDFで関係を逆に辿るのは可能だし、逆関係を記述することもできる。しかし、関係自体がそうなっているわけではない。

· 3つめの、やや微妙な違いは、RDFステートメントでは、２つの抽象的なものの間の関係を述べているのか、一つが具体的なリソースで他方が抽象的なリソースの関係を述べているのか、区別がないことである。また、ものの属性を述べるステートメントもあるが、それはURIの代わりに文字列が入っていることでしか区別できない。

要するに、トピックマップでは、何が関係であって、何がそうでないか、そして、すべての関係が双方向であり、複雑な関係を表すのがより簡単である。

2.3.属性

情報のモデル化する際には、モデル化されたものに属性を付与できることが望ましい。属性はものに付随した情報の一部であり単独に存在するわけではない。
例えば、'Lars Marius Garshol'というものの属性として　my name, my home page, and my birth date　を考えよう。
RDFでは、これらは、'Lars Marius　Garshol'というリソースのプロパティとして、次のような3つ組みステートメントでエンコードされる。
(mailto:larsga@ontopia.net, name, "Lars Marius Garshol"),
(mailto:larsga@ontopia.net, homepage, http://www.garshol.priv.no),
(mailto:larsga@ontopia.net, birthdate, "1973-12-25").

以下の図はこれらを表現している。他に情報がなければ、名前、メタデータ、およびリソースの割り当てを区別するのが難しいことに注意されたい。

RDFの3つの属性

トピックマップでは、これは全く異なる。トピックマップには、「出現(occurrence)」の概念がある。出現はトピックに関連した情報の断片のことである。出現はトピックマップへの外部のリソース(その場合リソースのURI)か、トピックマップ内部の文字列のいずれかである。出現には型が付いており、型はトピックである。

私のホームページを表す自然な方法は、私が「ホームページ」タイプの出現を持ち、" http://www.garshol.priv.no "にURIを設定することだろう。私の生年月日は、私の「生年月日」タイプの内部の出現になり、値が日付を表す文字列になる。しかし、私の名前というものは出現でない。トピックマップにはトピック名(特別な出現である)の概念があるので、私の名前は名前として表される。
ただし、残念ながら、筆者の記述力では、トピック、トピック名、および2種類の出現をダイアグラムで表現することはできない。

これは恐らくトピックマップとRDFの顕著な相違点である。ここでは３つの異なる属性のクラスについて別々に議論していこう。

· 「名前」はトピックマップとRDFの両方で表される。トピックマップでのみ、ソフトウェアがスキーマ知識なしでどのプロパティが名前であるかを判断できる。
その結果、どんなインタフェースでもトピックは名前で表現できる。一般のアプリケーションでは、これは非常に役に立つ。一方、RDFではしばしばスキーマ知識が必要となる。

· 「単純プロパティ」は、トピックマップとRDFで非常に似ている。あるものと別のものとの関係を文字列により与えることができる。

· 「ものに関連するリソース」については、RDFでは、ものに関連するリソースと、リソース間の関係を、同じステートメントによって表すため区別はない。トピックマップでは、関係が出現関係であれば、そのリソースはものに関してより情報を含んでいることがわかる。出現型(occurrence type)は、どういう情報がそこで見つかるかを示している。

トピックマップがRDFより高レベルであり、さらに明白なセマンティクスを含むことが再びわかった。このことは、既に標準化作業ですすめられているように、トピックマップに向けて汎用ソフトウェアを開発する方がより簡単で、トピックマップアプリケーションによる概念化の方が簡単であることを意味する。

2.4.　ものの種類

一般に、ものごとについて人が記録したいと思う情報は、それがどのような種類のものかということである。例えば、私は人であるとか、Ontopiaは会社である、といった情報である。これは非常に重要な情報なので、トピックマップとRDFのどちらにも標準的な表現手段がある。RDFでは、rdf:type という標準プロパティが、クラスとインスタンス間のinstance-of関係を表すのに使われる。

トピックマップでは、この情報はモデルの一部である。各トピックには、それをインスタンスに持つクラスの集合がある。そのため、直接情報を表現することができる。また、トピックマップはクラス-インスタンス関係のために標準で関連(association)タイプがある。一つの関連で、この関係を記述することができる。ただし、この関係はあまりに基本的であるので、ほとんどのトピックマップの実装ではトピックのプロパティとして表現している。

事実上、ここはトピックマップとRDFの共通領域である。Rdf:typeと、トピックマップのクラス-インスタンス関係は同じと思って良い。

2.5.　コンテクスト

ものの関係や属性に、そのコンテクスト情報を付与できると有益である。このコンテクスト情報は、「このプロパティはこれこれのコンテクストで有効である」とか、またはプロパティに関して役に立つメタデータかもしれない。RDFにはコンテクストのような概念はないが、匿名リソースを導入し、そのプロパティとしてコンテクスト情報をつけることで実現は可能である。ただし、この方法はやや苦しい。

トピックマップでは、「スコープ(有効範囲, scope)」でそのようなコンテクストを表せる。スコープは、コンテクストが妥当となるトピックの集合で与えられる。スコープは名前、出現、および関連に付与することができる。
この機能はかなり役に立つ場合がある。 例えば、色々な言語で情報を利用できる、多言語情報システムを作るにはどうすればよいだろう? RDFでは、たとえば、各言語ごとに概念の名前とプロパティを別々に定義することで扱うことができる。しかしこれは大変で、名前と定義の共通点もはっきりしなくなってしまう。さらに、色々なプロパティの違いがコンテクストの一つということもはっきりせず、スキーマの拡張も困難である。トピックマップでは、スコープの一つの軸として言語を使用することによって取り扱うことができる。名前にはスコープを付与できる。そして、プロパティ定義は出現型とすれば良い。

この部分におけるトピックマップとRDFの主な違いは、コンテクストはトピックマップで実現するのがはるかに簡単であるということである。実際、汎用トピックマップブラウザOntopia Omnigator [Omnigator]では、トピックマップで使用されるスコープを解釈でき、ユーザがコンテクストを設定することで表示されるトピックマップをフィルタリングできる。[Pepper01]は、トピックマップのスコープについて詳細なディスカッションをしており、アプリケーションを作る上で参考になる。

2.6.　具体化 (Reification)

具体化は人工知能における技術である。この語は文字通り"thingification" (「もの」にすること)である。これは本質的には、何か言明しようとするオブジェクトを「もの」に変換し、それらに関して言明できるようにすることである。オブジェクトがものにならなければ、我々はそれらに関して何か述べることはできない。

例えば、名前"Ontopia"がギリシャ語に由来しているというステートメントはどう作ったらよいだろう？ トピックマップでは、トピック"Ontopia"は"Ontopia"という名前を持つ。しかし、この名前とギリシャ語を関連させることはできない。なぜならば関連はトピックとトピックを結びつけるためである。これを解決するには、それを表現するトピックを作り、そのトピックをギリシャ語と関連させることで解決する。

しかし、この解決法における唯一の問題は、ソフトウェアが、トピック"Ontopia's-name"が、トピック"Ontopia"　の名前であることを知ることができないことである。
それには、ID (XTM構文によれば可能)を名前に与えて、トピック"Ontopia's name"の主題指示子をこのIDを指すようにすればよい。これによって、ソフトウェアがこのトピックとトピック名との関係を知ることができる。

RDFには、似た具体化の概念はあるものの、やや違なる。ただし筆者はその違いを明らかにするほど詳しくはないので、詳細は省く。

2.7.　DAMLとOIL

RDFやトピックマップとは違い、DAMLはデータモデルでなく、それはRDFデータモデルに従って、データ記述に制約を与えるのに使用されるスキーマ言語である。別の言い方をすればDAMLはRDFスキーマ言語である。RDFには、RDFスキーマ[RDF-Schema]というスキーマ言語が既にあり、DAMLはその拡張である。ただし、DAMLはRDF構文を拡張しているので、通常のRDFパーサではDAMLファイルは解析できないことに注意されたい。
DAMLの価値は、RDFデータにさらなる意味を加えることができることにある。

トピックマップとRDFの主な違いは、トピックマップはそれ自身でセマンティクスに関するより詳しい情報を記述できることにある。そこで、DAMLは、RDFとトピックマップの間のギャップを埋める可能性がある。一般に、DAMLがRDFスキーマに加えたのは、プロパティが取る値に関する制約と、クラスがどのようなプロパティを取ることができるかである。加えて、汎用ソフトウェア構築に役立つ次のような機能も与えている。

· daml:samePropertyAs: 異なったスキーマによる2つのRDFプロパティが、事実上同じであることを表す。

· daml:inverseOf: 1つのRDFプロパティが、別のプロパティの逆関係であることを表す。これは、トピックマップによる双方向関係を表現するのに用いることができる。ただし、関係がバイナリでないとうまくいかない。

· daml:TransitiveProperty: プロパティが推移的であることを表す。推移的なプロパティの例は例えば'larger than'である。'larger than'が推移的であることを知っていれば、AがＢより大きく(larger than)、BがＣより大きければ(larger than)、AがCより大きい(larger than)という知識も得ることができる。

要するに、DAMLはRDFスキーマ言語を拡張して、少しセマンティクスを加えたものである。このセマンティックスは、推移的関係を除けば、トピックマップには既にあるものである。ただし、推移的関係程度はどのような推論エンジンにもある。

OILはまた、RDFスキーマの拡張であるという点においてDAMLと同様であり、これら2つの機能も良く似ている。ただしDAMLの最新のリリースがDAML+OILと呼ばれるにもかかわらず、両者は完全に同一ではない。OILの推進者は、OILがDAMLが持っていない性質や機能を持っていると主張するが、これらについては本論文の範囲外である。

トピックマップについては、開発中のもの([TMCL])を除き、スキーマ言語の標準化はない。DAMLによってRDFに加えられたセマンティクスの大部分は、トピックマップに既にある。２つの関連型(association type)や出現型が同一であるというのは、トピックマップをマージすることで行なわれる。逆関係は、すべての関係がトピックマップで双方向であるため必要ない。しかし、推移的関係は、トピックマップには無く、付け加えれば有用かもしれない。

2.8.　シリアライズモデル

読者の理解を助けるために、このセクションはトピックマップとRDFの別の構文を、これまででてきたモデルの例を使って示そう。以下は、LTM ([LTM1.1])による構文の例である。簡潔のために、トピックのタイプ記述は省いている。

LTMによるモデル
[lmg : person = "Lars Marius Garshol"
 @"mailto:larsga@ontopia.net"]
{lmg, homepage, "http://www.garshol.priv.no"}
{lmg, birthdate, "1973-12-25"}
 
[ontopia : company = "Ontopia"
 @"http://www.ontopia.net"]
 
employed-by([ontopia] : employer, [lmg] : employee) 

以下は、対応するRDF３つ組みである。

RDF3つ組によるモデル
{mailto:larsga@ontopia.net,
 http://psi.ontopia.net/example/employed-by,
 http://www.ontopia.net}
 
{mailto:larsga@ontopia.net,
 http://psi.ontopia.net/example/name,
 "Lars Marius Garshol"}
 
{mailto:larsga@ontopia.net,
 http://www.w3.org/1999/02/22-rdf-syntax-ns#type,
 file://lmg.ltm#person}
 
{http://www.ontopia.net,
 http://www.w3.org/1999/02/22-rdf-syntax-ns#type,
 file://lmg.ltm#company}
 
{mailto:larsga@ontopia.net,
 http://psi.ontopia.net/example/birthdate,
 "1973-25-12"}
 
{mailto:larsga@ontopia.net,
 http://psi.ontopia.net/example/homepage,
 http://www.garshol.priv.no}
 
{http://www.ontopia.net,
 http://psi.ontopia.net/example/name,
 "Ontopia"}

2.9.　概要

RDFとトピックマップには、これまで「もの」と呼んでいた共通の基本概念がある。RDFとトピックマップでは、こうしたものに対して特徴を割り当てる手段も違い、ものの特定方法も異なる。RDFステートメントでは (サブジェクト、プロパティ、オブジェクト)の3つ組が唯一の性質割り当ての手段であるのに対し、トピックマップでは、トピックは、名前、出現、と関連による関係性を持つことができる。

RDFでは、URIによってリソースを特定する。トピックマップでは、トピックは、トピックであるリソースを示すURIかもしれないし、トピックが何であるかを説明するリソースを示すいろいろなURIsであるかもしれない。RDFはトピックマップより本質的に低レベルの記述しかできず、RDFモデルはスキーマ情報がないと意味をもたず、例えばデータを人によってわかりやすく表現することもできない。しかし、トピックマップでは、より高い抽象レベルが記述できるため可能である。DAMLとOILはどちらもRDFをデータモデルとしている。RDF自体を発展させたわけではなく、セマンティクスの拡張もわずかである。そのため、これらについてはこれ以上考える必要はないだろう。

以下の表は、トピックマップとRDFの間の用語をできる限り対応させたものである。完全でもないし正確でもないが、これらの比較には役に立つかもしれない。
トピックマップの用語についてさらに知りたい人は[XTM1.0]の付録Bをご覧頂きたい。

トピックマップの用語	関係	RDFの用語
Topic map (トピックマップ)	Comparable to	RDF graph
Topic (トピック)	Comparable to	Resource
Subject (主題)	Comparable to	Resource
Resource (リソース)	Comparable to	Network-retrievable resource
Non-addressable subject (番地付け不可な主題)	Comparable to	Non-network-retrievable resource
Association (関連)	kind of	Statement
Occurrence (出現)	kind of	Statement
Name assignment (名前割り当て)	type of	Statement
Class of topics （トピックのクラス）	Comparable to	Class

3.　規格の統合

RDFとトピックマップの2つのモデルの関係がわかったので、どう2つの表現の間でデータを変換するかについて考えていこう。

3.1.　従来技術

可能な手法を考えるまえに、これまでどのようなアプローチがされてきたかを、以前に述べた判断基準をもとに考えてみよう。

3.1.1.　最初の試み

最初に発表されたRDFとトピックマップデータの統合のアプローチは [Moore01]であった。この論文はいろいろな試みをしているので一つ一つ見ていこう。

まず最初に行なったのは、RDFモデルをトピックマップにより表現することである。これは、RDFステートメントにおける、(サブジェクト、プロパティ、オブジェクト) の概念を表す主題指示子を定義するということで極めて簡単に行なっている。各RDFステートメントは、RDFステートメント型による関連になり、サブジェクト、プロパティ、オブジェクトはそれぞれこの主題識別子による役割となる。

これは、トピックマップでRDFを表す直接的な方法であるが、いくつかの問題は残っている。例えば、RDFリソースはおそらくトピックになるが、そのURIに関して何も言っていない。URIは主題アドレスかあるいは主題識別子なのか?　この対応づけは実用上大きな問題になる。ムーアによれば、トピックマップがRDFをモデル化できるほど柔軟かどうかはアカデミックな問題の領域を出ないということなので、私もこれ以上は述べない。

Mooreは次の手段として、RDFによりトピックマップをモデル化している。RDFのプロパティによって、様々なトピックマップの構成物を定義し、それによってトピックマップを表現している。1つの注目に値するアイディアは、例えば名前を匿名リソースとして表現し、スコープを付与できるようにしたことである。しかしこのモデルは、異型名(variant name)が扱えないとか、主題アドレスと主題識別子をどう区別するかを解決していないなどの点から不完全である。しかし、ムアーによれば、単にRDFでトピックマップが表せることを示しただけで、実用的な手法ではないようである。

Mooreは最後の方法として、RDFとトピックマップ間のモデルからモデルへのマッピングを提案して、これが本筋である。モデルからモデルへのマッピングとは、RDFモデルをトピックマップと、そしてトピックをリソースと同一視することである。これは一般的には妥当な考えで、本論文でも同じ手法を取る。RDFリソースのURIは主題識別子と同一視する。ただし、一部のRDFリソースのURLは主題アドレスに相当するということについては依然として問題ではある。

Mooreは、最後にRDFステートメントと、トピックマップにおける関連とを比較している。そして、プロパティが関連型になり、決まった定義済みトピックが関連における主題とオブジェクトの役割になれば、RDFステートメントは関連に相当すると言っている。本論文では既にRDFステートメントがトピックマップにおける関連以外にも多く対応するのを見てきているため、Mooreの方法はマッピングの第一歩にすぎない。

Mooreでは、さらにトピックマップモデルに「アーク」と「関連テンプレート」の概念を拡張する提案もしている。ただ論文ではいくらか不明瞭なことがあり、これがRDFステートメントと関連との対応づけに類した問題に影響するのかはよくわからない。

まとめると、Mooreの研究は注目に値し、多くの重要点を指摘しているが、決定版ではない。筆者は「最初の一歩」ととらえており、それは公平な見方であろう。

3.1.2.　2番目の試み

別の注目すべきアプローチは[Lacher01]に述べられている。ここでは、[PMTM4]によるトピックマップデータモデルに基づき、トピックマップデータをRDFデータに変換する手法を示している。実際には、この手法はRDFスキーマで直接[PMTM4]モデルを、対応するRDFステートメントにより表現している。著者も指摘しているが、この手法は完全に動作し双方向であるが、結果のRDFデータは非常に汚い。

[Lacher01]にはRDFに変換されたトピックマップの例がない。したがって、この手法を完全に評価するのは難しいが、この対応づけの以下に述べるような特徴は明白である。

· このマッピングにはRDFスキーマを用いている。RDFアプリケーションでは、変換後のデータを利用するには提示されたRDFスキーマを解釈するか、さらなる追加処理が必要である。

· このRDFスキーマにより変換されたトピックマップデータの表現は非常に汚い。そのため、例えば、トピックの基底名を検索する程度にしても、RDFモデルの自明ではない検索が必要である。

· RDFにおけるURIが、主題アドレスか主題識別子のどちらに相当するかの問題は扱わない。

まとめると、この方法は、RDFとトピックマップの変換だけを考え、結果のRDFが汚いためその後の処理は大変なため、不完全である。

3.1.3.　 3番目の試み

[Ogievitsky01]では、トピックマップデータとRDFとのマッピングについて、[Lacher01]と似たような方法をとっている。
[Ogievitsky01]は、 [PMTM4]に基づいているものの、[Lacher01]とは使用するRDFスキーマも含めて.いくつかの点で異なっている。

Ogievetskyの提案には次のような面白いアイディアがある。

· トピックに主題アドレスがある場合、それはそれを表すのに使用されるRDFリソースのURIとすればよい。トピックに主題アドレスがない場合、新たにIDを作りrdf:ID に割り当てれば良い。主題識別子はリソースのプロパティになる。これは、RDFにおいて'リソース'と'リソースを構成する主題'が意味的に同じか明確ではないものの、理にかなっている。アプリケーションによっては外付けで同様のことを行なっているものもあるだろう。

· トピックマップにおけるクラスインスタンス関係はrdf:typeで表現できる。これは明らかである。

· 関連はまたリソースになり、関連のメンバーであるトピックがプロパティになる。関連がリソースのプロパティを与えているため、やや逆向きに見えるかもしれない。

· 名前と出現は、そのトピックをプロパティとして持つリソースに相当する。そして、名前文字列、出現文字列、または出現リソースになる。これも、リソース名がリソースのプロパティなので、逆向きに見える。

· スコープは、トピックを表すリソースプロパティになる。これは妥当である。

つまり、Ogievetskyの提案は、トピックマップからRDFへの変換だけを考え、結果のRDFもやはり汚いため不完全と言える。ただし、トピックマップをRDFにマッピングする処理は比較的完全である。

3.1.4.　まとめ

まとめると、RDFとトピックマップの統合における従来研究は不完全であり、トピックマップデータからRDFへのモデルベースのマッピングについての深い提案にすぎない。モデルの比較が不十分である。また、問題点が何かがあまり明らかにされず、RDFとトピックマップにおいて明らかに類似している構造と、明らかに類似していない構造とをほとんど分けずに議論を行っている。

3.2 RDFからトピックマップへ

前述のように、RDFモデルは3つ組からなる。RDFステートメントが対応する、トピックマップの構成要素を見てみよう。以下の表はRDFステートメントとトピックマップとの可能なマッピングを並べたものである。サブジェクト、プロパティ、およびオブジェクトがそれぞれトピックマップの何に相当するかを示す。

ステートメント	サブジェクト	プロパティ	オブジェクト
Association 関連	Role playing topic 役割を行なうトピック	Association type 関連型 (and role types) (および、役割型)	Role playing topic 役割を行なうトピック
Occurrence 出現	Topic トピック	Occurrence type 出現型 (and scope) (および、スコープ)	Resource リソース
Base name 基底名	Topic トピック	Scope スコープ	Base name value 基底名の値
Variant name 異形名	Topic トピック	Scope スコープ (and base name) (および、基底名)	Variant name value 異形名の値
Subject indicator 主題識別子	Topic トピック	URI prefix, if any もしあればURI接頭語	Subject indicator URI 主題識別子としてのURI
Instance of インスタンス	Topic トピック	Instance of association 関連のインスタンス	Topic トピック

これから明らかに、どんなRDFモデルでも動く、一般的なRDFからトピックマップへのマッピングは不可能ということがわかる。しかし、RDFスキーマの知識があれば適切なマッピングを作成することができる。これは、ステートメントは色々なものに対応しても、プロパティが対応するものは対応するものが一つなので可能になっている。

この点をより具体的にするため、例を使って示していこう。以下は http://www.semanticweb.org/library/ から得られるWordNetのRDFバージョンである。RDFによって辞書の情報が表現されている。この辞書は、概念を数値IDで表し、その語形や定義、下位概念へのリンク、類義概念へのリンクなどを表す。以下がWordNetにおけるある語についてのRDFステートメントのセットである。

WordNetステートメントの集合
1 : {http://www.cogsci.princeton.edu/~wn/concept#200399152,
  http://www.w3.org/1999/02/22-rdf-syntax-ns#type,
 http://www.cogsci.princeton.edu/~wn/schema/Verb}
 
2 : {http://www.cogsci.princeton.edu/~wn/concept#200399152,
 http://www.cogsci.princeton.edu/~wn/schema/wordForm,
  'understand'}
 
3 : {http://www.cogsci.princeton.edu/~wn/concept#200399152,
 http://www.cogsci.princeton.edu/~wn/schema/wordForm,
  'realize'}
 
4 : {http://www.cogsci.princeton.edu/~wn/concept#200399152,
 http://www.cogsci.princeton.edu/~wn/schema/wordForm,
  'see'}
 
5 : {http://www.cogsci.princeton.edu/~wn/concept#200399347,
 http://www.cogsci.princeton.edu/~wn/schema/hyponymOf,
 http://www.cogsci.princeton.edu/~wn/concept#200399152}
 
6 : {http://www.cogsci.princeton.edu/~wn/concept#200399152,
 http://www.cogsci.princeton.edu/~wn/schema/glossaryEntry,
  'perceive mentally, as of an idea; "Now I see!";
 "I just can\'t see your point"'} 

これらはID200399152という概念を表すRDFステートメントである。以下、それぞれの文の意味について説明しよう。

1. この文は、この概念がタイプ「Verb」タイプのインスタンスであることを表す;すなわち、それは動詞である。

2. この文は、この概念を示すのに使用することができる語が”understand”と言っている。

3. この文は、この概念を示すのに使用することができる語が”realize”と言っている。これは、同じ概念で”understand”と”realize”が同義語であることを意味する。(また、これらの単語が異なった概念を表すことも可能なことに注意)

4. この文は別の語形をあらわす: "see".

5. この文は、ID200399152による概念ががより下位概念であることを表す

6. 最後の文は概念のグロッサリーを与える。

RDFアプリケーションを理解したので、トピックマップへ変換する準備ができた。RDFのプロパティがわずか４つならば、これはそんなに困難ではない。以下、どのようにこうしたプロパティがトピックマップに変換されるか見ていこう。

· rdf:type:　この変換は簡単である。サブジェクトがあるオブジェクトのインスタンスであると述べているので、どちらも主題識別子で特定される。

· wordForm:　この述語も簡単。それは名前をサブジェクトに割当て、そのサブジェクトは主題識別子によって特定される

· hyponymOf:　この述語はサブジェクトとオブジェクトの”hyponym of(下位概念)”という関連を表す。サブジェクトが「特定のターム」の役割で、オブジェクトは「一般的なターム」の役割である

· glossaryEntry:　この述語はタイプ「glossary entry」タイプをサブジェクトに割り当てる。

以上で、WordNet RDFモデル全体をトピックマップに変える準備ができた。

RDFからトピックマップへのマッピングをあるXML構文で定義し、動作を実証するためにOntopia Topic Map Engineを使用して、Jythonにより実装を行なった。
マッピングファイルでは、各RDFプロパティの対応を、XTM 1.0構文をテンプレート化することにより記述した。マッピングファイルはXMLで作成する。以下はその例である。

WordNetのマッピングファイル

<rdf-to-tm>

 <property uri="http://www.w3.org/1999/02/22-rdf-syntax-ns#type">
 <instanceOf/>
 </property>
 
 <property uri="http://www.cogsci.princeton.edu/~wn/schema/wordForm">
 <baseName/>
 </property>
 
 <property uri="http://www.cogsci.princeton.edu/~wn/schema/glossaryEntry">
 <occurrence>
 <instanceOf>Glossary entry</instanceOf>
 <resourceData/>
 </occurrence>
 </property>
 
 <property uri="http://www.cogsci.princeton.edu/~wn/schema/hyponymOf">