Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Sugerencias de consulta SPARQL Puede utilizar sugerencias de consulta para especificar estrategias de optimización y evaluación para una consulta SPARQL concreta en Amazon Neptune. Las sugerencias de consulta se expresan utilizando patrones triples adicionales que están insertados en la consulta SPARQL con las siguientes partes: ``` scope hint value ``` + *scope*: determina la parte de la consulta a la que se aplica la sugerencia de consulta, como un grupo determinado de la consulta o la consulta completa. + *hint*: identifica el tipo de sugerencia que se va a aplicar. + *value*: determina el comportamiento del aspecto del sistema considerado. Las sugerencias y los ámbitos de consulta se exponen como términos predefinidos en el espacio de nombres `http://aws.amazon.com/neptune/vocab/v01/QueryHints#` de Amazon Neptune. Los ejemplos de esta sección incluyen el espacio de nombres como un prefijo `hint` que se define y se incluye en la consulta: ``` PREFIX hint: ``` Por ejemplo, a continuación se muestra cómo incluir una sugerencia `joinOrder` en una consulta `SELECT`: ``` PREFIX hint: SELECT ... { hint:Query hint:joinOrder "Ordered" . ... } ``` La consulta anterior indica al motor de Neptune que evalúe las uniones en la consulta en el orden *indicado* y deshabilita cualquier reordenación automática. Tenga en cuenta lo siguiente al usar sugerencias de consulta: + Puede combinar diferentes sugerencias de consulta en una sola consulta. Por ejemplo, puede utilizar la sugerencia de consulta `bottomUp` para anotar una subconsulta para la evaluación ascendente y una sugerencia de consulta `joinOrder` para corregir el orden de unión dentro de la subconsulta. + Puede utilizar la misma sugerencia de consulta varias veces, en diferentes ámbitos no solapados. + Las sugerencias de consulta son sugerencias. Aunque el motor de consulta generalmente tiene como objetivo tener en cuenta determinadas sugerencias de consulta, también puede ignorarlas. + Las sugerencias de consulta mantienen la semántica. La adición de una sugerencia de consulta no modifica la salida de la consulta (excepto el orden potencial de los resultados cuando no se dan garantías de ordenación, es decir, cuando el orden de los resultados no se aplica explícitamente mediante el uso de ORDER BY). En las siguientes secciones se proporciona más información sobre las sugerencias de consulta disponibles y su uso en Neptune. **Topics** + [Ámbito de las sugerencias de consulta SPARQL en Neptune](#sparql-query-hints-scope) + [La sugerencia de consulta SPARQL `joinOrder`](sparql-query-hints-joinOrder.md) + [La sugerencia de consulta `evaluationStrategy` de SPARQL](sparql-query-hints-evaluationStrategy.md) + [La sugerencia de consulta `queryTimeout` de SPARQL](sparql-query-hints-queryTimeout.md) + [La sugerencia de consulta `rangeSafe` de SPARQL](sparql-query-hints-rangeSafe.md) + [La sugerencia de consulta SPARQL `queryId`](sparql-query-hints-queryId.md) + [La sugerencia de consulta `useDFE` de SPARQL](sparql-query-hints-useDFE.md) + [Sugerencias de consulta de SPARQL utilizadas con DESCRIBE](sparql-query-hints-for-describe.md) ## Ámbito de las sugerencias de consulta SPARQL en Neptune En la siguiente tabla, se muestran los ámbitos disponibles, las sugerencias asociadas y las descripciones para las sugerencias de consulta SPARQL en Amazon Neptune. El prefijo `hint` en estas entradas representa el espacio de nombres de Neptune para las sugerencias: ``` PREFIX hint: ``` | Alcance | Sugerencia admitida | Description (Descripción) | | --- | --- | --- | | hint:Query | [joinOrder](sparql-query-hints-joinOrder.md) | La sugerencia de consulta se aplica a toda la consulta. | | hint:Query | [queryTimeout](sparql-query-hints-queryTimeout.md) | El valor de expiración se aplica a toda la consulta | | hint:Query | [rangeSafe](sparql-query-hints-rangeSafe.md) | La promoción de tipos está deshabilitada para toda la consulta. | | hint:Query | [queryId](sparql-query-hints-queryId.md) | El valor del identificador de consulta se aplica a toda la consulta | | hint:Query | [useDFE](sparql-query-hints-useDFE.md) | El uso del DFE está habilitado (o deshabilitado) para toda la consulta. | | hint:Group | [joinOrder](sparql-query-hints-joinOrder.md) | La sugerencia de consulta se aplica a los elementos de nivel superior del grupo especificado, pero no a los elementos anidados (como las subconsultas) o a los elementos principales. | | hint:SubQuery | [evaluationStrategy](sparql-query-hints-evaluationStrategy.md) | La sugerencia se especifica y se aplica a una subconsulta SELECT anidada. La subconsulta se evalúa de forma independiente, sin tener en cuenta las soluciones calculadas antes de la subconsulta. | # La sugerencia de consulta SPARQL `joinOrder` Cuando envía una consulta SPARQL, el motor de consultas de Amazon Neptune investiga la estructura de la consulta. Reordena partes de la consulta y trata de minimizar la cantidad de trabajo necesario para la evaluación y el tiempo de respuesta de la consulta. Por ejemplo, una secuencia de patrones triples conectados normalmente no se evalúa en el orden dado. Se reordena mediante heurística y estadísticas como la selectividad de los patrones individuales y cómo están conectados a través de variables compartidas. Además, si la consulta contiene patrones más complejos, como subconsultas o bloques OPTIONAL o MINUS complejos FILTERs, el motor de consultas de Neptune los reordena siempre que sea posible, con el objetivo de lograr un orden de evaluación eficiente. Para consultas más complejas, el orden en el que Neptune decide evaluar la consulta puede no ser siempre el óptimo. Por ejemplo, Neptune podría perder las características específicas de datos de instancias (como el alcance de nodos Power en el gráfico) que surgen durante la evaluación de la consulta. Si conoce las características exactas de los datos y desea dictar manualmente el orden de ejecución de la consulta, utilice la sugerencia de consulta `joinOrder` de Neptune para especificar que la consulta se evalúe en el orden indicado. ## Sintaxis de sugerencias SPARQL de `joinOrder` La sugerencia de consulta `joinOrder` se especifica como un patrón triple incluido en una consulta SPARQL. Para una mayor claridad, los siguientes usos de sintaxis utilizan un prefijo `hint` que se define e incluye en la consulta para especificar el espacio de nombres de la sugerencia de consulta de Neptune: ``` PREFIX hint: scope hint:joinOrder "Ordered" . ``` **Ámbitos disponibles** + `hint:Query` + `hint:Group` Para obtener más información acerca de los ámbitos de sugerencia de consulta, vea [Ámbito de las sugerencias de consulta SPARQL en Neptune](sparql-query-hints.md#sparql-query-hints-scope). ## Ejemplo de sugerencia SPARQL `joinOrder` En esta sección se muestra una consulta escrita con la sugerencia de consulta `joinOrder` y sin, así como las optimizaciones relacionadas. En este ejemplo, suponga que el conjunto de datos contiene lo siguiente: + Una sola persona llamada `John` que indica que le gustan (`:likes`) 1000 personas, incluyendo a `Jane`. + Una sola persona llamada `Jane` que indica que le gustan (`:likes`) 10 personas, incluyendo a `John`. **Sin sugerencias de consulta** La siguiente consulta SPARQL extrae todos los pares de personas que se llaman `John` y `Jane`, y que se gustan entre sí de un conjunto de datos de redes sociales: ``` PREFIX : SELECT ?john ?jane { ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` El motor de consultas de Neptune puede evaluar las instrucciones en un orden diferente al escrito. Por ejemplo, puede elegir evaluar en el siguiente orden: 1. Buscar todas las personas llamadas `John`. 1. Buscar todas las personas conectadas a `John` por un borde `:likes`. 1. Filtrar este conjunto por personas llamadas `Jane`. 1. Filtrar este conjunto por las conectadas a `John` por un borde `:likes`. Según el conjunto de datos, la evaluación en este orden da como resultado la extracción de 1000 entidades en el segundo paso. El tercer paso lo limita hasta el nodo individual, `Jane`. El paso final determina que a `Jane` también le gusta (`:likes`) el nodo `John`. **Sugerencia de consulta** Sería favorable comenzar con el nodo `Jane` porque solo tiene 10 bordes `:likes` salientes. De este modo se reduce la cantidad de trabajo durante la evaluación de la consulta al evitar la extracción de las 1000 entidades durante el segundo paso. En el ejemplo siguiente, se utiliza la sugerencia de consulta **joinOrder** para asegurar que el nodo `Jane` y sus bordes de salida se procesen primero deshabilitando de todo reordenamiento automático de uniones para la consulta: ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:joinOrder "Ordered" . ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` Un escenario aplicable real podría ser una aplicación de red social en la que las personas de dicha red se clasifican como personas con influencia con muchas conexiones o como usuarios normales con pocas conexiones. En tal escenario, podría asegurarse de que el usuario normal (`Jane`) se procese antes que la persona influyente (`John`) en una consulta como la del ejemplo anterior. **Sugerencia de consulta y reordenación** Puede llevar este ejemplo un paso más allá. Si sabe que el atributo `:name` es único para un solo nodo, podría acelerar la consulta mediante la reordenación y el uso de la sugerencia de consulta `joinOrder`. Este paso garantiza que los nodos únicos se extraigan primero. ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:joinOrder "Ordered" . ?person1 :name "Jane" . ?person2 :name "John" . ?person1 :likes ?person2 . ?person2 :likes ?person1 . } ``` En este caso, puede reducir la consulta a las siguientes acciones individuales en cada paso: 1. Buscar la persona con `:name` `Jane`. 1. Buscar la persona con `:name` `John`. 1. Comprobar que el primer nodo está conectado al segundo con un borde `:likes`. 1. Comprobar que el segundo nodo está conectado al primero con un borde `:likes`. **importante** Si elige un orden incorrecto, la sugerencia de consulta `joinOrder` puede provocar un descenso considerable del rendimiento. Por ejemplo, el ejemplo anterior no sería eficiente si los atributos `:name` no fueran únicos. Si los 100 nodos se llamaran `Jane` y los 1000 nodos se llamaran `John`, la consulta terminaría verificando 1000 \$1 100 (100.000) pares para los bordes `:likes`. # La sugerencia de consulta `evaluationStrategy` de SPARQL La sugerencia de consulta `evaluationStrategy` indica al motor de consultas de Amazon Neptune que el fragmento de la consulta anotada debe evaluarse de abajo arriba como una unidad independiente. Esto significa que no se utiliza ninguna solución de los pasos de evaluación anteriores para calcular el fragmento de consulta. El fragmento de consulta se evalúa como una unidad independiente y las soluciones producidas se unen con el resto de la consulta una vez calculada. El uso de la sugerencia de consulta `evaluationStrategy` implica un plan de consulta de bloqueo (sin canalización), lo que significa que las soluciones del fragmento anotado con la sugerencia de consulta se materializan y se almacenan en búfer en la memoria principal. El uso de esta sugerencia de consulta puede aumentar considerablemente la cantidad de memoria principal necesaria para evaluar la consulta, especialmente si el fragmento de consulta anotado calcula un gran número de resultados. ## Sintaxis de sugerencias SPARQL de `evaluationStrategy` La sugerencia de consulta `evaluationStrategy` se especifica como un patrón triple incluido en una consulta SPARQL. Para una mayor claridad, los siguientes usos de sintaxis utilizan un prefijo `hint` que se define e incluye en la consulta para especificar el espacio de nombres de la sugerencia de consulta de Neptune: ``` PREFIX hint: hint:SubQuery hint:evaluationStrategy "BottomUp" . ``` **Ámbitos disponibles** + `hint:SubQuery` **nota** Esta sugerencia de consulta solo es compatible con las subconsultas anidadas. Para obtener más información acerca de los ámbitos de sugerencia de consulta, vea [Ámbito de las sugerencias de consulta SPARQL en Neptune](sparql-query-hints.md#sparql-query-hints-scope). ## Ejemplo de sugerencia SPARQL `evaluationStrategy` En esta sección se muestra una consulta escrita con la sugerencia de consulta `evaluationStrategy` y sin, así como las optimizaciones relacionadas. En este ejemplo, suponga que el conjunto de datos tiene las siguientes características: + Contiene 1000 bordes etiquetados `:connectedTo`. + Cada nodo `component` está conectado a una media de otros 100 nodos `component`. + El número típico de conexiones cíclicas de cuatro saltos entre nodos es de unos 100. Como ejemplo típico, la sugerencia `evaluationStrategy` puede ser útil para optimizar los patrones de consulta que contienen ciclos. **Sin sugerencias de consulta** La siguiente consulta SPARQL extrae todos los nodos `component` que están cíclicamente conectados entre sí a través de cuatro saltos: ``` PREFIX : PREFIX hint: SELECT * { ?component1 :connectedTo ?component2 . ?component2 :connectedTo ?component3 . ?component3 :connectedTo ?component4 . ?component4 :connectedTo ?component1 . } ``` El enfoque del motor de consultas de Neptune es evaluar esta consulta utilizando los siguientes pasos: + Extraer los 1000 bordes `connectedTo` del gráfico. + Expandir 100 veces (el número de bordes `connectedTo` de salida desde component2). Resultados intermedios: 100.000 nodos. + Expandir 100 veces (el número de bordes `connectedTo` de salida desde component3). Resultados intermedios: 10.000.000 nodos. + Escanear los 10.000.000 de nodos para el cierre del ciclo. Esto da como resultado un plan de consulta de streaming, que tiene una cantidad constante de memoria principal. **Sugerencia de consulta y subconsultas** Es posible que desee intercambiar el espacio de memoria principal para acelerar el cálculo. Al reescribir la consulta mediante una sugerencia de consulta `evaluationStrategy`, puede forzar al motor a calcular una unión entre dos subconjuntos más pequeños y materializados. ``` 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 . } } } ``` En lugar de evaluar los patrones triples en secuencia mientras se usan iterativamente los resultados del patrón triple anterior como entrada para los patrones siguientes, la sugerencia `evaluationStrategy` provoca que las dos subconsultas se evalúen de forma independiente. Ambas subconsultas producen 100.000 nodos para los resultados intermedios, que después se unen para formar la salida final. En concreto, cuando ejecuta Neptune en los tipos de instancia más grandes, el almacenamiento temporal de estos dos subconjuntos de 100 000 en la memoria principal aumenta el uso de memoria a cambio de acelerar considerablemente la evaluación. # La sugerencia de consulta `queryTimeout` de SPARQL La sugerencia de consulta `queryTimeout` especifica un tiempo de espera que es menor que el conjunto de valores de`neptune_query_timeout` en el grupo de parámetros de base de datos. Si la consulta termina como resultado de esta sugerencia, se genera una `TimeLimitExceededException`, con un mensaje `Operation terminated (deadline exceeded)`. ## Sintaxis de sugerencias SPARQL de `queryTimeout` ``` PREFIX hint: SELECT ... WHERE { hint:Query hint:queryTimeout 10 . # OR hint:Query hint:queryTimeout "10" . # OR hint:Query hint:queryTimeout "10"^^xsd:integer . ... } ``` El valor del tiempo de espera se expresa en milisegundos. El valor del tiempo de espera debe ser menor que el valor de `neptune_query_timeout` establecido en el grupo de parámetros de la base de datos. De lo contrario, se generará una excepción `MalformedQueryException` con un mensaje `Malformed query: Query hint 'queryTimeout' must be less than neptune_query_timeout DB Parameter Group`. Se debe especificar la sugerencia de consulta `queryTimeout` en la cláusula `WHERE` de la consulta principal o en la cláusula `WHERE` de uno de las subconsultas tal como se en el ejemplo a continuación: Debe configurarse una sola vez en todas las secciones de actualizaciones queries/subqueries y en las de SPARQL (como INSERT y DELETE). De lo contrario, se generará una excepción `MalformedQueryException` con un mensaje `Malformed query: Query hint 'queryTimeout' must be set only once`. **Ámbitos disponibles** La sugerencia `queryTimeout` se puede aplicar tanto a las consultas SPARQL como a las actualizaciones. + En una consulta SPARQL, puede aparecer en la cláusula WHERE de la consulta principal o en una subconsulta. + En una actualización de SPARQL, se puede establecer en la cláusula INSERT, DELETE o WHERE. Si hay varias cláusulas de actualización, solo se puede establecer en una de ellas. Para obtener más información acerca de los ámbitos de sugerencia de consulta, vea [Ámbito de las sugerencias de consulta SPARQL en Neptune](sparql-query-hints.md#sparql-query-hints-scope). ## Ejemplo de sugerencia SPARQL `queryTimeout` A continuación se muestra un ejemplo de uso de `hint:queryTimeout` en la cláusula principal `WHERE` de una consulta `UPDATE`: ``` PREFIX hint: INSERT { ?s ?p ?o } WHERE { hint:Query hint:queryTimeout 100 . ?s ?p ?o . } ``` Aquí, la `hint:queryTimeout` se encuentra en la cláusula `WHERE` de una subconsulta: ``` PREFIX hint: SELECT * { ?s ?p ?o . { SELECT ?s WHERE { hint:Query hint:queryTimeout 100 . ?s ?p1 ?o1 . } } } ``` # La sugerencia de consulta `rangeSafe` de SPARQL Utilice esta sugerencia de consulta para desactivar la promoción de tipos en una consulta de SPARQL. Cuando envía una consulta SPARQL que incluye un `FILTER` en un valor o rango numérico, normalmente el motor de consultas de Neptune debe usar la promoción de tipos cuando ejecuta la consulta. Esto significa que tiene que examinar los valores de todos los tipos que puedan contener el valor por el que se está filtrando. Por ejemplo, si está filtrando valores iguales a 55, el motor debe buscar números enteros iguales a 55, enteros largos iguales a 55L, flotantes iguales a 55,0, etc. Cada promoción de tipo requiere una búsqueda adicional en el almacenamiento, lo que puede provocar que una consulta aparentemente simple tarde un tiempo inesperadamente largo en completarse. A menudo, la promoción de tipos no es necesaria porque ya sabe de antemano que solo necesita encontrar valores de un tipo específico. Cuando sea así, puede acelerar considerablemente sus consultas utilizando la sugerencia de consulta `rangeSafe` para desactivar la promoción de tipos. ## Sintaxis de sugerencias SPARQL de `rangeSafe` La sugerencia de consulta `rangeSafe` toma un valor de `true` para desactivar la promoción de tipos. También acepta un valor de `false` (el valor predeterminado). **Ejemplo.** El siguiente ejemplo muestra cómo desactivar la promoción de tipos al filtrar por un valor entero de `o` superior a 1: ``` PREFIX hint: SELECT * { ?s ?p ?o . hint:Prior hint:rangeSafe 'true' . FILTER (?o > '1'^^) ``` # La sugerencia de consulta SPARQL `queryId` Utilice esta sugerencia de consulta para asignar su propio valor de queryId a una consulta SPARQL. Ejemplo: ``` PREFIX hint: SELECT * WHERE { hint:Query hint:queryId "4d5c4fae-aa30-41cf-9e1f-91e6b7dd6f47" {?s ?p ?o}} ``` El valor que asigne debe ser único en todas las consultas de la base de datos de Neptune. # La sugerencia de consulta `useDFE` de SPARQL Utilice esta sugerencia de consulta para permitir el uso del DFE para ejecutar la consulta. De forma predeterminada, Neptune no usa el DFE sin que esta sugerencia de consulta esté establecida en `true`, ya que el parámetro de instancia [neptune\$1dfe\$1query\$1engine](parameters.md#parameters-instance-parameters-neptune_dfe_query_engine) tiene el valor predeterminado `viaQueryHint`. Si establece ese parámetro de instancia en `enabled`, el motor DFE se utiliza para todas las consultas excepto para las que la sugerencia de consulta `useDFE` está establecida en `false`. Ejemplo de cómo habilitar el uso del DFE para una consulta: ``` PREFIX : PREFIX hint: SELECT ?john ?jane { hint:Query hint:useDFE true . ?person1 :name "Jane" . ?person1 :likes ?person2 . ?person2 :name "John" . ?person2 :likes ?person1 . } ``` # Sugerencias de consulta de SPARQL utilizadas con DESCRIBE Una consulta `DESCRIBE` de SPARQL proporciona un mecanismo flexible para solicitar descripciones de recursos. Sin embargo, las especificaciones de SPARQL no definen la semántica precisa de `DESCRIBE`. A partir de la [versión 1.2.0.2 del motor](engine-releases-1.2.0.2.md), Neptune admite varios modos y algoritmos `DESCRIBE`diferentes que se adaptan a diferentes situaciones. Este conjunto de datos de muestra puede ayudar a ilustrar los diferentes modos: ``` @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 . ``` En los ejemplos siguientes, se supone que se solicita una descripción del recurso `:JaneDoe` mediante una consulta SPARQL como esta: ``` DESCRIBE ``` ## La sugerencia de consulta `describeMode` de SPARQL La sugerencia de consulta `hint:describeMode` de SPARQL se utiliza para seleccionar uno de los siguientes modos `DESCRIBE` de SPARQL compatibles con Neptune: ### El modo `ForwardOneStep` de DESCRIBE El modo `ForwardOneStep` se invoca con la sugerencia de consulta `describeMode` de la siguiente manera: ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "ForwardOneStep" } ``` El modo `ForwardOneStep` solo devuelve los atributos y los enlaces de reenvío del recurso que se va a describir. En el caso de ejemplo, esto significa que devuelve los triples que tienen `:JaneDoe`, que es el recurso que se va a describir, como asunto: ``` :JaneDoe :firstName "Jane" . :JaneDoe :knows :JohnDoe . :JaneDoe :knows _:b301990159 . ``` Tenga en cuenta que la consulta DESCRIBE puede devolver triples con nodos en blanco, por ejemplo`_:b301990159`, que son diferentes IDs cada vez en comparación con el conjunto de datos de entrada. ### El modo `SymmetricOneStep` de DESCRIBE `SymmetricOneStep` es el modo de DESCRIBE predeterminado si no proporciona una sugerencia de consulta. También puede invocarlo de forma explícita con la sugerencia de consulta `describeMode` de la siguiente manera: ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "SymmetricOneStep" } ``` En la semántica `SymmetricOneStep`, `DESCRIBE` devuelve los atributos, los enlaces directos y los enlaces inversos del recurso que se va a describir: ``` :JaneDoe :firstName "Jane" . :JaneDoe :knows :JohnDoe . :JaneDoe :knows _:b318767375 . _:b318767631 rdf:subject :JaneDoe . :RichardRoe :knows :JaneDoe . :ref_s2 rdf:subject :JaneDoe . ``` ### El modo de DESCRIBE de descripción limitada concisa (`CBD`) El modo de descripción limitada concisa (`CBD`) se invoca con la sugerencia de consulta `describeMode` de la siguiente manera: ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "CBD" } ``` En la semántica `CBD`, `DESCRIBE` devuelve la descripción limitada concisa ([tal como la define el W3C](http://www.w3.org/Submission/CBD)) del recurso que se va a describir: ``` :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 . ``` La descripción limitada concisa de un recurso de RDF (es decir, un nodo de un gráfico RDF) es el subgráfico más pequeño centrado alrededor de ese nodo que puede ser independiente. En la práctica, esto significa que si piensa en este gráfico como un árbol, con el nodo designado como raíz, no hay nodos en blanco (nodos b) como hojas de ese árbol. Como los nodos b no se pueden direccionar externamente ni se pueden usar en consultas posteriores, no basta con navegar por el gráfico para encontrar los siguientes saltos individuales desde el nodo actual. También hay que ir lo suficientemente lejos como para encontrar algo que pueda usarse en consultas posteriores (es decir, algo que no sea un nodo b). #### Cálculo del CBD Dado un nodo en particular (el nodo de inicio o raíz) en el gráfico RDF de origen, el CBD de ese nodo se calcula de la siguiente manera: 1. Incluya en el subgráfico todas las instrucciones del gráfico de origen en las que el *sujeto* de la instrucción sea el nodo inicial. 1. De forma recursiva, para todas las instrucciones del subgráfico que hasta ahora tengan un *objeto* de nodo en blanco, incluya en el subgráfico todas las instrucciones del gráfico de origen cuyo *sujeto* sea ese nodo en blanco y que aún no estén incluidas en el subgráfico. 1. De forma recursiva, para todas las instrucciones incluidas en el subgráfico hasta ahora, para todas las reificaciones de estas instrucciones en el gráfico de origen, incluya el CBD comenzando por el nodo `rdf:Statement` de cada reificación. Esto da como resultado un subgráfico en el que los nodos *objeto* son referencias o literales del IRI, o nodos en blanco que no sirven de *sujeto* a ninguna instrucción del gráfico. Tenga en cuenta que el CBD no se puede calcular con una sola consulta SELECT o CONSTRUCT de SPARQL. ### El modo DESCRIBE de descripción limitada concisa simétrica (`SCBD`) El modo de descripción limitada concisa simétrica (`SCBD`) se invoca con la sugerencia de consulta `describeMode` de la siguiente manera: ``` PREFIX hint: DESCRIBE { hint:Query hint:describeMode "SCBD" } ``` En la semántica de `SCBD`, `DESCRIBE` devuelve la descripción limitada concisa simétrica del recurso (tal como la define el W3C en [Describing Linked Datasets with the VoID Vocabulary](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 . ``` La ventaja de CBD y SCBD con respecto a los modos `ForwardOneStep` y `SymmetricOneStep` es que los nodos vacíos siempre se expanden para incluir su representación. Esto puede ser una ventaja importante, ya que no se puede consultar un nodo en blanco con SPARQL. Además, los modos CBD y SCBD también consideran las reificaciones. Tenga en cuenta que la sugerencia de consulta `describeMode` también puede formar parte de una cláusula `WHERE`: ``` PREFIX hint: DESCRIBE ?s WHERE { hint:Query hint:describeMode "CBD" . ?s rdf:type } ``` ## La sugerencia de consulta `describeIterationLimit` de SPARQL La sugerencia de consulta de SPARQL `hint:describeIterationLimit` proporciona una restricción **opcional** con respecto al número máximo de expansiones iterativas que se deben realizar para los algoritmos DESCRIBE iterativos, como CBD y SCBD. Los límites de DESCRIBE están ANDed juntos. Por lo tanto, si se especifican tanto el límite de iteración como el límite de las instrucciones, ambos límites deben cumplirse antes de que se interrumpa la consulta DESCRIBE. El valor predeterminado de este valor es 5. Puede establecerlo en CERO (0) para no especificar ningún límite en el número de expansiones iterativas. ## La sugerencia de consulta `describeStatementLimit` de SPARQL La sugerencia de consulta `hint:describeStatementLimit` de SPARQL proporciona una restricción **opcional** con respecto al número máximo de instrucciones que pueden estar presentes en una respuesta a una consulta DESCRIBE. Solo se aplica a los algoritmos DESCRIBE iterativos, como CBD y SCBD. Los límites de DESCRIBE están ANDed juntos. Por lo tanto, si se especifican tanto el límite de iteración como el límite de las instrucciones, ambos límites deben cumplirse antes de que se interrumpa la consulta DESCRIBE. El valor predeterminado de este valor es 5000. Puede establecerlo en CERO (0) para no especificar ningún límite en el número de instrucciones devueltas.