Un localizador uniforme de recursos persistente ( PURL ) es un localizador uniforme de recursos (URL) (es decir, identificador uniforme de recursos basado en la ubicación o URI) que se utiliza para redirigir a la ubicación del recurso web solicitado . Los PURL redirigen a los clientes HTTP mediante códigos de estado HTTP .
Originalmente, los PURL eran reconocibles por estar alojados 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 PURL se volvió genérico y se usó para designar cualquier servicio de redirección (denominado resolver PURL ) que: [1]
http://myPurlResolver.example (por ejemplo );http://myPurlResolver.example/name22);Las PURL se utilizan para controlar el proceso de resolución de URL, lo que resuelve 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 PURL es como la resolución de URL SEF . El resto de este artículo trata sobre el sistema PURL de OCLC, propuesto e implementado por OCLC (el Centro de Bibliotecas Informáticas en Línea).
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 bifurcada 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 http://purlz.org (la "Z" proviene del nombre Zepheira y se utilizó para diferenciar el sitio de software de código abierto PURL del solucionador 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 fuentes basado en Apache, inicialmente en 1999 bajo la Licencia Pública de Investigación de OCLC 1.0 y luego bajo la Licencia Pública de Investigación de OCLC 2.0 (http://opensource.org/licenses/oclc2). Zepheira publicó PURLz 1.0 en 2007 bajo la Licencia Apache, Versión 2.0. PURLz 2.0 se publicó en pruebas Beta en 2010, pero el lanzamiento nunca se finalizó. El Proyecto Callimachus implementó PURLs a partir de su lanzamiento 1.0 en 2012.
El solucionador HTTP PURL más antiguo fue operado por OCLC desde 1995 hasta septiembre de 2016 y se alcanzó como purl.oclc.orgasí como purl.org, purl.net, y purl.com.
Otros solucionadores PURL notables incluyen la Oficina de Imprenta del Gobierno de los EE. UU. (http://purl.fdlp.gov), que opera para el Programa de Bibliotecas de Depósito Federal y ha estado en funcionamiento desde 1997.
El concepto PURL se utiliza en 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 dio como resultado la transferencia del servicio de resolución y su interfaz de administración a Internet Archive. [3] El servicio es compatible con software de nueva creación, independiente de todas las implementaciones anteriores. La transferencia volvió a habilitar la capacidad de administrar definiciones PURL que habían estado deshabilitadas en el servicio alojado en OCLC durante varios meses. El servicio alojado en servidores de Internet Archive admite el acceso a través de purl.org, purl.net, purl.infoy purl.com. OCLC ahora redirige las solicitudes de DNS para purl.oclc.orga purl.org.
El concepto PURL permite la curación generalizada de URL de URL HTTP en la World Wide Web . Las PURL permiten que terceros controlen tanto la resolución de URL como la provisión de metadatos de recursos.
Una URL es simplemente una 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 lo apunte. 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 PURL es independiente del editor de la información. Por tanto, los servicios PURL permiten la gestión de la integridad de los hipervínculos. La integridad de los hipervínculos es una compensación de diseño de la World Wide Web, pero se puede restaurar parcialmente permitiendo que los usuarios de los recursos o terceros influyan en dónde y cómo se resuelve una URL.
Un 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 "Ubicación", cuyo valor es una URL que el cliente debe recuperar posteriormente a través de una nueva solicitud HTTP GET.
Los 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 biológicas (LSID) y los URI de información . Todos los esquemas de identificación persistente proporcionan identificadores únicos para recursos virtuales (posiblemente cambiantes), pero no todos los esquemas proporcionan oportunidades de conservación. La conservación de recursos virtuales se ha definido como "la participación activa de los profesionales de la información en la gestión, incluida la preservación, de datos digitales para uso futuro". [4]
Las PURL han sido criticadas por su necesidad de resolver una URL, vinculando así una PURL a una ubicación de red. Las ubicaciones de red tienen varias vulnerabilidades, como los registros del Sistema de nombres de dominio y las dependencias del host. Un fallo en la resolución de una PURL podría llevar a un estado ambiguo: no estaría claro si la PURL no se resolvió porque una falla de red lo impidió o porque no existía. [5]
Las PURL son en sí mismas URL válidas, por lo que sus componentes deben corresponderse con la especificación de la URL. La parte del esquema le dice a un programa de computadora, como un navegador web, qué protocolo usar para resolver la dirección. El esquema usado para las PURL es generalmente HTTP. La parte del host le dice a qué servidor PURL conectarse. La siguiente parte, el dominio PURL, es análoga a una ruta de recursos en una URL. El dominio es un espacio de información jerárquico que separa las PURL y permite que estas tengan diferentes mantenedores. Uno o más mantenedores designados pueden administrar cada dominio PURL. Finalmente, el nombre PURL es el nombre de la propia PURL. El dominio y el nombre juntos constituyen el "id" de la PURL.
Tanto el permalink como el 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 están relacionadas con el nombre de dominio y la escala de tiempo :
Los tipos más comunes de PURL se nombran para que coincidan 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 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. A tres tipos adicionales de PURL ("cadena", "parcial" y "clon") se les asignan nombres mnemotécnicos relacionados con sus funciones.
La mayoría de las PURL son las denominadas "PURL simples", que proporcionan una redirección al recurso deseado. El código de estado HTTP, y por lo tanto del tipo PURL, de una PURL simple es 302. La intención de una PURL 302 es informar al cliente web y al usuario final que la PURL siempre debe utilizarse para direccionar el recurso solicitado, no la URI final resuelta. Esto es para permitir la resolución continua del recurso si la PURL cambia. Algunos operadores prefieren utilizar PURL de tipo 301 (lo que indica que la URI final debe ser la dirección 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 gestionará la redirección internamente para lograr una mayor eficiencia. Esta eficiencia es útil cuando son posibles muchas redirecciones, ya que algunos navegadores web dejarán de seguir las redirecciones una vez que se alcance un límite establecido (en un intento de evitar bucles).
Un PURL de tipo "200" es un "PURL activo", en el que el PURL participa activamente en la creación o agregación de los metadatos devueltos. Un PURL activo incluye algún cálculo arbitrario para producir su salida. Los PURL activos se han implementado en PURLz 2.0 y The Callimachus Project. Se pueden utilizar para recopilar informes de estado de tiempo de ejecución, realizar consultas distribuidas o cualquier otro tipo de recopilación de datos donde se desee un identificador persistente. Los PURL activos actúan de forma similar a un procedimiento almacenado en bases de datos relacionales. [6]
Un 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 es útil cuando el URI HTTP solicitado se utiliza como un identificador para un objeto físico o conceptual que no se puede representar como un recurso de información. Los PURL de tipo 303 se utilizan con mayor frecuencia para redirigir a metadatos en un formato de serialización del Marco de descripción de recursos (RDF) y tienen relevancia para la Web semántica y el contenido de datos vinculados . Este uso del código de estado HTTP 303 es conforme con el hallazgo http-range-14 del Grupo de arquitectura técnica del Consorcio World Wide Web .
Una PURL de tipo "307" informa al usuario que el recurso reside temporalmente en una URL diferente a la normal. Las PURL de tipo 404 y 410 indican que no se pudo encontrar el recurso solicitado y sugieren información sobre el motivo. Para completar, se proporciona compatibilidad con los códigos de respuesta HTTP 307 (redirección temporal), 404 (no encontrado) y 410 (desaparecido).
Se proporcionan PURL de los tipos "404" y "410" para ayudar a los administradores a marcar los PURL que requieren reparación. Los PURL de estos tipos permiten indicar de manera más eficiente la falla en la identificación de recursos cuando los recursos de destino se han movido y no se ha identificado un reemplazo adecuado.
Los 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 un nuevo 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 frontal 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 URL de http//purl.org/some/path/ con una 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/data daría como resultado una redirección parcial a http://example.com/another/path/and/some/more/data. El concepto de redirección parcial permite que las jerarquías de recursos basados en la Web se direccionen a través de PURL sin que cada recurso requiera su propia PURL. Una PURL es suficiente para servir como un nodo de nivel superior para una jerarquía en un solo servidor de destino. El nuevo servicio PURL utiliza el tipo "parcial" para denotar un PURL que realiza una redirección parcial.
Las redirecciones parciales a nivel de una ruta URL no violan las interpretaciones comunes de la especificación HTTP 1.1. Sin embargo, el manejo de fragmentos de URL en redirecciones no se ha estandarizado y aún no ha surgido un consenso. Los identificadores de fragmentos indican un puntero a información más específica dentro de un recurso y se designan siguiendo un separador # en las URI. [7]
La redirección parcial en presencia de un identificador de fragmento es problemática porque son posibles dos interpretaciones conflictivas. [8] Si un fragmento está adjunto 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 en la presunción de que un recurso con una ubicación modificada 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 abandonarse. La sugerencia de Bos no logró navegar por la vía de los estándares de 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). [9] Los creadores de clientes web como navegadores "en general" [9] no han seguido la orientación de Bos.
A partir de la serie PURLz 1.0, el servicio PURL implementa redirecciones parciales que incluyen identificadores de fragmentos escribiendo fragmentos en URL de destino en un intento de cumplir con [9] y evitar un comportamiento problemático e inconsistente por parte de los proveedores de navegadores.
OCLC e Internet Archive anunciaron hoy los resultados de un esfuerzo cooperativo de un año de duración para garantizar la sostenibilidad futura de purl.org. Las organizaciones han trabajado juntas para crear un nuevo servicio sostenible alojado por Internet Archive que gestionará las URL persistentes y las redirecciones de subdominios para purl.org, purl.com, purl.info y purl.net.
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda )