Localizador uniforme de recursos persistente

Un localizador uniforme de recursos persistente ( PURL ) es un localizador uniforme de recursos (URL, es decir, un identificador uniforme de recursos , o URI, que se basa en la ubicación) que se utiliza para redirigir a la ubicación del recurso web solicitado . Los PURL redirigen a los clientes HTTP utilizando códigos de estado HTTP .

Originalmente, las PURL se reconocían por estar alojadas en purl.org u otros nombres de host que contenían purl. Al principio, muchos de esos otros hosts usaban descendientes del software del sistema PURL original de OCLC. Sin embargo, con el tiempo, el concepto de PURL se volvió genérico y se usó para designar cualquier servicio de redirección (llamado resolvedor de PURL ) que: ^{[ 1 ]}

• tiene una "URL raíz" como referencia del resolvedor (por ejemplo http://myPurlResolver.example);
• proporciona a su comunidad de usuarios los medios para incluir nuevos nombres en la URL raíz (por ejemplo http://myPurlResolver.example/name22);
• Proporciona los medios para asociar cada nombre con su URL (a la que se redirigirá) y para actualizar esta URL de redirección;
• garantizar la persistencia (por ejemplo, mediante contrato) de la URL raíz y de los servicios de resolución de PURL .

Las PURL se utilizan para gestionar el proceso de resolución de URL, solucionando así el problema de las URI transitorias en esquemas de URI basados ​​en la ubicación, como HTTP. Técnicamente, la resolución de cadenas en una PURL es similar a la resolución de URL SEF . El resto de este artículo trata sobre el sistema PURL de OCLC, propuesto e implementado por OCLC (Online Computer Library Center).

El concepto PURL fue desarrollado por Stuart Weibel y Erik Jul en OCLC en 1995. ^{[ 2 ]} El sistema PURL se implementó utilizando una versión anterior a la 1.0 de Apache HTTP Server . El software fue modernizado y ampliado en 2007 por Zepheira bajo contrato con OCLC y el sitio web oficial se trasladó a purlz.org(la 'Z' provenía del nombre de Zepheira y se utilizó para diferenciar el sitio de software de código abierto PURL del resolvedor PURL operado por OCLC).

Los números de versión de PURL pueden resultar confusos. OCLC publicó las versiones 1 y 2 del árbol de código fuente basado en Apache, inicialmente en 1999 bajo la Licencia Pública de Investigación OCLC 1.0 y posteriormente bajo la Licencia Pública de Investigación OCLC 2.0. ^{[ 3 ]} Zepheira publicó PURLz 1.0 en 2007 bajo la Licencia Apache , versión 2.0. ^{[ 4 ]} PURLz 2.0 se lanzó en fase beta en 2010, pero nunca se finalizó. El Proyecto Callimachus implementó PURLs a partir de su versión 1.0 en 2012.

El resolvedor HTTP PURL más antiguo fue operado por OCLC desde 1995 hasta septiembre de 2016 y se accedió a él purl.oclc.orgcomo purl.org, purl.net, y purl.com.

Otros resolvedores PURL notables incluyen la Oficina de Imprenta del Gobierno de los Estados Unidos ( purl.fdlp.gov), que opera para el Programa Federal de Bibliotecas Depositarias y ha estado en funcionamiento desde 1997.

El concepto PURL se utiliza en el w3id.org, que puede reemplazar los antiguos servicios y tecnologías PURL.

El 27 de septiembre de 2016, OCLC anunció una cooperación con Internet Archive que resultó en la transferencia del servicio de resolución y su interfaz de administración a Internet Archive. ^{[ 5 ]} El servicio es compatible con un software de nueva creación, independiente de todas las implementaciones anteriores. La transferencia reactivó la capacidad de administrar definiciones PURL que habían estado deshabilitadas en el servicio alojado por OCLC durante varios meses. El servicio alojado en los servidores de Internet Archive admite el acceso a través de purl.org, purl.net, purl.info, y purl.com. OCLC ahora redirige las solicitudes DNS para purl.oclc.orga purl.org.

El concepto PURL permite la gestión generalizada de URL de URI HTTP en la World Wide Web . Las PURL permiten que terceros controlen tanto la resolución de URL como el suministro de metadatos de recursos.

Una URL es simplemente la dirección de un recurso en la World Wide Web. Una URL persistente es una dirección en la World Wide Web que provoca una redirección a otro recurso web. Si un recurso web cambia de ubicación (y, por lo tanto, de URL), se puede actualizar una PURL que apunte a él. Un usuario de una PURL siempre utiliza la misma dirección web, aunque el recurso en cuestión se haya movido. Las PURL pueden ser utilizadas por los editores para gestionar su propio espacio de información o por los usuarios web para gestionar el suyo; un servicio de PURL es independiente del editor de la información. Los servicios de PURL permiten, por lo tanto, gestionar la integridad de los hipervínculos. La integridad de los hipervínculos es una limitación del diseño de la World Wide Web, pero puede restaurarse parcialmente permitiendo que los usuarios de recursos o terceros influyan en dónde y cómo se resuelve una URL.

Una PURL simple funciona respondiendo a una solicitud HTTP GET devolviendo una respuesta de tipo 302 (equivalente al código de estado HTTP 302, que significa " Encontrado "). La respuesta contiene un encabezado HTTP Location , cuyo valor es una URL que el cliente debe recuperar posteriormente mediante una nueva solicitud HTTP GET.

Las PURL implementan una forma de identificador persistente para recursos virtuales. Otros esquemas de identificadores persistentes incluyen los Identificadores de Objetos Digitales (DOI), los Identificadores de Ciencias de la Vida (LSID) y las URI INFO . Todos los esquemas de identificación persistente proporcionan identificadores únicos para recursos virtuales (que pueden cambiar), pero no todos ofrecen oportunidades de curación. La curación de recursos virtuales se ha definido como "la participación activa de profesionales de la información en la gestión, incluida la preservación, de datos digitales para su uso futuro". ^{[ 6 ]}

Las PURL han sido criticadas por su necesidad de resolver una URL, lo que las vincula a una ubicación de red. Las ubicaciones de red presentan varias vulnerabilidades, como los registros del Sistema de Nombres de Dominio (DNS) y las dependencias de host. Un fallo en la resolución de una PURL podría generar una situación ambigua: no estaría claro si la PURL no se resolvió debido a un fallo de red o porque simplemente no existía. ^{[ 7 ]}

Las PURL son URL válidas, por lo que sus componentes deben ajustarse a la especificación de URL. La parte del esquema indica a un programa informático , como un navegador web, qué protocolo utilizar para resolver la dirección. El esquema utilizado para las PURL suele ser HTTP. La parte del host indica a qué servidor PURL conectarse. La siguiente parte, el dominio PURL, es análoga a una ruta de recurso en una URL. El dominio es un espacio de información jerárquico que separa las PURL y permite que tengan diferentes administradores. Uno o más administradores designados pueden gestionar cada dominio PURL. Finalmente, el nombre PURL es el nombre de la PURL en sí. El dominio y el nombre juntos constituyen el ID de la PURL .

Tanto el enlace permanente (permalink) como la URL permanente (PURL) se utilizan como URL permanentes/persistentes y redirigen a la ubicación del recurso web solicitado . En términos generales, son lo mismo. Sus diferencias radican en el nombre de dominio y la escala de tiempo .

• Un enlace permanente normalmente no cambia el dominio de la URL y está diseñado para perdurar durante años .
• Un nombre de dominio PURL se puede cambiar de forma independiente y está diseñado para perdurar durante décadas .

Los tipos más comunes de PURL se nombran de acuerdo con el código de respuesta HTTP que devuelven. No todos los códigos de respuesta HTTP tienen tipos de PURL equivalentes, y no todos los servidores de PURL implementan todos los tipos de PURL. Algunos códigos de respuesta HTTP (por ejemplo, 401, no autorizado ) tienen significados claros en el contexto de una conversación HTTP, pero no se aplican al proceso de redirección HTTP. Tres tipos adicionales de PURL ( cadena , parcial y clon ) reciben nombres mnemotécnicos relacionados con sus funciones.

La mayoría de las PURL son las llamadas PURL simples , que proporcionan una redirección al recurso deseado. El código de estado HTTP, y por lo tanto el tipo de PURL, de una PURL simple es 302. El propósito de una PURL 302 es informar al cliente web y al usuario final que la PURL siempre debe usarse para acceder al recurso solicitado, no a la URI final resuelta. Esto permite que el recurso siga resolviéndose si la PURL cambia. Algunos operadores prefieren usar PURL de tipo 301 (que indican que se debe acceder a la URI final en futuras solicitudes).

Una PURL de tipo cadena permite que una PURL redirija a otra PURL de forma idéntica a una redirección 301 o 302, con la diferencia de que un servidor PURL gestiona la redirección internamente para una mayor eficiencia. Esta eficiencia resulta útil cuando son posibles muchas redirecciones, ya que algunos navegadores web dejan de seguirlas una vez que alcanzan un límite establecido (para evitar bucles).

Una PURL de tipo 200 es una PURL activa , en la que la PURL participa activamente en la creación o agregación de los metadatos devueltos. Una PURL activa incluye algún cálculo arbitrario para producir su salida. Las PURL activas se han implementado en PURLz 2.0 y en el Proyecto Callimachus . Se pueden utilizar para recopilar informes de estado en tiempo de ejecución, realizar consultas distribuidas o cualquier otro tipo de recopilación de datos donde se desee un identificador persistente. Las PURL activas funcionan de forma similar a un procedimiento almacenado en bases de datos relacionales. ^{[ 8 ]}

Una PURL de tipo 303 se utiliza para dirigir a un cliente web a un recurso que proporciona información adicional sobre el recurso solicitado, sin devolver el recurso en sí. Esta sutileza resulta útil cuando la URI HTTP solicitada se utiliza como identificador de un objeto físico o conceptual que no puede representarse como un recurso de información. Las PURL de tipo 303 se utilizan con mayor frecuencia para redirigir a metadatos en un formato de serialización del Resource Description Framework (RDF) y son relevantes para la Web Semántica y el contenido de datos enlazados . Este uso del código de estado HTTP 303 cumple con el hallazgo http-range-14 del Technical Architecture Group del World Wide Web Consortium . ^{[ 9 ]}

Una PURL de tipo 307 informa al usuario que el recurso reside temporalmente en una URL diferente a la habitual. Las PURL de tipo 404 y 410 indican que no se pudo encontrar el recurso solicitado y sugieren información sobre el motivo. Se incluye compatibilidad con los códigos de respuesta HTTP 307 (Redirección temporal), 404 (No encontrado) y 410 (Desaparecido) para mayor exhaustividad.

Las PURL de tipo 404 y 410 se proporcionan para ayudar a los administradores a marcar las PURL que requieren reparación. Estas PURL permiten indicar de forma más eficiente los fallos en la identificación de recursos cuando los recursos de destino se han movido y no se ha encontrado un reemplazo adecuado.

Las PURL de tipo clon se utilizan únicamente durante la administración de PURL como un método conveniente para copiar un registro PURL existente en una nueva PURL.

El servicio PURL incluye un concepto conocido como redirección parcial. Si una solicitud no coincide exactamente con una PURL, se comprueba la URL solicitada para determinar si alguna parte contigua de la cadena PURL coincide con una PURL registrada. Si es así, se produce una redirección y el resto de la URL solicitada se añade a la URL de destino. Por ejemplo, considere una PURL con una http://purl.org/some/path/URL de destino de http://example.com/another/path/. Un intento de realizar una operación HTTP GET en la URL http://purl.org/some/path/and/some/more/datadaría como resultado una redirección parcial a http://example.com/another/path/and/some/more/data. El concepto de redirección parcial permite acceder a jerarquías de recursos web mediante PURL sin que cada recurso requiera su propia PURL. Una PURL es suficiente para servir como nodo de nivel superior para una jerarquía en un único servidor de destino. El nuevo servicio PURL utiliza el tipo parcial para denotar una PURL que realiza una redirección parcial.

Las redirecciones parciales a nivel de ruta URL no infringen las interpretaciones comunes de la especificación HTTP 1.1. Sin embargo, el manejo de fragmentos URL en las redirecciones no se ha estandarizado y aún no se ha alcanzado un consenso. Los identificadores de fragmento indican un puntero a información más específica dentro de un recurso y se designan después de un #separador en las URI. ^{[ 10 ]}

La redirección parcial en presencia de un identificador de fragmento es problemática porque son posibles dos interpretaciones conflictivas. ^{[ 11 ]} Si un fragmento se adjunta a una PURL de tipo parcial , no está claro si un servicio PURL debe asumir que el fragmento tiene significado en la URL de destino, o descartarlo bajo la suposición de que un recurso con una ubicación cambiada también puede haber cambiado el contenido, invalidando así los fragmentos definidos anteriormente. Bos sugirió que los fragmentos deberían conservarse y pasarse a las URL de destino durante las redirecciones HTTP que resultan en respuestas 300 (Opción múltiple), 301 (Movido permanentemente), 302 (Encontrado) o 303 (Ver otro) a menos que una URL de destino designada ya incluya un identificador de fragmento. Si un identificador de fragmento ya está presente en una URL de destino, cualquier fragmento en la URL original debería descartarse. La sugerencia de Bos no logró avanzar en la vía de estándares de la IETF y expiró sin más trabajo. Dubost et al. resucitaron las sugerencias de Bos en una Nota del W3C (no un estándar, sino una guía en ausencia de un estándar). ^{[ 12 ]} Los fabricantes de clientes web, como los navegadores, "generalmente" ^{[ 12 ]} no han seguido las directrices de Bos.

A partir de la serie PURLz 1.0, el servicio PURL implementa redirecciones parciales que incluyen identificadores de fragmentos escribiendo fragmentos en las URL de destino en un intento de cumplir con ^{[ 12 ]} y evitar comportamientos problemáticos e inconsistentes por parte de los proveedores de navegadores.

• Ejemplos de implementación:
  • Clave de recurso de archivo (ARK)
  • Identificador de Objeto Digital (DOI)
  • Identificadores del sistema de manejo
• Enlace roto
• OPAC
• Enlace permanente
• Redirección de URL
• acortamiento de URL
• Nombre uniforme de recursos (URN)
• Máquina del tiempo

• Sitio web oficial de PURLz
• Sitio web oficial del Proyecto Calímaco
• Resolutor de PURL de Internet Archive
• Resolutor de PURL de la Oficina de Imprenta del Gobierno de EE. UU.
• identificador-persistente.de
• Sitio de información y resolución de DPE/PURL