Summary

  • El ensayo original de Berners-Lee, fechado por la cronología de W3C en diciembre de 1998, atribuye la permanencia de una URI a quien administra el sitio. El servidor puede dirigir una dirección estable al archivo o programa que corresponda tras una reforma.
  • Un nombre de empleado, cgi-bin, una extensión, el estado de un borrador o una categoría editorial describen cómo trabaja el editor hoy. Si forman parte de una dirección duradera, cada cambio de ese trabajo puede romper referencias ajenas.

El error empieza en el plano de la oficina

Una dirección web se escribe fuera del edificio que la creó. Aparece en otro sitio, en una bibliografía, en un marcador guardado durante años. El editor controla el servidor que responde cuando alguien vuelve. Berners-Lee preguntaba en “Cool URIs don't change” por qué tantos editores trataban sus cambios de oficina como cambios obligatorios del mapa público. Su respuesta era incómoda para el jefe de la reforma: mover un archivo no exige mover la URI que lo identifica. El servidor puede mantener una relación entre el nombre visible y la ubicación que use en ese momento.

La lista de excusas del ensayo parece el acta de una reunión: reorganizamos el sitio para mejorarlo; ya no sabemos qué documentos son válidos; cambiamos los ficheros de máquina; otra persona se encarga del material; hemos sustituido un script CGI. Son decisiones reales. También son decisiones del editor. Hacer que una dirección publique la ruta del fichero o el nombre del script convierte la vida interna del sitio en una carga para cualquiera que lo cite. Si se conserva la dirección y se cambia la correspondencia en el servidor, el trabajo permanece en casa.

El texto puso un ejemplo concreto de documentos de la National Science Foundation. Una dirección enseñaba cgi-bin, un programa Perl y una consulta de recuperación. Otra incorporaba pubs/1998 y un identificador de documento. Berners-Lee consideraba más prometedora la segunda porque el año y el identificador podían seguir describiendo el documento después de cambiar el mecanismo de publicación. Era un juicio sobre el diseño de aquellas direcciones en 1998. La lección no depende de comprobar si sus ejemplos siguen activos hoy: una ruta que anuncia el programa de turno tiene fecha de caducidad en su propia sintaxis.

La factura llega cuando un lector regresa. El administrador sabe exactamente qué movió; el sitio que enlazó hace años quizá no reciba aviso. Un investigador puede descubrir el error al revisar una cita. Otro no volverá a intentarlo. Berners-Lee señalaba que nadie puede enumerar todos los lugares donde quedó copiada una URI: páginas ajenas, favoritos, apuntes personales. El editor tiene una vista completa de la reforma, pero los afectados están dispersos. Esa asimetría explica por qué dejar morir la dirección parece barato para quien toma la decisión.

Un nombre público atrapado en una clasificación privada

El problema va más allá de cgi-bin. Si se pone el nombre de un autor en el camino, otro responsable hereda una dirección ligada a su antecesor. Si se pone draft, la publicación final queda con un nombre viejo o necesita otro. Si se distingue entre acceso interno, de miembros y público en la URI, abrir el documento obliga a cambiar el camino. Una extensión como .html confunde la forma actual del archivo con la identidad del recurso. Un subdominio dedicado a una función temporal traslada al nombre público una división administrativa. Berners-Lee enumeró esas piezas porque todas cambian antes que el interés de alguien por el documento.

La fecha de creación ofrece una salida parcial: una publicación de 1998 seguirá siendo de 1998. Para una página cuyo propósito sea mostrar siempre la edición actual, una dirección latest puede nombrar esa función cambiante. La diferencia es qué se prometió. Un informe fechado y «la edición de hoy» no son el mismo objeto. Mantener el nombre correcto requiere decidirlo al publicar y permitir que el servidor ajuste los archivos, no convertir cada nueva versión en una excusa para borrar lo que otros ya citaron.

Clasificar por tema parecía especialmente tentador. Ordenar el sitio ayuda a los visitantes y a los empleados, pero las categorías se discuten y se renombran. Berners-Lee recordó que el propio W3C había cambiado su vocabulario de «MarkUp» hacia «HTML». Un documento puede pasar de una sección a otra aunque su identidad permanezca. Cuando la categoría se incrusta en la URI, el editor debe elegir entre conservar un camino semánticamente anticuado o romper las citas. Es la organización de hoy haciendo una promesa que quizá no podrá sostener mañana.

Una palabra más solemne no mantiene el servidor

La idea de que los Uniform Resource Names resolverían la permanencia servía a veces como excusa para abandonar las URL antiguas. Berners-Lee replicó que una organización capaz de mantener un nombre persistente también podía conservar una URI HTTP. En ambos casos hacen falta autoridad sobre el nombre, un registro que lo relacione con el recurso actual y trabajo para que la respuesta siga llegando. Llamarlo «nombre» no paga a la persona que conserva el archivo ni escribe la regla del servidor.

El ensayo reconocía un obstáculo práctico: las herramientas de publicación corrientes no llevaban por sí solas un registro de identificadores, versiones, traducciones y sumas de comprobación. Ni todas las páginas del W3C cumplían el ideal. Esa admisión convertía el consejo en una exigencia de producto. El editor necesita herramientas que permitan cambiar responsables, permisos y ubicación sin cambiar el nombre que ya circula. De lo contrario, cada equipo tendrá un incentivo para simplificar su migración y trasladar la reparación a los demás.

La Recomendación de arquitectura web de W3C de 2004 dio forma institucional al mismo punto. La persistencia depende de la política y el compromiso de quien posee la URI. Elegir un esquema de identificadores no la garantiza. Respuestas coherentes y redirecciones HTTP pueden sostenerla cuando una representación o una ubicación cambian. El responsable sigue siendo el editor que emitió la dirección.