AIB. Commissione nazionale università e ricerca

AIB-WEB | Le Commissioni | Commissione università ricerca

Generalizzare lo schema OpenURL al di là delle citazioni bibliografiche ai lavori accademici: il modello Bison-Futé / Herbert Van de Sompel e Oren Beit-Arie [*]

Introduzione

Questo articolo presenta sinteticamente il modello Bison-Futé, che va considerato una generalizzazione concettuale dello schema OpenURL, nato nell'ambito dell'informazione accademica su web per il linking citazionale aperto e sensibile al contesto [Van de Sompel and Beit-Arie 2001, Van de Sompel and Hochstenbach 1999a, Van de Sompel and Hochstenbach 1999b, e Van de Sompel and Hochstenbach 1999c]; il presente contributo è di natura eminentemente astratta e deve considerarsi il resoconto di una riflessione in corso: perciò in esso alcune domande resteranno senza risposta e alcuni problemi verranno trascurati.

Esso si apre con una sommaria presentazione dello schema OpenURL: per approfondimenti si veda [Van de Sompel and Beit-Arie 2001].

Lo scopo è quello di fornire una base concettuale al processo di standardizzazione NISO della OpenURL: sono infatti stati proprio gli autori del presente contributo a sottoporre le specifiche OpenURL [Van de Sompel, Hochstenbach, Beit-Arie 2000] alla NISO, che le ha accettate quali scorciatoia verso il loro sviluppo in standard nazionale. Ma il Comitato AX per gli standard NISO tenterà anche di verificare l'applicabilità dei concetti OpenURL al di là dell'ambiente dell'informazione accademica. Riferendosi ai concetti OpenURL generali infatti, il documento di incarico (il mandato al) al Comitato AX della NISO si esprime così:

Lo schema OpenURL

Nell'ambiente accademico su web, un utente, quando interagisce con un servizio informativo, come risultato di tale interazione reperisce delle citazioni a lavori scientifici; tipicamente, i servizi informativi cercano anche di fornire, insieme ad ognuna delle citazioni, link a testi pieni o ad altri servizi: ma è stato evidenziato come in molti casi questi link di default non siano adeguati perché non sensibili al contesto dell'utente che li attiva [Van de Sompel and Beit-Arie 2001; Van de Sompel and Hochstenbach 1999a]; lo schema OpenURL è stato proposto proprio per affrontare questo problema, rendendo possibile che a fornire link ulteriori ed appropriati per una dato elemento informativo, su esplicita richiesta dell'utente, sia un soggetto esterno (una terza parte).

L'architettura OpenURL si basa sui seguenti concetti fondamentali:

• la collaborazione dei fornitori di informazione: i fornitori di informazione che supportano lo schema OpenURL inseriscono, con ogni citazione che inviano all'utente, un "gancio" (la OpenURL per quella citazione), cioè una richiesta HTTP il cui scopo è inviare ad un componente esterno metadati e identificatori relativi al lavoro citato, quando attivata dall'utente.
• L'esistenza di componenti di servizio autonomi rispetto ai fornitori di informazione: questi componenti di servizio sono il target (il punto di arrivo) del gancio fornito dai servizi informativi, ed il loro compito è fornire, a richiesta dell'utente, servizi estesi relativi al lavoro citato, usando i metadati e gli identificatori inviati col "gancio".
• L'esistenza di specifiche, che descrivano il formato del gancio: attualmente, tali specifiche sono costituite dalla bozza OpenURL [Van de Sompel, Hochstenbach, Beit-Arie 2000], la quale:
• descrive la sintassi perché la citazione ad un lavoro accademico possa venir codificata come concatenazione di coppie nome=valore
• descrive la sintassi perché gli elementi che descrivono il contesto in cui la citazione è fornita possano venir codificati come concatenazione di coppie nome=valore
• descrive il modo di trasformare questa informazione codificata in un link (richiesta HTTP): per esempio, nel caso, più comune, in cui la OpenURL venga codificata come richiesta HTTP GET, le coppie nome=valore diventano la <parte di ricerca> di una URL la cui parte http://<host>:<port>/<path> è l'indirizzo del componente di servizio esterno (si veda p.e. il formato di una URL http://<host>:<port>/<path>?<searchpart> in [Berners-Lee, Masinter, et al. 1994]).

Lo schema OpenURL, in quanto consente che, per una data citazione, i link ai vari servizi correlati vengano forniti da soggetti esterni che non possiedono il documento web contenente la citazione, è stato definito "uno schema di linking aperto per l'ambito informativo accademico su web" [Van de Sompel and Hochstenbach 1999a], dove "aperto" sta proprio ad evidenziare come lo schema dia all'utente la facoltà di rivolgersi, per i link ai testi pieni o ad altri servizi estesi relativi ad una citazione, ad un soggetto diverso da quello che fornisce la citazione.

E' importante notare come ad uno stesso lavoro accademico possano riferirsi diverse OpenURL, in quanto:

