SearchRetrieve en SRU

Posted on 10 octubre, 2013 por

0


SearchRetrieve en SRU

La operación Search-Retrieve en un SRU, es una operación principal, permite al cliente enviar una búsqueda y recuperar la solicitud de registros coincidentes desde el servidor.

¿Qué es SRU?

SRU es un estándar XML centrado en protocolo de búsqueda para las consultas de búsqueda de Internet, utilizando CQL (Contextual Query Language), una sintaxis estándar para la representación de las consultas.

Parámetros de consulta.

Es interesante desglosar una consulta para comprenderlo mejor. Si pretendemos recuperar 1 sola búsqueda con la palabra “Dinosaurio”

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaurioymaximunRecords=1 &recordSchema=dc

Partes:

  1. Posee el parámetro de la version = 1.1; en este parámetro se indica la versión de petición que el cliente desea de la pregunta
  2. El parámetro operación=searchRetrieve que sería la cadena para poder realizar la búsqueda en sí
  3. El parámetro query=dinosaurio, que sería la pregunta en sí misma; se expresa en un lenguaje CQL que veremos más adelante.
  4. maximunRecords=1 que es el número de registros que deben ser devueltos en este operación, en este caso solo se pide un registro.
  5. recordSchema=dc, esto es el esquema en el que los registros deben ser devueltos. El valor es el identificador URI para el esquema o nombre corto de lo publicado por el servidor.

Respuestas:

El procesamiento de una consulta da, como resultado, un conjunto de registros, representado por un conjunto de resultados que es, lógicamente, una lista ordenada de referencias a los registros. Una vez creado, este conjunto de resultados, no se puede modificar. Si se quiere realizar una operación sobre los resultados, lo que se hace es crear un nuevo conjunto de resultados diferentes del primero (aunque contenga los mismos registros modificados en el orden, por ejemplo).

Cada conjunto de resultados, se disingue, a través de una cadena de identificación única, generada por el servidor cuando se crea el conjunto de resultados. Así que se tendría en cuenta que, un registro puede ser eliminado  o no estar disponible, mientras que un resultado que hace referencia a ese registro aun podría existir.

Los registros del conjunto de resultados no están ordenados necesariamente, de acuerdo a ningún criterio específico, a menos que se haya creado bajo una petición en el lenguaje de consulta CQL, que contenga una especificación de clasificación como parte de la consulta.

Existe un parámetro importante, llamado RecordPacking, que nos devuelve la consulta en XML, esto es así porque puede resultarnos más cómodo tenerla en este formato a fin de manipular directamente la hoja de estilo que introduce los registros y/o la interfaz de usuario.

Lenguaje de consulta: CQL (contextual Query language: Lenguaje de preguntas contextuales)

Es un lenguaje formal, que sirve para representar las consultas en los sistemas de recuperación de información, como índices web, catálogos bibliográficos y de información  y/o colecciones de Museos.

CQL se llama así porque se funda en el concepto de búsqueda semántica o por el contexto, más que por la sintaxis. La misma búsqueda se puede realizar de forma diferente, pero lo importante es que los dos servidores comprenden la intención detrás de la consulta. CQL utiliza los conjuntos de contexto con el fin de garantizar la interoperabilidad entre dominios. Cada búsqueda CQL poseeré un identificador único: URI

Los lenguajes de consulta se han dividido tradicionalmente en 2 campos:

–         Potentes y expresivos: SQL; PQF y XQuery

–         Precisos e intuitivos pero no suficientemente poderosos para expresar conceptos más complejos: CCL y Google.

Lo que se intenta hacer con CQL es combinar la sencillez e inductividad de las expresiones de consultas con la riqueza de los idiomas más expresivos para dar cabida a conceptos complejos cuando sea necesario.

Sintaxis principal:

  1. Consulta CQL: consiste en una cláusula única de búsqueda, conectada por operadores booleanos o palabras clave. También pueden asignar algún identificador de conjunto de contexto.
  2. La clausula de búsqueda se compone de un índice, una relación y un término de búsqueda. Si solo posee un término de búsqueda o el índice la cláusula funcionará con la sintaxis: “cql.serverChoice” y la relación será tratada como un igual.
  3. Los términos de búsqueda se pueden encerrar con comillas dobles, sin nada o si tras estos caracteres <>=/() y un espacio en blanco debe ir entrecomillado

Los 4 aspectos más importantes del lenguaje de consulta CQL:

–         Índices

–         Relaciones

–         Modificaciones de la relación

–         Búsquedas booleanas

Estos 4 aspectos permiten la interoperabilidad. No existe, de todos modos, el requisito de que todos deben estar presentes, de hecho, se espera que la mayoría de los lenguajes CQL solo aparezca el índice.

El servidor debe ser compatible con uno de los tres niveles siguientes:

Nivel 0: procesar una consulta cada vez.

