JP5020414B2 - 構造化情報の生成 - Google Patents

Description

本発明は、一般に、ネットワークから情報を抽出することに関し、特に、ネットワーク上の電子文書から構造化情報のセットを構築することに関する。

インターネットまたは他のネットワークに関する情報を見付けることは困難であり得る。検索エンジンにより、ユーザは指定した特徴を有するコンテンツを見付けることができる。しかしながら、ある場合、検索エンジンの有効性は、インターネット上で利用可能な莫大な情報量により害されている。例えば、「トムのレストラン」のようなありふれた名称のレストランを探す人は、正しいレストランを見付けるために歩いて回らなければならないほど多くの一致結果を受け取るであろう。

「情報過多」の問題を改善する一つの方法は、より小さいセットの情報の検索を可能にすることである。検索エンジンにより、ユーザは特定の都市や他の地理的エリアに特化したディレクトリを検索することができる。そのように、ニューヨーク州ニューヨーク市の「トムのレストラン」を探している人は、ニューヨーク市のレストランだけに検索を制限するように指定することができる。結果として、検索結果が少なくなり、検索者が正しい結果を見出すことはより容易である。また、ローカルディレクトリは、レストランの位置を示す地図を提供するような追加の機能を提供することができる。

ロバストな機能性を有するディレクトリの構築は複雑なプロセスである。ある都市にあるレストランや他の企業の名称、住所、電話番号のようなある種の情報は、比較的簡単に得られる。電話会社や他のデータプロバイダは、しばしばこの種の情報を販売している。しかしながら、効果的であるためには、ディレクトリは、標準的な情報プロバイダからでは利用不可能な追加の情報を含めるべきである。そのような追加情報は、営業時間、予約規定、支払選択、および駐車場が利用可能か否かなどである。理想的には、ディレクトリは、「火曜日に深夜まで開いているレストランを探す」や「予約可能な係員付きの駐車場を有するレストランを示す」などの複雑な問い合わせをサポートする構造化フォーマットでこの情報を維持するであろう。そのような情報を収集し、表示することの困難さのため、この種のディレクトリはこれまで作成されていない。

上記のようなディレクトリを構築するのに必要な情報は、しばしばインターネット上で入手可能である。レストランは、営業時間や予約規定のような重要な詳細を提供するそれ自身のウェブページを有していることがある。同様に、レストランの項目を含む１以上のウェブディレクトリがあるかもしれない。けれども、通常、この情報は構造化されていないか、不適当な方法で構造化されている。例えば、レストランのウェブページは、「月曜定休」という言いまわしを用いてその営業時間を記載しているかもしれないが、既存のローカルディレクトリは、「営業日：火、水、木、金、土曜」のように同じ情報を特定している。このような同じ情報の表現方法の多様性により、種々の異なる情報源から得た構造化情報を有する統一されたディレクトリを構築することは困難である。

そのため、構造化または少なくとも部分的な構造化されたディレクトリのための情報収集を確立する方法がこの分野では必要である。

上記必要性は、構造化されたデータを生成するためのシステム、方法、コンピュータプログラムにより満たされる。一実施形態では、システムは、企業についての事実を記述する非構造化データを含む電子文書を受け取るためのデータ取得モジュールを備える。また、このシステムは、電子文書から企業についての情報を記述する非構造化データを抽出するためのデータ抽出モジュールを備える。さらに、このシステムは、抽出された非構造化データを受け取るとともに、非構造化データによって記述された事実の構造化された表現を作成するためのデータ解析モジュールを備える。

本発明の一実施形態における、多数の非構造化あるいは構造化情報源から構造化情報を生成するコンピュータ環境のハイレベルブロック図である。 一実施形態における図１のコンピュータ環境に示されるエンティティの一つとして用いられるコンピュータの機能図を示すハイレベルブロック図である。 一実施形態における構造生成エンジン内のモジュールを示すハイレベルブロック図である。 一実施形態における営業時間を標準化するための値標準化モジュールにより実行されるステップを示すフローチャートである。 一実施形態における構造生成エンジンにより実行されるステップを示すフローチャートである。

図面は、例証の目的のみで本発明の実施形態を描写する。当業者は、本明細書に記述される本発明の原則から逸脱することなく、本実施形態で示される構成および方法の代わりの実施形態を用いることができることを、以下の記述から容易に認識するであろう。

１．概観
図１は、本発明の一実施形態における、多数の構造化されあるいは構造化されていない情報源から構造化された情報を生成するためのコンピュータ環境１００のハイレベルブロック図である。図１は、構造化情報データベース１１２に接続される構造生成エンジン１１０を示す。構造生成エンジン１１０はネットワーク１１４に接続される。また、ネットワーク１１４は、商業データプロバイダ１１６と、企業ウェブサイト１１８と、ディレクトリウェブサイト１２０とにも接続される。ある実施形態では、これら後者の３つのエンティティの１以上が存在しない。

最も高いレベルでは、構造生成エンジン１１０は、ネットワーク１１４上の多数の情報源からデータを収集する。このデータは構造化されているか、構造化されていない。構造生成エンジン１１０は、このデータを解析して、構造化事実を作成する。構造化情報データベース１１２は構造化された情報を格納する。構造化事実は、ローカルディレクトリの項目として、すなわち、検索クエリの結果としてあるいは情報に対する別のリクエストに応じて、ネットワーク１１４を介して提供される。

構造化データは、コンテンツからデータのキー（すなわち、コンテキスト）の識別および区別を可能となるように組織化されたデータである。コンピュータまたは他の装置により構造化データを理解することができる。例えば、「TN: xxx-xxx-xxxx」（「x」は数字を意味する）という構造に組織化された電話番号を想定する。「TN: 212-864-6137」のようなこのフォーマットで組織化されたデータに遭遇すると、コンピュータにより実行されるプロセスでは、当該データのキーが電話番号であり、番号の値が212-864-6137であると決定することができる。非構造化データは、特定のフォーマットで組織化されていないデータであり、コンテキストおよびコンテンツを確認するのは困難である。準構造化データは、部分的に組織化されたデータである。

構造生成エンジン１１０は、ネットワーク１１４上の多数の情報源からデータを収集して構造化するハードウェアあるいはソフトウェア装置である。構造生成エンジン１１０は、ネットワーク１１４を介して種々のデータソースとインタフェースで接続する機能を含む。例えば、構造生成エンジン１１０は、１以上の商業データプロバイダ１１６からデータを受信するためのインタフェースを含む。同様に、構造生成エンジン１１０は、企業ウェブサイト１１８やディレクトリウェブサイト１２０などのウェブサイトからウェブページあるいは他の電子文書を検索することができる。構造生成エンジン１１０は、受け取ったデータを分析して、キーと値の対から形成される事実を識別する。構造生成エンジン１１０は、事実のキーおよび値を標準化して、構造化データを作り出す。

