====== Referencias en el OPAC ====== Algunas notas sobre la implementación de referencias (véase, véase además) en el OPAC. Seguramente hay material previo (¡del año 2003!) acerca de estas cuestiones; habría que rescatarlo de papeles que andan por ahí. También hay que ver el archivo ''cgi-bin/pft/headings.pft'' pues allí ya se tenía en cuenta la visualización de referencias. Comencemos por dejar en claro qué pretendemos lograr; luego iremos viendo posibles caminos que nos pueden llevar a lograrlo. - Los índices alfabéticos de encabezamientos (nombres, temas) deben mostrar también las formas no autorizadas. Éstas, en lugar de ser links (como sucede en el caso de las formas autorizadas), deben estar acompañadas del texto "véase: ", seguido por un link con la correspondiente forma autorizada. - Una búsqueda en las bases de encabezamientos (nombres, temas) debe recuperar también las formas no autorizadas. Si logramos estos dos objetivos, estaremos satisfechos. Para lograr ambos objetivos necesitamos empezar por esto: cada base de encabezamientos debe contener tanto las formas autorizadas como las no autorizadas, con una marca que distinga unas de otras. Además, cada forma no autorizada debe incluir un puntero a su respectiva forma autorizada, de manera de poder mostrar el link junto al encabezamiento. Podríamos usar justamente la presencia de ese puntero como la //marca// que permite reconocer una forma no autorizada. ¿Cómo llegan las formas no autorizadas a las bases de encabezamientos? Aquí tenemos que considerar dos situaciones. En la situación ideal, tenemos una base de autoridades, formada por registros MARC de autoridades con campos 1xx y referencias en 4xx y 5xx. En la presente situación de transición, podríamos contar con una tabla que ponga en correspondencia algunos encabezamientos problemáticos con algunas formas alternativas. ===== Scripts ===== En la situación actual, contamos con dos herramientas para extraer listas de encabezamientos a partir de una base bibliográfica: el script ''update_db.py'' usado para generar las bases para el OPAC, y el script ''auto.py'' usado para construir una base de registros de autoridad. El diagrama muestra a grandes rasgos el output de ambos procesos; el input en ambos casos es una base bibliográfica: update_db.py base name base subj base title base biblio (c/ headings y punteros) ----------- ----------- ------------ ------------- 1 heading 1 heading 1 title 245 ...... 8 subcat 8 subcat 2 tag 260 ...... 9 ID 9 ID 13 sort indic. 700 ..... > 11 hits 11 hits 14 sort letter 700 ..... > auto.py base auto base biblio (c/punteros, s/headings) ----------- ------------- 1 heading 245 ...... 8 subcat 260 ...... 9 ID 700 > $4edt 11 hits 700 > $4edt En el diagrama usamos ">" para indicar la presencia de un "puntero" a un registro en la base de headings; esto es, un subcampo $0 (o $9) que contiene el nro de control del registro asociado. Si bien el segundo proceso se originó en las técnicas usadas para el primero, ambos están desvinculados en la práctica. En el futuro, esperamos tener nuestros datos de origen en la forma generada por el 2do proceso, es decir, una base auto y una base biblio con punteros a auto. Por lo tanto, sería deseable que el proceso de actualización del OPAC tomase como datos iniciales justamente a ese par de bases. **TO-DO**: analizar ambos procesos, para detectar elementos comunes, y posibles inconsistencias entre ellos. ==== Algoritmo ==== Si partimos de esa estructura, tenemos este algoritmo: para cada registro A en auto: crear un registro en la base name/subj, con campos: - 001 : campo 001 de A (ID) - 1xx : campo 1xx de A (heading) - 011 : hits (npost(['biblio']v1)) para cada campo 4xx en A: crear un registro en la base name/subj, con campos: - 001 : necesitamos un ID para cada referencia? - 1xx o 4xx : el campo 4xx de A (referencia) - x : campo 001 de A (ID del heading autorizado) Usando mx, tendríamos algo así: mx auto "pft=@all-headings.pft" now -all > all-headings.id id2i all-headings.id create=all-headings /* all-headings.pft */ '!ID 0'/ '!v001!',v001/ '!v100!',v100, v110, v111/ '!v011!',f(npost(['biblio']v1), 1, 0)/ ( '!ID 0'/ '!v001!',v001[1], '_', f(iocc, 1, 0)/ '!v100!',v400, v410, v411/ '!v019!',v1[1]/ /* esta es la marca que identifica el registro como "referencia" */ ) A esto debemos agregar detección y consolidación de duplicados, por si hubiese referencias múltiples (ver explicación más abajo). ==== Por qué necesitamos crear una base aparte ==== Dado que ya contamos con una base de registros de autoridad, es natural preguntarse por qué no podemos usar en el OPAC esa misma base (quizás con alguna leve modificación), y en cambio vamos a crear una nueva base, con una estructura diferente: cada encabezamiento ---autorizado o referencia--- tendrá su propio registro. Más arriba habíamos mencionado dos objetivos que deseamos lograr. El primero tiene que ver con la función de //browsing//, y dado que en el OPAC el //browsing// de las listas de encabezamientos está implementado mediante un mfnrage sobre una base ordenada alfabéticamente, la base de autoridad en su estado original no nos sirve: necesitamos que cada encabezamiento (autorizado o referencia) tenga su propio registro, para luego poder ordenarlos. El segundo objetivo está relacionado con la función de //searching//; aquí no parece tan evidente que necesitemos un registro separado por cada referencia, pues bastaría con enviar al diccionario todos los encabezamientos que aparecen en un registro de autoridad, y al buscar por cualquiera de ellos recuperaríamos el registro de autoridad completo. Sin embargo, es importante que al mostrar los resultados de la búsqueda resaltemos los términos sobre los que se basó la recuperación; es decir, que de todo el registro de autoridad deberíamos mostrar el campo 4xx que nos interesa, y posiblemente ocultar todos los 4xx restantes. ¿Podríamos hacer esto fácilmente, sin recurrir a un registro por cada 4xx? Hay al menos dos maneras de convertir los registros de autoridad en registros que nos resulten más útiles en el OPAC: Partimos de estos dos registros de autoridad: [RA1] 100 Encabezamiento autorizado A 400 Referencia A1 400 Referencia A2 [RA2] 100 Encabezamiento autorizado B Como hay en total cuatro encabezamientos involucrados, y cada uno de ellos irá a un registro separado, generamos cuatro registros de encabezamientos. * Una opción consiste en usar un campo fijo (digamos el 1) para el encabezamiento, y en aquellos casos en que se trate de una referencia, usamos otro campo (digamos el 4) para el encabezamiento autorizado correspondiente. Así, el índice alfabético es un listado de los campos 1, y en base a la presencia del campo 4 decidimos si el término se visualiza como una referencia. Esto representa una //inversión// con respecto a la estructura del registro de autoridad, en el sentido de que el encabezamiento autorizado pasa a estar subordinado a la referencia. [R1] 1 Encabezamiento autorizado A [R2] 1 Referencia A1 4 Encabezamiento autorizado A [R3] 1 Referencia A2 4 Heading autorizado A [R4] 1 Encabezamiento autorizado B * Otra opción consiste en usar siempre el mismo campo (digamos el 1) para la forma autorizada del encabezamiento, y ocasionalmente un campo (digamos el 4) para una referencia. En este caso el índice alfabético se arma como un listado de campos 1, salvo cuando un registro tiene campo 4, en cuyo caso se muestra ese campo. Aquí la estructura es similar a la del registro de autoridad, con la limitación de tener no más de una referencia por registro. [R1'] 1 Encabezamiento autorizado A [R2'] 1 Encabezamiento autorizado A 4 Referencia A1 [R3'] 1 Encabezamiento autorizado A 4 Referencia A2 [R4'] 1 Encabezamiento autorizado B De las dos opciones, parece más satisfactoria la primera, ya que pone en un mismo nivel a todos los términos del índice, ya sean encabezamientos autorizados o referencias. Así se simplifica, p.ej., la FST para la base de encabezamientos, ya que sólo nos interesará buscar por palabras en el campo 1. ==== Análisis comparativo de ambos procesos ==== === update_db.py === Tomamos como muestra una de las bases de headings: subj. El caso de la base name es análogo. Cómo se crea y se usa la base SUBJ en update_db.py Archivos auxiliares: - SUBJ.PFT - REGPUNT.PFT - HEADSORT.PFT - ELIMDUP2.PFT - HEADINGS.FST def build_subj_db(): # ------------------------------------------------------------------ # BASE SUBJ # ------------------------------------------------------------------ logger.info("-----------------------------------------------------") logger.info(" Base de encabezamientos tematicos") logger.info("-----------------------------------------------------") logger.info("Creamos el listado de encabezamientos tematicos...") run('''mx "seq=tmp/biblio2.id\\n" lw=1000 "pft=if getenv('SUBJ_TAGS') : v1*1.4 then @SUBJ.PFT fi" now tell=%s > tmp/subj1.id''' % TELL) logger.info("Convertimos el listado en una base (desordenada y con duplicados)...") run('''id2i tmp/subj1.id create/app=tmp/subj1 tell=%s''' % TELL) logger.info("Regularizamos la puntuacion final de los encabezamientos generados...") run('''mx tmp/subj1 "proc='d2a2¦',v1,'¦'" "proc='d1a1¦',@REGPUNT.PFT,'¦'" "proc='d2'" copy=tmp/subj1 now -all tell=%s''' % TELL) logger.info("Almacenamos en un campo auxiliar la clave de ordenacion...") run('''mx tmp/subj1 uctab=UC-ANSI.TAB "proc='d99a99¦',@HEADSORT.PFT,'¦'" copy=tmp/subj1 now -all tell=%s''' % TELL) logger.info("Ordenamos la base de encabezamientos tematicos...") run('''msrt tmp/subj1 100 v99 tell=%s''' % TELL) logger.info("Generamos la tabla para mapear los numeros de encabezamientos...") run('''mx tmp/subj1 "pft=if s(v1) <> ref(mfn-1,v1) then putenv('HEADING_CODE='v9) fi, v9,'|',getenv('HEADING_CODE')/" now -all tell=%s > tmp/subjcode.seq''' % TELL) logger.info("Eliminamos los encabezamientos duplicados...") run('''mx tmp/subj1 lw=1000 "pft=@ELIMDUP2.PFT" now tell=%s > tmp/subj.id''' % TELL) logger.info("Creamos la base de encabezamientos tematicos (ordenada y sin duplicados)...") run('''id2i tmp/subj.id create/app=subj tell=%s''' % TELL) en recode_headings_in_biblio() run('''mx seq=tmp/subjcode.seq create=tmp/subjcode now -all''') run('''mx tmp/subjcode "fst=1 0 v1" fullinv=tmp/subjcode''') en process_subcatalogs() run('''mx subj "proc='a8#', ref(['tmp/hs']l(['tmp/hs']v9), v2+|#a8#|) ,'#'" copy=subj now -all''') en fullinv() run('''mx subj fst=@HEADINGS.FST actab=AC-ANSI.TAB uctab=UC-ANSI.TAB fullinv=subj tell=%s''' % TELL) en compute_heading_postings() logger.info("Asignamos postings a los terminos del indice de temas.") run('''mx subj "proc='d11a11#',f(npost(['biblio']'_SUBJ_'v9),1,0),'#'" copy=subj now -all tell=%s''' % TELL) en build_agrep_dictionaries() run('''mx dict=subj "pft=v1^*/" k1=a k2=zz now > dictSUBJ.txt''') === auto.bat === 1 - CONSTRUCCION DE BASE AUTO ARCHIVOS AUXILIARES: extract-headings.pft fix-tags-indicators.pft 008etc.pft auto.fst :: Si está presente el campo 240, creamos un campo auxiliar 1xx + $t (nombre/título) ::mx %BIBLIO% proc=@v240.pft create=%WORK%\biblio-240 now -all echo %PREFIX%>%WORK%\prefix :: Eliminamos campo 1106 y creamos una copia de trabajo de la base bibliográfica. mx %BIBLIO% "proc='d1106'" create=%WORK%\biblio now -all tell=%TELL% :: Cada campo de la base bibliográfica pasa a ser un registro de la base biblio-campos. i2id %WORK%\biblio >%WORK%\biblio.id mx "seq=%WORK%\biblio.id%SEQ_DELIM%" lw=%LW% create=%WORK%\biblio-campos now -all tell=%TELL% :: Eliminamos espacios en blanco en los extremos (¿a qué se deben esos espacios?) :: TO-DO: ¿vale la pena hacer la limpieza sobre toda la base, si solo nos interesan los encabezamientos? mxcp %WORK%\biblio-campos create=%WORK%\biblio-campos-clean clean log=%OUTPUT%\mxcp-biblio-campos.txt >nul tell=%TELL% :: Extraemos los campos con encabezamientos controlados, y creamos una base con ellos. :: ATENCION: para filtrar subcampos $e, $4, $5, podemos usar algo como name.pft del OPAC. (??) :: TO-DO: para uctab necesitamos usar una tabla ad hoc. mx %WORK%\biblio-campos-clean uctab=UC-ANSI.TAB lw=%LW% pft=@extract-headings.pft now tell=%TELL% >%WORK%\auto-dup.seq mx seq=%WORK%\auto-dup.seq create=%WORK%\auto-dup now -all tell=%TELL% :: Ordenamos la lista de encabezamientos. :: Usamos el formato "mpu,v1*4" para comparar en mayúsculas, ignorando los indicadores y el primer delimitador de subcampo. :: Necesitamos guardar la clave en un campo auxiliar (99) para poder usar la tabla correcta de conversión a mayúsculas. mx %WORK%\auto-dup uctab=UC-ANSI.TAB "proc='a99|',mpu,v1*4,'|'" copy=%WORK%\auto-dup now -all tell=%TELL% msrt %WORK%\auto-dup 1000 v99 :: Eliminamos encabezamientos duplicados. :: Usamos el formato "v1*2" para comparar encabezamientos ignorando los indicadores. :: La comparación es directa (sin conversión a mayúsculas ni de otro tipo), por lo tanto detecta *cualquier* diferencia. :: ATENCION: si normalizamos *antes* el 2do indicador de x00, x10, x11, ¿podemos acá incluir los indicadores en la comparación? mx %WORK%\auto-dup lw=%LW% "pft=if v1*2 <> ref(mfn-1,v1*2) then v1,'|',v2,'|',v3/ fi" now >%WORK%\auto-uniq.seq mx seq=%WORK%\auto-uniq.seq lw=%LW% create=%WORK%\auto-uniq now -all :: Reasignamos tags y ajustamos los indicadores en los registros de autoridades. mx %WORK%\auto-uniq "proc=@fix-tags-indicators.pft" create=%WORK%\auto now -all tell=%TELL% :: Agregamos campos a los registros de autoridades: leader, 005, 008, 999. mx %WORK%\auto "proc=@008etc.pft" copy=%WORK%\auto now -all :: Ordenamos por tag los campos de cada registro de autoridad. mx %WORK%\auto "proc='s'" create=%OUTPUT%\auto now -all :: Diccionario para la base de autoridades. mx %OUTPUT%\auto fst=@auto.fst actab=AC-ANSI.TAB uctab=UC-ANSI.TAB fullinv=%OUTPUT%\auto 3 - GENERACION DE LINKS ENTRE BIBLIO y AUTO ARCHIVOS AUXILIARES: create-subfield-0.pft update-subfield-0.pft :: Construimos tabla de mapeo de punteros a la base bibliográfica. mx %WORK%\auto-dup "pft=if v1*2 <> ref(mfn-1,v1*2) then putenv('PTR=',v2) fi, v2,'|',getenv('PTR')/" now -all >%WORK%\map.seq mx seq=%WORK%\map.seq create=%WORK%\map now -all :: Diccionario para map. mx %WORK%\map "fst=1 0 v1/" fullinv=%WORK%\map :: Creamos un subcampo $0 en cada punto de acceso. :: ¿Por qué subcampo $0? Ver http://www.loc.gov/marc/marbi/2007/2007-06.html mx %WORK%\biblio-campos-clean proc=@create-subfield-0.pft create=%WORK%\biblio-campos-ref1 now -all tell=%TELL% :: Consultamos la base map para reasignar punteros en la base bibliográfica. mx %WORK%\biblio-campos-ref1 proc=@update-subfield-0.pft create=%WORK%\biblio-campos-ref2 now -all tell=%TELL% :: Regeneramos la base bibliográfica. mx %WORK%\biblio-campos-ref2 lw=%LW% "pft=v1/" now -all tell=%TELL% >%WORK%\biblio-campos-ref2.id id2i %WORK%\biblio-campos-ref2.id create=%OUTPUT%\biblio-ref ===== Referencias múltiples ===== No sé si "referencia múltiple" es el nombre correcto, pero la situación es ésta: una referencia puede ser compartida por varios encabezamientos autorizados. Un ejemplo que aparece en el libro de Maxwell es **IBM**: 110 International Business Machines 110 Instituto de Biología Marina 410 IBM 410 IBM ¿Cómo debiera aparecer IBM en el índice de nombres? * un solo registro, que incluya todas las referencias: IBM véase: International Business Machines Instituto de Biología Marina * un registro por cada referencia: IBM véase: International Business Machines IBM véase: Instituto de Biología Marina El primer caso, que parece el más atractivo, requiere que detectemos y consolidemos los duplicados que pudieran aparecer en la lista de nombres. En el primer caso se hace más fácil lograr que todo el conjunto de referencias permanezca en una misma página. NOTA: En un caso de referencias múltiples no podríamos usar el //redireccionamiento automático// (i.e., que una búsqueda por una de las variantes muestre directamente los resultados asociados a la forma autorizada, sin que el usuario deba volver a pedirlos explícitamente). ===== Nombres rusos ===== Esta sección tiene relación con el problema de las referencias, en el sentido de guiar al usuario desde una forma no autorizada hacia la forma autorizada usada en el catálogo; sin embargo, como el problema de los apóstrofes parece que puede resolverse en forma automática sin necesidad de crear referencias en registros de autoridad, esta sección deberá moverse a otra página del wiki. Ciertos nombres rusos presentan un problema particular, que posiblemente tenga relevancia para otras situaciones. Tomemos el caso del matemático ruso [[http://en.wikipedia.org/wiki/Vladimir_Arnold|Vladimir Arnold]], cuyo nombre según Wikipedia es: **Vladimir Igorevich Arnol'd or Arnold (Russian: Влади́мир И́горевич Арно́льд)** (ver también [[http://ru.wikipedia.org/wiki/%D0%90%D1%80%D0%BD%D0%BE%D0%BB%D1%8C%D0%B4,_%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80_%D0%98%D0%B3%D0%BE%D1%80%D0%B5%D0%B2%D0%B8%D1%87|Wikipedia rusa]]), y cuyo encabezamiento en LC es: Arnolʹd, V. I. (Vladimir Igorevich), 1937- Es usual encontrar el apellido en alguna de estas variantes: Arnold, Arnol'd, Arnol´d. Repasemos de dónde proviene este apóstrofe. Según el artículo [[http://en.wikipedia.org/wiki/Soft_sign|Soft sign]] en Wikipedia: "[The soft sign] does not represent an individual sound but just indicates softening (palatalization) of the preceding consonant—or just has a traditional orthographic usage with no phonetic meaning..." "In the romanization of Cyrillic words, soft signs are typically replaced with the prime symbol (or, alternatively, apostrophe) or just ignored..." Al hacer una búsqueda en el [[http://catalog.loc.gov/|catálogo bibliográfico de LC]], usando Author/Creator Keyword = vladimir arnold encontramos el encabezamiento Arnol'd, V. I. (Vladimir Igorevich), 1937- Si buscamos usando el apóstrofe Author/Creator Keyword = vladimir arnol'd también llegamos al mismo resultado. Pero no encontramos nada si usamos un //acento agudo// (que no es lo mismo que el //símbolo de prima//): Author/Creator Keyword = vladimir arnol´d Si exploramos el [[http://authorities.loc.gov/|catálogo de autoridades de LC]], vemos que //Arnold// y //Arnol'd// aparecen intercalados en el listado alfabético, es decir, el apóstrofe es ignorado a los fines del ordenamiento. Por otra parte, encontramos que el registro de autoridad para Vladimir Arnold contiene: 100 10 |a Arnol'd, V. I. |q (Vladimir Igorevich), |d 1937- 400 10 |w nnaa |a Arnol'd, Vladimir Igorevich 400 10 |a Arnol'd, Vladimir Igorevich, |d 1937- donde podemos observar que LC no añade referencias para la variante sin apóstrofe. Por lo tanto, la posibilidad de recuperar los nombres independientemente de la presencia o ausencia de este símbolo no depende de la presencia explícita de referencias en el catálogo, sino de la capacidad del sistema para: - Ignorar el símbolo al ordenar alfabéticamente (filing rules): //arnol'd// se ordena como //arnold//. - Permitir que el string //Arnol'd// (tal como figura en el registro de autoridad), produzca un matching tanto con //arnol'd// como con //arnold//. Como en los matchings dependen tanto de las normalizaciones aplicadas a los datos del registro, como de aquellas aplicadas a los términos ingresados por el usuario, podemos llegar a este resultado por dos caminos: * Enviar //Arnol'd// al índice (archivo invertido) en dos formas: //ARNOL'D// y //ARNOLD//, y no quitar el apóstrofe en la expresión ingresada por el usuario. Así, el usuario puede ingresar cualquiera de las dos formas, y el matching se producirá. * Normalizar en ambos lados: //Arnol'd// se indiza como //ARNOLD//, y el término //arnol'd// ingresado por el usuario se convierte en //ARNOLD// antes de realizar la consulta a la base de datos. Actualmente, la normalización (o, mejor dicho, limpieza) de la expresión ingresada por el usuario la estamos realizando con la función ''cleanQuery'', que simplemente aplica una FST de una línea para extraer las "palabras"; con esta técnica, para un input de //arnol'd// obtendríamos dos palabras: //ARNOL// y //D//, o bien (si modificamos la tabla ACTAB) una única palabra //ARNOL'D//. Para lograr que desaparezca el apóstrofe (y dado que, hasta donde sé, la tabla UCTAB no nos permite //eliminar// un carácter al aplicar la conversión a mayúsculas) necesitamos recurrir a una sustitución, p.ej. mediante un gizmo o algo similar a esto: replace(query, "'"n9999, '') También queremos (y así está funcionando) poder entrar al índice mediante el término ''d'amore'' o ''damore'', y llegar a la misma posición en ambos casos. ===== Otros nombres con apóstrofes ===== Parece que esta técnica podría usarse tanto para nombres rusos como para cualquier otro nombre que contenga apóstrofes (o signos similares), p.ej. D'Amico => DAMICO L'Hôpital => LHOPITAL O'Higgins => OHIGGINS O'Reilly => OREILLY Sin embargo, no siempre un apóstrofe que aparezca como parte de un nombre puede omitirse para dar lugar a la fusión entre la partícula y la palabra que sigue, como puede verse en este ejemplo: Bureau Régional de L'Unesco pour L'education en Asie et en Océanie donde no queremos obtener ''LUNESCO'' ni ''LEDUCATION'', y sí queremos ''UNESCO'' y ''EDUCATION''. En el OPAC de LC notamos que una búsqueda por Author/Creator Keyword = lunesco recupera encabezamientos con el texto //de l'UNESCO//, y los mismos encabezamientos no se recuperan si la búsqueda usa el término ''unesco''. Entonces una primera aproximación puede ser: aplicar la conversión solamente a nombres personales. Problema: en la base ''name'' no hemos guardado el tipo de encabezamiento (100, 110, 111). TO-DO: estudiar el uso del gizmo **dictgiz**, y ver qué relación tiene con este problema. Ver http://catalis.uns.edu.ar/dokuwiki/doku.php/notas/diccionario_del_opac **ATENCION:** Tener en cuenta que el tratamiento que demos a los apóstrofes para la búsqueda por palabras en las bases de encabezamientos debe ser consistente con el que les demos al buscar en la base bibliográfica (dictgiz tiene que ver un poco). Esto es útil, por ejemplo, para que una búsqueda de "Darcy Thompson" hecha por error en el campo título nos permita obtener un link a la misma búsqueda (exitosa) en el campo autor (el autor es //D'Arcy Wentworth Thompson//). En el caso de la base bibliográfica, ¿en qué campos aplicamos la supresión de apóstrofes? ===== El mecanismo ===== Veamos entonces cuál es el mecanismo que usaremos para resolver este problema en el OPAC. Este es el comando que usamos en ''update_db.py'' para generar el invertido de la base ''name'': mx name fst=@HEADINGS.FST actab=AC-ANSI.TAB uctab=UC-ANSI.TAB fullinv=name La parte de ''headings.fst'' que afecta la búsqueda por palabras es: 0 0 /* Invertimos todos los subcampos, palabra por palabra */ 1 4 proc('a1002¦',replace(v1*1,'~','¦a1002¦'),'¦'), (v1002*1/) Si queremos que al pasar al diccionario ''O'Reilly'' se convierta en ''OREILLY'' y ''Arnol´d'' en ''ARNOLD'', necesitamos suprimir los apóstrofes y similares, //antes// de que entre en efecto el parámetro ''actab'' para separar en palabras. Esto puede lograrse desde la misma FST (usando la función ''replace''), o bien usando un gizmo. Dado que nos interesa aplicar exactamente las mismas sustituciones tanto a los datos de la base como al input del usuario, parece conveniente usar **un único gizmo** que sea llamado desde ''update_db.py'' y desde ''opac.xis'' (función ''cleanQuery''). Recordemos que en la versión 5.2 de la interfaz CISIS podemos **aplicar un gizmo como parte de un proc**; esto nos permite aplicar el gizmo al procesar la consulta del usuario con wxis. Ver en el manual de referencia de CISIS, //Función G[,]//. Otra novedad en esta versión: la limpieza que hacíamos con una FST se puede realizar usando ''"proc='Gsplit=1=words'"'' (con la actab apropiada). Un detalle que habría que revisar: el **resaltado** de los términos usados en la consulta no funciona correctamente; por ejemplo, al buscar ''arnold'' se recupera ''Arnol´d'', pero no se resalta la cadena. ===== Referencias de "véase además" (see also references) ===== Las referencias de "véase además" se generan a partir de los campos 5xx de los registros de autoridad. Se emplean para conducir al usuario desde un encabezamiento autorizado a otro encabezamiento relacionado, también autorizado. Usos típicos de estos campos (según //Maxwell's guide to authority work//): * Seudónimos * Referencias que entran en conflicto con encabezamientos establecidos * Nombres corporativos relacionados * //Performing groups// * Jefes de estado, etc. La visualización de las referencias puede aparecer en al menos estos dos contextos: - En la página donde aparecen los registros asociados a un encabezamiento - En el índice alfabético de encabezamientos, al hacer un //browse// o un //search// En el caso 1 no tenemos opción: es indispensable que el usuario, al ver la lista de registros asociados al encabezamiento H1, sepa que el catálogo le puede ofrecer registros relacionados, asociados a otros encabezamientos. En el caso 2 no resulta tan claro: podríamos optar entre presentar las referencias de //véase además// junto a los encabezamientos que las tengan, o bien diferir esa información hasta que el usuario haya efectuado una búsqueda usando uno de esos encabezamientos. Veamos qué esperamos del OPAC en cada uno de estos casos. ==== Seudónimos ==== Tomemos el caso de Lewis Carroll, para quien tenemos estos dos registros de autoridad: 100 1_ |a Carroll, Lewis, |d 1832-1898 400 1_ |a Karol, Luis, |d 1832-1898 500 1_ |a Dodgson, Charles Lutwidge, |d 1832-1898 100 1_ |a Dodgson, Charles Lutwidge, |d 1832-1898 400 1_ |a Dodgson, C. L. |q (Charles Lutwidge), |d 1832-1898 500 1_ |a Carroll, Lewis, |d 1832-1898 En el listado de autores podríamos presentar esta visualización: ... Carroll, Lewis, 1832-1898 ... Dodgson, C. L. (Charles Lutwidge), 1832-1898 véase: Dodgson, Charles Lutwidge, 1832-1898 ... Dodgson, Charles Lutwidge, 1832-1898 ... Karol, Luis, 1832-1898 véase: Carroll, Lewis, 1832-1898 ... Allí sólo estamos mostrando las referencias de véase (de los campos 4xx). {{tag>opacmarc desarrollo referencias}}