Nivel 1: soporte para nivel 0; analiza 2 cosas: las clausulas que consisten en ‘relación SearchTerm Indice’ y las consultas que combinan booleanos.

Nivel 2: soporte para el nivel 1; capacidad para analizar todos los CQL y responder con diagnósticos apropiados.En el nivel 2 no se requiere el apoyo de todos los CQL, se requiere que el servidor sea capaz de analizar todos los CQL

Operadores de la búsqueda CQL:

Operación Explique:

Permite a un cliente recuperar una descripción de las instalaciones disponibles en un servidor SRU. Hay 2 métodos:

–         Operación SRU Explain

–         Solicitud HTTP GET  a la URL base del servicio.

Operación Scan:

La operación de Scan permite al cliente solicitar un rango de los términos disponibles en un momento determinado dentro de una lista de términos indexados. Esto permite a los clientes presentar una lista ordenada de valores y, si es compatible, cuantos resultados habría para una búsqueda de ese término.

La operación Scan se utiliza, sobretodo, para seleccionar términos de búsqueda siguiente o para verificar un resultado de búsqueda negativo. La relación y la modificación de la relación puede ser utilizada para determinar, entre otros, el formato de los términos devueltos.

El término que se da en la cláusula, es para el cual queremos que se indique la posición de inicio, en la lista ordenada de los términos. Si se diera un término vacio, se entendería como el comienzo de la lista de términos.

Un ejemplo:

http://myserver.com/sru?operation=scan&version=1.2&scanClause=dc.Title=ranayresponsePosition=1&maximunTerms=25

Explicación del ejemplo:

Operation=scan es la operación que se pretende hacer, en el primer ejemplo era searchRetrive, porque lo que se pretendía era recuperar registros, no como ahora que se pretende su escaneado, para saber que lugar ocupa un término en el índice.

Versión=1.2 es la versión de petición

scanClause= dc.Title=rana se pretende  realizar el “escaneado”, es decir, buscar la palabra rana en el índice.

ResponsePosition=1 la posición dentro de la lista de términos. Si la posición dada es 0, entonces el término debe ser el inmediatamente antes del primer término en la respuesta. Si es 1 (nuestro caso) entonces el término debe ser el primero de la lista

MaximunTerms=25 es el numero de términos que se solicitan devueltos. En nuestro caso 25.

Diferencias entre CQL y XQuery

Tanto CQL como XQuery son dos tipos de lenguajes de consulta. El objetivo de CQL es combinar la simplicidad e intuitividad de google buscando con el poder expresivo de la consulta Z39.50, para que los usuarios puedan comenzar con consultas muy simples y se abren camino a las expresiones arbitrariamente complejas como sea necesario.

Por ejemplo, las siguientes búsquedas CQL son intuitivas y no necesitan explicación:

  • aves
  • aves o dinosaurios
  • dinosaurio reptil no
  • dinosaurio y ave o dinobird

Y los siguientes son razonablemente pero no completamente intuitivo:

  • aves prox dinosaurios – “encontrar aves cerca de los dinosaurios”
  • aves proxprox / = distancia = 1/unit dinosaurios frase – “…. Dentro de la misma oración”

El segundo conjunto de ejemplos reflejan una mayor funcionalidad que los de la primera serie y son más complejo, pero no de forma desproporcionada.

XQuery, por otro lado, es un lenguaje de especificación grande y complejo, que ha estado en desarrollo durante un largo tiempo (varios años) y consiste en un número de (12 o menos) de documentos grandes. Es difícil de comprender sin cometer varios días a la lectura de los documentos. CQL, por el contrario, puede ser entendida completamente en una hora o así.

El desarrollo de XQuery se ha visto influida, casi en su totalidad, por:

(1) XML-como-documento, refleja las raíces de XML como SGML

(2) como datos XML,  refleja un sesgo de base de datos relacionales.

Tanto XQuery y CQL asumen que la información se devuelve como XML. Pero XQuery va un paso más allá. Se supone que la información que se va a consultar es (o es representable como) XML; CQL no hace ninguna suposición.

XQuery podría ser muy útil y apropiado para la búsqueda, por ejemplo, el registro del Congreso, suponiendo que se expone en XML, donde el esquema específico de los datos es conocido. También sería útil para bases de datos relacionales. No sería útil para los datos bibliográficas, bases de datos basados ​​en registros, o para metasearching a través de diversas bases de datos, sino que CQL / SRU, será más apropiado.

Conformidad con el perfil SRU

Según las características mencionadas, se consideran especificaciones de implementación para garantizar la interoperabilidad entre los servidores y clientes SRU. Así, tanto los servidores como los clientes, deben soportar la operación Search-Retrieve así como, la forma para la presentación de los resultados.

Los perfiles SRU son documentos que especifican los requisitos que un servidor o cliente deben cumplir con el fin de reclamar el cumplimento de ese perfil. En las características del perfil, se consideran las especificaciones de aplicación, y si no se aplican, el cliente o el servidor será improbable que interoperen. Ya que no se entenderían.