一実施形態では、構造生成エンジン１１０は、都市など特定の地理的領域にある企業に関するデータを受け取る。「企業」とは、会社、学校、官庁、非営利組織、あるいは他の同様のエンティティである。一実施形態では、企業はレストランであり、構造生成エンジン１１０により受け取られるデータは、営業時間、予約規定、可能な支払方法などのレストランの側面に関する。しかしながら、当業者は、レストラン以外の企業のための情報を構造化するために構造生成エンジン１１０を用いることができることを理解するであろう。さらに、構造生成エンジン１１０により受け取られたデータは、特定の地理的領域に限定される必要はない。

構造化情報データベース１１２は、構造生成エンジン１１０により生成された、あるいは他の情報源からの構造化事実を格納する。一実施形態では、構造化情報データベース１１２は、構造化クエリ言語（ＳＱＬ：structured query language）で作成されたクエリをサポートする関係型データベースである。他の実施形態は、異なる種類のデータベースを利用する。

一実施形態では、構造化情報データベース１１２内の企業についての構造化事実は、地理的領域のためのローカルディレクトリをサポートするために利用される。ローカルディレクトリ内の事実は、ネットワーク１１４上のウェブサイトで利用可能とされる。コンピュータ、携帯電話、あるいは他のネットワーク接続装置を利用する人のようなエンドユーザは、このディレクトリにアクセスし、企業についての事実を要求することができる。例えば、エンドユーザは特定のレストランへのクエリを発することができる。それに応じて、ローカルディレクトリは、企業の名称、電話番号、住所、営業時間、予約規定、駐車場の利用可能性、可能な支払選択などのレストランについての事実を記載する１以上のウェブページを返す。ある実施形態では、エンドユーザは、ある場所から所定半径内にあるすべてのレストラン、予約可能なすべてのレストラン、あるいは午後１０時以降も開いているすべてのレストランのような他の種類のクエリを発することができる。そのようなローカルディレクトリの一例として、カリフォルニア州マウンテンビューのグーグル社から利用可能なグーグルローカルサービスがある

図１に示す商業データプロバイダ１１６は、ある実施形態では構造生成エンジン１１０にデータを提供する１以上の商業データプロバイダを表す。商業データプロバイダの例は、電話会社などの遠距離通信プロバイダ、新聞社などのメディアプロバイダ、およびＤ＆Ｂ社などの商業ディレクトリプロバイダを含む。ある実施形態では、商業データプロバイダ１１６は、企業の名称、住所、電話番号などの地域内の企業についての基本情報を記述する事実セットを提供する。これらのデータは典型的に構造化されている。商業データプロバイダ１１６は、ネットワーク１１４を介してあるいは別の通信チャネルを通して構造生成エンジン１１０に当該データを提供する。

図１に示す企業ウェブサイト１１８は、企業によってまたは企業に代行して運営される多数のウェブサイトを表す。企業ウェブサイト１１８の一例は、特定のレストランについての情報を提供するネットワーク１１４上のサイトである。通常の場合、そのサイトは、レストランの写真と、レストランの名称、住所、電話番号、営業時間、可能な支払方法および予約規定などの情報とを提供する。さらに、そのサイトは、サンプルメニューや道案内のような他の情報を含んでいてもよい。

ネットワーク上の数千あるいは数万の企業ウェブサイト１１８は、構造生成エンジン１１０がアクセスすることができる可能なデータ情報源を表す。企業ウェブサイト１１８に関するデータは、しばしば構造化されておらず、あるいは種々の異なるフォーマットで構造化されている。例えば、ある企業ウェブサイト１１８は、レストランの営業時間を「営業日：月曜〜金曜、午前９時〜午後５時、土曜は午後６時まで」のように特定し、別の企業ウェブサイト１１８は、「営業日：午前６時〜午後２時、定休日：日曜、祝日」と特定している。これらのデータは定義された構造を欠いており、コンピュータが解釈するのは困難である。

ディレクトリウェブサイト１２０は、多数の企業ウェブサイト１１８についての情報を提供するネットワーク１１４上の１以上のサイトを表す。一実施形態では、ディレクトリウェブサイト１２０は、地理的領域内にあるレストランの既存のディレクトリである。ディレクトリウェブサイト１２０は、レストランについての構造化情報、準構造化情報、あるいは非構造化情報を提供するウェブページを含む。そのページは、しばしば、少なくとも部分的に構造化されている。例えば、ディレクトリウェブサイト１２０のあるレストランのための各ページは、そのレストランが予約を受けるか否かを示すために、テキスト「予約」と、その後に続く「はい」または「いいえ」とを含んでもよい。しかしながら、ページについてのいくつかの情報は構造化されていないかもしれない。また、異なるディレクトリウェブサイト１２０では、異なる構造を利用している。

ネットワーク１１４は、構造生成エンジン１１０とデータ情報源１１６、１１８、１２０との間の通信径路を表す。一実施形態では、ネットワーク１１４はインターネットである。また、ネットワーク１１４は、必ずしもインターネットの一部ではない専用のまたはプライベートの通信リンクを用いることもできる。一実施形態では、ネットワーク１１４は、標準的な通信技術あるいはプロトコルを用いてトラフィックを実行する。したがって、ネットワーク１１４は、８０２．１１、総合デジタル通信網（ＩＳＤＮ）、デジタル加入者回線（ＤＳＬ）や非同期転送モード（ＡＴＭ）などの技術を用いるリンクを含むことができる。同様に、ネットワーク１１４上のトラフィックにより用いられる通信プロトコルは、マルチプロトコルラベルスイッチング（ＭＰＬＳ）、伝送制御プロトコル（ＴＣＰ／ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、シンプルメール転送プロトコル（ＳＭＴＰ）、ファイル転送プロトコル（ＦＴＰ）などを含むことができる。ネットワーク１１４を介して交換されるデータは、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）などを含む技術あるいはフォーマットを用いて表されればよい。さらに、すべてまたはいくつかのリンクは、セキュアソケットレイヤー（ＳＳＬ）、セキュアＨＴＴＰあるいは仮想プライベートネットワーク（ＶＰＮ）のような従来の暗号化技術を用いて暗号化されればよい。別の実施形態では、エンティティは、上述の技術の代わりにまたはそれに加えて、カスタムのあるいは専用のデータ通信技術を用いることができる。