• la citazione di un lavoro scientifico, può essere espressa in modi diversi in diversi servizi informativi
• poiché cambiano i contesti in cui un lavoro scientifico viene citato, la descrizione degli elementi contestuali nella OpenURL è variabile.

Generalizzare lo schema OpenURL

Per una miglior comprensione può essere utile visualizzare lo schema OpenURL come un'architettura che permette all'utente, data una certa citazione, di evadere dalla dimensione dei link forniti di default dai servizi informativi, permettendogli di accedere ad un livello di servizi sovrapposti dove sia possibile chiedere ad un componente esterno di fornire, relativamente al lavoro accademico citato, link di servizio ulterirori o alternativi, ed appropriati, (p.e. figura 1 e 2 di [Van de Sompel and Beit-Arie 2001]); in questa architettura, le specifiche della OpenURL sono il collante che consente la interoperabilità tra i servizi informativi e il componente di servizio.

E' facile immaginare che una tale architettura possa essere estesa a citazioni fatte in generale su web, cioè a riferimenti non solo a materiale accademico ma anche a città, malattie, automobili, case, concetti astratti etc. Il pre-requisito fondamentale per questa estensione è l'esistenza di metadati e/o identificatori che descrivano l'elemento citato, il che è abbastanza comune dato che molte comunità hanno creato identificatori o schemi di metadati per ottenere interoperabilità tra i sistemi.

Queste "citazioni", a cui possono accompagnarsi link di default inseriti dall'autore, si possono considerare disposte sul piano di base del web; si immagini un utente che possa evadere da questa dimensione per raggiungere un piano di servizi sovrapposti dove sia possibile, relativamente ad un dato elemento citato, chiedere a servizi web specializzati di fornire link di servizio alternativi: questi link possono concepirsi come strade alternative attraverso l'web, fornite dinamicamente, a richiesta dell'utente, da soggetti esterni, cioè non dall'autore della pagina web in cui si trova la citazione; tali strade si pongono perciò in una dimensione di servizi sovrapposti, non sono disponibili nel documento web in cui occorre la citazione.

E' un dato di fatto che diverse compagnie e vari progetti hanno introdotto soluzioni finalizzate all'invio di servizi sovrapposti. Ne sono esempi lo strumento di ricerca e annotazione ThirdVoice, ora dismesso; il QuickClick di NBCi; l'agente Dialpad agent; la soluzione di "sessione di link" del PeP di Steve Hitchcock [Hitchcock and Hall 2001]; il servizio di link hypermedia della Microcosm, lo Smart Tags della Microsoft; i servizi basati su hypermedia di Dexter per il World Wide Web [Gronbak, Bouvin Niels Olof, et al. 1997]; e fino ad un certo punto anche il servizio "What's Related" di Netscape [Curtin, Ellison, et al. 1998].

Come nel caso dello schema OpenURL, queste soluzioni poggiano sull'esistenza di componenti di servizio che immagazzinano o generano informazioni di collegamento separate dai documenti web (p.e. [Halasz and Schwartz 1994]); e però non si conformano agli altri due concetti fondamentali dello schema OpenURL: la collaborazione degli autori del documento web nell'inserire uncini, e l'esistenza di specifiche formali per tale uncino. Piuttosto, queste soluzioni utilizzano tecniche di proxying/copia della schermata, costruite su:

• applicazioni ausiliarie proprietarie che pre-scandiscono la pagina web per trovarvi occorrenze di riferimenti ("citazioni") non strutturati a determinati tipi di elementi (p.e. usando tecniche di confronto con un dizionario).
• l'introduzione di richieste HTTP con struttura proprietaria che, per ogni elemento "citato" per cui il software di pre-scansione abbia trovato un match, puntino al componente di servizio della soluzione specifica.

Sulla base della veloce accettazione incontrata dall'approccio OpenURL in ambiente accademico, si può sperare anche nell'accettazione di un tale approccio generalizzato all'ambiente web in generale: si può immaginare che la collaborazione degli autori web (che cioè introducano nei loro documenti uncini interoperabili che permettano la fornitura di servizi di link da parte di soggetti esterni) si possa ottenere facilmente quando vengono utilizzati strumenti software per la "composizione" dinamica dei documenti web; per autori che usino procedure manuali il compito potrebbe essere molto meno banale, e l'accettazione potrebbe tra le altre cose dipendere dalla semplicità delle specifiche dell'uncino. Si può anche immaginare come l'adesione alle specifiche per l'uncino potrebbe contribuire a risolvere il problema della mancanza di persistenza dei link forniti su web (p.e. si veda [Lawrence, Pennock, et al. 2001] sulla mancanza di persistenza dei riferimenti URL ai lavori accademici, e [Phelps and Wilenski 2000] per un approccio per rendere più robusti gli iperlink).

Ancora, si può immaginare come l'estensione dei concetti OpenURL potrebbe facilitare la vita alle compagnie e ai progetti sopra menzionati, rendendo le loro soluzioni interoperabili e facendo crescere l'offerta di servizi innovativi, finalizzati a fornire dinamicamente vie alternative attraverso l'web.

