JP2004118722A - サービス情報提供装置、サービス情報提供方法及び記録媒体 - Google Patents
サービス情報提供装置、サービス情報提供方法及び記録媒体 Download PDFInfo
- Publication number
- JP2004118722A JP2004118722A JP2002283974A JP2002283974A JP2004118722A JP 2004118722 A JP2004118722 A JP 2004118722A JP 2002283974 A JP2002283974 A JP 2002283974A JP 2002283974 A JP2002283974 A JP 2002283974A JP 2004118722 A JP2004118722 A JP 2004118722A
- Authority
- JP
- Japan
- Prior art keywords
- service
- ontology
- similarity
- information
- output
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】プログラム言語に関わる情報項目の中に現れる用語に関しても、類義語の判断などオントロジー技術を適用するための仕組みを有するサービス情報提供装置を実現する。
【解決手段】ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、サービスの情報を提供するサービス情報提供装置は、サービス記述は、サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されている。
【選択図】 図４
【解決手段】ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、サービスの情報を提供するサービス情報提供装置は、サービス記述は、サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されている。
【選択図】 図４
Description
【０００１】
【発明の属する技術分野】
本発明は、サービス情報提供装置、サービス情報提供方法及び記録媒体に関し、特に、ネットワーク上に存在するサービスプログラムが提供するサービスの情報を提供するサービス情報提供装置、サービス情報提供方法及び記録媒体に関する。
【０００２】
【従来の技術】
従来より、インターネット上のいわゆるＷｅｂページを検索するための検索エンジンは、ドキュメントであるＷｅｂページ内の言葉をキーとして検索を行う。ドキュメントでありドキュメント自身が検索キーの言葉を有するＷｅｂページと違って、Ｗｅｂサービスは、実態はサービスを提供するサービスプログラムであるため、プログラム自身には検索のための情報は含まれていない。そのため、Ｗｅｂサービス登録時にプログラムの内容を説明するために情報項目、サービス名、サービスドメイン、入出力項目、入出力に対する各種制約、その他コメントなどを、Ｗｅｂサービスを提供している企業等が登録する。そして、検索エンジンは、その登録された情報項目等に対して、検索を行う。
【０００３】
その際、Ｗｅｂサービスを提供するプログラムの内容を説明する情報は、人間が話す言葉の特性とプログラム言語の特性の両方を併せ持つ。プログラム言語においては、誰が記述したプログラムを誰が解釈しても意味が異なることはなく、プログラムとその意味はほぼ一意に決まる。一方、人間の言葉は、異なる言葉が同じ意味を持つことが多い。例えば、Ｗｅｂサービスがどのような入力を必要とし、どのような結果を返す、すなわち出力するのかを示す入出力の型は、プログラミングの型定義の文法に従うのに対して、そこで使われる型の名前は人間が話す言葉で表現される。
【０００４】
そして、従来のＷｅｂサービス検索では、プログラムの名前やコメント等の、もともと人間の言葉で書かれた情報項目に関しては、オントロジー技術を利用して、類義語の判断が行なわれていた（例えば、非特許文献１及び２参照。）。
【０００５】
【非特許文献１】
カティア・シカラ、セス・ウイドフ、マチアス・クルシュ、ジャンジュオ・ル・ラークス（Ｋａｔｉａ Ｓｙｃａｒａ， Ｓｅｔｈ Ｗｉｄｏｆｆ， Ｍａｔｔｈｉａｓ Ｋｌｕｓｃｈ ａｎｄ Ｊｉａｎｇｕｏ Ｌｕ． ＬＡＲＫＳ）著、「サイバースペースにおける異種ソフトウエアエージェント間の動的マッチメイキング（Ｄｙｎａｍｉｃ Ｍａｔｃｈｍａｋｉｎｇ Ａｍｏｎｇ Ｈｅｔｅｒｏｇｅｎｅｏｕｓ Ｓｏｆｔｗａｒｅ Ａｇｅｎｔｓ ｉｎ Ｃｙｂｅｒｓｐａｃｅ．）、 自律型エージェントとマルチエージェントシステム（Ａｕｔｏｎｏｍｏｕｓ Ａｇｅｎｔｓ ａｎｄ Ｍｕｌｔｉ−Ａｇｅｎｔ Ｓｙｓｔｅｍｓ）、第５巻（Ｖｏｌ． ５）、Ｐ．１７３−２０３， ２００２
【０００６】
【非特許文献２】
日経インターネットテクノロジ、「サービスの検索条件を拡張」、２００２年５月号、ｐ．４６
【０００７】
【発明が解決しようとする課題】
しかし、従来のＷｅｂサービス検索では、プログラムの名前やコメント等の、もともと人間の言葉で書かれた情報項目に関しては、オントロジー技術を利用して、類義語の判断を行ない、Ｗｅｂサービス提供者の使用し登録した言葉の類義語の範囲まで検索していたが、入出力の型定義等のプログラム言語に係る情報項目に関しては、類似の判断をするものはなかった。
【０００８】
【課題を解決するための手段】
そこで、本発明は、プログラム言語に関わる情報項目の中に現れる用語に関しても、類義語の判断等を行うオントロジー技術を適用するための仕組みを有するサービス情報提供装置を提供することを目的とする。
【０００９】
本発明のサービス情報提供装置は、ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、前記サービスの情報を提供するサービス情報提供装置であって、前記サービス記述は、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されている。
【００１０】
本発明のサービス情報提供方法は、ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、前記サービスの情報を提供するサービス情報提供方法であって、前記サービス記述は、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されている。
【００１１】
本発明のコンピュータ読み取り可能な記録媒体は、ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述のデータを有して、前記サービス記述のデータは、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されているデータが記録されている。
【００１２】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
【００１３】
まず図１に基づき、本実施の形態に係わるシステムの構成を説明する。図１は、本実施の形態に係わるＷｅｂサービス検索システムの構成を示す構成図である。
【００１４】
１は、サービス情報提供装置としてのウエブサーバ装置（以下、ウエブサーバという）であり、２は、ユーザが操作するパーソナルコンピュータ（以下、ＰＣという）である。ウエブサーバ１及びＰＣ２はインターネット３に接続されている。図１において、ＰＣ２は、一つしか図示していないが、複数接続され、各ユーザが自己のＰＣ２からウエブサーバ１にアクセスすることによってＷｅｂサービス検索システムを利用することができる。ウエブサーバ１は、ウエブサービスマッチメイカ（ウエブサービス検索エンジン）である。ウエブサーバ１には、オントロジー辞書データをストアするメモリ装置５と、後述するＷｅｂサービスに関するサービス記述データをストアするメモリ装置６が接続されている。メモリ装置５にストアされたオントロジー辞書データは、ここでは、複数のオントロジー辞書のデータを含む。オントロジー辞書データは、ユーザ要求に含まれる述語、Ｗｅｂサービス等を記述するサービス記述に含まれる述語を関連付けて体系化したデータベースである。具体的には、各オントロジーでは、複数のノードがツリー形式で関連付けられ、各ノードにおいて述語が定義されている。
【００１５】
４は、Ｗｅｂサービス用プログラムを有するサービス提供装置である。４−１から４−ｎ（ｎは整数）からなるｎ台のサービス提供装置も、ウエブサーバ１および複数のＰＣ２と同様に、インターネット３上に分散して存在し、インターネット３に接続されている。
【００１６】
Ｗｅｂサービスは、インターネットを利用してアクセス可能なサービスプログラムであるアプリケーションプログラムである。（従って、以下、Ｗｅｂサービスは、アプリケーションプログラムともいう。）人間あるいはコンピュータプログラムであるユーザは、インターネットを介して、そのアプリケーションプログラムを呼び出すことによって、そのアプリケーションプログラムを実行し、実行結果を利用することができる。
【００１７】
サービス検索装置としてのウエブサーバ１は、後述するように、ユーザであるＰＣ２からのＷｅｂサービスの検索要求を受信すると、その要求を満たすＷｅｂサービスを検索し、検索結果としてサービス提供装置４のそのＷｅｂサービスに関する情報を、ＰＣ２へ送信する。Ｗｅｂサービスに関する情報としては、Ｗｅｂサービスの呼び出しに必要なパラメータ、Ｗｅｂサービスの機能のデータ等である。ＰＣ２からの要求は、人間がＰＣ２を操作してＰＣ２からウエブサーバ１へ送信されるか、あるいはＰＣ２において実行されるコンピュータプログラムによって生成されてウエブサーバ１へ送信される。
【００１８】
なお、以下は、アプリケーションプログラムが、インターネットを利用したＷｅｂサービスである例を用いて説明するが、インターネットでない通信回線を利用してアクセス可能なアプリケーションプログラムであってもよい。
【００１９】
ウエブサーバ１には、インターネット４上にどのようなＷｅｂサービスがあるかというＷｅｂサービスに関するサービス記述データが、メモリ装置６に含まれるレジストリというデータベースに予め登録されている。ユーザからの検索要求に基づいて、ウエブサーバ１は、その登録、すなわちストアされたサービス記述データを検索して、Ｗｅｂサービスに関する情報、例えばそのユーザが利用したいＷｅｂサービスの有無、その呼び出し方法等の情報の提供をユーザのＰＣ２へ送信する。
【００２０】
図２は、図１のウエブサーバ１のサービス検索機能部の構成を示す機能ブロック図である。サービス情報提供装置としてのウエブサーバ１は、サービス検索機能部１１を含む。サービス検索機能部１１は、入出力通信機能部１２と、サービス記述解析機能部１３と、サービス類似性判断機能部１４を有する。入出力通信機能部１２は、インターネット３を介してＰＣ２等とのデータ通信を行う処理部である。サービス記述解析機能部１３は、検索要求に含まれるサービス記述のデータを解析し、かつレジストリにストアされたＷｅｂサービスに関するサービス記述のデータの解析も実行する処理部である。サービス類似性判断機能部１４は、後述する各種プリチェックと、オントロジーを利用した類似性判断と、スコア処理を行なう。
【００２１】
図３は、図２のサービス記述解析機能部１２の構成を示す機能ブロック図である。サービス記述解析機能部１２は、サービス記述解析機能部２１と、入出力型情報解析機能部２２と、制約条件解析機能部２３と、事前事後条件解析機能部２４と、属性情報解析機能部２５と、オントロジー情報解析機能部２６と、オントロジー情報取得機能部２７と、オントロジー情報格納機能部２８と、内部形式変換機能部２９とを含む。
【００２２】
サービス記述解析機能部２１は、ユーザからの検索要求あるいはレジストリにストアされたＷｅｂサービスのサービス記述データを、入出力型情報、制約条件、事前事後条件及び属性情報に分けるための解析処理部である。サービス記述解析機能部２１で分けられた入出力型情報、制約条件、事前事後条件及び属性情報のデータは、それぞれ解析する入出力型情報解析機能部２２、制約条件解析機能部２３、事前事後条件解析機能部２４及び属性情報解析機能部２５に供給され、解析される。
【００２３】
入出力型情報解析機能部２２、制約条件解析機能部２３、事前事後条件解析機能部２４及び属性情報解析機能部２５において解析されたそれぞれの情報に含まれるオントロジーに関連する情報が、オントロジー情報解析機能部２６に供給され、オントロジー情報、すなわちツリーとノードのデータが抽出される。そして、オントロジー情報取得機能部２７は、オントロジー情報解析機能部２６において抽出されたオントロジー情報を、レジストリのオントロジー辞書データから取得する。オントロジー情報格納機能部２８は、オントロジー情報取得機能部２７において取得されたオントロジー情報を、メモリ上にストア、すなわちキャッシュする。内部形式変換機能部２９は、外部のオントロジーの表現を、レジストリに登録されたオントロジーの表現形式に変換する処理部である。従って、内部形式変換機能部２９は、既にストアされている内部のオントロジー情報については、内部形式に変換しない。
【００２４】
図４は、図２のサービス類似性判断機能部１４の構成を示す機能ブロック図である。サービス類似性判断機能部１４は、ネームスペースプリチェック機能部３１と、テキストプリチェック機能部３２と、引数プリチェック機能部３３と、制約数プリチェック機能部３４と、型類似性判断機能部３５と、制約条件類似性判断機能部３６と、事前事後条件類似性判断機能部３７と、属性類似性判断機能部３８と、スコア機能部３９と、オントロジー類似性判断機能部４０とを含む。図４の各部の処理内容は後述する。
【００２５】
図５は、型類似性判断機能部３５の機能を示す機能ブロック図である。型類似性判断機能部３５は、型定義情報再帰分解機能部４１と、プログラム言語依存型整合性判断機能部４２と、オントロジー類似性判断機能部４３とを含む。型定義情報再帰分解機能部４１は、型定義情報を再帰的に分解する処理を行なう処理部である。プログラム言語依存型整合性判断機能部４２は、型定義がオントロジーで指定されていない場合、すなわちプログラム言語に依存して定義された型の整合性を判断する処理を行う処理部である。オントロジー類似性判断機能部４３は、オントロジーで指定された型の類似性を判断する処理を行なう処理部である。従って、入出力の型の情報は、型類似性判断機能部３５において型の整合性と類似性が再帰的に実行されて判断される。
【００２６】
図６は、制約条件類似性判断機能部３６の機能を示す機能ブロック図である。制約条件類似性判断機能部３６は、制約条件定義再帰分解機能部５１と、論理的包摂関係判断機能部５２と、オントロジー類似性判断機能部５３とを含む。制約条件定義再帰分解機能部５１は、制約条件定義情報を再帰的に分解する処理を行なう処理部である。論理的包摂関係判断機能部５２は、制約条件の定義がオントロジーで指定されていない場合、すなわちプログラム言語に依存して定義された制約条件の包摂関係を判断する処理を行う処理部である。オントロジー類似性判断機能部５３は、オントロジーで指定された制約条件の類似性を判断する処理を行なう処理部である。従って、制約条件の情報は、制約条件類似性判断機能部３６において制約条件の包摂関係と類似性が再帰的に実行されて判断される。
【００２７】
まず、サービス記述の具体例について説明する。
【００２８】
図７は、あるＷｅｂサービスのサービス記述の例を示す図である。例えば、ネジを製造し販売している会社が、ユーザからの見積要求に対して、要求するネジの価格と納期をネットワーク上で回答するサービスを、サービス提供装置４−１によってＷｅｂサービスとして提供している場合の例が、示されている。そして、そのＷｅｂサービスを多くのユーザに利用して貰うために、その会社は、Ｗｅｂサービス検索装置であるウエブサーバ１のメモリ装置６のレジストリにそのＷｅｂサービスの内容を記述したデータ、すなわちサービス記述データを登録する。登録されたサービス記述の例を、図７は示している。なお、Ｗｅｂサービスの検索条件も図７に示すような記述と同様に記述され、ユーザから検索要求データとして生成されて、ウエブサーバ１へ送信される。
【００２９】
図７は、ネジの見積を行うＷｅｂサービスであって、入力としてネジのタイプと個数を与えると、価格と納期を出力する見積もりサービスのサービス記述の例を示している。図７に示されたサービス記述は、そのＷｅｂサービスに関する入力、出力、入力制約及び出力制約の項目に関してのサービス記述部である、入力記述部６１、出力記述部６２、入力制約記述部６３、出力制約記述部６４及び事前条件記述部６５を含む例である。なお、これらの以外の項目についての記述部を含んでいてもよい。なお、以下の例では、オントロジーは、ツリーとノードで指定されており、「オントロジーツリー名＃ノード名」という形式で記述されている。
【００３０】
図７において、「Ｐａｒｔｓ Ｑｕｏｔｉｎｇ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ：」は、Ｗｅｂサービスの名称を示している。入力記述部６１中の「ｓｃｒｅｗ＠｛Ｐａｒｔｓ＃Ｓｃｒｅｗ，Ｂｕｈｉｎ＃ｎｅｊｉ｝， ｎｕｍ＠Ｕｎｉｔ＃Ｄｏｚｅｎ」は、入力項目に関してオントロジーを記述、すなわち入力項目がオントロジーによって指定されていることを示す。具体的には、「ｓｃｒｅｗ（ネジ）」という入力項目は、ツリーである「Ｐａｒｔｓ」というオントロジー辞書の中の「Ｓｃｒｅｗ」のノードの型か、別なツリーである「Ｂｕｈｉｎ」というオントロジー辞書の中の「ｎｅｊｉ」のノードの型を使用することを示す。言い換えると、「ｓｃｒｅｗ（ネジ）」という入力項目のデータの型は、「Ｐａｒｔｓ」というオントロジー辞書の中の「Ｓｃｒｅｗ」のノードの型か、「Ｂｕｈｉｎ」というオントロジー辞書の中の「ｎｅｊｉ」のノードの型と同じである、ということが記述されている。すなわち、２つの引数が夫々別のオントロジーによって指定されている。
【００３１】
このように、１つのサービスに関する記述中の個々の変数等の要素に対して、別々のオントロジーツリーを指定できるようになっている。以下の出力記述部６２等においても同様である。
【００３２】
さらに、ここの例では、「ｓｃｒｅｗ＠｛Ｐａｒｔｓ＃Ｓｃｒｅｗ，Ｂｕｈｉｎ＃ｎｅｊｉ｝」のように、１要素「ｓｃｒｅｗ」に対して複数のオントロジー指定ができることを意味しており、参照しようとしたオントロジーが有効でなかった場合、例えば、ネットワークトラブルやアクセス権の問題、ｏｂｓｏｌｅｔｅ等の場合に、それに代わるオントロジーを付けることを許すようになっている。
【００３３】
また、「ｎｕｍ（発注数）」という入力項目は、さらに別のツリーである「Ｕｎｉｔ」というオントロジー辞書の中の「Ｄｏｚｅｎ」のノードの型と同じである、ということが記述されている。すなわち、「ｎｕｍ（発注数）」という入力項目は、オントロジーによって指定されている。
【００３４】
メモリ装置５にストアされたオントロジー辞書データは、複数のノードをツリー形式で関連付け、各ノードにおいて述語が定義され、かつ各ノードのデータの型も併せて定義されている。従って、入力記述部６１には、入力項目のデータの型が、どのオントロジーのどのノードの型なのかが記述される。
【００３５】
同様に、図７において、出力記述部６２中の「ｌｅａｄ＿ｔｉｍｅｓ＠Ｔｉｍｅ＃Ｄａｙｓ， ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ」は、出力項目に関してオントロジーを記述、すなわち出力項目がオントロジーによって指定されていることを示す。具体的には、「ｌｅａｄ＿ｔｉｍｅｓ（リードタイム）」という出力項目は、「Ｔｉｍｅ」というオントロジー辞書の中の「Ｄａｙｓ」のノードの型を使用し、「ｐｒｉｃｅ（価格）」という出力項目は、「Ｃｕｒｒｅｎｃｙ」というオントロジー辞書の中の「Ｙｅｎ」のノードの型を使用することを示す。
【００３６】
つぎに、入力制約記述部６３について説明する。入力制約記述部６３中の「Ｉｎｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔｓ＠Ｒｕｌｅ＃Ｐｒｅｄｉｃａｔｅ」は、デフォルトのオントロジーを指定したものである。すなわち、検索要求中の入力制約の項目が、入力制約記述部６３の中の「ｍａｎｕｆａｃｔｕｒｅｒＯｆ（ｓｃｒｅｗ， ＡＢＣ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ）」で指定されたオントロジーにないが、デフォルトのオントロジーに存在する場合は、デフォルトのオントロジーのノードとして処理が行われる。
【００３７】
また、入力制約記述部６３中の「ｍａｎｕｆａｃｔｕｒｅｒＯｆ（ｓｃｒｅｗ， ＡＢＣ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ）」は、入力制約項目に関してオントロジーを記述、すなわち入力制約項目がオントロジーによって指定されていることを示す。具体的には、「ｍａｎｕｆａｃｔｕｒｅｒＯｆ」という述語名は、２つの引数、すなわち第１引数「ｓｃｒｅｗ」と第２引数「ＡＢＣ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ」からなり、第１引数の製造メーカは第２引数であることを意味する。そして、第２引数は、「ＡＢＣ」という項目は、「Ｃｏｍｐａｎｙ」というオントロジー辞書の中の「Ｍａｎｕｆａｃｔｕｒｅｒ」のノードの型を使用することを示す。すなわち、第２引数がオントロジーによって指定されている。
【００３８】
同様に、入力制約記述部６３中の「ｍｏｒｅ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１００）」も、入力制約項目に関してオントロジーを記述、すなわち入力制約項目がオントロジーによって指定されていることを示す。具体的には、「ｍｏｒｅ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語は、２つの引数、すなわち第１引数「ｎｕｍ」と第２引数「１００」からなり、「ｎｕｍ（個数）」は、「１００」個以上であることを意味する。そして、「ｍｏｒｅ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語は、「Ｍａｔｈ」というオントロジー辞書の中の「Ｍｏｒｅ」のノードの型を使用することを示す。すなわち、述語がオントロジーによって指定されている。
【００３９】
つぎに、出力制約記述部６４について説明する。出力制約記述部６４中の「Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ＠Ｒｕｌｅ＃Ｉｍｐｌｉｃａｔｉｏｎ」も入力制約記述部６３と同様に、デフォルトのオントロジーを指定したものである。すなわち、検索要求中の出力制約の項目が、出力制約記述部６４の中の「ｉｍｐｌｙ（ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１０００），ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｌｅａｄ＿ｔｉｍｅｓ，７））」で指定されたオントロジーにないが、デフォルトのオントロジーに存在する場合は、デフォルトのオントロジーのノードとして処理が行われる。
【００４０】
なお、以上の説明では、制約条件についてデフォルトオントロジーを指定しているが、入出力又は事前事後条件にデフォルトオントロジーを指定してもよい。
【００４１】
また、図７において、出力制約記述部６４中の「ｉｍｐｌｙ（ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１０００），ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｌｅａｄ＿ｔｉｍｅｓ，７））」は、出力制約項目に関してオントロジーを記述、すなわち入力制約項目がオントロジーによって指定されていることを示す。具体的には、「ｉｍｐｌｙ」という述語は、２つの引数、すなわち第１引数「ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１０００）」と第２引数「ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｌｅａｄ＿ｔｉｍｅｓ，７）」からなり、第１引数の条件のときは、第２引数の条件になることを意味する。
【００４２】
ここで、第１引数と第２引数において、「ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語において、オントロジー記述が用いられている。ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語は、「Ｍａｔｈ」というオントロジー辞書の中の「Ｍｏｒｅ」のノードの型を使用することを示す。従って、出力制約として、個数が１０００個以上であれば、納期は７日以上かかることが定義されている。すなわち、引数における述語がオントロジーによって指定されている。
【００４３】
また、図７において、事前条件記述部６５中の「ｎｏｔ（ｏｒｄｅｒｅｄ（ｓｃｒｅｗ））」は、ネジが未だ発注されていないことを示している。事後条件は存在していない。
【００４４】
以上のように、サービス記述には、Ｗｅｂサービスのプログラムに対する入力として、ネジのタイプと個数を与えると、価格と納期を出力するＷｅｂサービスにおいて、制約として、ネジの製造者がＡＢＣ会社であること、個数は１００個以上であること、個数が１０００個以上であれば納期は７日以上かかること、が定義されている。そして、事前条件としては、ネジがまだ発注されておらず、事後条件も存在しないことがサービス記述に記述されている。
【００４５】
そのサービス記述のデータが、メモリ装置６のレジストリにストアされ、ユーザからのＷｅｂサービス検索要求を受けると、ウエブサーバ１はレジストリにストアされた複数のＷｅｂサービスについてのＷｅｂサービス記述データを検索要求データに基づいて検索して、Ｗｅｂサービス検索要求に合致するＷｅｂサービスに関する情報を得て、検索要求を送信したユーザへその情報を送信する。
【００４６】
このとき、Ｗｅｂサービス記述のデータが、オントロジーによって指定されているので、例えば、項目について、データの型がオントロジー辞書によって定義されていれば、項目名が違っていても、データの型が一致する項目、あるいは類似する項目の型が検索でヒットすることになる。
【００４７】
以上の例では、オントロジーは、ツリーとノードで指定されているが、オントロジーの指定は他の方法を用いてもよい。
【００４８】
なお、サービス記述を、図７のような記述に代えて、図８に示すような記述にしてもよい。図８は、Ｗｅｂサービスの入出力、制約条件、事前事後条件等のそれぞれの参照先を記述したＷｅｂサービス記述の例を示す。
【００４９】
図８に示すように、入力項目の記述は、「Ｉｎｐｕｔ」としてＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｉｎｐｕｔ．ｘｍｌ」が記述され、出力項目の記述は、「Ｏｕｔｐｕｔ」として、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｏｕｔｐｕｔ．ｊａｖａ」が記述され、入力制約項目の記述は、「Ｉｎｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔｓ」として、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｉｎ＿ｃｏｎｓｔ．ｐｒｏｌｏｇ」が記述され、出力制約項目の記述は、「Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ」としてＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｏｕｔ＿ｃｏｎｓｔ．ｌｉｓｐ」が記述され、事前条件項目の記述は、「Ｐｒｅｃｏｎｄｉｔｉｏｎ」としてＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｐｒｅｃｏｎｄ．ｔｘｔ」が記述され、事後条件の記述はここでは記載されていない。すなわち、サービス記述として、図７の各項目６１から６５に対応して、各項目の参照先７１から７５を記述し、参照先において、各項目がオントロジーによって定義されている。図９は、入力項目の参照先７１における記述の例を示す図である。なお、図９に示すように、入力項目は、ＸＭＬ形式で記述された例である。ここでは、ＸＭＬ形式のタグについて、オントロジーを用いて要素が記述されている。
【００５０】
このように、入出力に関する記述形式と、制約条件に関する記述形式と、事前事後条件に関する記述形式と、サービス属性に関する記述形式と、オントロジーの記述形式をそれぞれ独立させて、特定の言語に依存しないサービスの記述を行うようにしてもよい。
【００５１】
次に、サービス間の類似性の判断方法について例を用いて説明する。
【００５２】
例えば、オントロジーツリーが
として、定義されているとする。ここでは、「＞」は親子関係を示す。ｃａｒの親はＡｕｔｏで、ノード間の距離を示すノード数は１であるとする。同様に、ｃａｒの子はｓｅｄａｎで、ノード数は１であり、ｃａｒの兄弟はＳＵＶで、ノード数は２であり、ＳＵＶと４ＷＤは同一であり、ノード数は０である。そして、オントロジーツリーのノード間のノード数（距離）を類似度と定義する。
【００５３】
この機能を利用するユーザは、入出力の型、制約条件、事前事後条件の比較の有無、比較する場合はオントロジーツリーの検索範囲を、上（親）方向、下（子）方向、同一の親または祖先を有する横（兄弟）方向、同一関係、あるいはそれら一部または全部の組合わせの中から選択できる。また、オントロジーツリーを走査する距離をノード数または検索にかかる時間でユーザが指定することもできる。
【００５４】
そこで、以下のような２つのサービスＳｅｒｖｉｃｅ １とＳｅｒｖｉｃｅ ２があり、２サービス記述間の類似性をオントロジーに基づいて判定する例を説明する。
【００５５】
Ｓｅｒｖｉｃｅ １は、
Ｉｎｐｕｔ： ａｕｔｏ＠Ｖｅｈｉｃｌｅ＃Ａｕｔｏ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であり、
Ｓｅｒｖｉｃｅ ２は、
Ｉｎｐｕｔ： ｓｅｄｅｎ＠Ｖｅｈｉｃｌｅ＃Ｓｅｄａｎ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であるとき、ユーザが、２つのサービスを、（１）入力と出力に関して比較する、（２）入力に関しては下（子）方向で距離３で、（３）出力に関しては同一、として検索範囲を設定した場合、Ａｕｔｏ とｓｅｄａｎ の距離は２であるため、Ｓｅｒｖｉｃｅ２はＳｅｒｖｉｃｅ１と類似性があると判断される。このように、ユーザは、オントロジーツリーにおいて類似と判断させたい範囲を設定することができる。
【００５６】
なお、ユーザは、入出力、制約条件、事前事後条件に加えて、前述したサービスの属性比較においても、比較の有無、比較する場合のツリーの走査方向と距離または時間を指定することができる。
【００５７】
ここで、時間の指定とは、類似性評価に掛かる時間を指定することである。類似性判断基準として、ノード間の距離の他に、評価時間を指定することによって、評価に要する時間、すなわち評価演算の時間が長くなると類似性が少ないと判断するようにしてもよい。また、最大評価時間を指定し、最大評価時間を超えた場合は、類似性が０（ゼロ）とみなすようにしてもよい。
【００５８】
次に、サービス間の類似性の判定方法の詳細について、型類似性判断機能、制約条件類似性判断機能、事前事後条件類似性判断機能、属性類似性判断機能のぞれぞれについて説明する。
【００５９】
まず、図４の型類似性判断機能部３５におけるオントロジーによる型類似性判断機能について説明する。
【００６０】
２つのサービス間において入出力の型を比較する際に、図５の型定義情報再帰分解機能部４１において型定義を再帰的に分解し、数学的な型判断とオントロジーの類似性判断を再帰的に実行することができる。
【００６１】
例えば、「ＣａｒＯｒｄｅｒ 」という項目について、「ｓｔｒｕｃｔ ＣａｒＯｒｄｅｒ｛ｉｎｔ ｎｕｍｂｅｒ；Ｖｅｈｉｃｌｅ＃Ｃａｒ ｔｙｐｅ；｝として型が定義されているとする。すなわち、ある項目が、２つの変数からなり、それぞれ型を有していることが定義されている。ここで、「Ｖｅｈｉｃｌｅ＃Ｃａｒ」はＶｅｈｉｃｌｅオントロジーのＣａｒノードを示し、類似の型を持つサービスも類似判断の対象とする。
【００６２】
このような場合、その例として、以下のような２つのサービスＳｅｒｖｉｃｅ ３とＳｅｒｖｉｃｅ ４があるとする。
【００６３】
Ｓｅｒｖｉｃｅ ３は、
Ｉｎｐｕｔ： ｏｒｄｅｒ＠ＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であり、Ｓｅｒｖｉｃｅ ４は、
Ｉｎｐｕｔ： ｏｒｄｅｒ＠Ｂｕｓｉｎｅｓｓ＃Ｏｒｄｅｒ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
である。
【００６４】
そして、Ｓｅｒｖｉｃｅ ３のノード「ＣａｒＯｒｄｅｒ」とＳｅｒｖｉｃｅ ４のノード「Ｏｒｄｅｒ」が、それぞれのオントロジーにおいて数学的な型とオントロジー指定が混在した一種の構造体として、次のように定義されているとする。
【００６５】
ノード「ＣａｒＯｒｄｅｒ」は
であり、ノード「Ｏｒｄｅｒ」は、
であると定義されている。すなわち、ノード「ＣａｒＯｒｄｅｒ」は、ｉｎｔ（整数）型のｎｕｍと、Ｖｅｈｉｃｌｅ＃Ｃａｒの２つの項目で定義され、ノード「Ｏｒｄｅｒ」は、ｆｌｏａｔ（浮動小数点）型のｑｕａｎｔｉｔｙと、Ｐｒｏｄｕｃｔ＃Ｏｂｊｅｃｔの２つの項目で定義されている。
【００６６】
オントロジーツリー上でＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのノードを比較すると、類似性がないと判断されてしまうが、ここでは、単にオントロジーツリー上でＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのノードを比較するだけではなく、両者の定義を参照し、それぞれを分解しながら、数学的な意味とオントロジー上の言葉の意味の比較を再帰的に行う。
【００６７】
なお、ここでは、それぞれのオントロジー指定部分のＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒが比較されるが、オントロジーツリーを跨いだ両者の関係（ｓｕｂＣｌａｓｓＯｆ， ｓａｍｅＡｓなどの親子関係、同一関係）は定義されていないものとする。
【００６８】
まず、ＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのそれぞれの定義を参照し、まずｉｎｔ（整数）型のｎｕｍとｆｌｏａｔ（浮動小数点）型のｑｕａｎｔｉｔｙが比較される。数学的には、ｆｌｏａｔはｉｎｔにキャスト（型変換）可能であることから、両者の比較は真となる。
【００６９】
次にＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのそれぞれの定義中の、Ｖｅｈｉｃｌｅ＃ＣａｒとＰｒｏｄｕｃｔ＃Ｏｂｊｅｃｔが比較される。ここで、Ｃａｒの親であるＡｕｔｏ（前述のＡｕｔｏオントロジー参照）は、Ｐｒｏｄｕｃｔ＃Ｏｂｊｅｃｔの子孫だと定義されているものとする。そのため、ＣａｒとＯｂｊｅｃｔの比較も真となる（ユーザによってツリー走査は親方向、距離無制限と設定されているものとする）。
【００７０】
その結果、Ｓｅｒｖｉｃｅ３とＳｅｒｖｉｃｅ４は類似性があると判断される。また、このような構造体定義の中に再度、構造体が指定されている場合は、この処理を再帰的に比較することとなる。
【００７１】
次に、図４の制約条件類似性判断機能部３６におけるオントロジーによる制約条件類似性判断機能について説明する。
【００７２】
２つのサービスにおける制約条件を比較する際に、図６の制約条件定義再帰分解機能部５１において制約条件を再帰的に分解し、制約条件の論理的な包摂関係判断とオントロジー類似性判断を再帰的に実行することができる。
【００７３】
最初の例として、２つのサービスにおける制約条件が、それぞれ次の２つ、すなわち制約１と制約２であったとする。
【００７４】
制約１： ｇｒｅａｔｅｒ（ｓｃｒｅｗ，１００）
制約２： ｌａｒｇｅｒ（ｎｅｊｉ，１０）
制約１は、ｓｃｒｅｗは１００より多いを意味し、制約２は、ｎｅｊｉが１０より多いを意味する。ここで、ｇｒｅａｔｅｒとｌａｇｅｒがオントロジーを利用した判断の結果により類似し、かつ、ｓｃｒｅｗとｎｅｊｉがオントロジーを利用した判断の結果によりで類似とされ、かつ、論理解釈に従って１００＞１０であることを加味して、制約１は制約２を満たし、検索要求が制約２の場合に、制約１を持つサービスは検索マッチ、すなわち要求を満たすとする。言い換えれば、制約１の「ｓｃｒｅｗが１００より多い」は、制約２の「ｎｅｊｉが１０より多い」に含まれるので、検索要求が制約２の場合は、制約１は要求を満たす制約条件である。
【００７５】
また、別の例として、２つのサービスにおける入出力と制約条件が、それぞれ次の２つ、Ｓｅｒｖｉｃｅ ５とＳｅｒｖｉｃｅ ６であったとする。
【００７６】
Ｓｅｒｖｉｃｅ ５は、
Ｉｎｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ： ｓｍａｌｌｅｒ（ｐｒｉｃｅ，１０）
であり、Ｓｅｒｖｉｃｅ ６は、
Ｉｎｐｕｔ： ｎｅｊｉ＠Ｂｕｈｉｎ＃Ｎｅｊｉ
Ｏｕｔｐｕｔ： ｎｅｄａｎ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ： ｌｅｓｓ（ｎｅｄａｎ，２０００）
である。
【００７７】
ここでも、制約条件Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔの類似性を判断する際に、図６のオントロジー類似性判断機能部５３と論理的包摂関係判断機能部５２とにおいて、それぞれオントロジーの類似性（言葉自体の意味の関係）の判定と、論理的な包摂関係（論理表現に基づいて論理的な計算によって求められる関係）の判定を再帰的に行うことができる。
【００７８】
例では、まずｓｍａｌｌｅｒとｌｅｓｓがオントロジー的に等価であることを判断される。次に、その論理的な意味が「より小さい」であることからＳｅｒｖｉｃｅ ５のＯｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔの第１引数ｐｒｉｃｅとＳｅｒｖｉｃｅ ６のそれの第１引数ｎｅｄａｎが言葉の意味において比較可能であり（オントロジー的な比較を行った結果として）、かつ、Ｓｅｒｖｉｃｅ ５のＯｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔの第２引数１０がＳｅｒｖｉｃｅ ６のそれの第２引数２０００より小さければ（論理的な比較を行った結果として）、Ｓｅｒｖｉｃｅ ５はＳｅｒｖｉｃｅ ６に包摂されると判断される。言い換えると、Ｓｅｒｖｉｃｅ ５を満たすものは常にＳｅｒｖｉｃｅ ５を満たすと判断される。
【００７９】
なお、ここでＣｕｒｒｅｎｃｙ＃ＵＳＤとＣｕｒｒｅｎｃｙ＃Ｙｅｎは、ｅｘｃｈａｎｇｅｂｌｅと定義されているとすると、ｐｒｉｃｅとｎｅｄａｎは比較可能であることが分かる。次に、ＵＳＤからＹｅｎへのｅｘｃｈａｎｇｅ ｒｕｌｅ（オントロジー定義に付与されている）に従って、例えば１０ドルが１２００円に直され（１ドルが１２０円とした場合）、１２００円は２０００円より小さいことから、論理的な意味「より小さい」が満たされていると判断できる。このようにして、Ｓｅｒｖｉｃｅ ５とＳｅｒｖｉｃｅ ５は類似性があると判断される。
【００８０】
つぎに、図４の事前事後条件類似性判断機能部３７におけるオントロジーに事前事後条件類似性判断機能について説明する。
【００８１】
ここでは、２つのサービスにおける制約条件を比較する際に、述語のオントロジーを参照し、引数の順序を無視して比較するか、順序どおりに比較するかを切り替えることができるようにする例について説明する。
【００８２】
例えば、以下のような２つのサービス、Ｓｅｒｖｉｃｅ ７とＳｅｒｖｉｃｅ ８があったとする。Ｓｅｒｖｉｃｅ ７は、
Ｉｎｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
Ｐｏｓｔｃｏｎｄｉｔｉｏｎ＠Ｒｕｌｅ＃ｐｒｅｄｉｃａｔｅ： ｏｒ（ｈａｖｅ（ｓｃｒｅｗ），ｎｏｔ（ｈａｖｅ（ｓｃｒｅｗ）））
であり、Ｓｅｒｖｉｃｅ ８は、：
Ｉｎｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
Ｐｏｓｔｃｏｎｄｉｔｉｏｎ＠Ｒｕｌｅ＃ｐｒｅｄｉｃａｔｅ： ｏｒ（ｎｏｔ（ｈａｖｅ（ｓｃｒｅｗ）），ｈａｖｅ（ｓｃｒｅｗ））
であるとする。
【００８３】
ここで、類似性を判断する場合に、ｏｒのオントロジー定義を参照し、引数の順序は同一性に関係しないことを判断し（関係するかどうかはオントロジー定義に付与されている）、Ｓｅｒｖｉｃｅ ７とＳｅｒｖｉｃｅ ８は同一であると分かる。
【００８４】
次に、図４の属性類似性判断機能部３８の属性類似性判断機能について説明する。
【００８５】
上述したオントロジーを用いたサービス記述を行うことによって、Ｗｅｂサービスの入出力、制約条件、事前事後条件に加えて、コメントのような属性を定義し、その属性をオントロジーを指定するようにして記述して、サービス記述に含めることができる。これによれば、サービス記述に適した属性をオントロジーで記述できる。
【００８６】
例えば、属性の要素として、サービスのカテゴリー（個人向け、企業向け、業種など）を、「Ｃａｔｅｇｏｒｙ： ｍａｎｕｆａｃｔｕｒｅｒ＠Ｂｕｓｉｎｅｓｓ＃Ｍａｎｕｆａｃｔｕｒｅｒ」として記述したり、サービスの提供範囲（日本、東京、浜松町など）を「Ｇｅｏｍｅｔｒｙ： ｊｐ＃Ｃｏｕｎｔｒｙ＃Ｊａｐａｎ」として記述したり、サービスのランク（信用情報など）を「Ｒａｔｉｎｇ： ８」として記述したり、サービスの提供者を、「Ｐｒｏｖｉｄｅｒ： ＸＹＺ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ」として記述したり、サービスの提供方法（オンライン、電話、郵送など）を「Ｍｅｄｉａ： ｏｎｌｉｎｅ＠Ｍｅｄｉａ＃Ｏｎｌｉｎｅ」として記述したりすることができる。いずれも、それぞれの属性が「＠」以下のオントロジーとノードによって記述されているので、Ｗｅｂサービス記述ならではの属性についても、Ｗｅｂサービス検索要求に対してオントロジー辞書を用いた検索を行うことができる。
【００８７】
次に、サービス類似性判定方法の高速化方法について説明する。
【００８８】
サービス間の類似性を比較する処理を高速化するため、オントロジー比較を行う前に、可能性の低いものを排除する前処理（プリチェック）を行う種々の方法について説明する。
【００８９】
最初の方法は、図４のネームスペースプリチェック機能部３１において、オントロジー名を比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、ネームスペースプリチェック機能では、各ノードの属するオントロジーツリー名を参照し、比較するオントロジーツリー名が異なっている場合は、高い確率で類似性がないと判断し、実際のオントロジーのノード比較を行わないことを指定できるようにしたものである。
【００９０】
なお、以下に説明する７つの例では、第１のＳｅｒｖｉｃｅが要求されるサービス、第２のＳｅｒｖｉｃｅが提供されているサービスであり、両者はマッチしないことを示している。
【００９１】
第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ ９は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、
第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １０は、
Ｉｎｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
である。従って、両者のオントロジー名を比較した結果、オントロジー名が異なっているため、類似性が無いと判断される。
【００９２】
第２の方法は、図４のテキストプリチェック機能部３２において、テキストを比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、テキストプリチェック機能では、サービス記述につけられた自然言語によるコメント、説明文などのテキストを参照し、テキストの量が十分であり、かつ、ＴＦＩＤＦ（Ｔｅｒｍ Ｆｒｅｑｕｅｎｃｙ ／ Ｉｎｖｅｒｓｅ Ｄｏｃｕｍｅｎｔ Ｆｒｅｑｕｅｎｃｙ）による類似性が一定のレベル以下であると判断された場合は、高い確率で類似性がないと判断し、入出力や制約条件のオントロジー比較を行わないことを指定できる。
【００９３】
第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １１は、
Ｃｏｍｍｅｎｔ： Ｃａｒ Ｓｅｌｌｉｎｇ
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １２は、
Ｃｏｍｍｅｎｔ： Ｐａｒｔｓ Ｑｕｏｔｉｎｇ
Ｉｎｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
であるとする。この場合、両者のコメント等のテキストを比較した結果、一定の条件の下、テキストが予め決められた閾値以上類似していないときは、類似性が無いと判断され、オントロジーを利用した判断を行わない。
【００９４】
第３の方法は、図４の引数プリチェック機能部３３において、引数を比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、引数プリチェック機能では、サービスが入力として必要とする情報（引数）の個数が要求されるサービスのそれより多い場合は、実際のオントロジーの比較を行わないことを指定できる。
【００９５】
例えば、あるサービスｆｕｎｃ（ｘ，ｙ，ｚ） は引数の数が３であり、引数の数が２の要求ｆｕｎｃ（ｘ，ｙ）には、ｚがないので、そのサービスは要求に対応することができない。この様な場合は、オントロジーを利用した判断を行わない。
他の例として、例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １３は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １４は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ， ｎｕｍ＠Ｕｎｉｔ＃ｄｏｚｅｎ
であるとする。この場合も、引数の数が違うので、オントロジーを利用した判断を行わない。
【００９６】
さらに、サービスが出力する情報（返り値）の個数が要求されるサービスのそれより少ない場合は、実際のオントロジーの比較を行わないことを指定できる。例えば、価格を返すサービスは，価格と納期が欲しいという要求には対応不可として、オントロジーを利用した判断を行わない。
【００９７】
さらに他の例として、例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １５は、
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ， ｌｅａｄ＿ｔｉｍｅｓ＠Ｔｉｍｅ＃Ｄａｙｓ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １６は、
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であるとする。この場合も、引数の数が違うので、オントロジーを利用した判断を行わない。
【００９８】
第４の方法は、図４の制約数プリチェック機能部３４において、制約数を比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、制約数プリチェック機能では、サービスの制約の個数が要求されるサービスの制約の個数と比べて多いか、少ないかに応じて、実際のオントロジーの比較を行わないことを指定できる。
【００９９】
最初の例として、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １７は、
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １８は、
であるとする。すなわち、サービス間の類似性を比較する場合、制約数プリチェック機能では、サービスの入力制約の個数が要求されるサービスのそれより多いので、実際のオントロジーの比較は行わなれない。
【０１００】
他の例として、例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １９は、
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ ２０は、
であるとする。このような場合、サービスの出力制約の個数が要求されるサービスのそれより少ないので、実際のオントロジーの比較は行われない。
【０１０１】
第５の方法は、オントロジー情報の解析、取得、格納機能において、サービス間の類似性を比較する処理を高速化するため、オントロジー記述がＷｅｂ上に存在する場合、オントロジーツリーをプログラミング言語のオブジェクトツリーに変換してローカルディスクまたはメモリ上に保持（キャッシュ）することができるようにしたものである。
【０１０２】
以下の例では、Ｓｅｒｖｉｃｅ ２１を取得し解析した時点で、Ｖｅｈｉｃｌｅオントロジーツリーは内部形式に変換され保持されるため、Ｓｅｒｖｉｃｅ ２２を解析する段階では再度取得を行わない。
【０１０３】
例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ ２１は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ ２２は、
Ｉｎｐｕｔ： ｓｅｄａｎ＠Ｖｅｈｉｃｌｅ＃Ｓｅｄａｎ
であるとする。この場合、Ｓｅｒｖｉｃｅ ２１を取得し解析した時点で、Ｖｅｈｉｃｌｅオントロジーツリーは内部形式に変換され保持されるため、その後は、一定間隔ごとにオントロジーツリーファイルの更新日時を参照し、更新されていれば再度取得するようにする。また、明示的にオントロジーツリーの更新を通知するメッセージまたはイベントを受け取った場合も再度取得する。
【０１０４】
次に、図４のスコア機能部３９におけるサービス類似性判定結果の評価方法について説明する。具体的には、このスコア機能では、サービス類似性判定の結果表示に関して、入出力、制約条件、事前事後条件、サービス属性に対して、ユーザが設定した重要度に応じて重み付けし、総合的な類似度を点数付けして結果をソートすることができるようにしたものである。
【０１０５】
例えば、以下のような３つのサービスＳｅｒｖｉｃｅ ２３、Ｓｅｒｖｉｃｅ ２４、Ｓｅｒｖｉｃｅ ２５があった場合、Ｓｅｒｖｉｃｅ ２３は、
Ｉｎｐｕｔ ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、Ｓｅｒｖｉｃｅ ２４は、
Ｉｎｐｕｔ ｎｅｄａｎ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
Ｏｕｔｐｕｔ ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、Ｓｅｒｖｉｃｅ ２５は、
Ｉｎｐｕｔ ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ ａｕｔｏ＠Ｖｅｈｉｃｌｅ＃Ａｕｔｏ
であるとする。ここで、Ｃｕｒｒｅｎｃｙ＃ＵＳＤとＣｕｒｒｅｎｃｙ＃Ｙｅｎの距離は１、Ｖｅｈｉｃｌｅ＃ＡｕｔｏとＶｅｈｉｃｌｅ＃Ｃａｒの距離も１であるため、Ｓｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２４の類似度は、Ｓｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２５の類似度と等しいと考えることができる。しかし、ユーザが入力としての通貨の単位を重視するならば、Ｉｎｐｕｔの重要度を高くすることで、Ｓｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２５の類似度をＳｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２４の類似度よりも高くすることができる。また、その逆も可能である。
【０１０６】
次に、以上の説明したサービス間の類似性判定を実行するための処理の流れについて説明する。
【０１０７】
まず、型類似性判断機能部３５の処理内容について説明する。図１０は、型類似性判断機能の処理の流れの例を示すフローチャートである。
【０１０８】
初めに、判断対象の型がオントロジー指定の型定義か、プログラム言語依存型定義かを判断する（ステップ（以下、Ｓと略す。）１）。オントロジー指定の型定義の場合、処理はＳ２へ移行し、指定オントロジーが外部のものか否かが判断される（Ｓ２）。Ｓ２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ３）。Ｓ２とＳ３でＮＯの場合は、処理はＳ４へ進む。
【０１０９】
Ｓ４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ５）。Ｓ５でＹＥＳならば、Ｓ６の処理へ進み、類似判断基準を設定し（Ｓ６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ７）。Ｓ５においてＮＯの場合は、Ｓ７の処理へ移行する。
【０１１０】
記録されたデータに基づいて類似性が０（ゼロ）であるか否かを判断する（Ｓ８）。Ｓ８でＮＯの場合は、そのまま処理は終了する。Ｓ８でＹＥＳの場合は、型が構造を持つか否かを判断し（Ｓ９）、Ｓ９でＹＥＳならば、型の各要素について、本手段を再帰的に適用する（Ｓ１０）。Ｓ９でＮＯの場合は、そのまま処理は終了する。
【０１１１】
Ｓ１で、判断対象がプログラム言語依存型定義であると判断されると、Ｓ１１の処理へ移行し、プログラム的変換可能性をチェックし、チェック結果データを記録、すなわちストアし（Ｓ１１）、Ｓ１２の処理へ移行する。Ｓ１２では、型変換可能性があるか否かが判断され、Ｓ１２でＹＥＳならば、そのまま処理は終了する。Ｓ１２でＮＯならば、Ｓ９の処理へ移行する。
【０１１２】
以上のようにして型類似性の判断の処理が実行される。
【０１１３】
次に、制約条件類似性判断機能部３６の処理内容について説明する。図１１は、制約条件類似性判断機能の処理の流れの例を示すフローチャートである。
【０１１４】
初めに、判断対象の制約がオントロジー指定の制約定義か、論理制約定義かを判断する（Ｓ２１）。オントロジー指定の制約定義の場合、処理はＳ２２へ移行し、指定オントロジーが外部のものか否かが判断される（Ｓ２２）。Ｓ２２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ２３）。Ｓ２２とＳ２３でＮＯの場合は、処理はＳ２４へ進む。
【０１１５】
Ｓ２４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ２４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ２５）。Ｓ２５でＹＥＳならば、Ｓ２６の処理へ進み、類似判断基準を設定し（Ｓ２６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ２７）。Ｓ２５においてＮＯの場合は、Ｓ２７の処理へ移行する。
【０１１６】
記録されたデータに基づいて類似性が０（ゼロ）であるか否かを判断する（Ｓ２８）。Ｓ２８でＮＯの場合は、そのまま処理は終了する。Ｓ２８でＹＥＳの場合は、制約が構造を持つか否かを判断し（Ｓ２９）、Ｓ２９でＹＥＳならば、制約の各要素について、本手段を再帰的に適用する（Ｓ３０）。Ｓ２９でＮＯの場合は、そのまま処理は終了する。
【０１１７】
Ｓ２１で、判断対象が論理制約定義であると判断されると、Ｓ３１の処理へ移行し、制約定義のデフォルトオントロジー内に同一名称のルールがあるか否かが判断される（３１）。Ｓ３１でＹＥＳならば、処理はＳ２２へ移行する。Ｓ３１でＮＯの場合は、論理的包括可能性をチェックし、チェック結果データを記録、すなわちストアし（Ｓ３２）、Ｓ３３の処理へ移行する。Ｓ３３では、包括可能性があるか否かが判断され、Ｓ３３でＹＥＳならば、そのまま処理は終了する。Ｓ３３でＮＯならば、Ｓ２９の処理へ移行する。
【０１１８】
以上のようにして制約条件類似性の判断の処理が実行される。
【０１１９】
次に、事前事後条件類似性判断機能部３７の処理内容について説明する。図１２は、事前事後条件類似性判断機能の処理の流れの例を示すフローチャートである。
【０１２０】
初めに、判断対象の事前事後条件がオントロジー指定の事前事後条件定義か、論理事前事後条件定義かを判断する（Ｓ４１）。オントロジー指定の事前事後条件定義の場合、処理はＳ４２へ移行し、指定オントロジーが外部のものか否かが判断される（Ｓ４２）。Ｓ４２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ４３）。Ｓ４２とＳ４３でＮＯの場合は、処理はＳ４４へ進む。
【０１２１】
Ｓ４４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ４４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ４５）。Ｓ４５でＹＥＳならば、Ｓ４６の処理へ進み、類似判断基準を設定し（Ｓ４６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ４７）。Ｓ４５においてＮＯの場合は、Ｓ４７の処理へ移行する。
【０１２２】
記録されたデータに基づいて類似性が０（ゼロ）であるか否かを判断する（Ｓ４８）。Ｓ２８でＮＯの場合は、そのまま処理は終了する。Ｓ２８でＹＥＳの場合は、事前事後条件が構造を持つか否かを判断し（Ｓ４９）、Ｓ４９でＹＥＳならば、事前事後条件の各要素について、本手段を再帰的に適用する（Ｓ５０）。Ｓ４９でＮＯの場合は、そのまま処理は終了する。
【０１２３】
Ｓ４１で、判断対象が論理事前事後条件定義であると判断されると、Ｓ５１の処理へ移行し、事前事後条件定義のデフォルトオントロジー内に同一名称のルールがあるか否かが判断される（５１）。Ｓ５１でＹＥＳならば、処理はＳ４２へ移行する。Ｓ５１でＮＯの場合は、論理的包括可能性をチェックし、チェック結果データを記録、すなわちストアし（Ｓ５２）、Ｓ５３の処理へ移行する。Ｓ５３では、包括可能性があるか否かが判断され、Ｓ５３でＹＥＳならば、そのまま処理は終了する。Ｓ５３でＮＯならば、Ｓ４９の処理へ移行する。
【０１２４】
以上のようにして事前事後条件類似性の判断の処理が実行される。
【０１２５】
次に、属性類似性判断機能部３８の処理内容について説明する。図１３は、属性類似性判断機能の処理の流れの例を示すフローチャートである。
【０１２６】
初めに、定義されている属性名称の一つに着目、すなわち選択し（Ｓ６１）、指定オントロジーが外部のものか否かが判断される（Ｓ６２）。Ｓ６２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ６３）。Ｓ６２とＳ６３でＮＯの場合は、処理はＳ６４へ進む。
【０１２７】
Ｓ６４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ６４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ６５）。Ｓ６５でＹＥＳならば、Ｓ６６の処理へ進み、類似判断基準を設定し（Ｓ６６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ６７）。Ｓ６５においてＮＯの場合は、Ｓ６７の処理へ移行する。そして、定義されている属性全てについてチェックしたか否かが判断され（Ｓ６８）、ＹＥＳならば処理は終了し、ＮＯであれば、未処理の属性にも同様の処理を行うべく、Ｓ６１の処理へ移行する。
【０１２８】
以上のようにして属性類似性の判断の処理が実行される。
【０１２９】
本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、以下、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明する。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【０１３０】
以上説明したように、本実施の形態によれば、サービス記述に、入出力の型、制約条件内の要素、事前条件内の要素、又は事後条件内の要素に対して、オントロジーを指定できるので、入出力の指定や、入出力に関する制約条件、事前条件、又は事後条件などを伴う特定機能を呼び出すためのインターフェースについて、異なる２サービスが類似しているかどうかを判断することができる。
【０１３１】
本実施の形態によれば、オントロジーを、従来のように文書理解における単語間の距離の測定に使うだけでなく、Ｗｅｂサービス記述において、型の判断、条件の論理判断、引数の順序判断を行うために、数学的な型に含ませてより複雑な構造体を作ったり、制約条件に含ませて条件記述に拡張性を持たせたり、関係述語が引数の順序を重視するかどうかの定義に含ませて使用することができる。
【０１３２】
なお、以上説明した動作を実行するプログラムは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶装置等に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のサービス情報提供装置を実現することができる。
【０１３３】
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【０１３４】
【発明の効果】
以上説明したように、本発明によれば、プログラム言語に関わる情報項目の中に現れる用語に関しても、類義語の判断などオントロジー技術を適用するための仕組みを有するサービス情報提供装置を実現することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係わるＷｅｂサービス検索システムの構成を示す構成図である。
【図２】本実施の形態に係わるウエブサーバのサービス検索機能部の構成を示す機能ブロック図である。
【図３】本実施の形態に係わるサービス記述解析機能部の構成を示す機能ブロック図である。
【図４】本実施の形態に係わるサービス類似性判断機能部の構成を示す機能ブロック図である。
【図５】本実施の形態に係わる型類似性判断機能部の機能を示す機能ブロック図である。
【図６】本実施の形態に係わる制約条件類似性判断機能部の機能を示す機能ブロック図である。
【図７】Ｗｅｂサービスのサービス記述の例を示す図である。
【図８】Ｗｅｂサービスの入出力、制約条件、事前事後条件等のそれぞれの参照先を記述したＷｅｂサービス記述の例を示す図である。
【図９】入力項目の参照先における記述の例を示す図である。
【図１０】型類似性判断機能の処理の流れの例を示すフローチャートである。
【図１１】制約条件類似性判断機能の処理の流れの例を示すフローチャートである。
【図１２】事前事後条件類似性判断機能の処理の流れの例を示すフローチャートである。
【図１３】属性類似性判断機能の処理の流れの例を示すフローチャートである。
【符号の説明】
１・・・ウエブサーバ
２・・・ＰＣ
３・・・インターネット
４・・・サービス提供装置
５、６・・・メモリ装置
【発明の属する技術分野】
本発明は、サービス情報提供装置、サービス情報提供方法及び記録媒体に関し、特に、ネットワーク上に存在するサービスプログラムが提供するサービスの情報を提供するサービス情報提供装置、サービス情報提供方法及び記録媒体に関する。
【０００２】
【従来の技術】
従来より、インターネット上のいわゆるＷｅｂページを検索するための検索エンジンは、ドキュメントであるＷｅｂページ内の言葉をキーとして検索を行う。ドキュメントでありドキュメント自身が検索キーの言葉を有するＷｅｂページと違って、Ｗｅｂサービスは、実態はサービスを提供するサービスプログラムであるため、プログラム自身には検索のための情報は含まれていない。そのため、Ｗｅｂサービス登録時にプログラムの内容を説明するために情報項目、サービス名、サービスドメイン、入出力項目、入出力に対する各種制約、その他コメントなどを、Ｗｅｂサービスを提供している企業等が登録する。そして、検索エンジンは、その登録された情報項目等に対して、検索を行う。
【０００３】
その際、Ｗｅｂサービスを提供するプログラムの内容を説明する情報は、人間が話す言葉の特性とプログラム言語の特性の両方を併せ持つ。プログラム言語においては、誰が記述したプログラムを誰が解釈しても意味が異なることはなく、プログラムとその意味はほぼ一意に決まる。一方、人間の言葉は、異なる言葉が同じ意味を持つことが多い。例えば、Ｗｅｂサービスがどのような入力を必要とし、どのような結果を返す、すなわち出力するのかを示す入出力の型は、プログラミングの型定義の文法に従うのに対して、そこで使われる型の名前は人間が話す言葉で表現される。
【０００４】
そして、従来のＷｅｂサービス検索では、プログラムの名前やコメント等の、もともと人間の言葉で書かれた情報項目に関しては、オントロジー技術を利用して、類義語の判断が行なわれていた（例えば、非特許文献１及び２参照。）。
【０００５】
【非特許文献１】
カティア・シカラ、セス・ウイドフ、マチアス・クルシュ、ジャンジュオ・ル・ラークス（Ｋａｔｉａ Ｓｙｃａｒａ， Ｓｅｔｈ Ｗｉｄｏｆｆ， Ｍａｔｔｈｉａｓ Ｋｌｕｓｃｈ ａｎｄ Ｊｉａｎｇｕｏ Ｌｕ． ＬＡＲＫＳ）著、「サイバースペースにおける異種ソフトウエアエージェント間の動的マッチメイキング（Ｄｙｎａｍｉｃ Ｍａｔｃｈｍａｋｉｎｇ Ａｍｏｎｇ Ｈｅｔｅｒｏｇｅｎｅｏｕｓ Ｓｏｆｔｗａｒｅ Ａｇｅｎｔｓ ｉｎ Ｃｙｂｅｒｓｐａｃｅ．）、 自律型エージェントとマルチエージェントシステム（Ａｕｔｏｎｏｍｏｕｓ Ａｇｅｎｔｓ ａｎｄ Ｍｕｌｔｉ−Ａｇｅｎｔ Ｓｙｓｔｅｍｓ）、第５巻（Ｖｏｌ． ５）、Ｐ．１７３−２０３， ２００２
【０００６】
【非特許文献２】
日経インターネットテクノロジ、「サービスの検索条件を拡張」、２００２年５月号、ｐ．４６
【０００７】
【発明が解決しようとする課題】
しかし、従来のＷｅｂサービス検索では、プログラムの名前やコメント等の、もともと人間の言葉で書かれた情報項目に関しては、オントロジー技術を利用して、類義語の判断を行ない、Ｗｅｂサービス提供者の使用し登録した言葉の類義語の範囲まで検索していたが、入出力の型定義等のプログラム言語に係る情報項目に関しては、類似の判断をするものはなかった。
【０００８】
【課題を解決するための手段】
そこで、本発明は、プログラム言語に関わる情報項目の中に現れる用語に関しても、類義語の判断等を行うオントロジー技術を適用するための仕組みを有するサービス情報提供装置を提供することを目的とする。
【０００９】
本発明のサービス情報提供装置は、ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、前記サービスの情報を提供するサービス情報提供装置であって、前記サービス記述は、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されている。
【００１０】
本発明のサービス情報提供方法は、ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、前記サービスの情報を提供するサービス情報提供方法であって、前記サービス記述は、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されている。
【００１１】
本発明のコンピュータ読み取り可能な記録媒体は、ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述のデータを有して、前記サービス記述のデータは、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されているデータが記録されている。
【００１２】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
【００１３】
まず図１に基づき、本実施の形態に係わるシステムの構成を説明する。図１は、本実施の形態に係わるＷｅｂサービス検索システムの構成を示す構成図である。
【００１４】
１は、サービス情報提供装置としてのウエブサーバ装置（以下、ウエブサーバという）であり、２は、ユーザが操作するパーソナルコンピュータ（以下、ＰＣという）である。ウエブサーバ１及びＰＣ２はインターネット３に接続されている。図１において、ＰＣ２は、一つしか図示していないが、複数接続され、各ユーザが自己のＰＣ２からウエブサーバ１にアクセスすることによってＷｅｂサービス検索システムを利用することができる。ウエブサーバ１は、ウエブサービスマッチメイカ（ウエブサービス検索エンジン）である。ウエブサーバ１には、オントロジー辞書データをストアするメモリ装置５と、後述するＷｅｂサービスに関するサービス記述データをストアするメモリ装置６が接続されている。メモリ装置５にストアされたオントロジー辞書データは、ここでは、複数のオントロジー辞書のデータを含む。オントロジー辞書データは、ユーザ要求に含まれる述語、Ｗｅｂサービス等を記述するサービス記述に含まれる述語を関連付けて体系化したデータベースである。具体的には、各オントロジーでは、複数のノードがツリー形式で関連付けられ、各ノードにおいて述語が定義されている。
【００１５】
４は、Ｗｅｂサービス用プログラムを有するサービス提供装置である。４−１から４−ｎ（ｎは整数）からなるｎ台のサービス提供装置も、ウエブサーバ１および複数のＰＣ２と同様に、インターネット３上に分散して存在し、インターネット３に接続されている。
【００１６】
Ｗｅｂサービスは、インターネットを利用してアクセス可能なサービスプログラムであるアプリケーションプログラムである。（従って、以下、Ｗｅｂサービスは、アプリケーションプログラムともいう。）人間あるいはコンピュータプログラムであるユーザは、インターネットを介して、そのアプリケーションプログラムを呼び出すことによって、そのアプリケーションプログラムを実行し、実行結果を利用することができる。
【００１７】
サービス検索装置としてのウエブサーバ１は、後述するように、ユーザであるＰＣ２からのＷｅｂサービスの検索要求を受信すると、その要求を満たすＷｅｂサービスを検索し、検索結果としてサービス提供装置４のそのＷｅｂサービスに関する情報を、ＰＣ２へ送信する。Ｗｅｂサービスに関する情報としては、Ｗｅｂサービスの呼び出しに必要なパラメータ、Ｗｅｂサービスの機能のデータ等である。ＰＣ２からの要求は、人間がＰＣ２を操作してＰＣ２からウエブサーバ１へ送信されるか、あるいはＰＣ２において実行されるコンピュータプログラムによって生成されてウエブサーバ１へ送信される。
【００１８】
なお、以下は、アプリケーションプログラムが、インターネットを利用したＷｅｂサービスである例を用いて説明するが、インターネットでない通信回線を利用してアクセス可能なアプリケーションプログラムであってもよい。
【００１９】
ウエブサーバ１には、インターネット４上にどのようなＷｅｂサービスがあるかというＷｅｂサービスに関するサービス記述データが、メモリ装置６に含まれるレジストリというデータベースに予め登録されている。ユーザからの検索要求に基づいて、ウエブサーバ１は、その登録、すなわちストアされたサービス記述データを検索して、Ｗｅｂサービスに関する情報、例えばそのユーザが利用したいＷｅｂサービスの有無、その呼び出し方法等の情報の提供をユーザのＰＣ２へ送信する。
【００２０】
図２は、図１のウエブサーバ１のサービス検索機能部の構成を示す機能ブロック図である。サービス情報提供装置としてのウエブサーバ１は、サービス検索機能部１１を含む。サービス検索機能部１１は、入出力通信機能部１２と、サービス記述解析機能部１３と、サービス類似性判断機能部１４を有する。入出力通信機能部１２は、インターネット３を介してＰＣ２等とのデータ通信を行う処理部である。サービス記述解析機能部１３は、検索要求に含まれるサービス記述のデータを解析し、かつレジストリにストアされたＷｅｂサービスに関するサービス記述のデータの解析も実行する処理部である。サービス類似性判断機能部１４は、後述する各種プリチェックと、オントロジーを利用した類似性判断と、スコア処理を行なう。
【００２１】
図３は、図２のサービス記述解析機能部１２の構成を示す機能ブロック図である。サービス記述解析機能部１２は、サービス記述解析機能部２１と、入出力型情報解析機能部２２と、制約条件解析機能部２３と、事前事後条件解析機能部２４と、属性情報解析機能部２５と、オントロジー情報解析機能部２６と、オントロジー情報取得機能部２７と、オントロジー情報格納機能部２８と、内部形式変換機能部２９とを含む。
【００２２】
サービス記述解析機能部２１は、ユーザからの検索要求あるいはレジストリにストアされたＷｅｂサービスのサービス記述データを、入出力型情報、制約条件、事前事後条件及び属性情報に分けるための解析処理部である。サービス記述解析機能部２１で分けられた入出力型情報、制約条件、事前事後条件及び属性情報のデータは、それぞれ解析する入出力型情報解析機能部２２、制約条件解析機能部２３、事前事後条件解析機能部２４及び属性情報解析機能部２５に供給され、解析される。
【００２３】
入出力型情報解析機能部２２、制約条件解析機能部２３、事前事後条件解析機能部２４及び属性情報解析機能部２５において解析されたそれぞれの情報に含まれるオントロジーに関連する情報が、オントロジー情報解析機能部２６に供給され、オントロジー情報、すなわちツリーとノードのデータが抽出される。そして、オントロジー情報取得機能部２７は、オントロジー情報解析機能部２６において抽出されたオントロジー情報を、レジストリのオントロジー辞書データから取得する。オントロジー情報格納機能部２８は、オントロジー情報取得機能部２７において取得されたオントロジー情報を、メモリ上にストア、すなわちキャッシュする。内部形式変換機能部２９は、外部のオントロジーの表現を、レジストリに登録されたオントロジーの表現形式に変換する処理部である。従って、内部形式変換機能部２９は、既にストアされている内部のオントロジー情報については、内部形式に変換しない。
【００２４】
図４は、図２のサービス類似性判断機能部１４の構成を示す機能ブロック図である。サービス類似性判断機能部１４は、ネームスペースプリチェック機能部３１と、テキストプリチェック機能部３２と、引数プリチェック機能部３３と、制約数プリチェック機能部３４と、型類似性判断機能部３５と、制約条件類似性判断機能部３６と、事前事後条件類似性判断機能部３７と、属性類似性判断機能部３８と、スコア機能部３９と、オントロジー類似性判断機能部４０とを含む。図４の各部の処理内容は後述する。
【００２５】
図５は、型類似性判断機能部３５の機能を示す機能ブロック図である。型類似性判断機能部３５は、型定義情報再帰分解機能部４１と、プログラム言語依存型整合性判断機能部４２と、オントロジー類似性判断機能部４３とを含む。型定義情報再帰分解機能部４１は、型定義情報を再帰的に分解する処理を行なう処理部である。プログラム言語依存型整合性判断機能部４２は、型定義がオントロジーで指定されていない場合、すなわちプログラム言語に依存して定義された型の整合性を判断する処理を行う処理部である。オントロジー類似性判断機能部４３は、オントロジーで指定された型の類似性を判断する処理を行なう処理部である。従って、入出力の型の情報は、型類似性判断機能部３５において型の整合性と類似性が再帰的に実行されて判断される。
【００２６】
図６は、制約条件類似性判断機能部３６の機能を示す機能ブロック図である。制約条件類似性判断機能部３６は、制約条件定義再帰分解機能部５１と、論理的包摂関係判断機能部５２と、オントロジー類似性判断機能部５３とを含む。制約条件定義再帰分解機能部５１は、制約条件定義情報を再帰的に分解する処理を行なう処理部である。論理的包摂関係判断機能部５２は、制約条件の定義がオントロジーで指定されていない場合、すなわちプログラム言語に依存して定義された制約条件の包摂関係を判断する処理を行う処理部である。オントロジー類似性判断機能部５３は、オントロジーで指定された制約条件の類似性を判断する処理を行なう処理部である。従って、制約条件の情報は、制約条件類似性判断機能部３６において制約条件の包摂関係と類似性が再帰的に実行されて判断される。
【００２７】
まず、サービス記述の具体例について説明する。
【００２８】
図７は、あるＷｅｂサービスのサービス記述の例を示す図である。例えば、ネジを製造し販売している会社が、ユーザからの見積要求に対して、要求するネジの価格と納期をネットワーク上で回答するサービスを、サービス提供装置４−１によってＷｅｂサービスとして提供している場合の例が、示されている。そして、そのＷｅｂサービスを多くのユーザに利用して貰うために、その会社は、Ｗｅｂサービス検索装置であるウエブサーバ１のメモリ装置６のレジストリにそのＷｅｂサービスの内容を記述したデータ、すなわちサービス記述データを登録する。登録されたサービス記述の例を、図７は示している。なお、Ｗｅｂサービスの検索条件も図７に示すような記述と同様に記述され、ユーザから検索要求データとして生成されて、ウエブサーバ１へ送信される。
【００２９】
図７は、ネジの見積を行うＷｅｂサービスであって、入力としてネジのタイプと個数を与えると、価格と納期を出力する見積もりサービスのサービス記述の例を示している。図７に示されたサービス記述は、そのＷｅｂサービスに関する入力、出力、入力制約及び出力制約の項目に関してのサービス記述部である、入力記述部６１、出力記述部６２、入力制約記述部６３、出力制約記述部６４及び事前条件記述部６５を含む例である。なお、これらの以外の項目についての記述部を含んでいてもよい。なお、以下の例では、オントロジーは、ツリーとノードで指定されており、「オントロジーツリー名＃ノード名」という形式で記述されている。
【００３０】
図７において、「Ｐａｒｔｓ Ｑｕｏｔｉｎｇ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ：」は、Ｗｅｂサービスの名称を示している。入力記述部６１中の「ｓｃｒｅｗ＠｛Ｐａｒｔｓ＃Ｓｃｒｅｗ，Ｂｕｈｉｎ＃ｎｅｊｉ｝， ｎｕｍ＠Ｕｎｉｔ＃Ｄｏｚｅｎ」は、入力項目に関してオントロジーを記述、すなわち入力項目がオントロジーによって指定されていることを示す。具体的には、「ｓｃｒｅｗ（ネジ）」という入力項目は、ツリーである「Ｐａｒｔｓ」というオントロジー辞書の中の「Ｓｃｒｅｗ」のノードの型か、別なツリーである「Ｂｕｈｉｎ」というオントロジー辞書の中の「ｎｅｊｉ」のノードの型を使用することを示す。言い換えると、「ｓｃｒｅｗ（ネジ）」という入力項目のデータの型は、「Ｐａｒｔｓ」というオントロジー辞書の中の「Ｓｃｒｅｗ」のノードの型か、「Ｂｕｈｉｎ」というオントロジー辞書の中の「ｎｅｊｉ」のノードの型と同じである、ということが記述されている。すなわち、２つの引数が夫々別のオントロジーによって指定されている。
【００３１】
このように、１つのサービスに関する記述中の個々の変数等の要素に対して、別々のオントロジーツリーを指定できるようになっている。以下の出力記述部６２等においても同様である。
【００３２】
さらに、ここの例では、「ｓｃｒｅｗ＠｛Ｐａｒｔｓ＃Ｓｃｒｅｗ，Ｂｕｈｉｎ＃ｎｅｊｉ｝」のように、１要素「ｓｃｒｅｗ」に対して複数のオントロジー指定ができることを意味しており、参照しようとしたオントロジーが有効でなかった場合、例えば、ネットワークトラブルやアクセス権の問題、ｏｂｓｏｌｅｔｅ等の場合に、それに代わるオントロジーを付けることを許すようになっている。
【００３３】
また、「ｎｕｍ（発注数）」という入力項目は、さらに別のツリーである「Ｕｎｉｔ」というオントロジー辞書の中の「Ｄｏｚｅｎ」のノードの型と同じである、ということが記述されている。すなわち、「ｎｕｍ（発注数）」という入力項目は、オントロジーによって指定されている。
【００３４】
メモリ装置５にストアされたオントロジー辞書データは、複数のノードをツリー形式で関連付け、各ノードにおいて述語が定義され、かつ各ノードのデータの型も併せて定義されている。従って、入力記述部６１には、入力項目のデータの型が、どのオントロジーのどのノードの型なのかが記述される。
【００３５】
同様に、図７において、出力記述部６２中の「ｌｅａｄ＿ｔｉｍｅｓ＠Ｔｉｍｅ＃Ｄａｙｓ， ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ」は、出力項目に関してオントロジーを記述、すなわち出力項目がオントロジーによって指定されていることを示す。具体的には、「ｌｅａｄ＿ｔｉｍｅｓ（リードタイム）」という出力項目は、「Ｔｉｍｅ」というオントロジー辞書の中の「Ｄａｙｓ」のノードの型を使用し、「ｐｒｉｃｅ（価格）」という出力項目は、「Ｃｕｒｒｅｎｃｙ」というオントロジー辞書の中の「Ｙｅｎ」のノードの型を使用することを示す。
【００３６】
つぎに、入力制約記述部６３について説明する。入力制約記述部６３中の「Ｉｎｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔｓ＠Ｒｕｌｅ＃Ｐｒｅｄｉｃａｔｅ」は、デフォルトのオントロジーを指定したものである。すなわち、検索要求中の入力制約の項目が、入力制約記述部６３の中の「ｍａｎｕｆａｃｔｕｒｅｒＯｆ（ｓｃｒｅｗ， ＡＢＣ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ）」で指定されたオントロジーにないが、デフォルトのオントロジーに存在する場合は、デフォルトのオントロジーのノードとして処理が行われる。
【００３７】
また、入力制約記述部６３中の「ｍａｎｕｆａｃｔｕｒｅｒＯｆ（ｓｃｒｅｗ， ＡＢＣ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ）」は、入力制約項目に関してオントロジーを記述、すなわち入力制約項目がオントロジーによって指定されていることを示す。具体的には、「ｍａｎｕｆａｃｔｕｒｅｒＯｆ」という述語名は、２つの引数、すなわち第１引数「ｓｃｒｅｗ」と第２引数「ＡＢＣ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ」からなり、第１引数の製造メーカは第２引数であることを意味する。そして、第２引数は、「ＡＢＣ」という項目は、「Ｃｏｍｐａｎｙ」というオントロジー辞書の中の「Ｍａｎｕｆａｃｔｕｒｅｒ」のノードの型を使用することを示す。すなわち、第２引数がオントロジーによって指定されている。
【００３８】
同様に、入力制約記述部６３中の「ｍｏｒｅ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１００）」も、入力制約項目に関してオントロジーを記述、すなわち入力制約項目がオントロジーによって指定されていることを示す。具体的には、「ｍｏｒｅ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語は、２つの引数、すなわち第１引数「ｎｕｍ」と第２引数「１００」からなり、「ｎｕｍ（個数）」は、「１００」個以上であることを意味する。そして、「ｍｏｒｅ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語は、「Ｍａｔｈ」というオントロジー辞書の中の「Ｍｏｒｅ」のノードの型を使用することを示す。すなわち、述語がオントロジーによって指定されている。
【００３９】
つぎに、出力制約記述部６４について説明する。出力制約記述部６４中の「Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ＠Ｒｕｌｅ＃Ｉｍｐｌｉｃａｔｉｏｎ」も入力制約記述部６３と同様に、デフォルトのオントロジーを指定したものである。すなわち、検索要求中の出力制約の項目が、出力制約記述部６４の中の「ｉｍｐｌｙ（ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１０００），ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｌｅａｄ＿ｔｉｍｅｓ，７））」で指定されたオントロジーにないが、デフォルトのオントロジーに存在する場合は、デフォルトのオントロジーのノードとして処理が行われる。
【００４０】
なお、以上の説明では、制約条件についてデフォルトオントロジーを指定しているが、入出力又は事前事後条件にデフォルトオントロジーを指定してもよい。
【００４１】
また、図７において、出力制約記述部６４中の「ｉｍｐｌｙ（ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１０００），ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｌｅａｄ＿ｔｉｍｅｓ，７））」は、出力制約項目に関してオントロジーを記述、すなわち入力制約項目がオントロジーによって指定されていることを示す。具体的には、「ｉｍｐｌｙ」という述語は、２つの引数、すなわち第１引数「ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｎｕｍ，１０００）」と第２引数「ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ（ｌｅａｄ＿ｔｉｍｅｓ，７）」からなり、第１引数の条件のときは、第２引数の条件になることを意味する。
【００４２】
ここで、第１引数と第２引数において、「ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語において、オントロジー記述が用いられている。ｌｅｓｓ＠Ｍａｔｈ＃Ｍｏｒｅ」という述語は、「Ｍａｔｈ」というオントロジー辞書の中の「Ｍｏｒｅ」のノードの型を使用することを示す。従って、出力制約として、個数が１０００個以上であれば、納期は７日以上かかることが定義されている。すなわち、引数における述語がオントロジーによって指定されている。
【００４３】
また、図７において、事前条件記述部６５中の「ｎｏｔ（ｏｒｄｅｒｅｄ（ｓｃｒｅｗ））」は、ネジが未だ発注されていないことを示している。事後条件は存在していない。
【００４４】
以上のように、サービス記述には、Ｗｅｂサービスのプログラムに対する入力として、ネジのタイプと個数を与えると、価格と納期を出力するＷｅｂサービスにおいて、制約として、ネジの製造者がＡＢＣ会社であること、個数は１００個以上であること、個数が１０００個以上であれば納期は７日以上かかること、が定義されている。そして、事前条件としては、ネジがまだ発注されておらず、事後条件も存在しないことがサービス記述に記述されている。
【００４５】
そのサービス記述のデータが、メモリ装置６のレジストリにストアされ、ユーザからのＷｅｂサービス検索要求を受けると、ウエブサーバ１はレジストリにストアされた複数のＷｅｂサービスについてのＷｅｂサービス記述データを検索要求データに基づいて検索して、Ｗｅｂサービス検索要求に合致するＷｅｂサービスに関する情報を得て、検索要求を送信したユーザへその情報を送信する。
【００４６】
このとき、Ｗｅｂサービス記述のデータが、オントロジーによって指定されているので、例えば、項目について、データの型がオントロジー辞書によって定義されていれば、項目名が違っていても、データの型が一致する項目、あるいは類似する項目の型が検索でヒットすることになる。
【００４７】
以上の例では、オントロジーは、ツリーとノードで指定されているが、オントロジーの指定は他の方法を用いてもよい。
【００４８】
なお、サービス記述を、図７のような記述に代えて、図８に示すような記述にしてもよい。図８は、Ｗｅｂサービスの入出力、制約条件、事前事後条件等のそれぞれの参照先を記述したＷｅｂサービス記述の例を示す。
【００４９】
図８に示すように、入力項目の記述は、「Ｉｎｐｕｔ」としてＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｉｎｐｕｔ．ｘｍｌ」が記述され、出力項目の記述は、「Ｏｕｔｐｕｔ」として、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｏｕｔｐｕｔ．ｊａｖａ」が記述され、入力制約項目の記述は、「Ｉｎｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔｓ」として、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｉｎ＿ｃｏｎｓｔ．ｐｒｏｌｏｇ」が記述され、出力制約項目の記述は、「Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ」としてＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｏｕｔ＿ｃｏｎｓｔ．ｌｉｓｐ」が記述され、事前条件項目の記述は、「Ｐｒｅｃｏｎｄｉｔｉｏｎ」としてＵＲＬ「ｈｔｔｐ：／／ｗｗｗ． ＡＢＣ．ｃｏ．ｊｐ／ｐａｒｔｓ＿ｑｕｏｔｅ／ｐｒｅｃｏｎｄ．ｔｘｔ」が記述され、事後条件の記述はここでは記載されていない。すなわち、サービス記述として、図７の各項目６１から６５に対応して、各項目の参照先７１から７５を記述し、参照先において、各項目がオントロジーによって定義されている。図９は、入力項目の参照先７１における記述の例を示す図である。なお、図９に示すように、入力項目は、ＸＭＬ形式で記述された例である。ここでは、ＸＭＬ形式のタグについて、オントロジーを用いて要素が記述されている。
【００５０】
このように、入出力に関する記述形式と、制約条件に関する記述形式と、事前事後条件に関する記述形式と、サービス属性に関する記述形式と、オントロジーの記述形式をそれぞれ独立させて、特定の言語に依存しないサービスの記述を行うようにしてもよい。
【００５１】
次に、サービス間の類似性の判断方法について例を用いて説明する。
【００５２】
例えば、オントロジーツリーが
【００５３】
この機能を利用するユーザは、入出力の型、制約条件、事前事後条件の比較の有無、比較する場合はオントロジーツリーの検索範囲を、上（親）方向、下（子）方向、同一の親または祖先を有する横（兄弟）方向、同一関係、あるいはそれら一部または全部の組合わせの中から選択できる。また、オントロジーツリーを走査する距離をノード数または検索にかかる時間でユーザが指定することもできる。
【００５４】
そこで、以下のような２つのサービスＳｅｒｖｉｃｅ １とＳｅｒｖｉｃｅ ２があり、２サービス記述間の類似性をオントロジーに基づいて判定する例を説明する。
【００５５】
Ｓｅｒｖｉｃｅ １は、
Ｉｎｐｕｔ： ａｕｔｏ＠Ｖｅｈｉｃｌｅ＃Ａｕｔｏ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であり、
Ｓｅｒｖｉｃｅ ２は、
Ｉｎｐｕｔ： ｓｅｄｅｎ＠Ｖｅｈｉｃｌｅ＃Ｓｅｄａｎ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であるとき、ユーザが、２つのサービスを、（１）入力と出力に関して比較する、（２）入力に関しては下（子）方向で距離３で、（３）出力に関しては同一、として検索範囲を設定した場合、Ａｕｔｏ とｓｅｄａｎ の距離は２であるため、Ｓｅｒｖｉｃｅ２はＳｅｒｖｉｃｅ１と類似性があると判断される。このように、ユーザは、オントロジーツリーにおいて類似と判断させたい範囲を設定することができる。
【００５６】
なお、ユーザは、入出力、制約条件、事前事後条件に加えて、前述したサービスの属性比較においても、比較の有無、比較する場合のツリーの走査方向と距離または時間を指定することができる。
【００５７】
ここで、時間の指定とは、類似性評価に掛かる時間を指定することである。類似性判断基準として、ノード間の距離の他に、評価時間を指定することによって、評価に要する時間、すなわち評価演算の時間が長くなると類似性が少ないと判断するようにしてもよい。また、最大評価時間を指定し、最大評価時間を超えた場合は、類似性が０（ゼロ）とみなすようにしてもよい。
【００５８】
次に、サービス間の類似性の判定方法の詳細について、型類似性判断機能、制約条件類似性判断機能、事前事後条件類似性判断機能、属性類似性判断機能のぞれぞれについて説明する。
【００５９】
まず、図４の型類似性判断機能部３５におけるオントロジーによる型類似性判断機能について説明する。
【００６０】
２つのサービス間において入出力の型を比較する際に、図５の型定義情報再帰分解機能部４１において型定義を再帰的に分解し、数学的な型判断とオントロジーの類似性判断を再帰的に実行することができる。
【００６１】
例えば、「ＣａｒＯｒｄｅｒ 」という項目について、「ｓｔｒｕｃｔ ＣａｒＯｒｄｅｒ｛ｉｎｔ ｎｕｍｂｅｒ；Ｖｅｈｉｃｌｅ＃Ｃａｒ ｔｙｐｅ；｝として型が定義されているとする。すなわち、ある項目が、２つの変数からなり、それぞれ型を有していることが定義されている。ここで、「Ｖｅｈｉｃｌｅ＃Ｃａｒ」はＶｅｈｉｃｌｅオントロジーのＣａｒノードを示し、類似の型を持つサービスも類似判断の対象とする。
【００６２】
このような場合、その例として、以下のような２つのサービスＳｅｒｖｉｃｅ ３とＳｅｒｖｉｃｅ ４があるとする。
【００６３】
Ｓｅｒｖｉｃｅ ３は、
Ｉｎｐｕｔ： ｏｒｄｅｒ＠ＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であり、Ｓｅｒｖｉｃｅ ４は、
Ｉｎｐｕｔ： ｏｒｄｅｒ＠Ｂｕｓｉｎｅｓｓ＃Ｏｒｄｅｒ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
である。
【００６４】
そして、Ｓｅｒｖｉｃｅ ３のノード「ＣａｒＯｒｄｅｒ」とＳｅｒｖｉｃｅ ４のノード「Ｏｒｄｅｒ」が、それぞれのオントロジーにおいて数学的な型とオントロジー指定が混在した一種の構造体として、次のように定義されているとする。
【００６５】
ノード「ＣａｒＯｒｄｅｒ」は
【００６６】
オントロジーツリー上でＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのノードを比較すると、類似性がないと判断されてしまうが、ここでは、単にオントロジーツリー上でＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのノードを比較するだけではなく、両者の定義を参照し、それぞれを分解しながら、数学的な意味とオントロジー上の言葉の意味の比較を再帰的に行う。
【００６７】
なお、ここでは、それぞれのオントロジー指定部分のＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒが比較されるが、オントロジーツリーを跨いだ両者の関係（ｓｕｂＣｌａｓｓＯｆ， ｓａｍｅＡｓなどの親子関係、同一関係）は定義されていないものとする。
【００６８】
まず、ＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのそれぞれの定義を参照し、まずｉｎｔ（整数）型のｎｕｍとｆｌｏａｔ（浮動小数点）型のｑｕａｎｔｉｔｙが比較される。数学的には、ｆｌｏａｔはｉｎｔにキャスト（型変換）可能であることから、両者の比較は真となる。
【００６９】
次にＣａｒＳｅｌｌｅｒ＃ＣａｒＯｒｄｅｒとＢｕｓｉｎｅｓｓ＃Ｏｒｄｅｒのそれぞれの定義中の、Ｖｅｈｉｃｌｅ＃ＣａｒとＰｒｏｄｕｃｔ＃Ｏｂｊｅｃｔが比較される。ここで、Ｃａｒの親であるＡｕｔｏ（前述のＡｕｔｏオントロジー参照）は、Ｐｒｏｄｕｃｔ＃Ｏｂｊｅｃｔの子孫だと定義されているものとする。そのため、ＣａｒとＯｂｊｅｃｔの比較も真となる（ユーザによってツリー走査は親方向、距離無制限と設定されているものとする）。
【００７０】
その結果、Ｓｅｒｖｉｃｅ３とＳｅｒｖｉｃｅ４は類似性があると判断される。また、このような構造体定義の中に再度、構造体が指定されている場合は、この処理を再帰的に比較することとなる。
【００７１】
次に、図４の制約条件類似性判断機能部３６におけるオントロジーによる制約条件類似性判断機能について説明する。
【００７２】
２つのサービスにおける制約条件を比較する際に、図６の制約条件定義再帰分解機能部５１において制約条件を再帰的に分解し、制約条件の論理的な包摂関係判断とオントロジー類似性判断を再帰的に実行することができる。
【００７３】
最初の例として、２つのサービスにおける制約条件が、それぞれ次の２つ、すなわち制約１と制約２であったとする。
【００７４】
制約１： ｇｒｅａｔｅｒ（ｓｃｒｅｗ，１００）
制約２： ｌａｒｇｅｒ（ｎｅｊｉ，１０）
制約１は、ｓｃｒｅｗは１００より多いを意味し、制約２は、ｎｅｊｉが１０より多いを意味する。ここで、ｇｒｅａｔｅｒとｌａｇｅｒがオントロジーを利用した判断の結果により類似し、かつ、ｓｃｒｅｗとｎｅｊｉがオントロジーを利用した判断の結果によりで類似とされ、かつ、論理解釈に従って１００＞１０であることを加味して、制約１は制約２を満たし、検索要求が制約２の場合に、制約１を持つサービスは検索マッチ、すなわち要求を満たすとする。言い換えれば、制約１の「ｓｃｒｅｗが１００より多い」は、制約２の「ｎｅｊｉが１０より多い」に含まれるので、検索要求が制約２の場合は、制約１は要求を満たす制約条件である。
【００７５】
また、別の例として、２つのサービスにおける入出力と制約条件が、それぞれ次の２つ、Ｓｅｒｖｉｃｅ ５とＳｅｒｖｉｃｅ ６であったとする。
【００７６】
Ｓｅｒｖｉｃｅ ５は、
Ｉｎｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ： ｓｍａｌｌｅｒ（ｐｒｉｃｅ，１０）
であり、Ｓｅｒｖｉｃｅ ６は、
Ｉｎｐｕｔ： ｎｅｊｉ＠Ｂｕｈｉｎ＃Ｎｅｊｉ
Ｏｕｔｐｕｔ： ｎｅｄａｎ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔ： ｌｅｓｓ（ｎｅｄａｎ，２０００）
である。
【００７７】
ここでも、制約条件Ｏｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔの類似性を判断する際に、図６のオントロジー類似性判断機能部５３と論理的包摂関係判断機能部５２とにおいて、それぞれオントロジーの類似性（言葉自体の意味の関係）の判定と、論理的な包摂関係（論理表現に基づいて論理的な計算によって求められる関係）の判定を再帰的に行うことができる。
【００７８】
例では、まずｓｍａｌｌｅｒとｌｅｓｓがオントロジー的に等価であることを判断される。次に、その論理的な意味が「より小さい」であることからＳｅｒｖｉｃｅ ５のＯｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔの第１引数ｐｒｉｃｅとＳｅｒｖｉｃｅ ６のそれの第１引数ｎｅｄａｎが言葉の意味において比較可能であり（オントロジー的な比較を行った結果として）、かつ、Ｓｅｒｖｉｃｅ ５のＯｕｔｐｕｔ＿Ｃｏｎｓｔｒａｉｎｔの第２引数１０がＳｅｒｖｉｃｅ ６のそれの第２引数２０００より小さければ（論理的な比較を行った結果として）、Ｓｅｒｖｉｃｅ ５はＳｅｒｖｉｃｅ ６に包摂されると判断される。言い換えると、Ｓｅｒｖｉｃｅ ５を満たすものは常にＳｅｒｖｉｃｅ ５を満たすと判断される。
【００７９】
なお、ここでＣｕｒｒｅｎｃｙ＃ＵＳＤとＣｕｒｒｅｎｃｙ＃Ｙｅｎは、ｅｘｃｈａｎｇｅｂｌｅと定義されているとすると、ｐｒｉｃｅとｎｅｄａｎは比較可能であることが分かる。次に、ＵＳＤからＹｅｎへのｅｘｃｈａｎｇｅ ｒｕｌｅ（オントロジー定義に付与されている）に従って、例えば１０ドルが１２００円に直され（１ドルが１２０円とした場合）、１２００円は２０００円より小さいことから、論理的な意味「より小さい」が満たされていると判断できる。このようにして、Ｓｅｒｖｉｃｅ ５とＳｅｒｖｉｃｅ ５は類似性があると判断される。
【００８０】
つぎに、図４の事前事後条件類似性判断機能部３７におけるオントロジーに事前事後条件類似性判断機能について説明する。
【００８１】
ここでは、２つのサービスにおける制約条件を比較する際に、述語のオントロジーを参照し、引数の順序を無視して比較するか、順序どおりに比較するかを切り替えることができるようにする例について説明する。
【００８２】
例えば、以下のような２つのサービス、Ｓｅｒｖｉｃｅ ７とＳｅｒｖｉｃｅ ８があったとする。Ｓｅｒｖｉｃｅ ７は、
Ｉｎｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
Ｐｏｓｔｃｏｎｄｉｔｉｏｎ＠Ｒｕｌｅ＃ｐｒｅｄｉｃａｔｅ： ｏｒ（ｈａｖｅ（ｓｃｒｅｗ），ｎｏｔ（ｈａｖｅ（ｓｃｒｅｗ）））
であり、Ｓｅｒｖｉｃｅ ８は、：
Ｉｎｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
Ｐｏｓｔｃｏｎｄｉｔｉｏｎ＠Ｒｕｌｅ＃ｐｒｅｄｉｃａｔｅ： ｏｒ（ｎｏｔ（ｈａｖｅ（ｓｃｒｅｗ）），ｈａｖｅ（ｓｃｒｅｗ））
であるとする。
【００８３】
ここで、類似性を判断する場合に、ｏｒのオントロジー定義を参照し、引数の順序は同一性に関係しないことを判断し（関係するかどうかはオントロジー定義に付与されている）、Ｓｅｒｖｉｃｅ ７とＳｅｒｖｉｃｅ ８は同一であると分かる。
【００８４】
次に、図４の属性類似性判断機能部３８の属性類似性判断機能について説明する。
【００８５】
上述したオントロジーを用いたサービス記述を行うことによって、Ｗｅｂサービスの入出力、制約条件、事前事後条件に加えて、コメントのような属性を定義し、その属性をオントロジーを指定するようにして記述して、サービス記述に含めることができる。これによれば、サービス記述に適した属性をオントロジーで記述できる。
【００８６】
例えば、属性の要素として、サービスのカテゴリー（個人向け、企業向け、業種など）を、「Ｃａｔｅｇｏｒｙ： ｍａｎｕｆａｃｔｕｒｅｒ＠Ｂｕｓｉｎｅｓｓ＃Ｍａｎｕｆａｃｔｕｒｅｒ」として記述したり、サービスの提供範囲（日本、東京、浜松町など）を「Ｇｅｏｍｅｔｒｙ： ｊｐ＃Ｃｏｕｎｔｒｙ＃Ｊａｐａｎ」として記述したり、サービスのランク（信用情報など）を「Ｒａｔｉｎｇ： ８」として記述したり、サービスの提供者を、「Ｐｒｏｖｉｄｅｒ： ＸＹＺ＠Ｃｏｍｐａｎｙ＃Ｍａｎｕｆａｃｔｕｒｅｒ」として記述したり、サービスの提供方法（オンライン、電話、郵送など）を「Ｍｅｄｉａ： ｏｎｌｉｎｅ＠Ｍｅｄｉａ＃Ｏｎｌｉｎｅ」として記述したりすることができる。いずれも、それぞれの属性が「＠」以下のオントロジーとノードによって記述されているので、Ｗｅｂサービス記述ならではの属性についても、Ｗｅｂサービス検索要求に対してオントロジー辞書を用いた検索を行うことができる。
【００８７】
次に、サービス類似性判定方法の高速化方法について説明する。
【００８８】
サービス間の類似性を比較する処理を高速化するため、オントロジー比較を行う前に、可能性の低いものを排除する前処理（プリチェック）を行う種々の方法について説明する。
【００８９】
最初の方法は、図４のネームスペースプリチェック機能部３１において、オントロジー名を比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、ネームスペースプリチェック機能では、各ノードの属するオントロジーツリー名を参照し、比較するオントロジーツリー名が異なっている場合は、高い確率で類似性がないと判断し、実際のオントロジーのノード比較を行わないことを指定できるようにしたものである。
【００９０】
なお、以下に説明する７つの例では、第１のＳｅｒｖｉｃｅが要求されるサービス、第２のＳｅｒｖｉｃｅが提供されているサービスであり、両者はマッチしないことを示している。
【００９１】
第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ ９は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、
第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １０は、
Ｉｎｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
である。従って、両者のオントロジー名を比較した結果、オントロジー名が異なっているため、類似性が無いと判断される。
【００９２】
第２の方法は、図４のテキストプリチェック機能部３２において、テキストを比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、テキストプリチェック機能では、サービス記述につけられた自然言語によるコメント、説明文などのテキストを参照し、テキストの量が十分であり、かつ、ＴＦＩＤＦ（Ｔｅｒｍ Ｆｒｅｑｕｅｎｃｙ ／ Ｉｎｖｅｒｓｅ Ｄｏｃｕｍｅｎｔ Ｆｒｅｑｕｅｎｃｙ）による類似性が一定のレベル以下であると判断された場合は、高い確率で類似性がないと判断し、入出力や制約条件のオントロジー比較を行わないことを指定できる。
【００９３】
第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １１は、
Ｃｏｍｍｅｎｔ： Ｃａｒ Ｓｅｌｌｉｎｇ
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １２は、
Ｃｏｍｍｅｎｔ： Ｐａｒｔｓ Ｑｕｏｔｉｎｇ
Ｉｎｐｕｔ： ｓｃｒｅｗ＠Ｐａｒｔｓ＃Ｓｃｒｅｗ
であるとする。この場合、両者のコメント等のテキストを比較した結果、一定の条件の下、テキストが予め決められた閾値以上類似していないときは、類似性が無いと判断され、オントロジーを利用した判断を行わない。
【００９４】
第３の方法は、図４の引数プリチェック機能部３３において、引数を比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、引数プリチェック機能では、サービスが入力として必要とする情報（引数）の個数が要求されるサービスのそれより多い場合は、実際のオントロジーの比較を行わないことを指定できる。
【００９５】
例えば、あるサービスｆｕｎｃ（ｘ，ｙ，ｚ） は引数の数が３であり、引数の数が２の要求ｆｕｎｃ（ｘ，ｙ）には、ｚがないので、そのサービスは要求に対応することができない。この様な場合は、オントロジーを利用した判断を行わない。
他の例として、例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １３は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １４は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ， ｎｕｍ＠Ｕｎｉｔ＃ｄｏｚｅｎ
であるとする。この場合も、引数の数が違うので、オントロジーを利用した判断を行わない。
【００９６】
さらに、サービスが出力する情報（返り値）の個数が要求されるサービスのそれより少ない場合は、実際のオントロジーの比較を行わないことを指定できる。例えば、価格を返すサービスは，価格と納期が欲しいという要求には対応不可として、オントロジーを利用した判断を行わない。
【００９７】
さらに他の例として、例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １５は、
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ， ｌｅａｄ＿ｔｉｍｅｓ＠Ｔｉｍｅ＃Ｄａｙｓ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １６は、
Ｏｕｔｐｕｔ： ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
であるとする。この場合も、引数の数が違うので、オントロジーを利用した判断を行わない。
【００９８】
第４の方法は、図４の制約数プリチェック機能部３４において、制約数を比較して類似性が低いものをオントロジー比較の対象から排除するという方法である。すなわち、サービス間の類似性を比較する場合、制約数プリチェック機能では、サービスの制約の個数が要求されるサービスの制約の個数と比べて多いか、少ないかに応じて、実際のオントロジーの比較を行わないことを指定できる。
【００９９】
最初の例として、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １７は、
【０１００】
他の例として、例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ １９は、
【０１０１】
第５の方法は、オントロジー情報の解析、取得、格納機能において、サービス間の類似性を比較する処理を高速化するため、オントロジー記述がＷｅｂ上に存在する場合、オントロジーツリーをプログラミング言語のオブジェクトツリーに変換してローカルディスクまたはメモリ上に保持（キャッシュ）することができるようにしたものである。
【０１０２】
以下の例では、Ｓｅｒｖｉｃｅ ２１を取得し解析した時点で、Ｖｅｈｉｃｌｅオントロジーツリーは内部形式に変換され保持されるため、Ｓｅｒｖｉｃｅ ２２を解析する段階では再度取得を行わない。
【０１０３】
例えば、第１のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ ２１は、
Ｉｎｐｕｔ： ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、第２のＳｅｒｖｉｃｅであるＳｅｒｖｉｃｅ ２２は、
Ｉｎｐｕｔ： ｓｅｄａｎ＠Ｖｅｈｉｃｌｅ＃Ｓｅｄａｎ
であるとする。この場合、Ｓｅｒｖｉｃｅ ２１を取得し解析した時点で、Ｖｅｈｉｃｌｅオントロジーツリーは内部形式に変換され保持されるため、その後は、一定間隔ごとにオントロジーツリーファイルの更新日時を参照し、更新されていれば再度取得するようにする。また、明示的にオントロジーツリーの更新を通知するメッセージまたはイベントを受け取った場合も再度取得する。
【０１０４】
次に、図４のスコア機能部３９におけるサービス類似性判定結果の評価方法について説明する。具体的には、このスコア機能では、サービス類似性判定の結果表示に関して、入出力、制約条件、事前事後条件、サービス属性に対して、ユーザが設定した重要度に応じて重み付けし、総合的な類似度を点数付けして結果をソートすることができるようにしたものである。
【０１０５】
例えば、以下のような３つのサービスＳｅｒｖｉｃｅ ２３、Ｓｅｒｖｉｃｅ ２４、Ｓｅｒｖｉｃｅ ２５があった場合、Ｓｅｒｖｉｃｅ ２３は、
Ｉｎｐｕｔ ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、Ｓｅｒｖｉｃｅ ２４は、
Ｉｎｐｕｔ ｎｅｄａｎ＠Ｃｕｒｒｅｎｃｙ＃Ｙｅｎ
Ｏｕｔｐｕｔ ｃａｒ＠Ｖｅｈｉｃｌｅ＃Ｃａｒ
であり、Ｓｅｒｖｉｃｅ ２５は、
Ｉｎｐｕｔ ｐｒｉｃｅ＠Ｃｕｒｒｅｎｃｙ＃ＵＳＤ
Ｏｕｔｐｕｔ ａｕｔｏ＠Ｖｅｈｉｃｌｅ＃Ａｕｔｏ
であるとする。ここで、Ｃｕｒｒｅｎｃｙ＃ＵＳＤとＣｕｒｒｅｎｃｙ＃Ｙｅｎの距離は１、Ｖｅｈｉｃｌｅ＃ＡｕｔｏとＶｅｈｉｃｌｅ＃Ｃａｒの距離も１であるため、Ｓｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２４の類似度は、Ｓｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２５の類似度と等しいと考えることができる。しかし、ユーザが入力としての通貨の単位を重視するならば、Ｉｎｐｕｔの重要度を高くすることで、Ｓｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２５の類似度をＳｅｒｖｉｃｅ ２３とＳｅｒｖｉｃｅ ２４の類似度よりも高くすることができる。また、その逆も可能である。
【０１０６】
次に、以上の説明したサービス間の類似性判定を実行するための処理の流れについて説明する。
【０１０７】
まず、型類似性判断機能部３５の処理内容について説明する。図１０は、型類似性判断機能の処理の流れの例を示すフローチャートである。
【０１０８】
初めに、判断対象の型がオントロジー指定の型定義か、プログラム言語依存型定義かを判断する（ステップ（以下、Ｓと略す。）１）。オントロジー指定の型定義の場合、処理はＳ２へ移行し、指定オントロジーが外部のものか否かが判断される（Ｓ２）。Ｓ２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ３）。Ｓ２とＳ３でＮＯの場合は、処理はＳ４へ進む。
【０１０９】
Ｓ４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ５）。Ｓ５でＹＥＳならば、Ｓ６の処理へ進み、類似判断基準を設定し（Ｓ６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ７）。Ｓ５においてＮＯの場合は、Ｓ７の処理へ移行する。
【０１１０】
記録されたデータに基づいて類似性が０（ゼロ）であるか否かを判断する（Ｓ８）。Ｓ８でＮＯの場合は、そのまま処理は終了する。Ｓ８でＹＥＳの場合は、型が構造を持つか否かを判断し（Ｓ９）、Ｓ９でＹＥＳならば、型の各要素について、本手段を再帰的に適用する（Ｓ１０）。Ｓ９でＮＯの場合は、そのまま処理は終了する。
【０１１１】
Ｓ１で、判断対象がプログラム言語依存型定義であると判断されると、Ｓ１１の処理へ移行し、プログラム的変換可能性をチェックし、チェック結果データを記録、すなわちストアし（Ｓ１１）、Ｓ１２の処理へ移行する。Ｓ１２では、型変換可能性があるか否かが判断され、Ｓ１２でＹＥＳならば、そのまま処理は終了する。Ｓ１２でＮＯならば、Ｓ９の処理へ移行する。
【０１１２】
以上のようにして型類似性の判断の処理が実行される。
【０１１３】
次に、制約条件類似性判断機能部３６の処理内容について説明する。図１１は、制約条件類似性判断機能の処理の流れの例を示すフローチャートである。
【０１１４】
初めに、判断対象の制約がオントロジー指定の制約定義か、論理制約定義かを判断する（Ｓ２１）。オントロジー指定の制約定義の場合、処理はＳ２２へ移行し、指定オントロジーが外部のものか否かが判断される（Ｓ２２）。Ｓ２２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ２３）。Ｓ２２とＳ２３でＮＯの場合は、処理はＳ２４へ進む。
【０１１５】
Ｓ２４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ２４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ２５）。Ｓ２５でＹＥＳならば、Ｓ２６の処理へ進み、類似判断基準を設定し（Ｓ２６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ２７）。Ｓ２５においてＮＯの場合は、Ｓ２７の処理へ移行する。
【０１１６】
記録されたデータに基づいて類似性が０（ゼロ）であるか否かを判断する（Ｓ２８）。Ｓ２８でＮＯの場合は、そのまま処理は終了する。Ｓ２８でＹＥＳの場合は、制約が構造を持つか否かを判断し（Ｓ２９）、Ｓ２９でＹＥＳならば、制約の各要素について、本手段を再帰的に適用する（Ｓ３０）。Ｓ２９でＮＯの場合は、そのまま処理は終了する。
【０１１７】
Ｓ２１で、判断対象が論理制約定義であると判断されると、Ｓ３１の処理へ移行し、制約定義のデフォルトオントロジー内に同一名称のルールがあるか否かが判断される（３１）。Ｓ３１でＹＥＳならば、処理はＳ２２へ移行する。Ｓ３１でＮＯの場合は、論理的包括可能性をチェックし、チェック結果データを記録、すなわちストアし（Ｓ３２）、Ｓ３３の処理へ移行する。Ｓ３３では、包括可能性があるか否かが判断され、Ｓ３３でＹＥＳならば、そのまま処理は終了する。Ｓ３３でＮＯならば、Ｓ２９の処理へ移行する。
【０１１８】
以上のようにして制約条件類似性の判断の処理が実行される。
【０１１９】
次に、事前事後条件類似性判断機能部３７の処理内容について説明する。図１２は、事前事後条件類似性判断機能の処理の流れの例を示すフローチャートである。
【０１２０】
初めに、判断対象の事前事後条件がオントロジー指定の事前事後条件定義か、論理事前事後条件定義かを判断する（Ｓ４１）。オントロジー指定の事前事後条件定義の場合、処理はＳ４２へ移行し、指定オントロジーが外部のものか否かが判断される（Ｓ４２）。Ｓ４２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ４３）。Ｓ４２とＳ４３でＮＯの場合は、処理はＳ４４へ進む。
【０１２１】
Ｓ４４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ４４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ４５）。Ｓ４５でＹＥＳならば、Ｓ４６の処理へ進み、類似判断基準を設定し（Ｓ４６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ４７）。Ｓ４５においてＮＯの場合は、Ｓ４７の処理へ移行する。
【０１２２】
記録されたデータに基づいて類似性が０（ゼロ）であるか否かを判断する（Ｓ４８）。Ｓ２８でＮＯの場合は、そのまま処理は終了する。Ｓ２８でＹＥＳの場合は、事前事後条件が構造を持つか否かを判断し（Ｓ４９）、Ｓ４９でＹＥＳならば、事前事後条件の各要素について、本手段を再帰的に適用する（Ｓ５０）。Ｓ４９でＮＯの場合は、そのまま処理は終了する。
【０１２３】
Ｓ４１で、判断対象が論理事前事後条件定義であると判断されると、Ｓ５１の処理へ移行し、事前事後条件定義のデフォルトオントロジー内に同一名称のルールがあるか否かが判断される（５１）。Ｓ５１でＹＥＳならば、処理はＳ４２へ移行する。Ｓ５１でＮＯの場合は、論理的包括可能性をチェックし、チェック結果データを記録、すなわちストアし（Ｓ５２）、Ｓ５３の処理へ移行する。Ｓ５３では、包括可能性があるか否かが判断され、Ｓ５３でＹＥＳならば、そのまま処理は終了する。Ｓ５３でＮＯならば、Ｓ４９の処理へ移行する。
【０１２４】
以上のようにして事前事後条件類似性の判断の処理が実行される。
【０１２５】
次に、属性類似性判断機能部３８の処理内容について説明する。図１３は、属性類似性判断機能の処理の流れの例を示すフローチャートである。
【０１２６】
初めに、定義されている属性名称の一つに着目、すなわち選択し（Ｓ６１）、指定オントロジーが外部のものか否かが判断される（Ｓ６２）。Ｓ６２でＹＥＳならば、そのオントロジーがキャッシュに存在するか否かが判断される（Ｓ６３）。Ｓ６２とＳ６３でＮＯの場合は、処理はＳ６４へ進む。
【０１２７】
Ｓ６４では、オントロジーのデータを読み込み、内部表現に変換してキャッシュに登録する（Ｓ６４）。次に、類似判断基準の指定があるか否かが判断される（Ｓ６５）。Ｓ６５でＹＥＳならば、Ｓ６６の処理へ進み、類似判断基準を設定し（Ｓ６６）、次に類似性を評価し、オントロジーノード間の距離と評価計算時間のデータを記録すなわちストアする（Ｓ６７）。Ｓ６５においてＮＯの場合は、Ｓ６７の処理へ移行する。そして、定義されている属性全てについてチェックしたか否かが判断され（Ｓ６８）、ＹＥＳならば処理は終了し、ＮＯであれば、未処理の属性にも同様の処理を行うべく、Ｓ６１の処理へ移行する。
【０１２８】
以上のようにして属性類似性の判断の処理が実行される。
【０１２９】
本明細書における各「部」は、実施の形態の各機能に対応する概念的なもので、必ずしも特定のハードウエアやソフトウエア・ルーチンに１対１には対応しない。従って、本明細書では、以下、実施の形態の各機能を有する仮想的回路ブロック（部）を想定して実施の形態を説明する。また、本実施の形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、あるいは実行毎に異なった順序で実行してもよい。
【０１３０】
以上説明したように、本実施の形態によれば、サービス記述に、入出力の型、制約条件内の要素、事前条件内の要素、又は事後条件内の要素に対して、オントロジーを指定できるので、入出力の指定や、入出力に関する制約条件、事前条件、又は事後条件などを伴う特定機能を呼び出すためのインターフェースについて、異なる２サービスが類似しているかどうかを判断することができる。
【０１３１】
本実施の形態によれば、オントロジーを、従来のように文書理解における単語間の距離の測定に使うだけでなく、Ｗｅｂサービス記述において、型の判断、条件の論理判断、引数の順序判断を行うために、数学的な型に含ませてより複雑な構造体を作ったり、制約条件に含ませて条件記述に拡張性を持たせたり、関係述語が引数の順序を重視するかどうかの定義に含ませて使用することができる。
【０１３２】
なお、以上説明した動作を実行するプログラムは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶装置等に、その全体あるいは一部が記録され、あるいは記憶されている。そのプログラムがコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を通信ネットワークを介して流通または提供することができる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のサービス情報提供装置を実現することができる。
【０１３３】
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。
【０１３４】
【発明の効果】
以上説明したように、本発明によれば、プログラム言語に関わる情報項目の中に現れる用語に関しても、類義語の判断などオントロジー技術を適用するための仕組みを有するサービス情報提供装置を実現することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係わるＷｅｂサービス検索システムの構成を示す構成図である。
【図２】本実施の形態に係わるウエブサーバのサービス検索機能部の構成を示す機能ブロック図である。
【図３】本実施の形態に係わるサービス記述解析機能部の構成を示す機能ブロック図である。
【図４】本実施の形態に係わるサービス類似性判断機能部の構成を示す機能ブロック図である。
【図５】本実施の形態に係わる型類似性判断機能部の機能を示す機能ブロック図である。
【図６】本実施の形態に係わる制約条件類似性判断機能部の機能を示す機能ブロック図である。
【図７】Ｗｅｂサービスのサービス記述の例を示す図である。
【図８】Ｗｅｂサービスの入出力、制約条件、事前事後条件等のそれぞれの参照先を記述したＷｅｂサービス記述の例を示す図である。
【図９】入力項目の参照先における記述の例を示す図である。
【図１０】型類似性判断機能の処理の流れの例を示すフローチャートである。
【図１１】制約条件類似性判断機能の処理の流れの例を示すフローチャートである。
【図１２】事前事後条件類似性判断機能の処理の流れの例を示すフローチャートである。
【図１３】属性類似性判断機能の処理の流れの例を示すフローチャートである。
【符号の説明】
１・・・ウエブサーバ
２・・・ＰＣ
３・・・インターネット
４・・・サービス提供装置
５、６・・・メモリ装置
Claims (29)
- ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、前記サービスの情報を提供するサービス情報提供装置であって、
前記サービス記述は、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されていることを特徴とするサービス情報提供装置。 - 前記オントロジーの指定は、オントロジーツリー名とノード名の組合わせによって行われることを特徴とする請求項１に記載のサービス情報提供装置。
- 前記サービス記述内の個々の要素に対して別々のオントロジー指定がされることを特徴とする請求項１又は請求項２に記載のサービス情報提供装置。
- 前記サービス記述内の一つの要素に対して複数のオントロジー指定がされることを特徴とする請求項１、請求項２又は請求項３に記載のサービス情報提供装置。
- 前記入出力の型、前記制約条件及び前記事前事後条件のうち少なくとも一つにデフォルトのオントロジー指定がされることを特徴とする請求項１から請求項４のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記入出力の型、前記制約条件及び前記事前事後条件の少なくとも一つについての比較において、前記オントロジーツリーの検索範囲を、親方向、子方向、同一の親若しくは祖先を有する兄弟方向及び同一関係の少なくとも一つを選択し、かつ距離をノード数又は検索時間で指定するようにしたことを特徴とする請求項１から請求項５のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジツリー内のノードを検索する前に、前記ノードの属するオントロジーツリー名が異なっている場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２から請求項６のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービス記述につけられたテキストの量が予め決められた閾値よりも多いと判断された場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２から請求項７のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスが入力として必要とする情報の個数が要求される前記サービスの情報の個数より多い場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２から請求項８のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスが出力する情報の個数が要求される前記サービスの情報の個数より少ない場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２から請求項９のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスの前記制約条件のうち入力制約の個数が要求される前記サービスの前記制約条件のうち入力制約の個数より多いときは、前記類似性の判定を行わないように指定できることを特徴とする請求項２から請求項１０のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスの前記制約条件のうち出力制約の個数が要求される前記サービスの前記制約条件のうち出力制約の個数より少ないときは、前記類似性の判定を行わないように指定できることを特徴とする請求項２から請求項１１のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、２つの前記サービスにおける前記入出力の型を比較するとき、型定義を再帰的に分解して、数学的な型判断手段と前記オントロジー類似性を判断するオントロジー類似性判断手段とが再帰的に実行されることを特徴とする請求項１から請求項１２のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、２つの前記サービスにおける前記制約条件を比較するとき、前記制約条件を再帰的に分解して、前記制約条件の論理的な包摂関係判定手段と前記オントロジー類似性を判断するオントロジー類似性判断手段とが再帰的に実行されることを特徴とする請求項１から請求項１３のいずれかに記載のサービス情報提供装置。
- 前記サービス記述は、前記サービスの属性である前記サービスのカテゴリー、前記サービスの提供範囲、前記サービスのランク、前記サービスの提供者、前記サービスの提供方法のいずれかのデータを含み、前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供することを特徴とする請求項１から請求項１４のいずれかに記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記入出力、前記制約条件、前記事前事後条件及び前記属性に対して、重要度に応じた重み付けをして、前記類似性の判定し、前記判定の結果をソートして出力することを特徴とする請求項１５に記載のサービス情報提供装置。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記２つのサービスにおける前記制約条件を比較するときに、引数の順序を無視して比較するか、順序どおりに比較するかを切り替える述語の前記オントロジーを参照して、前記比較が行われることを特徴とする請求項１から請求項１６のいずれかに記載のサービス情報提供装置。
- 前記オントロジーの記述データがネットワーク上に存在する場合は、前記オントロジーのデータをプログラミング言語のオブジェクトツリーに変換して、ローカルディスクまたはメモリ上に保持することを特徴とする請求項１から請求項１７のいずれかに記載のサービス情報提供装置。
- さらに、前記オントロジーのデータが、前記ネットワーク上のデータ更新日時を参照して更新されていなければ前記ローカルディスクまたは前記メモリを使用し，更新されていれば再度前記ネットワークを介して取得することを特徴とする請求項１８に記載のサービス情報提供装置。
- 前記サービス記述において、前記入出力に関する記述形式と、前記制約条件に関する記述形式と、前記事前事後条件に関する記述形式と、前記オントロジーの記述形式をそれぞれ独立した特定の言語に依存しない形式で記述されていることを特徴とする請求項１に記載のサービス情報提供装置。
- ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述を有して、前記サービスの情報を提供するサービス情報提供方法であって、
前記サービス記述は、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されていることを特徴とするサービス情報提供方法。 - 前記オントロジーの指定は、オントロジーツリー名とノード名の組合わせによって行われることを特徴とする請求項２１に記載のサービス情報提供方法。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーのツリー内のノードを検索する前に、前記ノードの属するオントロジーツリー名称が異なっている場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２２に記載のサービス情報提供方法。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービス記述につけられたテキストの量が予め決められた閾値よりも多く、かつ前記テキストの類似性が予め決められた閾値よりも低いと判断された場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２２又は請求項２３に記載のサービス情報提供方法。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスが入力として必要とする情報の個数が要求される前記サービスの情報の個数より多い場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２２、請求項２３又は請求項２４に記載のサービス情報提供方法。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスが出力する情報の個数が要求される前記サービスの情報の個数より少ない場合は、前記類似性の判定を行わないように指定できることを特徴とする請求項２２から請求項２５のいずれかに記載のサービス情報提供方法。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスの前記制約条件のうち入力制約の個数が要求される前記サービスの前記制約条件のうち入力制約の個数より多いときは、前記類似性の判定を行わないように指定できることを特徴とする請求項２２から請求項２６のいずれかに記載のサービス情報提供方法。
- 前記オントロジーに基づいて２つの前記サービス記述間の類似性を判定して、前記サービスの情報を提供する場合に、前記オントロジーツリー内のノードを検索する前に、前記サービスの前記制約条件のうち出力制約の個数が要求される前記サービスの前記制約条件のうち出力制約の個数より少ないときは、前記類似性の判定を行わないように指定できることを特徴とする請求項２２から請求項２７のいずれかに記載のサービス情報提供方法。
- ネットワーク上に存在するサービスプログラムが提供するサービスの内容を記述したサービス記述のデータを有して、
前記サービス記述のデータは、前記サービスプログラムにおける、入出力の型、制約条件内の要素、事前条件内の要素、及び事後条件内の要素の少なくとも一つに対して、オントロジーが指定されているデータが記録されたコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002283974A JP2004118722A (ja) | 2002-09-27 | 2002-09-27 | サービス情報提供装置、サービス情報提供方法及び記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002283974A JP2004118722A (ja) | 2002-09-27 | 2002-09-27 | サービス情報提供装置、サービス情報提供方法及び記録媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004118722A true JP2004118722A (ja) | 2004-04-15 |
Family
ID=32277683
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002283974A Pending JP2004118722A (ja) | 2002-09-27 | 2002-09-27 | サービス情報提供装置、サービス情報提供方法及び記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004118722A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013140767A1 (ja) * | 2012-03-23 | 2013-09-26 | 日本電気株式会社 | コンテキスト処理装置、情報処理装置、コンテキスト処理方法、および、コンピュータ・プログラム |
| JP2014225092A (ja) * | 2013-05-15 | 2014-12-04 | キヤノン株式会社 | 情報処理装置、その制御方法、プログラム |
-
2002
- 2002-09-27 JP JP2002283974A patent/JP2004118722A/ja active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013140767A1 (ja) * | 2012-03-23 | 2013-09-26 | 日本電気株式会社 | コンテキスト処理装置、情報処理装置、コンテキスト処理方法、および、コンピュータ・プログラム |
| JP2014225092A (ja) * | 2013-05-15 | 2014-12-04 | キヤノン株式会社 | 情報処理装置、その制御方法、プログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Elgazzar et al. | Clustering wsdl documents to bootstrap the discovery of web services | |
| US10705796B1 (en) | Methods, systems, and computer program product for implementing real-time or near real-time classification of digital data | |
| US7191185B2 (en) | Systems and methods for facilitating access to documents via an entitlement rule | |
| Medjahed et al. | A multilevel composability model for semantic web services | |
| Sirin et al. | Semi-automatic composition of web services using semantic descriptions | |
| US8014997B2 (en) | Method of search content enhancement | |
| US20070203869A1 (en) | Adaptive semantic platform architecture | |
| US20090210411A1 (en) | Information Retrieving System | |
| US20050131872A1 (en) | Query recognizer | |
| US20020065857A1 (en) | System and method for analysis and clustering of documents for search engine | |
| US20040163043A1 (en) | System method and computer program product for obtaining structured data from text | |
| US20020024532A1 (en) | Dynamic personalization method of creating personalized user profiles for searching a database of information | |
| US20080301092A1 (en) | Geocoding using information retrieval | |
| JP2006525601A (ja) | 概念ネットワーク | |
| JP2001509293A (ja) | 情報検索 | |
| JP2007500903A (ja) | 拡張検索クエリを有するユーザインターフェースを提供するシステム | |
| US6963863B1 (en) | Network query and matching system and method | |
| Abbattista et al. | Improving the usability of an e-commerce web site through personalization | |
| US20040243575A1 (en) | Information searching system | |
| Fensel et al. | What is wrong with Web services Discovery | |
| Kim et al. | Agent based intelligent search framework for product information using ontology mapping | |
| Ben Njima et al. | Development of a mobile web services discovery and composition model | |
| JP2004118722A (ja) | サービス情報提供装置、サービス情報提供方法及び記録媒体 | |
| Vaddi et al. | Webservice specification and discovery | |
| Chen et al. | A web service matching algorithm based on semantic similarity |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060829 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061030 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061205 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070205 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070313 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070514 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070731 |