２．システムアーキテクチャ
図２は、一実施形態における図１のコンピュータ環境１００に示されるエンティティの一つとして用いられるコンピュータ２００の機能図を示すハイレベルブロック図である。バス２０４に接続される少なくとも１つのプロセッサ２０２が示される。また、メモリ２０６、記憶装置２０８、キーボード２１０、グラフィックアダプタ２１２、ポインティングデバイス２１４およびネットワークアダプタ２１６もバス２０４に接続される。ディスプレイ２１８はグラフィックアダプタ２１２に接続される。

プロセッサ２０２は、インテル社のｘ８６、サンマイクロシステムズ社のＳＰＡＲＣ、またはパワーＰＣ社の互換性ＣＰＵなどのあらゆる汎用プロセッサであればよい。記憶装置２０８は、一実施形態ではハードディスク装置であるが、書き込み可能なコンパクトディスク（ＣＤ）やＤＶＤ、ソリッドステート記憶装置のようなデータを格納することができるあらゆる他の装置であってもよい。メモリ２０６は、例えば、ファームウェア、リードオンリーメモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、あるいはＲＡＭであればよく、プロセッサ２０２により用いられる命令およびデータを保持する。ポインティングデバイス２１４は、マウス、トラックボール、その他のポインティングデバイスであり、コンピュータシステム２００にデータを入力するためのキーボード２１０と組み合わせて用いられる。グラフィックアダプタ２１２は、ディスプレイ２１８にイメージや他の情報を表示させる。ネットワークアダプタ２１６は、コンピュータ２００をネットワーク１１４に接続させる。多くの場合、コンピュータは、キーボード２１０、ポインティングデバイス２１４、グラフィックアダプタ２１２あるいはディスプレイ２１８のような図２に示す１以上の構成要素を欠いている。

本技術分野では公知のように、コンピュータ２００は、コンピュータプログラムモジュールを実行するよう構成される。本実施形態で用いられるように、用語「モジュール（module）」は、指定された機能性を提供するためのコンピュータプログラムロジックあるいはデータに関する。モジュールは、ハードウェア、ファームウェアあるいはソフトウェアにおいて実行され得る。一実施形態では、モジュールは、記憶装置２０８に格納され、メモリ２０６にロードされ、プロセッサ２０２により実行される。

図１のエンティティにより利用されるこの種のコンピュータ２００は、実施形態およびそのエンティティにより要求される処理能力に応じて変更可能である。企業ウェブサイト１１８は、１つのコンピュータ２００で実行するウェブサーバにより提供されてもよい。対照的に、ディレクトリウェブサイト１２０は、より強力なコンピュータで実行するウェブサーバあるいは協動する１以上のブレードサーバにより提供されてもよい。同様に、一実施形態では、構造生成エンジン１１０は、１以上のブレードサーバで実行する１以上のモジュールまたは本実施形態に記述される機能性を提供するために協働する他の種類のコンピュータを含む。

図３は、一実施形態における構造生成エンジン１１０内のモジュールを示すハイレベルブロック図である。他の実施形態は、図示以外の追加のあるいは異なるモジュールを有する。さらに、本実施形態に記述される方法とは異なる方法でモジュール間に機能性を分散することもできる。また、構造生成モジュール１１０以外のエンティティにより上記機能のいくつかが提供されてもよい。

データ取得モジュール３１０は、ディレクトリに含まれるべき企業についてのデータを取得する。一実施形態では、データ取得モジュール３１０は、商業データプロバイダ１１６から企業についてのデータを受信する。これらのデータは、例えば、商業データプロバイダ１１６により運用されるウェブサイトからそのデータを検索し、ＸＭＬまたは別のフォーマットを用いてデータを指定するデータフィード（data feed）を受信し、ＤＶＤまたは他のコンピュータに読み取り可能なメディアからそのデータをロードすることなどによって受け取られる。上述のように、商業データプロバイダ１１６からのデータは構造化され、それらの名称、住所あるいは電話番号を含む企業についての基本的事実のセットを提供する。

一実施形態では、データ取得モジュール３１０は、企業ウェブサイト１１８あるいはディレクトリウェブサイト１２０についてのウェブページにより提供されるデータにアクセスするためのウェブ巡回モジュール３１２を含む。ウェブクローラは、そのリンクに続くことによりウェブサイトにアクセスし、そのサイトを通してトラバースする自動化プログラムである。ウェブ巡回モジュール３１２は、企業ウェブサイト１１８およびディレクトリウェブサイト１２０を巡回し、一実施形態では、次の解析を可能にするために遭遇するウェブページを格納する。実施形態に応じて、ウェブ巡回モジュール３１２が巡回するサイトは、手動で指定されるか、あるいは、商業データプロバイダ１１６または他の情報源から受信したデータに基づいてプログラムで選択される。

一実施形態では、ウェブ巡回モジュール３１２は、１つの汎用クローラと１以上の特定目的のクローラとを含む。汎用クローラは、未知のフォーマットを有するウェブサイトを巡回するために用いられる。企業ウェブサイト１１８はしばしば場当たり的に作られ、各サイトのフォーマットは完全に一意であるかもしれない。一実施形態では、汎用クローラの振る舞いは、多種多様の異なるフォーマットを有するそのような場当たり的なサイトのために最適化される。

特定目的のクローラは、フォーマットが事前に知られているディレクトリウェブサイト１２０あるいは企業ウェブサイト１１８を巡回するために利用される。例えば、ある地理的領域内のレストランを記述する既知の基底アドレスにおいて、既存のディレクトリウェブサイト１２０が一連のウェブページを有すると想定する。特定目的のクローラは、そのアドレスのウェブサイトにアクセスし、そのウェブページのみを検索するために手動でコード化される。特定目的のクローラは、それらが広告であるように、またはデータが収集される企業についての情報を他の方法で提供しないようにする特徴を有するリンクのようなページ上のあるリンクを無視するためにコード化され得る。同様に、特定目的のクローラは、企業についてのデータを含むようなページのみにアクセスするように、あるリンクを選択するためにコード化されてもよい。

ある実施形態では、データ取得モジュール３１０は、企業を記述するデータを取得するために他の技術を用いる。一実施形態では、企業は、モジュールが商業データプロバイダ１１６からデータをどのように受信するかと同様に、予め構造化された事実テキストを直接データ取得モジュール３１０に送信する。別の実施形態では、データ取得モジュール３１０は、ネットワーク１１４に接続されるウェブサイトから検索されたコンテンツのキャッシュで見出されるウェブページのような、貯蔵庫で見出される分類されていないウェブページを検査する。

