[AIB]

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ì:

"... dobbiamo 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..."

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:

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:

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:

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:

Ambito

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"

Contesto

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).

Schemi

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:

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).

Codifica

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é

OpenURL framework

Schema OpenURL

Modello Bison-Futé

Web-based scholarly information environment

(ambiente dell'informazione accademica su web)

Web in general

(web in generale)

referenced scholarly work

(lavoro scientifico citato)

referent

(referente)

citation to a scholarly work

(citazione a un lavoro scientifico)

citation to a referent

(citazione a un referente)

hook for citation to scholarly work = OpenURL :

(gancio per una citaz. a un lavoro scient.=OpenURL)

hook for citation to referent = ContextObject :

(gancio per una citaz. a un referente=ContextObject)

* standardized reference to a work

(citazione standardizzata a un lavoro/articolo)

* descriptor of a referent

(descrittore di un referente)

* standardized reference to contextual elements

(citazione standardizzata a elementi contestuali)

* descriptors of contextual entities

(descrittori di entità contestuali)

* hook turned into link = OpenURL

(gancio trasformato in link=OpenURL)

hook turned into link = OpenResolutionLink

(gancio trasformato in link=Link a risoluz. aperta)

service component

(componente di servizio)

resolver

(risolutore)

extended services; reference links

(servizi estesi, link a full text)

services

(servizi)

the referenced scholarly work; the service component which is the target of the OpenURL; the information service providing the OpenURL

(il lavoro scientifico citato; il componente di servizio puntato dalla OpneURL; la risorsa informativa che emette la OpenURL)

Entities

(entità)

Tavola 1: un confronto tra i termini usati nello schema OpenURL e nel modello Bison-Futé

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

Termini Bison-Futé

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

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:


Moll JR, Olive & M, Vinson C. Attractive interhelical electrostatic interactions in the proline- and acidic-rich region (PAR) zipper subfamily preclude heterodimerization with other basic leucine zipper subfamilies. J Biol Chem. 2000 Nov 3 ; 275(44):34826-32.

Tavola 2: una citazione ad un articolo: l'articolo sarà usato come referente negli esempi successivi

Entità, descrittore

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:

L'articolo accademico citato nella Tavola 2 è una entità, perché per esso è possibile creare un descrittore. Di fatto, in un descrittore per questa entità, possono essere inclusi uno o più dei seguenti tipi:

  • entity-id: se p.e. l'entità ha associato un DOI (digital object identifier), la citazione di dominio può essere doi e l'identificatore all'interno di tale dominio è 10.1074/jbc.M004545200
  • metadata-id: se, p.e., l'entità è indicizzata in PubMed e la registrazione dei suoi metadati in PubMed ha un identificatore pubmed unico, la citazione di dominio può essere pmid e l'identificatore all'interno di tale dominio è 10942764.
  • metadata-description: se, p.e., per questa entità PubMed fornisce descrizioni formulate secondo determinati schemi di metadati, la citazione dello schema può essere PubMedSGML e il record di metadati PubMed formulato secondo tale schema è la descrizione dell'entità.
  • metadata-description-pointer: Di nuovo, la citazione allo schema di metadati può essere PubMedSGML, nel qual caso il puntatore è http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&list_uids=10942764&dopt=SGML

Esempio 1: un'illustrazione della nozione di descrittore, per l'entità costituita dall'articolo citato nella Tavola 2

A commento di quanto sopra:

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.

entità

Il descrittore può essere costruito sulla base di

tipo

Journal article

DOI

entity-id

Economics journal article

EconLit record

metadata-description

Medical journal article

PubMed identifier

metadata-id

Journal

MARC record

metadata-description

Journal

ISSN number

entity-id

Book

ONIX description

metadata-description

Book

ISBN number

entity-id

Book in a library

Call-number

entity-id

Book in a library

MARC holdings record

metadata-description

Person

Person's e-mail address

entity-id

Person's home address

SRI Indicode identifier

entity-id

Person affiliated with a university

LDAP URL leading into the institutional directory

metadata-description-pointer

Preprint

OAI identifier

metadata-id

Economical author

HoPEc record

metadata-description

Printed music publication

ISMN number

entity-id

Company in the information industry

SAN code

entity-id

Company delivering web-services

UDDI identifier

entity-id

Company involved in EDI

D&N DUNS number

entity-id

Astronomical object

SIMBAD object identifier

entity-id

City in the US

US ZIP code

entity-id

Digital audio file

Relatable TRM fingerprint

entity-id

Economics subject

JeL classification subject descriptor

entity-id

Medical concept

MESH subject heading

entity-id

Web server

HTTP address

entity-id

Region on earth

CSDGM record

metadata-description

Moment in time

UTC datetime

entity-id

Tavola 3: entità ed esempi di descrittori

ContextObject, Link a risoluzione aperta (OpenResolutionLink)

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

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à:

L'articolo citato nella Tavola 2 può essere considerato un referente di un ContextObject. Invero, fin qui si è dimostrato soltanto che è possibile creato un descrittore per esso; ma fare dell'articolo il referente di un ContextObject fornito in un documento web insieme con una citazione informale del referente, spiana la strada alla fornitura di servizi per quell'articolo. Inoltre, il ContextObject può contenere descrittori di altre entità che descrivano il contesto in cui la citazione è fatta. Per esempio:

  • The resolver: The resolver è un servizio web, perciò nel ContextObject il descrittore più diretto per il risolutore sarà la combinazione dell'identificatore del dominio di tutti gli indirizzi HTTP - appunto HTTP - e dell'identificatore del servizio all'interno del dominio HTTP, p.e. sfxserv.rug.ac.be/menu, che è un server SFX all'Università di Ghent
  • The referrer and the referring-entity: la citazione della Tavola 2 si trova in un articolo di periodico accessibile attraverso il Protein Science journal web-service di HighWire Press. Se in questo articolo citante viene fornito un ContextObject, insieme con la citazione dell'articolo citato nella Tavola 2, allora ovviamente, questo secondo articolo costituisce il referente del ContextObject, mentre l'articolo citante costituisce l'entità citante, e poiché si tratta di un articolo in un periodico medico, il suo descrittore potrebbe essere di tipo metadata-id, e potrebbe consistere di una citazione del dominio PubMed - pmid - unito all'identificatore PubMed dell'articolo citante - 11344333. Il servizio citante (referrer) in the ContextObject indica la risorsa complessiva in cui è citato il referente; p.e., il servizio citante potrebbe essere il Protein Science journal web-service oppure il HighWire Press web-site.
  • The requester: aiuta pensare al richiedente come all'utente che fa clicks su un OpenResolutionLink per chiedere servizi. Un descrittore per l'utente nel ContextObject, potrebbe essere basato sul suo indirizzo e-mail: tale descrittore sarebbe del tipo entity-id, e sarebbe la combinazione dell'identificatore del dominio di tutti gli indirizzi e-mail - cioè mailto - e dell'indirizzo e-mail stesso, p.e. herbertv@cs.cornell.edu. Ma un descrittore per questo utente potrebbe essere costruito anche su una voce in un elenco LDAP, nel qual caso, il descrittore potrebbe essere di tipo metadata-description-pointer e consistere nella combinazione di un identificatore di schema di metadati - e.g., inetperson.org, (un comune schema LDAP) - e in un puntatore dentro l'elenco LDAP che usa tale schema, p.e. ldap://ldap.cs.cornell.edu:389/herbertv.
  • The serviceType: Il Tipo di servizio è introdotto per permettere di identificare il tipo di servizio richiesto sulla base della risoluzione del descrittore del referente. Considerati i problemi sottesi alla descrizione univoca dei tipi di servizio, può risultare difficile assegnare ai Tipi di servizio degli identificatori che siano interpretabili a livello globale. Tuttavia, all'interno di un ambiente controllato, è possibile assegnare identificatori locali utilizzabili per costruire descrittori. P.e., local:scholarly-services potrebbe essere l'identificatore di un dominio (namespace) locale, nel cui ambito l'identificatore searchweb può essere interpretato come il servizio che lancia una ricerca su un motore di ricerca web utilizzando le parole significative del titolo del referente.

Esempio 2: un'illustrazione della nozione di ContextObject: il referente è l'articolo citato nella Tavola 2

A commento dell'esempio 2:

Figura 2: un ContextObject può contenere 6 entità; ognuna delle quali è specificata per mezzo di un descrittore; ogni descrittore è composto da uno o più dei 5 "tipi di descrittori" (descriptor-types)

Risolutore, servizio

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:


<p>
Moll JR, Olive & M, Vinson C. Attractive interhelical electrostatic interactions in the proline- and acidic-rich region (PAR) leucine zipper subfamily preclude heterodimerization with other basic leucine zipper subfamilies. J Biol Chem. 2000 Nov 3 ; 275(44):34826-32. <a href=http://dx.doi.org/10.1074/jbc.M004545200>full text</a>
</p>

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".

<descriptor>
<entity-id>
<namespace-identifier>doi</namespace-identifier>
<identifier>10.1074/jbc.M004545200</identifier>
</entity-id>
</descriptor>

(Si ipotizza qui che esista una agenzia di mantenimento che registri e diffonda la corrispondenza tra il dominio degli identificatori doi e il dominio DOI)

<descriptor>
<metadata-description>
<metadata-format-identifier>openurl</metadata-format-identifier>
<metadata>
<aulast>Moll</aulast>
<auinit>JR</auinit>
<issn>0021-9258</issn>
<volume>275</volume>
<issue>44</issue>
<spage>34826</spage>
<date>2000-11-03</date>
</metadata>
</metadata-description>
<metadata-id>
<metadata-namespace-identifier>pmid</metadata-namespace-identifier>
<metadata-identifier>10942764</metadata-identifier>
</metadata-id>
</descriptor>

(Si ipotizza qui che esista una agenzia di mantenimento che registri e diffonda la corrispondenza tra openurl e http://www.sfxit.com/openurl/openurl.html , così come tra pmid e il dominio degli identificatori PubMed)

<descriptor>
<metadata-description-pointer>
<metadata-format-identifier>PubMedSGML</metadata-format-identifier>
<metadata-pointer>http://www.ncbi.nlm.nih.gov/
entrez/query.fcgi?cmd=Retrieve&

db=PubMed&list_uids=10942764&dopt=SGML
</metadata-pointer >
</metadata-description-pointer>
</descriptor>

(Si ipotizza qui che esista un'agenzia di mantenimento che registri pubblicamente la corrispondenza tra PubMedSGML e <http://www.ncbi.nlm.nih.gov/entrez/query/static/PubMed.dtd>)

Tavola 5: esempi di descrittori per l'articolo citato nella Tavola 2

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".


<p>
Moll JR, Olive & M, Vinson C. Attractive interhelical electrostatic interactions in the proline- and acidic-rich region (PAR) leucine zipper subfamily preclude heterodimerization with other basic leucine zipper subfamilies. J Biol Chem. 2000 Nov 3 ; 275(44):34826-32. <a href="http://dx.doi.org/10.1074/jbc.M004545200">full text</a>
<ContextObject><referent-block><referent><entity-id>
<namespace-identifier>doi</namespace-identifier>
<identifier>10.1074/jbc.M004545200</identifier></referent>
</referent-block></ContextObject>

</p>

Tavola 6: un documento HTML con un ContextObject fornito da un servizio web collaborativo (servizio citante)

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.


<p>
Moll JR, Olive & M, Vinson C. Attractive interhelical electrostatic interactions in the proline- and acidic-rich region (PAR) leucine zipper subfamily preclude heterodimerization with other basic leucine zipper subfamilies. J Biol Chem. 2000 Nov 3 ; 275(44):34826-32. <a href=http://dx.doi.org/10.1074/jbc.M004545200>full text</a>
<form name="ContextObject_1" action="http://sfx1.exlibris-usa.com/demo" method="POST" target="_new"><input type="hidden" name="OpenResolutionLink" value="
<?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;>
<ContextObject>
<header>
<resolver>
<entity-id>
<namespace-identifier>http</namespace-identifier>
<identifier>sfx1.exlibris-usa.com/demo</identifier>
</entity-id>
</resolver>
<resolver>
<entity-id>
<namespace-identifier>http</namespace-identifier>
<identifier>sfx.rug.ac.be/menu</identifier>
</entity-id>
</resolver>
<requester>
<entity-id>
<namespace-identifier>mailto</namespace-identifier>
<identifier>herbertv@cs.cornell.edu</identifier>
</entity-id>
<metadata-description-pointer>
<metadata-format-identifier>inetorgperson.schema</metadata-format-identifier>
<metadata-pointer>ldap://ldap.cs.cornell.edu:389/herbertv</metadata-pointer>
</metadata-description-pointer>
</requester>
</header>
<referent-block>
<referent>
<entity-id>
<namespace-identifier>doi</namespace-identifier>
<identifier>10.1074/jbc.M004545200</identifier>
</entity-id>
</referent>
</referent-block>
</ContextObject>" />
<a href="javascript:document.forms.ContextObject_1.submit();">more services</a>
</form>

</p>

Tavola 7: brano HTML con un OpenResolutionLink

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:

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

<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:desc=" http://www.niso.org/descriptor_format"
targetNamespace="http://www.niso.org/descriptor_format"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<element name="descriptor" type="desc:descriptor-type"/>

<complexType name="descriptor-type">
<sequence>
<element name="entity-id" minOccurs="0" maxOccurs="unbounded" type="desc:entity-id-type"/>
<element name="metadata-id" minOccurs="0" maxOccurs="unbounded" type="desc:metadata-id-type"/>
<element name="metadata-description" minOccurs="0" maxOccurs="unbounded" type="desc:metadata-description-type"/>
<element name="metadata-description-pointer" minOccurs="0" maxOccurs="unbounded" type="desc:metadata-pointer-type"/>

<element name="private-zone" minOccurs="0" maxOccurs="unbounded" type="desc:private-zone-type"/>
</sequence>
</complexType>

<complexType name="entity-id-type">
<sequence>
<element name="namespace-identifier" minOccurs="1" maxOccurs="1" type="identifier-type"/>
<element name="identifier" minOccurs="1" maxOccurs="1" type="string"/>
</sequence>
</complexType>

<complexType name="metadata-id-type">
<sequence>
<element name="metadata-namespace-identifier" minOccurs="1" maxOccurs="1" type="identifier-type"/>
<element name="metadata-identifier" minOccurs="1" maxOccurs="1" type="string"/>
</sequence>
</complexType>

<complexType name="metadata-description-type">
<sequence>
<element name="metadata-format-identifier" minOccurs="1" maxOccurs="1" type="identifier-type"/>
<element name="metadata" minOccurs="1" maxOccurs="1" type="metadata-type"/>
</sequence>
</complexType>

<complexType name="metadata-pointer-type">
<sequence>
<element name="metadata-format-identifier" minOccurs="1" maxOccurs="1" type="identifier-type"/>
<element name="metadata-pointer" minOccurs="1" maxOccurs="1" type="anyURI"/>
</sequence>
</complexType>

<complexType name="private-zone-type">
<sequence>
<any namespace="##other" processContents="lax"/>
</sequence>
</complexType>

<simpleType name="identifier-type">
<restriction base="string">
<pattern value="[a-zA-Z0-9]+"/>
<element name="metadata" minOccurs="1" maxOccurs="1" type="metadata-type"/>
</restriction>
</simpleType>

<complexType name="metadata-type">
<sequence>
<any namespace="##other" processContents="lax"/>
</sequence>
</complexType>

</schema>

Appendice B: un esempio di formato di ContextObject

<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:desc=" http://www.niso.org/descriptor_format"
xmlns:cont=" http://www.niso.org/contextobject_format"
targetNamespace="http://www.niso.org/contextobject_format"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<element name="ContextObject" type="cont:ContextObject-type"/>

<complexType name="ContextObject-type">
<sequence>
<element name="header" minOccurs="0" maxOccurs="1" type="cont:header-type"/>
<element name="referent-block" minOccurs="1" maxOccurs="unbounded" type="cont:referent-block-type"/>
</sequence>
</complexType>

<complexType name="header-type">
<sequence>
<element name="resolver" minOccurs="0" maxOccurs="unbounded" type="desc:descriptor-type"/>
<element name="requester" minOccurs="0" maxOccurs="1" type="desc:descriptor-type"/>
</sequence>
</complexType>

<complexType name="referent-block-type">
<sequence>
<element name="referent" minOccurs="1" maxOccurs="1" type="desc:descriptor-type"/>
<element name="referrer" minOccurs="0" maxOccurs="1" type="desc:descriptor-type"/>
<element name="referring-entity" minOccurs="0" maxOccurs="1" type="desc:descriptor-type"/>
<element name="serviceType" minOccurs="0" maxOccurs="1" type="desc:descriptor-type"/>
</sequence>
</complexType>

</schema>

 

Appendice C : Relazioni tra le attuali specifiche OpenURL e la nozione di ContextObject del modello Bison-Futé

ContextObject

entity

available in OpenURL?

1 or more

descriptor

     

entity-id

metadata-id

metadata-desc

metadata-desc-ptr

private-zone

             

referent

yes (OBJECT-DESCRIPTION)

More

yes (GLOBAL-IDENTIFIER-ZONE). no distinction between entity-id and metadata-id

yes (OBJECT-METADATA-ZONE). single metadata scheme

no

yes (LOCAL-IDENTIFIER-ZONE)

resolver

yes (BASE-URL)

1

yes (BASE-URL)

-

-

-

-

referrer

yes (ORIGIN-DESCRIPTION)

1

yes (ORIGIN-DESCRIPTION)

-

-

-

-

referring entity

no

-

-

-

-

-

-

requester

no

-

-

-

-

-

(*)

serviceType

no

-

-

-

-

-

(*)

(*) Sebbene la nozione di requester (richiedente) e di ServiceType (tipo di servizio) non siano esplicitamente previste nella attuale bozza di specifiche OpenURL, la sua "local-identifier-zone" (zona dell'identificatore locale) è stata spesso usata impropriamente per contenere tali informazioni.


[*] 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