Infine, un approccio collaborativo risulterebbe probabilmente più attraente per gli autori di documenti web, i quali possono sentirsi minacciati da approcci intrusivi del tipo "copia della schermata" che offuscano l'autorialità dei documenti, mentre sarebbero rassicurati da un modello in cui la decisione su quali "citazioni" debbano essere soggette alla fornitura di servizi sovrapposti, restasse sotto il loro controllo.

Il modello Bison-Futé

Nel prosieguo di questo articolo verrà introdotto il modello Bison-Futé e i suoi componenti: si tratta di uno schema concettuale che generalizza i concetti OpenURL. Lo scopo del modello Bison-Futé è permettere a soggetti esterni (terze parti) di fornire servizi alternativi in relazione ad elementi citati su web, utilizzando un approccio direttamente derivato dallo schema OpenURL. Il termine Bison-Futé si riferisce al nome dato in Francia alle strade alternative raccomandate dal governo a chi preferisce evitare le autostrade: insomma, i link di default inseriti dall'autore web corrispondono alle autostrade, mentre i servizi alternativi per le citazioni web corrispondono alle strade alternative.

Si richiama l'attenzione del lettore sulle relazioni esistenti tra i concetti introdotti di seguito e gli sforzi in corso nell'ambito dei lavori sul web semantico [Berners-Lee, Hendler and Lassila 2001), sulla ricerca Open Hypermedia (si veda sopra, e, p.e., [Carr, Bechofer and Goble 2001]), e sulla gestione della conoscenza ("Knowledge Management", p.e. si veda <http://www.aktors.org/>). La nozione di annotazione di documenti informali con descrittori formali di concetti, propria del web semantico, è una relazione di speciale rilevanza per le idee qui presentate, pur restando il fatto che tale ricerca è incentrata sull'interrogazione e non sul collegamento come invece la nostra.

Tuttavia, gli autori hanno qui fatto la scelta esplicita di descrivere i concetti di un collegamento aperto e sensibile al contesto per l'web, partendo da una prospettiva concreta, e cioè dall'applicazione OpenURL esistente, leggera ed efficace. Questo approccio sfrutta l'esperienza di sviluppo di tale applicazione per provare ad identificare gli elementi essenziali richiesti per facilitare, in ambito web, il linking aperto e sensibile al contesto, ed derivare dal concreto un modello più astratto. Inoltre, vengono inevitabilmente in mente le possibili relazioni con i linguaggi che descrivono concetti quali RDF o RDFS: ma gli autori hanno scelto di descrivere il modello indipendentemente da tali linguaggi, focalizzandosi piuttosto sugli strumenti essenziali che un linguaggio deve offrire per essere applicabile nell'abito del linking aperto e context-sensitive. L'intento di queste scelte non è certo di ignorare i lavori in corso: al contrario, di contribuire agli sforzi sopra menzionati, aggiungendovi un ingrediente derivato da un'applicazione effettivamente sviluppata.

Natura della generalizzazione

Il modello Bison-Futé è una generalizzazione del corrente schema OpenURL sotto diversi aspetti:

nel modello Bison-Futé, il concetto di linking aperto e sensibile al contesto per citazioni fatte nelle pagine web, viene generalizzato al di là dell'ambiente informativo accademico, arrivando a comprendere, in quanto citati nelle pagine web, i lavori pubblicati in generale (CD, CD-Rom, file audio, video etc.), gli oggetti (città, automobili, persone, aziende etc.) e i concetti astratti: nel modello Bison-Futé, questi elementi che vengono "citati" sono chiamati "referenti"

le specifiche della OpenURL permettono di descrivere solo 3 tipi di entità: l'oggetto citato (OBJECT-DESCRIPTION), il servizio informativo in cui l'elemento è citato (ORIGIN-DESCRIPTION), e il componente di servizio che fornirà i servizi estesi (BASE-URL). Comunque, lo sviluppo di OpenURL ha mostrato che ci sono altre entità che potrebbero essere descritte come parti del contesto complessivo in cui avviene una richiesta di fornitura di servizi contestualizzati: di conseguenza, il modello Bison-Futé introduce le seguenti nuove entità: l'utente che richiede i servizi ("richiedente"), il tipo di servizio richiesto ("tipo di servizio"), e l'entità informativa che effettivamente cita ("entità citante"). A questo scopo, nel modello Bison-Futé viene introdotto il termine ContextObject: esso è un costrutto che contiene la descrizione di tutte le entità importanti per la fornitura di servizi contestuali per un elemento citato (figura 1).

Secondo le specifiche correnti, la OpenURL per un elemento citato non deve necessariamente contenere fisicamente la citazione completa: tali specifiche permettono due forme di trasferimento dell'informazione:

• per valore: l'informazione viene fisicamente inviata all'interno della richiesta HTTP ("zona dei metadati dell'oggetto", "zona dell'identificatore globale")
• per riferimento: all'interno della richiesta HTTP viene inviato un puntatore all'informazione, e sono i componenti di servizio che devono risolverlo per arrivare all'informazione effettiva ("zona dell'identificatore globale", "zona dell'identificatore locale").

In Bison-Futé questa proprietà viene estesa a tutte le entità che descrivono il contesto, mentre l'approccio per riferimento viene reso più flessibile: secondo le correnti specifiche OpenURL, l'interpretazione di un puntatore richiede intelligenza da parte del componente di servizio che deve risolverlo in metadati: il modello Bison-Futé prevede puntatori che possano essere risolti senza alcuna intelligenza aggiuntiva da parte del componente di servizio.

Ancora, una OpenURL consente che un elemento citato venga descritto per mezzo di identificatori e/o metadati conformi allo schema definito nelle specifiche OpenURL, per l'appunto focalizzato sui lavoro accademici; nel modello Bison-Futé questa proprietà viene estesa a tutte le entità che descrivono il contesto, e viene inoltre risolta l'ambiguità esistente tra identificatori elementi e identificatori di metadati sugli elemento. Infine, poiché l'ambito di Bison-Futé va al di là del dominio dell'informazione accademica, per la descrizione delle entità vengono consentiti altri formati di metadati.

In Bison-Futé viene introdotto il termine "descrittore" per far riferirsi ad un modo uniforme di descrivere le entità coinvolte nella fornitura contestuale di servizi per un elemento citato: un descrittore permette di specificare le entità coinvolte nel processo della fornitura contestuale di servizi, secondo modalità specificatamente disegnate per ottimizzare il processo (figura 2).

Le specifiche OpenURL descrivono le modalità per fornire, all'interno di una richiesta HTTP, informazioni su entità, sotto forma di sequenze di coppie nome=valore; ma, come ha mostrato l'esperienza di sviluppo della OpenURL, talvolta sarebbero desiderabili altri schemi di codifica, p.e. nei casi in cui deve essere fornita informazione su una pluralità di elementi citati: le nozioni introdotte nel modello Bison-Futé restano perciò svincolate da ogni codifica specifica, così come la descrizione delle entità del ContexObject (per mezzo dei descrittori) è svincolata dalla sua codifica come richiesta HTTP: la richiesta HTTP è indicata separatamente, come "Link a risoluzione aperta"

I concetti Bison-Futé

In maniera parallela alla descrizione data sopra dei concetti fondamentali dello schema OpenURL, si presentano di seguito i concetti del modello Bison-Futé, introducendone contemporaneamente la terminologia specifica, che verrà poi spiegata con maggiori dettagli nel prosieguo del lavoro. Per facilitarne una miglior comprensione, la tavola 1 elenca la terminologia tipica della OpenURL, a fronte dei corrispondenti termini Bison-Futé

Il modello Bison-Futé si basa sui seguenti concetti fondamentali:

• la collaborazione degli autori dei documenti web: gli autori che desiderano supportare il modello Bison-Futé inseriscono, insieme ad ogni citazione a un "referente" (cioè ad un elemento citato) fornita all'utente, un "gancio", chiamato "ContexObject per quel referente". Un ContexObject è composto di diversi descrittori: il descrittore centrale è quello del referente, ma ci sono anche i descrittori delle entità che descrivono il contesto in cui il referente è citato (figura 1). Ogni descrittore può contenere metadati e/o identificatori, o informazioni che consentono di raggiungere metadati e/o identificatori (figura 2). Di solito il ContexObject è poi trasformato in una richiesta HTTP, chiamata "link a risoluzione aperta" per il referente dato. Lo scopo dell'inserimento del "link a risoluzione aperta" per una data citazione in una pagina web, è quello di inviare, quando attivato dall'utente, metadati e identificatori relativi al referente, e al contesto in cui il referente è citato, ad un soggetto esterno.
• L'esistenza di risolutori di soggetti esterni (terze parti): questi risolutori sono servizi web che vengono puntati dai (sono target dei) "link a risoluzione aperta": la loro funzione è inviare, su richiesta dell'utente, servizi relativi al referente che costituisce il nucleo del ContexObject (e perciò anche del "link a risoluzione aperta" derivato dal ContexObject). Fondamentalmente, un risolutore risolve il descrittore di un referente in servizi, nel contesto degli altri descrittori che costituiscono il ContexObject del referente suddetto.
• l'esistenza di specifiche per codificare descrittori, ContexObject e "link a risoluzione aperta".

Termini Bison-Futé

Il resto di questo articolo fornirà una descrizione più dettagliata dei nuovi termini introdotti nel modello Bison-Futé, specificatamente:

• entità
• descrittore
• ContextObject
• link a risoluzione aperta
• risolutore
• servizi.

L'articolo accademico citato nella tavola 2 (per cui è possibile reperire dettagli all'indirizzo:

http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&list_uids=
10942764&dopt=SGML) sarà usato come riferimento negli esempi successivi:

Un'entità è la "cosa" che viene specificata utilizzando un descrittore, in quanto passibile di essere citata autonomamente.

Un descrittore è il veicolo definito per specificare un'entità, secondo uno o più dei seguenti tipi:

• identificatore di entità: la combinazione della citazione di un dominio e dell'identificatore di entità unico all'interno del dominio citato
• identificatore di metadati: la combinazione della citazione di un dominio e dell'identificatore di metadati di entità unico all'interno del dominio citato.
• descrizione di metadati: la combinazione della citazione di uno schema di metadati e di una descrizione dell'entità espressa secondo lo schema di metadati citato
• puntatore ad una descrizione di metadati: la combinazione della citazione di uno schema di metadati e di un puntatore ai metadati dell'entità espressi secondo lo schema di metadati citato
• zona privata: contenuto non specificato, riservato per usi specifici di singole comunità e per le estensioni.

A commento di quanto sopra:

• la nozione di descrittore viene introdotta per permettere la citazione di un'entità per mezzo di un singolo costrutto; funzione del descrittore è rendere disponibili i metadati e gli identificatori dell'entità, e questo è perseguibile in modo esplicito (per valore) e/o implicito (per riferimento): in modalità esplicita, i metadati e gli identificatori sono fisicamente contenuti all'interno del descrittore, mentre in modalità implicita i metadati e gli identificatori sono semplicemente reperibili sulla base dell'informazione disponibile nel descrittore.
• Resta fuori dell'ambito di questo lavoro dare una definizione formale di "dominio" (namespace): in questo contesto, un "dominio" può semplicemente considerarsi una collezione di identificatori, ognuno dei quali sia unico all'interno della collezione stessa. Ovviamente ogni collezione è rigorosamente definita/circoscritta: o per mezzo della definizione formale di una sintassi a cui tutti gli identificari all'interno della collezione si conformano; oppure dal dizionario dei termini che costituiscono la collezione, o ancora dalle modalità di gestione, etc. Qualche esempio può aiutare la comprensione: si può parlare del dominio DOI, costituito da tutti gli identificatori di oggetti digitali; del dominio mailto di tutti gli indirizzi e.mail; del dominio HTTP di tutti gli indirizzi http; del dominio di tutte le stringhe di soggetto del MESH; del dominio di tutti i numeri di sistema in un DB bibliografico; del dominio UTC di tutti i momenti temporali che possono essere espressi per mezzo del W3C datetime specification.
• I descrittori possono essere codificati in molti modi diversi: ogni tecnica di codificazione costituisce un "formato di descrittore", il quale può essere considerato una struttura generale che permette di descrivere un'entità per mezzo di identificatori, metadati e puntatori ai metadati. Un formato di descrittore consente l'impiego elementi multipli dello stesso tipo, p.e. di zero o più identificatori di entità. Per un dato formato di descrittore, possono darsi più descrittori per ogni singola entità.
• Un formato di descrittore dipende dalla capacità di citare (di fare riferimento a) in modo non ambiguo gli schemi di metadati e i domini: certe applicazioni possono richiedere che tali riferimenti siamo interpretati a livello globale, e allora può essere necessaria l'esistenza di un'agenzia incaricata del mantenimento e della diffusione di tali convenzioni citazionali; per altre applicazioni può essere sufficiente che i riferimenti agli schemi di metadati e ai domini siano interpretati a livello locale, p.e. in un ambiente controllato o all'interno di una specifica comunità, e in questo caso non c'è bisogno di alcuna agenzia di mantenimento. In ogni modo è importante che un formato di descrittore permetta di distinguere tra casi locali e globali in modo non ambiguo.
• La differenza tra "identificatore di metadati" e "puntatore alla descrizione in metadati" sta nell'intelligenza necessaria per la loro risoluzione in metadati effettivi: un identificatore di metadati non può essere risolto senza intelligenza esterna aggiuntiva, p.e. senza la conoscenza di dove gli identificatori del dominio citato possono essere risolti; invece, il "puntatore alla descrizione in metadati" può sempre essere risolto senza aggiunta di intelligenza esterna.