データ抽出モジュール３１４は、ウェブ巡回モジュール３１２により格納されたウェブページあるいは電子文書から企業についてのデータを抽出する。一般的に言って、抽出されたデータは、エンドユーザが企業のディレクトリに役に立つと思うような企業の側面を記述する。一実施形態では、抽出されたデータは、企業の以下のものを含む：
名称、住所あるいは電話番号、
営業時間（すなわち、開いている時間）、
予約規定、
アクセスしやすさ（すなわち、身体障害者のアクセス）、
可能な支払方法、
駐車場（すなわち、駐車場がどのような形式で利用可能か）、
提供されるサービス、および
提供されるブランド。
他の実施形態は、異なるあるいは追加のデータを抽出する。

一実施形態では、データ抽出モジュール３１４は、ウェブページから、企業を記述するキー、値の対を含むようなテキスト文字列を抽出する。データは、汎用のあるいは専用の抽出装置を用いて抽出される。一実施形態では、汎用および専用の両抽出装置は、手動で構築された正規表現を有する解析ツール（解析部：parser）から形成される。他の実施形態では、抽出装置のいくつかまたはすべては、自動化されたラッパ帰納（wrapper induction）技術を用いて作られる。

専用の抽出装置は、既知のフォーマットを有するウェブページから情報を抽出するように最適化される。例えば、特定のディレクトリウェブサイト１２０からレストランについてのすべてのウェブページが、そのページの特定の位置に用語「身体障害者のアクセスしやすさ：」とそれに続く「はい」または「いいえ」を含むために知られていると想定する。専用の抽出装置は、ウェブページの正しい部分を見付け、「身体障害者のアクセスしやすさ」文字列を抽出する正規表現を含む。一実施形態では、専用の抽出装置は、二段組のテーブルを有するウェブページのために適合される。そのようなテーブルでは、１つの段は典型的に「駐車場」や「専門」のようなキーを含み、他方の段はそのキーの値を含む。専用の抽出装置は、そのテーブルからキーと値の対を抽出する。汎用の抽出装置は、同種の情報を抽出するが、特有ではないフォーマットを有するウェブページからデータを抽出するよう設計される。

データ解析モジュール３１６は、キーと値の対を含む抽出された文字列を事実の正規表現に変換する。データ解析モジュール３１６の機能性を理解するために、ある企業に身体障害者がアクセス可能であるか否かを２つの異なるウェブページ（および抽出された文字列）がどのように表現することができるかを考える。一つの文字列が「車椅子がアクセス可能か（Wheelchair Accessible）：はい（YES）」であり、もう一つの文字列が「身体障害者のアクセス（Handicap Access）：はい（Y）」であることを想定する。両文字列は、身体障害者がその企業にアクセス可能であることを示すが、キー（すなわち、「車椅子がアクセス可能か」および「身体障害者のアクセス」）および値（すなわち、「YES」および「Y」）の両方とも異なる。同様に、文字列「営業時間：月曜から金曜の午前９時〜午後５時（hours: Monday to Friday 9-5）」と「営業日：平日、午前９時〜午後５時（OPEN weekdays from 9:00 am to 5:00 pm.）」を考える。これらの両文字列は、同じ営業時間を表すために、異なるキーと値の対を用いている。データ解析モジュール３１６は、可能な場合には、異なる情報源からのデータが同じ方法で表現されるようにキーと値の両方を変換する。一実施形態では、事実の正規表現は、構造化情報データベース１１２に格納される。

キー標準化モジュール３１８は、抽出された文字列のおけるキーを標準化する。一般に、キー標準化は、文字列のデータを既知のデータタイプに分類する（例えば、文字列が時間データ、駐車場データまたはアクセスしやすさデータを含むか否かを決定する）処理である。一実施形態では、キー標準化モジュール３１８は、キーを識別するために、正規表現マッチングを実行する解析ツールを用いる。例えば、キー標準化モジュール３１８は、用語「営業日」、「定休日」、「時間」、「毎日」、あるいは文字列が営業時間を記述していることを意味する他の用語をその文字列が含むか否かを決定する。別の例では、キー標準化モジュール３１８は、用語「駐車場」、「ボーイ」、「敷地（lot）」、あるいは文字列がその企業で駐車場を利用可能であるか否かを記述していることを意味する他の用語をその文字列が含むか否かを決定する。キー標準化モジュール３１８が抽出された文字列内のキーを認識するならば、そのことは、その文字列をそのキーの正規表現に関連付けている。

値標準化モジュール３２０は、抽出された文字列内の値を標準化する。値標準化は、文字列内にある値の機械に理解可能な表現を作り出す処理である。一実施形態では、値標準化モジュール３２０は、その値を解釈するために、正規表現マッチングを実行する解析ツールを用いる。ある種の値は、標準化するのに比較的素直である。例えば、「予約規定」および「アクセスしやすさ」キーは、「はい」か「いいえ」のいずれかの値を通常有する。これらの２種の値のための解析ツールは、文字列が用語「はい」、「いいえ」あるいはそれらと同等のものを含むか否かを決定することにより標準化を実行する。しかしながら、営業時間のようないくつかの値は、種々の異なる方法で表現されている。そのため、その種の値のための解析ツールはより複雑なロジックを利用する。

図４は、一実施形態における営業時間値を標準化するための値標準化モジュール３２０により実行されるステップを示すフローチャートである。他の実施形態は、異なるあるいは追加のステップを実行する。また、他の実施形態は、異なる順序でステップを実行する。図４のステップが営業時間を標準化するように意図されるが、当業者は、他の種の値を標準化するために、類似のステップを用いることができることを認識するであろう。

例として、文字列「営業日：月曜〜水曜、午前９時〜午後５時、木曜、〜午後７時」を用いて企業がその営業時間を記述していると想定する。営業時間の正規表現を作るために、値標準化モジュール３２０は、文字列内のシンボルを分類するために（ステップ４１０）、その文字列を解析する。一実施形態では、そのシンボルは、時間、日、セパレータ、営業日、定休日、あるいは無視のいずれかに分類される。正規表現はこれらの分類を実行するために用いられる。一実施形態では、これらを検出するために用いられるこれらの分類の意味および正規表現の記述は、以下のようになる：

「時間」（Ｔ）は、企業の営業時間の時間を記述する値である。文字列の時間は、「＃＃：＃＃（午前／午後）」（ここで、「＃」は数字であり、午前／午後は任意のサブコンポーネントである）、「＃時」、「正午」および「＃＃＃＃時間」のようなサブ文字列の発生を検出する正規表現により認識される。