No debe confundirse los perfiles con los conjuntos, ya sean en el contexto CQL o en la extensión para SRU. En los perfiles, no se establece nada nuevo, sólo una lista de una serie de requisitos. Muchos perfiles han asociado el contexto, los esquemas, los conjuntos de registros y  las extensiones, pero el propio perfil es sólo una lista de estas cosas. Cada perfil debe tener un identificador único, a fin de distinguirlo de otros perfiles. Estos identificadores deben figurar en el registro Explain.

Relación con el Z39.50

La Iniciativa SRU reconoce la importancia de Z39.50 en la comunicación empresarial. Mientras SRU se centra en conseguir la información al usuario, basándose en la semántica Z39.50, permite la creación de vías de acceso a los sistemas existentes basados en la norma Z39.50.

SRU combina varias características del Z39.50, en particular, los servicios de búsqueda y la operación Scan. Otras características adicionales o servicios se pueden añadir más tarde, o más tarde definirse como nuevos servicios web.

Algunas diferencias entre el SRU y el Z39.50

  • Conjunto de resultados llamado por el servidor: Z39.50 En contraste con el nombre que da el cliente al conjunto de resultados, En SRU es el servidor  quien asigna el identificador de conjunto de resultados.
  • Conexiones, Sesiones,  Estado: no existe el concepto explícito de la conexión, la sesión, o el estado.
  • No se distingue entre el servidor y la base de datos: SRU no distingue entre un servidor y una base de datos, y se espera que la eliminación del concepto de base de datos hará mejorar los resutlados significativamente, (ya que el concepto de múltiples bases de datos en Z39.50 ha causado una gran complejidad).
  • Registro único sintaxis:  En SRU todos los registros se recuperan según una sintaxis de registro único (XML) y por lo tanto el concepto (Z39.50) de la sintaxis de registro no es necesario. Los conceptos (Z39.50) del conjunto de elementos / especificación y el esquema se representan mediante esquemas XML, por ejemplo, Dublin Core, Onix, mods, y MARCXML.
  • Cadena de consulta: En SRU se especifica la cadena base de las consultas sobre el lenguaje de consulta, CQL.  En Z39.50, en contraste, no se define un lenguaje de consulta legible por humanos. La sintaxis CQL incluye el nombre del conjunto de resultados, y es compatible con la capacidad para calificar a un conjunto de resultados (por ejemplo, “los registros de conjunto de resultados ‘A’ donde el título es ‘B'”) y para especificar sólo un nombre de conjunto de resultados (por ejemplo, “los registros de conjunto de resultados ‘A’ “) similar a un presente Z39.50.
  • Índices planos: Éstos se definen, en lugar de utilizar vectores de atributos como en el  Z39.50.
  • Operación Explique:  la información no se basa en el concepto de Z39.50, Explique incluye puntos de acceso compatibles y esquemas de registro. La simplificación Explique también se debe en gran parte a las bases de datos de simplificación SRU

Y, todo esto, ¿qué tiene que ver con el OPENURL?

OpenURL vincula un usuario a un recurso apropiado. Lo hace, en parte, mediante la inclusión de información bibliográfica sobre el recurso. Por eso podrían llegar a confundirse

En un escenario típico OpenURL un usuario ( solicitante ) accede a un servidor ( referrer ) en el que hay un artículo (refiriéndose entidad ) que cita una referencia ( referente ).En la referencia parece que podría haber una relación normal en la que el usuario puede hacer clic, pero en realidad es un OpenURL – una URL HTTP, no una dirección URL de un recurso específico, pero en cambio, los metadatos sobre estas entidades contexto (solicitante, referente, refiriéndose entidad , referente). Y la url base (es decir, donde está siendo enviado la url) no es la ubicación del recurso deseado, sino que es lo que se conoce como un resolutor – un servidor diseñado para tener toda esta información y determinar qué recurso el usuario realmente quiere ( o es “más apropiado”).

Así SRU y OpenURL sirven a propósitos muy diferentes;

  1.  En SRU se selecciona registros en función de criterios de búsqueda, en OpenURL se  selecciona un único recurso, el que parezca “más apropiado”, de entre un número de recursos posibles, basándose en el contexto.
  2. OpenURL pretende ubicar un único recurso, mientras SRU encuentra todos los recursos que cumplen los criterios especificados
  3.  OpenURL generalmente devuelve texto completo del recurso. Con SRU, la solicitud se puede especificar el formato de los registros de respuesta, y la respuesta podría no incluir ningún registro, sino que indican un recuento de resultado.
  4. Así SRU es un protocolo de recuperación de información. OpenURL no lo es.
  5. Por otro lado, OpenURL, claramente, que trata sobre las funciones que SRU no contempla.
Anuncios
Posted in: Uncategorized