(57)【要約】【課題】データベースに登録されている値が目的の値なのかどうかを評価できるようにする。【解決手段】評価装置１０は、複数のエンティティそれぞれの特定の特徴を示す値の推定値を取得する。次に評価装置１０は、複数のエンティティのうち、特定の関係情報を辿った先の値が推定値と同じとなるエンティティを第１エンティティとし、特定の関係情報を記憶する。次に評価装置１０は、複数のエンティティのうち、特定の関係情報を辿った先に推定値と異なる値が存在するエンティティを第２エンティティとする。そして評価装置１０は、第１エンティティの数と第２エンティティの数とに基づいて、複数のエンティティそれぞれの推定値と、複数のエンティティそれぞれから特定の関係情報を辿った先に存在する値との一致率を算出する。【選択図】図１
2018060398.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得し、
前記複数のエンティティ、前記複数のエンティティそれぞれの特徴を示す値、および前記複数のエンティティと前記複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、前記複数のエンティティそれぞれを第１候補エンティティとし、いずれかの前記第１候補エンティティから前記関係情報を辿ることで到達可能な値の中に前記第１候補エンティティの第１推定値と同じ値が存在する場合、前記第１推定値と同じ値までに辿った１以上の関係情報を特定の関係情報とし、前記第１候補エンティティから前記特定の関係情報を辿った先の値が前記第１候補エンティティの前記第１推定値と同じとなる前記第１候補エンティティを第１エンティティとし、
前記データベースを参照し、前記複数のエンティティのうちの前記第１エンティティ以外のエンティティそれぞれを第２候補エンティティとし、前記第２候補エンティティから前記特定の関係情報を辿った先に前記第２候補エンティティの第２推定値と異なる値が存在する前記第２候補エンティティを第２エンティティとし、
前記第１エンティティの数と前記第２エンティティの数とに基づいて、前記複数のエンティティそれぞれの前記推定値と、前記複数のエンティティそれぞれから前記特定の関係情報を辿った先に存在する値との一致率を算出する、
処理を実行させる評価プログラム。
【請求項２】
前記コンピュータに、さらに、
前記複数のエンティティの数、前記第１エンティティの数、および前記第２エンティティの数に基づいて、前記複数のエンティティのうち、前記関係情報を辿った位置に値が存在するエンティティの割合を示す存在率を算出する、
処理を実行させる請求項１記載の評価プログラム。
【請求項３】
前記コンピュータに、さらに、
前記複数のエンティティの共通の特徴を示す検索式を取得し、
前記データベースから、前記複数のエンティティ以外で前記検索式にヒットする追加エンティティを検出し、
前記データベースを参照し、前記追加エンティティのうち、前記特定の関係情報を辿った先に値が存在するエンティティを第３エンティティとし、
前記複数のエンティティの数、前記追加エンティティの数、前記第１エンティティの数、前記第２エンティティの数、および第３エンティティの数に基づいて、前記複数のエンティティのうち、前記関係情報を辿った位置に値が存在するエンティティの割合を示す存在率を算出する、
処理を実行させる請求項１記載の評価プログラム。
【請求項４】
前記コンピュータに、さらに、
前記一致率および前記存在率が所定の条件を満たした場合、前記特定の関係情報を、ネットワーク経由で接続された他のコンピュータに通知する、
処理を実行させる請求項２または３記載の評価プログラム。
【請求項５】
前記コンピュータに、さらに、
前記複数のエンティティの共通の特徴を示す検索式と、前記複数のエンティティに関連付けられた値に基づいて、前記複数のエンティティそれぞれの前記特定の特徴を示す値の前記推定値を得るプログラムモジュールとを取得し、
前記推定値の取得では、前記検索式により、前記データベース内の前記複数のエンティティを特定し、前記プログラムモジュールを実行することで、特定した前記複数のエンティティそれぞれの前記推定値を取得する、
処理を実行させる請求項１乃至４のいずれかに記載の評価プログラム。
【請求項６】
コンピュータが、
複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得し、
前記複数のエンティティ、前記複数のエンティティそれぞれの特徴を示す値、および前記複数のエンティティと前記複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、前記複数のエンティティそれぞれを第１候補エンティティとし、いずれかの前記第１候補エンティティから前記関係情報を辿ることで到達可能な値の中に前記第１候補エンティティの第１推定値と同じ値が存在する場合、前記第１推定値と同じ値までに辿った１以上の関係情報を特定の関係情報とし、前記第１候補エンティティから前記特定の関係情報を辿った先の値が前記第１候補エンティティの前記第１推定値と同じとなる前記第１候補エンティティを第１エンティティとし、
前記データベースを参照し、前記複数のエンティティのうちの前記第１エンティティ以外のエンティティそれぞれを第２候補エンティティとし、前記第２候補エンティティから前記特定関係情報を辿った先に前記第２候補エンティティの第２推定値と異なる値が存在する前記第２候補エンティティを第２エンティティとし、
前記第１エンティティの数と前記第２エンティティの数とに基づいて、前記複数のエンティティそれぞれの前記推定値と、前記複数のエンティティそれぞれから前記特定の関係情報を辿った先に存在する値との一致率を算出する、
評価方法。
【請求項７】
エンティティと前記エンティティの特徴を示す値との関連を示す関係情報を記憶する記憶部と、
複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得し、前記複数のエンティティ、前記複数のエンティティそれぞれの特徴を示す値、および前記複数のエンティティと前記複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、前記複数のエンティティそれぞれを第１候補エンティティとし、いずれかの前記第１候補エンティティから前記関係情報を辿ることで到達可能な値の中に前記第１候補エンティティの第１推定値と同じ値が存在する場合、前記第１推定値と同じ値までに辿った１以上の関係情報を、特定の関係情報として前記記憶部に格納し、前記第１候補エンティティから格納された前記特定の関係情報を辿った先の値が前記第１候補エンティティの前記第１推定値と同じとなる前記第１候補エンティティを第１エンティティとし、前記データベースを参照し、前記複数のエンティティのうちの前記第１エンティティ以外のエンティティそれぞれを第２候補エンティティとし、前記第２候補エンティティから格納された前記特定の関係情報を辿った先に前記第２候補エンティティの第２推定値と異なる値が存在する前記第２候補エンティティを第２エンティティとし、前記第１エンティティの数と前記第２エンティティの数とに基づいて、前記複数のエンティティそれぞれの前記推定値と、前記複数のエンティティそれぞれから前記特定の関係情報を辿った先に存在する値との一致率を算出する処理部と、
を有する評価装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、評価プログラム、評価方法、および評価装置に関する。
【背景技術】
【０００２】
ネットワークを介して様々な情報が提供される。提供される情報は、例えばＲＤＦ（Resource Description Framework）の形式で記述される。ＲＤＦは、リソースを記述するための規格である。ＲＤＦで記述されたデータ（ＲＤＦデータ）は、例えばＳＰＡＲＱＬ（Simple Protocol and RDF Query Language）エンドポイントと呼ばれるコンピュータを用いて提供される。ＳＰＡＲＱＬエンドポイントは、ＳＰＡＲＱＬと呼ばれるＲＤＦ問い合わせ言語で記述されたクエリに応じて、ＲＤＦデータの検索や操作を行う。
【０００３】
ＲＤＦデータは、主語、プロパティ（述語）、目的語の各要素の組で表される。このような表現形式を、トリプルと呼ぶ。主語とプロパティはＵＲＩ（Uniform Resource Identifier）で記述される。目的語は、ＵＲＩまたはリテラルで記述される。リテラルとは、例えば文字列や数値である。また、あるトリプルの目的語が他のトリプルの主語となる場合に、ＵＲＩを持たない空白ノードを使用することができる。ＲＤＦデータは、各要素間の関係をグラフで表現することができる。例えばＵＲＩと空白ノードとを円または楕円、リテラルを四角で表し、主語と目的語間の関係を示すプロパティを、円と四角を接続する矢印で表す。
【０００４】
ＲＤＦデータは、アプリケーションソフトウェアの開発者（以下、単に開発者と呼ぶ）によって利用されることがある。開発者は、例えばＳＰＡＲＱＬを用いてＳＰＡＲＱＬエンドポイントから所定のＲＤＦデータを取得し、そのＲＤＦデータに含まれる値を利用した処理を実行するソフトウェアを作成する。このとき、開発者が利用したい値（処理対象ＵＲＩからプロパティパスで辿れる値）が、ＲＤＦデータに含まれていない場合がある。この場合、開発者は、他の値から利用する値を推定するプログラムモジュールを作成し、そのプログラムモジュールで推定した値を利用する。例えば、様々な人物の姓を示す値を利用したいが、ＲＤＦには氏名の値しか含まれていないことがある。この場合、開発者は、氏名から姓を推定するプログラムモジュールを作成する。
【０００５】
値を推定するプログラムモジュールで得られる値には、誤りが含まれる可能性がある。そのため、このプログラムモジュールは暫定的なものである。ＳＰＡＲＱＬエンドポイント内のＲＤＦデータに目的の値が追加された場合、開発者は、暫定的なプログラムモジュールを、ＲＤＦから目的の値を抽出するプログラムモジュールに置き換える。そのためには、ＳＰＡＲＱＬエンドポイント内のＲＤＦデータに目的の値が追加された場合、そのことを、開発者が早期に知ることが重要である。
【０００６】
ＲＤＦデータに目的の値が追加されたことを知るために利用できる技術としては、例えば情報の変化に応じて通知される情報量が適切となる通知条件を設定させる情報変化通知方法がある。またネットワーク・リソースを動的に監視し、ネットワーク・リソースが更新された後にユーザーに通知するシステムも考えられている。また分散記憶環境でグラフデータを記述するトリプルの記憶に関し、トリプルに対してアクセスがあった際に通知等を行うトリガを付与する技術がある。さらにデータグラフを符号化するデータを格納するよう構成されるデータ記憶システムにおいて、イベントハンドラの実行をトリガすることにより、複数のリソースのうちの１つのリソースにおける処理イベントに応答する技術がある。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１５８８６９号公報
【特許文献２】特表２０１２−５２９６８８号公報
【特許文献３】特開２０１３−１７５１８１号公報
【特許文献４】特開２０１５−１５６２０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、従来の技術では、ＲＤＦデータのようなデータを格納するデータベースに対して何らかの値が追加されたことを知ることはできるが、追加された値が、開発者が利用しようとする目的の値なのかどうかを判別することができない。
【０００９】
１つの側面では、本件は、データベースに含まれる値が目的の値なのかどうかを評価できるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
１つの案では、コンピュータに以下の処理を実行させる評価プログラムが提供される。
コンピュータは、複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得する。次にコンピュータは、複数のエンティティ、複数のエンティティそれぞれの特徴を示す値、および複数のエンティティと複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、複数のエンティティそれぞれを第１候補エンティティとし、いずれかの第１候補エンティティから関係情報を辿ることで到達可能な値の中に第１候補エンティティの第１推定値と同じ値が存在する場合、第１推定値と同じ値までに辿った１以上の関係情報を特定の関係情報とし、第１候補エンティティから特定の関係情報を辿った先の値が第１候補エンティティの第１推定値と同じとなる第１候補エンティティを第１エンティティとする。さらにコンピュータは、データベースを参照し、複数のエンティティのうちの第１エンティティ以外のエンティティそれぞれを第２候補エンティティとし、第２候補エンティティから特定の関係情報を辿った先に第２候補エンティティの第２推定値と異なる値が存在する第２候補エンティティを第２エンティティとする。そしてコンピュータは、第１エンティティの数と第２エンティティの数とに基づいて、複数のエンティティそれぞれの推定値と、複数のエンティティそれぞれから特定の関係情報を辿った先に存在する値との一致率を算出する。
【発明の効果】
【００１１】
１態様によれば、データベースに含まれる値が目的の値なのかどうかを評価可能となる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態のシステム構成例を示す図である。
【図２】第２の実施の形態のシステム構成例を示す図である。
【図３】本実施の形態に用いるプロパティパス候補通知装置のハードウェアの一構成例を示す図である。
【図４】第２の実施の形態における各装置の機能を示すブロック図である。
【図５】接頭辞の定義例を示す図である。
【図６】ＲＤＦデータベースに格納されているＲＤＦデータの一例を示す図である。
【図７】タプルテーブルの一例を示す図である。
【図８】プロパティパス計算テーブルの一例を示す図である。
【図９】プロパティパス候補テーブルの一例を示す図である。
【図１０】ＲＤＦデータ利用処理の手順の一例を示すフローチャートである。
【図１１】姓の値取得処理の手順の一例を示すフローチャートである。
【図１２】タプル受信処理の手順の一例を示すフローチャートである。
【図１３】更新後のＲＤＦデータの第１の例を示す図である。
【図１４】プロパティパス計算処理の手順の一例を示す図である。
【図１５】同プロパティパス計算処理の手順の一例を示す図である。
【図１６】同プロパティパス計算例を示す第１の図である。
【図１７】同プロパティパス計算例を示す第２の図である。
【図１８】異プロパティパス計算処理の手順の一例を示すフローチャートである。
【図１９】異プロパティパス計算例を示す図である。
【図２０】カバー率・マッチ率計算処理の手順の一例を示すフローチャートである。
【図２１】カバー率・マッチ率の計算例を示す図である。
【図２２】カバー率とマッチ率との意味を概念的に説明する図である。
【図２３】通知処理の手順の一例を示す図である。
【図２４】データ更新ごとのカバー率・マッチ率の計算結果を示す第１の図である。
【図２５】データ更新ごとのカバー率・マッチ率の計算結果を示す第２の図である。
【図２６】プロパティパスの通知判断の例を示す図である。
【図２７】ＲＤＦデータの第２の更新例を示す図である。
【図２８】ＲＤＦデータの第２の更新例に基づくカバー率・マッチ率の計算例を示す図である。
【図２９】ＲＤＦデータの第２の更新例におけるデータ更新ごとのカバー率・マッチ率の計算結果を示す第１の図である。
【図３０】ＲＤＦデータの第２の更新例におけるデータ更新ごとのカバー率・マッチ率の計算結果を示す第２の図である。
【図３１】ＲＤＦデータの第２の更新例におけるプロパティパスの通知判断の例を示す図である。
【図３２】ＲＤＦデータの第３の更新例を示す図である。
【図３３】ＲＤＦデータの第３の更新例に基づくカバー率・マッチ率の計算例を示す図である。
【図３４】ＲＤＦデータの第３の更新例におけるデータ更新ごとのカバー率・マッチ率の計算結果を示す図である。
【図３５】ＲＤＦデータの第３の更新例におけるプロパティパスの通知判断の例を示す図である。
【図３６】第３の実施の形態における各装置の機能を示すブロック図である。
【図３７】検索式テーブルの一例を示す図である。
【図３８】追加ＵＲＩテーブルの一例を示す図である。
【図３９】受信処理の手順の一例を示すフローチャートである。
【図４０】第３の実施の形態におけるプロパティパス計算処理の手順の一例を示すフローチャートである。
【図４１】不明プロパティパス計算処理の手順の一例を示すフローチャートである。
【図４２】不明プロパティパス計算処理の結果の一例を示す図である。
【図４３】第３の実施の形態におけるカバー率・マッチ率計算処理の手順の一例を示すフローチャートである。
【図４４】カバー率・マッチ率の計算例を示す図である。
【図４５】第２の実施の形態と第３の実施の形態とのカバー率・マッチ率の第１の比較例を示す図である。
【図４６】ＲＤＦデータに追加された値の数が少ない場合のプロパティパス計算テーブルの例を示す図である。
【図４７】第２の実施の形態と第３の実施の形態とのカバー率・マッチ率の第２の比較例を示す図である。
【図４８】第４の実施の形態における各装置の機能を示すブロック図である。
【図４９】検索式・モジュールテーブルの一例を示す図である。
【図５０】一時ＵＲＩテーブルの一例を示す図である。
【図５１】第４の実施の形態における受信処理の手順の一例を示すフローチャートである。
【図５２】第４の実施の形態におけるプロパティパス計算処理の手順の一例を示すフローチャートである。
【図５３】タプルテーブル生成処理の手順の一例を示すフローチャートである。
【図５４】タプルテーブルの生成例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。
【００１４】
図１は、第１の実施の形態のシステム構成例を示す図である。第１の実施の形態のシステムは、データベース１、データ処理装置２、および評価装置１０を有する。データベース１、データ処理装置２、および評価装置１０は、例えばネットワーク経由で接続されている。
【００１５】
データベース１は、複数のエンティティと、複数のエンティティそれぞれの特徴を示す値とを、関係情報で関連付けて記憶している。エンティティは、例えばデータベース１によって表現する対象の要素（人・物・場所・事象・概念・サービスなど）である。データベース１には、例えばＲＤＦデータが格納される。その場合、トリプルの主語がエンティティである。エンティティは、例えばＵＲＩで表現される。図１の例では、「ex:P101」、「ex:P102」などがエンティティを表している。
【００１６】
データ処理装置２は、データベース１内のデータを用いたデータ処理を行うコンピュータである。データ処理装置２は、例えばエンティティの特徴を示す値を用いて、統計処理などを行う。データ処理装置２にデータ処理を実行させるプログラムの開発者は、データ処理に利用しようとする目的の値がデータベースに含まれていない場合、他の値から目的の値を推定するプログラムモジュールを作成する。例えば開発者は、人物の氏名から姓を推定するプログラムモジュールを作成する。そして開発者は、データ処理のプログラムに、値を推定するプログラムモジュールを組み込み、データ処理装置２に実行させる。
【００１７】
評価装置１０は、データベース１と特定の関係情報で関連付けられた先に登録された値が、データ処理装置２が推定した値に対応する値かどうかを評価する。評価を行うために、評価装置１０は、処理部１１と記憶部１２とを有する。
【００１８】
処理部１１は、記憶部１２へのデータの格納および記憶部１２からのデータの読み出しを行いながら、データベース１に、エンティティに関連付けて登録された値が、データ処理装置２が推定した値に対応する値かどうかを評価する評価値を算出する。記憶部１２は、エンティティとエンティティの特徴を示す値との関連を示す関係情報などの、処理部１１が利用するデータを記憶する。
【００１９】
具体的には、処理部１１は、まず複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得する。例えばデータ処理装置２が、データ処理装置２で推定された、複数のエンティティの推定値を、評価装置１０に送信する。送信された推定値を、処理部１１が取得する。
【００２０】
次に処理部１１は、データベース１を参照し、複数のエンティティそれぞれを第１候補エンティティとする。第１候補エンティティは、推定値と同じ値が関連付けられているエンティティ（第１エンティティ）の候補である。処理部１１は、いずれかの第１候補エンティティから関係情報を辿ることで到達可能な値の中に第１候補エンティティの推定値（第１推定値）と同じ値が存在する場合、第１推定値と同じ値までに辿った１以上の関係情報を特定の関係情報とする。さらに処理部１１は、データベース１を参照し、複数の第１候補エンティティのうち、第１候補エンティティから特定の関係情報を辿った先の値が第１候補エンティティの第１推定値と同じとなる場合、その第１候補エンティティを第１エンティティとする。この際、処理部１１は、記憶部１２に特定の関係情報を格納する。例えば、データ処理装置２がデータベース１内のデータを利用したデータ処理を実施した後、データベースに、エンティティと関連付けた値が新規に追加された場合に、第１エンティティが検出される。
【００２１】
その後、処理部１１は、データベース１を参照し、複数のエンティティのうちの第１エンティティ以外のエンティティを第２候補エンティティとする。第２候補エンティティは、特定の関係情報を辿った位置に推定値と異なる値が関連付けられているエンティティ（第２エンティティ）の候補である。処理部１１は、第２候補エンティティから特定の関係情報を辿った先に第２候補エンティティの推定値（第２推定値）と異なる値が存在する場合、第２候補エンティティを第２エンティティとする。
【００２２】
さらに処理部１１は、評価値を算出する。評価値には、例えば一致率や存在率がある。例えば処理部１１は、第１エンティティの数と第２エンティティの数とに基づいて、複数のエンティティそれぞれの推定値と、複数のエンティティそれぞれから特定の関係情報を辿った先に存在する値との一致率を算出する。また処理部１１は、値の推定が行われたエンティティの数、第１エンティティの数、および第２エンティティの数に基づいて、複数のエンティティのうち、関係情報を辿った位置に値が存在するエンティティの割合を示す存在率を算出してもよい。
【００２３】
そして処理部１１は、一致率および存在率が所定の条件を満たした場合、特定の関係情報を、データ処理装置２に通知する。例えば処理部１１は、一致率が所定の一致率閾値以上であり、かつ存在率が所定の存在率閾値以上の場合に、通知を行う。通知には、例えば、記憶部１２に記憶している関係情報に示される位置に、データ処理装置２で推定した値に対応する値（開発者が利用しようとする目的の値）が存在する可能性があることが示される。
【００２４】
このような評価装置１０は、例えばデータ処理装置２から複数の人物の姓の値の推定値を取得すると、その推定値をエンティティに対応付けて記憶部１２に格納する。次に評価装置１０は、姓の推定値と同じ値が特定の関係情報の先に存在するエンティティを、データベース１から検索し、ヒットしたエンティティを第１エンティティとする。例えばエンティティ「ex:P101」には、関係情報「ex:姓」で関連付けられた「Ａ山」という値が存在する。この値は、記憶部１２にエンティティ「ex:P101」に対応付けて記憶されている推定値「Ａ山」と一致する。そこで処理部１１は、エンティティ「ex:P101」を第１エンティティとすると共に、関係情報「ex:姓」を記憶部１２に格納する。図１の例では、関係情報「ex:姓」の先に推定値と同じ値が存在するエンティティが、エンティティ「ex:P101」以外に２つ見つかったものとする。その結果、第１エンティティは３つとなる。
【００２５】
その後、処理部１１は、第１エンティティ以外で、エンティティから関係情報「ex:姓」を辿った先に、そのエンティティの推定値と異なる値が存在するエンティティを検索し、ヒットしたエンティティを第２エンティティとする。図１の例ではエンティティ「ex:P102」から関係情報「ex:姓」を辿った先に「Ａ山」という値が存在する。この値は、記憶部１２に、エンティティ「ex:P102」に対応付けて登録されている推定値「Ａ山田」と異なる。そこで処理部１１は、エンティティ「ex:P102」を第２エンティティとする。図１の例では、第２エンティティは、エンティティ「ex:P102」のみであるものとする。
【００２６】
なおエンティティ「ex:P105」は、関係情報「ex:姓」を辿った先に値が存在していないため、第１エンティティでも第２エンティティでもない。
その後、処理部１１は一致率と存在率とを計算する。一致率は、例えば第１エンティティの数を、第１エンティティの数と第２エンティティの数との合計値で除算した値である。図１の例では、一致率は「３／４」である。存在率は、例えば第１エンティティの数と第２エンティティの数との合計値を、値の推定が行われたエンティティの数で除算した値である。図１の例では、存在率は「４／５」である。
【００２７】
処理部１１は、例えば一致率と存在率との両方が閾値以上であれば、関係情報「ex:姓」をデータ処理装置２に通知する。データ処理装置２では、通知を受け取ることで、データベース１に姓の値が登録されていることを認識する。そこでデータ処理装置２におけるプログラムの開発者は、姓の値を推定するプログラムモジュールを、データベース１から姓の値を抽出するプログラムモジュールに置き換える。これによりデータ処理装置２では、推定値より信頼性の高い値を用いたデータ処理を実施することができる。
【００２８】
このように、評価装置１０でデータベース１内の値を評価することで、例えばデータベース１に新たに追加された値が、データ処理装置２で処理に利用しようとする目的の値であるかどうかを評価することができる。そして高い評価が得られた場合、その値がデータベース１にあることを評価装置１０が通知することで、データ処理装置２のプログラムの開発者は、データベース１の更新を常に監視することなく、利用する目的の値が追加されたことを知ることができる。その結果、開発者の監視負担が軽減される。
【００２９】
すなわちデータベース１内に新たな値が追加されるごとにそのことが開発者に通知されると、開発者は、通知がある度に、追加された値が、利用しようとする目的の値か否かを判断することとなり、負担が過大となる。それに対して、第１の実施の形態の評価装置１０は、データベース１内の値が、開発者が利用しようとする目的の値であるかどうかについて、高い評価が得られたときにのみ通知を行う。そのため、開発者の負担が軽減される。
【００３０】
さらに評価値として一致率だけでなく存在率を用いることで、データベース１に開発者が利用しようとする目的の値が、統計的な処理で利用できる十分な量追加されたときに、その旨が通知される。その結果、無駄な通知がさらに抑制される。
【００３１】
なお無駄な通知の抑制は、データ処理装置２、評価装置１０の処理負荷の軽減、およびデータ処理装置２と評価装置１０の間のネットワークの負荷の軽減にもなる。例えばデータベース１の利用者全員に、所望の値が追加されたことの通知サービスを行う場合を想定すると、利用者の数が多くなるほど、無駄な通知を抑止することによる評価装置１０の処理負荷の軽減効果が高くなる。
【００３２】
なお処理部１１は、十分な量の推定値が取得できない場合を想定し、さらに以下の処理を行うこともできる。
処理部１１は、推定値が取得できたエンティティの共通の特徴を示す検索式を取得する。次に処理部１１は、データベース１から、推定値が取得できたエンティティ以外で検索式にヒットする追加エンティティを検出する。さらに処理部１１は、データベース１を参照し、追加エンティティのうち、特定の関係情報を辿った先に値が存在するエンティティを第３エンティティとする。そして処理部１１は、複数のエンティティの数、追加エンティティの数、第１エンティティの数、第２エンティティの数、および第３エンティティの数に基づいて、存在率を算出する。例えば処理部１１は、第１エンティティの数、第２エンティティの数、および第３エンティティの数の合計値を、複数のエンティティの数と追加エンティティの数との合計値で除算した値を、存在率とする。
【００３３】
このように検索式を用いて追加エンティティと第３エンティティとを検出して、存在率を計算することで、十分な量のエンティティに対する推定値が取得できていない場合でも、信頼性の高い存在率を算出することができる。
【００３４】
処理部１１は、さらに外部から推定値を取得することが困難な場合を想定し、以下の処理を行うこともできる。
処理部１１は、複数のエンティティの共通の特徴を示す検索式と、複数のエンティティに関連付けられた値に基づいて、複数のエンティティそれぞれの特定の特徴を示す値の推定値を得るプログラムモジュールとを取得する。そして処理部１１は、推定値の取得では、検索式により、データベース内の複数のエンティティを特定し、プログラムモジュールを実行することで、特定した複数のエンティティそれぞれの推定値を取得する。
【００３５】
このように処理部１１自身がプログラムモジュールを用いて推定値を算出することで、データ処理装置２から推定値を取得しなくても、信頼性の高い一致率を計算することができる。
【００３６】
なお処理部１１は、例えば評価装置１０が有するプロセッサにより実現することができる。また、記憶部１２は、例えば評価装置１０が有するメモリまたはストレージ装置により実現することができる。
【００３７】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ＳＰＡＲＱＬエンドポイント内のＲＤＦデータに追加された値が、開発者が利用したい目的の値かどうかを評価し、所定値以上の評価が得られた場合、目的の値が追加されたことを開発者に通知するものである。
【００３８】
なお第２の実施の形態では、第１の実施の形態における一致率を「マッチ率」と呼ぶこととする。また第１の実施の形態における存在率を「カバー率」と呼ぶこととする。
図２は、第２の実施の形態のシステム構成例を示す図である。第２の実施の形態では、ネットワーク２０を介して、プロパティパス候補通知装置１００、端末装置２００、およびＳＰＡＲＱＬエンドポイント３００が接続されている。
【００３９】
プロパティパス候補通知装置１００は、ＳＰＡＲＱＬエンドポイント３００内のＲＤＦデータへの値の追加を監視し、追加された値が、開発者が利用したい目的の値かどうかを評価するコンピュータである。プロパティパス候補通知装置１００は、追加された値の評価値が所定値以上であれば、その値のＲＤＦデータ内での位置を示すプロパティパスを、端末装置２００に通知する。
【００４０】
端末装置２００は、開発者がアプリケーションソフトウェアの開発に利用するコンピュータである。ＳＰＡＲＱＬエンドポイント３００は、ＲＤＦデータを保持し、そのＲＤＦデータをネットワーク２０経由で提供するコンピュータである。
【００４１】
図３は、本実施の形態に用いるプロパティパス候補通知装置のハードウェアの一構成例を示す図である。プロパティパス候補通知装置１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
【００４２】
メモリ１０２は、プロパティパス候補通知装置１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションソフトウェアの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
【００４３】
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。
【００４４】
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションソフトウェア、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
【００４５】
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
【００４６】
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００４７】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００４８】
機器接続インタフェース１０７は、プロパティパス候補通知装置１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
【００４９】
ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
【００５０】
以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した装置も、図３に示したプロパティパス候補通知装置１００と同様のハードウェアにより実現することができる。
【００５１】
プロパティパス候補通知装置１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。プロパティパス候補通知装置１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、プロパティパス候補通知装置１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またプロパティパス候補通知装置１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【００５２】
図４は、第２の実施の形態における各装置の機能を示すブロック図である。プロパティパス候補通知装置１００は、記憶部１１０、受信部１２０、プロパティパス計算部１３０、および通知部１４０を有する。
【００５３】
記憶部１１０は、開発者が利用しようとする目的の値のプロパティパスの特定に用いるデータを記憶する。記憶部１１０としては、例えばメモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。例えば記憶部１１０には、タプルテーブル１１１、プロパティパス計算テーブル１１２、およびプロパティパス候補テーブル１１３が格納される。タプルテーブル１１１は、開発者が利用しようとする目的の値の推定値を、タプルとして登録するデータテーブルである。プロパティパス計算テーブル１１２は、ＲＤＦデータごとの、追加された値の評価内容を登録するデータテーブルである。プロパティパス候補テーブル１１３は、ＲＤＦデータ内のプロパティパスで示される位置の値が、開発者が利用しようとする目的の値であるかどうかの評価値を登録するデータテーブルである。なお、各データテーブルの詳細は、後述する（図７〜図９参照）。
【００５４】
受信部１２０は、端末装置２００から送信された「ラベル−ＵＲＩ−値タプル」を受信し、タプルテーブル１１１に登録する。タプルは、サンプルとして開発者によって指定される。
【００５５】
プロパティパス計算部１３０は、ＲＤＦデータ内のプロパティパスで示される位置の値が、開発者が利用しようとする目的の値であるかどうかの評価値を計算する。例えばプロパティパス計算部１３０は、定期的（１日１回など）またはＳＰＡＲＱＬエンドポイント３００におけるデータ更新の度に、評価値を計算する。プロパティパス計算部１３０は、同プロパティパス計算部１３１、異プロパティパス計算部１３２、およびカバー率・マッチ率計算部１３３を有する。
【００５６】
同プロパティパス計算部１３１は、タプルテーブル１１１のタプルごとに、タプルに示されるＵＲＩから、タプルに示される値まで、何らかのプロパティパスで辿れるか調べる。同プロパティパス計算部１３１は、値まで辿れるプロパティパスがある場合、そのプロパティパスに関する情報を「同」としてプロパティパス計算テーブル１１２に登録する。
【００５７】
異プロパティパス計算部１３２は、プロパティパス計算テーブル１１２に登録されたプロパティパスと、タプルテーブル１１１中のタプルごとに、タプルに示されるＵＲＩからプロパティパスを辿った先に値があるか調べる。値が存在し、その値がタプルに示される値と異なる場合、異プロパティパス計算部１３２は、そのプロパティパスに関する情報を「異」としてプロパティパス計算テーブル１１２に登録する。
【００５８】
カバー率・マッチ率計算部１３３は、プロパティパス計算テーブル１１２に登録されたプロパティパスごとに、プロパティパスの登録割合（カバー率）と「同」の割合（マッチ率）を計算する。カバー率・マッチ率計算部１３３は、計算したカバー率とマッチ率とを、プロパティパス候補テーブル１１３に登録する。カバー率・マッチ率計算部１３３が計算したカバー率とマッチ率とは、プロパティパスを辿った位置にある値が、開発者が利用しようとする目的の値かどうかの評価値の一例である。カバー率とマッチ率との計算方法の詳細は後述する。
【００５９】
通知部１４０は、プロパティパス候補テーブル１１３を参照し、カバー率とマッチ率とが閾値以上のプロパティパスを検出する。そして通知部１４０は、検出したプロパティパスを、開発者が使用する端末装置２００に通知する。
【００６０】
端末装置２００は、ＲＤＦデータ利用部２１０、送信部２２０、および取得部２３０を有する。
ＲＤＦデータ利用部２１０は、ＳＰＡＲＱＬエンドポイント３００が有するＲＤＦデータを利用して処理を実行する。ＲＤＦデータ利用部２１０は、例えば開発者が作成したアプリケーションソフトウェアを端末装置２００で実行することにより実現する機能である。
【００６１】
送信部２２０は、ＲＤＦデータ利用部２１０においてＲＤＦデータ内の値から推定した値を含むタプルを、プロパティパス候補通知装置１００に送信する。例えば送信部２２０は、開発者からの手動操作によって入力された値を含むタプルを送信する。また送信部２２０は、ＲＤＦデータ利用部２１０から推定した値を取得し、その値を含むタプルを送信する。
【００６２】
取得部２３０は、プロパティパス候補通知装置１００から通知されたプロパティパスを取得する。取得部２３０は、取得されたプロパティパスを、例えばモニタに表示する。
ＳＰＡＲＱＬエンドポイント３００は、ＲＤＦデータ提供部３１０とＲＤＦデータベース３２０とを有する。ＲＤＦデータ提供部３１０は、端末装置２００からのクエリに応じて、ＲＤＦデータベース３２０内のＲＤＦデータの検索や操作を行う。ＲＤＦデータベース３２０は、ＲＤＦデータを記憶する。
【００６３】
なお、図４に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図４に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
【００６４】
以下、本実施の形態で使用するＲＤＦデータについて説明する。以下の説明は、本実施の形態の開示に用いるＲＤＦデータの仕様について記載するものであり、記載していない仕様を使用したＲＤＦデータに対する本実施の形態の処理の適用を妨げるものではない。
【００６５】
ＲＤＦデータは、主語、プロパティ、目的語の組（トリプル）で表されている。主語とプロパティは、ＵＲＩで表される。目的語は、ＵＲＩかリテラルで表される。目的語のＵＲＩは他のＲＤＦデータの主語にもなりうる。目的語のリテラルとしては、例えば文字列や数値が使用される。本実施の形態の例においては、リテラルとして文字列のみを使用し、以降ではリテラルという用語の代わりに文字列という用語を用いて説明する。
【００６６】
ＵＲＩは、「http://...」という表記の識別子である。ＵＲＩは、物や概念を示す要素に対して付与される。以下の説明では、簡単のため、ＵＲＩとして「http://...」という表記に代えて、Turtle構文で使用される、接頭辞を用いた省略表記を使用する。具体的には、ＵＲＩを「ex:P101」「ex:氏名」のように表記する。Turtle構文では、例えば、接頭辞「ex」が、実際には「@prefix ex: <http://localhost/example/> .」と定義されている。すなわち、ＵＲＩ「ex:P101」は実際には「http://localhost/example/P101」であり、ＵＲＩ「ex:氏名」は実際には「http://localhost/example/氏名」である。
【００６７】
また、一般的に用いられる「rdf:type」(型を表す)、「owl:sameAs」（同一性を表す）を本件でも用いる。これらで使用される接頭辞「rdf」「owl」と上記接頭辞「ex」がまとめて、図５のように定義されているとする。
【００６８】
図５は、接頭辞の定義例を示す図である。図５に示すように、各接頭辞に対する実際のＵＲＩを、ＲＤＦデータを取り扱う装置内に定義しておくことで、その装置内では、ＲＤＦデータに含まれる要素のＵＲＩを接頭辞を用いて簡略表記できる。
【００６９】
また、あるトリプルの目的語が他のトリプルの主語となる場合に、ＵＲＩを持たない空白ノードを使用することができる。
図６は、ＲＤＦデータベースに格納されているＲＤＦデータの一例を示す図である。図６の例では、ＲＤＦデータベース３２０内のＲＤＦデータが、グラフ３２１〜３２５で表されている。グラフ３２１〜３２５では、主語または目的語のＵＲＩを楕円で表し、目的語の文字列を四角で表し、ＵＲＩを持たない空白ノードを円で表す。またグラフ３２１〜３２５では、プロパティのＵＲＩを、円または楕円、文字列の各要素間を接続する線で表している。
【００７０】
図６において、グラフ３２１〜３２５にそれぞれ存在する「ex:人物」で表されるＵＲＩは同一ＵＲＩであり一つの楕円として表すべきであるが、見やすさのため別の楕円として表している。
【００７１】
なお本実施の形態の例においては、あるトリプルにおいて主語または目的語として使用されるＵＲＩは他のトリプルにおいてプロパティとして使用されない。また、あるトリプルにおいてプロパティとして使用されるＵＲＩは他のトリプルにおいて主語または目的語として使用されない。しかし、一般的には、任意のＵＲＩは主語、目的語、プロパティのうちいずれの位置にも使用可能であり、そうしたＲＤＦデータに対する本実施の形態の処理の適用を妨げるものではない。
【００７２】
あるＵＲＩから複数のプロパティを介して他のＵＲＩや空白ノードや文字列へ辿れるとき、その複数のプロパティをプロパティパスと呼ぶ。プロパティパスは、「ex:個情/ex:氏名」のように、プロパティを示すＵＲＩの並びで表される。
【００７３】
本実施の形態においては、プロパティパスを辿る元となるＵＲＩをそのプロパティパスの主語と呼び、プロパティパスを辿った先にある他のＵＲＩや空白ノードや文字列をそのプロパティパスの目的語と呼ぶこととする。
【００７４】
次に図７〜図９を参照して、プロパティパス候補通知装置１００内の記憶部１１０に格納される各データテーブルについて、詳細に説明する。
図７は、タプルテーブルの一例を示す図である。タプルテーブル１１１には、ラベル、ＵＲＩ、および値の欄が設けられている。ラベルの欄には、タプルの種別を示すラベルが設定される。開発者が特定の目的で使用するために推定した値には、同じラベルが付与される。ＵＲＩの欄には、タプルに示されているＵＲＩが設定される。値の欄には、タプルに示されている値が設定される。
【００７５】
値の欄に設定されている値は、対応するＵＲＩに示される主語からプロパティパスを辿ることで得られた値に基づいて推定した推定値である。例えば、氏名から推定した姓の文字列が、タプルテーブル１１１の値の欄に設定される。値の欄に設定されている値は、図７では文字列としているが、文字列以外のリテラルでもよいし、ＵＲＩでもよい。
【００７６】
図８は、プロパティパス計算テーブルの一例を示す図である。プロパティパス計算テーブル１１２には、ＵＲＩ、プロパティパス、および同異の欄が設けられている。ＵＲＩの欄には、ＲＤＦデータの主語のＵＲＩが設定される。プロパティパスの欄には、対応するＵＲＩからプロパティを辿る経路を示すプロパティパスが設定される。同異の欄には、対応するＵＲＩから対応するプロパティパスを辿った先の目的語の値が、タプルに示される値と同じか否かの判定結果が設定される。値が同じであれば、同異の欄に「同」と設定され、値が異なれば、同異の欄に「異」と設定される。
【００７７】
図９は、プロパティパス候補テーブルの一例を示す図である。プロパティパス候補テーブル１１３には、ラベル、プロパティパス、カバー率、およびマッチ率の欄が設けられている。ラベルの欄には、プロパティパスの評価の判定元となったタプルのラベルが設定される。プロパティパスの欄には、評価対象のプロパティパスが設定される。カバー率の欄には、対応するプロパティパスのカバー率が設定される。マッチ率の欄には、対応するプロパティパスのマッチ率が設定される。
【００７８】
このようなシステムにおいて、端末装置２００を使用する開発者は、例えばＳＰＡＲＱＬエンドポイント３００に対してＳＰＡＲＱＬ検索を実行した結果を利用するアプリケーションソフトウェアを開発するものとする。例えば開発者は、「rdf:type」の値として「ex:人物」を持つＵＲＩ（以下「人物ＵＲＩ」と呼ぶ）に対する「姓」の値ごとの「誕生年」の値の統計を求めるアプリケーションソフトウェアを開発する。
【００７９】
なお、図６に示したＲＤＦデータベース３２０には、ＲＤＦデータ中にアプリケーションソフトウェアで利用する「姓」の値が存在しない。この場合、開発者は、他の値から「姓」の値を計算によって推定するプログラムモジュール（暫定モジュール）を作成する。図６の例であれば、開発者は「氏名」の値から「姓」の値を推定する暫定モジュールを作成する。例えば端末装置２００は、暫定モジュールに基づいて、「氏名」の先頭から１以上の文字列のうち、別途用意した姓辞書に存在する文字列と最も長く一致する文字列を、「姓」の値と推定する。
【００８０】
しかし暫定モジュールを用いて求めた推定値が、間違っている可能性がある。例えば図６のグラフ３２２には、「氏名」の値として「Ａ山田Ｃ男」が設定されている。このとき姓辞書に「Ａ山」と「Ａ山田」とが登録されている場合、端末装置２００は、「Ａ山田」が姓であると推定する。このとき、該当する人物の本来の姓は「Ａ山」、名は「田Ｃ男」であった場合、推定値は誤りである。
【００８１】
端末装置２００では、暫定モジュールを用いてアプリケーションソフトウェアを実行することになるが、利用する正しい値がＲＤＦデータベース３２０に追加された場合、開発者は、正しい値を利用したモジュールに置き換えたいと通常考える。例えばＲＤＦデータベース３２０に「姓」の値が追加されれば、信頼性の高いアプリケーションソフトウェアとするために、開発者は、アプリケーションソフトウェア内の暫定モジュールを、「姓」の値を利用したモジュールに変更する。
【００８２】
しかし、目的の値が追加されたことを開発者が知るのは一般に困難である。すなわち、ＳＰＡＲＱＬエンドポイント３００の運営者が適切なアナウンスをするとは限らないし、アナウンスがあっても開発者が逐次チェックし続けるのは困難である。なお、何らかのデータ更新があったことを開発者に通知する仕組みがあったとしても、目的の値が追加されたのかどうかを判別するのは容易でない。
【００８３】
そこで第２の実施の形態では、プロパティパス候補通知装置１００が、ＲＤＦデータベース３２０に追加された、同じプロパティパスで辿れる値について、開発者が利用しようとする目的の値かどうかを評価する。そしてプロパティパス候補通知装置１００は、高い評価が得られた場合にのみ、その値へのプロパティパスを端末装置２００に通知する。
【００８４】
なおプロパティパス候補通知装置１００は、プロパティパスの評価に、開発者の推定値（例えば姓辞書を使った暫定モジュールの出力）を利用する。すなわち、開発者の推定値は、正解の可能性が高いが、完璧ではないものと考えることができる。そこであるＵＲＩから特定のプロパティパスで辿れる値が、そのＵＲＩに対して開発者が推定した値と同一となる確率がある程度以上高ければ、そのプロパティパスで辿れる位置に、正解の値が追加されていると判断できる。
【００８５】
ただし、追加されたデータ量が少ない場合、正解の値が追加されたとしても、アプリケーションソフトウェアで適切に利用することができない。そのため、更新があるたびにプロパティパスの通知を行うと、追加されたデータ量が少ない間は通知過多となり、開発者の負担となる。そこでプロパティパス候補通知装置１００は、開発者が利用したい値の数に対する、追加された正解の値の数の割合がある程度以上になったときに、追加された値へのプロパティパスを通知する。
【００８６】
開発者はプロパティパス候補を通知されたら、実際に自分の目で新規追加されたデータを確認し、開発者の意志でモジュールを置き換えるか否かを決定する。このようにして、開発者は、利用しようとする目的の値が追加された場合に、適切なタイミングでその通知を受け取り、モジュールの置き換えを適格に実施することができる。
【００８７】
以下、第２の実施の形態のシステムが実行する処理を詳細に説明する。まず、端末装置２００におけるアプリケーションソフトウェアを用いたＲＤＦデータ利用処理について説明する。
【００８８】
図１０は、ＲＤＦデータ利用処理の手順の一例を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］ＲＤＦデータ利用部２１０は、ＳＰＡＲＱＬエンドポイント３００から、すべての人物ＵＲＩを取得する。例えばＲＤＦデータ利用部２１０は、「SELECT ?n WHERE [ ?n rdf:type ex:人物 . ]」というクエリをＳＰＡＲＱＬエンドポイント３００に送信する。するとＳＰＡＲＱＬエンドポイント３００内のＲＤＦデータ提供部３１０が、受信したクエリに基づいて、人物ＵＲＩを検索する。そしてＲＤＦデータ提供部３１０は、検索でヒットしたすべての人物ＵＲＩを、端末装置２００に送信する。
【００８９】
［ステップＳ１０２］ＲＤＦデータ利用部２１０は、取得した各人物ＵＲＩに対応する人物の誕生年を示す値を、ＳＰＡＲＱＬエンドポイント３００から取得する。例えばＲＤＦデータ利用部２１０は、ステップＳ１０１の検索結果として得られたすべての「?n」に対し、誕生年を取得するクエリを送信する。人物ＵＲＩ「?n=ex:P102」であれば、クエリは「SELECT ?y WHERE [ ex:P102 ex:個情/ex:誕生年 ?y . ]」となる。するとＳＰＡＲＱＬエンドポイント３００内のＲＤＦデータ提供部３１０が、受信したクエリに基づいて、誕生年の値を応答する。
【００９０】
［ステップＳ１０３］ＲＤＦデータ利用部２１０は、暫定モジュールを呼び出して、姓の値取得処理を行う。この処理の詳細は後述する（図１１参照）。
［ステップＳ１０４］ＲＤＦデータ利用部２１０は、取得した値（誕生年や姓）を用いた統計処理を行い、処理結果を出力する。
【００９１】
統計処理とは例えば、１９８０年から１９８９年までの年ごとに、各年を誕生年として持つ人物の姓を集計し、件数上位５つの姓を算出する処理であり、処理結果とは例えば、年ごとに算出された５つの姓を表形式でまとめた結果である（図示せず）。
【００９２】
図１１は、姓の値取得処理の手順の一例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
［ステップＳ１１１］ＲＤＦデータ利用部２１０は、ステップＳ１０１で取得した人物ＵＲＩのうち、未選択の人物ＵＲＩを１つ選択する。
【００９３】
［ステップＳ１１２］ＲＤＦデータ利用部２１０は、ＳＰＡＲＱＬエンドポイント３００から、選択した人物ＵＲＩで示される人物の氏名の値を取得する。選択した人物ＵＲＩが「ex:P102」の場合、ＲＤＦデータ利用部２１０は、例えば「SELECT ?n WHERE [ ex:P102 ex:個情/ex:氏名 ?n . ]」というクエリをＳＰＡＲＱＬエンドポイント３００に送信する。するとＳＰＡＲＱＬエンドポイント３００内のＲＤＦデータ提供部３１０が、受信したクエリに基づいて、氏名の値を応答する。例えば「?n = “Ａ山田Ｂ男”」という応答が返される。
【００９４】
［ステップＳ１１３］ＲＤＦデータ利用部２１０は、氏名の値から姓を推定する。例えばＲＤＦデータ利用部２１０は、氏名の値の先頭数文字のうち、予めＲＤＦデータ利用部２１０が保持する姓辞書２１１内に存在する最長のものが姓であると推定する。図１１の例では、姓辞書２１１に「Ａ山」と「Ａ山田」がある。ＲＤＦデータ利用部２１０は、氏名が「Ａ山田Ｂ男」の場合、最長に一致する「Ａ山田」が姓であると推定する。
【００９５】
［ステップＳ１１４］送信部２２０は、ＲＤＦデータ利用部２１０が推定した姓の値を含むタプルを、プロパティパス候補通知装置１００に送信する。送信されるタプルには、例えばラベルとして「ＳＥＩ」が含まれ、ＵＲＩとして選択した人物ＵＲＩが含まれ、値として推定した姓の値が含まれる。
【００９６】
ステップＳ１１３で説明した例においては、送信されるタプルは「〈SEI, ex:P102, Ａ山田〉」というタプルである。
［ステップＳ１１５］ＲＤＦデータ利用部２１０は、暫定モジュールの呼び出し元に姓の値を返す。
【００９７】
ステップＳ１１３で説明した例においては、暫定モジュールの呼び出し元に返される姓の値は「Ａ山田」である。
［ステップＳ１１６］ＲＤＦデータ利用部２１０は、未選択の人物ＵＲＩがあるか否かを判断する。未選択の人物ＵＲＩがあれば、処理がステップＳ１１１に進められる。すべての人物ＵＲＩに対する処理が完了したら、姓の値取得処理が終了する。
【００９８】
図１０、図１１に示した処理によって、開発者が作成したアプリケーションソフトウェアを用いたＲＤＦデータ利用処理の過程で、推定した値を含むタプルを、端末装置２００からプロパティパス候補通知装置１００に送信することができる。送信されたタプルは、プロパティパス候補通知装置１００内の受信部１２０で受信される。
【００９９】
なお、開発者が本実施の形態を利用しない場合のフローチャートは、図１１に示したフローチャートにおいてステップＳ１１４が存在しない。この場合、ステップＳ１１３の次にステップＳ１１５を実行するフローチャートとなる。すなわち、ステップＳ１１４により開発者は本実施の形態による効果の恩恵を受けることができる。
【０１００】
次に、受信部１２０によるタプル受信処理について説明する。
図１２は、タプル受信処理の手順の一例を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
【０１０１】
［ステップＳ１２１］受信部１２０は、端末装置２００からタプルを受信したか否かを判断する。タプルを受信した場合、処理がステップＳ１２２に進められる。タプルを受信していなければ、ステップＳ１２１の処理が繰り返される。
【０１０２】
［ステップＳ１２２］受信部１２０は、タプルテーブル１１１に受信したタプルを登録する。具体的には、受信部１２０は、タプルに含まれるラベル、ＵＲＩ、および値を関連付けて１つのレコードとし、そのレコードをタプルテーブル１１１に登録する。
【０１０３】
例えば受信部１２０が、図６に示したＲＤＦデータを利用した端末装置２００から、以下のようなタプルを受信したものとする。
１回目：〈SEI, ex:P101, Ａ山〉
２回目：〈SEI, ex:P102, Ａ山田〉
３回目：〈SEI, ex:P103, Ａ川〉
４回目：〈SEI, ex:P104, Ｅ橋〉
５回目：〈SEI, ex:P105, Ａ川〉
受信部１２０がこれらのタプルをタプルテーブル１１１に登録することで、タプルテーブル１１１には図７に示した情報が登録される。その後、ＲＤＦデータベース３２０内のＲＤＦデータが更新されたものとする。
【０１０４】
図１３は、更新後のＲＤＦデータの第１の例を示す図である。図１３の例では、グラフ３２１ａ〜３２４ａに対して、プロパティパス「ex:姓名/ex:姓」の位置と「ex:姓名/ex:名」の位置とに文字列が追加されている。グラフ３２５は更新されていない。ＲＤＦデータが更新されると、プロパティパス候補通知装置１００内のプロパティパス計算部１３０によって、推定された値に対応する正しい値へのプロパティパスを求めるプロパティパス計算処理が実行される。
【０１０５】
図１４は、プロパティパス計算処理の手順の一例を示す図である。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳ１３１］プロパティパス計算部１３０は、ＲＤＦデータが更新されたか否かを判断する。例えばプロパティパス計算部１３０は、ＳＰＡＲＱＬエンドポイント３００内のＲＤＦデータベース３２０を定期的にチェックして、更新の有無を判断する。更新の有無を判断する方法としては、例えば「SELECT COUNT(*) WHERE [ ?s ?p ?o . ]」というクエリによりＲＤＦデータベース３２０が持つ総トリプル数を取得し、図示しないテーブルに保存するようにし、取得のたびに前回保存した総トリプル数と比較する方法がある。またＳＰＡＲＱＬエンドポイント３００内のＲＤＦデータ提供部３１０が、ＲＤＦデータを更新した際に、更新した旨をプロパティパス計算部１３０に通知してもよい。この場合、プロパティパス計算部１３０は、ＲＤＦデータ提供部３１０からの更新した旨の通知があったとき、ＲＤＦデータが更新されたと判断する。ＲＤＦデータが更新された場合、処理がステップＳ１３２に進められる。ＲＤＦデータが更新されていなければ、ステップＳ１３１の処理が繰り返される。
【０１０６】
なおステップＳ１３１において、ＲＤＦデータが更新されたか否かを判断せず、定期的に、例えば３０分ごとに、ステップＳ１３２以降の処理を実行するようにしてもよい。
［ステップＳ１３２］プロパティパス計算部１３０は、タプルテーブル１１１に設定されているラベルごとに、ステップＳ１３３〜Ｓ１３５の処理を実行する。図７の例では、タプルテーブル１１１に登録されているラベルは「ＳＥＩ」のみである。
【０１０７】
［ステップＳ１３３］プロパティパス計算部１３０は、同プロパティパス計算部１３１に、同プロパティパス計算処理を実行させる。同プロパティパス計算処理の詳細は後述する（図１５参照）。
【０１０８】
［ステップＳ１３４］プロパティパス計算部１３０は、異プロパティパス計算部１３２に、異プロパティパス計算処理を実行させる。異プロパティパス計算処理の詳細は後述する（図１８参照）。
【０１０９】
［ステップＳ１３５］プロパティパス計算部１３０は、カバー率・マッチ率計算部１３３に、カバー率・マッチ率計算処理を実行させる。カバー率・マッチ率計算処理の詳細は後述する（図２０参照）。
【０１１０】
［ステップＳ１３６］プロパティパス計算部１３０は、すべてのラベルについて処理が完了したら、処理をステップＳ１３１に進める。
次に、同プロパティパス計算処理について詳細に説明する。
【０１１１】
図１５は、同プロパティパス計算処理の手順の一例を示す図である。以下、図１５に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］同プロパティパス計算部１３１は、タプルテーブル１１１に登録されているタプルごとに、ステップＳ１４２〜Ｓ１４４の処理を実行する。
【０１１２】
［ステップＳ１４２］同プロパティパス計算部１３１は、ＳＰＡＲＱＬエンドポイント３００に、処理対象のタプルに対応するプロパティパスを問い合わせる。例えば同プロパティパス計算部１３１は、タプルに示されるＵＲＩからプロパティパスを辿った先に、タプルに示される値と同じ文字列までのプロパティパスを問い合わせるクエリを、ＳＰＡＲＱＬエンドポイント３００に送信する。
【０１１３】
本実施の形態中のＳＰＡＲＱＬエンドポイント３００内のＲＤＦデータ提供部３１０は、指定されたＵＲＩから、指定された別のＵＲＩまたは文字列までのプロパティパスを問い合わせるクエリを受け付け、結果を応答する機能を持つものとする。
【０１１４】
ＲＤＦデータ提供部３１０は、例えば「ex:P101」から値「A山」までのプロパティパスを問い合わせるクエリを受け付けると、「SELECT ?p1 [ ex:P101 ?p1 "A山" . ]」というＳＰＡＲＱＬクエリにより長さ１のプロパティパス（?p1として得られる結果）を探索する。次にＲＤＦデータ提供部３１０は、「SELECT ?p1 ?p2 [ ex:P101 ?p1 ?o1 . ?o1 ?p2 "A山" . ]」というＳＰＡＲＱＬクエリにより長さ２のプロパティパス（?p1、?p2として得られる結果を繋げたもの）を探索する。さらにＲＤＦデータ提供部３１０は、「SELECT ?p1 ?p2 ?p3 [ ex:P101 ?p1 ?o1 . ?o1 ?p2 ?o2 . ?o2 ?p3 "A山" . ]」というＳＰＡＲＱＬクエリにより長さ３のプロパティパス（?p1、?p2、?p3として得られる結果を繋げたもの）を探索する。このようにＲＤＦデータ提供部３１０は、プロパティパスの長さ（プロパティを辿る回数）を１から始めて１ずつ増やしていき、それに応じたＳＰＡＲＱＬクエリにより探索を進め、探索の結果得られたプロパティパスを応答する。この場合、ＲＤＦデータ提供部３１０は、例えばプロパティパスの長さに上限値を設ける等終了条件を適宜定め、処理が終了するようにする。なお探索の結果プロパティパスが見つからない場合、ＲＤＦデータ提供部３１０は、該当プロパティパスがないことを応答する。
【０１１５】
なお、プロパティパス上に存在するＵＲＩやプロパティとして除外したいＵＲＩやプロパティがある場合には、ＦＩＬＴＥＲ句を適切に用いて除外したいＵＲＩやプロパティを除外するようにして、プロパティパスを問い合わせるようにしてもよい。
【０１１６】
なお、プロパティパスを辿る際には、主語から目的語への方向だけでなく、目的語から主語への方向も辿るようにしてもよい。この場合、プロパティパスがループしないよう、ＦＩＬＴＥＲ句を適切に用いて制限を加えてもよい。
【０１１７】
以降の例においては、プロパティパスの長さに上限値を設けず、また目的語から主語への方向は辿らないこととする。
［ステップＳ１４３］同プロパティパス計算部１３１は、１件以上のプロパティパスが応答されたか否かを判断する。１件以上のプロパティパスが応答された場合、処理がステップＳ１４４に進められる。１件もプロパティパスが応答されなかった場合、処理がステップＳ１４５に進められる。
【０１１８】
［ステップＳ１４４］同プロパティパス計算部１３１は、値が同じであるという情報と共に、処理対象のタプルに示されるＵＲＩおよび応答されたプロパティパスを、プロパティパスごとにプロパティパス計算テーブル１１２に登録する。
【０１１９】
［ステップＳ１４５］同プロパティパス計算部１３１は、すべてのタプルに対する処理が完了したら、同プロパティパス計算処理を終了する。
このようにして、プロパティパス計算テーブル１１２に、タプルに示される値と同じ文字列までのプロパティパスが登録される。以下、図１６、図１７を参照し、同プロパティパス計算の具体例を説明する。
【０１２０】
図１６は、同プロパティパス計算例を示す第１の図である。まずタプルテーブル１１１の先頭のタプルに対して、同プロパティパス計算処理が実行される。そのタプルのＵＲＩは「ex:P101」であり、値は「Ａ山」である。このタプルに基づいて同プロパティパス計算部１３１がプロパティパスの問い合わせを行うと、ＲＤＦデータ提供部３１０は、グラフ３２１ａ内のＵＲＩ「ex:P101」から、値「Ａ山」の文字列を探索する。グラフ３２１ａで示されるＲＤＦデータには値「Ａ山」の文字列が存在するため、ＲＤＦデータ提供部３１０は、その文字列までのプロパティパス「ex:姓名/ex:姓」を応答する。すると同プロパティパス計算部１３１は、タプルに示されたＵＲＩ「ex:P101」、取得したプロパティパス「ex:姓名/ex:姓」、および同じであることを示す情報「同」を１つのレコードとして、プロパティパス計算テーブル１１２に登録する。
【０１２１】
次にタプルテーブル１１１の２番目のタプルに対して、同プロパティパス計算処理が実行される。そのタプルのＵＲＩは「ex:P102」であり、値は「Ａ山田」である。このタプルに基づいて同プロパティパス計算部１３１がプロパティパスの問い合わせを行うと、ＲＤＦデータ提供部３１０は、グラフ３２２ａ内のＵＲＩ「ex:P102」から、値「Ａ山田」の文字列を探索する。グラフ３２２ａで示されるＲＤＦデータには値「Ａ山田」の文字列が存在しないため、ＲＤＦデータ提供部３１０は、該当するプロパティパスがない旨を応答する。この場合、同プロパティパス計算部１３１は、プロパティパス計算テーブル１１２には何も登録しない。
【０１２２】
次にタプルテーブル１１１の３番目のタプルに対して、同プロパティパス計算処理が実行される。そのタプルのＵＲＩは「ex:P103」であり、値は「Ａ川」である。このタプルに基づいて同プロパティパス計算部１３１がプロパティパスの問い合わせを行うと、ＲＤＦデータ提供部３１０は、グラフ３２３ａ内のＵＲＩ「ex:P103」から、値「Ａ川」の文字列を探索する。グラフ３２３ａで示されるＲＤＦデータには値「Ａ川」の文字列が存在するため、ＲＤＦデータ提供部３１０は、その文字列までのプロパティパス「ex:姓名/ex:姓」を応答する。すると同プロパティパス計算部１３１は、タプルに示されたＵＲＩ「ex:P103」、取得したプロパティパス「ex:姓名/ex:姓」、および同じであることを示す情報「同」を１つのレコードとして、プロパティパス計算テーブル１１２に登録する。
【０１２３】
図１７は、同プロパティパス計算例を示す第２の図である。次にタプルテーブル１１１の４番目のタプルに対して、同プロパティパス計算処理が実行される。そのタプルのＵＲＩは「ex:P104」であり、値は「Ｅ橋」である。このタプルに基づいて同プロパティパス計算部１３１がプロパティパスの問い合わせを行うと、ＲＤＦデータ提供部３１０は、グラフ３２４ａ内のＵＲＩ「ex:P104」から、値「Ｅ橋」の文字列を探索する。グラフ３２４ａで示されるＲＤＦデータには値「Ｅ橋」の文字列が存在するため、ＲＤＦデータ提供部３１０は、その文字列までのプロパティパス「ex:姓名/ex:姓」を応答する。すると同プロパティパス計算部１３１は、タプルに示されたＵＲＩ「ex:P104」、取得したプロパティパス「ex:姓名/ex:姓」、および同じであることを示す情報「同」を１つのレコードとして、プロパティパス計算テーブル１１２に登録する。
【０１２４】
最後にタプルテーブル１１１の５番目のタプルに対して、同プロパティパス計算処理が実行される。そのタプルのＵＲＩは「ex:P105」であり、値は「Ａ川」である。このタプルに基づいて同プロパティパス計算部１３１がプロパティパスの問い合わせを行うと、ＲＤＦデータ提供部３１０は、グラフ３２５内のＵＲＩ「ex:P105」から、値「Ａ川」の文字列を探索する。グラフ３２５で示されるＲＤＦデータには値「Ａ川」の文字列が存在しないため、ＲＤＦデータ提供部３１０は、該当するプロパティパスがない旨を応答する。この場合、同プロパティパス計算部１３１は、プロパティパス計算テーブル１１２には何も登録しない。
【０１２５】
なお図１６、図１７に示した例では、ＳＰＡＲＱＬエンドポイント３００において、「owl:sameAs」で表現された等価なＵＲＩを区別せず扱える機能を持っている場合を想定している。そのため、「ex:P102」から「ex:姓名/ex:姓」を辿れる。「owl:sameAs」で表現された等価なＵＲＩを区別できない場合は、「owl:sameAs/ex:姓名/ex:姓」が応答されるプロパティパスとなる。
【０１２６】
このようにして、同プロパティパス計算処理が行われた後、異プロパティパス計算処理が実行される。
図１８は、異プロパティパス計算処理の手順の一例を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。
【０１２７】
［ステップＳ１５１］異プロパティパス計算部１３２は、プロパティパス計算テーブル１１２に登録されているユニークなプロパティパスごとに、ステップＳ１５２〜Ｓ１５７の処理を実行する。図１７に示した例では、プロパティパス計算テーブル１１２に登録されているプロパティパスは、「ex:姓名/ex:姓」のみである。
【０１２８】
［ステップＳ１５２］異プロパティパス計算部１３２は、タプルテーブル１１１に登録されているタプルごとに、ステップＳ１５３〜Ｓ１５６の処理を実行する。
［ステップＳ１５３］異プロパティパス計算部１３２は、ＳＰＡＲＱＬエンドポイント３００に、処理対象のタプルに示されたＵＲＩから、処理対象のプロパティパスを辿った位置にある値を問い合わせる。ＳＰＡＲＱＬエンドポイント３００のＲＤＦデータ提供部３１０は、問い合わせで指定された位置に値があれば、その値を応答する。またＲＤＦデータ提供部３１０は、問い合わせで指定された位置に値がなければ、値がない旨を応答する。
【０１２９】
［ステップＳ１５４］異プロパティパス計算部１３２は、対応する値の応答があったか否かを判断する。値が応答された場合、処理がステップＳ１５５に進められる。値が応答されなかった場合、処理がステップＳ１５７に進められる。
【０１３０】
［ステップＳ１５５］異プロパティパス計算部１３２は、応答された値が、処理対象のタプルの値と同じか否かを判断する。値が同じであれば、処理がステップＳ１５７に進められる。値が異なれば、処理がステップＳ１５６に進められる。
【０１３１】
［ステップＳ１５６］異プロパティパス計算部１３２は、値が異なるという情報と共に、処理対象のタプルに示されるＵＲＩおよび処理対象のプロパティパスをプロパティパス計算テーブル１１２に登録する。
【０１３２】
［ステップＳ１５７］異プロパティパス計算部１３２は、すべてのタプルに対する処理が完了したら、処理をステップＳ１５８に進める。
［ステップＳ１５８］異プロパティパス計算部１３２は、すべてのプロパティパスに対する処理が完了したら、異プロパティパス計算処理を終了する。
【０１３３】
このようにして、プロパティパス計算テーブル１１２に登録されているプロパティパスを辿ると、タプルに示される値と異なる値の文字列に到達するＵＲＩが、プロパティパス計算テーブル１１２に登録される。
【０１３４】
なお、処理対象のタプルに示されたＵＲＩから、処理対象のプロパティパスを辿った位置にある値が、処理対象のタプルの値と同じであることを判定する別の方法として、プロパティパス計算テーブル１１２を参照し、処理対象のタプルに示されたＵＲＩに対応する同異が「同」であるかどうかにより判定する方法もある。
【０１３５】
図１９は、異プロパティパス計算例を示す図である。タプルテーブル１１１に登録されているタプルのうち、同プロパティパス計算処理によって既にプロパティパス計算テーブル１１２に対応するレコードが登録されているタプルについては、異プロパティパス計算処理のステップＳ１５５において「ＮＯ」と判定される。その結果、それらのタプルに対する異プロパティパス計算処理においては、プロパティパス計算テーブル１１２に対する新たなレコードは登録されない。
【０１３６】
タプルテーブル１１１における２番目と５番目のタプル（ＵＲＩ「ex:P102」、「ex:P105」）については、同プロパティパス計算処理によってプロパティパス計算テーブル１１２に対応するレコードが登録されていない。
【０１３７】
タプルテーブル１１１の２番目のタプルに対して、異プロパティパス計算処理が実行されると、異プロパティパス計算部１３２が値の問い合わせを行う。その問い合わせに対して、ＲＤＦデータ提供部３１０は、グラフ３２２ａ内のＵＲＩ「ex:P102」からプロパティパス「ex:姓名/ex:姓」を辿った位置の値「Ａ山」の文字列を応答する。応答を受け取った異プロパティパス計算部１３２は、処理対象のタプルの値「Ａ山田」と応答された値「Ａ山」とが異なると判断する。そして異プロパティパス計算部１３２は、タプルに示されたＵＲＩ「ex:P102」、探索したプロパティパス「ex:姓名/ex:姓」、および異なることを示す情報「異」を１つのレコードとして、プロパティパス計算テーブル１１２に登録する。
【０１３８】
なお、タプルテーブル１１１の５番目のタプルに対して、異プロパティパス計算処理が実行された場合、グラフ３２５内のＵＲＩ「ex:P105」からプロパティパス「ex:姓名/ex:姓」を辿った先に値が存在しない。そのため、プロパティパス計算テーブル１１２には何も登録されない。
【０１３９】
異プロパティパス計算処理が完了すると、カバー率・マッチ率計算処理が実行される。
図２０は、カバー率・マッチ率計算処理の手順の一例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。
【０１４０】
［ステップＳ１６１］カバー率・マッチ率計算部１３３は、プロパティパス計算テーブル１１２に登録されているユニークなプロパティパスごとに、ステップＳ１６２〜Ｓ１６７の処理を実行する。図１９に示した例では、プロパティパス計算テーブル１１２に登録されているプロパティパスは、「ex:姓名/ex:姓」のみである。
【０１４１】
［ステップＳ１６２］カバー率・マッチ率計算部１３３は、タプルテーブル１１１中で処理対象タプルを持つタプルの数を変数Ａに設定する。
［ステップＳ１６３］カバー率・マッチ率計算部１３３は、プロパティパス計算テーブル中の処理対象のプロパティパスが設定されているレコードの数（プロパティパス出現数）を、変数Ｂに設定する。
【０１４２】
［ステップＳ１６４］カバー率・マッチ率計算部１３３は、プロパティパス計算テーブル中の処理対象のプロパティパスのうち、同異が「同」のプロパティパスの数を、変数Ｃに設定する。
【０１４３】
［ステップＳ１６５］カバー率・マッチ率計算部１３３は、変数Ｂを変数Ａで除算した結果（Ｂ／Ａ）を、カバー率とする。
［ステップＳ１６６］カバー率・マッチ率計算部１３３は、変数Ｃを変数Ｂで除算した結果（Ｃ／Ｂ）を、マッチ率とする。
【０１４４】
［ステップＳ１６７］カバー率・マッチ率計算部１３３は、プロパティパス候補テーブル１１３に、算出したカバー率とマッチ率とを登録する。
［ステップＳ１６８］カバー率・マッチ率計算部１３３は、すべてのプロパティパスに対して処理が完了したら、カバー率・マッチ率計算処理を終了する。
【０１４５】
このようにして、カバー率とマッチ率とが計算される。
図２１は、カバー率・マッチ率の計算例を示す図である。図２１の例では、タプルテーブル１１１に登録されているタプルは５件であり、「Ａ＝５」となる。またプロパティパス計算テーブル１１２におけるプロパティパス「ex:姓名/ex:姓」の出現数は４件であり、「Ｂ＝４」となる。さらにプロパティパス計算テーブル１１２におけるプロパティパス「ex:姓名/ex:姓」のうち、同異が「同」の数は３件であり、「Ｃ＝３」となる。その結果、カバー率は「４／５」となり、マッチ率は「３／４」となる。
【０１４６】
ここで、カバー率とマッチ率とが表す統計上の意味について説明する。マッチ率は、複数のエンティティ（人や物）それぞれの推定値と、複数のエンティティそれぞれから特定の関係情報を辿った先に存在する値とが一致する割合（一致率）である。カバー率は、複数のエンティティのうち、関係情報を辿った位置に値が存在するエンティティの割合（存在率）である。より詳細には以下の通りである。
【０１４７】
図２２は、カバー率とマッチ率との意味を概念的に説明する図である。開発者が作成したアプリケーションソフトウェアを実行するのに利用する値（正解の集合３１）がＲＤＦデータから取得できない場合、利用する値を推定する暫定モジュールを作成する。端末装置２００では、暫定モジュールにより利用する値を推定する。推定した値の集合３２は、正解の集合３１とかなりの部分で重複するが、異なる部分も存在する。すなわち開発者の推定結果（姓辞書を使った暫定モジュールの出力）は正解の可能性が高いが完全に正解と一致するとは限らない。外部に提供する目的で利用されるＲＤＦデータベース３２０に追加された値（追加の集合３３）は、正解の可能性が、推定した値より高いものと考えられる。
【０１４８】
カバー率は、追加した値の集合３３の要素数の、推定した値の集合３２の要素数に対する比の値（Ｂ／Ａ）である。すなわちカバー率は、開発者が作成したアプリケーションソフトウェアを実行するのに利用する値が、ＲＤＦデータからどの程度の割合で入手可能かを表す。カバー率が高くないと、アプリケーションソフトウェア内の暫定モジュールを、ＲＤＦデータから値を入手するモジュールに置き換える意味がない。そこで、通知部１４０は、カバー率が所定の閾値以上の場合にのみ、プロパティパスを端末装置２００に通知する。
【０１４９】
マッチ率は、推定した値の集合３２と追加した値の集合３３とに共通する要素数の、追加した値の集合３３の要素数に対する比の値（Ｃ／Ｂ）である。すなわちマッチ率は、入手可能な値のうち、開発者が推定した値との一致の度合いを表し、高いことが重要である。開発者の暫定モジュールで推定した値は正解とは限らないので、置き換えたい値は、マッチ率がある程度以上高いことが重要である。そこで、通知部１４０は、マッチ率が所定の閾値以上の場合にのみ、プロパティパスを端末装置２００に通知する。
【０１５０】
つまり通知部１４０は、カバー率とマッチ率との両方が閾値を超えて初めて通知を行う。これにより、過剰な通知が抑止される。
次に、通知部１４０における通知処理について詳細に説明する。
【０１５１】
図２３は、通知処理の手順の一例を示す図である。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ１７１］通知部１４０は、プロパティパス候補テーブル１１３の更新の有無を監視する。プロパティパス候補テーブル１１３が更新された場合、処理がステップＳ１７２に進められる。プロパティパス候補テーブル１１３が更新されていなければ、ステップＳ１７１の処理が繰り返される。
【０１５２】
［ステップＳ１７２］通知部１４０は、プロパティパス候補テーブル１１３内の更新されたレコードのカバー率が閾値以上か否かを判断する。カバー率が閾値以上であれば、処理がステップＳ１７３に進められる。カバー率が閾値未満であれば、処理がステップＳ１７１に進められる。
【０１５３】
［ステップＳ１７３］通知部１４０は、プロパティパス候補テーブル１１３内の更新されたレコードのマッチ率が閾値以上か否かを判断する。マッチ率が閾値以上であれば、処理がステップＳ１７４に進められる。マッチ率が閾値未満であれば、処理がステップＳ１７１に進められる。
【０１５４】
［ステップＳ１７４］通知部１４０は、プロパティパス候補テーブル１１３内の更新されたレコードのプロパティパスが通知済か否かを判断する。例えば通知部１４０は、端末装置２００に通知したプロパティパスの履歴を保持しており、その履歴に既に登録されているプロパティパスについては通知済と判断する。通知済であれば、処理がステップＳ１７１に進められる。通知済でなければ、処理がステップＳ１７５に進められる。
【０１５５】
［ステップＳ１７５］通知部１４０は、プロパティパス候補テーブル１１３内の更新されたレコードのプロパティパスを、端末装置２００に通知する。この際、通知部１４０は、プロパティパスと共に、カバー率とマッチ率とを通知してもよい。プロパティパス通知後、処理がステップＳ１７１に進められる。
【０１５６】
このようにして、カバー率とマッチ率とが共に閾値以上となったときに、プロパティパスが通知される。例えば図６に示したＲＤＦデータベース３２０に示される上位のグラフから順に時間を置いて、図１３に示されるように、プロパティパス「ex:姓名/ex:姓」の位置に値が追加されていく場合を想定する。この場合、タプルと同じ値がある程度以上追加された時点でプロパティパス「ex:姓名/ex:姓」が通知される。
【０１５７】
以下、図２４〜図２６を参照し、各グラフに値が追加されるごとのカバー率およびマッチ率と、プロパティパスを通知するか否かの判断状況について説明する。
図２４は、データ更新ごとのカバー率・マッチ率の計算結果を示す第１の図である。図２４には、１回目のデータ更新から３回目のデータ更新までの更新結果が示されている。
【０１５８】
１回目のデータ更新では、グラフ３２１内のプロパティパス「ex:姓名/ex:姓」で辿ることで到達する位置に、タプルと同じ値が追加され、グラフ３２１ａに更新される。１回目のデータ更新では、カバー率は「１／５」であり、マッチ率は「１／１」である。
【０１５９】
２回目のデータ更新では、グラフ３２２内のプロパティパス「ex:姓名/ex:姓」で辿ることで到達する位置に、タプルと異なる値が追加され、グラフ３２２ａに更新される。２回目のデータ更新では、カバー率は「２／５」であり、マッチ率は「１／２」である。
【０１６０】
３回目のデータ更新では、グラフ３２３内のプロパティパス「ex:姓名/ex:姓」で辿ることで到達する位置に、タプルと同じ値が追加され、グラフ３２３ａに更新される。３回目のデータ更新では、カバー率は「３／５」であり、マッチ率は「２／３」である。
【０１６１】
図２５は、データ更新ごとのカバー率・マッチ率の計算結果を示す第２の図である。図２５には、４回目のデータ更新から５回目のデータ更新までの更新結果が示されている。
４回目のデータ更新では、グラフ３２４内のプロパティパス「ex:姓名/ex:姓」で辿ることで到達する位置に、タプルと同じ値が追加され、グラフ３２４ａに更新される。４回目のデータ更新では、カバー率は「４／５」であり、マッチ率は「３／４」である。
【０１６２】
５回目のデータ更新では、グラフ３２５内のプロパティパス「ex:姓名/ex:姓」で辿ることで到達する位置に、タプルと異なる値が追加され、グラフ３２５ａに更新される。５回目のデータ更新では、カバー率は「５／５」であり、マッチ率は「４／５」である。
【０１６３】
図２６は、プロパティパスの通知判断の例を示す図である。図２６の例では、カバー率の閾値が「０．６５」、マッチ率の閾値が「０．６」であるものとする。
図２４に示した１回目のデータ更新では、マッチ率は閾値以上であるが、カバー率が閾値未満である。その結果、通知しないと判定される。図２４に示した２回目のデータ更新では、カバー率、マッチ率共に閾値未満である。その結果、通知しないと判定される。図２４に示した３回目のデータ更新では、マッチ率は閾値以上であるが、カバー率が閾値未満である。その結果、通知しないと判定される。
【０１６４】
図２５に示した４回目のデータ更新では、カバー率、マッチ率共に閾値以上である。その結果、通知すると判定される。図２５に示した５回目のデータ更新では、カバー率、マッチ率共に閾値以上であるが、既に通知済である。その結果、通知しないと判定される。
【０１６５】
このようにして、開発者は、ＲＤＦデータ内に、利用しようとする目的の値が追加されたことを、十分にデータが揃った時点で知ることができる。なお図２４〜図２６の例は、ＲＤＦデータベース３２０内のＲＤＦデータが、図１３に示すように更新される場合の例である。この例では、最終的にカバー率とマッチ率との両方が閾値以上となるが、ＲＤＦデータの更新内容によっては、カバー率が高くなっても、マッチ率が低いままの場合がある。
【０１６６】
なお通知後に、処理の負荷を減らすため、タプルテーブル中にある処理対象のラベルを含むタプルを削除するとしてもよい。図２４〜図２６に示した例においては、４回目のデータ更新後に通知を行った後、図７に示したタプルテーブル１１１のうちラベル「ＳＥＩ」を含む５つのタプルを削除する。
【０１６７】
図２７は、ＲＤＦデータの第２の更新例を示す図である。図２７の例では、グラフ３２１ｂ〜３２５ｂに対して、プロパティパス「ex:出身地」の位置に、文字列が追加されている。出身地を示す地名の中に人物の姓と同じ文字列のものが存在すると、偶然、追加された値がタプルに示される値と同じとなる。例えばグラフ３２３ｂに示される「ex:P103」に対応する人物の出身地は「Ａ川」であり、図７のタプルテーブル１１１に登録されている「ex:P103」のタプルにある推定値「Ａ川」と同じである。ただし、ＲＤＦデータ全体としては、人物の出身地を追加しているだけなので、開発者へのプロパティパスの通知は行わないのが適切である。
【０１６８】
図２８は、ＲＤＦデータの第２の更新例に基づくカバー率・マッチ率の計算例を示す図である。図２８の例では、カバー率の閾値が「０．６５」、マッチ率の閾値が「０．６」であるものとする。図２８に示すように、図２７の例におけるカバー率は「５／５」であり閾値以上であるものの、マッチ率は「１／５」であり閾値未満である。そのため、プロパティパスの通知は行われない。
【０１６９】
なお図２８では、グラフ３２１ｂ〜３２５ｂのすべてを更新した後のカバー率とマッチ率とを示しているが、グラフ３２１ｂ〜３２５ｂを１つずつ順番に更新した場合のカバー率とマッチ率とは、図２９〜図３０のようになる。
【０１７０】
図２９は、ＲＤＦデータの第２の更新例におけるデータ更新ごとのカバー率・マッチ率の計算結果を示す第１の図である。図２９には、１回目のデータ更新から３回目のデータ更新までの更新結果が示されている。
【０１７１】
１回目のデータ更新では、グラフ３２１内のプロパティパス「ex:出身地」で辿ることで到達する位置に、タプルと異なる値が追加され、グラフ３２１ｂに更新される。１回目のデータ更新では、タプルに示される値と同じ値が存在せず、カバー率とマッチ率とは算出されない。
【０１７２】
２回目のデータ更新では、グラフ３２２内のプロパティパス「ex:出身地」で辿ることで到達する位置に、タプルと異なる値が追加され、グラフ３２２ｂに更新される。２回目のデータ更新では、タプルに示される値と同じ値が存在せず、カバー率とマッチ率とは算出されない。
【０１７３】
３回目のデータ更新では、グラフ３２３内のプロパティパス「ex:出身地」で辿ることで到達する位置に、タプルと同じ値が追加され、グラフ３２３ｂに更新される。３回目のデータ更新では、カバー率は「３／５」であり、マッチ率は「１／３」である。
【０１７４】
図３０は、ＲＤＦデータの第２の更新例におけるデータ更新ごとのカバー率・マッチ率の計算結果を示す第２の図である。図３０には、４回目のデータ更新から５回目のデータ更新までの更新結果が示されている。
【０１７５】
４回目のデータ更新では、グラフ３２４内のプロパティパス「ex:出身地」で辿ることで到達する位置に、タプルと異なる値が追加され、グラフ３２４ｂに更新される。４回目のデータ更新では、カバー率は「４／５」であり、マッチ率は「１／４」である。
【０１７６】
５回目のデータ更新では、グラフ３２５内のプロパティパス「ex:出身地」で辿ることで到達する位置に、タプルと異なる値が追加され、グラフ３２５ｂに更新される。５回目のデータ更新では、カバー率は「５／５」であり、マッチ率は「１／５」である。
【０１７７】
図３１は、ＲＤＦデータの第２の更新例におけるプロパティパスの通知判断の例を示す図である。図３１の例では、カバー率の閾値が「０．６５」、マッチ率の閾値が「０．６」であるものとする。
【０１７８】
図２９に示した１回目および２回目のデータ更新では、カバー率とマッチ率とが計算されないため、通知判定の対象外である。図２９に示した３回目のデータ更新では、カバー率、マッチ率共に閾値未満である。その結果、通知しないと判定される。図３０に示した４回目のデータ更新では、カバー率は閾値以上であるが、マッチ率が閾値未満である。その結果、通知しないと判定される。図３０に示した５回目のデータ更新では、カバー率は閾値以上であるが、マッチ率が閾値未満である。その結果、通知しないと判定される。
【０１７９】
このようにＲＤＦデータの第２の更新例では、一度もプロパティパスの通知が行われない。すなわち、開発者が利用する値とは異なる値を追加するデータ更新が行われた場合には、プロパティパスが通知されない。
【０１８０】
またＲＤＦデータの更新内容によっては、マッチ率が高くなっても、カバー率が低いままの場合がある。
図３２は、ＲＤＦデータの第３の更新例を示す図である。図３２の例では、グラフ３２１ｃ，３２３ｃに対して、プロパティパス「ex:苗字」の位置に、文字列が追加されている。値が追加されているのはグラフ３２１ｃ，３２３ｃのみであるため、プロパティパス「ex:苗字」の位置の値をアプリケーションソフトウェアで利用しようとしても、十分な数の値を取得することはできない。そのため、開発者へのプロパティパスの通知は行わないのが適切である。
【０１８１】
図３３は、ＲＤＦデータの第３の更新例に基づくカバー率・マッチ率の計算例を示す図である。図３３の例では、カバー率の閾値が「０．６５」、マッチ率の閾値が「０．６」であるものとする。図３３に示すように、図３２の例におけるマッチ率は「２／２」であり閾値以上であるものの、カバー率は「２／５」であり閾値未満である。そのため、プロパティパスの通知は行われない。
【０１８２】
なお図３３では、グラフ３２１ｃ，３２３ｃとの両方を更新した後のカバー率とマッチ率とを示しているが、グラフ３２１ｃ，３２３ｃとを１つずつ順番に更新した場合のカバー率とマッチ率とは、図３４のようになる。
【０１８３】
図３４は、ＲＤＦデータの第３の更新例におけるデータ更新ごとのカバー率・マッチ率の計算結果を示す図である。
１回目のデータ更新では、グラフ３２１内のプロパティパス「ex:苗字」で辿ることで到達する位置に、タプルと同じ値が追加され、グラフ３２１ｃに更新される。１回目のデータ更新では、カバー率は「１／５」であり、マッチ率は「１／１」である。
【０１８４】
２回目のデータ更新では、グラフ３２３内のプロパティパス「ex:苗字」で辿ることで到達する位置に、タプルと同じ値が追加され、グラフ３２３ｃに更新される。２回目のデータ更新では、カバー率は「２／５」であり、マッチ率は「２／２」である。
【０１８５】
図３５は、ＲＤＦデータの第３の更新例におけるプロパティパスの通知判断の例を示す図である。図３５の例では、カバー率の閾値が「０．６５」、マッチ率の閾値が「０．６」であるものとする。
【０１８６】
図３４に示した１回目のデータ更新では、マッチ率は閾値以上であるが、カバー率が閾値未満である。その結果、通知しないと判定される。図３４に示した２回目のデータ更新では、マッチ率は閾値以上であるが、カバー率が閾値未満である。その結果、通知しないと判定される。
【０１８７】
このようにＲＤＦデータの第３の更新例では、一度もプロパティパスの通知が行われない。すなわち、開発者が利用する値と同じ値を追加するデータ更新が行われたとしても、十分な量の値が追加されていない場合には、プロパティパスは通知されない。
【０１８８】
以上説明したように、第２の実施の形態では、ＲＤＦデータがグラフ構造で作られている特徴を活かしている。すなわち、グラフにおける同じプロパティパスを辿ることで、あるカテゴリに属するどんなＵＲＩからでも、所望の値が得られる可能性がある。プロパティパス候補通知装置１００は、同じプロパティパスを辿ることで得られる値を探索し、値の有無や、推定値との同異を調べることで、カバー率とマッチ率とが共に高いプロパティパスのみを通知する。これにより、無駄な通知を抑制し、開発者の確認負担を減らすことができる。例えば図２４〜図２６に示した例において、もしデータ更新の度に通知すると、プロパティパスが５回通知されるが、第２の実施の形態では１回の通知で済んでいる。
【０１８９】
〔第３の実施の形態〕
次に第３の実施の形態について説明する。
前述の第２の実施の形態では、開発者が送信するタプルが多いほど、カバー率やマッチ率の統計的な信頼性が上がる。しかし、多数のタプルの送信が開発者にとって負担となることもある。例えば、暫定モジュール内にタプルの自動送信機能を組み込めればよいが、処理効率などの問題で、そのような機能を組み込むことができない場合がある。その場合、開発者が手動でタプルを送信することになるが、大量のタプルを手動で送信するのは、現実的でない。
【０１９０】
そこで第３の実施の形態では、統計的な信頼性をあまり損なわずに開発者の送信の負担を減らすために、ＵＲＩ選択用ＳＰＡＲＱＬ検索式（以下、単に「検索式」と呼ぶ）を利用する。すなわちプロパティパス計算部１３０での処理対象のＵＲＩとして、タプルテーブル１１１にあるタプルのＵＲＩの他に、検索式で得られるＵＲＩも使用する。
【０１９１】
以下、第２の実施の形態との相違点を中心として、第３の実施の形態について詳細に説明する。
図３６は、第３の実施の形態における各装置の機能を示すブロック図である。図３６において、第２の実施の形態と同じ機能の要素には、図４に示した第２の実施の形態の対応する要素と同じ符号を付し、説明を省略する。
【０１９２】
端末装置２００ａの送信部２２０ａは、タプルの他に、検索式をプロパティパス候補通知装置１００ａに送信する。例えば送信部２２０ａは、処理に利用するＵＲＩの検索式を、ＲＤＦデータ利用部２１０から取得する。そして送信部２２０ａは、取得した検索式を、ラベルに対応付けてプロパティパス候補通知装置１００ａに送信する。また送信部２２０ａは、開発者が入力した検索式をプロパティパス候補通知装置１００ａに送信するようにしてもよい。
【０１９３】
プロパティパス候補通知装置１００ａの受信部１２０ａは、端末装置２００ａから送られたタプルと検索式とを受信する。受信部１２０ａは、受信したタプルをタプルテーブル１１１に登録し、受信した検索式を検索式テーブル１１４に登録する。
【０１９４】
記憶部１１０ａは、第２の実施の形態の記憶部１１０が記憶する各データテーブルに加え、検索式テーブル１１４と追加ＵＲＩテーブル１１５とを記憶する。検索式テーブル１１４は、検索式を格納するデータテーブルである。追加ＵＲＩテーブル１１５は、検索式によって取得したＵＲＩを格納するデータテーブルである。
【０１９５】
プロパティパス計算部１３０ａは、第２の実施の形態のプロパティパス計算部１３０が有する機能に加え、不明プロパティパス計算部１３４を有する。不明プロパティパス計算部１３４は、検索式を用いてＵＲＩをＳＰＡＲＱＬエンドポイント３００から取得する。不明プロパティパス計算部１３４は、取得したＵＲＩのうち、タプルテーブルに登録されていないＵＲＩから、プロパティパス計算テーブル１１２に登録されているプロパティパスを辿った先の値を探索する。不明プロパティパス計算部１３４は、探索により値が見つかれば、取得したＵＲＩについて同異を「不明」として、プロパティパス計算テーブル１１２に登録する。
【０１９６】
また第３の実施の形態におけるカバー率・マッチ率計算部１３３ａは、追加ＵＲＩテーブル１１５に登録されているＵＲＩの数を加味して、カバー率を計算する。またカバー率・マッチ率計算部１３３ａは、プロパティパス計算テーブル１１２において同異「不明」とされているＵＲＩの数を加味して、マッチ率を計算する。
【０１９７】
なお、図３６に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図３６に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
【０１９８】
図３７は、検索式テーブルの一例を示す図である。検索式テーブル１１４には、ラベルに対応付けて、端末装置２００ａから送られた検索式が設定される。図３７に示す検索式は、プロパティ「rdf:type」を辿るとＵＲＩ「ex:人物」に達するような、主語のＵＲＩ「?p」を求める検索式である。
【０１９９】
図３８は、追加ＵＲＩテーブルの一例を示す図である。追加ＵＲＩテーブル１１５には、不明プロパティパス計算部１３４がＳＰＡＲＱＬエンドポイント３００から取得したＵＲＩが設定される。
【０２００】
次に、第３の実施の形態の受信部１２０ａにおける受信処理について説明する。
図３９は、受信処理の手順の一例を示すフローチャートである。以下、図３９に示す処理をステップ番号に沿って説明する。
【０２０１】
［ステップＳ２０１］受信部１２０ａは、端末装置２００ａからタプルまたは検索式を受信したか否かを判断する。タプルまたは検索式を受信した場合、処理がステップＳ２０２に進められる。タプルと検索式のいずれも受信していなければ、ステップＳ２０１の処理が繰り返される。なお、受信する検索式にはラベルが付与されている。
【０２０２】
［ステップＳ２０２］受信部１２０ａは、何を受信したのか判断する。タプルを受信したのであれば、処理がステップＳ２０３に進められる。検索式を受信したのであれば、処理がステップＳ２０４に進められる。
【０２０３】
［ステップＳ２０３］受信部１２０ａは、タプルテーブル１１１に受信したタプルを登録する。その後、処理がステップＳ２０１に進められる。
［ステップＳ２０４］受信部１２０ａは、受信した検索式と、その検索式に付与されているラベルとを、検索式テーブル１１４に登録する。その後、処理がステップＳ２０１に進められる。
【０２０４】
このように第３の実施の形態では、受信部１２０ａがタプルまたは検索式を受信し、それぞれタプルテーブル１１１と検索式テーブル１１４とに登録される。その後、プロパティパス計算部１３０ａにより、プロパティパス計算処理が実行される。
【０２０５】
図４０は、第３の実施の形態におけるプロパティパス計算処理の手順の一例を示すフローチャートである。図４０に示した処理のうち、ステップＳ２１１〜２１４，Ｓ２１７の各処理は、図１４に示したステップＳ１３１〜Ｓ１３４，Ｓ１３６の各処理と同じである。以下、図１４と異なるステップＳ２１５，Ｓ２１６の処理について説明する。
【０２０６】
［ステップＳ２１５］プロパティパス計算部１３０ａは、不明プロパティパス計算部１３４に、不明プロパティパス計算処理を実行させる。不明プロパティパス計算処理の詳細は後述する（図４１参照）。
【０２０７】
［ステップＳ２１６］プロパティパス計算部１３０ａは、カバー率・マッチ率計算部１３３ａに、カバー率・マッチ率計算処理を実行させる。カバー率・マッチ率計算処理の詳細は後述する（図４３参照）。
【０２０８】
次に、不明プロパティパス計算処理について詳細に説明する。
図４１は、不明プロパティパス計算処理の手順の一例を示すフローチャートである。以下、図４１に示す処理をステップ番号に沿って説明する。
【０２０９】
［ステップＳ２２１］不明プロパティパス計算部１３４は、検索式テーブル１１４にラベルに対応付けて登録されている検索式を用いて、ＳＰＡＲＱＬエンドポイント３００にＵＲＩを問い合わせる。問い合わせを受けたＳＰＡＲＱＬエンドポイント３００は、ＲＤＦデータベース３２０から検索式に合致するＵＲＩを検索し、該当するＵＲＩを応答する。
【０２１０】
［ステップＳ２２２］不明プロパティパス計算部１３４は、ＳＰＡＲＱＬエンドポイント３００から取得したＵＲＩのうち、タプルテーブル１１１に登録されていないＵＲＩを、追加ＵＲＩテーブル１１５に登録する。
【０２１１】
［ステップＳ２２３］不明プロパティパス計算部１３４は、プロパティパス計算テーブル１１２に登録されているプロパティパスごとに、ステップＳ２２４〜Ｓ２２８の処理を実行する。
【０２１２】
［ステップＳ２２４］不明プロパティパス計算部１３４は、追加ＵＲＩテーブル１１５に登録されているＵＲＩごとに、ステップＳ２２５〜Ｓ２２７の処理を実行する。
［ステップＳ２２５］不明プロパティパス計算部１３４は、処理対象のＵＲＩから、処理対象のプロパティパスを辿った先に値があるかどうかを、ＳＰＡＲＱＬエンドポイント３００に問い合わせる。ＳＰＡＲＱＬエンドポイント３００は、問い合わせを受けると、ＲＤＦデータ提供部３１０が指定されたＵＲＩからプロパティパスを辿り、値の有無を判断する。そしてＲＤＦデータ提供部３１０は、値の有無をプロパティパス候補通知装置１００ａに応答する。
【０２１３】
［ステップＳ２２６］不明プロパティパス計算部１３４は、処理対象のＵＲＩから、処理対象のプロパティパスを辿った先に値がある場合、処理をステップＳ２２７に進める。値がない場合、処理をステップＳ２２８に進める。
【０２１４】
［ステップＳ２２７］不明プロパティパス計算部１３４は、値が不明であるという情報と共に、処理対象のＵＲＩおよび処理対象のプロパティパスをプロパティパス計算テーブル１１２に登録する。
【０２１５】
［ステップＳ２２８］不明プロパティパス計算部１３４は、追加ＵＲＩテーブル１１５内のすべてのＵＲＩについて処理が完了したら、処理をステップＳ２２９に進める。
［ステップＳ２２９］不明プロパティパス計算部１３４は、プロパティパス計算テーブル１１２内のすべてのプロパティパスについて処理が完了したら、不明プロパティパス計算処理を終了する。
【０２１６】
このようにして、タプルテーブル１１１に登録されていないＵＲＩについても、プロパティパス計算テーブル１１２に同異「不明」との情報が登録される。
図４２は、不明プロパティパス計算処理の結果の一例を示す図である。ここで、ＲＤＦデータベース３２０には、図１３に示すようなＲＤＦデータが登録されているものとする。図４２の例では、タプルテーブル１１１には、３件のタプルが登録されている。そして同プロパティパス計算処理と異プロパティパス計算処理の結果、プロパティパス計算テーブル１１２には、ＵＲＩ「ex:P101」〜「ex:P103」それぞれについてプロパティパス「ex:姓名/ex:姓」を辿ったときの同異の情報が設定される。
【０２１７】
その後、不明プロパティパス計算処理が実行される。図１３を参照すると、グラフ３２１ａ〜３２４ａ，３２５のルートのＵＲＩは、いずれも検索式テーブル１１４に登録されている検索式に合致する。そこで検索式による問い合わせでは、ＳＰＡＲＱＬエンドポイント３００から「ex:P101」〜「ex:P105」が応答される。このうち「ex:P101」〜「ex:P103」についてはタプルテーブル１１１に登録されているため、残りの「ex:P104」、「ex:P105」が追加ＵＲＩテーブル１１５に登録される。
【０２１８】
追加ＵＲＩテーブル１１５に登録されたＵＲＩ「ex:P104」から、グラフ３２４ａのプロパティパス「ex:姓名/ex:姓」を辿ると、値「Ｅ橋」が存在する。そのためプロパティパス計算テーブル１１２には、ＵＲＩ「ex:P104」とプロパティパス「ex:姓名/ex:姓」とに対応付けて、同異「不明」のレコードが登録される。
【０２１９】
他方、追加ＵＲＩテーブル１１５に登録されたＵＲＩ「ex:P105」から、グラフ３２５のプロパティパス「ex:姓名/ex:姓」を辿っても値が存在しない（図１３参照）。そのためＵＲＩ「ex:P105」に対応するレコードは、プロパティパス計算テーブル１１２には追加されない。
【０２２０】
不明プロパティパス計算処理が終了すると、カバー率・マッチ率計算処理が実行される。
図４３は、第３の実施の形態におけるカバー率・マッチ率計算処理の手順の一例を示すフローチャートである。
【０２２１】
［ステップＳ２３１］カバー率・マッチ率計算部１３３ａは、プロパティパス計算テーブル１１２に登録されているプロパティパスごとに、ステップＳ２３２〜Ｓ２３８の処理を実行する。
【０２２２】
［ステップＳ２３２］カバー率・マッチ率計算部１３３ａは、タプルテーブル１１１に登録されているタプル数に追加ＵＲＩテーブル１１５に登録されているＵＲＩ数を加算した値を、変数Ａに設定する。
【０２２３】
［ステップＳ２３３］カバー率・マッチ率計算部１３３ａは、プロパティパス計算テーブルに登録されている、処理対象のプロパティパスの出現数を、変数Ｂに設定する。
［ステップＳ２３４］カバー率・マッチ率計算部１３３ａは、プロパティパス計算テーブル１１２に登録されている、処理対象のプロパティパスのうち、同異が「同」のプロパティパスの数を、変数Ｃに設定する。
【０２２４】
［ステップＳ２３５］カバー率・マッチ率計算部１３３ａは、プロパティパス計算テーブル１１２に登録されている、処理対象のプロパティパスのうち、同異が「異」のプロパティパスの数を、変数Ｄに設定する。
【０２２５】
［ステップＳ２３６］カバー率・マッチ率計算部１３３ａは、変数Ｂを変数Ａで除算した結果（Ｂ／Ａ）を、カバー率とする。
［ステップＳ２３７］カバー率・マッチ率計算部１３３ａは、変数Ｃを、変数Ｃと変数Ｄとの合計値で除算した結果（Ｃ／（Ｃ＋Ｄ））を、マッチ率とする。
【０２２６】
なお、Ｃ＋Ｄの値は、タプルテーブル１１１中で処理対象ラベルを含むタプルの数と等しいので、マッチ率の分母としてＣ＋Ｄの代わりにタプルテーブル１１１中で処理対象ラベルを含むタプルの数を用いてもよい。
【０２２７】
［ステップＳ２３８］カバー率・マッチ率計算部１３３ａは、プロパティパス候補テーブル１１３に、算出したカバー率とマッチ率とを登録する。
［ステップＳ２３９］カバー率・マッチ率計算部１３３ａは、すべてのプロパティパスに対して処理が完了したら、カバー率・マッチ率計算処理を終了する。
【０２２８】
このようにして、カバー率とマッチ率とが計算される。
図４４は、カバー率・マッチ率の計算例を示す図である。図４４の例では、タプルテーブル１１１に登録されているタプルは３件であり、追加ＵＲＩテーブル１１５に登録されているＵＲＩは２件である。従って「Ａ＝５」となる。またプロパティパス計算テーブル１１２におけるプロパティパス「ex:姓名/ex:姓」の出現数は４件であり、「Ｂ＝４」となる。さらにプロパティパス計算テーブル１１２におけるプロパティパス「ex:姓名/ex:姓」のうち、同異が「同」の数は２件であり、「Ｃ＝２」となる。プロパティパス計算テーブル１１２におけるプロパティパス「ex:姓名/ex:姓」のうち、同異が「異」の数は１件であり、「Ｄ＝１」となる。その結果、カバー率は「４／５」となり、マッチ率は「２／３」となる。
【０２２９】
ここで、第２の実施の形態と同様の閾値（カバー率：０．６５、マッチ率：０．６）であった場合、通知部１４０は、プロパティパス「ex:姓名/ex:姓」を端末装置２００ａに通知する。
【０２３０】
図４５は、第２の実施の形態と第３の実施の形態とのカバー率・マッチ率の第１の比較例を示す図である。図４５の左側に第２の実施の形態におけるカバー率・マッチ率計算例を示し、図４５の右側に第３の実施の形態におけるカバー率・マッチ率計算例を示している。なお、ＲＤＦデータは、図１３に示すように更新されているものとする。
【０２３１】
第２の実施の形態では、十分な量のタプルが送信される（図４５の例では５件）ことで、カバー率「４／５」、マッチ率「３／４」を得ている。それに対して、第３の実施の形態では、少量のタプル（図４５の例では３件）と検索式が送信される。検索式に合致するＵＲＩがあれば、カバー率の分母「Ａ」にそのＵＲＩの数が加算される。また、検索式で新たに検出されたＵＲＩのうち、プロパティパスを辿った先に何らかの値が追加されているＵＲＩの数が、カバー率の分子「Ｂ」に加算される。その結果、カバー率「４／５」、マッチ率「２／３」を得ている。
【０２３２】
第３の実施の形態では、少量しかタプルを送信しないことでマッチ率の分母が小さくなるため、マッチ率の信頼性が第２の実施の形態より劣るものの、検索式を併用したことで、カバー率の分母「Ａ」が送信タプル数に比べ大きくなるため、第２の実施の形態と同様の信頼性のカバー率を得ることができる。その結果、第３の実施の形態でも、第２の実施の形態と同様に、開発者が利用しようとする目的の値が十分にＲＤＦデータに追加された適切なタイミングで、追加された値の位置を示すプロパティパスが通知される。
【０２３３】
なお図４５の例では、第３の実施の形態の処理については十分な量のタプルが送信されることを想定している。少量のタプルしか送信されない場合、第２の実施の形態ではカバー率の信頼性が低下してしまうが、第３の実施の形態のように検索式を利用することで、カバー率の信頼性の低下を抑止できる。以下、図４６、図４７を参照して、第３の実施の形態における、送信されるタプル数の低下時のカバー率の信頼性維持効果について説明する。
【０２３４】
図４６は、ＲＤＦデータに追加された値の数が少ない場合のプロパティパス計算テーブルの例を示す図である。図４６に示すように、ＲＤＦデータベース３２０内のグラフ３２１ｃ、３２３ｃが更新されているものとする。このときＵＲＩ「ex:P101」〜「ex:P103」の３つのタプルしか送信されないと、プロパティパス計算テーブル１１２には、２つのＵＲＩ「ex:P101」、「ex:P103」に対応するレコードしか登録されない。プロパティパス計算テーブル１１２への登録内容は、第２の実施の形態でも第３の実施の形態でも同じである。
【０２３５】
次に、図４６に示すプロパティパス計算テーブル１１２が生成されたときの第２の実施の形態と第３の実施の形態とのカバー率・マッチ率の違いについて説明する。
図４７は、第２の実施の形態と第３の実施の形態とのカバー率・マッチ率の第２の比較例を示す図である。図４７の左側に第２の実施の形態におけるカバー率・マッチ率計算例を示し、図４７の右側に第３の実施の形態におけるカバー率・マッチ率計算例を示している。
【０２３６】
第２の実施の形態では、少量のタプルしか送信されていないことで、カバー率「２／３」、マッチ率「２／２」となっている。閾値が「カバー率：０．６５、マッチ率：０．６」であるとすると、第２の実施の形態では、ＲＤＦデータに対して若干の値の追加しか行われていないにもかかわらず、プロパティパスを通知すると判断される。
【０２３７】
それに対して、第３の実施の形態では、少量のタプルしか通知されていないが、検索式を併用することで、カバー率「２／５」、マッチ率「２／２」となっている。するとカバー率が閾値未満となり、プロパティパスを通知しないと判断される。
【０２３８】
このように第３の実施の形態では、検索式を利用しているためカバー率の信頼性が向上し、不適切な通知が抑止される。
以上のように、第３の実施の形態では、検索式で多数のＵＲＩを取得できるため、カバー率の統計的信頼性が向上する。端末装置２００ａからは、送信するタプルの数が少数で済むため、開発者の負担を減らすことができる。
【０２３９】
〔第４の実施の形態〕
次に第４の実施の形態について説明する。第３の実施の形態では、カバー率の信頼性を向上させることはできるものの、通知されるタプル数が少なければ、マッチ率の統計的信頼性が低くなる。そこで、第４の実施の形態では、統計的な信頼性を全く損なわず、開発者の送信の負担を減らすことができるようにする。具体的には、プロパティパス候補通知装置において、開発者から少数のタプルと検索式を取得するのではなく、暫定モジュールと検索式を取得するようにする。
【０２４０】
図４８は、第４の実施の形態における各装置の機能を示すブロック図である。図４８において、第２の実施の形態と同じ機能の要素には、図４に示した第２の実施の形態の対応する要素と同じ符号を付し、説明を省略する。
【０２４１】
端末装置２００ｂの送信部２２０ｂは、タプルの送信に代えて、暫定モジュールと検索式とをプロパティパス候補通知装置１００ｂに送信する。例えば送信部２２０ｂは、開発者が入力した暫定モジュールと検索式とを、ラベルに対応付けてプロパティパス候補通知装置１００ｂに送信する。また送信部２２０ｂは、ＲＤＦデータ利用部から取得した検索式をプロパティパス候補通知装置１００ｂに送信するようにしてもよい。
【０２４２】
プロパティパス候補通知装置１００ｂの受信部１２０ｂは、端末装置２００ｂから送られた暫定モジュールと検索式とを受信する。受信部１２０ｂは、受信した暫定モジュールと検索式とを検索式・モジュールテーブル１１６に登録する。
【０２４３】
記憶部１１０ｂは、第２の実施の形態の記憶部１１０が記憶する各データテーブルに加え、検索式・モジュールテーブル１１６と一時ＵＲＩテーブル１１７とを記憶する。検索式・モジュールテーブル１１６は、暫定モジュールと検索式とを格納するデータテーブルである。一時ＵＲＩテーブル１１７は、検索式によって取得したＵＲＩを格納するデータテーブルである。
【０２４４】
プロパティパス計算部１３０ｂは、第２の実施の形態のプロパティパス計算部１３０が有する機能に加え、タプルテーブル生成部１３５を有する。タプルテーブル生成部１３５は、検索式を用いて、ＵＲＩをＳＰＡＲＱＬエンドポイント３００から取得する。そしてタプルテーブル生成部１３５は、取得したＵＲＩに基づいて、暫定モジュールを用いてタプルを生成し、生成したタプルをタプルテーブル１１１に登録する。
【０２４５】
なお、図４８に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図４８に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
【０２４６】
図４９は、検索式・モジュールテーブル１１６の一例を示す図である。検索式・モジュールテーブル１１６には、ラベルに対応付けて、検索式と暫定モジュールとが登録されている。検索式は、ＲＤＦデータの中から処理対象のＵＲＩを特定する条件が、ＳＰＡＲＱＬで記述されている。暫定モジュールは、ＲＤＦデータ内の所定の値から、ＲＤＦデータに未登録の他の値を推定するための処理手順が記述されたプログラムである。例えば図１１に示すように、人物の氏名の値から姓の値を推定するための処理手順が、暫定モジュールに記述されている。
【０２４７】
図５０は、一時ＵＲＩテーブルの一例を示す図である。一時ＵＲＩテーブル１１７には、タプルテーブル生成部１３５が、検索式・モジュールテーブル１１６にある検索式を用いて、ＳＰＡＲＱＬエンドポイント３００から取得したＵＲＩが格納される。
【０２４８】
以上のような構成のプロパティパス計算部１３０ｂにおける、第２の実施の形態と相違する処理について、以下に詳細に説明する。
図５１は、第４の実施の形態における受信処理の手順の一例を示すフローチャートである。以下、図５１に示す処理をステップ番号に沿って説明する。
【０２４９】
［ステップＳ３０１］受信部１２０ｂは、端末装置２００ｂから、ラベル、検索式、および暫定モジュールの組を受信したか否かを判断する。ラベル、検索式、および暫定モジュールの組を受信した場合、処理がステップＳ３０２に進められる。ラベル、検索式、および暫定モジュールの組を受信していなければ、ステップＳ３０１の処理が繰り返される。
【０２５０】
［ステップＳ３０２］受信部１２０ｂは、受信したラベル、検索式、および暫定モジュールの組を１つのレコードとして、検索式・モジュールテーブル１１６に登録する。
このようにして、プロパティパス候補通知装置１００ｂは、端末装置２００ｂから検索式と暫定モジュールとを取得する。その後、プロパティパス計算部１３０ｂによってプロパティパス計算処理が実行される。
【０２５１】
図５２は、第４の実施の形態におけるプロパティパス計算処理の手順の一例を示すフローチャートである。図５２に示した処理のうち、ステップＳ３１１，Ｓ３１２，Ｓ３１４〜Ｓ３１７の各処理は、図１４に示したステップＳ１３１〜Ｓ１３６の各処理と同じである。以下、図１４と異なるステップＳ３１３の処理について説明する。
【０２５２】
［ステップＳ３１３］プロパティパス計算部１３０ｂは、タプルテーブル生成部１３５に、タプルテーブル生成処理を実行させる。
図５３は、タプルテーブル生成処理の手順の一例を示すフローチャートである。以下、図５３に示す処理をステップ番号に沿って説明する。
【０２５３】
［ステップＳ３３１］タプルテーブル生成部１３５は、検索式・モジュールテーブル１１６からラベルに対応付けられた検索式を読み出し、その検索式を用いて、ＳＰＡＲＱＬエンドポイント３００に対してＵＲＩを問い合わせる。問い合わせを受けたＳＰＡＲＱＬエンドポイント３００は、ＲＤＦデータベース３２０から、検索式に合致するＵＲＩを検索し、該当するＵＲＩを応答する。
【０２５４】
［ステップＳ３３２］タプルテーブル生成部１３５は、ＳＰＡＲＱＬエンドポイント３００から取得したＵＲＩを、一時ＵＲＩテーブル１１７に登録する。
［ステップＳ３３３］タプルテーブル生成部１３５は、一時ＵＲＩテーブル１１７に登録されているＵＲＩごとに、ステップＳ３３４〜Ｓ３３５の処理を実行する。
【０２５５】
［ステップＳ３３４］タプルテーブル生成部１３５は、検索式・モジュールテーブル１１６からラベルに対応付けられた暫定モジュールを読み出し、処理対象のＵＲＩを引数として暫定モジュールを実行する。タプルテーブル生成部１３５は、暫定モジュールを実行することで、例えば、処理対象ＵＲＩから所定のプロパティパスを辿った先にある値をＳＰＡＲＱＬエンドポイント３００から取得する。そしてタプルテーブル生成部１３５は、取得した値に基づいて、開発者が利用しようとする目的の値の推定値を得る。例えば人物の「氏名」の値から「姓」の推定値が得られる。
【０２５６】
［ステップＳ３３５］タプルテーブル生成部１３５は、暫定モジュールの実行結果として得られた値にラベルと処理対象のＵＲＩとを付与し、タプルテーブル１１１に登録する。なお、実行結果が存在しない場合には、タプルテーブル１１１への登録は行わない。
【０２５７】
［ステップＳ３３６］タプルテーブル生成部１３５は、一時ＵＲＩテーブル１１７内のすべてのＵＲＩについて処理が完了したら、タプルテーブル生成処理を終了する。
図５４は、タプルテーブルの生成例を示す図である。図５４の例では、ＲＤＦデータベース３２０には、図６に示したようなＲＤＦデータが格納されているものとする。この場合、検索式４１を用いた検索により、５つのＵＲＩ「ex:P101」〜「ex:P105」が取得され、一時ＵＲＩテーブル１１７に格納される。一時ＵＲＩテーブル１１７に格納された各ＵＲＩについて暫定モジュール４２による処理を実行すると、「氏名」の値から「姓」を示す値が推定され、推定した値がタプルテーブル１１１にタプルとして登録される。なお、暫定モジュール４２には、図１１に示したような姓辞書２１１が含まれているものとする。
【０２５８】
このように、検索式４１と暫定モジュール４２とを用いることで、タプルテーブル１１１にタプルを登録し、第２の実施の形態と同じ内容のタプルテーブル１１１を生成することができる。その後の処理は第２の実施の形態と同様である。
【０２５９】
第４の実施の形態により、開発者にタプルを送信させることなく、暫定モジュールと検索式のみを送信させることで、マッチ率の統計的信頼性とカバー率の統計的信頼性を共に損なわずに、プロパティパスを評価することができる。その結果、開発者の負担をかけずに、適切なタイミングで、開発者が利用しようとする目的の値へのプロパティパスを端末装置２００ｂに通知することができる。
【０２６０】
〔その他の実施の形態〕
第２〜第４の実施の形態では、プロパティパス候補通知装置１００，１００ａ，１００ｂがＳＰＡＲＱＬエンドポイント３００とは別に設けられているが、プロパティパス候補通知装置１００，１００ａ，１００ｂを他の装置に内包させてもよい。例えば、ＳＰＡＲＱＬエンドポイント３００内にプロパティパス候補通知装置１００，１００ａ，１００ｂを設けることもできる。
【０２６１】
また第２〜第４の実施の形態では、カバー率とマッチ率との両方が閾値以上になったときにプロパティパスを通知しているが、カバー率とマッチ率との少なくとも一方が閾値以上になったときにプロパティパスを通知するようにしてもよい。
【０２６２】
さらにカバー率とマッチ率との閾値を多段階に設けることもできる。例えばカバー率とマッチ率とについて、それぞれ第１の閾値と第２の閾値を設ける。例えばプロパティパス候補通知装置１００，１００ａ，１００ｂは、カバー率とマッチ率とが共に第１の閾値以上となったときに１回目の通知を行う。そしてプロパティパス候補通知装置１００，１００ａ，１００ｂは、カバー率とマッチ率とが共に第２の閾値以上となったときに２回目の通知を行う。
【０２６３】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【０２６４】
以上の実施の形態に関し、さらに以下の付記を開示する。
（付記１）  コンピュータに、
複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得し、
前記複数のエンティティ、前記複数のエンティティそれぞれの特徴を示す値、および前記複数のエンティティと前記複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、前記複数のエンティティそれぞれを第１候補エンティティとし、いずれかの前記第１候補エンティティから前記関係情報を辿ることで到達可能な値の中に前記第１候補エンティティの第１推定値と同じ値が存在する場合、前記第１推定値と同じ値までに辿った１以上の関係情報を特定の関係情報とし、前記第１候補エンティティから前記特定の関係情報を辿った先の値が前記第１候補エンティティの前記第１推定値と同じとなる前記第１候補エンティティを第１エンティティとし、
前記データベースを参照し、前記複数のエンティティのうちの前記第１エンティティ以外のエンティティそれぞれを第２候補エンティティとし、前記第２候補エンティティから前記特定の関係情報を辿った先に前記第２候補エンティティの第２推定値と異なる値が存在する前記第２候補エンティティを第２エンティティとし、
前記第１エンティティの数と前記第２エンティティの数とに基づいて、前記複数のエンティティそれぞれの前記推定値と、前記複数のエンティティそれぞれから前記特定の関係情報を辿った先に存在する値との一致率を算出する、
処理を実行させる評価プログラム。
【０２６５】
（付記２）  前記コンピュータに、さらに、
前記複数のエンティティの数、前記第１エンティティの数、および前記第２エンティティの数に基づいて、前記複数のエンティティのうち、前記関係情報を辿った位置に値が存在するエンティティの割合を示す存在率を算出する、
処理を実行させる付記１記載の評価プログラム。
【０２６６】
（付記３）  前記コンピュータに、さらに、
前記複数のエンティティの共通の特徴を示す検索式を取得し、
前記データベースから、前記複数のエンティティ以外で前記検索式にヒットする追加エンティティを検出し、
前記データベースを参照し、前記追加エンティティのうち、前記特定の関係情報を辿った先に値が存在するエンティティを第３エンティティとし、
前記複数のエンティティの数、前記追加エンティティの数、前記第１エンティティの数、前記第２エンティティの数、および第３エンティティの数に基づいて、前記複数のエンティティのうち、前記関係情報を辿った位置に値が存在するエンティティの割合を示す存在率を算出する、
処理を実行させる付記１記載の評価プログラム。
【０２６７】
（付記４）  前記コンピュータに、さらに、
前記一致率および前記存在率が所定の条件を満たした場合、前記特定の関係情報を、ネットワーク経由で接続された他のコンピュータに通知する、
処理を実行させる付記２または３記載の評価プログラム。
【０２６８】
（付記５）  前記コンピュータに、さらに、
前記複数のエンティティの共通の特徴を示す検索式と、前記複数のエンティティに関連付けられた値に基づいて、前記複数のエンティティそれぞれの前記特定の特徴を示す値の前記推定値を得るプログラムモジュールとを取得し、
前記推定値の取得では、前記検索式により、前記データベース内の前記複数のエンティティを特定し、前記プログラムモジュールを実行することで、特定した前記複数のエンティティそれぞれの前記推定値を取得する、
処理を実行させる付記１乃至４のいずれかに記載の評価プログラム。
【０２６９】
（付記６）  コンピュータに、
複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得し、
前記複数のエンティティ、前記複数のエンティティそれぞれの特徴を示す値、および前記複数のエンティティと前記複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、前記複数のエンティティそれぞれを候補エンティティとし、いずれかの前記候補エンティティから前記関係情報を辿ることで到達可能な値の中に前記候補エンティティの前記推定値と同じ値が存在する場合、前記推定値と同じ値までに辿った１以上の関係情報を特定の関係情報とし、
前記データベースを参照し、前記候補エンティティから前記特定の関係情報を辿った先の値が前記候補エンティティの前記推定値と同じとなる前記候補エンティティの数と、前記候補エンティティから前記特定の関係情報を辿った先の値が前記候補エンティティの前記推定値と異なる前記候補エンティティの数とに基づいて、前記複数のエンティティそれぞれの前記推定値と、前記複数のエンティティそれぞれから前記特定の関係情報を辿った先に存在する値との一致率を算出する、
処理を実行させる評価プログラム。
【０２７０】
（付記７）  コンピュータが、
複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得し、
前記複数のエンティティ、前記複数のエンティティそれぞれの特徴を示す値、および前記複数のエンティティと前記複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、前記複数のエンティティそれぞれを第１候補エンティティとし、いずれかの前記第１候補エンティティから前記関係情報を辿ることで到達可能な値の中に前記第１候補エンティティの第１推定値と同じ値が存在する場合、前記第１推定値と同じ値までに辿った１以上の関係情報を特定の関係情報とし、前記第１候補エンティティから前記特定の関係情報を辿った先の値が前記第１候補エンティティの前記第１推定値と同じとなる前記第１候補エンティティを第１エンティティとし、
前記データベースを参照し、前記複数のエンティティのうちの前記第１エンティティ以外のエンティティそれぞれを第２候補エンティティとし、前記第２候補エンティティから前記特定関係情報を辿った先に前記第２候補エンティティの第２推定値と異なる値が存在する前記第２候補エンティティを第２エンティティとし、
前記第１エンティティの数と前記第２エンティティの数とに基づいて、前記複数のエンティティそれぞれの前記推定値と、前記複数のエンティティそれぞれから前記特定の関係情報を辿った先に存在する値との一致率を算出する、
評価方法。
【０２７１】
（付記８）  エンティティと前記エンティティの特徴を示す値との関連を示す関係情報を記憶する記憶部と、
複数のエンティティそれぞれの特定の特徴を示す値を推定した推定値を取得し、前記複数のエンティティ、前記複数のエンティティそれぞれの特徴を示す値、および前記複数のエンティティと前記複数のエンティティそれぞれの特徴を示す値との関係性を示す関係情報が格納されたデータベースを参照し、前記複数のエンティティそれぞれを第１候補エンティティとし、いずれかの前記第１候補エンティティから前記関係情報を辿ることで到達可能な値の中に前記第１候補エンティティの第１推定値と同じ値が存在する場合、前記第１推定値と同じ値までに辿った１以上の関係情報を、特定の関係情報として前記記憶部に格納し、前記第１候補エンティティから格納された前記特定の関係情報を辿った先の値が前記第１候補エンティティの前記第１推定値と同じとなる前記第１候補エンティティを第１エンティティとし、前記データベースを参照し、前記複数のエンティティのうちの前記第１エンティティ以外のエンティティそれぞれを第２候補エンティティとし、前記第２候補エンティティから格納された前記特定の関係情報を辿った先に前記第２候補エンティティの第２推定値と異なる値が存在する前記第２候補エンティティを第２エンティティとし、前記第１エンティティの数と前記第２エンティティの数とに基づいて、前記複数のエンティティそれぞれの前記推定値と、前記複数のエンティティそれぞれから前記特定の関係情報を辿った先に存在する値との一致率を算出する処理部と、
を有する評価装置。
【符号の説明】
【０２７２】
１  データベース
２  データ処理装置
１０  評価装置
１１  処理部
１２  記憶部
【図１】
2018060398.tif 000003
【図２】
2018060398.tif 000004
【図３】
2018060398.tif 000005
【図４】
2018060398.tif 000006
【図５】
2018060398.tif 000007
【図６】
2018060398.tif 000008
【図７】
2018060398.tif 000009
【図８】
2018060398.tif 000010
【図９】
2018060398.tif 000011
【図１０】
2018060398.tif 000012
【図１１】
2018060398.tif 000013
【図１２】
2018060398.tif 000014
【図１３】
2018060398.tif 000015
【図１４】
2018060398.tif 000016
【図１５】
2018060398.tif 000017
【図１６】
2018060398.tif 000018
【図１７】
2018060398.tif 000019
【図１８】
2018060398.tif 000020
【図１９】
2018060398.tif 000021
【図２０】
2018060398.tif 000022
【図２１】
2018060398.tif 000023
【図２２】
2018060398.tif 000024
【図２３】
2018060398.tif 000025
【図２４】
2018060398.tif 000026
【図２５】
2018060398.tif 000027
【図２６】
2018060398.tif 000028
【図２７】
2018060398.tif 000029
【図２８】
2018060398.tif 000030
【図２９】
2018060398.tif 000031
【図３０】
2018060398.tif 000032
【図３１】
2018060398.tif 000033
【図３２】
2018060398.tif 000034
【図３３】
2018060398.tif 000035
【図３４】
2018060398.tif 000036
【図３５】
2018060398.tif 000037
【図３６】
2018060398.tif 000038
【図３７】
2018060398.tif 000039
【図３８】
2018060398.tif 000040
【図３９】
2018060398.tif 000041
【図４０】
2018060398.tif 000042
【図４１】
2018060398.tif 000043
【図４２】
2018060398.tif 000044
【図４３】
2018060398.tif 000045
【図４４】
2018060398.tif 000046
【図４５】
2018060398.tif 000047
【図４６】
2018060398.tif 000048
【図４７】
2018060398.tif 000049
【図４８】
2018060398.tif 000050
【図４９】
2018060398.tif 000051
【図５０】
2018060398.tif 000052
【図５１】
2018060398.tif 000053
【図５２】
2018060398.tif 000054
【図５３】
2018060398.tif 000055
【図５４】
2018060398.tif 000056