TextBPV 5432 ======= * Los TextBPV constituyen una "representación" de un nodo en forma de texto. Se utilizan en diversas partes del sistema para presentar información al usuario. * Los TextBPV se generan por medio de una TextBPVFunction que tiene como datos de entrada un nodo y un idioma. * Los TextBPV resultantes incluyen no sólo el valor de texto propiamente dicho, sino también el idioma de ese texto. * Resumen de lo anterior: Tipo de información Cómo recuperarla ------------------- ---------------- Entrada: nodo (DOorVal) textBPV.onDoOrVal() Entrada: idioma de ejecución (Lang) textBPV.funcExecutionLang() Función (TextBPVFunction) textBPV.generatedWith() Salida: valor de texto (String) textBPV.val() Salida: idioma del texto (Lang) textBPV.valueLang() (En esta tabla, "textBPV" se refiere a una instancia de la clase TextBPV.) * En cualquier RuleSet se pueden definir varias TextBPVFunction, cuyo propósito es generar los TextBPV para los nodos vinculados con ese RuleSet. * A menudo en los RuleSet se define una TextBPVFunction de default, cuyos resultados se usa en diferentes lugares del sistema como la forma "por omisión" de representar, en texto, los nodos vinculados con ese RuleSet. * En los RuleSet donde no se ha definido una TextBPVFunction de default, el sistema genera una automáticamente. Esto permite asegurar que para _todos_ los DOorVal (objetos descriptibles o valores) puede obtenerse un TextBPV default que represente a ese DOorVal en forma de texto. * Para los literales en la mayoría de los casos el TextBPV de default será igual al valor del mismo literal. * A menudo, al interior de una TextBPVFunction, se construye el resultado con base en el TextBPV de otro(s) nodo(s)--es decir, los TextBPV se generan "en cadena". Por ejemplo, la función siguiente--aplicable a los nodos que representan a personas--se busca el TextBPV de los nodos literales que contienen los apellidos y nombres, los cuales se ensamblan para generar un nuevo TextBPV. |{ given = (@root->has_given_names).text_bpv last = (@root->has_last_names).text_bpv "#{last}, #{given}" }| * El hecho de que los TextBPV se ejecuten "en cadena", unos utilizando a otros, significa que existe cierto nivel de repetición de la información. * Los idiomas de ejecución de las TextBPVFunction varian: algunas funciones solamente se ejecutan con el idioma NONE, mientras que otras se ejecutan una vez por cada idioma vedadero disponible. * Los TextBPV no se generan en el momento en que se necesiten, sino que se crean de manera anticipada y se guardan en un cache (esto se maneja en la clase estática TextBPVManager. Búsquedas ========= * Respecto a los resultados de búsqueda tenemos los siguientes objetivos: 1) Presentar los resultados de manera accesible; 2) Presentar resultados que sean de interés para el usuario final; y 3) Permitir la agrupación de los resultados de una manera que resalte las similitudes y relaciones que pueden existir entre ellos. Para lograr esto es necesario imaginar en concreto cómo se presentarán los resultados, para luego diseñar los algoritmos que permitirán generarlos y desplegarlos de esa manera. Por ejemplo, si se hiciera una búsqueda con la palabra "horizontal", podemos imaginar unos resultados así: Orientación _horizontal_: 3 fotografías CMICH01 ... CMICH05 ... CMICH07 ... _horizontal_ aparece en el campo Observaciones: 2 fotografías CMICH03 ... CMICH08 ... * Se prevé que el algoritmo de búsqueda en texto libre funcione a grandes rasgos de la manera siguiente: - Se busca el texto solicitado en los TextBPV almacenados en cache. (Esto sucede en la clase TextBPVManager.) - De los TextBPV resultantes se recuperan los nodos sobre los cuales se ejecutaron las TextBPVFunction--es decir, los nodos que son representados por los TextBPV. (Este y los siguientes pasos se realizan en la clase Search.) - De esos nodos se recuperan los objetos descriptibles relacionados. * Recuerda que todos los nodos tienen sólo un objeto descriptible relacionado: para los objetos descriptibles mismos, el objeto descriptible relacionado es el mismo nodo, y para los valores, es el objeto descriptible "más cercano" atravesando los triples en sentido inverso, es decir, de los objetos hacia los sujetos.) - Se agrupan los nodos por objeto descriptible relacionado. * Esto se hace porque el algoritmo que genera los resultados de búsqueda recorrerá la gráfica sólo de objetos descriptibles a otros objetos descriptibles. - Para cada objeto descriptible relacionado, se eliminan los resultados que pueden considerarse "repetidos". - Para los resultados que no se han eliminado se guarda información acerca del camino que existe entre el nodo que representa el TextBPV encontrado y el objeto descriptible relacionado. * Esta información servirá más adelante para proporcionar al usuario información acerca de dónde se encontraron las palabras que buscó. Podrá almacenarse en las instancias de una clase encrustada de Search. - De los objetos descriptibles relacionados que no se encuentren en una SOC de nivel principal, se busca un camino en la gráfica que lleve a otro objeto descriptible que sí esté en una SOC de nivel principal. * Al presentar los resultados al usuario también se deberá presentar una descripción textual amigable de este camino. - Generar los grupos y ubicar cada resultado en un grupo para GroupedDescList * El algoritmo anterior corresponde (parcialmente) al primer paso del algoritmo mencionado en el documento Lógica de RC (http://200.67.231.185/mediawiki/index.php/Pescador:L%C3%B3gica_de_RC#Generaci.C3.B3n_de_conjuntos). (Los demás de ese algoritmo resultan más sencillas, repetidas en otras operaciones del sistema, o se omitirán.) De miembros de una SOC secundaria a aquéllos de una SOC de nivel principal (Backtrace) ====================================================================================== * Se establecen, cuando se inicia el sistema, las reglas de relaciones de RC _múltiples_ que _podrían_ conducir de los miembros de una SOC secundaria a aquéllos de una SOC de nivel principal. * Inicialmente haremos que estas reglas sólo puedan contener otras reglas de relaciones de RC _simples_. * Impondremos un límite en el número de pasos podrán contener estas reglas múltiples (4 ó 5) * El sistema automáticamente generará estas reglas tomando en cuenta los descriptores de lso RuleSet, los rangos de las propiedades, la vinculación de los RuleSet con las SOC, y el groupDomain de las SOC * El sistema atravesará estas reglas especiales para llevar a cabo el penúltimo paso de la búsqueda que se describe arriba Apuntes para implementar TokenSources ===================================== * Antes de refactorar mucho, hacer una prueba sacando cosas a la bitácora desde TextBPVManager * Si eso funciona, diseñar cómo hacer que TextBPVManaager.searchLucene devuelva no sólo los TextBPV sino también la información necesaria para crear las cadenas subrayadas en su momento. * Muy posiblemente convenga que search.luceneHighlighter llame de vuelvo a TextBPVManager para conseguir el texto subrayado, ya que TextBPVManager es la clase que maneja los LuceneObjects que se probablemente se usarán para eso. Apuntes para agrupar resultados de búsqueda =========================================== Resultados de ejemplo --------------------- photo_1 --regla_1--> libro_1 photo_2 --regla_1--> libro_1 photo_3 --regla_1--> libro_2 photo_4 --regla_2--> libro_2 --regla_3--> autor_1 photo_5 --regla_2--> libro_2 --regla_3--> autor_1 photo_6 --regla_3--> autor_1 --regla_1--> libro_1 --(resultado directo) Presentación de ejemplo ----------------------- Registros con resultados en diversos campos (distintos a los grupos de resultados que aparecen a continuación) photo_6 photo_4 photo_5 libro_1/regla_1 : 3 photos photo_1 photo_2 photo_6 libro_2/regla_1 : 1 photo photo_3 Algoritmo para la consolidación ------------------------------- - Sacar todos los DO de SOC principal - Para cada DO de un SOC principal hacer una lista de las vías por las que fue encontrado - Hacer la lista de las vías que se han usado (una vía es distinguida por su regla, DO de partida o, si DO de partida = DO de SOC principal, por la propiedad en que aparece el resutlado de literal) - Si hay vías que derivan en más de un DO de SOC principal, estos DO pueden formar un grupo - Si hay grupos que tienen exactamente los mismos DO de SOC principales, pueden consolidarse en un sólo grupo