IBM Cloud Docs
DQLの概要

DQLの概要

Discoveryクエリー言語は、データのフィルタリング、検索、分析に使用できる構文を定義しています。

Discoveryクエリー言語クエリーの書き方

Discoveryクエリー言語は、インデックスされたドキュメントの構造を活用します。 次のJSONスニペットは、Entitiesエンリッチメントが適用されたコレクションからインデックス化されたドキュメントを示しています。 エンリッチメントの結果、JSON構造は、都市名、企業、有名人などの既知のエンティティのあらゆる言及をキャプチャする。

この例では、認識される実体は会社名 IBM です。

{
  "document": {
    "document_id": "f7f27ea30eb3e4c0ce21830618d9ee99",
    "enriched_text": [
      {
        "entities": [
          {
            "model_name": "natural_language_understanding",
            "mentions": [],
            "text":"IBM",
            "type":"Organization"
          }
        ]
      }
    ]
  }
}

エンティティ IBM が言及されているすべての文書を返すクエリを作成するには、次の構文を使います:

クエリの構造 enriched_text.entities.text:IBM。enriched_textのtextはエンリッチメントが適用されているフィールドで、IBMはenriched_text.entities.textサブフィールドで探している用語です。
Example query structure

この基本的なクエリは、: 演算子の前に入れ子になったパス式を含んでいます。 各path要素は、ピリオド(.)で区切られたドキュメント内のフィールド名です。: 演算子は、演算子に続くテキストが結果に含まれなければならないことを示します。

:: 演算子は、テキストが結果の中で正確に一致しなければならないことを示します。 詳細は クエリー演算子 を参照してください。 この2つの演算子がどのように使われるかは、以下の例で見ることができる。

  • マッチしたドキュメントを関連性の高い順に返すには、POST リクエストで以下のデータオブジェクトを渡します:

    {
      "query":"enriched_text.entities.text:IBM"
    }
    
  • 一致するドキュメントを任意の順番で返すには、POST リクエストで以下のデータオブジェクトをクエリボディとして渡します:

    {
      "filter":"enriched_text.entities.text::IBM"
    }
    

フィルターとクエリーパラメーターを併用する

filter パラメータは、query パラメータよりも速く返され、その結果はキャッシュされます。 filterquery パラメータを使用したクエリを、小さなデータセットに対して別々に送信した場合、それぞれのリクエストは(同一ではないにしても)似たような結果を返します。

大きなデータセットでは、関連性の高い順に結果を返す必要がある場合、filterquery パラメータを組み合わせます。 filter パラメータが最初に適用されるため、パラメータを一緒に使うとパフォーマンスが向上します。 ドキュメントをフィルタリングし、結果をキャッシュする。 query パラメータは、キャッシュされた結果をランク付けします。

フィルタの例IDでドキュメントを取得する

照会本体:

{
  "filter": "document_id::b6d8c6e3-1097-421b-9e39-75717d2554aa"
}

ドキュメントが存在する場合、クエリはマッチする結果を1つ返します。 そうでない場合、クエリーはマッチする結果を返さない。

フィルタの例ファイル名から文書IDを検索する

文書の document_id はわからないが、文書の元の filename はわかっている場合、filterreturn のパラメータを一緒に使って document_id を発見することができます。

照会本体:

{
  "filter": "extracted_metadata.filename::100674.txt",
  "return": [ "document_id", "extracted_metadata" ]
}

回答:

{
  "matching_results": 1,
  "results": [
    {
      "document_id": "b6d8c6e3-1097-421b-9e39-75717d2554aa",
      "extracted_metadata": {
        "sha1": "AD447F7592A17CDCBF0A589C4E6EC2087AF7H35F",
        "filename": "100674.txt",
        "file_type": "text"
      }
    }
  ]
}

フィルタの例エンティティ値に言及している文書を検索する

このクエリは、エンティティ Gilroy に言及している文書を探し、4つのマッチする文書を見つけます。

照会本体:

{
  "filter": "enriched_text.entities.text::Gilroy"
}

回答:

{
  "matching_results": 4
}

ネストした値のフィルタリング

1つのフィルタを別のフィルタの中に入れ子にすることで、返されるドキュメントが複数の条件に一致するようにすることができます。

これらの例に使われた文書では、"Gilroy" という実体は "Location"(カリフォルニア州の町)としても "Person"(苗字)としても現れます。 "Gilroy" が場所として現れる文書を見つけるには、入れ子になった2つのフィールドを同時にフィルタリングするクエリを書きます:エンティティテキストは "Gilroy" でなければならず、エンティティタイプは "Location" でなければなりません。

クエリを記述する方法の1つは次のとおりです

{
  "filter": "enriched_text.entities.text::Gilroy,enriched_text.entities.type::Location"
}

このクエリは、あるパス enriched_text.entities.textGilroy であり、あるパス enriched_text.entities.type::LocationLocation である文書にマッチします。 しかし、これら2つのパスが同じ entities オブジェクトの下にあるという保証はない。 例えば、クエリは GilroyPerson エンティティタイプとして持ち、同時に他の Location エンティティタイプオブジェクトを持つ文書にマッチします。

このクエリーのネストされたセマンティクスを正確に捉えるには、以下の構文を使ってフィルター値をネストする:

照会本体:

{
  "filter": "enriched_text.entities:(text::Gilroy,type::Location)"
}

このより厳密なクエリは、entities オブジェクトが存在し、textGilroy と等しく、typeLocation と等しい文書にのみマッチします。

別の例として、entities オブジェクトを含み、textGilroy が等しく、type ないLocation が等しい文書にマッチさせたい場合は、クエリー内で ノットイコール 演算子を使うことができます:

{
  "filter": "enriched_text.entities:(text::Gilroy,type::!Location)"
}

また、集計を使って、より高度なフィルタリングを行うこともできる。 使用可能な集約タイプの詳細については、クエリ集約 を参照してください。

Discovery クエリ言語の詳細については、以下のトピックを参照してください