コンピュータによって実行される情報処理方法であって、複数の被所有リソースを受信するとともに、前記複数の被所有リソースのインデックスを保持する段階と、ユーザインターフェースを提供する段階と、前記ユーザインターフェースを介して、複数のオーナーから、該複数のオーナーが所有するリソースに関するラベル及び属性を受信する段階と、前記受信したラベル及び属性を前記インデックスに格納する段階と、前記インデックスに格納された前記受信したラベル及び属性を使用して、検索エンジン内に検索エンジン結果を生成する段階とを有し、各被所有リソースは、それぞれのオーナーを有し、各オーナーは、前記複数の被所有リソースを集団的に所有する複数のオーナーのうちの1つであり、各被所有リソースは、前記それぞれのオーナーから公然と入手可能なリソースであり、前記ユーザインターフェースは、前記複数のオーナーのうちのいずれかが、該複数のオーナーの所有するリソースに前記ラベル及び属性を手作業で関連付けることによって、前記複数のオーナーそれぞれの複数の被所有リソースを構築するために使用する複数の領域を有し、各属性は、属性名及び属性値を有し、各ラベルは、属性名だけを有し、属性値を有さない特別な種類の属性であり、前記インデックスは、検索エンジンによって検索可能であり、前記検索エンジン結果を生成する段階は、前記インデックスに格納されたラベルを使用して、検索エンジンに入力された照会用語に対応する検索エンジン結果を生成する段階と、前記インデックスに格納された属性を使用して、前記照会用語に関連した属性名を提示する段階と、前記提示した属性名に応答して検索エンジンに入力された属性値に対応する絞り込まれた検索エンジン結果を生成する段階とを含むことを特徴とする方法。各被所有リソースに関連する複数の属性の複数のサブセットを選択する段階をさらに有し、前記ユーザインターフェースが、各被所有リソースに関連する複数の属性の前記選択された複数のサブセットを表示するための領域をさらに有することを特徴とする請求項1に記載の方法。前記ユーザインターフェースは、前記検索エンジン結果中に特定の被所有リソースが存在することを確認した場合に、前記特定のリソースを表示するための題名、画像、説明、及びリソース識別子を、オーナーによって指定できるようにするための領域をさらに有することを特徴とする請求項1に記載の方法。前記受信した属性を前記インデックスに格納する段階が、ヌル属性値を格納する段階をさらに有することを特徴とする請求項1に記載の方法。前記受信した属性を前記インデックスに格納する段階が、特定の被所有リソースに関連した属性名/属性値の対を格納する段階をさらに有することを特徴とする請求項1に記載の方法。前記属性が、総量、作成者、及び記事ソース情報を有することを特徴とする請求項1に記載の方法。前記属性が、価格、価格オプション、総量属性、ブランド、状態属性、及び製品タイプ情報を有することを特徴とする請求項1に記載の方法。前記属性を受信する段階が、属性リポジトリに以前は格納されていなかった手作業で追加された属性名と、前記手作業で追加された属性名に関連する属性値とを受信する段階をさらに有することを特徴とする請求項1に記載の方法。前記ユーザインターフェースは、前記複数のオーナーのうちのいずれかが特定の被所有リソースと該特定の所有リソースに関する地理的位置との接続を手作業で指定するための領域をさらに有することを特徴とする請求項1に記載の方法。前記ユーザインターフェースが、前記複数のオーナーのうちのいずれかが前記属性値に対する値タイプを手作業で指定するための領域をさらに有することを特徴とする請求項1に記載の方法。前記値タイプが、さらに、数値タイプ、データ範囲値タイプ、テキスト値タイプ、リソース識別子値タイプ、又は論理値タイプのうちの1つであることを特徴とする請求項10に記載の方法。1つ以上のプロセッサと、前記1つ以上のプロセッサに接続されたコンピュータ可読媒体とから成り、前記コンピュータ可読媒体は、複数の命令を格納しており、前記複数の命令は、実行されたときに、前記1つ以上のプロセッサに複数の演算を実行させ、前記複数の演算は、複数の被所有リソースを受信するとともに、前記複数の被所有リソースのインデックスを保持する段階と、ユーザインターフェースを提供する段階と、前記ユーザインターフェースを介して、複数のオーナーから、該複数のオーナーが所有するリソースに関するラベル及び属性を受信する段階と、前記受信したラベル及び属性を前記インデックスに格納する段階と、前記インデックスに格納された前記受信したラベル及び属性を使用して、検索エンジン内に検索エンジン結果を生成する段階とから成り、各被所有リソースは、それぞれのオーナーを有し、各オーナーは、前記複数の被所有リソースを集団的に所有する複数のオーナーのうちの1つであり、各被所有リソースは、前記それぞれのオーナーから公然と入手可能なリソースであり、前記ユーザインターフェースは、前記複数のオーナーのうちのいずれかが、該複数のオーナーの所有するリソースに前記ラベル及び属性を手作業で関連付けることによって、前記複数のオーナーそれぞれの複数の被所有リソースを構築するために使用する複数の領域を有し、各属性は、属性名及び属性値を有し、各ラベルは、属性名だけを有し、属性値を有さない特別な種類の属性であり、前記インデックスは、検索エンジンによって検索可能であり、前記検索エンジン結果を生成する段階は、前記インデックスに格納されたラベルを使用して、検索エンジンに入力された照会用語に対応する検索エンジン結果を生成する段階と、前記インデックスに格納された属性を使用して、前記照会用語に関連した属性名を提示する段階と、前記提示した属性名に応答して検索エンジンに入力された属性値に対応する絞り込まれた検索エンジン結果を生成する段階とを含むことを特徴とするシステム。前記受信した属性を前記インデックスに格納する段階が、ヌル属性値を格納する段階をさらに有することを特徴とする請求項12に記載のシステム。前記受信した属性を前記インデックスに格納する段階が、特定の被所有リソースに関連した属性名/属性値の対を格納する段階をさらに有することを特徴とする請求項12に記載のシステム。前記属性を受信する段階が、属性リポジトリに以前は格納されていなかった手作業で追加された属性名と、前記手作業で追加された属性名に関連する属性値とを受信する段階をさらに有することを特徴とする請求項12に記載のシステム。前記ユーザインターフェースは、前記複数のオーナーのうちのいずれかが前記属性値に対する値タイプを手作業で指定するための領域をさらに有することを特徴とする請求項12に記載のシステム。コンピュータプログラムによってコード化され、実行されたときに、1つ以上のコンピュータに複数の演算を実行させるように動作する複数の命令を有するコンピュータ可読媒体であって、前記複数の演算は、複数の被所有リソースを受信するとともに、前記複数の被所有リソースのインデックスを保持する段階と、ユーザインターフェースを提供する段階と、前記ユーザインターフェースを介して、複数のオーナーから、該複数のオーナーが所有するリソースに関するラベル及び属性を受信する段階と、前記受信したラベル及び属性を前記インデックスに格納する段階と、前記インデックスに格納された前記受信したラベル及び属性を使用して、検索エンジン内に検索エンジン結果を生成する段階とから成り、各被所有リソースは、それぞれのオーナーを有し、各オーナーは、前記複数の被所有リソースを集団的に所有する複数のオーナーのうちの1つであり、各被所有リソースは、前記それぞれのオーナーから公然と入手可能なリソースであり、前記ユーザインターフェースは、前記複数のオーナーのうちのいずれかが、該複数のオーナーの所有するリソースに前記ラベル及び属性を手作業で関連付けることによって、前記複数のオーナーそれぞれの複数の被所有リソースを構築するために使用する複数の領域を有し、各属性は、属性名及び属性値を有し、各ラベルは、属性名だけを有し、属性値を有さない特別な種類の属性であり、前記インデックスは、検索エンジンによって検索可能であり、前記検索エンジン結果を生成する段階は、前記インデックスに格納されたラベルを使用して、検索エンジンに入力された照会用語に対応する検索エンジン結果を生成する段階と、前記インデックスに格納された属性を使用して、前記照会用語に関連した属性名を提示する段階と、前記提示した属性名に応答して検索エンジンに入力された属性値に対応する絞り込まれた検索エンジン結果を生成する段階とを含むことを特徴とするコンピュータ可読媒体。前記受信した属性を前記インデックスに格納する段階が、ヌル属性値を格納する段階をさらに有することを特徴とする請求項17に記載のコンピュータ可読媒体。前記受信した属性を前記インデックスに格納する段階が、特定の被所有リソースに関連した属性名/属性値の対を格納する段階をさらに有することを特徴とする請求項17に記載のコンピュータ可読媒体。前記属性を受信する段階が、属性リポジトリに以前は格納されていなかった手作業で追加された属性名と、前記手作業で追加された属性名に関連する属性値とを受信する段階をさらに有することを特徴とする請求項17に記載のコンピュータ可読媒体。記載された本発明の実施形態は、ラベルおよび属性値を検索されるべきデータ項目に関連付ける。プロバイダが、属性およびラベルをプロバイダのデータに関連付けるか、または属性およびラベルが、既存データに追加されることができる。好ましい実施形態によって、コンテンツプロバイダは、コンテンツプロバイダ独自のカスタムラベルおよびカスタム属性を項目に付加するか、または予め定義されたラベルおよび属性を使用することができる。プロバイダは、ユーザインターフェースまたはバルクアップロード機構を使用してデータをアップロードすることができる。本発明の教示は、添付図面と共に下記の詳細な記載を考慮することによって容易に理解できる。同様の参照番号は、添付図面内で同様の要素のために使用される。図は、例示のみを目的として本発明の実施形態を示す。当業者は、本明細書で示される構造および方法の変形実施形態が本明細書に記載された本発明の原理から逸脱することなく使用されてよいことを以下の記載から容易に理解する。以下の段落は、本発明による構造化データをアップロードし検索するためのシステムの様々な実施形態を説明する。図1aは、本発明の好ましい実施形態によるデータ処理システムを示す構成図100である。図1aは、複数のクライアントデータ処理システム110a~110n、ネットワーク130、およびサーバデータ処理システム120を含む。図中では、例示のユーザデータ処理システム110aは、プロセッサ140、ブラウザ150、およびメモリ160を含む。ユーザデータ処理システム110またはその構成要素は、それに限定されないが、パーソナルコンピュータ、有線ネットワークコンピュータ、無線ネットワークコンピュータ、携帯電話または携帯電話を内蔵した機器、ハンドヘルド機器、シンクライアント機器、それらのいくつかの組合せなどを含む任意の適切なデータ処理システムであってよい。ネットワーク130は、ユーザデータ処理システム110のうちの1つまたは複数とサーバデータ処理システム120との間の通信を可能にする任意のネットワークであってよい。例えば、ネットワーク130は、それに限定されないが、インターネット、LAN、WAN、有線ネットワーク、無線ネットワーク、携帯電話ネットワーク、テキストメッセージを送信するネットワーク、およびそれらのいくつかの組合せであってよい。本発明の好ましい実施形態では、ユーザデータ処理システム110aは、ユーザがサーバシステム120と通信することができるためにプロセッサ140によって実行されるメモリ160内のブラウザソフトウェア150を含む。以下に詳細に記載されるように、この種のブラウザ150によって、ユーザは、照会用語をサーバデータ処理システム120に送信し、かつシステム120から照会結果を受信するために、サーバデータ処理システム120と通信することができる。以下にさらに詳細に記載されるように、ブラウザ150によって、ユーザは、照会結果に関連したラベルおよび属性を受信し、照会結果をさらに定義するためにラベルおよび属性を使用することができる。本明細書に記載される実施形態はブラウザベースであるが、本発明はブラウザベースの検索に限定されず、ユーザ110とサーバ120との間の通信に関する任意の適切な機構が、本発明の精神および範囲から逸脱することなく使用されてよい。本明細書に記載されるすべてのソフトウェアおよびコンピュータ実行可能命令のうちの一部は、それに限定されないが、データ処理システムのメモリ、CDROM、フラッシュメモリ、およびフロッピー登録商標ディスクを含むコンピュータ可読媒体上にコンピュータプログラム製品として格納されること、またはネットワークを介する信号もしくはシステム構成要素間の信号として送信されることができる。サーバデータ処理システム120は、サーバシステム120が照会用語に関する構造化データの集合体190を検索することができるように検索および照会エンジンソフトウェア185を実行するプロセッサ170を含む。構造化データの一例はフィールド化されたデータであり、それぞれは1つまたは複数のデータフィールドを有する。メモリ180は、構造化データ190内のデータ項目の一部またはすべてに関する属性を格納する属性リポジトリ195も含む。リポジトリは、図5に関連して以下に記載される。リポジトリ195が構造化データの集合体190の一部であるとして示されているが、リポジトリ195はデータ集合体190から分離していてもよい。大きい検索エンジンおよび大きいデータ集合体は、それに限定されないが、分散データ処理システム、協働データ処理システム、ネットワークデータ処理システムなどを含んで多くの方法で格納されてよいが、検索エンジン185、リポジトリ195、および構造化データの集合体190のすべてが単一のメモリ180内にあるとして図1aに示されている。検索エンジン185は、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せであってよい。好ましい実施形態では照会用語は、複数のユーザシステム110のうちの1つまたは複数を介してユーザによって入力され、ネットワーク130を介してサーバデータ処理システム120に送信される。データの集合体を受信し、インデックス付けし、かつ検索するためにサーバ120によって使用される方法の詳細が本明細書に詳細に記載される。図1bは、本発明の好ましい実施形態による他のデータ処理システムを示す構成図111である。図1bでは、ユーザはユーザの装置110上に個人のデータ集合体190を格納する。個人の検索エンジンは、ネットワーク130を介してユーザによって、および場合によっては他のユーザによって検索可能にするためにこのデータにアクセスし、かつ編成することが意図される。この種のシステムによってデータベースおよび他のタイプのデータ集合体が、中央の検索エンジンによってアクセス可能である検索可能な文書のプールに追加されることもできる。図1bの実施形態では、データ集合体190は、ユーザのデータ処理システム110またはエンタプライズサーバ上に格納され、ユーザのみ、より小さいサブセットのユーザのみ、またはデータ集合体190にアクセスする方法を認識しているすべてのユーザなどの選択されたグループの人または個人に対して利用可能であってよい。そのような場合、本明細書に記載されるように属性およびラベルを用いて検索をフィルタリングする機能は、コンピュータ上またはコンピュータのローカルネットワーク上で局部的に実行する個人の検索エンジン185の一部であってよい。例えば、Google社から入手できるGoogleデスクトップ検索ツールは、ユーザのデスクトップ上で実行し、ユーザのパーソナルコンピュータ上でデータにインデックス付けする検索ツールである。本発明を組み込んだGoogleデスクトップ検索の実装形態は、ユーザのデスクトップ上に格納されるまたはユーザのデスクトップからアクセス可能であるデータベースおよび他の種類のデータ集合体を検索する機能をユーザに提供する。その実装形態は、有用な属性およびラベルを用いてユーザのデータを編成する機能もユーザに提供する。例えば、大学図書館は、そのオンラインコレクションのすべてを大学の学生、教員、および卒業生に利用可能にすることができる。そのような場合、情報は、公的に利用できるサーバ上ではなく、大学のサーバ内に格納され、大学のデータプロバイダによってアクセスを許可された人に対してのみアクセス可能かつ検索可能となる。例では大学は、どのプロバイダがデータ集合体に追加する能力を有するかを制御することもできる。図1cは、本発明の好ましい実施形態によるアーキテクチャ図131である。記載された実施形態ではプロバイダは、データおよび属性をシステムに入力する3つの方法のうちの1つまたは複数を使用することができる。プロバイダが面するフロントエンド132によって、プロバイダは、その目的のために提供されるユーザインターフェースを使用してデータ項目および属性を入力することができる。プロバイダは、データ項目のバルクアップロード133も実行することができる。プロバイダは、特定のURLから項目をアップロードもできる。検索および照会エンジン185は、すべてのデータのインデックス137を生成するためにデータ項目に関する入力された属性およびそれらの値を好ましくは含んでデータ集合体190内の項目にインデックス付けする。検索エンジン185によって、ユーザは、照会を入力することもできる。システムは、ソフトウェアプログラムが検索エンジン185を介してデータを照会することを可能にするアプリケーションプログラムインターフェースも含む。図2aは、本発明の好ましい実施形態による検索可能なデータ項目の集合体の生成の概要を示す流れ図200である。図6a~6eおよび図8a~8dに関連して以下に記載されるように、サーバ120はデータ項目の集合体を受信する。このデータは、標準のウェブクロールの結果として受信するか、またはそれらのデータが検索可能になることを望む1つまたは複数のプロバイダによって提供されるかのいずれかであってよい。受信されたデータ項目の集合体は、以下に記載されるようにラベル、属性、および属性値を抽出するように処理され、それらのラベル、属性および属性値は様々な情報タイプに関連付けられる。ある種の環境ではユーザは、入力されたデータの一部またはすべてに関する属性名および/または属性値を提供することになる。一例として、ユーザは、ユーザが医学雑誌の集合体を保持するために生成したデータベースをアップロードすることができる。ユーザは、Journal、yearofpublication、JournalNameなどの属性名を反映する値を用いてこれらの雑誌に対して属性を指定していてよい。ユーザは、Medical、Dental、FromHarvardなど、雑誌ごとにゼロ以上のラベルも入力することができる。ラベルは、ラベルに関連した値を有しない特別の種類の属性である。要素204の詳細は図3aに関連して記載される。図2bは、本発明の好ましい実施形態による文書の集合体を検索し、検索を詳細化することの概要を示す流れ図210である。記載された実施形態ではユーザは、1つまたは複数の照会用語を入力する。ある種の実施形態ではユーザは、領域402内にタイプされる照会の一部として属性名および属性値も入力することができる。例えば、ユーザは、領域402内に下記をタイプすることができる。Cancerreceptorattr照会結果内のいくつかの項目がJournalTypeと名づけられた属性を有するが、その属性が属性のコアセットの一部でないことをユーザが知る場合、ユーザは医学雑誌だけを返すことを望む。システムは、図3bに関連して以下に詳細に記載されるように照会結果を決定する。いくつかの実施形態では、照会結果がこの時点で表示される。他の実施形態では、照会結果はまだ表示されないが、代わりにユーザは照会用語に固有のラベルおよび/または属性を選択することによって自身の検索をさらに詳細化するように求められる。例えば、図3dに示されるようにユーザは、ラベルおよび属性を指定することによってユーザの検索を詳細化することができる。図3aは、データ項目の集合体からラベルおよび属性を抽出する方法を示す流れ図300である。この方法は、データの集合体が検索できるようにデータの集合体を編成するために使用される設定プロセスの一部である。データ項目が受信されると、情報タイプを有するデータ項目ごとにシステムは、この情報タイプに関するラベルおよび属性を決定する。属性は、journalなどの名前を有する名前/値の対であり、次いで名前/値の対は雑誌の名前の1つまたは複数の可能性のある値を有する。好ましい実施形態では、属性およびラベルはデータのプロバイダによって指定される。したがって、属性を決定することは、ユーザ提供の属性およびラベルを識別することの問題だけである。ある種の場合にはデータのプロバイダは、プロバイダの項目に関する属性およびラベルを指定しない。例えば、項目がウェブクローラによって捜し出されるウェブページである場合、ウェブページの所有者はそれらのページに関する属性およびラベルを指定する機会を有しない。したがって、他の好ましい実施形態では、ラベルおよび属性はデータ集合体に関してソフトウェアによって得られる。ラベルおよび属性を得ることは、所定のリストのラベルおよび属性に対する可能性のある値がソフトウェアによってデータ集合体内で見いだされる完全に自動化されたプロセスを含むことができる。例えば、販売用項目のリストでは、所定の基準を満たす価格総額はその項目に関するPrice属性の値として割り当てられる。他の実施形態では、ソフトウェアは、ソフトウェアが属性/値の対を提案するプロバイダとの対話式処理を実行し、次いで属性/値の対はプロバイダによって受け入れられるまたは拒否される。他の好ましい実施形態では、htmlタグが走査され、見いだされた情報がタグを有するページに関する属性値を得るために使用される。一例として、ページがhtmlコメントを含む場合は以下のようになる。ソフトウェアは、示されたURLから現在の価格を得て、それをそのウェブページに関するPrice属性の値とする。属性およびラベルがデータ項目と関連付けられていると、データ項目はそれらが検索できるようにインデックス付けされる。第1の好ましい実施形態では、属性およびラベルならびにそれらの値もインデックス付けされるが、他の好ましい実施形態では、それらは個別に検索され、個別にインデックス付けされる。図5aは、リポジトリ195内にラベルおよび属性を格納するために使用される形式500の一例を示す。各項目は、そのタイプに適した特定の属性およびラベルに関連付けられる。例えば、求人募集は属性の職務権限、雇用者、職種を有することができる。好ましい実施形態での属性およびラベルは、下記のタイプの値を有することができる。BOOLEANINTFLOATURLSTRINGLOCATIONDATEDATERANGE属性およびラベルは、メタタグによって格納中に下記のように示される。namevalueしたがって、好ましい実施形態では各属性は、journalという属性名およびJournalofInflammationというjournal属性に関する値などの名前/値の対である。各ラベルは、特定の雑誌が医学雑誌であることを示すであろうMedicalなどの名前だけを有する。好ましい実施形態では、データ項目の情報タイプもそのラベルのうちの1つの名前である。したがって、EventsandActivitiesという情報タイプを有するデータ項目は、同一の名前を有するラベルも有するであろう。そのようにユーザは、データ項目の情報タイプと同一の名前を有するラベルを指定することによって特定の情報タイプを有するデータを検索することができる。図5dは、情報タイプをそれらの属性にマッピングするための例示のデータ構造を示す。したがって、データの集合体190内の項目がProductという情報タイプを有する場合、項目の属性は、図5cのデータ構造にアクセスすることによって決定されてよく、そのデータ構造は情報タイプProductに関する属性およびそれらの属性タイプを含む。図5dに示されるように、各情報タイプは予め定義された属性を有する。属性の値は属性タイプである。図5eはいくつかの実際の値を示す。したがって、Journalという情報タイプは、属性タイプの文字列の値を有するJournalnameという属性およびヌル値を有するMedicalというラベルを有する。例えば、この種の属性によって、ユーザが、特定の雑誌の題名を検索するまたはすべての医学雑誌を検索することができる。同様に、Productという情報タイプは、販売のために使用できるいくつかの特定の製品を示すNumAvailという属性を有し、整数の属性タイプを有する。すべての属性は任意選択である。プロバイダは、プロバイダに提案された属性のうちのいずれかを設定するために選択するまたはプロバイダ独自のものを生成することができる。図3bは、1つの受信した照会用語または複数の照会用語に応答して照会結果を表示する方法を示す流れ図310である。好ましい実施形態では、照会結果は検索エンジン185によって決定される。例えば、cancerreceptor402の照会は、図4bに示されるものなどの属性404を有する項目の照会結果406を返すことができる。上述のように、本発明のいくつかの実施形態は、この時点で照会結果406を決定するが表示しない。照会結果が照会に対して決定されると、照会結果に関する属性名およびラベルの少なくともいくつかは表示される。データセット406内のデータ項目はある種の情報タイプを有する。最初に表示される属性404は、照会結果406内のデータ項目の情報タイプに関する属性の一部またはすべてである。照会結果は複数のデータ項目を有し、データ項目のそれぞれは様々な属性を有する。照会結果の上位に現れる属性は、照会結果内で最も一般的である属性であり、最も検索者によってクリックされているまたは詳細化されている属性である。例えば、照会housingは、属性としてbedroomsおよびbathroomsを有する多数の項目を有し、検索者は、照会のhousingに関する属性のbathroomsおよびbedroomsによって常に詳細化している。したがって、bedroomsおよびbathroomsは検索結果の上方の最上位の行に現れるべきである。図4bは、照会結果406ならびに複数の属性名およびラベル名404を示す。各属性の後の数字は、それに関連した属性を有する照会結果406内の項目の数を示す。例えば、図4bでは照会結果406は、関連のjournal属性/ラベルを有する2050項目を含む。したがって、特定の照会結果と共に示される属性の数および識別情報は、照会に依存しており、検索を絞り込むために後で選択される属性およびラベルにさらに依存している。図3cは、どの属性が所与の照会結果406のために表示されるべきかを決定する方法を示す流れ図340である。エンドユーザが検索を実行するとき、q個の最も関連のある結果が検索エンジン185によって決定され、n個の最も人気のある属性がq個の最も関連のある結果に対して決定される。上位のn個の属性名についてシステムは、上位m個の属性/ラベル値を決定する。次いでシステムは、関連のある結果の組内で一致する提供数を計算することによってヒストグラムまたは提供数を計算する。値q、n、およびmはすべて設定可能である。限定を意図しない値の例は、qが1000~100000K、nが数百の範囲であり、mが20~100の範囲である。好ましい実施形態では、属性はヒストグラムが決定される前に正規化される。ある種の実装形態ではある量のデータ整理および正規化が、データがデータ集合体190内に最初に格納されるときに行われる。記載された実施形態ではデータの正規化は、検索されている照会用語に基づいて進行中に行われる。他の実施形態は、データがデータの集合体190に受信されるときにより多くの正規化を行うことができる。データの正規化は、下記によって好ましい実施形態内で実行される。1語幹解釈2省略3単位等価4入力されなかったスペルの補完具体的には語幹解釈は、プロバイダが、語尾変化およびミススペルがデータ集合体190内に入り込むことを可能にしてプロバイダ独自の属性名を指定するシステムで有用である。例えば、語幹解釈によって、ユーザは、語幹解釈された属性のJournalsの単一の選択を用いてJournal、journasl、Journslなどの属性名によってフィルタリングすることができる。ある種の好ましい実施形態では、プロバイダによって追加される属性はタイプチェックがなされる。例えば、URL、DateTime、Number、String、Location、Boolean属性は、それらが有効値であるかどうかを知るためにチェックされる。いくつかの実施形態は、これが様々な実装形態にとって任意選択であるが、各URL値にピングしてそれがアクティブであるかどうかを知る。好ましい実施形態の場合、locationsが、それらが、例えばGoogleMapsなどのオンラインマッピングサービス上で参照できるようにジオコード化される。ある種の実施形態では、ジオコード化できないlocationという属性は無効であると見なされる。人気のある属性およびラベルが決定され表示されると、ユーザは、照会結果に関する表示されたラベルおよび属性値のうちの1つまたは複数を指定することを許可される。図4cは、ユーザが図4bから属性journalを選択し、ユーザが自身の検索を絞り込むことを望む雑誌名をフィールド408内に入力する用意をしている一例を示す。照会用語402はここでcancerreceptorfilterjournalであることに留意されたい。属性journalは記載されたコア属性404から姿を消した。同様に、図4dではユーザは、第2の属性year410を選択し、ユーザが指定した雑誌の照会用語内で検索することを望む1年または範囲または複数年を入力する。属性yearは、属性タイプrangeofyearsのことである。照会用語402はここでcancerreceptorfilterjournalfilteryearであることに留意されたい。属性yearは、記載された属性404から姿を消した。ユーザがGOボタン411を選択する場合、図4eで表示されるものなどの選択された属性をフィルタおよび表示として使用して、検索が再び実行される。したがって、ユーザは、表示された照会結果に関する1つまたは複数の人気のある属性を選択することができ、表示された属性による最初の検索をフィルタリングすることができる。ユーザが属性値をブランクにしたままである場合、すべての属性値が一致したものとされる。例えば、ユーザが属性Journalを選択するが雑誌名を入力しない場合、journalという属性を有するデータ項目すべてが照会結果に関する可能性のある候補として選択される。Journalという属性を有しないデータ項目は照会結果に関して選択されない。図4dは、ユーザが検索を絞り込むために2つ以上の属性またはラベルを選択した一例を示す。記載された実施形態では複数のラベルおよび属性が、属性およびラベル404の複数のラベルおよび属性上をクリックすることによって選択される。他の好ましい実施形態によって、ラベルおよび属性が検索ウィンドウ402内に入力されることができる。例えば、属性Priceが存在する場合、ユーザは照会用語として下記をタイプすることができる。Attributeこの照会は、Priceという属性および150という属性値を有する現在の照会結果内のデータ項目を捜し出す。他の例として、ユーザは下記をタイプすることができる。AttributeANDLabelこの照会は、Priceという属性、および150という属性値、ならびにSmallerThanABreadBoxというラベルを有する現在の照会結果内のデータ項目を捜し出す。他の実施形態は、ユーザに属性とラベルを論理的に結合することを可能にするために他の適切なユーザインターフェース要素を使用する。図4eは、図4dで指定されるように特定の年または年の範囲の特定の雑誌に絞り込まれた照会結果を示す。ユーザは、ユーザが雑誌内を検索412し続けたいかどうか、またはデータ項目の集合体全体を検索413すべきかどうかを決定することを許可される。例ではユーザは、領域414内の複数のラベルの選択を提供される。例ではユーザは、領域416内の属性に対する値を指定するための選択をさらに提供される。ユーザは、relevance、date属性、またはユーザが定義した属性のいずれかによって照会結果406を分類することのオプションも提供される。図4fではユーザは、図4eの領域414から属性Dateを選択し、日付420を入力する機会を与えられる。ユーザがドロップダウンの演算子betweenを選択するとき、ユーザは日付の範囲を選択するための機会を与えられる。属性Dateは記載された属性418から姿を消した。この例では、Authorという属性が属性414から姿を消した。属性は、それらが照会および照会結果にもはや関連しない場合に姿を消す。ここで、ユーザが雑誌によってフィルタリングしなかったということは、ユーザが限定された項目セットだけを見ていることであると仮定する。ユーザは、検索を実行するためにGoボタンを選択し、著者用語が再び現れる。図4gは、著者名422を指定するユーザを示す。照会が詳細化されているとき、属性およびラベルが照会結果に基づいており、かつ照会結果が絶えず変化するので、新しい属性およびラベルが現れる。ユーザはGoボタン423を押すとき、他の検索が、ユーザによって指定される属性および属性値を反映するために照会結果をさらにフィルタリングして実行される。下記の段落では、属性およびラベルを使用して検索中または検索の絞込み中の属性リポジトリ195のアクセスについて記載する。照会およびその参照リポジトリ195のインデックス付けが下記の演算子をサポートすることが好ましい。NumberStringDateLocationリポジトリ195は、少なくとも下記の方法で照会されてよい。特定の属性の名とタイプとの対に一致するすべての項目をユーザに与える属性値の値に基づいてこれらの項目を分類する属性の下記のタイプに関する分類がサポートされるDateTimeNumberStringLocationこの照会能力によって、ユーザは、下記のタイプの属性照会を入力することができる。特定の名前とタイプとの対を有するすべての項目をユーザに与える属性値によってそれを分類するこれらの項目を与えられる特定の名前とタイプの属性に関する値1と値2との間にあるすべての項目をユーザに与える例属性として料理タイプを有し、15と30との間の値を有するすべての項目をユーザに与える属性としてサイズを有し、単位のない値1と15とを有するすべての項目をユーザに与えるイベント日を有し、本日未満の値を有するすべての項目をユーザに与える発行日を有し、1925年での値を有するすべての項目をユーザに与える下記の演算子がサポートされる数字の場合int、floatLessthanGreaterthanBetween日時の場合IsBeforeAfterBetweenScoringofItems現在、項目が点数付けされる2つの重大な信号がある照会依存ランク照会独立ランクページランクは、プロバイダのウェブサイトのページランクである。ページランクは、項目がデータ集合体190内でホストされるおよび/または項目が他の項目に関連付けられないもしくは接続されない場合には存在しない。項目ランクは、複数の要因によって決定されてよい。2つの主な信号は、プロバイダ特定信号提供特定信号項目ランクは下記の信号によって定義されてよいDescの長さ題名の長さラベルの数属性の数画像提供がスパムとして報告された回数プロバイダの評価提供の最新さ項目は、として点数付けされる。既定の分類についてランクは既定分類である。好ましい実施形態ではある種のパラメータがシステム内で設定されてよい。これらのパラメータは、プロバイダあたりの項目の最大数を含む。これは、特定のプロバイダによってページが密集するのを防止する。ユーザが検索を絞り込むために属性および/またはラベルを選択するとき、システムは、ラベル、題名、説明および属性値を検索する。属性名はまた、完全な名前として検索可能であるべきである。句は、遠く離れて生じる語と比較して重く重み付けられる。ラベルは題名よりも重く重み付けられ、題名は説明よりも重く重み付けられる。属性値は、ラベルと同一に重み付けられる。各プロバイダによるマーチャント密集は、個別のプロバイダからの項目のページ数が、検索の結果として表示されるか否かを規制するためにユーザによってオンまたはオフされてよい。実行される検索に応じてマーチャント密集は望ましいかどうかはわかない。好ましい実施形態ではシステムは、同一のまたは類似のタイプの他の項目に関連した属性に基づいて新しい項目の特定のタイプの構造を定義する。検索者および他のプログラムは、GivemealljobswhoseemployerisABCCorporationandwhosejobtypeisproductmanagementなどの照会を用いてデータセットを照会することができる。本明細書に記載された例は人間のユーザを参照するが、当然のことながら、本発明の他の実施形態は、人口知能ソフトウェアプログラムなどの人ではないユーザと共に、または人もしくは人でないもののいずれかであってよいウェブを介して通信するエンティティと共に動作するように設計されてよい。人ではないユーザがソフトウェアプログラムである場合、本明細書に記載された結果および属性を表示する必要がなくてよい。代わりに、この種の実装形態は、照会結果を絞り込むために使用されうる可能性のある属性を伝達だけすることができる。この種の実施形態では、人ではない人口知能が選択されるべき多数の属性によって苦しめられないのでより多くの属性のオプションが表示されてよい。この種の実施形態では、ヒストグラムを決定することなどの方法の要素は必要でなくてよく、または方法の要素が、いくつかの利用できる属性選択に限定するためではなく、属性選択をランク付けするためだけに使用されてよい。当然のことながら、構造化データ190内の様々な情報タイプに関するコア属性が定期的に更新される必要がありうる。データが構造化データの集合体に追加されるとき、最初に人気がなかったある種の属性が人気になりうる。例えば、配役写真がテレビ番組の何期からのものかを指定することができる整数の属性タイプを有するSeason属性は、情報型ワイドショーに対する初期コア属性によって最初は意図していなかったが、ますます多くの配役写真がデータの集合体に追加されるにつれて人気になりうる。ある実施形態では、コア属性は、人気度および季節性に基づいて、スパムフィルタを通過後に自動更新もされる図3eは、任意の新しいプロバイダが提供する属性が情報タイプに関するコア属性に格上げされるべきかどうかを決定するために定期的に実行される方法350を示す。項目の情報タイプに関する属性のコアグループは、プロバイダが情報タイプの新しい項目を追加するときにはいつでも自動的に提供される属性である。好ましい実施形態ではコア属性だけが、プロバイダが表示される属性に強制的に入るために属性をスパムする可能性を低減するように提供される。情報タイプごとにその方法は、その情報タイプに関する最も人気のあるユーザが追加した属性を見て、その情報タイプに関して最も人気のある属性をコア属性に格上げする。どの属性をコア属性に格上げするべきかを決定するために使用される最も人気のあるものは、様々な実施形態に対して異なって定義される。例えば、最も人気のあるものは、コア属性内にはなく、例えば週または月などの所定の期間にわたってユーザによって最も頻繁に選択される属性であってよい。他の例として、最も人気のあるものは、コア属性内にはなく、所定の期間にわたって照会結果内で最も頻繁に現れるデータ項目を有する属性であってよい。他の例として、最も人気のあるものは、コア属性内にはなく、所定の期間にわたって最多数のプロバイダのデータ内に現れる属性であってよい。最も人気のあるものは、コア属性に追加されることによって属性が検索を絞り込むのに有用である限り任意の適切な方法で決定されてよい。例えば、プロバイダは、記事がブログ内で言及されたことを示すために記事の項目の情報タイプに関してbloggedの属性を追加し始めていてよい。この種の属性は、項目が言及されたブログのURLを示すURL属性タイプを有するであろう。固有のプロバイダまたはユーザの閾値354が情報タイプに関する特定の新しい属性を使用する場合、属性はその情報タイプに関する属性のコアグループに追加される。好ましい実施形態では、閾値はシステムを使用するプロバイダの総数に基づいている。閾値は、2~3の低いものから始め、より大きい数字に増大されることになる。同様の方法が、人気のあるラベルをラベルのコアセットに追加するためにラベルに対して実行される。ある種の好ましい実施形態では、格上げされた属性は、人または適切なソフトウェアもしくはハードウェアが実装された方法によって健全にチェックされる。概して、前の段落には構造化データの集合体190内に入力されたデータを検索し更新する方法を記載した。以下の段落では、プロバイダが構造化データの集合体190にデータを入力するまたはデータを追加することができる方法を記載する。ある種の好ましい実施形態では、プロバイダはそれらのデータに関する新しい属性を指定することもできる。図6a~6eは、どのようにプロバイダがデータ集合体内で項目を編集することができるかを示す例示のスクリーンショットである。プロバイダは、データ集合体190に内容を追加するまたは追加することができる任意の人物である。記載された実施形態では、データの集合体190は、個人、非営利組織、または企業などの1つまたは複数のプロバイダによって所有されるデータである。実施形態によってこの種のプロバイダは、ウェブを介してプロバイダ独自の構造化データの集合体を設定し追加することができ、ウェブまたは同様のネットワークを介してそれらのデータの集合体を検索可能にすることができる。プロバイダは、データが他者によって検索されることができるように、有料かまたはプロバイダの許可と引き換えかのいずれかで中央のリポジトリ内のデータを格納することを望んでいると考えられる。このような状態ではデータ集合体は、本明細書に記載された機能の一部またはすべてを含むバージョン内で、GoogleブラウザまたはGoogleデスクトップ検索エンジンなどのウェブまたはネットワークベースのブラウザを介して検索されてよい。図6a~6eは、プロバイダに、データを編集し、かつシステム内に入力することを可能にするユーザインターフェースを示す例示のスクリーンショットである。図6aは、プロバイダにデータの集合体190内のデータ項目を見て編集することを可能にするユーザインターフェース600を示す。ユーザインターフェースは、データの集合体190に項目を追加するために使用されてもよい。領域602は、データの集合体190内の項目の一部のリストを含む。ここの例ではこのリストは、項目題名601、項目タイプ603、状態605、有効期限、いくつかのインプレッション、いくつかの対象上のクリック、およびクリックスルー率を含む。例では、データ集合体内のすべての項目のサブセットが領域602に示されているが、プロバイダは、プロバイダの個人のデータ集合体620または全体のデータ集合体622のいずれかを検索することもできる。プロバイダは、非アクティブ項目616を見るまたはバルクファイル618をアップロードすることもできる。各データ項目は、関連のeditリンク619を有する。好ましい実施形態では、プロバイダはプロバイダ独自のデータ項目を編集だけすることができる。領域604によって、プロバイダは、既存の情報タイプを示すドロップダウンメニューなどの選択デバイスを表示することができる。プロバイダが情報タイプを選択する場合、プロバイダは、プロバイダのデータに関する領域606内の情報タイプの説明を追加することができる。図6bは、プロバイダにデータの集合体190内のデータ項目を見て編集することができるユーザインターフェースを示す。項目はNewsandarticlesという情報タイプを有する。プロバイダが図6aの領域602内のデータ項目を選択した場合、その項目の情報は領域のフィールド611内に表示される。しかし、例ではプロバイダは項目を選択せず、したがってプロバイダは新しいデータ項目を自由に入力する。例ではNewsandarticlesという情報タイプ610は以下のフィールドを含む。Title、Pictures、Descriptionおよび照会結果内に表示されるべきリンク614。図6bのユーザインターフェースによって、プロバイダは、項目の属性およびラベルも編集することができる。各情報タイプは関連の属性を有するが、特定のタイプのすべてのデータ項目が、その情報タイプに関するすべての可能性のある属性に対する値を有するとは限らないことに留意されたい。例では、参照番号612によって示されるようにプロバイダは、数量1の項目が利用できるまたは存在することを示した。値が、この項目に関するAuthor属性またはNewsSource属性に対して指定されていない。それらの属性のそれぞれは、textという属性タイプを有する。プロバイダは、個別のデータ項目の属性に対する値を自由に追加する。プロバイダは、領域613を使用して属性を追加することもできる。ここで、プロバイダは属性名および属性値を追加することができる。プロバイダは、領域618内の連絡先情報に関する属性値を提供することができる。プロバイダは、領域619内の位置情報に関する属性値を提供することができる。プロバイダは、領域619内の項目にラベルを追加することができる。ある種の実施形態では、情報タイプは既定の属性名である。ここで、情報タイプはNewsandArticlesであり、これがラベルでもある。図6cは、プロバイダにデータの集合体190内のデータ項目を見て編集することを可能にする図6bのユーザインターフェースを示す。例では、プロバイダは新しいプロバイダが定義した属性613に関する名前および値を追加することができる。既定の属性タイプはtextであるが、プロバイダは、数字単位、数字、データ範囲、大きいテキスト、URL、ブール、および位置などの他の属性タイプを選択することができる。図6dは、プロバイダにデータ集合体190内のデータ項目を見て編集することを可能にするユーザインターフェースを示す。項目はProductという情報タイプ630を有する。プロバイダが図6aの領域602内のデータ項目を選択した場合、その項目の情報は領域のフィールド611内に表示される。しかし、例では、プロバイダは項目を選択せず、したがってプロバイダはユーザインターフェースを使用して新しい項目を自由に入力する。例では、Productsという情報タイプは以下のフィールドを含む。Title、Pictures、Descriptionsおよび照会結果内に表示されるべきリンク634。図6dのユーザインターフェースによって、プロバイダは、項目の属性およびラベルを編集することもできる。各情報タイプは関連の属性を有するが、特定の情報タイプのすべてのデータ項目がその情報タイプに関するすべての可能性のある属性に対する値を有するとは限らないことに留意されたい。例では、参照番号632によって示されるように、プロバイダは、項目あたり150の価格を示している。数量1が指定される。Priceタイプは、プロバイダが設定している価格のタイプである。この項目に関するPriceoption、Brand、Condition、およびProductTypeに対する値は指定されていない。それらの属性のそれぞれは、textという属性タイプを有する。この実施形態ではプロバイダは、プロバイダが指定したそれらの属性に関する属性タイプを変更することができる。プロバイダは、個別のデータ項目の属性に対する値を自由に追加することができる。プロバイダは、領域613を使用して属性を追加することもできる。ここで、プロバイダは属性名および属性値を追加することができる。この実施形態では、プロバイダが追加する属性は、現在の情報タイプのプロバイダの項目のすべてに追加される。ここで例えば、タイプProductsのプロバイダの項目のすべてが、新しく追加された属性613が定義されると新しく追加された属性613を与えられる。項目ごとの値は一般に、個々に追加される。ある種の実施形態によって、プロバイダは、指定された情報タイプのプロバイダの項目のすべてに対して値を指定することもできる。上述のように、新しい属性が属性のコアセットに昇格することが可能である。他の実施形態では、新しい属性が情報のタイプのすべての項目に必ずしも追加されない。他の実施形態では、プロバイダは、定義されたグループのプロバイダのすべてが同一の属性を有することに合意することができ、その結果、1つのプロバイダが属性を追加するとき、グループ内の他のプロバイダも同一の属性を有することになる。プロバイダは、領域618内の連絡先情報に関する属性値を提供することができる。プロバイダは、領域619内の位置情報に関する属性値を提供することができる。プロバイダは、領域638内のPayment方法に関する属性値を提供することができる。プロバイダは、ラベルを領域616内の項目に追加することができる。ある種の実施形態では、情報タイプは既定の属性名である。ここで、情報タイプはProductsであり、これがラベルでもある。この実施形態では、プロバイダが追加するラベルは、現在のタイプのプロバイダの項目のすべてに追加されるわけではない。上述のように、新しいラベルがラベルのコアセットに昇格することが可能である。他の実施形態では、新しいラベルは、情報タイプのすべての項目に常に追加される。図6eは、プロバイダにデータ集合体190内のデータ項目を見て編集することが可能になる図6dのユーザインターフェースを示す。この例では、Contacts、Payments、およびLocationがProduct情報タイプのすべての属性である。それらは、複雑なタイプを有する属性である。例では、プロバイダは情報タイプProductsの項目に関する連絡先618に関する値を追加することができる。ここでプロバイダは、ニックネーム、電話番号、電子メールアドレスの一部またはすべてを指定する。例ではプロバイダは、情報タイプProductsの項目に関するPayments638に関する値を追加することができる。ここで、プロバイダはPayment方法およびNotesの一部またはすべてを指定する。例では、プロバイダは情報タイプProductsの項目に関する位置619に関する値を追加することができる。ここで、プロバイダはテキストメモの一部またはすべてを指定する。この実施形態では、顧客がこの位置および配達区域から受け取ることができるかどうかを示すためのチェックボックスもある。例では、Contactの値、Paymentの値、およびLocationの値が項目ごとに個別に入力される。プロバイダが追加する値は、現在の情報タイプのプロバイダの項目のすべてに追加されるわけではない。ここで例えば、情報タイプProductsのプロバイダの項目のすべてが、図6eに示されるContactの値、Paymentの値、およびLocationの値を与えられるとは限らない。一般に、項目ごとの値は個々に追加される。ある種の実施形態によって、プロバイダは、指定された情報タイプのプロバイダの項目のすべてに対して値を指定することもできる。例えば、支払い情報は、プロバイダのすべてのProductsに関して同一であってよい。プロモータは、図6のUIを介してまたは図7および図8に示されるバルクアップロード方法を介してのいずれかで項目を入力することができる。図7は、バルクアップロードファイルを登録するためのユーザインターフェースを示す例示のスクリーンショット700である。バルクアップロードファイルは、データ集合体190を生成するまたはデータ集合体190に追加するために使用される。この例では、同一の情報タイプのすべてである項目のフラットファイルが追加されるべきである。例では、ファイル名712はlocalinventoryである。プロバイダは、予め定義された情報タイプまたはカスタムの情報タイプであるデータタイプ714を選択する。プロバイダは、データ内のテキスト文字列に対する言語716を選択する。プロバイダがボタンRegisterbulkuploadfile718を選択するとき、ファイル名712を有するファイルが登録され、次いでプロバイダはファイルをアップロードすることが許可される。プロバイダは、ウェブベースのアップローディングインターフェースを使用してまたはFTPもしくはRSSなどの他の機構を使用してファイルをアップロードすることができる。図8aは、バルクアップロードされるべきタブ区切りのファイルに関する形式801を示す。下記は、バルクアップロードファイルに対する形式の要求である。タブ区切りされたプレーンテキストファイルの第1の行はヘッダであるを含まなければならない行あたり1つの項目最後の行に末尾タブを有しないファイルはLATIN1またはUTF8符号化で保存されなければならない。ASCIIも、それがLATIN1のサブセットであるので許容可能である。リンクおよび画像URLは完全に揃ってなければならない。つまり、それらはhttpportionを含まなければならない。タブ、キャリッジリターン、または改行文字HTMLタグ、コメント、およびエスケープシーケンス好ましい実施形態では、データ項目は、属性も含むアップロードされるファイルの一部である。他の好ましい実施形態ではデータ項目および属性は構築される個別のファイル内にアップロードされ、その結果、どの属性値がどのデータ項目に関係するかが明らかである。図8bは、バルクアップロードファイルを生成するためにプロバイダによって使用される例示の方法の流れ図800である。プロバイダは、人、またはハードウェアもしくはソフトウェアであってよい。要素802記載された方法は、バルクアップロードファイルを生成するためにMicrosoftExcelなどの表計算プログラムを使用する。MicrosoftExcelのような表計算プログラムを使用すると、バルクアップロードを生成し、かつそれを適切な形式に変換することを容易にする。適切にフォーマットされたファイルをもたらす他の方法が使用されてよい。要素804一例として、製品バルクアップロードに関するヘッダ行は図8c内の列832のように見えうる。プロバイダがサブミットしたい項目の情報タイプによりバルクアップロード内の列のそれぞれを指定する。スプレッドシート832の第1の行上に、プロバイダがプロバイダの項目を説明するために含めたい属性のそれぞれの名前を入力する。これがヘッダ行である。ヘッダ行の内容は、サブミットされる情報の情報タイプに依存し、プロバイダが、定義された情報タイプを送信しているか、プロバイダがプロバイダ自体で生成したものを送信しているかに依存する。カスタム情報タイプバルクアップロードは、任意の情報タイプをサブミットするために使用されてよい。プロバイダがプロバイダ独自の情報タイプを送信している場合、プロバイダは予め定義された属性の任意の組合せを使用することができる。好ましい実施形態では、プロバイダが予め定義された属性を使用することが強く推奨される。プロバイダは無制限の数のカスタムの属性を含むこともできる。プロバイダは、プロバイダの項目を最良に説明する1組の属性を選ぶべきである。定義された情報タイププロバイダは、定義された情報タイプのうちの1つに関するバルクアップロードを送信することができる。プロバイダがプロバイダのバルクアップロード内にそれらを含むことが強く推奨される。それらは、照会を検索するために項目のより正確な一致を可能にする。プロバイダが与える情報が多ければ多いほど、ユーザが項目を捜し出すことが容易になる。好ましい実施形態ではプロバイダは、プロバイダの項目が、行われた検索の重要な部分に現れることを可能にするためにこれらの推奨された属性を含まなければならない。要素806各行834上でプロバイダは、プロバイダのデータ集合体内の項目に関する情報を入力する。情報の各片は、それが存在する列のヘッダに反映すべきである。。各行は行あたり1つの項目だけを含む。図8c参照。要素808以前に登録されたファイル名を使用してスプレッドシートをタブ区切りのテキストファイルに変換する。プロバイダがスプレッドシート内のすべての項目を入力した後、プロバイダはタブ区切りのテキスト形式でスプレッドシートを保存する。登録されたファイル名は後続のアップロードのために再使用されてよい。アップロードされたファイルが登録されていない名前を有する場合、ファイル内の項目は、データ集合体190に追加されない。好ましい実施形態では更新されたバルクアップロードは、項目がデータ集合体190内に残っていることを保証するために30日ごとに少なくとも1度送信されなければならない。要素810図8dはファイルをアップロードするためのユーザインターフェース840を示す。要素812プロバイダがバルクアップロードを送信した後、プロバイダは、中央のウェブサイトにログインすることによってバルクアップロードの状態を知ることができる。結果がSuccessとして記載される場合、バルクアップロードは変更される必要はない。そうでない場合、プロバイダは、誤りを訂正する方法についての情報を知るためにバルクアップロードのファイル名上をクリックすることができる。バルクアップロードがアップロードされた後、ファイルは、項目、属性、およびラベルをデータ集合体190および図5のデータ構造に追加するように処理されることになる。アップロードが承認されると同一のファイル名を有する任意の今後の更新が自動的に処理されることになる。本発明がいくつかの実施形態に関して上述されたが、様々な変更形態が本発明の範囲内で作成されてよい。例えば、ある種の好ましい実施形態は、無効なまたはスパムの属性およびラベルを検出する方法およびシステムを含む。データ項目が検索の最上位になることを可能にする属性をプロバイダのデータに追加することはプロバイダにとって望ましくない。この種の属性を避けるために使用されるいくつかの方法は、ブラックリスト、特定のヒストグラム分布などを含む。他の好ましい実施形態では、表示された上位の属性およびラベルは、属性の主要なタイプの組およびラベルの人気度だけではなく値の分布に基づいて決定される。例えば、色が属性であり、赤、青および緑が上位の色として知られる場合、色は詳細化するのに良い属性であろう。一方、それぞれが3回生じる色に対して100個の値を有することはそれほど有用ではない。他の好ましい実施形態は、属性、各提供の項目ランク/提供ランクを使用するプロバイダの数に基づいて高度な信頼度点数付けを行う。他の好ましい実施形態は、どの属性をユーザに表示するべきかを決定するためにユーザからのクリック信号を使用する。属性およびラベルは、人気度ランクとして定義された何らかのものによって点数付けられる。PR照会結果の人気度その特定の照会に関するCTR他の好ましい実施形態では、ユーザのALWAYS2属性が特定の照会を制限する場合、照会結果に既に適用されたそれらの制限を示す。したがって、本発明の開示は、添付の特許請求の範囲に記載された本発明の範囲の例示であって限定するものではない。