Localizzatore di risorse uniforme permanente - Persistent uniform resource locator

Un Uniform Resource Locator ( PURL ) persistente è un URL ( Uniform Resource Locator ) (cioè un identificatore di risorsa uniforme basato sulla posizione o URI) che viene utilizzato per reindirizzare alla posizione della risorsa web richiesta . I PURL reindirizzano i client HTTP utilizzando i codici di stato HTTP .

In origine, i PURL erano riconoscibili per essere ospitati su purl.org o altri nomi host contenenti purl. All'inizio molti di questi altri host utilizzavano discendenti del software di sistema OCLC PURL originale. Alla fine, tuttavia, il concetto di PURL è diventato generico ed è stato utilizzato per designare qualsiasi servizio di reindirizzamento (denominato PURL resolver ) che:

  • ha un "URL radice" come riferimento del risolutore (es. http://myPurlResolver.example);
  • fornisce mezzi, alla sua comunità di utenti, per includere nuovi nomi nell'URL radice (es. http://myPurlResolver.example/name22);
  • fornisce mezzi per associare ogni nome al suo URL (da reindirizzare) e per aggiornare questo URL di reindirizzamento;
  • garantire la persistenza (ad es. per contratto) dell'URL radice e dei servizi di risoluzione PURL .

I PURL vengono utilizzati per curare il processo di risoluzione degli URL, risolvendo così il problema degli URI transitori negli schemi URI basati sulla posizione come HTTP. Tecnicamente la risoluzione della stringa su PURL è come la risoluzione dell'URL SEF . Il resto di questo articolo è di circa il sistema PURL del OCLC, proposto e attuato da OCLC (Library Online Computer Center).

Storia

Il concetto di PURL è stato sviluppato presso l' OCLC nel 1995 e il sistema PURL è stato implementato utilizzando una versione biforcuta precedente alla 1.0 di Apache HTTP Server . Il software è stato modernizzato ed esteso nel 2007 da Zepheira sotto contratto con OCLC e il sito Web ufficiale è stato spostato su http://purlz.org (la "Z" deriva dal nome Zepheira ed è stata utilizzata per differenziare il sito del software open source PURL da il resolver PURL gestito da OCLC).

I numeri di versione di PURL possono essere considerati confusi. OCLC ha rilasciato le versioni 1 e 2 dell'albero dei sorgenti basato su Apache, inizialmente nel 1999 con la licenza OCLC Research Public License 1.0 e successivamente con la licenza OCLC Research Public License 2.0 ( http://opensource.org/licenses/oclc2 ). Zepheira ha rilasciato PURLz 1.0 nel 2007 con la licenza Apache, versione 2.0 . PURLz 2.0 è stato rilasciato in beta testing nel 2010 ma il rilascio non è mai stato finalizzato. Il progetto Callimachus ha implementato i PURL a partire dalla sua versione 1.0 nel 2012.

Il più vecchio risolutore HTTP PURL è stato gestito da OCLC dal 1995 a settembre 2016 ed è stato raggiunto come purl.oclc.org e purl.org , purl.net e purl.com .

Altri notevoli risolutori PURL includono il Government Printing Office degli Stati Uniti ( http://purl.fdlp.gov ), che è gestito per il Federal Depository Library Program ed è operativo dal 1997.

Il concetto PURL è utilizzato in w3id.org , che potrebbe sostituire i vecchi servizi PURL e le tecnologie PURL.

Il 27 settembre 2016 OCLC ha annunciato una collaborazione con Internet Archive che ha portato al trasferimento del servizio resolver e della sua interfaccia di amministrazione a Internet Archive. Il servizio è supportato su software di nuova creazione, separato da tutte le precedenti implementazioni. Il trasferimento ha riabilitato la capacità di gestire le definizioni PURL che erano state disabilitate nel servizio ospitato da OCLC per diversi mesi. Il servizio ospitato sui server di Internet Archive supporta l'accesso tramite purl.org , purl.net , purl.info e purl.com . OCLC ora reindirizza le richieste DNS per purl.oclc.org a purl.org .

Principi di funzionamento

Il concetto PURL consente la gestione URL generalizzata degli URI HTTP sul World Wide Web . I PURL consentono il controllo di terze parti sia sulla risoluzione degli URL che sulla fornitura dei metadati delle risorse.

Un URL è semplicemente un indirizzo di una risorsa sul World Wide Web. Un URL persistente è un indirizzo sul World Wide Web che provoca un reindirizzamento a un'altra risorsa Web. Se una risorsa Web cambia posizione (e quindi URL), è possibile aggiornare un PURL che punta ad essa. Un utente di un PURL utilizza sempre lo stesso indirizzo Web, anche se la risorsa in questione potrebbe essere stata spostata. I PURL possono essere utilizzati dagli editori per gestire il proprio spazio informativo o dagli utenti Web per gestire il proprio; un servizio PURL è indipendente dall'editore delle informazioni. I servizi PURL consentono quindi la gestione dell'integrità del collegamento ipertestuale. L'integrità dei collegamenti ipertestuali è un compromesso di progettazione del World Wide Web, ma può essere parzialmente ripristinata consentendo agli utenti delle risorse oa terzi di influenzare dove e come si risolve un URL.

Un semplice PURL funziona rispondendo a una richiesta HTTP GET restituendo una risposta di tipo 302 (equivalente al codice di stato HTTP 302, che significa "Trovato"). La risposta contiene un'intestazione HTTP "Location", il cui valore è un URL che il client deve successivamente recuperare tramite una nuova richiesta HTTP GET.

I PURL implementano una forma di identificatore persistente per le risorse virtuali. Altri schemi di identificatori persistenti includono Digital Object Identifier (DOI), Life Sciences Identifier (LSID) e INFO URI . Tutti gli schemi di identificazione persistente forniscono identificatori univoci per le risorse virtuali (eventualmente modificabili), ma non tutti gli schemi forniscono opportunità di cura. La cura delle risorse virtuali è stata definita come "il coinvolgimento attivo di professionisti dell'informazione nella gestione, inclusa la conservazione, dei dati digitali per un uso futuro".

I PURL sono stati criticati per la loro necessità di risolvere un URL, collegando così un PURL a un percorso di rete. I percorsi di rete presentano diverse vulnerabilità, come le registrazioni del Domain Name System e le dipendenze dell'host. Un errore nella risoluzione di un PURL potrebbe portare a uno stato ambiguo: non sarebbe chiaro se il PURL non sia stato risolto perché un errore di rete lo ha impedito o perché non esisteva.

I PURL sono essi stessi URL validi, quindi i loro componenti devono essere mappati alla specifica dell'URL. La parte dello schema indica a un programma per computer, ad esempio un browser Web, quale protocollo utilizzare per risolvere l'indirizzo. Lo schema utilizzato per i PURL è generalmente HTTP. La parte host indica a quale server PURL connettersi. La parte successiva, il dominio PURL, è analogo al percorso di una risorsa in un URL. Il dominio è uno spazio di informazioni gerarchico che separa i PURL e consente ai PURL di avere manutentori diversi. Uno o più manutentori designati possono amministrare ciascun dominio PURL. Infine, il nome PURL è il nome del PURL stesso. Il dominio e il nome insieme costituiscono l'"id" del PURL.

Confronto con permalink

Sia il permalink che il PURL vengono utilizzati come URL permanente/persistente e reindirizzano alla posizione della risorsa Web richiesta . In parole povere, sono la stessa cosa. Le loro differenze riguardano il nome di dominio e la scala temporale :

  • Un permalink di solito non cambia il dominio dell'URL ed è progettato per durare negli anni .
  • Un nome di dominio PURL è modificabile in modo indipendente ed è progettato per durare per decenni .

tipi

I tipi più comuni di PURL sono denominati in modo che coincidano con il codice di risposta HTTP che restituiscono. Non tutti i codici di risposta HTTP hanno tipi PURL equivalenti e non tutti i server PURL implementano tutti i tipi PURL. Alcuni codici di risposta HTTP (ad es. 401, Non autorizzato) hanno significati chiari nel contesto di una conversazione HTTP ma non si applicano al processo di reindirizzamento HTTP. A tre tipi aggiuntivi di PURL ("catena", "parziale" e "clone") vengono dati nomi mnemonici relativi alle loro funzioni.

Tipi di PURL
genere PURL significato significato HTTP
200 Contenuti creati o aggregati ok
301 Spostato in modo permanente a un URL di destinazione Trasferito
302 Reindirizzamento semplice a un URL di destinazione Trovato
Catena Reindirizza a un altro PURL all'interno dello stesso server Trovato
Parziale Reindirizza a un URL di destinazione con le informazioni sul percorso finale aggiunte Trovato
303 Vedi altri URL Vedi altro
307 Reindirizzamento temporaneo a un URL di destinazione Reindirizzamento temporaneo
404 Temporaneamente andato Non trovato
410 definitivamente andato Andato
Clone Copia gli attributi di un PURL esistente N / A

La maggior parte dei PURL sono i cosiddetti "PURL semplici", che forniscono un reindirizzamento alla risorsa desiderata. Il codice di stato HTTP, e quindi del tipo PURL, di un PURL semplice è 302. Lo scopo di un PURL 302 è informare il client Web e l' utente finale che il PURL deve essere sempre utilizzato per indirizzare la risorsa richiesta, non il finale URI risolto. Questo per consentire la risoluzione continua della risorsa se il PURL cambia. Alcuni operatori preferiscono utilizzare PURL di tipo 301 (che indica che l'URI finale dovrebbe essere indirizzato nelle richieste future).

Un PURL di tipo "chain" consente a un PURL di reindirizzare a un altro PURL in modo identico a un reindirizzamento 301 o 302, con la differenza che un server PURL gestirà il reindirizzamento internamente per una maggiore efficienza. Questa efficienza è utile quando sono possibili molti reindirizzamenti; poiché alcuni browser Web smetteranno di seguire i reindirizzamenti una volta incontrato un limite impostato (nel tentativo di evitare i loop).

Un PURL di tipo "200" è un "PURL attivo", in cui il PURL partecipa attivamente alla creazione o all'aggregazione dei metadati restituiti. Un PURL attivo include alcuni calcoli arbitrari per produrre il suo output. I PURL attivi sono stati implementati in PURLz 2.0 e The Callimachus Project . Possono essere utilizzati per raccogliere rapporti sullo stato di runtime, eseguire query distribuite o qualsiasi altro tipo di raccolta dati in cui si desidera un identificatore persistente. I PURL attivi agiscono in modo simile a una stored procedure nei database relazionali.

Un PURL di tipo "303" viene utilizzato per indirizzare un client Web a una risorsa che fornisce informazioni aggiuntive sulla risorsa richiesta, senza restituire la risorsa stessa. Questa sottigliezza è utile quando l'URI HTTP richiesto viene utilizzato come identificatore per un oggetto fisico o concettuale che non può essere rappresentato come una risorsa informativa. I PURL di tipo 303 vengono utilizzati più spesso per reindirizzare ai metadati in un formato di serializzazione del Resource Description Framework (RDF) e hanno rilevanza per il Web semantico e il contenuto dei dati collegati . Questo uso del codice di stato HTTP 303 è conforme alla scoperta http-range-14 del Technical Architecture Group del World Wide Web Consortium .

Un PURL di tipo "307" informa un utente che la risorsa risiede temporaneamente su un URL diverso dalla norma. I PURL di tipo 404 e 410 rilevano che la risorsa richiesta non è stata trovata e suggeriscono alcune informazioni sul motivo per cui è stato così. Per completezza, viene fornito il supporto per i codici di risposta HTTP 307 (reindirizzamento temporaneo), 404 (non trovato) e 410 (non trovato).

I PURL di tipo "404" e "410" vengono forniti per aiutare gli amministratori a contrassegnare i PURL che richiedono una riparazione. I PURL di questi tipi consentono indicazioni più efficienti dell'errore di identificazione delle risorse quando le risorse di destinazione sono state spostate e non è stata identificata una sostituzione adeguata.

I PURL di tipo "clone" vengono utilizzati esclusivamente durante l'amministrazione PURL come metodo conveniente per copiare un record PURL esistente in un nuovo PURL.

Reindirizzamento di frammenti di URL

Il servizio PURL include un concetto noto come reindirizzamento parziale. Se una richiesta non corrisponde esattamente a un PURL, l'URL richiesto viene controllato per determinare se una parte anteriore contigua della stringa PURL corrisponde a un PURL registrato. In tal caso, si verifica un reindirizzamento con il resto dell'URL richiesto aggiunto all'URL di destinazione. Ad esempio, considera un PURL con un URL di http//purl.org/some/path/ con un URL di destinazione di http://example.com/another/path/. Un tentativo di eseguire un'operazione HTTP GET sull'URL http//purl.org/some/path/and/some/more/data comporterebbe un reindirizzamento parziale a http://example.com/another/path/and/ alcuni/più/dati. Il concetto di reindirizzamento parziale consente di indirizzare le gerarchie di risorse basate sul Web tramite PURL senza che ciascuna risorsa richieda il proprio PURL. Un PURL è sufficiente per fungere da nodo di primo livello per una gerarchia su un singolo server di destinazione. Il nuovo servizio PURL utilizza il tipo "parziale" per indicare un PURL che esegue il reindirizzamento parziale.

I reindirizzamenti parziali a livello di un percorso URL non violano le interpretazioni comuni della specifica HTTP 1.1. Tuttavia, la gestione dei frammenti di URL attraverso i reindirizzamenti non è stata standardizzata e non è ancora emerso un consenso. Gli identificatori di frammento indicano un puntatore a informazioni più specifiche all'interno di una risorsa e sono designati come segue un separatore # negli URI.

Il reindirizzamento parziale in presenza di un identificatore di frammento è problematico perché sono possibili due interpretazioni contrastanti. Se un frammento è allegato a un PURL di tipo "parziale", un servizio PURL dovrebbe presumere che il frammento abbia un significato sull'URL di destinazione o dovrebbe scartarlo nella presunzione che una risorsa con una posizione modificata possa aver modificato anche il contenuto, quindi invalidare i frammenti definiti in precedenza? Bos ha suggerito che i frammenti dovrebbero essere conservati e passati agli URL di destinazione durante i reindirizzamenti HTTP con conseguente risposta 300 (Scelta multipla), 301 (Spostato in modo permanente), 302 (Trovato) o 303 (Vedi altro) a meno che un URL di destinazione designato non includa già un frammento identificatore. Se un identificatore di frammento è già presente in un URL di destinazione, qualsiasi frammento nell'URL originale dovrebbe essere abbandonato. Sfortunatamente, il suggerimento di Bos non è riuscito a navigare nella traccia degli standard IETF ed è scaduto senza ulteriori lavori. Dubost et al. ha resuscitato i suggerimenti di Bos in una nota del W3C (non uno standard, ma una guida in assenza di uno standard). I produttori di client Web come i browser "generalmente" non sono riusciti a seguire la guida di Bos.

A partire dalla serie PURLz 1.0, il servizio PURL implementa reindirizzamenti parziali comprensivi di identificatori di frammento scrivendo frammenti sugli URL di destinazione nel tentativo di rispettare ed evitare comportamenti problematici e incoerenti da parte dei fornitori di browser.

Guarda anche

Riferimenti

link esterno