「日」（Ｄ）は、企業が開店（オープン）しまたは閉店（クローズ）している日を記述する値である。文字列の日は、「Ｍ」、「Ｍｏｎ」、「Ｍｏｎｄａｙ（月曜日）」（および他の日の同等物）、「週末」、「毎日」のような１週間の日を表すサブ文字列の発生を検出する正規表現により認識される。

「セパレータ」（−）は、文字列内の他のシンボルを分離するシンボルである。文字列のセパレータは、「−」（ハイフン）、「まで（to）」、「まで（until）」、「から（through）」、「から（thru）」のようなセパレータを表すサブ文字列の発生を検出する正規表現により認識される。

「営業日／定休日」（Ｏ／Ｃ）は、文字列内の日付あるいは時間を修正する値である。これらの値は、「営業日」、「定休日」、あるいは文字列内の同様のサブ文字列の発生を検出する正規表現により認識される。

「無視」（Ｘ）は、文字列を解析するとき無視される値である。無視は、スペース、カンマ、「and」等のような用語を検出する正規表現を用いて文字列から取り除かれる。

分類（ステップ４１０）の後、文字列「open M-W 9 to 5, TH to 7」は、「ＯＤ−ＤＴ−ＴＤ−Ｔ」として表される。次に、値標準化モジュール３２０は、「Ｄ」シーケンスを、シーケンス内のすべての日を表す一つの「Ｄ」に折り畳む（ステップ４１２）。このステップは、「Ｄ−折り畳み」と呼ばれる。一実施形態では、折り畳まれたＤは、営業日を記述するビットを有するベクトルにより表される。例えば、そのベクトルが日曜から始まるならば、月曜から水曜は「０１１１０００」として表される。このステップの後、例示の文字列は「ＯＤＴ−ＴＤ−Ｔ」として表される。

Ｄ−折り畳み後、値標準化モジュール３２０は、必要であれば、時間シンボルをその表現に挿入する（ステップ４１４）。「Ｔ−挿入」と呼ばれるこのステップは滅多に起こらず、営業時間の提示が境界値を欠いている特別な場合を取り扱う。例えば、Ｔ−挿入は、営業時間が「TH 9-7」の代わりに「TH to 7」として表されている場合を取り扱う。一実施形態では、値標準化モジュール３２０は、「Ｔ」が先導しない「−Ｔ」、例えば、（Ｄ−Ｔ）の発生のための文字列の表現を検査する。そのような「−Ｔ」が見付けられるならば、値標準化モジュール３２０は、（存在するならば）直前の「Ｔ−」を識別子、この「Ｔ」をその表現に挿入する。したがって、「ＯＤＴ−ＴＤ−Ｔ」は、「ＯＤＴ−ＴＤＴ−Ｔ」に変換される。それは、「営業日：月曜〜水曜、９時〜５時、木曜、９時〜７時」と同等である。

次に、値標準化モジュール３２０は、その表現内の時間を解釈する（ステップ４１６）。その表現の一つの「Ｔ」は、３つの可能な解釈：午前、午後、または次の日の午前を有することができる。言い換えると、「１」は、午前１時、午後１時、または次の日の午前１時に言及することができる。一実施形態では、値標準化モジュール３２０は、「ＤＴ−Ｔ」シーケンスを識別するために解析ツールを用いる。これらの解析ツールは、これらのシーケンス内の時間を解釈するためにロジックを用いる。そのロジックは、ほとんどの企業がその営業時間をどのように表すかに基づいている。例えば、８から１１までの開始時間は午前となる傾向があり、５〜７の間の開始時間は午後となる傾向があり、午後の開始時間に続くがより小さい数を持つ終了時間は、次の日の午前となる傾向がある。したがって、サンプル文字列は、「営業日：月曜〜水曜午前９時から午後５時まで、木曜午前９時から午後７時まで」と解釈される。

これらのステップをサンプル文字列に適用すると、値標準化モジュール３２０は、その文字列を解釈することができ、機械に理解可能な正規表現で営業時間を表すことができる（ステップ４１８）。一実施形態では、正規表現は、１週間の営業日と営業時間を記述するベクトルである。

図３において、データ解析モジュール３１６により実行される標準化は、一般に３つのカテゴリ（完全な標準化、キーのみの標準化、標準化なし）の一つに分類される。完全な標準化では、データ解析モジュール３１６は、抽出された文字列に含まれるキーと値の両方を標準化する。完全な標準化は最善の結果である。なぜならば、それにより、機械がキーと値の対により表現された事実を完全に理解することができ、多数の情報源からの事実を比較することができるからである。一実施形態では、「営業時間」、「予約規定」および「アクセスしやすさ」の日付を提供する文字列はしばしばこのカテゴリに分類される。

「キーのみの標準化」では、データ解析モジュール３１６は、抽出された文字列に含まれるデータタイプを理解することができるが、その値の機械に理解可能な表現を作り出すことができない。一実施形態では、「可能な支払方法」と「駐車場」データを提供する文字列は、しばしばこのカテゴリに分類される。なぜならば、対応する値の解析が困難だからである。ある実施形態では、これは過渡的な状態である。最初に不明瞭な（理解されない）十分な値が考慮されると、解析ツールは、その値を標準化するよう構成され得る。

「標準化なし」では、データ解析モジュール３１６は、キーだけでなく値も標準化することができない。一実施形態では、標準化することができない抽出された文字列は、抽出された形式で保存される。そして、抽出された文字列は、そこに含まれる事実の人による解釈を可能にするために、そのままディレクトリに提供される。

ある実施形態では、データ解析モジュール３１６は、事実を理解するのと同様に、事実を認識するために、キー標準化モジュール３１８あるいは値標準化モジュール３２０の機能性を用いる。データ解析モジュール３１６がウェブサイトまたは別の情報源からテキストの断片を受信したが、テキストの意味についての情報を欠いているならば、データ解析モジュール３１６は、キーおよび値標準化モジュール３１８、３２０からの解析ツールをテキストに適用し、その解析ツールが有効な結果を作るか否かを決定することができる。そして、データ解析モジュール３１６は、解析ツールの結果に基づいてそのテキストを分類することができる。例えば、営業時間解析ツールがテキストの断片に適用され、有効な結果を作り出すならば、データ解析モジュール３１６は、そのテキストが営業時間情報を含み、営業時間キーをそのテキストに関連付けることを認識する。

データクラスタリングモジュール３２２は、その事実（標準化されたか否か）をそれらが属する企業に関連付ける。一実施形態では、このクラスタリング処理は、企業ウェブサイト１１８あるいはディレクトリウェブサイト１２０から抽出された事実のセットを商業データプロバイダ１１６から受信される企業データと関連付けることにより実行される。クラスタリング処理の結果は、同じ企業に属する事実が一緒にグループ化されることである。