Per uno sguardo più ravvicinato su che cosa sia una entità, si veda la tabella 3 che mostra alcuni esempi di entità, insieme agli elementi utilizzabili per creare un descrittore di esse, e i tipi di questi elementi.

In astratto, un ContexObject è una struttura per citare, per mezzo di un descrittore per ogni entità:

• una entità centrale chiamata referente
• varie entità che sono parte del contesto in cui il referente è citato

Come tale, il ContextObject è un contenitore di descrittori, al centro del quale sta il descrittore del referente.

La figura 1 è un'illustrazione della nozione del ContextObject. La figura 2 mostra le relazioni tra il ContextObject, le entità nel ContextObject, i descrittori per quelle entità e i tipi che possono essere usati per creare descrittori per quelle entità.

Figura 1: il ContextObject e le sue entità

Come per i descrittori, esistono diversi metodi di codifica del ContextObject; è importante notare che, nel modello Bison-Futé, il ContextObject per un dato referente non è una richiesta HTTP: l'effettiva codifica del ContextObject in una richiesta HTTP è il "link a risoluzione aperta" (OpenResolutionLink) per il referente dato - e, di nuovo, esistono diversi modi per generare un OpenResolutionLink da un ContextObject.

Un ContextObject può contenere descrittori per ognuna delle seguenti entità:

• il referente (referent), cioè l'entità citata: è nel nucleo del ContextObject, e in ogni ContextObject deve esserci almeno un referente; è proprio il descrittore del referente che dovrà essere risolto in servizi.
• Il risolutore (resolver), cioè il servizio web che risolverà il descrittore del referente in servizi: un risolutore deve capire gli OpenResolutionLink; nel ContextObject si rende necessario un "descrittore di risolutore" al momento in cui esso è codificato in un OpenResolutionLink (cioè in una richiesta HTTP).
• Il servizio citante (referrer), cioè il servizio web che fornisce la citazione al referente
• la entità citante (referring entity), cioè l'entità elementare che, all'interno del servizio citante, contiene la citazione al referente
• il richiedente (requester), cioè l'utente che chiede la risoluzione del descrittore del referente: si noti che il richiedente può essere tanto una persona che lavori da un dispositivo di rete quanto un programma software.
• il tipo di servizio (serviceType), cioè la natura della risoluzione richiesta: esso permette di specificare il tipo di servizio a cui mira il richiedente quando chiede la risoluzione di un descrittore di referente.

A commento dell'esempio 2:

• la nozione di ContextObject viene introdotta per poter citare, con un singolo costrutto, un referente insieme con il contesto in cui il referente è citato; all'interno di tale costrutto, ogni entità (il referente così come le entità contestuali) viene descritta per mezzo di un descrittore. Perciò la funzione del ContextObject è di rendere disponibili i metadati e gli identificatori tanto del referente quanto delle entità contestuale, in modo esplicito o implicito.
• Sebbene si ammetta in uno sviluppo concreto del ContexObject possano rendersi necessari dati di natura amministrativa (quali il timestamp, la versione etc.), questo aspetto viene lasciato fuori dal presente studio.
• E' ammissibile che certi formati di codifica del ContextObject possano permettere l'inclusione di referenti e risolutori multipli.
• Non si pone alcun vincolo su come il ContextObject possa venir assemblato, né da parte di quali soggetti: di fatto, può essere assemblato per fasi, dal servizio citante, da sistemi intermedi, dal browser dell'utente, etc. E comunque, poiché il modello Bison-Futé poggia sulla collaborazione degli autori dei documenti web, si assume che il servizio citante collabori fornendo un ContextObject che contenga almeno un descrittore del referente.
• Non si pone alcun vincolo su come il ContextObject possa venir codificato nella richiesta HTTP né da parte di quali soggetti: tale compito può essere svolto dal servizio citante, da un sistema intermedio, dal browser dell'utente, etc.

Un risolutore è un servizio web che può che può prendere in input un "link a risoluzione aperta" e fornire in output servizi relativi al referente in esso contenuto: esso cioè risolve il descrittore del referente (o i descrittori dei referenti) nel contesto degli altri descrittori contenuti nel "link a risoluzione aperta".

Ai fini di questo lavoro, la nozione di servizio viene lasciata indefinita, a parte il fatto che esso possa essere la risposta ad una richiesta di risoluzione. Si può immaginare che il modello Bison-Futé funzioni in modo tale da lasciare ai risolutori la decisione su che cosa si voglia considerare "servizio", che poi è il modo in cui effettivamente funziona lo schema OpenURL. Si potrebbe anche voler definire in modo formale le risposte alle richieste di risoluzione, ma ciò richiederebbe spingere lo schema di codifica dei "link a risoluzione aperta" verso la definizione di un protocollo - il che, però, ne restringerebbe l'applicabilità.

La codifica dei descrittori, dei ContextObjects, dei "link a risoluzione aperta" nel modello Bison-Futé

La descrizione sopra esposta del modello Bison-Futé e dei suoi concetti è astratta, e vederne un'istanza concreta può aiutarne la comprensione: i lettori interessati sono perciò incoraggiati a verificare come alcuni aggiustamenti all'attuale bozza di specifiche OpenURL possano condurre all'allineamento con i concetti generalizzati sopra esposti, facendo della OpenURL una delle possibili tecniche di codifica dei "link a risoluzione aperta", quella specifica per l'ambiente accademico; in particolare, è interessante notare come la OpenURL risulterebbe una tecnica di codifica che taglia fuori molta della ricchezza disponibile nel modello Bison-Futé per ottenere un buon livello di semplicità. Nelle correnti specifiche OpenURL il referente è specificato nella ObjectDescription, il servizio citante è specificato nella OriginDescription e il risolutore è specificato nella BaseURL. L'appendice C mostra le entità del ContextObject correntemente disponibili nelle specifiche OpenURL, e i tipi di descrittori attualmente usati nei descrittori di ognuna di queste entità.

Di seguito viene presentato un altro scenario in cui lo schema di codifica utilizzato per esprimere descrittori, ContextObjects e Link a risoluzione aperta risulta più ricco:

Tavola 4: brano di un documento HTML che contiene una citazione all'articolo della Tavola 2

