セマンティックウェブとオントロジ技術は拡大を続けている

作者 Steven Robbins , 翻訳者 白石 俊平 投稿日 2008年5月18日

セクション

設計/アーキテクチャ,

エンタープライズ・アーキテクチャ

トピック

Semantic Web ,

エンタープライズアーキテクチャ ,

SOA ,

Architecture

タグ

XMLスキーマ ,

Best Practices ,

Enterprisey

オントロジとオントロジカル・マネジメントは、組織内にエンタープライズアーキテクチャが広がるに従って人気を得るようになってきた。ツールのサポートがより充実し、セマンティックとオントロジのコンセプトへの理解が進むにつれ、技術に寄与する人の数が増えてきた。AKSWグループは"Webの'セマンティフィケーション'を構築する部品"を提供するためのTriplifyと言う製品を最近リリース(サイト・英語)した。UMBELバックボーンプロジェクトは(source)、軽量なサブジェクト構造をWeb向けに提供するため始められた。Dan McCrearyは、エンタープライズのオントロジを開発、保守するなかでのいくつかの落とし穴(source)について語っている。


 The Agile Knowledge and Semantic Web research group(source)（AKSQ）は、Triplifyの最新バージョン(サイト・英語)を最近リリースした。TriplifyはWebアプリケーションに対する小さなプラグインで、リレーショナルデータベースの内容をRDF、JSON、もしくはリンクしたデータとして利用可能にすることで、データベース内にエンコードされている意味的な構造を明らかにする。このプラグインを使用し、アプリケーションのクエリによってカラムを順序づけることで、Triplifyはアプリケーションのクエリが返すデータを分析し、先に述べたフォーマットでそれらを利用可能にする。これにより、巨大なセマンティック定義を作成、保持するための多大な努力をすることなしに、中小規模のWebアプリケーションがセマンティックウェブに参加することが容易になる。Triplifyのアプローチにおける最終的なゴールは次のような物である - "Webアプリケーションの裏にある構造化されたリレーショナル表現を利用して、Web上に巨大な意味的表現を作成する"

The Upper Mapping and Bind Exchange Layer (UMBEL)プロジェクトは、自身のことを"サブジェクト・コンセプトの標準的なセットを通じ、Webデータとデータセットをお互い関連づけるための軽量のオントロジ"であるとしている。UMBELは"サブジェクト・コンセプト"を以下のように定義している。

SKOSやRDFSなどで使用されている統制語彙や形式概念分析、いくつかの上位オントロジに共通する一般的なコンセプトなど、より広く知られているコンセプトとは異なるサブセットです。サブジェクト・コンセプトは、特別な種類のコンセプトです: 具象的で、サブジェクトに関連したものであり、抽象的ではありません。さらにこれらを名前付きエンティティと対比してみると、名前付きエンティティは、サブジェクト・コンセプトのクラスにメンバとして属する世界における、実際のものやインスタンスです。

プロジェクトの主な目的は、非常に多くの粒度が細かいローカルなオントロジーと、概念の組み合わせにおける関連の"メタマップ"を提供する手助けをすることである。Michael K. Bergman(source)は、Webにおけるサブジェクトの骨組みがどのように見えるか(source)を示すだけではなく、スライドショー(source)でUMBELのオンラインデモを見せたり、プロジェクトが手始めに作成した11個のセマンティックウェブサービス(source) を公開している。

最後に述べるのは、エンタープライズ・オントロジを定義するにあたって注意すべきいくつかの事柄(source)についての、Dan McCrearyの意見である。オントロジを定義しようとする企業が、主につまづきやすい部分をいくつか尋ねられると、Danは"オントロジ"と言う単語自体が大きな障害である、と答えた。

それ（オントロジと言う単語）はあまりにも威圧的です。あまりに多くの人々のやる気を失わせます。彼らは、AIの研究に金を投じていると考えてします。いつか、私たちはよりフレンドリな名前を付ける必要があります。単にそれをメタデータレジストリと呼べば、より採用され易いことでしょう。データベース開発者と仕事をしている多くの人々は、それを単に論理的なデータモデル、もしくはエンタープライズデータディクショナリと呼ぶのが落ちです。XMLを好む人は、それをXML Schemaタイプのライブラリだと呼びたがるでしょう。どんな人々でも構いません...彼らが快適だと思う用語をつけ、組織の弱点にフォーカスするべきなのです。私は、顧客のだいたい25%にしか、私がオントロジを構築しているとは伝えていません。

組織がオントロジの定義と保守を一度始めたら、管理され、エンタープライズ全体で利用する必要がある。Danが言うには、それは単に企業におけるハイレベルな努力と言うだけではなく、組織全体へと拡大する必要がある。

上位のオントロジは、それ自体ではほとんど利用価値がありません。それら自体は、現実的なビジネス上の問題を解決しないのです。それがビジネス上の問題を解決するのは、末節のレベルに達し、データベースのカラムへのマッピングを開始できたときだけです。それこそがまさしく肝心な部分です。

組織内でオントロジの採用が始まったら、McCrearyが挙げた10個の落とし穴(source)に注意すべきである。

1. オントロジをデザインするために作られたツールを使いましょう
2.  データ要素の重複を避けましょう
3.  オントロジ内におけるオブジェクトの役割を混同させないようにしましょう
4. 意味の定義と、制約の定義はプロセスを分けましょう。
5. 上位のオントロジを徹底的にテストしましょう
6. データ要素に一義的な定義を作成しましょう
7. 要素の定義と、それらの説明を混同しないようにしましょう
8. 複雑な全文検索を許容する、検索し易い構造を作成しましょう
9. 定義のバージョニングとトレーサビリティを実践しましょう
10. エンタープライズコード/識別子オブジェクトにも同様に意味を定義しましょう

オントロジを持つ組織内に、意味の正確さに対して責任を持つ個人やチームを抱えることの重要性についても、McCrearyは強調した。エンタープライズにとって、オントロジの価値は非常に重要であり、そうした個人やチームがリーダーとしての役割を演じるべきだとしている。

原文はこちらです：     http://www.infoq.com/news/2008/04/semantic-and-ontological

• 次へ >