World Wide Web, come sappiamo, è costituito da una collezione di documenti, ciascuno dei quali è formato da uno o più oggetti digitali archiviati, sotto forma di file, sugli host di Internet. Affinché tali oggetti siano individuabili e accessibili da un determinato user agent (di norma un browser) o da una applicazione server (ad esempio il modulo spider di un motore di ricerca), è necessario un adeguato sistema di identificazione e localizzazione delle risorse on-line, esattamente come i file archiviati nelle memorie di massa di un singolo computer sono gestiti dal file system del sistema operativo.
Di fatto tutti i protocolli in uso su Internet sono dotati di un qualche sistema interno per individuare e localizzare le risorse: in termini tecnici possiamo dire che ogni protocollo individua un insieme di oggetti che possono essere raggiunti associando loro un nome o un indirizzo. I nomi o indirizzi usati da un protocollo sono validi solo nell'ambito delle risorse accessibili mediante il protocollo stesso: tale ambito viene definito spazio dei nomi. Ogni protocollo dunque ha uno schema di denominazione che individua uno spazio dei nomi.
Se però, come avviene con il Web, un sistema può o deve accedere a risorse collocate in spazi diversi, si rende necessaria la creazione di uno spazio universale dei nomi e degli indirizzi, che permetta di identificare ogni risorsa astraendo dai requisiti tecnici di ogni singolo protocollo. Tanto più che tale spazio astratto dei nomi rimarrebbe valido anche nel caso in cui fosse modificato il modo in cui un protocollo accede alle risorse: basterebbe una modifica all'algoritmo che dal nome o indirizzo universale porta alla stringa di localizzazione effettiva del protocollo. Lo stesso potrebbe dirsi per la creazione di nuovi protocolli.
Un membro dell'insieme di nomi o indirizzi in tale spazio universale viene definito Universal Resource Identifier (URI). Ogni URI è suddivisa in due parti principali: uno specificatore di schema seguito da una stringa di identificazione dell'oggetto (path), la cui forma è determinata dallo schema (a sua volta funzione del protocollo cui è associato). Le due parti sono separate dal simbolo ':' (due punti):
schema : path.
Se lo schema individua uno spazio dei nomi o degli indirizzi organizzato gerarchicamente, esso può essere rappresentato da una serie di sottostringhe separate dal simbolo '/' (barra in avanti) il cui verso va da destra a sinistra. Alcuni schemi permettono di individuare anche parti di un oggetto. In tale caso la stringa che identifica tale parte (identificatore di frammento) viene posta alla estremità destra del path preceduta dal simbolo '#' (cancelletto).
Al momento l'unica forma di URI che viene effettivamente utilizzata è la Uniform Resource Locator (URL). Una URL è una forma di URI che esprime l'indirizzo (ovvero la collocazione reale) di un oggetto accessibile mediante uno dei protocolli attualmente in uso su Internet. Per risolvere una serie di problemi legati alla natura delle URL, da alcuni anni è in fase di sviluppo una nuova forma di URI, denominata Universal Resource Name (URN). Una URN, a differenza di una URL, esprime il nome di un oggetto in un dato spazio dei nomi indipendentemente dalla sua locazione fisica.
Uniform Resource Locator (URL)
Le Uniform Resource Locator (URL), come detto, sono un sottoinsieme del più generale insieme delle URI. Esse codificano formalmente l'indirizzo di ogni risorsa disponibile su Web in modo astratto dagli effettivi algoritmi di risoluzione implementati in ciascun protocollo. Allo stato attuale le URL sono l'unico sistema di identificazione e localizzazione delle risorse di rete effettivamente utilizzato, sebbene ciò determini una serie di problemi sui quali ci soffermeremo nel prossimo paragrafo.
La sintassi di una URL, basata naturalmente su quella delle URI, si articola in tre parti:
* identificatore dello schema di indirizzamento, seguito dal simbolo ':';
* identificatore dell'host sul quale risiede la risorsa, espresso mediante un nome di dominio o un indirizzo IP, e preceduto da due simboli '/' (barra in avanti); se necessario (e se lo schema lo permette) esso può essere preceduto da una coppia 'username' 'password' separata dal simbolo ':' (due punti) e seguita dal simbolo '@' (a commerciale); un altro elemento opzionale che può seguire l'identificatore è l'indicatore della porta preceduto dal simbolo ':';
* stringa di identificazione della risorsa sul server (path) preceduta dal simbolo '/'; la sua interpretazione dipende dallo schema di denominazione; il simbolo '/' viene utilizzato per denotare una struttura gerarchica, con la parte a sinistra indicante il livello superiore.
Di conseguenza una URL ha la seguente forma generale (le parti tra parentesi quadre sono opzionali):
Un esempio di URL per una risorsa Web, è il seguente:
http://www.liberliber.it/index.htm
Naturalmente ogni singolo schema di indirizzamento può presentare delle varianti a questa forma generale. Gli schemi registrati e attualmente implementati (corrispondenti ai vari protocolli in uso su Internet) sono i seguenti:
* http: per il protocollo HTTP
* ftp: per il File Transfer Protocol
* gopher: per il Gopher protocol
* mailto: per gli indirizzi di posta elettronica
* news: per i messaggi dei newsgruop NNTP
* wais: per i server WAIS
* file: per l'accesso a file locali
* telnet, rlogin, tn3270: per riferirsi a sessioni interattive in modalità terminale.
Per gli schemi http, ftp, file e gopher, la sezione del path di una URL ha una struttura gerarchica che corrisponde alla collocazione del file dell'oggetto referenziato nella porzione di file system visibile dal server. Ad ogni server infatti viene assegnato uno spazio sulla memoria di massa che inizia da una data directory (la root del server) e comprende tutte le sue sub-directory. La sezione del path di una URL seleziona la root del server mediante il primo simbolo '/' dopo l'indirizzo dell'host, e le successive subdirectory con i relativi nomi separati da simboli '/'.
Ad esempio, se la root di un server HTTP sul file system ha il path '/user/local/httpd/htdocs', la URL 'http://www.foo.it/personal/ciotti/index.html' si riferirà al file '/user/local/httpd/htdocs/personal/ciotti/index.html'. Con lo schema http è possibile usare delle URL relative, che vengono risolte estraendo le informazioni mancanti dalla URL del documento corrente.
Gli schemi 'mailto' e 'news' hanno una sintassi parzialmente diversa da quella generale che abbiamo visto sopra. Per la precisione una URL che si riferisce ad un indirizzo di posta elettronica si presenta in questa forma:
mailto:
Ad esempio:
mailto:
Lo schema per i messaggi su server NNTP ha invece la seguente sintassi:
news:nome_newsgroup[:numero_messaggio]
Ad esempio:
news:comp.text.xml:1223334
Si noti che a differenza degli altri schemi che indicano una locazione assoluta della risorsa, valida ovunque, lo schema news è indipendente dalla collocazione, poiché seleziona un messaggio che ogni client dovrà reperire dal suo server locale.
La sintassi delle URL può essere utilizzata sia nelle istruzioni ipertestuali dei file HTML, sia con i comandi che i singoli client, ciascuno a suo modo, mettono a disposizione per raggiungere un particolare server o documento. È bene pertanto che anche il normale utente della rete Internet impari a servirsene correttamente.
Uniform Resource Name
Une delle esperienze più comuni tra gli utilizzatori abituali di World Wide Web è la comparsa di un messaggio che annuncia l'impossibilità di accedere ad una data risorsa quando si attiva un link ipertestuale o si digita una URL nella barra degli indirizzi del browser. Che cosa è avvenuto?
Semplicemente che il file corrispondente non si trova più nella posizione indicata dal suo indirizzo. Che fine ha fatto? Può essere stato spostato, cancellato, rinominato. Il fatto è che i riferimenti in possesso dell'utente non gli permettono più di accedere al suo contenuto.
Un'esperienza simmetrica è la scoperta che il contenuto di un certo documento, di cui magari si era inserita la URL nell'elenco dei bookmark, è cambiato. Anche in questo caso la causa del problema è molto semplice: al file 'xyz.html', pur conservando lo stesso indirizzo, è stato cambiato il contenuto.
Alla radice di queste spiacevoli esperienze c'è uno dei limiti più importanti della attuale architettura di World Wide Web: il sistema di assegnazione dei nomi alle risorse informative sulla rete, e il modo in cui queste vengono localizzate. Come sappiamo, attualmente queste due funzioni sono svolte entrambe dalla URL di un documento. Il problema fondamentale è che la URL fornisce un ottimo sistema di indirizzamento (ovvero indica con molta efficienza la posizione di un oggetto sulla rete), ma un pessimo schema di assegnazione di nomi.
La fusione delle funzioni di indirizzamento e di identificazione delle risorse in una unica tecnologia si rivela un sistema inadeguato in molti altri settori. A titolo di esempio: introduce grossi problemi nello sviluppo di applicazioni di information retrieval sulla rete; rende molto difficile la citazione, il riferimento e la catalogazione bibliografica dei documenti presenti in rete; non permette lo sviluppo di sistemi di versioning, ovvero sistemi che tengano traccia dell'evoluzione dinamica di un documento, conservandone le versioni successive; complica la gestione del mirroring, ovvero la creazione e l'allineamento di molteplici esemplari di un medesimo documento.
Lo sviluppo di un efficiente sistema di distribuzione dell'informazione su rete geografica richiede dunque un potente e affidabile sistema di identificazione delle risorse informative. Per rispondere a questa esigenza, vari enti e organizzazioni che si occupano dello sviluppo degli standard su Internet hanno proposto la creazione di un nuovo tipo di URI, denominate Uniform Resource Name (URN). In realtà con questa sigla vengono indicate una serie di tecnologie, ancora in fase sperimentale, nate in ambiti diversi e caratterizzate da diversi approcci e finalità immediate. Nell'ottobre del 1995, in una conferenza tenuta alla University of Tennessee, i vari gruppi interessati hanno definito un sistema di specifiche unitarie. La convergenza prevede la compatibilità tra le varie implementazioni, pur garantendo la coesistenza di ognuna di esse. Dal 1996 la IETF, che si occupa della definizione degli standard per Internet, ha creato un gruppo di lavoro sugli URN.
Chi è interessato ad approfondire gli aspetti tecnici e gli sviluppi in corso può consultare le pagine Web di questa commissione, il cui indirizzo è http://www.ietf.org/html.charters/urn-charter.html. In questa sede ci limiteremo ad esporre le caratteristiche generali dell'architettura URN.
Un URN è un identificatore che può essere associato ad ogni risorsa disponibile su Internet, e che dovrebbe essere utilizzato in tutti i contesti che attualmente fanno uso delle URL. In generale, esso gode delle seguenti caratteristiche:
* unicità: due risorse distinte non possono avere lo stesso URN;
* validità globale: un URN è indipendente dalla localizzazione della risorsa;
* persistenza: una volta assegnato un URN ad una risorsa esso rimarrà associato ad essa per sempre, anche se la risorsa non sarà più disponibile; nessuna altra risorsa in futuro potrà avere un URN già assegnato;
* scalabilità: ogni tipo di risorsa su Internet, presente e futura, potrà avere un URN che gode delle caratteristiche elencate sopra.
Per risorsa si intende il 'contenuto intellettuale' di un documento (testo, immagine, animazione, software, ecc.), o una sua particolare presentazione: ad esempio, ogni versione di un documento in un dato formato può avere un URN. Ciascuna risorsa individuata da un URN può essere disponibile in molteplici copie, distribuite su diversi luoghi della rete: conseguentemente ad ogni URN possono corrispondere molteplici URL. Il processo di determinazione delle URL di una risorsa a partire dalla sua URN viene definito 'risoluzione'. I nomi vengono assegnati da una serie di autorità indipendenti, dette naming authority, che garantiscono la loro unicità e permanenza. A ogni naming authority corrisponde almeno un Name Resolution Service, ovvero un sistema software che effettua la risoluzione del nome [96].
I problemi che si cerca di risolvere attraverso l'introduzione degli URN sono molto rilevanti, anche se, allo stato attuale, non esiste nessuna implementazione pubblica dell'architettura URN. I processi di standardizzazione, come al solito, sono molto lenti, specialmente in un ambiente decentralizzato come Internet. Il consenso necessario alla introduzione di una tecnologia completamente nuova richiede il concorso di molti soggetti, e non di rado impone agli attori commerciali notevoli investimenti nella progettazione o modifica dei prodotti software. L'introduzione delle URN è, comunque, tra gli obiettivi nell'agenda del progetto Internet 2, che coinvolge alcune grandi università statunitensi nella progettazione della rete del prossimo futuro.
Nel frattempo, è stato sviluppato un sistema che offre un'ottima approssimazione delle funzionalità di identificazione univoca dei documenti sulla rete. Si tratta delle Persistent URLs (PURLs), non casualmente messe a punto nell'ambito bibliotecario. Il sistema infatti nasce come progetto di ricerca sponsorizzato dalla OCLC, consorzio internazionale di biblioteche, di cui abbiamo parlato nel capitolo 'Le biblioteche in rete'.
Il sistema PURLs, come indica il nome, si basa sull'attuale meccanismo di indirizzamento dei documenti su Web e dunque non richiede alcuna modifica negli attuali browser. In effetti una PURL è, sia dal punto di vista funzionale sia da quello sintattico, una normale URL, e può essere utilizzata negli stessi contesti (all'interno dei file HTML, nelle finestre dei browser, ecc). Questa ad esempio, rimanda a un documento introduttivo sul tema: http://purl.oclc.org/OCLC/PURL/SUMMARY.
Anziché puntare direttamente verso la risorsa indirizzata, una PURL punta a uno speciale server che ospita un sistema di risoluzione (PURL resolution service): nell'esempio il servizio ha l'indirizzo 'purl.oclc.org'. Quest'ultimo, in base al nome della risorsa - nell'esempio /OCLC/PURL/SUMMARY/ - traduce la PURL in una vera e propria URL, e reindirizza il client verso questo indirizzo. Il meccanismo si basa su una normale transazione HTTP, detta redirezione.
L'effettiva localizzazione della risorsa viene determinata dinamicamente dal PURL Service. Se un documento registrato presso un sistema di risoluzione PURL viene spostato (o se cambia il nome del file corrispondente), è sufficiente cambiare l'associazione PURL-URL nel database del servizio. La PURL rimane immutata e dunque tutti i riferimenti e i link da qualsiasi parte della rete verso quel documento continuano a funzionare perfettamente. L'aggiornamento delle relazioni deve essere effettuato esplicitamente dai responsabili della manutenzione del PURL Service. È comunque possibile eseguire questa operazione anche da computer remoti, e assegnare permessi di manutenzione per particolari gerarchie di nomi.
Il primo PURL Resolution Service è stato attivato dalla OCLC dal gennaio del 1996, e si è dimostrato molto efficiente. Chi desidera vederlo in funzione può indirizzare il suo browser all'indirizzo http://purl.oclc.org. Naturalmente l'efficacia effettiva di questa tecnologia richiede la disseminazione attraverso la rete del maggior numero possibile di PURL server. Per facilitarne la diffusione l'OCLC ha deciso di distribuire gratuitamente il relativo software, che è disponibile sul sito Web indicato sopra. Molte istituzioni, specialmente nell'ambio bibliotecario e accademico, hanno dimostrato grande interesse, e hanno iniziato a sviluppare altri servizi di risoluzione PURL.
Il sistema PURL costituisce un importante passo intermedio verso l'architettura URN. Inoltre, è ormai chiaro che la sintassi PURL sarà facilmente traducibile in forma di URN, trasformandola in uno schema di indirizzamento. Dunque coloro che oggi hanno adottato la tecnologia sviluppata dalla OCLC saranno in grado di migrare verso la tecnologia URN senza problemi.
Nel frattempo le PURL, appoggiandosi sull'attuale sistema di indirizzamento utilizzato su Internet, hanno il chiaro vantaggio di essere già disponibili, di funzionare perfettamente e risolvere la sindrome da 'risorsa non disponibile'.
