翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # SPARQL クエリヒント クエリヒントを使用して Amazon Neptune の特定の SPARQL クエリの最適化と評価戦略を指定することができます。 クエリヒントは、以下の部分で SPARQL クエリに組み込まれている追加の 3 つのパターンで表されます。 ``` scope hint value ``` + *scope* - クエリ内の特定のグループまたは完全なクエリなど、クエリヒントが適用されるクエリの部分を決定します。 + *hint* – 適用するヒントのタイプを特定します。 + *value* – 検討中のシステムアスペクトの動作を決めます。 クエリのヒントとスコープは、Amazon Neptune 名前空間 `http://aws.amazon.com/neptune/vocab/v01/QueryHints#` の事前定義された条件として表示されます。このセクションの例には、クエリで定義され、クエリに含まれている `hint` プレフィックスとして名前空間が含まれています。 ``` PREFIX hint: ``` たとえば、以下は `SELECT` クエリに `joinOrder` ヒントを含める方法を示します。 ``` PREFIX hint: SELECT ... { hint:Query hint:joinOrder "Ordered" . ... } ``` 前述のクエリは、Neptune エンジンに、クエリ内の結合を評価するように指示します。*指定された*順序付けを行い、自動並べ替えを無効にします。 クエリヒントを使用するときは、以下について検討します。 + 単一のクエリでさまざまなクエリヒントを組み合わせることができます。たとえば、ボトムアップ評価のためにサブクエリに注釈を追加するには `bottomUp` クエリヒントを使用できます。また、サブクエリ内の結合の順序を修正するには `joinOrder` クエリヒントを使用できます。 + 別の重複していないスコープで同じクエリを複数回使用できます。 + クエリヒントはヒントです。クエリエンジンは通常、特定のクエリヒントを考慮することを目的としていますが、それらを無視することもあります。 + クエリヒントはセマンティクスを維持します。クエリヒントを追加しても、クエリの出力は変更されません (順序保証が指定されていない場合、つまり、ORDER BY を使用して結果の順序が明示的に適用されない場合を除く)。 以下のセクションでは、Neptune で使用可能なクエリヒントとその使用方法に関する詳しい情報が記載されています。 **Topics** + [Neptune における SPARQL クエリヒントの範囲。](#sparql-query-hints-scope) + [`joinOrder` SPARQL クエリヒント](sparql-query-hints-joinOrder.md) + [`evaluationStrategy`SPARQL クエリヒント](sparql-query-hints-evaluationStrategy.md) + [`queryTimeout` SPARQL クエリヒント](sparql-query-hints-queryTimeout.md) + [`rangeSafe` SPARQL クエリヒント](sparql-query-hints-rangeSafe.md) + [`queryId`SPARQL クエリヒント](sparql-query-hints-queryId.md) + [`useDFE` SPARQL クエリヒント](sparql-query-hints-useDFE.md) + [DESCRIBE で使用される SPARQL クエリヒント](sparql-query-hints-for-describe.md) ## Neptune における SPARQL クエリヒントの範囲。 次の表は、Amazon Neptune で使用可能なスコープ、関連付けられたヒント、SPARQL クエリヒントの説明を示します。これらのエントリの `hint` プレフィックスは、ヒントの Neptune 名前空間を表します。 ``` PREFIX hint: ``` | スコープ | サポートされるヒント | 説明 | | --- | --- | --- | | hint:Query | [joinOrder](sparql-query-hints-joinOrder.md) | クエリヒントはクエリ全体に適用されます。 | | hint:Query | [queryTimeout](sparql-query-hints-queryTimeout.md) | タイムアウト値はクエリ全体に適用されます。 | | hint:Query | [RangeSafe](sparql-query-hints-rangeSafe.md) | タイプ昇格は、クエリ全体に対して無効になっています。 | | hint:Query | [queryId](sparql-query-hints-queryId.md) | クエリ ID 値はクエリ全体に適用されます。 | | hint:Query | [useDFE](sparql-query-hints-useDFE.md) | DFE の使用は、クエリ全体に対して無効になっています。 | | hint:Group | [joinOrder](sparql-query-hints-joinOrder.md) | クエリヒントは指定されたグループの最上位の要素に適用されますが、ネストされた要素 (サブクエリなど) や親要素には適用されません。 | | hint:SubQuery | [evaluationStrategy](sparql-query-hints-evaluationStrategy.md) | ヒントは指定されて、ネストされた SELECT サブクエリに適用されます。サブクエリの前に計算されたソリューションを考慮せずに、サブクエリは個別に評価されます。 | # `joinOrder` SPARQL クエリヒント SPARQL クエリを送信すると、Amazon Neptune クエリエンジンはクエリの構造を調査します。クエリの各パートの順序を変更し、評価に必要な作業の量とクエリレスポンス時間を最小限にしようとします。 たとえば、一連の接続された 3 つのパターンは通常、指定された順序では評価されません。ヒューリスティックと統計 (個々のパターンの選択性と共有変数で接続される方法など) を使用して順序が変更されます。さらに、サブクエリ、FILTER、複雑な OPTIONAL や MINUS ブロックなど、より複雑なパターンがクエリに含まれている場合、Neptune クエリエンジンは評価の順序を効率的にするために、可能な限りそれらの順序を変更します。 より複雑なクエリでは、Neptune で選択されるクエリの評価順序は常に最適であるとは限りません。たとえば、Neptune では、クエリ評価中に発生するインスタンスデータ固有の特性 (グラフでの power ノードの発生など) を見逃す可能性があります。 データの正確な特性がわかっていて、クエリ実行の順序を手動で指定する場合は、Neptune `joinOrder` クエリヒントを使用して特定の順序でクエリが評価されるように指定します。 ## `joinOrder` SPARQL ヒント構文 `joinOrder` クエリヒントは、SPARQL クエリに含まれる 3 つのパターンとして指定されます。 わかりやすくするために、次の構文では、クエリに定義されて含まれる `hint` プレフィックスを使用して Neptune クエリヒント名前空間を指定します。 ``` PREFIX hint: scope hint:joinOrder "Ordered" . ``` **利用可能なスコープ** + `hint:Query` + `hint:Group` クエリヒントスコープの詳細については、「[Neptune における SPARQL クエリヒントの範囲。](sparql-query-hints.md#sparql-query-hints-scope)」を参照してください。 ## `joinOrder`SPARQL ヒントの例 このセクションでは、`joinOrder` クエリヒントを使用した場合と使用していない場合に記述されたクエリ、および関連する最適化を示します。 この例では、データセットに次のものが含まれていることを前提としています。 + `Jane` を含む 1,000 人に `:likes` エッジを持つ (「いいね！」した) `John` という名前の 1 人の人物。 + `John` を含む 10 人に `:likes` エッジを持つ (「いいね！」した) `Jane` という名前の 1 人の人物。 **クエリヒントなし** 次の SPARQL クエリは、一連のソーシャルネットワーキングデータから相互に「いいね！」した `John` と `Jane` という名前のすべての人物のペアを抽出します。 ``` PREFIX : SELECT ?john ?jane { ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` Neptune クエリエンジンは、記述とは異なる順序でステートメントを評価する可能性があります。たとえば、次の順序で評価するように選択される場合があります。 1. `John` という名前の人物をすべて検索します。 1. `:likes` エッジによって `John` に接続されているすべての人物を検索します。 1. `Jane` という名前の人物でこのセットをフィルタリングします。 1. `:likes` エッジによって `John` に接続されている人物でこのセットをフィルタリングします。 データセットによると、この順序で評価すると 2 番目のステップで 1,000 のエンティティが抽出されます。これは 3 番目のステップで 1 つのノード `Jane` に絞り込まれます。そして最後のステップで、`Jane` も `John` ノードに対して `:likes` エッジを持っていると判断されます。 **クエリヒント** `Jane` ノードには発信 `:likes` エッジが 10 個しかないため、このノードから開始する方が有利です。これにより、2 番目のステップで 1,000 のエンティティを抽出することを回避し、クエリの評価中の作業量を低減できます。 次の例では **joinOrder** クエリヒントを使用し、クエリの自動結合の順序変更をすべて無効にすることで、`Jane` ノードとその発信エッジが最初に処理されるようにします。 ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:joinOrder "Ordered" . ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` 応用できる現実社会のシナリオとしては、ネットワーク内の人物を「コネクションが多いインフルエンサー」や「コネクションが少ない通常のユーザー」に分類する、ソーシャルネットワークへの応用などが挙げられます。このようなシナリオでは、前述の例のようなクエリで、インフルエンサー (`John`) の前に通常のユーザー (`Jane`) が処理されるようになっていることを確認します。 **クエリヒントと順序変更** この例をさらに一歩進めることができます。`:name` 属性が単一のノードに固有であることがわかっている場合は、`joinOrder` クエリヒントの順序を変更して使用することで、クエリの時間を短縮することができます。このステップでは、最初に一意のノードが抽出されるようにします。 ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:joinOrder "Ordered" . ?person1 :name "Jane" . ?person2 :name "John" . ?person1 :likes ?person2 . ?person2 :likes ?person1 . } ``` この場合、各ステップで以下の単一のアクションへのクエリを減らすことができます。 1. `:name` `Jane` を持つ 1 人の人物のノードを検索します。 1. `:name` `John` を持つ 1 人の人物のノードを検索します。 1. 最初のノードが 2 番目のノードに `:likes` エッジで接続されていることを確認します。 1. 2 番目のノードが最初のノードに `:likes` エッジで接続されていることを確認します。 **重要** 間違った順序を選択した場合、`joinOrder` クエリヒントのパフォーマンスが大幅に低下する可能性があります。たとえば、前述の例は `:name` 属性が一意でない場合、非効率的です。100 ノードすべての名前が `Jane` で 1,000 ノードすべての名前が `John` の場合、クエリで 1,000 \$1 100 (100,000) ペアの `:likes` エッジを確認することになります。 # `evaluationStrategy`SPARQL クエリヒント `evaluationStrategy` クエリヒントは、注釈が付けられたクエリのフラグメントを独立したユニットとして下部から評価するように Amazon Neptune クエリエンジンに指示します。つまり、前回の評価ステップからのソリューションは、クエリフラグメントの計算に使用されません。クエリフラグメントはスタンドアロンユニットとして評価され、生成されたソリューションは計算された後にクエリの残りの部分と結合されます。 `evaluationStrategy` クエリヒントを使用することは、(パイプライン化されていない) クエリプランをブロックすることを意味します。つまり、クエリヒントによって注釈が付けられたフラグメントのソリューションは、メインメモリでマテリアライズおよびバッファされます。特に注釈が付けられたクエリフラグメントが大量の結果を計算する場合、このクエリヒントを使用することによって、クエリの評価に必要なメインメモリの量が大幅に増加する可能性があります。 ## `evaluationStrategy` SPARQL ヒント構文 `evaluationStrategy` クエリヒントは、SPARQL クエリに含まれる 3 つのパターンとして指定されます。 わかりやすくするために、次の構文では、クエリに定義されて含まれる `hint` プレフィックスを使用して Neptune クエリヒント名前空間を指定します。 ``` PREFIX hint: hint:SubQuery hint:evaluationStrategy "BottomUp" . ``` **利用可能なスコープ** + `hint:SubQuery` **注記** このクエリヒントは、ネストされたサブクエリでのみサポートされています。 クエリヒントスコープの詳細については、「[Neptune における SPARQL クエリヒントの範囲。](sparql-query-hints.md#sparql-query-hints-scope)」を参照してください。 ## `evaluationStrategy`SPARQL ヒントの例 このセクションでは、`evaluationStrategy` クエリヒントを使用した場合と使用していない場合に記述されたクエリ、および関連する最適化を示します。 この例では、データセットに次の特性があることを前提としています。 + 1,000 のエッジラベル `:connectedTo` が含まれています。 + 各 `component` ノードは、平均 100 の他の `component` ノードに接続されています。 + ノード間の 4 つのホップの周期的な接続の標準的な数は、約 100 です。 一般的な例として、`evaluationStrategy` ヒントはサイクルを含むクエリパターンを最適化するのに役立ちます。 **クエリヒントなし** 次の SPARQL クエリは、4 つのホップを通じて周期的に相互に接続される `component` ノードをすべて抽出します。 ``` PREFIX : PREFIX hint: SELECT * { ?component1 :connectedTo ?component2 . ?component2 :connectedTo ?component3 . ?component3 :connectedTo ?component4 . ?component4 :connectedTo ?component1 . } ``` Neptune クエリエンジンのアプローチは、次のステップを使用してこのクエリを評価することです。 + グラフ内の 1,000 の `connectedTo` エッジをすべて抽出します。 + 100 倍で展開します (100 は component2 からの発信 `connectedTo` エッジの数)。 中間結果: 100,000 ノード。 + 100 倍で展開します (100 は component3 からの発信 `connectedTo` エッジの数)。 中間結果: 10,000,000 ノード。 + サイクルを閉じるために 10,000,000 ノードをスキャンします。 この結果、一定量のメインメモリを持つクエリプランがストリーミングされます。 **クエリヒントとサブクエリ** メインメモリスペースと高速コンピューティングのトレードオフを実現できます。`evaluationStrategy` クエリヒントを使用してクエリを書き換えることで、2 つの小さなマテリアライズされたサブセット間の結合をエンジンに計算させることができます。 ``` PREFIX : PREFIX hint: SELECT * { { SELECT * WHERE { hint:SubQuery hint:evaluationStrategy "BottomUp" . ?component1 :connectedTo ?component2 . ?component2 :connectedTo ?component3 . } } { SELECT * WHERE { hint:SubQuery hint:evaluationStrategy "BottomUp" . ?component3 :connectedTo ?component4 . ?component4 :connectedTo ?component1 . } } } ``` 今後のパターンの入力として、前の 3 つのパターンの結果を反復的に使用しながら 3 つのパターンを順番に評価する代わりに、`evaluationStrategy` ヒントを使用すると、2 つのサブクエリを個別に評価することができます。この 2 つのサブクエリは、中間結果で 100,000 のノードを生成します。これは、最終出力を生成するために結合されます。 特に、より大規模なインスタンスタイプで Neptune を実行するとき、メインメモリにこれら 2 つの 100,000 サブセットを一時的に保管することにより、評価の時間を大幅に短縮するのと引き換えにメモリ使用量が増加します。 # `queryTimeout` SPARQL クエリヒント `queryTimeout` クエリヒントは、DB パラメータグループに設定されている `neptune_query_timeout` 値より短いタイムアウトを指定します。 このヒントの結果としてクエリが終了すると、 `Operation terminated (deadline exceeded)` メッセージとともに `TimeLimitExceededException` がスローされます。 ## `queryTimeout` SPARQL ヒント構文 ``` PREFIX hint: SELECT ... WHERE { hint:Query hint:queryTimeout 10 . # OR hint:Query hint:queryTimeout "10" . # OR hint:Query hint:queryTimeout "10"^^xsd:integer . ... } ``` タイムアウト値はミリ秒単位で表されます。 タイムアウト値は、DB `neptune_query_timeout` パラメーターグループで設定された値より小さくする必要があります。それ以外の場合は、 `Malformed query: Query hint 'queryTimeout' must be less than neptune_query_timeout DB Parameter Group` メッセージとともに `MalformedQueryException` 例外がスローされます。 `queryTimeout` クエリヒントは、メインクエリの `WHERE` 句、または次の例に示すようにいずれかのサブクエリの `WHERE` 句に指定する必要があります。 すべてのクエリ / サブクエリおよび SPARQL 更新セクション（INSERT、DELETE など）で 1 回のみ設定する必要があります。それ以外の場合は、 `Malformed query: Query hint 'queryTimeout' must be set only once` メッセージとともに `MalformedQueryException` 例外がスローされます。 **利用可能なスコープ** `queryTimeout` ヒントは、SPARQL クエリと更新の両方に適用できます。 + SPARQL クエリでは、メインクエリまたはサブクエリの WHERE 句に表示されます。 + SPARQL 更新では、INSERT、DELETE、または WHERE 句で設定できます。複数の更新句がある場合は、そのうちの 1 つにのみ設定できます。 クエリヒントスコープの詳細については、「[Neptune における SPARQL クエリヒントの範囲。](sparql-query-hints.md#sparql-query-hints-scope)」を参照してください。 ## `queryTimeout`SPARQL ヒントの例 `UPDATE` クエリのメイン `WHERE` 句で `hint:queryTimeout` を使用する例を示します。 ``` PREFIX hint: INSERT { ?s ?p ?o } WHERE { hint:Query hint:queryTimeout 100 . ?s ?p ?o . } ``` ここで、`hint:queryTimeout` はサブクエリの `WHERE` 句にあります。 ``` PREFIX hint: SELECT * { ?s ?p ?o . { SELECT ?s WHERE { hint:Query hint:queryTimeout 100 . ?s ?p1 ?o1 . } } } ``` # `rangeSafe` SPARQL クエリヒント SPARQL クエリのタイププロモーションをオフにするには、このクエリヒントを使用します。 数値または範囲を越える `FILTER` を含む SPARQL クエリを送信する場合、Neptune クエリエンジンは通常、クエリの実行時に型の上位変換を使用する必要があります。つまり、フィルタリングする値を保持できるすべてのタイプの値を調べる必要があります。 たとえば、55 に等しい値をフィルタリングする場合、エンジンは 55 に等しい整数、55L に等しい長整数、55.0 に等しい浮動小数点数などを探す必要があります。各型の上位変換では、ストレージに対する追加のルックアップが必要なため、単純なクエリの完了に予期せず長い時間がかかることがあります。 多くの場合、特定のタイプの値を見つけるだけで済むことが事前にわかっているため、型の上位変換は不要です。この場合、クエリを劇的に高速化するには、型の上位変換をオフにする `rangeSafe` クエリヒントを使います。 ## `rangeSafe` SPARQL ヒント構文 `rangeSafe` クエリヒントは、タイププロモーションをオフにする `true` の値を取ります。また、`false` (デフォルト) の値も受け入れます。 **例。**次の例は、1 より大きい `o` の整数値のフィルタリング時にタイプ昇格をオフにする方法を示しています。 ``` PREFIX hint: SELECT * { ?s ?p ?o . hint:Prior hint:rangeSafe 'true' . FILTER (?o > '1'^^) ``` # `queryId`SPARQL クエリヒント このクエリヒントを使用して、独自の queryId 値を SPARQL クエリに割り当てます。 例: ``` PREFIX hint: SELECT * WHERE { hint:Query hint:queryId "4d5c4fae-aa30-41cf-9e1f-91e6b7dd6f47" {?s ?p ?o}} ``` 割り当てる値は、Neptune DB 内のすべてのクエリで一意である必要があります。 # `useDFE` SPARQL クエリヒント このクエリヒントを使用して、クエリを実行するための DFE の使用を有効にします。[neptune\$1dfe\$1query\$1engine](parameters.md#parameters-instance-parameters-neptune_dfe_query_engine) インスタンスパラメータはデフォルトでは `viaQueryHint` に設定されるため、デフォルトでは、このクエリヒントが `true` に設定されていないと、Neptune は DFE を使用しません。このインスタンスパラメータを `enabled` に設定した場合、`useDFE` クエリヒントが `false` に設定されているクエリを除き、すべてのクエリに DFE エンジンが使用されます。 DFE の使用をクエリに使用できるようにする例 ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:useDFE true . ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` # DESCRIBE で使用される SPARQL クエリヒント SPARQL `DESCRIBE` クエリは、リソースの説明をリクエストするための柔軟なメカニズムを提供します。ただし、SPARQL 仕様では、`DESCRIBE` の正確なセマンティクスは定義されていません。 [エンジンリリース 1.2.0.2](engine-releases-1.2.0.2.md) 以降、Neptune はさまざまな状況に適したいくつかの異なる `DESCRIBE` モードとアルゴリズムをサポートしています。 このサンプルデータセットは、さまざまなモードを説明するのに役立ちます。 ``` @prefix rdf: . @prefix : . :JaneDoe :firstName "Jane" . :JaneDoe :knows :JohnDoe . :JohnDoe :firstName "John" . :JaneDoe :knows _:b1 . _:b1 :knows :RichardRoe . :RichardRoe :knows :JaneDoe . :RichardRoe :firstName "Richard" . _:s1 rdf:type rdf:Statement . _:s1 rdf:subject :JaneDoe . _:s1 rdf:predicate :knows . _:s1 rdf:object :JohnDoe . _:s1 :knowsFrom "Berlin" . :ref_s2 rdf:type rdf:Statement . :ref_s2 rdf:subject :JaneDoe . :ref_s2 rdf:predicate :knows . :ref_s2 rdf:object :JohnDoe . :ref_s2 :knowsSince 1988 . ``` 以下の例では、以下のような SPARQL クエリを使用してリソース `:JaneDoe` の説明が要求されていることを前提としています。 ``` DESCRIBE ``` ## `describeMode` SPARQL クエリヒント `hint:describeMode` SPARQL クエリヒントは、Neptune によってサポートされる次の SPARQL `DESCRIBE` モードのいずれかを選択するために使用されます。 ### `ForwardOneStep` DESCRIBE モード 次のような `describeMode` クエリヒントで `ForwardOneStep` モードを呼び出します。 ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "ForwardOneStep" } ``` `ForwardOneStep` モードは、記述されるリソースの属性と転送リンクのみを返します。この例では、これは、記述されるリソース `:JaneDoe` をサブジェクトとして持つトリプルを返すことを意味します。 ``` :JaneDoe :firstName "Jane" . :JaneDoe :knows :JohnDoe . :JaneDoe :knows _:b301990159 . ``` DESCRIBE クエリは、入力データセットと比較して、`_:b301990159` など、毎回異なる ID を持つ空白のノードのトリプルを返す場合があることに注意してください。 ### `SymmetricOneStep` DESCRIBE モード `SymmetricOneStep` は、クエリヒントを指定しなかった場合のデフォルトの DESCRIBE モードです。また、次のような `describeMode` クエリヒントを使って明示的に呼び出すこともできます。 ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "SymmetricOneStep" } ``` `SymmetricOneStep` セマンティクスでは、`DESCRIBE` は、記述されるリソースの属性、送信リンク、逆リンクを返します。 ``` :JaneDoe :firstName "Jane" . :JaneDoe :knows :JohnDoe . :JaneDoe :knows _:b318767375 . _:b318767631 rdf:subject :JaneDoe . :RichardRoe :knows :JaneDoe . :ref_s2 rdf:subject :JaneDoe . ``` ### Concise Bounded Description (`CBD`) DESCRIBE モード Concise Bounded Description (`CBD`) モードは、次のような `describeMode` クエリヒントを使用して呼び出されます。 ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "CBD" } ``` `CBD` セマンティクスでは、`DESCRIBE` は、記述されるリソースの Concise Bounded Description ([W3C によって定義](http://www.w3.org/Submission/CBD)) を返します。 ``` :JaneDoe :firstName "Jane" . :JaneDoe :knows :JohnDoe . :JaneDoe :knows _:b285212943 . _:b285212943 :knows :RichardRoe . _:b285213199 rdf:subject :JaneDoe . _:b285213199 rdf:type rdf:Statement . _:b285213199 rdf:predicate :knows . _:b285213199 rdf:object :JohnDoe . _:b285213199 :knowsFrom "Berlin" . :ref_s2 rdf:subject :JaneDoe . ``` RDF リソース (つまり RDF グラフ内のノード) の Concise Bounded Description は、そのノードを中心として独立できる最小のサブグラフです。実際には、このグラフを、指定されたノードをルートとするツリーと考えると、そのツリーの葉のような空白のノード (bnode) は存在しないということです。bnode は外部からアドレス指定することも、後続のクエリで使用することもできないため、現在のノードから次のシングルホップを見つけるには、グラフをブラウズするだけでは不十分です。また、後続のクエリで使用できるもの (つまり、bnode 以外のもの) を見つけるにも、十分に調査する必要があります。 #### CBD の計算 ソース RDF グラフ内の特定のノード (開始ノードまたはルート) が指定されると、そのノードの CBD は次のように計算されます。 1. ステートメントの*サブジェクト*が開始ノードであるソースグラフ内のすべてのステートメントをサブグラフに含めます。 1. 再帰的に、サブグラフ内のこれまでに空白のノード*オブジェクト*を持つすべてのステートメントについて、ソースグラフ内の、ステートメントの*サブジェクト*がその空白のノードであり、サブグラフにまだ含まれていないすべてのステートメントをサブグラフに含めます。 1. 再帰的に、それまでにサブグラフに含まれていたすべてのステートメントについて、ソースグラフ内のこれらのステートメントのすべての具象化について、各具象化の `rdf:Statement` ノードから始まる CBD を含めます。 その結果、*オブジェクト*ノードが IRI 参照またはリテラルのいずれかであるサブグラフ、または空白のノードがグラフ内のどのステートメントの*サブジェクト*にもなっていないサブグラフになります。CBD は、単一の SPARQL SELECT または CONSTRUCT クエリーでは計算できないことに注意してください。 ### Symmetric Concise Bounded Description (`SCBD`) DESCRIBE モード Symmetric Concise Bounded Description (`SCBD`) モードは、次のような `describeMode` クエリヒントを使用して呼び出されます。 ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "SCBD" } ``` `SCBD` セマンティクスでは、`DESCRIBE` は、リソースの Symmetric Concise Bounded Description (W3C によって「[リンクされたデータセットを VoID ボキャブラリで記述する](http://www.w3.org/TR/void/)」で定義) を返します 。 ``` :JaneDoe :firstName "Jane" . :JaneDoe :knows :JohnDoe . :JaneDoe :knows _:b335544591 . _:b335544591 :knows :RichardRoe . :RichardRoe :knows :JaneDoe . _:b335544847 rdf:subject :JaneDoe . _:b335544847 rdf:type rdf:Statement . _:b335544847 rdf:predicate :knows . _:b335544847 rdf:object :JohnDoe . _:b335544847 :knowsFrom "Berlin" . :ref_s2 rdf:subject :JaneDoe . ``` CBD と SCBD が `ForwardOneStep` および `SymmetricOneStep` モードより優れている点は、空白のノードが常にその表現を含むように拡張される点です。SPARQL を使用して空白のノードをクエリすることはできないため、これは重要な利点かもしれません。さらに、CBD モードと SCBD モードでは具象化も考慮されます。 `describeMode` クエリヒントは `WHERE` 句の一部にもなることに注意してください。 ``` PREFIX hint: DESCRIBE ?s WHERE { hint:Query hint:describeMode "CBD" . ?s rdf:type } ``` ## `describeIterationLimit` SPARQL クエリヒント `hint:describeIterationLimit` SPARQL クエリヒントは、CBD や SCBD などの反復的な DESCRIBE アルゴリズムで実行される反復拡張の最大回数に関する**オプション**制約となります。 DESCRIBE 制限は AND 処理されます。したがって、反復制限とステートメント制限の両方が指定された場合、DESCRIBE クエリを切断する前に両方の制限を満たす必要があります。 この値のデフォルトは 5 です。ゼロ (0) に設定すると、反復拡張の回数に制限がないように指定できます。 ## `describeStatementLimit` SPARQL クエリヒント `hint:describeStatementLimit` SPARQL クエリヒントは、DESCRIBE クエリレスポンスに含めることができるステートメントの最大数を**オプションで**制限できます。CBD や SCBD のような反復的な DESCRIBE アルゴリズムにのみ適用されます。 DESCRIBE 制限は AND 処理されます。したがって、反復制限とステートメント制限の両方が指定された場合、DESCRIBE クエリを切断する前に両方の制限を満たす必要があります。 この値のデフォルトは 5000 です。ゼロ (0) に設定すると、返されるステートメントの数に制限がないように指定できます。