以下、本発明の実施の形態を図面に基づいて説明する。先ず、ダイナミック・パブリッシングについて、システム構成例を用いて説明する。図1は、システム構成例を示す図である。図1において、システム1000は、端末3と、サーバ装置100と、LOD(Linked Open Data)クラウド500を構成するLODサーバ装置200とを有する。
端末3は、ユーザによって利用される情報処理装置であり、インターネット2を介して、サーバ装置100、LODクラウド500の複数のLODサーバ装置200にアクセス可能である。端末3は、サーバ装置100から所望のページ4pを表示するための定義情報を取得し、取得した定義情報を用いて、LODクラウド500からデータ収集して統計し、その統計結果を示すガジェット4gを含むページ4pを生成して表示する。
ページ4pは、複数のガジェット4gを含み、ダイナミック・パブリッシングの技術により作成されるWebページである。各ガジェット4gでは、当該ガジェット4gで記述されるクエリによりLODクラウド500内のLODサーバ装置200が保持するデータベース205にアクセスしてデータを抽出し、抽出したデータの統計情報に基づくグラフ表示等が行われる。
サーバ装置100は、ページ4p毎のページ画面定義を記憶した定義情報記憶部2を有し、インターネット2を介して、端末3からのページ4pの定義情報の要求に応じて、定義情報を端末3に提供する。定義情報は、メタデータで記述され定義情報記憶部2内に保持されている。
LODクラウド500は、複数のLODサーバ装置200により構成され、それぞれのLODサーバ装置200により様々な種類のデータが提供可能に管理されている。LODサーバ装置200は、提供可能なデータを蓄積したデータベース205を有し、端末3からのクエリに応じてデータベース205から抽出したデータを提供する。データベース205は、RDF(Resource Description Framework)データ等を蓄積したRDFストアに相当する。
ページ4pに含まれる各ガジェット4gには、通常、複数のクエリが記述されている。以下、複数のクエリを「クエリ集合」という。クエリ集合が大きくなると、インターネット2を介した検索回数が増大する。
従って、クエリ集合から共通となる部分を特定し、特定した共通となる部分と、非共通の部分による問合せを包含する記載とにより「共通クエリ」を定める。定めた共通クエリで、クエリ集合内で共通に検索される中間結果を取得した後、クエリ集合内の各クエリを中間結果に対して実行して、最終的な解を得ることで、インターネット2を介したLODクラウド500に対するデータ検索(問い合わせ)の回数を削減することができる。このような考え方に基づき、共通クエリの生成方法について検討する。
先ず、この分野の専門家が容易に思いつくであろう方法として、
・方法A
クエリの知識のある者によって、共通クエリを記述し、予め用意しておくことが考えられる。この場合の課題は以下の通りである。
課題1:取得したいデータ項目が増えた場合、ページ4p内のガジェット4gを増やしたい場合等の状況ごとに、共通クエリは書き換えなければならない。
・方法B
共通クエリを自動的に作成することが考えられる。この場合の課題は以下の通りである。
課題2-1(図2(A)):ガジェット定義が多くなる程、すべてのガジェット間で共通するクエリの記述を抽出するための比較処理の負荷が大きくなる。
課題2-2(図2(B)):全ての3つ組条件で比較を行うため、効率が悪い。
図2を参照して方法Bの課題2-1及び課題2-2について説明する。図2は、比較処理の負担を説明するための図である。図2(A)に示す一例を用いて、課題2-1を説明する。一例として、ガジェット数「6」の場合には3つ組条件の比較数は「15(=6C2)」、ガジェット数「100(=100C2)」の場合には3つ組条件の比較数は「4、950」、ガジェット数「200(=200C2)」の場合には3つ組条件の比較数は「19,900」等となる。ガジェット数の増加は、3つ組条件の比較数を大幅に増加させる。
また、図2(B)に示す一例を用いて課題2-2を説明する。図2(B)では、ガジェット4g-1と4g-2のクエリの記述例を示している。Linked Dataを検索するためのRDFクエリ言語として一般的なSPARQL(Protocol and RDF Query Language)で記述された例として示しているが、記述言語はSPARQLに限定されない。この記述例では、where節に6行で列挙されているそれぞれの記述文が3つ組条件を表現している。
ガジェット4g-1及び4g-2共に、3つ組条件数「6」の場合を示している。この場合、ガジェット4g-1内の各3つ組条件に対して、ガジェット4g-2の全3つ組条件との比較が行われる。従って、比較処理は36回行われる。
次に、端末3で行われるダイナミック・パブリッシングについて説明する。図3は、ダイナミック・パブリッシングの概要を説明するための図である。図3において、本実施例では、端末3では、サーバ装置100によって提供される画面から、ユーザが「視点」と「観点」とを指定することにより、ダイナミック・パブリッシングが行われる。
ユーザの「視点」と「観点」の指定に応じて、サーバ装置100の定義情報記憶部105から、対応するページ4pを作成するための定義情報107が選択される。
「視点」とは、注目するエンティティ(実体)を意味し、視点として、企業名、人命、技術用語、イベント等がユーザにより指定される。「観点」では、エンティティをどのように見るかが指定される。特定の調達が視点として指定された場合、発注者、受注者等が観点として指定される。また、特定の製品が視点として指定された場合、製造者等が観点として指定される。視点及び観点とによって、ページ4pを特定するURI(Uniform Resource Identifier)が決定する。URIは、Web空間で資源(リソース)を一意に識別する識別子である。
サーバ装置100の定義情報記憶部105には、ガジェットA、B、C等を含む複数のガジェット4g、ガジェット4gを含むページ4pごとの定義情報107等が記憶されている。各定義情報107は、ページ4pにおいて注目する視点と、視点に係る観点とに応じた、ページ4pに含むガジェットを定義している。
端末3は、定義情報107を受信すると、後述する本実施例に係る処理を行うことでダイナミック・パブリッシング300を実行する。ダイナミック・パブリッシング300では、主に、定義情報107に含まれる各クエリを実行し、LODクラウド500からデータを集約する。行政法人ポータル200a、オープンデータサイト200b等からデータを集約する例を示しているが、これら以外の様々なサイトからインターネット2を介してデータを集約してもよい。
定義情報107に従って集約したデータを用いて統計処理が行われ、ページ4p内に、2以上のタイプの異なるグラフが描画され画面表示される。「観点」の違いにより異なる定義情報107が選択されるため、様々な異なるページ4pの表示が行われる。
このように本実施例では、1つのページ4pはある観点に基づいて作成される、ことに着目し、サーバ装置100では、観点に応じて定義情報107が作成される。一方で、同じガジェット4gであっても異なる観点に用いられる場合には、それぞれに固有のグラフ表示が行われる。
「ある観点に基づく」ページ4pの一例として、様々な情報源から集めたデータを、統計を表すグラフ等により可視化する一般的なダッシュボードが考えられる。ダッシュボードでは、ページ4p内は類似又は関連した情報を可視化することが多い。そのため、重複した問い合わせを行う可能性が高い。本実施例では、共通の問い合わせが多いことを利用する。
また、発明者は、上述した比較処理において、ガジェット4g内の各3つ組条件が型で記述されることに注目し、型を考慮することで比較回数を削減可能とした。
型の要素である主語(S)、目的語(O)、及び述語(P)は、それぞれ変数又は定数で示される。つまり、発明者は、主語(S)、目的語(O)、及び述語(P)のそれぞれが変数又は定数であるのかを示す型ごとに比較処理を行えば、比較回数を削減できることに着目した。
発明者による着眼ポイントは、以下のように示される。
<ポイント1>
選択された定義情報107に関連付けられる複数のガジェット4gのみに注目する。
<ポイント2>
ガジェット4g内の3つ組条件の主語(S)、目的語(O)、及び述語(P)のそれぞれの種別が変数又は定数であるかのを示す型ごとに比較処理を行うことで、ガジェット4gから共通するクエリ(共通クエリ)の抽出を簡潔化する。
図4は、本実施例における比較処理の概要を説明するための図である。図4において、本実施例では、定義情報107に含まれるガジェット4g-1と4g-2とを比較対象とし、クエリを解析し、各3つ組条件を型に基づいて変数か定数かを示す型を判定する。型を判定する手法は、後述される。
型を考慮することで、分類5Aに対するガジェット4g-1と4g-2との間の比較は1回となり、分類5Bに対するガジェット4g-1と4g-2との間の比較は10回となる。結果、合計して12回の比較回数となる。図2(B)では36回であったのに対して、大幅に比較回数を削減できる。
図5は、本実施例における端末によるLODクラウドへのデータ検索処理の概要を説明するための図である。図5において、端末3では、サーバ装置100から取得したページαの定義情報107aのガジェット4g-1と4g-2とに対して、クエリまとめ処理330が行われる。
クエリまとめ処理330によって共通クエリ8を得ると、共通クエリ8を用いたデータ検索(問い合わせ)がLODクラウド500に対して1回行われ、端末3は、データベース205から中間結果9を得る。
次に、ページαの定義情報107aに含まれるガジェット4g-1及び4g-2のクエリを用いて、端末3が取得して保持している中間結果9に対してデータ検索(問い合わせ)を行う。そして、得られたデータを用いて統計情報を得ると、ページα内に定義されたガジェット4g-1及び4g-2それぞれの画面にグラフが表示される。
この例において、ガジェット4g-1内の記述5g-1のコードC2101はページαに表示される文字列「事業所数」に対応し、ガジェット4g-2内の記述5g-2のコードC2102はページαに表示される文字列「人口」に対応する。
中間結果9には、共通クエリ8を用いたデータ検索によって、全てのコードに対応するデータが集約される。その中から、コードを特定してデータ検索することにより、文字列「事業所数」、「人口」等のデータが抽出される。
上述したようなデータ検索処理を行う端末3は、図6に示すようなハードウェア構成を有する。図6は、端末のハードウェア構成を示す図である。図6において、端末3は、コンピュータによって制御される情報処理装置であって、CPU(Central Processing Unit)11と、主記憶装置12と、補助記憶装置13と、入力装置14と、表示装置15と、通信I/F(インターフェース)17と、ドライブ装置18とを有し、バスBに接続される。
CPU11は、主記憶装置12に格納されたプログラムに従って端末3を制御するプロセッサに相当する。主記憶装置12には、RAM(Random Access Memory)、ROM(Read Only Memory)等が用いられ、CPU11にて実行されるプログラム、CPU11での処理に必要なデータ、CPU11での処理にて得られたデータ等を記憶又は一時保存する。
補助記憶装置13には、HDD(Hard Disk Drive)等が用いられ、各種処理を実行するためのプログラム等のデータを格納する。補助記憶装置13に格納されているプログラムの一部が主記憶装置12にロードされ、CPU11に実行されることによって、各種処理が実現される。記憶部130は、主記憶装置12と、補助記憶装置13とを有する。
入力装置14は、マウス、キーボード等を有し、ユーザが端末3による処理に必要な各種情報を入力するために用いられる。表示装置15は、CPU11の制御のもとに必要な各種情報を表示する。入力装置14と表示装置15とは、一体化したタッチパネル等によるユーザインタフェースであってもよい。通信I/F17は、有線又は無線などのネットワークを通じて通信を行う。通信I/F17による通信は無線又は有線に限定されるものではない。
ドライブ装置18は、ドライブ装置18にセットされた記憶媒体19(例えば、CD-ROM(Compact Disc Read-Only Memory)等)と端末3とのインターフェースを行う。
端末3によって行われる処理を実現するプログラムは、例えば、CD-ROM等の記憶媒体19によって端末3に提供される。記憶媒体19に、後述される本実施の形態に係る種々の処理を実現するプログラムを格納し、この記憶媒体19に格納されたプログラムは、ドライブ装置18を介して端末3にインストールされる。インストールされたプログラムは、端末3により実行可能となる。
尚、プログラムを格納する記憶媒体19はCD-ROMに限定されず、コンピュータが読み取り可能な、構造(structure)を有する1つ以上の非一時的(non-transitory)な、有形(tangible)な媒体であればよい。コンピュータ読取可能な記憶媒体として、CD-ROMの他に、DVD(Digital Versatile Disk)ディスク、USBメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリであっても良い。
図7は、端末の機能構成例を示す図である。図7において、端末3は、ページ定義処理部310と、クエリまとめ処理部320とを有する。ページ定義処理部310と、クエリまとめ処理部320とによって、ダイナミック・パブリッシング300が実現される。ページ定義処理部310と、クエリまとめ処理部320とは、端末3にインストールされたプログラムが、端末3のCPU11に実行させる処理により実現される。
ページ定義処理部310は、インターネット2を介してサーバ装置100からページαの定義情報107aを取得して入力し、クエリまとめ処理部320へ通知する。サーバ装置100から取得したページαの定義情報107aは、記憶部130に保持される。ページαの定義情報107aには、ガジェットA、B、及びCが定義されている。
また、ページ定義処理部310は、一時クエリ保存部329に共有クエリ8により中間結果9の格納されると、ページαの定義情報107aを用いて一時クエリ保存部329をデータ検索し、ガジェットA、B、及びCのそれぞれの画面にグラフを描画して、ページαを表示装置15に表示させる。
クエリまとめ処理部320は、ページαの定義情報107a内のガジェットA、B、Cから共通クエリ8を決定して、決定した共通クエリ8でLODクラウド500に対してデータ検索を行う処理部であり、クエリ分類部321と、実行管理部323とを有する。
クエリ分類部321は、ページαの定義情報107a内のガジェットA~Cに記載される3つ組条件を、3つの要素が変数又は定数を示す型毎に分類する。クエリ分類部321は、型毎に、クエリから共通となる部分を特定し、特定した共通となる部分と、非共通の部分による問合せを包含する記載とにより共通クエリ8を作成する。
実行管理部323は、LODクラウド500に対して、共通クエリ8を用いたデータ検索を行い、データを集約して一時クエリ保存部329に記憶する。一時クエリ保存部329は、記憶部130の一部に相当する。また、実行管理部323は、ガジェットA、B、Cのそれぞれのクエリで、一時クエリ保存部329に対してデータ検索を行う。ガジェットA、B、Cのそれぞれの検索結果データ328が記憶部130に出力され格納される。
ページ定義処理部310は、記憶部130に記憶された検索結果データ328を参照して、統計情報を作成してグラフを描画する。ページαが、表示装置15に表示される。一時クエリ保存部329に対するデータ検索では、ガジェットA~Cに含まれる全てのクエリで行われるが、一時クエリ保存部329は、端末3の記憶部130に存在するため、ネットワーク通信を行うことなく、効率的に所望のデータを集約することができる。
図8を参照して、本実施例におけるクエリまとめ処理部320が存在しない場合の比較例として機能構成例を説明する。図8は、クエリまとめ処理部が存在しない比較機能構成例を示す図である。
図8では、図7に示すクエリまとめ処理部320が存在しない。そのため、ページ定義処理部310は、ガジェットA~Cに記載の各クエリを、インターネット2を介してLODクラウド500に対して行う。従って、データ検索がクエリの数だけ繰り返され、ネットワーク通信に係る処理、データ集約に係る時間等の負担が、図7に示す本願発明における機能構成に比べて大きいと言える。
次に、図9~図15を参照して、クエリまとめ処理部320による処理を説明する。先ず、ガジェットプログラムの入力について説明する。
図9は、ガジェットプログラムの入力を説明するための図である。図9では、ユーザが、「視点」として「神奈川県川崎市中原区」を指定し、「観点」として「地域」を指定した場合に、ページ4pに関連付けられるガジェット4gが4つある場合を示している。
この例では、視点「神奈川県_川崎市_中原区」の選択により「http://lod4all.net/resource/神奈川県_川崎市_中原区」が特定され、観点「地域」の選択により「http://lod4all.net/ontology/Geo」が特定され、視点と観点とが対応付けられる。ここで「Geo」が観点に相当している。
サーバ装置100から提供される「視点」及び「観点」の一覧により、ユーザに選択可能な画面を端末3に表示することで、選択させるようにしてもよい。選択により、ユーザが所望するページ4pの定義情報107に関連付けられるガジェット4gを取得する。
具体的には、「http://lod4all.net/ontology/Geo」に関連付けられる4つのガジェットプログラムが取得され、クエリまとめ処理部320へ入力される。以下の説明では、単に、ガジェットPP1~PP4という。ガジェットPP1~PP4はそれぞれ異なる3つ組条件を表すクエリが記載されている。
図10は、取得時のガジェットのクエリの記載例を示す図である。図10において、クエリまとめ処理部320のクエリ分類部321は、ガジェットPP1~PP4の全ての3つ組条件の記載を対象に、要素ごとに種別を示す型を決定する。主語(S)と目的語(O)は、述語(P)によりリンクされる形式で記述されるため、主語(S)、述語(P)、目的語(O)の順に各要素の種別(定数又は変数)を判断する。
主語(S)、述語(P)、目的語(O)のそれぞれが、
・定数であれば大文字
・変数であれば小文字
で種別を示す型を表す。全て定数であれば<S、P、O>と表し、全て変数であれば<s、p、o>と表す。
クエリ分類部321は、ガジェットPP1~PP4のうちガジェットPP1から3つ組条件ごとに種別を判定し、型を決定する。ガジェットPP1のwhere節内の1番目の3つ組条件は、
「l4a-geo:神奈川県_川崎市_中原区 rdfs:seeAlso ?geojp.」
である。主語(S)の「l4a-geo:神奈川県_川崎市_中原区」は定数である。述語(P)の「rdfs:seeAlso」は定数である。また、目的語(O)の「?geojp」は変数である。従って、種別を示す型は、
<S、P、o>
である。この種別の型<S、P、o>に属する3つ組条件のIDをG1xxで表すものとする。1番目の3つ組条件にID「G101」を付与する。
このように要素ごとに種別を判断すると、2番目の3つ組条件「l4a-geo:神奈川県_川崎市_中原区 rdfs:label ?label.」の型は、1番目と同様に、
<S、P、o>
である。2番目の3つ組条件にID「G102」を付与する。
3番目の3つ組条件「?refArea sdmx-2009:dimension#refArea ?geojp.」の型は、1番目及び2番目とは異なり、
<s、P、o>
となる。この型に属する3つ組条件のIDをG2xxで表すものとする。3番目の3つ組条件にID「G201」を付与する。
4番目の3つ組条件「?refArea wb270a-prop:indicator gn-jp:C2101.」の型は、1番目、2番目、及び3番目とも異なり、
<s、P、O>
となる。この型に属する3つ組条件のIDをG3xxで表すものとする。4番目の3つ組条件にID「G301」を付与する。
5番目の3つ組条件「?refArea sdmx-2009:measure#obsValue ?value.」の型は、
<s、P、o>
となり、既に作成済みであるため、ID「G202」が付与される。
6番目の3つ組条件「?refArea sdmx-2009:dimension#refPeriod ?year.」の型は、
<s、P、o>
となり、既に作成済みであるため、ID「G203」が付与される。よって、ガジェットPP1の全ての3つ組条件に対して分類分けが終了する。同様にガジェットPP2~PP4の各3つ組条件についても分類分けを行うと、図11に示す分類結果を得る。
図11は、分類結果を表す図である。図11に示すように、各型ごとに、テーブルが記憶部130に作成され、ID、3つ組条件、クエリ情報等の項目を有する。IDはテーブル内でどの3つ組条件であるか特定し、3つ組条件は分類された3つ組条件の記述を示し、クエリ情報は3つ組条件が記述されているガジェットプログラムを特定する識別子を示す。この例では、クエリ情報には、識別子として、PP1、PP2、PP3、PP4のいずれかが指定される。
上述した<S、P、o>、<s、P、o>、及び<s、P、O>の3つが、ガジェットPP1~PP4を分類して得られた3つ組条件グループに相当する。3つ組条件グループごとに、テーブルが作成され記憶部130に記憶される。図11では、<S、P、o>、<s、P、o>、及び<s、P、O>のそれぞれの3つ組条件グループに対して、<S、P、o>テーブルT341、<s、P、o>テーブルT342、及び<s、P、O>テーブルT343が作成される例を示している。
図11を参照すると、<S、P、o>テーブルT341では、ID「G101」の3つ組条件は「l4a-geo:神奈川県_川崎市_中原区 rdfs:seeAlso ?geojp」であり、クエリ情報には「PP1、PP2、PP3、PP4」が示されている。同一のグラフパタンがガジェットPP1、PP2、PP3、及びPP4に存在することを示している。
また、ID「G102」の3つ組条件は「l4a-geo:神奈川県_川崎市_中原区 rdfs:label ?label」であり、クエリ情報により、同一のグラフパタンがガジェットPP1、PP2、PP3、及びPP4に存在することを示している。
<s、P、o>テーブルT342では、ID「G201」の3つ組条件は「?refArea sdmx-2009:dimension#refArea ?geojp」であり、クエリ情報により、同一のグラフパタンがガジェットPP1、PP3、PP4に存在することを示している。<s、P、o>テーブルT342では、更に、ID「G202」から「G206」のそれぞれに対して、3つ組条件とクエリ情報とが対応付けられている。ID「G204」から「G206」のそれぞれに対してクエリ情報では、ガジェットPP1、PP2、PP3、そしてPP4が示され、即ち、1つのガジェットプログラムのみが対応付けられている。
<s、P、O>テーブルT343では、ID「G301」の3つ組条件は「?refArea wb270a-prop:indicator gn-jp:C2101」であり、クエリ情報によりPP1のみが示され、同一のグラフパタンが記載されているガジェットプログラムは無いことが分かる。<s、P、O>テーブルT343では、更に、ID「G302」から「G304」のそれぞれに対して、3つ組条件とクエリ情報とが対応付けられている。この例では、各IDに対してクエリ情報では1つのガジェットプログラムのみが対応付けられている。
クエリ分類部321は、このようなテーブルT341~T343のそれぞれごとに、3つ組条件を比較する。比較は、同一の要素間で行う。つまり、クエリ分類部321は、主語(S)、述語(P)、及び目的語(O)のそれぞれで記述が一致するか否かを判定し、まとめ可否を判断する。図12及び図13を参照して、クエリ分類部321によるまとめ処理について説明する。
図12は、クエリ分類部によるまとめ処理(その1)を説明するための図である。図12において、クエリ分類部321は、同一テーブル内の3つ組条件同士の比較を要素単位で行う。3つ組条件の「まとめ判断ルール」は、以下の通りである。
[まとめる場合]
[A1]定数又は変数に係らず全ての要素が3つ組条件同士で一致する場合は、いずれか一方の3つ組条件を選択して1つの3つ組条件にまとめる。
[A2]変数の要素が3つ組条件同士で一致しない場合に、当該要素を除外することで3つ組条件同士が一致するときは、いずれか一方の3つ組条件を選択して1つの3つ組条件にまとめる。つまり、少なくとも1つの要素が定数であって3つ組条件同士で一致すれば、1つの3つ組条件にまとめる。
[まとめない場合]
[B1]全ての要素が定数であって3つ組条件同士で一致しない場合は、3つ組条件同士をまとめない。
[B2]変数の要素が3つ組条件同士で一致しない場合に、当該要素を除外しても3つ組条件同士で一致しないときは、3つ組条件同士をまとめない。つまり、定数の要素の1つ以上で3つ組条件同士で一致しない場合は、1レコードにまとめない。
上述した「まとめ判断ルール」における「まとめる」は、「共通化する」ことに相当する。また、「共通化する」とは、2以上の3つ組条件で検索されるデータを包含して検索可能な3つ組条件を作成することに相当する。
このようなまとめ判断ルールに従うと、<S、P、o>テーブルT341では、ID「G101」及び「G102」の3つ組条件は上述した[まとめない場合]の[B1]に相当する。従って、<S、P、o>テーブルT341は更新されない。
<s、P、o>テーブルT342では、変数の主語(S)を除外することで、ID「G201」と「G204」の3つ組条件同士が一致する。また、変数の目的語(O)を除外することで、ID「G202」と「G206」の3つ組条件同士が一致する。更に、変数の主語(S)及び目的語(O)を除外することで、ID「G203」と「G205」の3つ組条件同士が一致する。これらは、[まとめる場合]の[A2]に相当する
次に、<s、P、O>テーブルT343では、ID「G301」~「G304」の全てにおいて、主語(S)が変数であり、述語(P)及び目的語(O)が定数である。定数の目的語(O)が、全ての3つ組条件で一致しない。従って、上述した[まとめない場合]の[B2]に相当する。従って、<s、P、O>テーブルT343は更新されない。
上述したような、クエリ分類部321による処理により、<S、P、o>テーブルT341、<s、P、o>テーブルT342、及び<s、P、O>テーブルT343のそれぞれに対する更新状態を図13に示す。
図13は、クエリ分類部によるまとめ処理(その2)を説明するための図である。図13において、図12に説明したまとめ結果に基づいて、特に、<s、P、O>テーブルT343に対する更新方法を説明する。
図12で説明したように、ID「G201」とID「G204」の3つ組条件は1つにまとめることができる。具体的には、ID「G204」のレコードのクエリ情報にID「G204」のクエリ情報「PP2」を追加する。追加する際、除外した変数の要素がどの変数に対応するかを記録する。「PP2(?ref:?refArea)」のようにID「G201」のクエリ情報に追加する。その後、ID「G204」のレコードを削除する。
追加方法の一例として、「PP2(?ref:?refArea)」の場合、ガジェットプログラムの識別子「PP2」に加えて、かっこ内にPP2での変数と、ID「G201」の3つ組条件内の変数とを":"を用いて対応付けて記載する。
また、ID「G202」とID「G206」の3つ組条件は1つにまとめることができる。ID「G202」とID「G206」の3つ組条件の比較では、変数である目的語(O)を除外することで一致したため、ID「G202」のレコードのクエリ情報に、「PP4(?val:?value)」を追加する。ID「G206」のレコードを削除する。
更に、ID「G203」とID「G205」の3つ組条件は1つにまとめることができる。ID「G203」とID「G205」の3つ組条件の比較では、変数である主語(S)と目的語(O)とを除外することで一致したため、ID「G203」のレコードのクエリ情報に、「PP2(?ref:?refArea,?y:?year)」を追加する。ID「G205」のレコードを削除する。
このように要素の種別(変数/定数)に基づく型ごとに3つ組条件をまとめた後、共通クエリ8を作成する。クエリ分類部321による、共通クエリ8を作成する共通クエリ作成処理について、図14及び図15を参照して説明する。
図14は、クエリ分類部による共通クエリ作成処理(その1)を説明するための図である。図14において、クエリ分類部321は、各テーブルT341~T343のクエリ情報を参照して、ガジェットプログラムの識別子が1つしかない<s、P、O>テーブルT343を対象外とし、<S、P、o>テーブルT341と<s、P、o>テーブルT342とを参照して、まず共通クエリ8を作成する。
クエリ分類部321は、共通クエリ8の領域を記憶部130内に獲得し、<S、P、o>テーブルT341から3つ組条件の記載を読み込んで共通クエリ8のwhere節内に挿入する。次に、クエリ分類部321は、<s、P、o>テーブルT342から3つ組条件の記載を読み込んで共通クエリ8のwhere節内に挿入する。その後、目的語(O)の変数をselect文に列挙してwhere節前に挿入する。
したがって、
select ?year ?geojp ?value where {
l4a-geo:神奈川県_川崎市_中原区 rdfs:seeAlso ?geojp.
l4a-geo:神奈川県_川崎市_中原区 rdfs:label ?label.
?refArea sdmx-2009:dimension#refArea ?geojp.
?refArea sdmx-2009:measure#obsValue ?value.
?refArea sdmx-2009:dimension#refPeriod ?year.
} ORDER BY ?year
のような共通クエリ8が、記憶部130に作成される。where節の後に"ORDER BY ?year"を追加しておくことで、検索したデータは年順にソートされ、効率的にデータを利用できる。
次に、対象外とした<s、P、O>テーブルT343に対して、図15で説明するような処理が行われる。図15は、クエリ分類部による共通クエリ作成処理(その2)を説明するための図である。図15では、クエリ分類部321は、図13で説明した":"を用いた変数の対応付けを「変数変換規則」として参照する。
具体的には、クエリ分類部321は、<s、P、o>テーブルT342から、「?ref:?refArea」と「?ref:?refArea,?y:?year」とを特定して、
・「?ref:?refArea」から「?ref」を「?refArea」に置き換える、
・「?y:?year」から「?y」を「?year」に置き換える
変数変換規則を取得する。クエリ分類部321は、得られた変数変換規則に従って、G302の3つ組条件の「?ref」を「?refArea」に変換する。
次に、クエリ分類部321は、定数の要素の異なる値に対して、変数に置き換える。具体的には、この例では、目的語(O)がID「G301」から「G304」までそれぞれ違う値を示している。この目的語(O)を変数に置き換える。一例として「?o001」に置き換えた例を示すが、この例に限定されず、どのような変数であってもよい。
よって、ID「G301」から「G304」の全ての3つ組条件に対して、
「?refArea wb270a-prop:indicator ?o001」
のような3つ組条件8hを得る。クエリ分類部321は、得られた3つ組条件を共通クエリ8のwhere節内の最後に追加し、目的語(O)を置き換えた変数をselect文に追加する。
全てのテーブル(3つ組条件グループ)を共通化すると、クエリ分類部321は、共通クエリ8を実行管理部323へと通知する。また、クエリ分類部321は、記憶部130に作成した<S、P、o>テーブルT341、<s、P、o>テーブルT342、及び<s、P、O>テーブルT343を削除してもよい。
次に、実行管理部323による実行管理処理について説明する。図16は、実行管理部による実行管理処理を説明するための図である。図16において、実行管理部323は、クエリ分類部321によって作成された共通クエリ8を用いて、LODクラウド500にデータ検索を行い、得られたデータを中間結果9として一時クエリ保存部329に格納する。LODクラウド500へのデータ検索は、ガジェットPP1~PP4に関して1回のみである。
次に、実行管理部323は、ガジェットPP1~PP4のそれぞれのクエリを用いて、一時クエリ保存部329に対してデータ検索を行って得られた検索結果データ328を記憶部130に記憶する。
検索結果データ328の取得に応じて、クエリまとめ処理部320は、ページ定義処理部310へデータ検索の完了を通知する。データ検索の完了通知に応じて、ページ定義処理部310は、ガジェットPP1~PP4のそれぞれの統計情報を取得してグラフを生成し、1つのページ4p内に配置されたガジェット毎の画面にグラフを描画して表示する。
図17は、3つ組条件でのデータ検索例を示す図である。図17において、共通クエリ8のうち3つ組条件「?refArea wb270a-prop:indicator ?o001」を例として、ガジェットPP1でデータ検索した場合の概念を示している。
3つ組条件「?refArea wb270a-prop:indicator ?o001」を用いてLODクラウド500から得られた中間結果9には、一例として、神奈川県川崎市中原区に関する様々な統計情報を得るためのデータが含まれている。具体的には、「gn-jp:C2101」、「gn-jp:C4101」、「gn-jp:C2102」、「gn-jp:C3581」、「gn-jp:C2104」等に相当する値が示されている。値の例として、事業所数、人口等がある。
このような中間結果9を保持する一時クエリ保存部329に対して、ガジェットPP1でデータ検索した場合、一時クエリ保存部329の中間結果9のうち、「l4a-geo:神奈川県_川崎市_中原区」を示し、かつ、「wb270a-prop:indicator」によってリンクされる「gn-jp:C2101」の値が特定される。ガジェットPP1によるデータ検索では、図17に示されるように3つのノードが返却される。
一時クエリ保存部329に保持されたデータは、ガジェットPP1~PP4によるデータ検索によって抽出されるデータを含んでいる。
次に、クエリまとめ処理部320によって行われる処理について説明する。図18は、クエリまとめ処理部による処理全体の概要を説明するためのフローチャート図である。図18において、クエリ分類部321は、ページ定義処理部310から、ユーザが所望するページに係る定義情報107を受信すると、各ガジェット4gからクエリを抽出し、各クエリに記載された3つ組条件を型ごとに分類する(ステップS501)。定義情報107は、ユーザが指定した観点に係るページ4pを作成するための複数のガジェット4gを含む。
型は主語(O)、述語(P)、及び目的語(O)の要素を有し、各要素が定数又は変数であるかを表した型ごとに3つ組条件が分類され、グループを形成する。形成されたグループを、「3つ組条件グループ」という。3つ組条件グループに対応するテーブルが記憶部130に記憶される(図11)。
クエリ分類部321は、各3つ組条件グループ内で、上述した「まとめ判断ルール」に従って、3つ組条件をまとめるまとめ処理を行う(ステップS502)。クエリ分類部321は、記憶部130に記憶されたテーブルごとに、「まとめ判断ルール」に従って3つ組条件グループをまとめる(図12)。「まとめ判断ルール」でまとめられなかった3つ組条件に対して、クエリ分類部321は、更に、変数の置き換えによるまとめ処理を実行する(図13)。変数の置き換えにより、「変数変換規則」が定まる。
そして、クエリ分類部321は、まとめ処理で更新された3つ組条件グループごとのテーブルを参照して、共通クエリ8を作成する共通クエリ作成処理を行う(ステップS503)。
クエリ分類部321は、テーブルのクエリ情報にガジェットの識別子が複数記録された3つ組条件を共通クエリ8に含める(図14)。ガジェットの識別子が一つのみのテーブルが存在する場合には、クエリ分類部321は、まとめ処理にて定めた「変数変換規則」を用いて、3つ組条件内の該当する変数を変換し、異なる定数を示す要素の値は予め定めた変数に置き換える(図15)。
そして、実行管理部323は、クエリ分類部321によって作成された共通クエリ8を用いて、LODクラウド500に対してデータ検索を行い、得られた中間結果9を一時クエリ保存部329へ格納する(ステップS504)。
次に、実行管理部323は、一時クエリ保存部329に対して、ガジェット4gごとに、ガジェット4g内のクエリを用いたデータ検索を行う(ステップS505)。従って、定義情報107に含まれるガジェット4gに係るデータ検索が完了し、クエリまとめ処理部320は、ページ定義処理部310へデータ検索の完了を通知し、この処理を終了する。
図19は、クエリ分類部による処理全体を説明するためのフローチャート図である。図19において、クエリ分類部321は、ページに関連付けられるガジェット4gを読み込む(ステップS600)。
クエリ分類部321は、全ガジェット4gについて3つ組条件を分類したか否かを判断する(ステップS601)。具体的には、ページ定義処理部310から通知された定義情報107に含まれるガジェット4gのクエリ内にある全ての3つ組条件を分類したか否かが判断される。
3つ組条件を分類していないガジェット4gが存在する場合(ステップS601のNO)、クエリ分類部321は、未処理のガジェット4gを1つ選択し、選択したガジェット4gのクエリ内の各3つ組条件の型を判別し、型ごとに3つ組条件を分類して(ステップS602)、ステップS601へと戻る。クエリ分類部321は、新たな型を検出するごとに、テーブルを作成し、3つ組条件を記録する。既に検出した型の場合、クエリ分類部321は、型に対応するテーブルに3つ組条件を追加する。
全てのガジェット4gの3つ組条件を分類した場合(ステップS601のYES)、即ち、3つ組条件の分類を終了した場合、クエリ分類部321は、3つ組条件を分類した全てのグループに対して、まとめ判断ルールによるまとめ処理を終了したか否かを判断する(ステップS603)。
未処理のグループが存在する場合(ステップS603のNO)、クエリ分類部321は、未処理のグループから1つ選択して、選択したグループ内の3つ組条件をまとめ判断ルールに基づいてまとめ(ステップS604)、ステップS603へと戻る。具体的には、クエリ分類部321は、テーブルを1つ選択し、テーブルに記録された3つ組条件をまとめ判断ルールに基づいてまとめる(図11)。
全てのグループに対してまとめ判断ルールによるまとめ処理を終了した場合(ステップS603のYES)、クエリ分類部321は、まとめた3つ組条件を共通クエリに追加し、グループから削除する(ステップS605)。具体的には、テーブルから削除する3つ組条件に対応付けられたクエリ情報から、置き換え前の変数と置き換え後の変数の対応付けを取得し、変数変換規則に追加しておく。
クエリ分類部321は、3つ組条件が残っているグループが存在するか否かを判断する(ステップS606)。テーブルのクエリ情報が2以上のガジェット4gの識別子を示す3つ組条件は、まとめ判断ルールによりまとめられテーブルから削除されている。3つ組条件が残っているグループとは、クエリ情報が1つのガジェット4gの識別子しか示さない3つ組条件のみとなったテーブルに相当する。
3つ組条件が残っているグループが存在する場合(ステップS606のYES)、クエリ分類部321は、残っているグループの1つを選択し、変数変換規則に基づく変数の要素の変換及び定数の要素の変数への置き換えを行って(図15)、2以上の3つ組条件をまとめる(ステップS607)。
そして、クエリ分類部321は、まとめにより作成された3つ組条件を共通クエリに追加し、まとめられた3つ組条件をグループから削除し(ステップS608)、ステップS606へと戻り上述した処理を繰り返す。
3つ組条件が残っているグループが存在しない場合(ステップS606のNO)、クエリ分類部321は、共通クエリ8を実行管理部に通知して(ステップS609)、この処理を終了する。
ステップS606において、残っている3つ組条件とは、テーブルのクエリ情報にガジェット4gの識別子が1つのみ記録された3つ組条件である。
図20は、実行管理部による実行管理処理を説明するためのフローチャート図である。図20において、実行管理部323は、共通クエリ8を利用してLODクラウド500をデータ検索し、検索結果を中間結果9として一時クエリ保存部329へ格納する(ステップS701)。
次に、実行管理部323は、ガジェット4g内のクエリを利用して一時クエリ保存部329をデータ検索し、ガジェット4gごとの検索結果データ328を取得する(ステップS702)。ガジェット4gごとの検索結果データ328は、記憶部130に記憶される。
そして、実行管理部323は、ガジェット4gごとの検索結果データ328をページ定義処理部に通知して(ステップS703)、この実行管理処理を終了する。
以下に、本実施例を用いないで全ガジェットを対象として比較した場合(既存手法)と、本実施例におけるページ4pに関連付けられたガジェットのみを対象として比較した場合の結果例を示す。
図21は、比較結果例を示す図である。図21において、既存手法では、条件は全ガジェット数「200」及びガジェットのクエリ内の3つ組条件数「6」であり、本実施例では、条件はページ4p内のガジェット数「6」及びガジェットのクエリ内の3つ組条件数「6」である。
既存手法では、比較する2つのガジェット4gの組み合せ数と、2つのガジェット4gのそれぞれのクエリ内の3つ組条件との比較回数とから、
200C2×(6×6)=19、900×36=716、400回
を得る。
本実施例では、比較する2つのガジェット4gの組み合せ数と、2つのガジェット4gのそれぞれのクエリ内の3つ組条件の型を考慮した場合の比較回数(図4等の説明から13回)とから、
4C2×12=6×12=72回
を得る。この条件の場合には、本実施例では、既存手法と比べて、凡そ1/9000にまで削減することができる。
上述した本実施例における、ページ定義処理部310は特定部の一例であり、クエリ分類部321は作成部の一例であり、実行管理部323は検索部の一例である。
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、主々の変形や変更が可能である。
以上の実施例を含む実施形態に関し、更に以下の付記を開示する。
(付記1)
記憶部に記憶された、表示するページの定義情報を参照して、該表示するページに関連付けられるガジェットを特定し、
特定した前記ガジェットに含まれるクエリから共通となる部分を特定し、特定した共通となる部分と、非共通の部分による問合せを包含する記載とにより共通クエリを作成し、
作成した前記共通クエリを用いてインターネットを介してデータ検索を行う
処理をコンピュータが実行するデータ検索方法。
(付記2)
前記共通クエリの作成では、前記コンピュータは、
前記クエリ内の複数の3つ組条件を構成する各要素が定数であるか変数であるかの種別を示す型ごとに分類し、該型ごとに前記共通となる部分を特定することを特徴とする付記1記載のデータ検索方法。
(付記3)
前記コンピュータは、
前記型ごとに、2以上の3つ組条件の同一要素間の一致又は不一致の結果と、前記型の前記要素の前記種別とに基づいて、該2以上の3つ組条件が検索するデータを包含して検索可能な3つ組条件を作成することで、該2以上の3つ組条件を共通化することを特徴とする付記2記載のデータ検索方法。
(付記4)
前記コンピュータは、
前記ページにおいて注目する第1の対象と、該第1の対象に係る第2の対象の指定に応じて、該ページに含まれるガジェットを前記定義情報に定義する
処理を行うことを特徴とする付記1乃至3のいずれか一項記載のデータ検索方法。
(付記5)
前記コンピュータは、
変数の要素が前記2以上の3つ組条件同士で一致しない場合に、当該要素を除外することで該2以上の3つ組条件同士で一致するときは、いずれか一方の3つ組条件を選択する第1のまとめ処理を行うことを特徴とする付記4記載のデータ検索方法。
(付記6)
前記コンピュータは、
一致しなかった前記要素の変数の対応付けを示す変数変換規則を前記記憶部に作成し、
前記第1のまとめ処理後に、前記記憶部に作成した前記変数変換規則を用いて、未だまとめられいない3つ組条件の変数の要素を対応付けられた変数へと変換し、一致しない定数の要素を予め定めた変数に置き換える第2のまとめ処理を行うことを特徴とする付記5記載のデータ検索方法。
(付記7)
前記コンピュータは、
前記インターネットを介して行ったデータ検索によりデータを取得すると、該データを前記記憶部に記憶し、
前記記憶部に記憶された前記データに対して、特定した前記ガジェットのクエリを用いてデータ検索する
処理を行うことを特徴とする付記1乃至6記載のデータ検索方法。
(付記8)
記憶部に記憶された、表示するページの定義情報を参照して、該表示するページに関連付けられるガジェットを特定し、
特定した前記ガジェットに含まれるクエリから共通となる部分を特定し、特定した共通となる部分と、非共通の部分による問合せを包含する記載とにより共通クエリを作成し、
作成した前記共通クエリを用いてインターネットを介してデータ検索を行う
処理をコンピュータに行わせるデータ検索プログラム。
(付記9)
記憶部に記憶された、表示するページの定義情報を参照して、該表示するページに関連付けられるガジェットを特定する特定部と、
特定した前記ガジェットに含まれるクエリから共通となる部分を特定し、特定した共通となる部分と、非共通の部分による問合せを包含する記載とにより共通クエリを作成する作成部と、
作成した前記共通クエリを用いてインターネットを介してデータ検索を行う検索部と
を有する情報処理装置。