データクラスタリングモジュール３２２の動作を理解するために、以下の５つの事実セットを考える：
１．円卓（Round Table）ピザ
６５０−９６１−０３６１
カリフォルニア州マウンテンビュー海岸線大通り北５７０
営業日 毎日午前１１時〜午後１０時
２．マウンテンビューの円卓ピザ
６５０−９６１−０３６１
９４０４３ カリフォルニア州マウンテンビュー海岸線大通り北５６０
３．セーフウェーのフード＆ドラッグ
６５０−９６１−４８６８
９４０４３ カリフォルニア州マウンテンビュー海岸線大通り５７０
２４時間オープン
４．円卓ピザ
６５０−９６１−０３６１
９４０２２ カリフォルニア州ロスアルトス一番通り３９９
宅配可能
５．円卓
６５０−３８４−７４６３
９４０４３ カリフォルニア州マウンテンビュー海岸線大通り５７０

これらの事実が５つの異なる情報源から得られると想定する。例えば、事実２のセットは、商業データプロバイダ１１６から受信したデータから得られるが、他の４つの事実セットは、企業ウェブサイト１１８あるいはディレクトリウェブサイト１２０から得られる。

これらの事実から、観察者は、第１、第２および第５の事実セットがおそらく同じ企業（マウンテンビューの円卓ピザ）を記述すると思うかもしれない。その事実は、通りの住所（番地）についてわずかに一致しないが、同じブロックのピザレストランの同じブランドが２つあることより、事実情報源の一つは間違った番号を有していた可能性が高い。また、電話番号についてもいくつかの不一致がある。再び、あるデータ情報源が間違った番号を有していたか、おそらくそのレストランが多数の電話番号を有しているかであろう。第３の事実セットは、ピザレストランと同じ住所を有する明らかに異なる企業（セーフウェー食料雑貨品店）を記述する（おそらく、円卓住所についてある混乱を説明する同じ小規模ショッピングセンター内である）。第４の事実セットは、数マイル離れたロスアルトスの異なる円卓レストランのように見える。データクラスタリングモジュール３２２は、同じ企業に属する事実セットを識別するとともに、異なる企業に属する事実セットを区別するために、同様のロジックを一覧表に適用する。

データクラスタリングモジュール３２２は、近接により事実セットをグループ化する。一実施形態では、データクラスタリングモジュール３２２または別のモジュールは、住所あるいは他のデータから得られる経度と緯度を用いてその事実により記述される各企業の位置を表す。互いに適度に近い複数の企業（およそエラー半径、例えば、上述の５６０／５７０の住所の混乱）は同じ企業であるかもしれない。一方、（マウンテンビューとロスアルトスのような）非常に離れた複数の企業はほとんど同じではない。

そのグループ化を容易にするために、データクラスタリングモジュール３２２の一実施形態は、近隣サイズが「エラー半径」（ほとんどの場合、２街区、密集市街地ではより近い）の回りである「近隣」に世界を分割する。近隣は部分的に重なり合い、事実セットは結局いくつかの近隣に割当てられる。この重なりにより、事実セットは隣接する近隣の事実で結合され得る。

データクラスタリングモジュール３２２は、その事実が同じ企業に属するか否かを決定するために、ある近隣内の各事実セットをその近隣内の他の事実セットと比較する。一実施形態では、データクラスタリングモジュール３２２は、事実セット対の名称、電話番号、および位置を比較し、これらのアイテムに基づいて類似スコアを計算する。名称を比較するために、データクラスタリングモジュールは、コーパス（corpus）の頻度により重み付けされた共用用語および二重音字に基づいて、本文の類似韻律学を用いる。

類似スコアが閾値を超えると、データクラスタリングモジュール３２２は、２つの事実セットを併合する。一実施形態では、データクラスタリングモジュール３２２は、事実セットが関連しないような特別な条件を取り扱うために、その併合に対するある例外を強制する。データクラスタリングモジュール３２２の一実施形態は、その名称が全く同じでない限り、異なる電話番号を有する１つの事実セットを併合しない。データクラスタリングモジュール３２２は、後の処理において事実グループを識別するために用いられる「クラスタＩＤ」を併合された事実セットに割り当てる。近隣が部分的に重なるので、多数の近隣において、事実セットが他の事実セットと併合され、クラスタＩＤを割り当てられたことは可能である。これが起こると、それに併合されたほとんどの事実セットを有するクラスタＩＤは企業用のクラスタになる。

一実施形態では、事実比較モジュール３２４は、その事実の信頼レベルを確立するために、ある企業のクラスタされた（ひとまとめにされた）事実を比較する。上述のように、事実が種々の情報源から得られるとき、いくつかの事実は一致して、いくつかの事実は矛盾する。多数の情報源によりサポートされる事実は、高い信頼レベルを有する。例えば、多数の情報源から得られる事実が企業の営業時間について一致するならば、これらの事実は正しい可能性が高く、そのため、事実比較モジュール３２４は、高い信頼レベルをこれらの事実に割り当てる。対照的に、多数の情報源からの事実が矛盾するならば、事実比較モジュール３２４は、低い信頼レベルをこれらの事実に割り当てる。一実施形態では、部分的に標準化されあるいは標準化されていない事実は信頼レベルを割り当てられない。

ある実施形態では、事実比較モジュール３２４は、ある情報源からの矛盾する事実と好意的な事実とを区別するために、重み付け処理を用いる。重み付け処理は、例えば、より最近の事実により重い重みを、最近ではない矛盾する事実により軽い重みを割り当てる。さらに、より信頼できる情報源からの事実に他の事実よりも重い重みを割り当てることができる。同様に、他の事実セットよりも多くの情報を提供する事実セット内の事実により重い重みを割り当てることができる。信頼レベルを欠いている部分的に標準化された事実あるいは標準化されない事実は、その事実の情報源、同じセット内の他の事実の数、あるいは他の基準に基づいて割り当てられる重みを有することができる。一実施形態では、低い信頼レベルあるいは重み付けを有する事実は捨てられる。

上述のように、一実施形態では、構造化情報データベース１１２に格納される事実は、企業のローカルディレクトリをエンドユーザに提供するために用いられる。一実施形態では、構造生成エンジン１１０は、そのディレクトリが構造化情報データベース１１２に格納される事実をどのように提供すべきかを指定する事実表現モジュール３２６を含む。他の実施形態では、事実表現モジュール３２６は、そのディレクトリのウェブページを与えるモジュールのような異なるエンティティに位置する。

