Migración de FOLIO de la Library of Congress : Preguntas frecuentes para los usuarios de NACO de OCLC
OCLC está trabajando estrechamente con la Library of Congress para apoyar su migración a FOLIO. Durante esta migración, la Library of Congress congelará todo el trabajo de autoridad y deshabilitará temporalmente los nodos NACO . Esto afectará a los colaboradores autorizados de NACO en la comunidad de OCLC y a las aplicaciones Connexion y Administrador de Registros de WorldShare de OCLC.
Cómo afecta a OCLC la migración de la Biblioteca del Congreso a FOLIO :
- OCLC es socio de la Library of Congress y actúa como nodo NACO . A medida que la Library of Congress migre a su nuevo sistema FOLIO, OCLC deberá volver a cargar todo el Archivo de autoridad de nombres de la Library of Congress (LC/NAF) después de haber migrado a FOLIO.
Migración de FOLIO de la Library of Congress : Preguntas frecuentes para los usuarios de NACO de OCLC
- Última actualización: 14 de agosto de 2025
- Descubra información relacionada con la migración de la Biblioteca del Congreso a FOLIO.
NOVEDADES
- Todos los campos y subcampos MARC nuevos y/o modificados en el formato de autoridad ahora estarán disponibles para su uso, siguiendo las Pautas de LC. Las pautas de DCM Z1 y LC se actualizarán a fines de agosto para reflejar los nuevos campos y subcampos que ahora están disponibles.
- Se han eliminado los 375 campos en los registros de nombres personales. Tenga en cuenta que si alguien agrega un 375 a una autoridad de nombre, su registro será rechazado a través del proceso de validación de distribución.
- Ahora es posible la implementación completa de Unicode. El Comité de Políticas de PCC está en proceso de analizar los cambios de política que ahora son posibles debido a este cambio en el sistema. En otras palabras, ¡no empiece a agregar de repente todos y cada uno de los scripts! Todas las políticas actuales relacionadas con los caracteres y el script siguen vigentes. Pero la barrera técnica para cambiar las políticas ya no existe. A medida que se tomen decisiones sobre los cambios que NACO desea implementar, NACO hará anuncios y actualizará la documentación lo antes posible.
- Los cambios por lotes en los NAR de nombres para permitir que se utilicen como puntos de acceso ahora serán considerablemente más fáciles y deberían ocurrir poco después del reinicio.
- Todos los registros NACO AACR2 elegibles para RDA se han convertido a RDA (es decir, 008/10=z; 040 $e rda).
POLÍTICAS Y CONFIGURACIÓN DE CHARACTER ENCODING
Pautas para el ingreso de caracteres
Para colaboradores de NACO : continuar usando caracteres descompuestos (letra + diacrítico separado) en lugar de caracteres Unicode precompuestos hasta que la PCC establezca una política oficial.
Mejores prácticas:
- Use solo los caracteres disponibles en su teclado estándar
- Agregue símbolos diacríticos y caracteres especiales mediante la función "Ingresar símbolos diacríticos y caracteres especiales" de OCLC Connexion
- Al copiar de recursos en línea, convierta los caracteres precompuestos y las comillas tipográficas a sus equivalentes descompuestos
- Evite copiar y pegar caracteres especiales directamente de fuentes web
Ajustes de configuración de exportación
Configuración recomendada: establecer Exportar → Características del registro en UTF-8 Unicode (en lugar de MARC-8)
Cuándo UTF-8 es ideal:
- Exportando a archivos para usar con MarcEdit o herramientas similares
- Trabajando con sistemas que manejan codificación UTF-8
- Necesita flexibilidad para volver a codificar registros más adelante (los archivos UTF-8 se pueden convertir a MARC-8 usando herramientas externas)
Cuando MARC-8 puede ser necesario:
- Su sistema local requiere la codificación MARC-8
- Los registros se importan directamente (no a través de la exportación de archivos)
- Su sistema no puede manejar UTF-8
Consideraciones importantes
- Ventajas de UTF-8: Mejor compatibilidad con los sistemas modernos y permite flexibilidad en la recodificación a través de herramientas externas.
- Limitaciones de MARC-8: algunos registros que contienen caracteres no compatibles con MARC-8 pueden mostrar caracteres corruptos o inusuales, sin una solución alternativa disponible, ya que LC está realizando la transición a UTF-8 sin garantizar la compatibilidad con MARC-8.
- En pocas palabras: Por lo general, se recomienda UTF-8 por su flexibilidad y compatibilidad futura, a menos que su sistema local requiera específicamente la importación directa de MARC-8.
PANTALLA DE CONNEXION DE OCLC
En el cliente de Connexion , algunos caracteres CJK pueden mostrarse como radicales individuales o componentes de sílabas en lugar de como caracteres compuestos. Siempre que los caracteres que ingrese tengan los puntos de código Unicode apropiados, esta diferencia de visualización no debería afectar la funcionalidad.
Tenga en cuenta que los Connexion 400 están completamente descompuestos y espaciados. Los 670 de la versión 2.63 también se ven completamente diferentes a los de la 3.1, aunque los personajes son los mismos detrás de escena.
CONEXIÓN 2.63
CONEXIÓN 3.1
PROBLEMA CONOCIDO: REGISTROS DE AUTORIDAD DUPLICADOS CON EL MISMO LCCN
OCLC ha sido informada de una situación poco frecuente que ocurrió con al menos un registro de autoridad de nombre distribuido de LC a OCLC. Como sabe, el registro de autoridad que ve en Connexion and Record Manager es una copia del registro de autoridad alojado en la Library of Congress. Todos los días, OCLC procesa un archivo de la LC para sincronizar nuestra copia del archivo de autoridad con la de la LC. LC también procesa un archivo de OCLC y otros nodos de NACO para incorporar los cambios realizados por los participantes de NACO . Este proceso se describe de forma algo anticuada aquí: https://www.loc.gov/aba/pcc/naco/nodes.html. Ocasionalmente, en lugar de reemplazar el registro de autoridad, terminamos con dos versiones del mismo registro. Esta es la razón por la que está viendo dos registros de autoridad con diferentes marcas de tiempo y el mismo LCCN. Si observa el registro de autoridad de LC en su base de datos, verá la versión correcta del registro: https://lccn.loc.gov/no2020000021 .
Necesitamos borrar la copia incorrecta del registro de autoridad en la base de datos de OCLC, de modo que solo vea la copia correcta con la marca de tiempo 2025. Reporte estos registros de autoridad a askqc@oclc.org y proporcione la siguiente información:
- El LCCN del registro de autoridad
- Una descripción o captura de pantalla de lo que está viendo
- Qué aplicación de OCLC está utilizando (p. ej., Connexion 2.63, Connexion 3.0 o Record Manager)
Ejemplo:
N.º 1
LDR nzn
001 oca12667562
008 200101nc azannaabn ∎b aaa c
005 20200103073010.0
010 no2020000021
040 HkU $b eng $e rda $c HkU
046 $f 1989 $2 edtf
100 1 Duan, Lei, $d 1989 en adelante
#2
LDR nzn
001 oca13024952
008 200101nc azannaabn ∎b aaa c
005 20250804171813.9
010 no2020000021
040 HkU $b eng $e rda $c HkU
046 $f 1989 $2 edtf
100 1 Duan, Lei, $d 1989 en adelante
Mientras tanto, si necesita usar el encabezamiento en un registro bibliográfico, simplemente controle el encabezamiento como de costumbre.
Tenga en cuenta que esto solo se aplica a registros de autoridad duplicados con el mismo LCCN. Cuando encuentre registros de autoridad duplicados con diferentes LCCN para la entidad, se aplicarán los procedimientos habituales. Los miembros de NACO deben informar de ello a la LC y los no miembros de NACO deben informar de ello a authfile@oclc.org.
