SFX - un acronimo che è anche un gioco di parole derivante da special effects - è il nome che è stato dato ad un progetto pluriennale a più stadi, portato avanti dall'Università di Gand in Belgio e di Los Alamos in USA, e che ha coinvolto un buon numero di partner commerciali. Tale progetto è documentato attraverso una serie di articoli sulla rivista on line D-Lib Magazine, che in questa breve esposizione si tengono soprattutto presenti (e che a partire da agosto 2002 saranno a disposizione in traduzione sulle pagine web della CNUR, la Commissione Nazionale Università e Ricerca dell'AIB).

Lo scopo del progetto è stato produrre un software (un "componente di servizio") che permetta ad una istituzione (diciamo una digital library o una hybrid library) di creare un ambiente informativo interconnesso, cioè di stabilire link tra le varie risorse elettroniche (a pagamento o ad accesso libero) che costituiscono la sua collezione, indipendentemente dalle connessioni previste a priori da ogni risorsa. Ciò permette che un utente, effettuata una ricerca su una risorsa (detta origin) ed ottenuta una risposta, possa richiedere, per un certo record o citazione o entità informativa bibliografica (che diventa la link-source), dei cosiddetti "servizi estesi", cioè collegamenti rilevanti ad altre risorse della collezione (che saranno dette target). Dal punto di vista della specifica istituzione, l'obiettivo è stato la disponibilità di un software in grado di offrire un punto unico di gestione di link a servizi estesi da essa stessa definiti.

Per servizi estesi rispetto ad una certa entità informativa bibliografica si intende, per esempio:

• il testo pieno dell'articolo indicizzato nella link-source
• un record di un altro database che contiene un abstract dello stesso articolo
• informazioni citazionali corrispondenti alla link-source (dati ISIS)
• il posseduto della biblioteca per la rivista che contiene l'articolo della link-source
• la recensione (review) sul libro che viene descritto nella link-source.

Scendendo maggiormente nel dettaglio, il progetto SFX ha prodotto:

• un software commerciale distribuito dalla Ex Libris, il produttore del sistema di gestione di biblioteche Aleph. Per inciso: può disturbare che un software nato per contrastare il predominio commerciale nel campo dell'informazione elettronica si sia immediatamente trasformato in una soluzione proprietaria; è però anche vero che (cfr. Burioni) se questo non fosse avvenuto, molto forte sarebbe stato il rischio che tutto si fermasse allo stadio prototipale, come avviene di molti progetti analoghi, e che l'operatore commerciale ha il merito di aver accettato il rischio di una soluzione innovativa; del resto è comunque una garanzia che una soluzione di collegamento venga sottratta ai possessori dei contenuti da parte di un fornitore di software gestionale;
• una proposta di standard (OpenURL, per un linking aperto) accolta dall'ente statunitense di standardizzazione NISO, il quale ha recepito la bozza prodotta dal progetto come versione 0.1, e ne sta attualmente sviluppando la versione successiva;
• un software libero (OpenResolver, con licenza GNU), disponibile sul sito dell'UKOLN.

Attualmente, il nome SFX definisce l'implementazione proprietaria di Ex Libris, e SFX server è il componente di servizio di Ex Libris; il componente di servizio free software viene denominato semplicemente OpenURL resolver (anzi: OpenResolver).

Non è facile capire fin dove è pura questione di nomi: scorrendo i dettagliati resoconti di Van de Sompel sulla sperimentazione, pare proprio che essa sia pienamente confluita nel software proprietario SFX, e che l'OpenResolver di UKOLN sia molto più semplice nell'architettura e limitato nelle funzionalità, seppur sviluppabile secondo la filosofia del free software [1].

E' possibile farsi un'idea concreta del funzionamento di SFX attraverso alcune demo disponibili in rete, raccolte al sito:

<http://library.caltech.edu/openurl/Demos.htm>. Si vedano in particolare OpenResolver di Ukoln e SFX di Ex Libris, per il quale si veda anche <http://www.sfxit.com/>.

