La búsqueda federada recupera información de una variedad de fuentes a través de una aplicación de búsqueda integrada en uno o más motores de búsqueda. [1] Un usuario realiza una única solicitud de consulta que se distribuye a los motores de búsqueda , bases de datos u otros motores de consulta que participan en la federación. Luego, la búsqueda federada agrega los resultados que se reciben de los motores de búsqueda para presentarlos al usuario. La búsqueda federada se puede utilizar para integrar recursos de información dispares dentro de una única gran organización ("empresa") o para toda la web.
La búsqueda federada, a diferencia de la búsqueda distribuida, requiere una coordinación centralizada de los recursos de búsqueda. Esto implica tanto la coordinación de las consultas transmitidas a los distintos motores de búsqueda como la fusión de los resultados de búsqueda devueltos por cada uno de ellos.
La búsqueda federada surgió para satisfacer la necesidad de buscar múltiples fuentes de contenido dispares con una sola consulta. Esto permite al usuario buscar en varias bases de datos a la vez en tiempo real, organizar los resultados de las distintas bases de datos en una forma útil y luego presentar los resultados al usuario.
Como tal, es un enfoque de agregación o integración de información: proporciona un punto de acceso único a muchos recursos de información y, por lo general, devuelve los datos en una forma estándar o parcialmente homogeneizada. Otros enfoques incluyen la construcción de un almacén de datos empresarial , un lago de datos o un centro de datos . La búsqueda federada realiza consultas muchas veces y de muchas maneras (cada fuente se consulta por separado), mientras que otros enfoques importan y transforman datos muchas veces, normalmente en procesos por lotes nocturnos. La búsqueda federada proporciona una vista en tiempo real de todas las fuentes (en la medida en que todas estén en línea y disponibles).
En los motores de búsqueda industriales, como LinkedIn , la búsqueda federada se utiliza para personalizar las preferencias verticales para consultas ambiguas. [2] Por ejemplo, cuando un usuario realiza una consulta como "aprendizaje automático" en LinkedIn, podría querer buscar personas con habilidades de aprendizaje automático, trabajos que requieran habilidades de aprendizaje automático o contenido sobre el tema. En tales casos, la búsqueda federada podría explotar la intención del usuario (por ejemplo, contratación, búsqueda de empleo o consumo de contenido) para personalizar el orden vertical de cada usuario individual.
Como lo describe Peter Jacso (2004 [3] ), la búsqueda federada consiste en (1) transformar una consulta y transmitirla a un grupo de bases de datos dispares u otros recursos web, con la sintaxis adecuada, (2) fusionar los resultados recopilados de la bases de datos, (3) presentarlas en un formato conciso y unificado con una duplicación mínima, y (4) proporcionar un medio, realizado automáticamente o por el usuario del portal, para ordenar el conjunto de resultados fusionados.
Los portales de búsqueda federados, ya sean comerciales o de acceso abierto , generalmente buscan bases de datos bibliográficas de acceso público , catálogos de bibliotecas basados en Web ( OPAC ) de acceso público, motores de búsqueda basados en Web como Google y/o colecciones de datos de acceso abierto, operadas por gobiernos o corporativas. Estas fuentes de información individuales envían a la interfaz del portal una lista de resultados de la consulta de búsqueda. El usuario puede revisar esta lista de resultados. Algunos portales simplemente seleccionarán los resultados reales de la base de datos y no permitirán directamente que un usuario ingrese a la aplicación de la fuente de información. Los más sofisticados eliminarán la duplicación de la lista de resultados fusionando y eliminando duplicados. Hay funciones adicionales disponibles en muchos portales, pero la idea básica es la misma: mejorar la precisión y relevancia de las búsquedas individuales, así como reducir la cantidad de tiempo necesario para buscar recursos.
Este proceso permite a la búsqueda federada algunas ventajas clave en comparación con los motores de búsqueda existentes basados en rastreadores. La búsqueda federada no necesita imponer ningún requisito o carga a los propietarios de las fuentes de información individuales, aparte de manejar un mayor tráfico. Las búsquedas federadas son inherentemente tan actuales como las fuentes de información individuales, ya que se buscan en tiempo real.
Una aplicación de la búsqueda federada es el motor de metabúsqueda . Sin embargo, el enfoque de metabúsqueda no supera las deficiencias de los motores de búsqueda que lo componen, como los índices incompletos. Los documentos que no son indexados por los motores de búsqueda crean lo que se conoce como la Web profunda o Web invisible. Google Scholar es un ejemplo de muchos proyectos que intentan abordar este problema indexando documentos electrónicos que los motores de búsqueda ignoran. Y el enfoque de metabúsqueda, al igual que la tecnología subyacente de los motores de búsqueda, sólo funciona con fuentes de información almacenadas en formato electrónico.
Uno de los principales desafíos de la metabúsqueda es garantizar que la consulta de búsqueda sea compatible con los motores de búsqueda componentes que se están federando y combinando. Cuando el vocabulario de búsqueda o el modelo de datos del sistema de búsqueda es diferente del modelo de datos de uno o más de los sistemas de destino externos, la consulta debe traducirse a cada uno de los sistemas de destino externos. Esto se puede hacer mediante una traducción simple de elementos de datos o puede requerir una traducción semántica . Por ejemplo, si un motor de búsqueda permite citar cadenas exactas o n-gramas y otro no, la consulta debe traducirse para que sea compatible con cada motor de búsqueda. Para traducir una consulta de cadena exacta entre comillas, se puede dividir en un conjunto de N-gramas superpuestos que tienen más probabilidades de brindar los resultados de búsqueda deseados en cada motor de búsqueda.
Otro desafío al que se enfrenta la implementación de motores de búsqueda federados es la escalabilidad. Es difícil mantener el rendimiento y la velocidad de respuesta de un motor de búsqueda federado, ya que combina cada vez más fuentes de información. Una implementación de búsqueda federada que ha comenzado a abordar este problema es WorldWideScience , alojada en la Oficina de Información Científica y Técnica del Departamento de Energía de EE.UU. WorldWideScience [4] está compuesto por más de 40 fuentes de información, varias de las cuales son portales de búsqueda federados. Uno de esos portales es Science.gov [5] , que a su vez reúne más de 30 fuentes de información que representan la mayor parte de la producción de I+D del gobierno federal de Estados Unidos. Science.gov devuelve sus resultados mejor clasificados a WorldWideScience, que luego fusiona y clasifica estos resultados con la búsqueda devuelta por las otras fuentes de información que componen WorldWideScience. [5] Este enfoque de búsqueda federada en cascada permite buscar en un gran número de fuentes de información mediante una única consulta.
Otra aplicación, Sesam, que se ejecuta tanto en Noruega como en Suecia, se ha creado sobre una plataforma de código abierto especializada en soluciones de búsqueda federadas. Sesat, [6] acrónimo de Sesam Search Application Toolkit , es una plataforma que proporciona gran parte del marco y la funcionalidad necesarios para manejar búsquedas paralelas y canalizadas y mostrarlas elegantemente en una interfaz de usuario, lo que permite a los ingenieros centrarse en la configuración del índice/base de datos. Afinación.
Para personalizar los pedidos verticales en la búsqueda federada, el motor de búsqueda LinkedIn [2] explota el perfil del buscador y sus actividades recientes para inferir su intención, como contratación, búsqueda de empleo y consumo de contenido, y luego utiliza la intención, junto con muchas otras señales, para Clasifique los pedidos verticales que sean personalmente relevantes para el buscador individual.
SWIRL Search [7] es un motor de búsqueda federado de código abierto, publicado bajo la licencia Apache 2.0. Incluye conectores prediseñados para motores de búsqueda populares de código abierto y reordena los resultados utilizando la similitud de vectores coseno.
Las búsquedas federadas presentan una serie de desafíos importantes, en comparación con las búsquedas convencionales de fuente única:
1. Transmisión de credenciales
Cuando se realiza una búsqueda federada en fuentes de datos seguras, las credenciales de los usuarios deben transmitirse a cada motor de búsqueda subyacente, para que se mantenga la seguridad adecuada. Si el usuario tiene diferentes credenciales de inicio de sesión para diferentes sistemas, debe haber un medio para asignar su ID de inicio de sesión al dominio de seguridad de cada motor de búsqueda. [8]
2. Los resultados del mapeo enumeran los navegadores en una forma común
Supongamos que se buscan tres sitios inmobiliarios y cada uno proporciona una lista de nombres de ciudades con hipervínculos en los que hacer clic para ver coincidencias solo en cada ciudad. Lo ideal sería combinar estas facetas en un solo conjunto, pero eso presenta desafíos técnicos adicionales. [9] El sistema también necesita comprender los enlaces de "página siguiente" si va a permitir al usuario navegar por los resultados combinados.
Parte de este desafío de mapear a una forma común se puede resolver si los recursos federados admiten datos abiertos vinculados a través de RDF . Se pueden agregar ontologías (reglas) para asignar resultados a formas comunes utilizando esa tecnología.
3. Clasificación y puntuación de resultados.
Cada recurso web tiene su propia noción de puntuación de relevancia y puede admitir algunos resultados ordenados. La relevancia varía mucho entre los "federados" en la búsqueda, por lo que saber intercalar resultados para mostrar los más relevantes es difícil o imposible.
4. Consulta sólida
Es posible que la búsqueda federada deba limitarse al conjunto mínimo de capacidades de consulta que son comunes a todos los federados. Por ejemplo, si Google admite negaciones y frases entre comillas, pero science.gov no, será imposible que la búsqueda federada admita frases negadas y entre comillas.
5. Disponibilidad y tiempo de espera
A medida que crece el número de federados (fuentes federadas), la probabilidad de que uno o más federados sean lentos o fuera de línea se vuelve alta. La búsqueda federada debe decidir cuándo considerar una federación fuera de línea o esperar una respuesta lenta. Los tiempos de respuesta los dictará el federado más lento del grupo.
6. Desarrollo y pruebas dentro de una empresa (frente a la Internet pública)
Por lo general, los grupos de desarrollo no deberían acceder a los sistemas de producción en vivo, ya que realizan un trabajo regular, y mucho menos pruebas de carga intensivas. Además, algunos recursos son seguros y no deben consultarse ni exponerse arbitrariamente durante el desarrollo debido a preocupaciones de privacidad y seguridad. Por lo tanto, los entornos de desarrollo, pruebas y pruebas de rendimiento deben incluir la instalación y configuración de muchos subsistemas para permitir pruebas seguras.
7. HA/DR ( alta disponibilidad y recuperación ante desastres )
Para que el sistema federado general sea HA/DR, cada subsistema debe ser HA/DR.
De manera similar, el modelado del desempeño y la planificación de la capacidad para el sistema federado requiere modelado, planificación y, a veces, expansión de todos los federados.
Por todas las razones anteriores, dentro de una empresa, puede ser preferible un centro de datos o un lago de datos , o un enfoque híbrido. Los centros y lagos de datos simplifican el desarrollo y el acceso, pero pueden generar algún retraso antes de que los datos estén disponibles (sin una lógica de sincronización especial). En la web, la federación es más típica.