トピックマップ、RDFDAMLOIL

A comparison

By:

Lars Marius Garshol

所属

Ontopia

Email:

larsga@ontopia.net

Web:

http://www.ontopia.net/

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

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

Ontopia

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

要約

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

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

著者紹介

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

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

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で3種類のものを指すことがある。
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とトピックマップには、関係の表現で3つの主要な違いがある:

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

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

·         3つめの、やや微妙な違いは、RDFステートメントでは、2つの抽象的なものの間の関係を述べているのか、一つが具体的なリソースで他方が抽象的なリソースの関係を述べているのか、区別がないことである。また、ものの属性を述べるステートメントもあるが、それは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の顕著な相違点である。ここでは3つの異なる属性のクラスについて別々に議論していこう。

·         「名前」はトピックマップと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. DAMLOIL

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がBより大きく(larger than)、BがCより大きければ(larger than)、AがCより大きい(larger than)という知識も得ることができる。

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

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

トピックマップについては、開発中のもの([TMCL])を除き、スキーマ言語の標準化はない。DAMLによってRDFに加えられたセマンティクスの大部分は、トピックマップに既にある。2つの関連型(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) 

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

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のプロパティがわずか4つならば、これはそんなに困難ではない。以下、どのようにこうしたプロパティがトピックマップに変換されるか見ていこう。

 

·         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">
    <association>
      <instanceOf>Hyponym of</instanceOf>
 
      <member>
        <roleSpec>Specific term</roleSpec>
        <subject/>
      </member>
 
      <member>
        <roleSpec>General term</roleSpec>
        <object/>
      </member>
    </association>
  </property>
 
</rdf-to-tm> 

 

マッピングファイルの中のproperty要素により、RDFプロパティをトピックマップのどの構造に変換するかを定義する。マッピングファイルで定義されていなければ、対象リソースのURIは常にトピックの主題識別子になる (この例には出てこない)。また、ここに書いてある以上に、テンプレートは豊富な記述が可能である。
例えば、マッピングファイルの中で基底名、出現、および関連のスコープが指定できる。

このマッピングファイルと、WordNetのRDFによる記述を、RDF-to-topicmapマッパプログラムに与えると、以下のようなトピックマップ (LTM構文[LTM1.1]による)が得られる。分量が多くなり、読みづらいのでこの例ではXTM構文は使っていない。


The result of the mapping
マッピングの結果

[understand : verb = "realize"
                   = "understand"
                   = "see"
 @"http://www.cogsci.princeton.edu/~wn/concept#200399152"]
 
{understand, glossary, [[perceive mentally, as of an idea; "Now I see!";
"I just can't see your point"]]}
 
hyponym-of([understand] : general, [perceive] : specific) 

 

このトピックマップには、1つのトピック”understand”が、動詞タイプで、3つの基底名と一つの主題識別子により表されている。 (角括弧で囲まれている)
このトピックは、glossary型の出現を持ち、テキストにより値が与えられている。最後の行は関連を表し、hyponym-of(下位概念)型である。このトピックが一般的な概念で、perceiveがより特定の概念ということを示している。

 

この変換手法は、設定したり使ったりするの簡単で、質的に同等なトピックマップを得られる。また、既存のトピックマップエンジンとRDFパーサがあれば、実装するのも簡単である。Jythonを使うと、わずか300行で実装できる(スペースの都合で、ソースコードは掲載しない)。
 

この方法には、いくつか問題がある。最も大きなものは、間接的なRDFプロパティ割り当てが扱えないことである。すなわち、匿名のリソースを使用することによる指定ができない。これはRDFでコレクションを使用したり、プロパティ割り当てを具体化しようとすると必要になる。2番目の問題点は、RDFのプロパティの変換定義が一つだけであることである。例えば、主題のタイプや、具体化によりプロパティで与えられた値(例えばスコープ)により、複数の変換の方法を変えるということができない。

 

筆者は、RDFの専門家でないため、実際にこうしたことが問題となる実例は示すことはできない。たぶん、これらの問題を扱うには、マッピングファイルで何らかのRDFクエリ言語により検索を行い、入力データの変換を行なうことになるだろう。今後、この方向の研究も行なう予定である。