事実表現モジュール３２６は、事実がどのようにディレクトリに表示されるかを決定するために、その事実の信頼レベルあるいは重み付けを用いる。一般に、より大きい信頼レベルあるいは重み付けを有する事実は表示されるが、より低い信頼レベルあるいは重み付けを有する事実は表示されない。表示された事実は、それらの情報源に帰属するか否かにかかわらず示される。一実施形態では、非常に高い信頼レベルを有する事実は帰属なしに表示される。例えば、商業データプロバイダ１１６からの名称、住所および電話番号の事実は、帰属なしに表示される。より低い信頼レベルを有する他の事実は、その事実が得られた情報源に帰属して表示される。一実施形態では、その帰属は、事実が抽出されたウェブページまたは他の電子文書にリンクするユニフォームリソースロケータ（ＵＲＬ）を含む。

多数の情報源が同じ事実を提供するならば、一実施形態は、最も重い重み付けを有する事実のみを表示し、その事実を提供した情報源にそれを帰す。この技術は、二重の事実でページを満たすよりもむしろ他の事実を示すために、ページ上に空き領域を残す。例えば、ある企業が「営業日：月曜〜土曜 午前８時〜午後６時」であると情報源Ａが示し、その企業が「営業日：月曜〜土曜」であるとのみ情報源Ｂが示すならば、それが多くの情報を含んでいるので（そのため、より重い重み付けを受けているので）、事実表現モジュール３２６は情報源Ａからの事実を示す。

一実施形態では、部分的に標準化されあるいは標準化されていない事実は、そのまま帰属して表示される。すなわち、その事実を記述する抽出された文字列は、その文字列の情報源へのリンクとともに、ウェブページに表示される。この表示により、エンドユーザはその事実を直接見て解釈することができる。

３．プロセス／例
図５は、一実施形態における構造生成エンジン１１０により実行されるステップを示すフローチャートである。他の実施形態は、異なる順序でステップを実行し、あるいは、図５に示すステップと異なるステップまたは追加のステップを実行する。構造生成エンジン１１０は、図５のステップの多数の事例を同時に実行し、あるいは並列にステップを実行することができる。

まず、構造生成エンジン１１０は、１以上の情報源から企業についてのデータを取得する（ステップ５１０）。これらの情報源は、商業データプロバイダ１１６、企業ウェブサイト１１８、あるいはディレクトリウェブサイト１２０を含むことができる。構造生成エンジン１１０は、そのデータから事実を記述する文字列を抽出する。

構造生成エンジン１１０は、抽出された文字列を解析し、機械に理解可能な表現の標準化された事実を作り出す（ステップ５１２）。各文字列はキーと値の対を含む。構造生成エンジン１１０は、ある場合には、キーと値の両方を標準化することができ、他の場合には、キーのみを標準化することができ、さらに他の場合には、キーと値のいずれも標準化することができない。

構造生成エンジン１１０は、その事実をクラスタする（ステップ５１４）。すなわち、構造生成エンジン１１０は、各事実をそれが属する企業と関連付ける。結果として、各企業は、１以上の事実のリストを得る。その事実のいくつかは一致し、別のいくつかは矛盾してもよい。構造生成エンジン１１０は、ある企業に関連した事実を比較する（ステップ５１６）。一実施形態では、構造生成エンジン１１０は、信頼レベルあるいは重みをそれらの事実に割り当てる。例えば、一致する多数の情報源からの事実は、高い信頼レベルを割り当てられる。

ある時点で、事実は、その事実が属する企業のためのウェブページまたは他の電子文書上に提示される（ステップ５１８）。ウェブページは、ローカルディレクトリの一部であればよく、別のコンテキストに提供され得る。いくつかの事実はそれらの情報源の帰属なしに提示されるが、他の事実は帰属とともに提示される。また、非常に低い信頼レベルを有し、あるいは別の事実により既に提供された情報を含むいくつかの事実は示されない。

上記の記述は、好適実施形態の動作を示すために含まれるが、本発明の範囲を限定するよう意味するものではない。本発明の範囲は、添付の特許請求の範囲によってのみ限定されるべきである。上記議論から、多くの変更は、本発明の意図および範囲によってもう包含されるであろう関連技術分野の当業者にとって明白であろう。

１００ コンピュータ環境
１１０ 構造生成エンジン
１１２ 構造化情報データベース
１１４ ネットワーク
１１６ 商業データプロバイダ
１１８ 企業ウェブサイト
１２０ ディレクトリウェブサイト

Claims (18)

1. 構造化データを生成するシステムであって、
   企業の営業時間についての事実を記述する非構造化データを含む電子文書を受け取るためのデータ取得モジュールと、
   前記企業の営業時間についての事実を記述する前記非構造化データを前記電子文書から抽出するためのデータ抽出モジュールと、
   前記抽出された非構造化データを受け取り、前記非構造化データにより記述される前記企業の営業時間についての事実の構造化表現を作り出すためのデータ解析モジュールであって、値標準化モジュールを含み、該値標準化モジュールは、
   前記電子文書から抽出された前記企業の営業時間についての事実を記述する文字列を受信し、
   前記文字列内に含まれる複数シンボルを分類するために前記文字列を解析し、ここで、該解析することは、前記文字列から、一週間の曜日を表すシンボルを分類し、かつ、前記企業の前記営業時間を表すシンボルを分類することからなり、
   前記文字列内における前記一週間の曜日を表すシンボルを一つにまとめて、まとめられた文字列を形成し、ここで、該まとめられた文字列は、一連の曜日を表すシンボルと前記企業の営業時間を表すシンボルとを有し、
   前記一連の曜日における前記企業の営業時間を判定するために前記まとめられた文字列を解釈する、
   ことを行う、前記データ解析モジュールと
   を備え、前記企業の営業時間についての事実の前記構造化表現が、該企業が営業している一週間内の曜日を表すビットを使用して前記一連の曜日を表す前記シンボルを記述するベクトルを含むことを特徴とするシステム。
2. 前記文字列内における一週間の曜日を表すシンボルを一つにまとめることは、
   前記文字列内における一週間の曜日を表す複数のシンボルのシーケンスを識別することと、
   前記一週間の曜日を表す複数のシンボルのシーケンスを一連の曜日を表す1つのシンボルにまとめること
   を含む請求項１に記載のシステム。
3. 前記値標準化モジュールは、更に、
   前記文字列内の前記企業の営業時間の記述が境界値を欠いていることを識別することと、
   前記境界値として前記企業の営業時間の一つの時間を前記文字列内に挿入すること
   を行うものである請求項１又は２に記載のシステム。