La tavola 5 mostra i descrittori per la citazione sopra riportata, espressa secondo un "formato di descrittore" rudimentale il cui schema viene fornito nell'Appendice A. Nessuna pretesa viene avanzata sulla correttezza o applicabilità di tale schema, che serve qui solo per chiarire il concetto di descrittore e di "formato di descrittore".

l'Appendice B mostra un rudimentale formato di codifica per il ContextObjects costruito sul descriptor format dell'Appendice A. Non si avanza nessuna pretesa sulla correttezza e l'applicabilità dello schema, che serve qui solo a spiegare il concetto di ContextObject e di formato per la codifica di esso.

La tavola 6 riporta un brano di documento HTML in cui un servizio di informazione collaborativo (cioè un servizio citante) ha fornito un ContextObject minimo, espresso nei formati delle Appendici A e B, ed introdotto nel documento HTML a seguito della citazione: si noti che il ContextObject, così come viene fornito, non è attivabile cliccandoci sopra: non è ancora un "link a risoluzione aperta".

In questo scenario si ipotizza che il browser dell'utente possa chiamare una applicazione ausiliaria che renda cliccabili i ContextObject trovati in una pag. HTML: una tale applicazione ausiliaria esiste effettivamente in via sperimentale, e permette all'utente di configurare una lista di risolutori preferiti, un'immagine o parola da usarsi come ancora del "link a risoluzione aperta", dettagli della schermata che si apre cliccando sul "link a risoluzione aperta", etc.

La tavola 7 riporta lo stesso brano HTML della tavola 6, dopo l'intervento dell'applicazione ausiliaria: come si vede, il ContextObject è stato esteso e trasformato in un "link a risoluzione aperta", il quale ha la struttura di una richiesta POST in HTTP che punta ad un risolutore, in questo caso <http://sfx1.exlibris-usa.com/demo>; la parte <BODY> del messaggio inviato nel POST è un documento XML che si conforma allo schema XML dell'appendice B. Come si vede l'applicazione ausiliaria ha aggiunto al ContextObject alcuni descrittori contestuali: ha incluso l'indirizzo dei due risolutori in essa configurati, in modo tale che il risolutore puntato per primo (il primo citato nel ContextObject) possa passare all'altro risolutore, quando necessario, la richiesta di risoluzione del descrittore del referente: questo potrebbe per esempio accadere se il risolutore iniziale non fosse in grado di risolvere i descrittori del dominio DOI. L'applicazione ausiliaria ha anche aggiunto informazioni sul richiedente, includendone l'indirizzo e.mail e la URL LDAP URL [Howes and Smith 1996].

Conclusioni

In questo articolo sono stati introdotti concetti che possono costituire la base di una generalizzazione dello schema OpenURL al di là del settore delle citazioni accademiche; questo anche per rispondere al desiderio espresso dal documento di incarico alla NISO AX di "... tener presenti altre comunità informative nel cui ambito possa risultare utile un meccanismo generico per rendere disponibili a un componente di servizio identificatori e metadati...".

La generalizzazione descritta nell'ambito del modello Bison-Futé estende la nozione di collegamenti aperti e sensibili al contesto alle citazioni su web in generale.

L'introduzione dei concetti Bison-Futé non va interpretata come una proposta da cui far partire affrettatamente il processo di standardizzazione; al contrario, lo scopo è proporre uno schema astratto comune in cui il processo di standardizzazione possa trovare alimento.

Gli autori vogliono evidenziare che l'attuale processo di standardizzazione non può ignorare i seguenti aspetti:

• l'esistenza della bozza di specifiche per la OpenURL;
• il fatto che la bozza di specifiche sia già applicata nell'industria dell'informazione accademica;
• il fatto che l'alto livello di accettazione e adozione della corrente versione OpenURL è molto probabilmente dovuta alla sua facilità di implementazione;
• l'intenzione della NISO AX di arrivare in tempi relativamente brevi ad uno standard OpenURL applicabile nell'ambito del linking aperto da citazione in ambiente informativo accademico;
• l'evidente desiderio da parte dell'industria informativa, che siano evitati cambiamenti drammatici rispetto alla bozza corrente, per garantire continuità.

Insomma, il modello Bison-Futé, come presentato in questo contributo, dovrebbe essere considerata un piano architettonico per la costruzione di una grande casa, di cui lo schema OpenURL costituisca una delle molte stanze: gli autori suggeriscono che il comitato NISO AX si impegni a costruire questa stanza in conformità con il piano architettonico della casa.

Gli autori sperano che questo modello induca altre comunità informative ad esplorare praticamente il potenziale del linking aperto: il grande entusiasmo intorno allo schema OpenURL in ambiente informativo accademico dovrebbe essere un incoraggiamento; auspicano inoltre che il presente contributo solleciti una ricerca verso una sinergia tra gli sforzi di linking da parte della comunità della biblioteca digitale, e le altre comunità che stanno lavorando su analoghe problematiche.

Riferimenti bibliografici

Berners-Lee, Tim, L. Masinter, and M. McCahill. 1994. RFC1738: Uniform Resource Locators (URL). <http://search.ietf.org/rfc/rfc1738.txt?number=1738>.