3.3. モデルベースのトピックマップからRDFのマッピング

トピックマップからRDFまでのマッピングの1つの方法がRDFスキーマを使ってトピックマップのモデルを定義し、トピックマップをRDF形式への変換を実装するというものである。これは[Lacher01]と[Ogievitsky01]によって既に行なわれている。前述のように、これらの方法は、結果のRDFデータが汚いため使用するのが難しいというのが問題だった。

 

 [Garshol01a]では、トピックマップの抽象モデルを定義するのに、W3CのXML Information Set([Cowan01])で最初に採用されたinfosetモデルアプローチをとっている。このモデルはかなり直接的であり、また使用するRDFスキーマは既存の研究よりはかなり使いやすいものである。以下は、そのスキーマの抜粋である。

 

infosetモデルのためのRDFスキーマ

<!-- EXCERPT ONLY! -->
 
<!-- =========================================================================
  TOPIC MAP OBJECT
========================================================================== -->
 
<rdfs:Class ID="TopicMapObject
  <rdfs:comment>The class of all objects that may be found in topic
  maps.</rdfs:comment>
</rdfs:Class>
 
<rdfs:Property ID="source-locators">
  <rdfs:domain resource="#TopicMapObject"/>
  <rdfs:range resource="#LocatorSet"/>
</rdfs:Property>
 
 
<!-- =========================================================================
  TOPIC MAP
========================================================================== -->
 
<rdfs:Class ID="TopicMap">
  <rdfs:comment>The class of topic maps.</rdfs:comment>
  <rdfs:subClassOf resource="#TopicMapObject"/>
</rdfs:Class>
 
<rdfs:Property ID="base-locator">
  <rdfs:domain resource="#TopicMap"/>
  <rdfs:range resource="#Locator"/>
</rdfs:Property>
 
<rdfs:Property ID="topics">
  <rdfs:domain resource="#TopicMap"/>
  <rdfs:range resource="#TopicSet"/>
</rdfs:Property>
 
<rdfs:Property ID="associations">
  <rdfs:domain resource="#TopicMap"/>
  <rdfs:range resource="#AssociationSet"/>
</rdfs:Property>
 
 
<!-- =========================================================================
  TOPIC
========================================================================== -->
 
<rdfs:Class ID="TopicMap">
  <rdfs:comment>The class of topics.</rdfs:comment>
  <rdfs:subClassOf resource="#TopicMapObject"/>
</rdfs:Class>
 
<rdfs:Property ID="classes">
  <rdfs:domain resource="#Topic"/>
  <rdfs:range resource="#TopicSet"/>
</rdfs:Property>
 
<rdfs:Property ID="basenames">
  <rdfs:domain resource="#Topic"/>
  <rdfs:range resource="#BaseNameSet"/>
</rdfs:Property> 

 

トピックマップからこのスキーマへのマッピングは、直接的なので実装はかなり簡単だろう。RDFリソースのURIは、[source locator]のURIのどれかになる。また、ソースロケータのないものはIDを自動生成する。以下はあるトピックマップの例を与えて、変換されたRDFモデルである。

RDFによるトピックマップの例

<rdf:RDF xml:lang="en"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns="http://psi.ontopia.net/infoset#">
 
<TopicMap rdf:about="#id0"/>
 
<Topic rdf:about="#lmg">
  <baseName>
    <BaseName rdf:about="#id1">
      <value>Lars Marius Garshol</value>
    </BaseName>
  </baseName>
 
  <subjectIndicator rdf:resource="mailto:larsga@ontopia.net"/>
 
  <occurrence>
    <Occurrence rdf:about="#id2">
      <instanceOf rdf:resource="#homepage"/>
      <locator rdf:resource="http://www.garshol.priv.no"/>
    </Occurrence>
  </occurrence>
 
  <occurrence>
    <Occurrence rdf:about="#id3">
      <instanceOf rdf:resource="#birthdate"/>
      <value>1973-12-25</value>
    </Occurrence>
  </occurrence>
</Topic>
 