4. 前記文字列を解析することは、該文字列内で他のシンボルを分離するセパレータを、該文字列内の複数シンボルから分類することを含む請求項１乃至３のいずれかに記載のシステム。
5. 前記文字列を解析することは、該文字列内での他のシンボルによって表された曜日及び／又は時間の修飾語を、該文字列内のシンボルから分類することを含む請求項１乃至４のいずれかに記載のシステム。
6. 前記ベクトルは、一週間内の各曜日において前記企業が営業している営業時間を記述する、請求項１乃至５のいずれかに記載のシステム。
7. 構造化データを生成するためのコンピュータプログラムであって、コンピュータに、
   企業の営業時間についての事実を記述する非構造化データを含む電子文書を受け取るためのデータ取得手順と、
   前記企業の営業時間についての事実を記述する前記非構造化データを前記電子文書から抽出するためのデータ抽出手順と、
   前記抽出された非構造化データを受け取り、前記非構造化データにより記述される前記企業の営業時間についての事実の構造化表現を作り出すためのデータ解析手順であって、
   前記電子文書から抽出された前記企業の営業時間についての事実を記述する文字列を受信し、
   前記文字列内に含まれる複数シンボルを分類するために前記文字列を解析し、ここで、該解析することは、前記文字列から、一週間の曜日を表すシンボルを分類し、かつ、前記企業の前記営業時間を表すシンボルを分類することからなり、
   前記文字列内における一週間の曜日を表すシンボルを一つにまとめて、まとめられた文字列を形成し、ここで、該まとめられた文字列は、一連の曜日を表すシンボルと前記企業の営業時間を表すシンボルとを有し、前記一連の曜日を表す前記シンボルは、前記企業が営業している一週間内の曜日を表すビットを有するベクトルによって前記構造化表現内において記述され、
   前記一連の曜日における前記企業の営業時間を判定するために前記まとめられた文字列を解釈する、
   ことを行う値標準化手順を備え、ここで、前記企業の営業時間についての事実の前記構造化表現が、該企業が営業している一週間内の曜日を表すビットを使用して前記一連の曜日を表すシンボルを記述する前記ベクトルからなる、前記データ解析手順と
   を実行させるためのコンピュータプログラム。
8. 前記文字列内における一週間の曜日を表すシンボルを一つにまとめることは、
   前記文字列内における一週間の曜日を表す複数のシンボルのシーケンスを識別する手順と、
   前記一週間の曜日を表す複数のシンボルのシーケンスを一連の曜日を表す1つのシンボルにまとめる手順
   を前記コンピュータに実行させることを含む請求項７に記載のコンピュータプログラム。
9. 前記値標準化手順は、更に、
   前記文字列内の前記企業の営業時間の記述が境界値を欠いていることを識別する手順と、
   前記境界値として前記企業の営業時間の一つの時間を前記文字列内に挿入する手順
   を前記コンピュータに実行させることを含む請求項７又は８に記載のコンピュータプログラム。
10. 前記文字列を解析することは、該文字列内で他のシンボルを分離するセパレータを、該文字列内の複数シンボルから分類することを含む請求項７乃至９のいずれかに記載のコンピュータプログラム。
11. 前記文字列を解析することは、該文字列内での他のシンボルによって表された曜日及び／又は時間の修飾語を、該文字列内のシンボルから分類することを含む請求項７乃至１０のいずれかに記載のコンピュータプログラム。
12. 前記ベクトルは、一週間内の各曜日において前記企業が営業している営業時間を記述する、請求項７乃至１１のいずれかに記載のコンピュータプログラム。
13. 構造化データを生成するためにコンピュータによって実行される方法であって、
    前記コンピュータが、企業の営業時間についての事実を記述する非構造化データを含む電子文書を受け取ることと、
    前記コンピュータが、前記企業の営業時間についての事実を記述する前記非構造化データを前記電子文書から抽出することと、
    前記コンピュータが、前記抽出された非構造化データを受け取り、前記非構造化データにより記述される前記企業の営業時間についての事実の構造化表現を作り出すこと、
    を備え、前記抽出された非構造化データを受け取って前記構造化表現を作り出すことは、
    前記電子文書から抽出された前記企業の営業時間についての事実を記述する文字列を受信することと、
    前記文字列に含まれる複数シンボルを分類するために前記文字列を解析することと、ここで、該解析することは、前記文字列から、一週間の曜日を表すシンボルを分類し、かつ、前記企業の前記営業時間を表すシンボルを分類することからなり、
    前記文字列内における一週間の曜日を表すシンボルを一つにまとめて、まとめられた文字列を形成することと、ここで、該まとめられた文字列は、一連の曜日を表すシンボルと前記企業の営業時間を表すシンボルとを有し、前記一連の曜日を表す前記シンボルは、前記企業が営業している一週間内の曜日を表すビットを有するベクトルによって前記構造化表現内において記述され、
    前記一連の曜日における前記企業の営業時間を判定するために前記まとめられた文字列を解釈すること、
    を含み、前記企業の営業時間についての事実の前記構造化表現が、該企業が営業している一週間内の曜日を表すビットを使用して前記一連の曜日を表すシンボルを記述する前記ベクトルからなることを特徴とする方法。
14. 前記文字列内における一週間の曜日を表すシンボルを一つにまとめることは、
    前記コンピュータによって、前記文字列内における一週間の曜日を表す複数のシンボルのシーケンスを識別することと、
    前記コンピュータによって、前記一週間の曜日を表す複数のシンボルのシーケンスを一連の曜日を表す1つのシンボルにまとめること
    を含む請求項１３に記載の方法。
15. 前記抽出された非構造化データを受け取って前記構造化表現を作り出すことは、更に、
    前記コンピュータによって、前記文字列内の前記企業の営業時間の記述が境界値を欠いていることを識別することと、
    前記コンピュータによって、前記境界値として前記企業の営業時間の一つの時間を前記文字列内に挿入すること
    を含む請求項１３又は１４に記載の方法。
16. 前記文字列を解析することは、該文字列内で他のシンボルを分離するセパレータを、該文字列内の複数シンボルから分類することを含む請求項１３乃至１５のいずれかに記載の方法。
17. 前記文字列を解析することは、該文字列内での他のシンボルによって表された曜日及び／又は時間の修飾語を、該文字列内のシンボルから分類することを含む請求項１３乃至１６のいずれかに記載の方法。
18. 前記ベクトルは、一週間内の各曜日において前記企業が営業している営業時間を記述する、請求項１３乃至１７のいずれかに記載の方法。

Images