Berners-Lee, Tim, James Hendler and Ora Lassila. 2001. "The Semantic Web." Scientific American. May 2001. (URL). <http://www.sciam.com/2001/0501issue/0501berners-lee.html>.

Caplan, Priscilla and Arms, William Y. 1999. "Reference linking for journal articles." D-Lib Magazine. 5(7/8). <http://www.dlib.org/dlib/july99/caplan/07caplan.html>.

Carr, Leslie, Wendy Hall, Sean Bechofer and Carole Goble. 2001. "Conceptual inking: ontology-based open hypermedia." Tenth International World Wide Web Conference. May 1-5 2001, Hong Kong. <http://www10.org/cdrom/papers/pdf/p246.pdf>.

Curtin, Matt, Gary Ellison, and Doug Monroe. 1998. "What's Related?" Everything but your privacy. <http://www.interhack.net/pubs/whatsrelated/>.

Gronbak, Kaj, Niels Olof Bouvin, and Lennert Sloth. "Designing Dexter-Based Hypermedia Services for the World Wide Web." Proceedings of the eighth ACM conference on Hypertext. April 6 - 11, 1997, Southampton United Kingdom. ACM, p. 146-56. <http://www.acm.org/pubs/citations/proceedings/hypertext/267437/p146-gronbaek/>.

Halasz, F. and M. Schwartz. 1994. "The Dexter Hypertext Reference Model." Communications of the ACM 37, no. 2 (1994): p. 30-39. <http://www.acm.org/pubs/citations/journals/cacm/1994-37-2/p30-halasz/>.

Hitchcock, Steve and Wendy Hall. 2001. "How dynamic e-journals can interconnect open access archives." Paper prepared for ElPub conference, Canterbury, July 2001. <http://www.ecs.soton.ac.uk/~sh94r/elpub01.pdf>.

Howes, T and M. Smith. 1996. RFC1959: An LDAP URL Format. <http://www.ietf.org/rfc/rfc1959.txt?number=1959>.

Lawrence, Steve and others. 2001. "Persistence of Web References in Scientific Research." Computer. 34(2). p. 26-31. <http://ieeexplore.ieee.org/iel5/2/19496/00901164.pdf>.

Phelps, Thomas A. and Robert Wilensky. 2000. "Robust Hyperlinks: Cheap, Everywhere, Now ." Lecture Notes in Computer Science. Proceedings of Digital Documents and Electronic Publishing, Munich, Germany, 13-15 September 2000. <http://www.cs.berkeley.edu/~phelps/Robust/papers/RobustHyperlinks.html>.

Van de Sompel, Herbert and Oren Beit-Arie. 2001. "Open Linking in the Scholarly Information Environment Using the OpenURL Framework." D-Lib Magazine. 7(3). <http://www.dlib.org/dlib/march01/vandesompel/03vandesompel.html>.

Van de Sompel, Herbert and Patrick Hochstenbach. 1999a. "Reference Linking in a Hybrid Library Environment. Part 1: Frameworks for Linking." D-Lib Magazine. 5(4). <http://www.dlib.org/dlib/april99/van_de_sompel/04van_de_sompel-pt1.html>.

Van de Sompel, Herbert and Patrick Hochstenbach. 1999b. "Reference Linking in a Hybrid Library Environment. Part 2: SFX, a Generic Linking Solution." D-Lib Magazine. 5(4). <http://www.dlib.org/dlib/april99/van_de_sompel/04van_de_sompel-pt2.html>.

Van de Sompel, Herbert and Patrick Hochstenbach. 1999c. "Reference Linking in a Hybrid Library Environment. Part 3: Generalizing the SFX Solution in the "SFX@Ghent & SFX@LANL" experiment." D-Lib Magazine. 5(10). <http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html>.

Van de Sompel, Herbert, Patrick Hochstenbach, and Oren Beit-Arie. May 2000. OpenURL Syntax Description. <http://www.sfxit.com/openurl/openurl.html>.

Appendice A: Un esempio di formato di descrittore

Appendice B: un esempio di formato di ContextObject

[*] Trad. di: Herbert Van de Sompel, Oren Beit-Arie, Generalizing the OpenURL Framework beyond References to Scholarly Works. The Bison-Futé Model, "D-Lib Magazine" 7, 7/8 (luglio/agosto 2001).
Testo originale su <http://mirrored.ukoln.ac.uk/lis-journals/dlib/dlib/dlib/july01/vandesompel/07vandesompel.html>.
Traduzione italiana a cura di Cinzia Bucchioni per la Commissione Nazionale Università e Ricerca dell'AIB, con l'autorizzazione degli Autori e della Rivista.
Nota del Traduttore: si sono tralasciati Abstract e Acknowledgements.

Copyright AIB 2003-01-08, ultimo aggiornamento 2024-02-09 a cura di Serafina Spinelli
URL: http://www.aib.it/aib/commiss/cnur/trsomp5.htm3

AIB-WEB | Le Commissioni | Commissione università ricerca