<Association rdf:about="#id4">
  <instanceOf rdf:resource="#employed-by"/>
 
  <role>
    <AssociationRole rdf:about="#id5">
      <instanceOf rdf:resource="#employee"/>
      <player rdf:resource="#lmg"/>
    </AssociationRole>
  </role>
 
  <role>
    <AssociationRole rdf:about="#id6">
      <instanceOf rdf:resource="#employer"/>
      <player rdf:resource="#ontopia"/>
    </AssociationRole>
  </role>
</Association>
 
</rdf:RDF> 

 

この例はかなり長く、構文もやや冗長であるが、基本原理は明らかである。この手法は[Lacher01]と[Ogievitsky01]で提案されたものより簡単であるが、結果として得られるRDFはRDFアプリケーションで直接使えるくらいきれいなものである。

 

この章の目的は、主としてinfosetモデルに基づいて[PMTM4]よりも直接にトピックマップの変換を与えることができることを示すことであった。目的が達成されたので次へ行こう。

3.4. トピックマップからRDFのマッピング--手法2

トピックマップからRDFへのマッピングの他のやり方は、RDFアプリケーションとしてトピックマップを実行することではなく、マッピング定義を行なうことでトピックマップデータをRDFに変換することである。RDFデータを作ることでより使いやすくなり、RDFアプリケーションではトピックマップについて何も知らなくても扱うことができる。

 

トピックマップからRDFへのスキーマベースのマッピングについて説明するのは、RDFからトピックマップへのマッピングよりはやや難しい。というのは主に、RDFではマッピングはプロパティに関するものだけだったのに対して、トピックマップではもう少し複雑だからである。マッピングを定義するには、トピックマップから特定の情報を簡単に抜き取ることができるような言語(クエリ言語かもしれない)が必要である。ISO TMQLの規格作業はまだ未完なので、今のところ選択肢はtolog[Garshol01b]である。 (本論分で使うtologのバージョンは、参照した論文のものよりは少しアップデートしてある。)

また、変換定義としてトピックマップデータからRDFステートメントを作り出す方法を記述するXMLファイルが必要である。以下はその例である。

トピックマップからRDFへの変換例

<tm-to-rdf>
  <generator> <!-- 1 -->
    <query>employed-by($A : employee, $B : employer)</query>
 
    <subject>$A</subject>
    <property>http://psi.ontopia.net/example/employed-by</property>
    <object>$B</object>
  </generator>
 
  <generator> <!-- 2 -->
    <query>instance-of($A, person), has-name($A, $B)</query>
 
    <subject>$A</subject>
    <property>http://psi.ontopia.net/example/name</property>
    <object>$B</object>
  </generator>
 
  <generator> <!-- 3 -->
    <query>instance-of($A, $B)</query>
 
    <subject>$A</subject>
    <property>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</property>
    <object>$B</object>
  </generator>
 
  <generator> <!-- 4 -->
    <query>has-occurrence($A, birthdate, $B)</query>
 
    <subject>$A</subject>
    <property>http://psi.ontopia.net/example/birthdate</property>
    <object>$B</object>
  </generator>
 
  <generator> <!-- 5 -->
    <query>has-occurrence($A, homepage, $B)</query>
 
    <subject>$A</subject>
    <property>http://psi.ontopia.net/example/homepage</property>
    <object>$B</object>
  </generator>
</tm-to-rdf> 

 

この例では、すべてのジェネレータの結果を一つのRDFモデルに併合することによって、結果のRDFモデルが作成される。各ジェネレータでは、まずクエリを実行して、その結果マッチしたものそれぞれについて、属性値を埋めることでステートメントのインスタンスを作っていくことにより、一連のRDFステートメントを生成する。変数や定数はステートメントの3つの要素のどこにでも現れることに注意されたい。

 

変数の参照は、変数で保持されるトピックの主題識別子の1つで置き換えられる。ステートメントテンプレートでuri属性を要素として使うことで、これを上書きし、代わりにソースロケータ([Garshol01a])、主題アドレス、または生成したオブジェクトIDを用いることもできる。基底名と出現は、それらの文字列としての値か、出現リソースのURIによって表される。
 

トピックマップの例から、以下のようなRDFモデルが結果として得られる。RDF3つ組の前の数字は、それを生成したgenerator文についている数字である。