Anche solo mediante le demo, si può dunque vedere che il processo avviene in tre tempi e attraverso tre passaggi successivi:

1. all'utente, in ogni record o citazione trovati con la sua ricerca di partenza, viene presentato il bottone SFX per servizi estesi:

à dietro quel bottone c'è una particolare URL, la OpenURL, che al momento del "click" verrà inviata al componente di servizio dell'utente; perché si abbia questo, è necessario che la risorsa di partenza sia OpenURL compliant, cioè in grado di emettere una OpenURL, opportunamente formattata e opportunamente indirizzata (cioè indirizzata di volta in volta al componente di servizio specifico per l'utente);

2. cliccando il bottone SFX, si apre una nuova finestra, con un elenco di servizi, cioè di link, potenzialmente rilevanti per la citazione di partenza, ognuno con un proprio bottoncino cliccabile per l'attivazione:

à attivando il bottone SFX si realizza dunque l'invio della OpenURL al componente di servizio (o al risolutore di OpenURL): ad esso la OpenURL porta come parametri i metadati della link-source [2], utilizzando i quali il componente di servizio può attuare il processo di verifica concettuale o valutazione SFX (cioè il confronto con la base SFX) e selezionare i servizi possibili, cioè una serie di link potenziali, attivabili singolarmente cliccando l'apposito bottoncino;

3. cliccando uno dei servizi proposti, si apre una terza finestra con l'effettivo collegamento all'interno della risorsa selezionata:

Gli esperimenti di Van de Sompel

Seguendo la falsariga degli articoli di Van de Sompel, si ha l'opportunità di seguire il percorso sperimentale e di apprezzarne il metodo, che procede per implementazioni concrete e generalizzazioni progressive. Infatti:

• la prima fase del progetto (la fase Elektron) ha coinvolto un numero limitato di risorse all'Università di Gand (opac, database bibliografici, raccolte di testi pieni, Amazon), e si è focalizzata sulla progettazione di un componente di servizio, definibile come un particolare servizio di linking che, ricevuto in input un certo "documento", dà in output altri documenti correlati, o anche come un servizio di risoluzione web che ricevuto in input una URL - una OpenURL - la risolve in una serie di link;
• nella fase successiva sono state coinvolte le due sedi di Gand e di Los Alamos e una grande varietà di risorse, e lo sforzo è stato quello di generalizzare il prodotto precedente perché fosse facilmente portabile in ambienti diversi [3].

Qui di seguito si cerca pertanto di delineare sincronicamente i principali nodi affrontati e di descrivere il funzionamento del componente di servizio nella sua architettura definitiva.

In sintesi il progetto è consistito:

1. nella verifica della necessità di avere servizi estesi, e di averli sotto il controllo della biblioteca, e in una riflessione sulle strutture di linking;
2. nel cercare un'architettura adatta a rispondere a tale necessità, cioè un software che sapesse ottenere ed elaborare i metadati dalla link-source e, a partire da essi, procurare servizi, cioè link verso appropriati target. In questo ambito:

• è nata la proposta di un identificatore per la link-source (la più volte nominata OpenURL)
• si sono cercate soluzioni per il link-to
• è stata ideata la base SFX (e la sua tabella centrale "Colli", che enuncia i link potenziali tra risorse) per quella che Van de Sompel definisce "verifica concettuale" dei link.

Scendendo nei dettagli:

1. la riflessione è partita dal verificare la necessità di servizi context-sensitive, cioè decisi in dipendenza del contesto di fruizione dei servizi stessi, inteso qui come l'istituzione dell'utente (ma nulla vieta di arrivare ad una personalizzazione per singolo utente); questo, per dare risposta ad un problema già emerso in altra sede di studio (cfr. i vari convegni della Digital Library Federation sul reference linking, centrato sul collegamento tra citazione e testo pieno), il problema della "copia appropriata" o "di Harvard", cioè di come rinviare, da una citazione in un opac o in un database bibliografico, al corrispondente testo pieno, sul server appropriato, che non sempre è quello di default dell'editore (possono esserci copie locali di repository di testi pieni, o può esserci necessità di transitare attraverso un altro server che controlli i diritti di accesso). E' risultato subito chiaro che, per ottenere ciò, sono necessari link che non siano scritti in maniera precalcolata e statica all'interno di una risorsa, ma siano generati di volta in volta da un componente di servizio locale, a seconda della situazione e delle risorse in campo in un certo ambiente; detto in altro modo, è necessario che i link non si pongano allo stesso livello a cui si pongono i metadati citazionali, ma ad un livello sovrapposto dall'esterno: per questo il progetto ha cercato di implementare una struttura di linking con le seguenti caratteristiche:
• aperta cioè context-sensitive (configurabile localmente) e non predeterminata da un fornitore;
• dinamica, cioè non precalcolata in un database di link che rappresentano collegamenti tra documenti specifici, ma basata su un database di interrelazioni potenziali tra le risorse che contengono i documenti;
• che generi link just-in-time, calcolati cioè solo al momento del click: il bottone SFX nasconde un identificatore (la OpenURL), che viene passato al componente di indirizzamento solo nel momento in cui l'utente segue il link; sulla base dello stesso principio, i vari link a servizi approntati nella schermata SFX, hanno dietro i parametri per lo script targetParser, che viene lanciato solo al momento del click su un servizio particolare.
2. è stata quindi disegnata la seguente architettura del componente di servizio:

• versante source: è stato in primo luogo affrontato il problema di fare in modo che il componente di servizio possa ottenere i metadati della link-source (di solito un record bibliografico o una citazione bibliografica all'interno di una risorsa origin) per poter poi approntare i servizi (collegamenti o link) utili: è risultato evidente che, pur essendo possibili metodi di proxying, essi sono pesanti e poco generalizzabili, e fin dall'inizio si è puntato piuttosto sulla collaborazione delle risorse origin, cui si è chiesto di rendersi SFX aware o OpenURL compliant, cioè in grado di inviare un identificatore, la OpenURL; SFX insomma, cercando di superare il linking chiuso con un approccio dinamico, è approdato alla proposta di un modello di linking aperto. Definire la OpenURL ha voluto dire considerare come entità separate: (a) il link, (b) i metadati di una citazione [4];

• linking: per implementare un linking dinamico, è stato ideato il Colli, una tabella relazionale che è un repertorio di servizi, che accoppia cioè ogni risorsa con ogni altra attraverso un servizio possibile; essa contiene link predisposti tra risorse, ognuno dei quali corrisponde ad un servizio. Per esemplificare (dalla tabella n. 7 del terzo articolo di Van de Sompel):

Source (punto di partenza)	servizio del Colli	target (punto di arrivo)
APS/PROLA	abstract	Inspec
BIOSIS	abstract	Medline
BIOSIS	genome	Genome Base
Wiley	abstract	Medline
Wiley	cited_reference	Science Cit. Base
CC	abstrac	LiSa
EconLit	review	Books in Print
Inspec	full_text	Springer

• attorno al Colli è stata costruita la base SFX, un database di conoscenza contestuale sulle risorse, gli oggetti in esse contenuti, la situazione locale. Essa descrive le relazioni tra i servizi della tabella Colli e i valori dei parametri nella link-source: registra cioè le soglie di rilevanza (o di attivazione) di ogni link, permettendone una selezione preliminare, cioè una verifica concettuale ancorché non funzionale, riducendo le probabilità di link irrilevanti, sempre possibili nelle soluzioni just-in-time. Per concretizzare: se la link-source descrive un libro, il link ad un contenitore di articoli full-text è irrilevante; ma se anche la link-source descrive un articolo, il link suddetto è irrilevante quando l'annata sia precedente all'inizio dell'edizione elettronica; e anche quando l'annata sia posteriore, il link suddetto sarà irrilevante quando l'istituzione non abbia l'abbonamento. Per non presentare link che al tentativo di accesso risultino ciechi, SFX si serve di un repertorio di controllo e filtro, appunto la base SFX. Perché poi essa sia facilmente gestibile e portabile, è strutturata in modo da rispecchiare la distinzione tra rilevanza globale e locale:
• la rilevanza globale è il contrario dell'essere "irrilevante in ogni contesto" (p.e. per un articolo di rivista ha rilevanza globale il testo pieno, se l'anno di inizio dell'edizione elettronica è anteriore a quello della citazione);

• la rilevanza locale, più ristretta della precedente, si riferisce solo a quegli aspetti potenzialmente rilevanti che lo sono effettivamente in una certa collezione (p.e. in dipendenza del fatto che una certa collezione possieda una certa risorsa, e ne disponga in un'implementazione utilizzabile).

Per chiarezza si riporta qui la figura n. 7 del terzo articolo di Van de Sompel:

• versante target: è stato affrontato il problema di come attuare il legame con gli elementi target, cioè gli elementi scelti come punto di arrivo dei link suddetti. Su questo versante non si sono proposte soluzioni generalizzate ma si è cercata una soluzione pragmatica: si è scelta la via di scrivere script targetParser ad hoc che implementino caso per caso la particolare sintassi link-to di ogni risorsa target. Naturalmente questi script sono condivisibili o applicabili in varie situazioni, in quanto, per esempio, uno stesso targetParser è utilizzabile per tutte le risorse che supportano la stessa sintassi link-to. E' stata anche sperimentata l'adozione della soluzione S-Link-S, ovvero un software calcolatore di URL che opera sulla base di template XML descriventi la sintassi link-to: una adozione diffusa di questo modello permetterebbe una maggior generalizzazione e standardizzazione, ma essendone per ora l'uso poco diffuso, SFX ha adottato una soluzione mista per raggiungere più target possibili. Peraltro i targetParser permettono di puntare a qualunque target ad un qualche livello di profondità, e di utilizzare una sintassi di ricerca dove non sia possibile puntare direttamente al record.

Ripercorrendo il funzionamento della soluzione SFX

Attraverso una schematizzazione grafica è possibile riepilogare forse più agevolmente i vari passaggi e la successione delle schermate del processo SFX.

Sotto il bottone SFX, che una risorsa OpenURL compliant presenta all'utente per ogni citazione bibliografica, c'è una OpenURL: essa è costituita da una BASE-URL (cioè un indirizzo web, che è quello del componente di servizio, che garantisce la contex-sensitiveness) e una QUERY, che contiene la serie di parametri passati al componente di servizio, formattati secondo lo standard.

La proposta dello standard OpenURL è probabilmente il principale conseguimento del progetto: invece del proxying o di altro modo ad hoc per catturare i metadati della risorsa, si è scelto di sollecitare la collaborazione dei fornitori di informazione, ai quali si chiede di includere nei propri record, invece di più link chiusi, un solo "gancio" costruito secondo un ben preciso standard. Si chiede perciò ad ogni risorsa di rendersi SFX aware o OpenURL compliant, introducendo, nel record che presenta all'utente, una OpenURL, cioè un bottone cliccabile, che, attivato, punta al componente di servizio (o risolutore di OpenURL) e gli passa i metadati in formato predefinito (di nuovo: la risorsa di partenza OpenURL compliant deve poter proporre ad ogni utente un bottoncino che punti esattamente al suo componente di servizio).

Quando al componente di servizio arriva la OpenURL, esso (anzi, per la precisione il sottomodulo chiamato "componente di reindirizzamento" [3]) è in grado di integrare i metadati attraverso l'attivazione dell'apposito script sourceParser [5].

Ricevuta ed eventualmente integrata l'informazione suddetta, il componente di servizio la trasforma in un oggetto di rappresentazione interna normalizzata, per poi passarla nel processo valutativo SFX attuato per confronto con la base SFX, costituita dalla tabella Colli e dalle soglie. In questo processo, vengono selezionati (col Colli) e filtrati (con le soglie) i servizi pertinenti per tale link-source (in funzione dell'origine, del tipo di documento, e di altri metadati presenti nelle soglie quali l'ISSN o l'annata); ogni servizio è implementato verso determinati target: in questo modo può accadere che determinate link-source si trovino in connessione con determinati target anche imprevedutamente.

Il componente di servizio, per svolgere la sua funzione di servizio di linking sofisticato, non utilizza un database di identificatori (del tipo, per esempio: "tal DOI -> tale URL"), bensì un database di connessioni logiche ("tale risorsa -> tale servizio"), il che richiede che esso sia in grado di lavorare con i metadati e non solo con gli identificatori; detto in altro modo, richiede che i metadati siano utilizzati non solo come identificatori ma come operatori per delle procedure.

A questo punto viene presentata la schermata SFX all'utente, con l'elenco dei servizi selezionati, che è una serie di link concettualmente verificati ma non risolti: al click su di essi, si attiva il targetParser specifico per risorsa, che conduce l'utente nella risorsa target, il più vicino possibile all'elemento specifico desiderato. Lo script targetParser riceve infatti alcuni parametri (identificatore dell'oggetto GenericRequest che rappresenta la citazione, il servizio del Colli con relativo target, alcuni metadati), che utilizza per implementare le procedure link-to per il target proposto: produce cioè una URL verso la risorsa target che implementa la sintassi di puntamento interna specifica per la risorsa (o, se essa non esiste, la sintassi di ricerca) in modo tale da condurre l'utente il più vicino possibile all'informazione pertinente. Ad esempio, se si tratta di reperire il full-text di un articolo, conduce ove possibile al testo pieno e non alla pagina di selezione dei fascicoli. Ma la possibilità di un link più o meno diretto dipende dalla risorsa: ogni target è infatti raggiungibile, ma ad un livello maggiore o minore di profondità in dipendenza dai metadati disponibili e dalla sintassi link-to supportata; i target che non ammettono una sintassi link-to diretta, ammettono di solito una ricerca, anch'essa implementabile tramite il targetParser, la quale è più incerta ma offre il vantaggio di salvaguardare una certa serendipity.

E' evidente che il novero e la qualità dei servizi proposti dipendono da:

• situazione locale e scelte istituzionali
• architettura del componente di servizio e dettaglio delle definizioni della base SFX
• qualità dei metadati relativi alla link-source
• sintassi link-to delle risorse di arrivo.

La OpenURL

La OpenURL è attualmente basata [6] sul protocollo TCP-IP HTTP GET o POST, ma non sono escluse evoluzioni in direzione XML, ed è così strutturata:

La BASE-URL corrisponde alla componente <authority><path> delle specifiche URI e deve ottemperare alle regole ad essa relative sui caratteri riservati. E' la URL di un componente di servizio che può accettare in input una OpenURL.

La QUERY corrisponde al componente query delle specifiche URI.

DESCRIPTION descrive l'origine dell'oggetto di metadati trasportato + l'oggetto di metadati stesso.

Se ci sono più oggetti, le loro DESCRIPTION devono essere delimitate da 2 & (e commerciale).

• identificatore di entità: citazione del dominio + identificatore unico nel dominio (tipo DOI)
• identificatore di metadati: citazione di un dominio + identificatore unico nel dominio (che punta a metadati)
• descrizione in metadati: citazione di uno schema + descrizione secondo quello schema
• puntatore ad una descrizione di metadati: citazione di uno schema + puntatore ad una descrizione dell'entità secondo quello schema.

• "per valore" (direttamente i dati) o "per riferimento" (per mezzo di identificatori);
• in modalità "esplicita" (i metadati e gli identificatori sono fisicamente contenuti all'interno del descrittore) o in modalità "implicita" (i metadati e gli identificatori sono semplicemente reperibili sulla base dell'informazione disponibile nel descrittore, che contiene un puntatore).

Per approfondimenti su questi ultimi concetti, si veda lo standard OpenURL.

E' evidente che una certa citazione bibliografica può essere descritta da diverse OpenURL, utilizzando diverse delle possibilità offerte dallo standard. Un esempio dal quarto articolo di Van de Sompel:

In un articolo posteriore alla conclusione del progetto e all'avvio dell'iter di standardizzazione, Van de Sompel, facendo eco anche ad alcune indicazioni della stessa NISO, avanza la proposta di estendere l'applicazione della OpenURL dall'ambito delle citazioni bibliografiche alla descrizione di tutti gli oggetti nominabili su web per cui un autore voglia emettere un link a risoluzione aperta in un qualunque documento html, e presenta il modello Bison-Futé, che si muove in territori contigui agli studi relativi al web semantico (in particolare quelli che riguardano l'uso di descrittori formali per annotare documenti non formalizzati). Invece che di OpenURL si parla di:

• OpenResolutionLink corrispondente alla BASE-URL
• ContexObject corrispondente alla parte descrittiva QUERY, che viene ampliata per poter descrivere vari elementi contestuali oltre la ORIGIN (quindi molte entità contestuali);
• restano i quattro tipi di descrittori già definiti, ma il formato del descrittore non è più vincolato alla coppia "nome=valore", si ammettono anche formati definiti in XML.

Uno strumento per la SFX-awareness: il cookiePusher

Praticamente, per emettere la OpenURL, oltre a formattare i metadati nel modo appropriato, è necessario che la risorsa origin sia ogni volta informata dell'apposito componente di reindirizzamento dell'utente, unica garanzia di context-sensitiveness (si può dire che deve implementare una risoluzione selettiva, cioè la capacità per un sistema di scegliere a quale risolutore indirizzarsi): la risorsa può ottenere questo scopo in vari modi, tra cui:

• mantenendo un profilo di utente (persona o istituzione) che includa il dato del server opportuno;
• con il meccanismo del cookiePusher (è il metodo consigliato da Ex Libris): il cookiePusher è un semplice Script, che diventa l'indirizzo a cui il client dell'utente che vuole connettersi a quella risorsa deve puntare, attraverso una URL che ha come parametri;
• (1) il server per i servizi estesi
• (2) il server della risorsa da accedere

Una volta che il cookiePusher è stato installato, la URL per connettersi a quella risorsa deve essere:

laddove:

• CookiePusher_URL è la URL del cookiePusher script
• local_SFX è la URL del componente di reindirizzamento locale SFX
• service_URL è la URL desiderata della risorsa informativa, quella che si usa normalmente in condizioni non SFX; tale URL può puntare all'iniziale schermo di ricerca di un database bibliografico, può essere la URL di un articolo sul sito di un editore, etc.

La collaborazione tra il progetto SFX e l'iniziativa DOI

Di notevole interesse è il progetto di collaborazione con DOI, iniziativa nata nel contesto degli editori di riviste elettroniche, che hanno ideato un metodo di interconnessione tra gli articoli attraverso le citazioni: l'idea è di attribuire un codice identificativo, il Digital Object Identifier, ad ogni articolo e di registrare su server centrale, nel database CrossRef, per ognuno di essi:

• il codice DOI
• i metadati corrispondenti
• la URL del testo pieno.

Per ogni nuovo editore, basterebbe dunque includere una URL che punti al proxy DOI e passi come parametro il numero DOI, perché venga risolta nella URL dell'editore. Ma questo genera il "problema di Harvard o della copia appropriata", e d'altro canto non permette di aggiungere altri servizi.

La collaborazione con SFX ha condotto ad aggiungere al Proxy DOI la capacità di sapere se un certo utente ha accesso ad un componente di servizio SFX e in tal caso di operare un reindirizzamento a tale componente tramite una OpenURL che contenga l'identificatore DOI; si è trattato insomma di rendere il proxy DOI stesso OpenURL compliant, cioè capace di conoscere il componente di servizio dell'utente tramite cookiePusher e di emettere OpenURL. Si tratta dunque di un meccanismo potente ed economico, che permette di passare da un sistema di linking chiuso ad uno aperto con pochissimi investimenti, realizzato attraverso la convergenza di standard, prodotti e identificatori, che, pur nati in contesti diversi, interagiscono allo scopo di fornire all'utenza servizi sempre più evoluti.

Cinzia Bucchioni, Biblioteca di Anglistica - Università di Pisa, e-mail: bucchioni@angl.unipi.it

Note

* Questo articolo riprende il testo della relazione tenuta in occasione del Seminario "Open Archive per una comunicazione scientifica 'free'", organizzato dalla Biblioteca di Matematica, Informatica, Fisica dell'Università di Pisa, con il patrocinio AIB - Sezione Toscana e CNUR - Commissione Nazionale Università e Ricerca, Pisa, 12 giugno 2002.

[1] Tentando un confronto tra SFX Server e openResolver di UKOLN (per la cui comprensione è consigliabile una previa lettura completa del presente lavoro):

• openResolver non è per ora in grado di reindirizzare un DOI;
• openResolver non pare implementare il complicato meccanismo della SFX Base che consente di "accordare" o "sintonizzare" i servizi eliminando i link irrilevanti; non pare cioè che ci sia una posizione di soglie né globali né locali; il documento fa riferimento in prospettiva all'architettura DNER (Distributed National Electronic Resource, modello studiato all'UKOLN) come a uno strumento per ovviare a questo problema inserendo un institutional profile);
• non è chiaro a che livello openResolver sappia trarre i metadati dalla link-source se gli viene passato solo l'identificatore locale + risorsa che lo contiene: quali sourceParser sono disponibili? Parrebbe solo quelli dei domini (namespace) standard. Probabilmente li si può aggiungere secondo la filosofia del Free software;
• sicuramente UKOLN fa uso di targetParser, ma quali sono disponibili? Probabilmente li si può aggiungere secondo la filosofia del Free software.

E' vero che la soluzione SFX proprietaria costringe a passare attraverso il fornitore per qualsiasi aggiustamento di tiro, implementazione di nuove sintassi, aggiunta di risorse completamente nuove o modifica di quelle esistenti. Ma d'altra parte fornisce un sistema di ampia repertoriazione delle risorse esistenti, in cui le soglie globali sono praticamente già implementate, e parametrizzato per una facile gestione delle soglie locali.

[2] Per una comprensione di queste note è necessario ricordare almeno che le URL sono sempre costituite da un indirizzo che punta ad un certo file su una certa macchina; nei casi più semplici tale file è una pagina web statica, che al click viene presentata; ma tale file può essere anche un programma che al click viene attivato: in tal caso la URL può essere più complessa, e all'indirizzo possono seguire una serie di parametri (separati da esso da un punto interrogativo), i quali non hanno significato per il web ma solo per il programma che li riceve e su di essi lavora.

[3] Le principali generalizzazioni, meglio comprensibili a fine discorso, sono state:

• l'evoluzione della tabella Colli, che inizialmente includeva "servizio verso target" e poi è diventato solo "servizio" da mettersi in relazione con sources e targets;
• la standardizzazione della OpenURL, e la funzione svolta dalla tabella Colli di mettere in relazione "tipi di sources" e targets;
• la distinzione tra rilevanza locale e globale nella base SFX;
• la suddivisione del modulo software "componente di servizio" in due moduli indipendenti e interoperabili: "componente di reindirizzamento" e "componente di servizio" vero e proprio:
• il componente locale di reindirizzamento, costituito dal meccanismo locale di reindirizzamento, per interoperare col quale le authorities devono rendersi SFX aware: alla richiesta dell'utente che fa click, esso cattura i metadati della link-source: riceve quelli della OpenURL e li usa per un'operazione di "cattura" attraverso il protocolli disponibili per la risorsa origin in oggetto, per la qual cosa esso contiene un repertorio di sourceParser;
• il componente locale di servizio, che, ricevuta l'informazione dal precedente, la trasforma in un oggetto di rappresentazione interna normalizzata, poi la passa nel processo valutativo SFX attuato per confronto con la base SFX: esso è il vero e proprio servizio di linking sofisticato che, ricevuto in input un certo "documento", dà in output altri documenti correlati.

[4] Si noti che il componente di reindirizzamento, almeno nella soluzione SFX vera e propria, resta comunque in grado di arricchire i metadati della link-source traendoli dalla origin medesima o da altra fonte, lanciando cioè i vari script sourceParser definiti per risorsa.

[5] I sourceParser non fanno altro che implementare l'accesso alla risorsa origin utilizzando i protocolli eventualmente ammessi (Z39.50, HTTP etc.), ed arricchire i metadati ricevuti nella OpenURL; invero questo era il meccanismo ideato prima della OpenURL, e presuppone sourceParser per ogni risorsa e la conoscenza della origin; ma i metadati possono anche essere tratti da altra fonte, anzi questa è la direzione generalizzabile indicata dalla OpenURL: infatti quanto più vengono utilizzati identificatori di domini (namespace) globali dove andare a prendere metadati (invece che identificatori locali specifici per risorsa) tanto più i sourceParser sarebbero generalizzati (per dominio). Il cambiamento di prospettiva è evidenziato anche dal fatto che nello standard OpenURL il parametro origin è facoltativo, mentre nei primi esperimenti SFX la prima selezione di servizi possibili nel Colli si basa proprio sulla origin; è perciò stato necessario aggiungere al Colli una selezione per "qualsiasi origine" in relazione a tutti i target, per cui funzionano solo i filtri delle soglie.

[6] La OpenURL è un'evoluzione della concezione iniziale della SFX URL:

formato generale: target?serviceDesc&objectDesc

formato dettagliato: local_SFX?vendorID=<il_fornitore>&databaseID=<la_base>&objectDesc=<l'identificatore>

• target è l'URL del componente locale di reindirizzamento della soluzione SFX
• serviceDesc definisce univocamente la risorsa origine: fornitore della risorsa e risorsa stessa
• objectDesc contiene informazioni relative alla link-source: identificatore del record + metadati.

• Van de Sompel, Herbert, Patrick Hochstenbach, Reference Linking in a Hybrid Libary Environment, Part 1: Frameworks for Linking.
• Van de Sompel, Herbert, Patrick Hochstenbach, Reference Linking in a Hybrid Libary Environment, Part 2: SFX, a Generic Linking Solution .
• Van de Sompel, Herbert, Patrick Hochstenbach, Reference Linking in a Hybrid Libary Environment, Part 3: Generalizing the SFX solution in the "SFX@Ghent & SFX@LANL" experiment.
• Van de Sompel, Herbert, Oren Beit-Arie, Open Linking in the Scholarly Information Environment Using the OpenURL Framework.
• Van de Sompel, Herbert, Oren Beit-Arie, Generalizing the OpenURL Framework beyond References to Scholarly Works: The Bison-Futé Model.
• Powell, Andy, OpenResolver: a Simple OpenURL Resolver.
• Walker, Jenny, Navigating information landscapes: the role of linking technologies.
• Sadeh, Tamar, SFX : An open linking framework for the hybrid library [PDF].
• Blake, Miriam, Implementation of OpenURL and SFX in Digital Library [PPT].
• Burioni, Luca, Il contenuto è re, ma il regno è in grande fermento. Analisi e tendenze del mercato dell'informazione.
• Potortì, Francesco, Che cos'è il software libero.