La presente nota intende riprendere brevemente il discorso avviato ormai due anni fa su queste pagine a proposito delle tecnologie di context sensitive linking e del collegato processo di standardizzazione della OpenURL, individuata come strumento essenziale per superare un ambiente di link chiusi e proprietari (cioè ogni volta "contrattati" tra fornitori di contenuti o dati bibliografici) e realizzare una interconnessione tra contenuti elettronici, generalizzata e capace di tener conto del contesto di fruizione.

In questi anni il context sensitive linking è divenuto familiare ad un numero sempre maggiore di colleghi anche in Italia, soprattutto a seguito della significativa diffusione delle applicazioni SFX. Può dunque rivestire qualche interesse gettare uno sguardo avanti sull'evoluzione in corso per lo Standard di riferimento, per quanto di rilevanza non immediatamente applicativa.

La prima osservazione che si impone è che la versione 0.1 dello Standard ha avuto una fortuna implementativa ampia e rapida tra gli attori del mercato dell'informazione elettronica accademica [1], probabilmente proprio perché nata in contesto applicativo.

Il riferimento è agli ormai classici esperimenti congiunti Università di Gent - National Laboratory di Los Alamos [2], che hanno portato:

Solo per ricordare che cosa si intende per servizi estesi, ecco un esempio dei servizi desiderabili per una citazione bibliografica trovata in calce ad un articolo elettronico:

Questa nota intende lasciare da parte le problematiche relative alla realizzazione del server o componente di rete in grado di fornire tali servizi, per focalizzarsi sul processo di standardizzazione della OpenURL, ovvero lo strumento di linking funzionale a un tale server e a tali servizi.

La NISO, accettando la dettagliata specifica tecnica elaborata dal gruppo di progetto SFX come base di partenza (cioè come versione 0.1) per uno standard di più ampio respiro, ha avviato fin da subito una profonda riflessione sulle problematiche relative, in vista di una revisione diretta all'estensione e generalizzazione della OpenURL [4].

Nel corso del 2003 presso la NISO (AX Committee) è stata messa a punto una nuova versione (la 1.0) dello Standard, che è rimasta a disposizione come draf sul sito dell'Organizzazione dal gennaio al marzo 2004. Attualmente, conclusasi questa fase, il documento si trova nello stato "approvato, in attesa di pubblicazione" e uscirà come Standard ANSI/NISO Z39.88-200X.

E' dunque di questo documento, e della tecnologia in esso prefigurata, che qui si cercherà di dare un'idea.

Lo Standard si compone:

Da un punto di vista funzionale, c'è assoluta continuità tra le due versioni dello Standard: il punto fermo è la finalizzazione alla fornitura di servizi contestualizzati rispetto all'ambiente di fruizione. Da qui la necessità di interrompere il link, predefinito in un documento di partenza verso un documento target, per intercettarlo all'interno dell'ambiente dell'utente e re-dirigerlo; l'idea è quella di un link (l'OpenURL appunto) che invece che condurre ad una destinazione prefissata, impachetti l'informazione relativa all'elemento citato e la invii ad un "componente di servizio" (o server di linking), in grado di interpretarla di re-dirigere il link tenendo conto dell'ambiente di fruizione.

Traducendo dall'abstract che apre lo Standard:

La nuova versione dello Standard attua un'estensione della precedente sotto i seguenti profili:

• non è limitata ai servizi di ambito bibliografico, ma si apre a possibili utilizzi di altre comunità del mondo dell'informazione;
• non è vincolata ad una modalità di rappresentazione dell'informazione, ma ammette la definizione di diverse modalità, a cominciare dall'uso di schemi XML;
• non definisce un formato di metadati ma ammette la definizione di diversi formati di metadati;
• non è vincolata ai formati GET e POST della URL, ma ammette la definizione di altri metodi di trasporto.

Partendo dall'esame della OpenURL "primo tipo" (cioè quella definita dalla versione 0.1 dello standard), di cui si riporta un esempio:

il processo di generalizzazione è giunto a riconoscervi la descrizione di tre entità, e cioè:

La nuova versione dello Standard definisce e riordina questi elementi come:

e, anche sulla base di analisi delle scelte fatte nelle implementazioni concrete, vi aggiunge altre tre entità contestuali che possono risultare necessarie per pienamente definire una situazione informativa:

• il tipo di servizio
• il richiedente
• la citazione di partenza.

Lo Standard parla dunque di un costrutto informativo, il ContextObject, il quale contiene la descrizione di sei entità:

Traducendo ancora dall'abstract dello Standard [5]:

Vale la pena di riportare anche la "situazione di esempio" utilizzata nello Standard [6]:

All'interno del ContextObject, ogni entità viene descritta da un descrittore. I descrittori possono essere di diverso tipo:

Ogni descrittore può essere codificato in modi diversi ed utilizzare identificatori o metadati diversi; inoltre, all'interno del costrutto informativo ContextObject, può variare il modo di esprimere e combinare i descrittori.

Ogni tecnica di codifica costituisce un "formato"; esistono dunque:

• formati di ContextObject (con quali elementi costruire il costrutto globale e come rappresentarli)
• formati di metadati (se si usa la descrizione in metadati, quali usare e come rappresentarli).

Sono inoltre utilizzabili diverse codifiche di carattere, diversi metodi di trasposto sulla rete, etc.

Il nuovo Standard è dunque un framework, cioè una cornice generale (non un protocollo), che prevede:

• la necessità di "registrare" i diversi formati e i metodi che si possono utilizzare;
• la necessità per ogni implementazione concreta di scegliere tra le molte possibilità;
• la necessità di ritagliare dei "profili di comunità", cioè dei sottoinsiemi dello Standard adatti a particolari ambiti.

Partendo così da funzionalità analoghe a quelle previste nella prima versione, si giunge ad una struttura molto più complessa; si veda un esempio parziale di costrutto informativo espresso secondo la nuova versione dello Standard:

In questo costrutto è facile riconoscere i dati della OpenURL "primo tipo".

La novità sostanziale è che esso va interpretato non direttamente sulla base dello Standard, ma sulla base dello specifico formato di ContextObject, registrato nel registro come:

e qui citato alla riga:

Solo nell'ambito di tale formato di ContextObject acquisiscono significato le righe:

Quest'ultima riga cita il formato di metadati registrato come info:ofi/fmt:kev:mtx:journal, e precisa che qui sarà usato esplicitamente (by-value) per descrivere il referent; nell'ambito di questo formato di metadati, acquisiscono significato le righe seguenti del tipo:

Le prime righe del costrutto esprimono dati relativi al metodo di trasporto utilizzato in questo caso (Inline OpenURL su HTTP) anch'esso registrato come info:ofi/tsp:http:openurl-inline.

Fondamentale diventa quindi il Registro: in esso devono essere registrati tutti gli elementi poi utilizzati, nonché tutte le scelte di rappresentazione compiute a monte degli elementi direttamente utilizzati. Ad ogni elemento registrato, viene assegnato un identificatore di registro.

Al registro è dedicata tutta la seconda parte dello Standard, che specifica:

Relativamente al primo punto, si riconoscono otto classi di elementi soggetti a registrazione, come si è già osservato non tutti da utilizzarsi nei costrutti ma alcuni necessari per costruire altri elementi.

Relativamente al secondo punto, inserire un elemento nel registro significa assegnargli un identificatore univoco composto secondo una ben precisa sintassi, il quale, oltre a permetterne la citazione inequivoca, è collegato ad una descrizione Dublin Core e ad una documentazione completa; traducendo dallo Standard [7]:

Attenzione dunque a non fare confusione tra la metodologia di costruzione degli identificatori di registro, e l'effettivo significato di ogni elemento registrato e l'uso che ne viene fatto nei costrutti informativi.

Tornando alle otto classi di elementi soggetti a registrazione, se ne dà di seguito l'elenco, riportando esempi di elementi già inseriti nel registro, identificati mediante l'identificatore assegnato nel registro stesso:

Traducendo ancora dallo Standard [8] (le interpolazioni fra quadre sono di chi scrive):

Per finire, qualche commento al contenuto del registro.

I formati, sia di metadati, sia di ContextObject, sono gli elementi principali che si trovano espressi nei costrutti informativi. Come si ricava da quanto detto sopra, i formati sono espressi da una tripla, cioè sono definiti da tre elementi:

• una rappresentazione fisica
• un linguaggio formalizzato
• una serie di costrutti in tale linguaggio.

Perciò la registrazione dei formati è possibile solo previa registrazione delle "rappresentazioni fisiche" e dei "linguaggi formalizzati" (elementi che non compaiono mai in quanto tali in un ContextObject).

In questa fase di avvio, il registro già contiene concretamente due "rappresentazione fisiche":

• KEV Key/EncodedValue
• XML

e due "linguaggio formalizzati" in cui rappresentarli:

• a matrice (definito nello Standard) per il KEV
• secondo il linguaggio XML schema definito dal W3C.

Con questi elementi, vengono costruiti due formati di ContextObject e vari formati di metadati.

I namespace [9] sono una classe di supporto alla gestione del registro stesso, in quanto includono gli identificatori di registro utilizzati. Ma comprendono anche tutti gli identificatori utilizzabili direttamente nei ContextObject, cioè i citati "descrittori identificatori" (le cui modalità di utilizzo e di espressione sono peraltro definite in ogni formato di ContextObject). Traducendo dallo Standard:

Per una gestione coerente con l'infrastruttura della rete, è stato introdotto uno specifico schema URI, proprio per la gestione di questo registro; traducendo dallo Standard [10]:

Insomma, la ragione per cui, nel ContecxtObject sopra citato, si può utilizzare:

I metodi di trasporto sono anch'essi direttamente implicati nei costrutti informativi. Il registro comprende per ora sei metodi registrati, che sono in effetti tre metodi replicati secondo il protocollo HTTP e HTTPS. In tutti i casi sono presenti alcuni dati essenziali, quali la versione dello Standard e il formato di ContextObject.

La distinzione è essenzialmente tra il trasporto dei dati effettivi (By-Value e Inline OpenURL) e il trasporto del solo "indirizzo" dei dati (By-Reference OpenURL); mentre tra la Inline e la By-Value la distinzione è essenzialmente di codifica dei dati, restando la prima più aderente alla vecchia versione dello Standard.

By-Reference OpenURL: la rappresentazione fisica del ContextObject viene solo citata attraverso una URI che rimanda alla sua locazione di rete, come valore della chiave 'url_ctx_ref'.

Ecco l'esempio dello Standard, per una By-Reference OpenURL che trasporta, usando HTTP GET, l'indirizzo di rete di un KEV ContextObject ad un OpenURL Resolver con indirizzo: http://www.example.net/menu:

• scritta in modo leggibile al lettore umano:

• codificata come URL:

Inline OpenURL: la rappresentazione fisica del ContextObject viene direttamente inserita come sequenza di molteplici coppie chiave=valore.

Ecco l'esempio dello Standard, per una Inline OpenURL che trasporta, usando HTTP GET, la rappresentazione di un KEV ContextObject ad un OpenURL Resolver with con indirizzo: http://www.example.net/menu:

• scritta in modo leggibile al lettore umano:

• codificata come URL:

By-Value OpenURL: la rappresentazione fisica del ContextObject viene direttamente inserita, come valore dell'unica chiave 'url_ctx_val' (che comprende dunque tutto il ContextObject). Questa modalità, che implica una doppia codifica dei valori delle chiavi, è opportuna per trasportare ContextObject espressi in XML.

Ecco l'esempio dello Standard, per una By-Value OpenURL che trasporta, usando HTTP GET, una rappresentazione di un semplice KEV ContextObject ad un OpenURL Resolver con indirizzo: http://www.example.net/menu:

• scritta in modo leggibile al lettore umano:

• codificata come URL:

url_ver=Z39.88-2004&url_tim=2002-08-16T17%3A23%3A45Z&url_ctx_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Actx&url_ctx_val=rft_id%3Dinfo%253A doi%252F10.1126%252Fscience.275.5304.1320

Dove si noti la doppia codificazione come URL dei Valori trasportati: una codificazione richiesta dal formato KEV del ContextObject, la seconda dalla sintassi della URI.

Cinzia Bucchioni, Centro Bibliotecario LM2 - Università di Pisa, e-mail: bucchioni@angl.unipi.it

Sitografia

• il sito della National Information Standards Organization NISO: <http://www.niso.org/>;
• il sito della OpenURL: <http://library.caltech.edu/openurl/>;
• la presentazione di Tony Hammond: <http://library.caltech.edu/openurl/Talks/Tony Hammond - Cork.ppt>;
• i messaggi sulla OpenURL sulla lista di discussione del W3C: <http://lists.w3.org/Archives/Public/>;
• le informazioni sugli standard sul sito della Library of Congress: <http://www.loc.gov/standards/uri/info.html>.

Note

[1] Il dato è molto rilevante, anche se rimane l'impressione che il funzionamento delle applicazioni disponibili, quanto più riesca soddisfacente tanto più sia pesantemente basato su soluzioni ad hoc, forse proprio perché il perseguimento di un server di servizio efficace ha preceduto il processo di standardizzazione; e che a volte l'adeguamento allo standard sia attuato in maniera minimale. A questo proposito sarebbe interessante verificare quanti dei prodotti OpenURL compliant utilizzino l'identificatore "privato", sfuggendo così al controllo dello standard; o ancora quanti dei servizi effettivamente disponibili siano resi possibili non tanto dai dati passati con la OpenURL ma piuttosto dal ri-accesso da parte del server di linking alla risorsa di partenza per arricchire i dati, processo questo che si attua attraverso sourceParser specifici per risorsa.

[2] Cinzia Bucchioni, SFX e OpenURL: gli esperimenti del team di Van de Sompel in "Bibliotime", anno V, numero 2 (luglio 2002), <http://www.spbo.unibo.it/bibliotime/num-v-2/bucchion.htm>.

[3] Il server prototipale messo a punto durante la sperimentazione, è stato poi ceduto all'azienda ExLibris ed è attualmente commercializzato col nome SFX.

[4] La direzione della revisione della NISO viene tracciata già nell'articolo di Van de Sompel, Herbert, Oren Beit-Arie, Generalizing the OpenURL Framework beyond References to Scholarly Works: The Bison-Futé Model in: "D-Lib Magazine", volume 7, numero 7/8 (July/August 2001), <http://mirrored.ukoln.ac.uk/lis-journals/dlib/dlib/dlib/july01/vandesompel/07vandesompel.html>. Traduzione italiana sul sito della CNUR, <https://www.aib.it/aib/commiss/cnur/trsomp5.htm3>.

[5] The OpenURL Framework for Context-Sensitive Services. Part 1: ContextObject and Transport Mechanisms, p. i, <http://library.caltech.edu/openurl/StandardDocuments/Z39_88_Pt1_ballot final.pdf>.

[6] The OpenURL Framework for Context-Sensitive Services. Part 1: ContextObject and Transport Mechanisms, p. 6.

[7] The OpenURL Framework for Context-Sensitive Services. Part 2: Initial Registry Content, p. 1

[8] The OpenURL Framework for Context-Sensitive Services. Part 1: ContextObject and Transport Mechanisms, p. i.

[9] Per chiarire ai non addetti ai lavori il significato, ampio perché trasversale a parecchi contesti, di namespace, può essere un utile punto di partenza la Wikipedia:
<http://en.wikipedia.org/wiki/Uniform_Resource_Identifier>
<http://en.wikipedia.org/wiki/Namespace_%28programming%29>
<http://en.wikipedia.org/wiki/XML>.

[10] The OpenURL Framework for Context-Sensitive Services. Part 1: ContextObject and Transport Mechanisms, p. 3.