トピックマップからRDF変換の結果

 

1 : {mailto:larsga@ontopia.net,
     http://psi.ontopia.net/example/employed-by,
     http://www.ontopia.net}
 
2 : {mailto:larsga@ontopia.net,
     http://psi.ontopia.net/example/name,
     "Lars Marius Garshol"}
 
3 : {mailto:larsga@ontopia.net,
     http://www.w3.org/1999/02/22-rdf-syntax-ns#type,
     file://lmg.ltm#person}
 
3 : {http://www.ontopia.net,
     http://www.w3.org/1999/02/22-rdf-syntax-ns#type,
     file://lmg.ltm#company}
 
4 : {mailto:larsga@ontopia.net,
     http://psi.ontopia.net/example/birthdate,
     "1973-25-12"}
 
5 : {mailto:larsga@ontopia.net,
     http://psi.ontopia.net/example/homepage,
     http://www.garshol.priv.no}

 

 この方法は、実行するのが(もちろんtologクエリプロセッサがあれば)簡単で、使うのも容易で、RDFアプリケーションが直接使え、またどのようなRDFスキーマとも整合するRDFデータを生成できる。その主な欠点は、複雑なRDFステートメントを作り出す機能が欠けていることであるが、これは将来のバージョンでは改善されるだろう。

4. 結論

本論文は、RDF、トピックマップ、DAML、およびOILのデータモデルと特徴を比較した。RDF、DAML、およびOILはデータモデルを共有したファミリー規格であり、トピックマップはそれらとは全く異なっていることがわかった。また、この2つのデータモデルでは、ほとんど同じ概念もあれば、根本的に異なる概念もあった。

 

モデルを比較することで、RDFからトピックマップへのスキーマ独立な変換は不可能であることを示した。なぜなら、トピックマップの方がより高いレベルで記述が可能だからである。一方、本論文では、RDFからトピックマップへのスキーマベースのマッピングの解決を提案し、RDFデータモデルの細かいところまですべてをサポートするというわけではないが、良い結果を出すことができた。また、この方法を拡張することで、今後そうした機能をサポートできることを指摘した。

 

我々は、トピックマップからRDFへのスキーマ独立なマッピング手法について、既存研究を調べ、それらが生成されるRDFデータの利用で問題があることを示した。それに対して、我々自身の手法も提案し、それが十分ではないものの、わずかに優れていることがわかった。この結論としては、スキーマ独立のマッピングは役に立つ場合もあるが、最も良い変換手法ではないということである。
 

我々は、トピックマップからRDFへのスキーマベースのマッピング方法を提案して、RDFデータモデルの全てをサポートはしないが、良い結果を出せることを示した。

本論文におけるさらに高次の結論としては、トピックマップとRDFの間で相互にデータ変換は可能であるが、スキーマベースのマッピングが必要であるということである。この2つのモデルは、本質的に異なった機能を持ち、抽象化の異なったレベルも違う。これらの違いがどの程度重要かに関する結論は、読者にゆだねよう。

 

本論文がトピックマップとRDFの関係の理解を助ける最初の一歩となることを願っている。XML Europe 2002における論文のあるパラグラフでは、「[Garshol01]で示した分析と手法は、有用であるが、不完全で…」という記述がある。少なくとも、これを改善する意味でも、さらなるステップが必要である。


謝辞

Thanks to Steve Pepper, for help on improving the prose presentation of the paper.
Thanks to Geir Ove GrA¸nmo, for corrections of some omissions throughout the paper.
Thanks to David Allsopp, for answering some of my questions on RDF and DAML.
Thanks to Nikita Ogievetsky, Martin Lacher, and Graham Moore for discussing their solutions with me.
Thanks to Aaron Swartz and Eric Miller for a very constructive discussion, which was, sadly, too close to the deadline (through the author's own fault) to have much as impact on the paper as it should have had.

 Bibliography

Cowan01

XML Information Set, John Cowan, W3C Proposed Recommendation. Available from http://www.w3.org/TR/xml-infoset/.

Garshol01a

A Topic Map Data Model: An Infoset-based Proposal, Lars Marius Garshol. Available from http://www.ontopia.net/topicmaps/materials/proc-model.html.

Garshol01b

tolog: A topic map query language, Lars Marius Garshol, XML Europe 2001, Berlin. Available from http://www.ontopia.net/topicmaps/materials/tolog.html.

ISO13250

ISO/IEC 13250:2000 Topic Maps, International Organization for Standardization, Geneva. Available from http://www.y12.doe.gov/sgml/sc34/document/0129.pdf.

Lacher01

On the integration of Topic Map data and RDF data, Martin Lacher and Stefan Decker, presented at Extreme Markup Languages 2001, Montréal, Canada. Available from http://www.semanticweb.org/SWWS/program/full/paper53.pdf.

LTM1.1

Linear Topic Available from http://www.ontopia.net/download/ltm.html.

Moore01

RDF and TopicMaps: An Exercise in Convergence, Graham Moore, presented at XML Europe 2001 in Berlin. Available from http://www.topicmaps.com/topicmapsrdf.pdf.

Omnigator

The Ontopia Omnigator, software from Ontopia AS in Oslo, Norway. Online demonstration at http://www.ontopia.net/omnigator/.

Ogievitsky01

XML Topic Maps through RDF glasses, Nikita Ogievetsky, presented at Extreme Markup Languages 2001, Montréal, Canada. Available from http://www.cogx.com/rdfglasses.html.

Pepper01

Towards a general theory of scope, Steve Pepper and Geir Ove Grønmo, Extreme Markup Languages 2001, Montréal, Canada. Available from http://www.ontopia.net/topicmaps/materials/scope.htm.

PICS

PICS 1.1 Rating Services and Rating Systems -- and Their Machine Readable Descriptions, Jim Miller, Paul Resnick, and David Singer, W3C Recommendation, 31 October 1996. Available from http://www.w3.org/TR/REC-PICS-services.

PMTM4

Topicmaps.net's Processing Model for XTM 1.0, version 1.0.2. Available from http://www.topicmaps.net/pmtm4.htm.

RDF

Resource Description Framework (RDF) Model and Syntax Specification, Ora Lassila and Ralph Swick, W3C Recommendation, 22 February 1999. Available from http://www.w3.org/TR/REC-rdf-syntax/.

RDF-Schema

Resource Description Framework (RDF) Schemas, Dan Brickly and R.V. Guha, W3C Candidate Recommendation, 3 March 2000. Available from http://www.w3.org/TR/rdf-schema/.

TMCL

Draft Requirements for TMCL, Steve Pepper, ISO SC34 N 226, 8 June 2001. Available from http://www.y12.doe.gov/sgml/sc34/document/0226.htm.

XTM1.0

XML Topic Maps (XTM) 1.0, Steve Pepper and Graham Moore (editors), TopicMaps.Org. Available from http://www.topicmaps.org/xtm/1.0/.

 

 

 

(訳者注)

トピックマップの用語については、主としてXTM1.0の日本語訳http://www.y-adagio.com/public/standards/tr_xtm/toc.htm における日本語訳を使用した。

(除く、スコープ)

番地付け可能な情報資源(addressable information resource)

番地付け可能な主題(addressable subject)

関連(association)

関連型(association type)

基底名(base name)

特質(characteristic)

無矛盾トピックマップ(consistent topic map)

メンバ(member)

併合(merging)

番地付け不可能な主題(non-addressable subject)

出現(occurrence)

出現型(occurrence type)

パラメタ(parameters)

処理済みトピックマップ(processed topic map)

処理要件(processing requirements)

PSI

公開主題指示子(published subject indicator)

具体化(reification)

資源(resource)

役割(role)

有効範囲(scope)

主題(subject)

主題指示子(subject indicator)

トピック(topic)

トピック特質(topic characteristic)

トピック特質割当て(topic characteristic assignment)

トピックマップ(topic map)

トピックマップ文書(topic map document)

トピックマップノード(topic map node)

トピック名(topic name)

トピック名前付け制約(topic naming constraint)

トピック出現(topic occurrence)

トピック型(topic type)

制約なしの有効範囲(unconstrained scope)

異形(variant)

異形名(variant name)

XTM文書(XTM document)