INTRODUZIONE AD AIRE/SFX® Lucia Soranzo Padova ../9/2005

Indice I parte Web e linking : problemi nelle biblioteche accademiche Strutture di linking chiuse Linking ai servizi estesi Problema della copia appropriata e dei servizi estesi appropriati Strutture di linking aperte e sensibili al contesto: il progetto SFX Che cos’è l’OpenURL? Componenti fondamentali dello schema OpenURL 1.0 Lo schema OpenURL nell’ambiente dell’informazione accademica OpenURL: il ContextObject OpenURL 0.1 a confronto con il ContextObject Esempi di OpenURL II parte SFX SFX: un po’ di storia Fasi ed elementi dell’implementazione di AIRE/SFX SFX: il meccanismo alla base Menu dei servizi di SFX V3 La ricerca in una banca dati La ricerca con CitationLinker Il KnowledgeBase di SFX Sources Target, target services e object portfolio Service: collegamento tra source e target Strumenti per i bibliotecari Statistiche Bello, ma.. Sviluppi di SFX

Web e linking : problemi nelle biblioteche accademiche Cresce in modo incontrollato la documentazione disponibile in web Gli utenti chiedono di recuperare velocemente informazioni da fonti autorevoli I bibliotecari hanno bisogno di strumenti per aiutare l’utente nell’accesso alle risorse Le biblioteche non possono intervenire sui link Nascono soluzioni proprietarie con alti costi di mantenimento Le collezioni non sono usate in modo ottimale L’enfasi è solo sul link al full text Il servizio offerto non è all’altezza della richiesta

Web e linking : problemi nelle biblioteche accademiche La ricerca di un articolo nella biblioteca ibrida Gli articoli compaiono in molteplici fonti, perciò bisogna consultare molti repertori e database per localizzarne il testo completo. Alcuni database contengono il full-text di articoli selezionati e altri solo il record bibliografico. L’attività di ricerca di un documento può prevedere vari passaggi: 1. Localizzare le citazioni di articoli di periodico Cercando nei cataloghi di periodici o un database elettronico si crea una lista di articoli sull’argomento di interesse. Quando si trovano riferimenti utili bisogna accertarsi di scrivere o stampare i dati sufficienti a recuperarli in seguito. (cioè: titolo del periodico, volume, pagine e anno di pubblicazione). 2. Decodificare i titoli abbreviati A volte, nei database bibliografici e negli indici, i titoli sono abbreviati. Prima di localizzare il periodico il titolo va svolto in forma completa. 3. Determinare se l’articolo è disponibile in formato elettronico Alcuni database hanno link agli articoli full-text. Se un database non fornisce il full-text, bisogna controllare il catalogo dei periodici a stampa ed elettronici. 4. Determinare se l’articolo è disponibile in formato cartaceo La ricerca nel catalogo della biblioteca determina se e quale biblioteca è abbonata al giornale. Si deve digitare il titolo del periodico, non dell’articolo, nel box di ricerca. Se nessuno possiede il periodico, si passa al punto 5. 5. Richiedere il lavoro tramite il servizio di DD Una volta determinato che il periodico non è disponibile nella biblioteca nè in formato elettronico, nè a stampa, si può richiedere il lavoro via DD, completando il modulo di richiesta in biblioteca o in rete.

Strutture di linking chiuse   Alla fine degli anni ’90 ci si è resi conto che le modalità con cui l’industria informativa forniva i link a servizi estesi non erano soddisfacenti in quanto: - i link non tenevano conto del contesto dell’utente - erano focalizzate sul full-text fornito dagli editori - - erano chiuse: non permettevano a terze parti, qual è la biblioteca dell’utente, di attivare link a servizi estesi sensibili al contesto e autodefiniti. Tali strutture di collegamento sono state perciò definite “chiuse” e “non context-sensitive”. (Van de Sompel e Hochstenbach 1999a)

Linking ai servizi estesi   L’espressione “link ai servizi estesi” è stata introdotta da Van de Sompel and Hochstenbach per indicare link che vanno oltre la nozione classica di link citazionale (reference link) inteso come link dai metadati al full-text. La nozione di servizi estesi si riferisce ad un insieme di collegamenti ai servizi alternativi e complementari al link citazionale al full-text. I link ai servizi estesi che comunemente si incontrano nelle biblioteche digitali accademiche, sono collegamenti: - dal record in una banca dati bibliografica al full-text corrispondente; - dal record di una monografia in un catalogo di biblioteca alla descrizione dello stesso libro in una libreria in Internet; - dalla citazione all’interno di un articolo, al record di un database bibliografico che descrive l’articolo citato. Si possono immaginare anche servizi estesi più creativi …

Problema della copia appropriata e dei servizi estesi appropriati   Il “problema della copia appropriata” (nell’ambito del collegamento al full-text) - noto anche come “The Harvard problem” - è determinato dalle strutture di linking chiuse che conducono dalla citazione di un articolo di periodico alla copia dell’articolo definita dall’editore come default e non alla copia full-text “appropriata” per l’istituzione che può risiedere ad un indirizzo alternativo. Il problema del link alla copia appropriata di un articolo di periodico rientra nel problema più generale dei “servizi estesi appropriati”.(Van de Sompel and Hochstenbach (1999)) Dare una soluzione a questo problema è stato l’obbiettivo del progetto SFX.

Strutture di linking aperte e sensibili al contesto: il progetto SFX SFX - special effects - è il nome che è stato dato ad un progetto pluriennale , condotto dall'Università di Ghent in Belgio e dai laboratori di Los Alamos in USA   Il progetto era volto a creare una “struttura di linking aperta e context-sensitive”. In SFX la nozione di contesto è correlata all’istituzione cui è affiliato l’utente. Gli elementi del contesto presi in considerazione sono i contenuti accessibili all’utente nella biblioteca digitale istituzionale: - i database bibliografici cui l’utente ha accesso - i periodici elettronici cui l’utente ha accesso - l’opac dell’istituzione dell’utente - i sistemi di e-print (di auto-pubblicazione elettronica) accessibili all’utente; - le implementazioni specifiche per accedere a tali contenuti - le preferenze dell’utente riguardo all’interazione con le collezioni digitali.

Che cos’è l’OpenURL? OpenURL! L’OpenURL è un formato standardizzato per il trasporto del ContextObject attraverso i servizi informativi. L’OpenURL è: un formato per il trasporto delle informazioni (metadata) dalla fonte (source/referrer) al link server dell’istituzione un protocollo aperto, non proprietario, definito da standard Niso (OpenURL 0.1 (May 16th, 2000) e nel 2005 da: The OpenURL Framework Standard for Context-Sensitive Services NISO z39.88-2004) ContextObject OpenURL!

Componenti fondamentali dello schema OpenURL 1.0 Namespace Il set di tutti gli Uniform Resource Identifiers che sono compatibili con uno specifico schema URI o uno specifico URN namespace. Character Encoding La combinazione di un repertorio di caratteri e di una forma di codifica Serialization Metodo per conservare o trasmettere in rete i valori racchiusi all’interno di un costrutto informativo Constraint Language Un metodo usato per specificare restrizioni sintattiche e semantiche nei costrutti informazivi di una data classe ContextObject Formats Formato per rappresentare i ContextObjects Metadata Formats Formato per creare il By-Reference Metadata Descriptor o il By-Value Metadata Descriptor di un’entità Transports Protocollo di rete e metodo con cui si inviano le rappresentazioni del ContextObject Community Profiles Definizione di un’applicazione come lista di selezioni di tutte le componenti fondamentali dell’OpenURL Framework Info: http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListSets

OpenURL: il ContextObject Esempio di ContextObject Se l’utente Mario Rossi all’Università di Padova trova nel database di Elsevier ScienceDirect il record: McArthur, JG “p27-p16 Chimera…” Molecular Therapy 3(1) 8-13 che riporta la citazione: Bergelson, J. “Isolation of…” Science (275) 1320-1323 Il ContextObject relativo al documento conterrà 6 entità: Referent: il documento di Bergelson ReferringEntity: il documento di McArthur Referrer: ScienceDirect Requester: mario.rossi@unipd.it ServiceType: full text Resolver: http://aire.cab.unipd.it:9003/unipd

OpenURL 0.1 a confronto con il ContextObject http://www.example.com/resolver?genre=article &atitle=p27-p16 Chimera: A Superior Antiproliferative &title=Molecular Theory &aulast=McArthur &aufirst=James &date=2001 &volume=3 &issue=1 &spage=8 &epage=13 http://www.example.com/resolver?url_ver=Z39.88-2004 &url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx &rft_val_fmt=info:ofi/fmt:kev:mtx:journal &rft.genre=article &rft.atitle=p27-p16 Chimera: A Superior Antiproliferative &rft.jtitle=Molecular Theory &rft.aulast=McArthur &rft.aufirst=James &rft.date=2001 &rft.volume=3 &rft.issue=1 &rft.spage=8 &rft.epage=13 L’OpenURL si compone di svariati elementi ed è suddivisa in zone La BaseURL (indirizzo del link server a cui indirizzare l’OpenURL stessa) Origin Description è il SID e identifica il sorgente (opzionale) Object Description (obbligatoria) Le zone dell’Object Description sono: 1) Global Identifier - contiene un codice o una definizione accettata universalmente, univoca per uno specifico oggetto e utilizzata da tutti (ad esempio il PMID di PubMed o il DOI) 2) Object metadata – contiene un set di elementi descrittivi (combinazione di attributo/valore o nome elemento/valore) 3) Local Identifier – contiene il PID che può essere rappresentato da un identificatore proprietario, specifico di un record all’interno di una risorsa (MyID), attraverso il quale sarà possibile fare operazioni di fetching, oppure può contenere metadati descrittivi espressi in una sintassi non pubblica.

OpenURL 0.1 a confronto con il ContextObject ContextObject (OpenURL 1.0) L’OpenURL 0.1 include esplicitamente la risorsa di riferimento, il sistema che fornisce l’OpenURL (sid), e il linking server che è il target dell’OpenURL. La definizione di ContextObject formalizza queste risorse rispettivamente nelle entità dette di: Referent, Referrer, e Resolver L’utilizzo di OpenURL 0.1 ha mostrato che tre altre risorse venivano regolarmente descritte nel Private Identifier (pid): l’iniziatore di un trasporto di OpenURL (l’utente che clicca l’OpenURL), il documento che contiene la citazione, e il tipo di servizio richiesto (p.e. “get full-text”). La definizione di ContextObject formalizza queste risorse rispettivamente nelle entità dette di: Requester, ReferringEntity, e ServiceType. L’OpenURL 0.1 specifica un set di metadata chiave per descrivere gli elementi del record bibliografico attraverso una stringa di metadata. La definizione di ContextObject stabilisce regole generali per questo metodo descrittivo nel By-Value Metadata Descriptor of Entities. Questo descrittore dipende dal formato dei metadata disponibili nell’OpenURL Framework Registry. L’OpenURL 0.1 specifica le aree (Namespace) per gli identificatori che compongono gli elementi del record bibliografico, per il sistema che fornisce l’OpenURL, e per il target dell’OpenURL. La definizione di ContextObject stabilisce regole generali per questo metodo descrittivo nell’Identifier Descriptor of Entities. Questo descrittore dispende dalle aree (Namespace) per gli identificatori disponibili nell’OpenURL Framework Registry. L’OpenURL 0.1 accetta dati privati che descrivono gli elementi del record bibliografico in base ad una struttura specifica del fornitore dell’OpenURL. Per elaborare questa sintassi, un linking server deve stabilire degli accordi con il fornitore dell’OpenURL. La definizione di ContextObject stabilisce regole generali per questo metodo descrittivo nel Private Data Descriptor of Entities. L’utilizzo dell’OpenURL 0.1 ha mostrato che il Private Identifier (pid) dell’OpenURL 0.1 spesso contiene un puntatore ai metadata descrittori degli elementi del record bibliografico. La definizione di ContextObject stabilisce regole generali per questo metodo descrittivo nel By-Reference Metadata Descriptor of Entities. Questo descrittore dipende dal formati dei Metadata Formats disponibili nell’OpenURL Framework Registry. 1 L’OpenURL si compone di svariati elementi ed è suddivisa in zone La BaseURL (indirizzo del link server a cui indirizzare l’OpenURL stessa) Origin Description è il SID e identifica il sorgente (opzionale) Object Description (obbligatoria) Le zone dell’Object Description sono: 1) Global Identifier - contiene un codice o una definizione accettata universalmente, univoca per uno specifico oggetto e utilizzata da tutti (ad esempio il PMID di PubMed o il DOI) 2) Object metadata – contiene un set di elementi descrittivi (combinazione di attributo/valore o nome elemento/valore) 3) Local Identifier – contiene il PID che può essere rappresentato da un identificatore proprietario, specifico di un record all’interno di una risorsa (MyID), attraverso il quale sarà possibile fare operazioni di fetching, oppure può contenere metadati descrittivi espressi in una sintassi non pubblica. ANSI/NISO Z39.88 –2004 The OpenURL Framework for Context-Sensitive Services http://www.niso.org/standards/standard_detail.cfm?std_id=783

Esempi di OpenURL http://aire.cab.unipd.it:9003/unipd?ctx_enc=info:ofi/enc:UTF-8&ctx_id=10_1&ctx_tim=2005-8-17T13:45:9CEST&ctx_ver=Z39.88-2004&rfr_id=info:sid/sfxit.com:citation&rft.atitle=linking aperto nell'ambiente informativo accademico usando la OpenUrl&rft.aulast=van de sompel&rft.date=2001&rft.genre=article&rft.issn=1082-9873& rft.issue=3&rft.jtitle=Dlib&rft.volume=7&rft_val_fmt=info:ofi/fmt:kev:mtx:article&sfx.title_search=exact&url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx&url_ver=Z39.88-2004 // http://aire.cab.unipd.it:9003/unipd?atitle=Risks and limitations of the Web&auinit=T&aulast=Berners-Lee&date=2000&epage=64&issn=0029-5671&issue=328&sid=ISI:WoK&spage=62&stitle=RECHERCHE&title=RECHERCHE http://aire.cab.unipd.it:9003/unipd?sid=CAPERE&issn=00026018&genre=journal&__char_set=utf8 Qui vediamo qualche esempio più complicato di OpenURL. Un aspetto importante della sintassi dell’OpenURL è che può essere costruita in modi diversi per adattarsi alle differenze di un particolare set-up o sistema di database del fornitore. Nel primo esempio vediamo come il PID possa essere utilizzato per utilizzare il nome di altri autori, oltre al primo citato, in una OpenURL proveniente da WoS. Questo permetterà al server SFX di creare servizi di linking per tutti gli autori del lavoro descritto nell’OpenURL e non soltanto per il primo autore. Nel secondo esempio attraverso un codice identificativo (Global Identifier), in questo caso il DOI, SFX è in grado di sapere dove reperire ulteriori metadati e quindi di fare una operazione di fetch presso CrossRef OpenURL 1.0 in formato unicode (UTF-8) http://aire.cab.unipd.it:9003/unipd?ctx_enc=info%3Aofi%2Fenc%3AUTF-8;ctx_id=10_1;ctx_tim=2005-9-22T11%3A3%3A8CEST;ctx_ver=Z39.88-2004;rfr_id=info%3Asid%2Fsfxit.com%3Acitation;rft.atitle=%27True%20and%20Fair%27%20and%20%27Fair%20Value%27-Accounting%20and%20Legal%20Will-o%27-the-Wisps;rft.auinit=G;rft.aulast=Dean;rft.date=2005-06;rft.genre=article;rft.issn=0001-3072;rft.issue=2;rft.jtitle=Abacus;rft.volume=41;rft_id=info%3Adoi%2F10.1111%2Fj.1467-6281.2005.00174.x;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Aarticle;sfx.title_search=exact;url_ctx_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Actx;url_ver=Z39.88-2004

SFX Qui vediamo qualche esempio più complicato di OpenURL. Un aspetto importante della sintassi dell’OpenURL è che può essere costruita in modi diversi per adattarsi alle differenze di un particolare set-up o sistema di database del fornitore. Nel primo esempio vediamo come il PID possa essere utilizzato per utilizzare il nome di altri autori, oltre al primo citato, in una OpenURL proveniente da WoS. Questo permetterà al server SFX di creare servizi di linking per tutti gli autori del lavoro descritto nell’OpenURL e non soltanto per il primo autore. Nel secondo esempio attraverso un codice identificativo (Global Identifier), in questo caso il DOI, SFX è in grado di sapere dove reperire ulteriori metadati e quindi di fare una operazione di fetch presso CrossRef

SFX Il progetto SFX ha prodotto: un software commerciale distribuito dalla Ex Libris, il produttore del sistema di gestione di biblioteche Aleph. http://www.sfxit.com/ uno standard NISO http://www.niso.org/standards/standard_detail.cfm?std_id=783 un software libero (OpenResolver, con licenza GNU), disponibile sul sito dell'UKOLN ftp://ftp.ukoln.ac.uk/metadata/tools/openresolver/ 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 (o: OpenResolver). Esistono altre implementazioni di OpenURL proprietarie e non.

SFX: un po’ di storia 1997/98: Van de Sompel inizia il lavoro su SFX alla Ghent University Febbraio 2000: Ex Libris™ acquista la tecnologia SFX Novembre 2000: l’OpenURL viene sottoposta al NISO Marzo 2001: lancio di SFX Giugno 2002: 200 clienti in 17 paesi The OpenURL Framework for Context-Sensitive Services (ANSI/NISO Z39.88 –2004) 2005: SFX V3 Aprile 2005: 700+ clienti in 36 paesi Maggio 2004: Cipe acquista Metalib/SFX Marzo 2005: AIRE/SFX viene messo a disposizione del pubblico a Padova

Fasi ed elementi dell’implementazione di AIRE/SFX Configurazione hosting locale Caricamento e configurazione delle risorse locali nell’istanza unipd e delle risorse consortili nell’istanza CIPE Personalizzazioni: menu, bottone SFX, servizi estesi Personalizzazioni: target e source locali, Institute/GROUP Contatti con gli editori per chiedere di visualizzare il bottone SFX nei loro DB e far puntare l’Openurl al server dell’istituzione Test Riconfigurazione di alcuni elementi in base ai risultati del test Attivazione delle statistiche Attualmente stiamo utilizzando la V3 di SFX uscita a febbraio 2005 e implementata a Padova a Luglio 2005

SFX: il meccanismo alla base L’OpenURL rende disponibili in modo dinamico i metadati al componente di servizio Il server di linking descrive il contesto dell’utente Permette il trasporto del ContextObject da una risorsa informativa (source o referrer) a un componente di servizio (resolver SFX) in grado di determinare e fornire servizi sensibili al contesto dell’utente per quei metadata N.B.: I link OpenURL non sono gestiti o gestibili dai bibliotecari ma dalle fonti (source) dei ContextObject

SFX: il meccanismo alla base Il resolver associa i metadati agli oggetti presenti nel KnowledgeBase (KB) di SFX e determina il menu dei servizi per l’utente. Il KB è configurato dalla biblioteca in base alle collezioni e ai servizi locali. Il menu rispecchia le scelte dell’istituzione. SFX: il meccanismo alla base

Menu dei servizi di SFX V3

La ricerca in una banca dati (WOS)

La ricerca in una banca dati SARS

La ricerca in una banca dati

La ricerca in una banca dati

La ricerca con CitationLinker http://www.cab.unipd.it/cataloghi/ FORZA SCIENZA NATURE 2001 412 6844 264 ABBOTT A

Le source di SFX L’elenco aggiornato delle source di SFX è consultabile all’URL: http://homepage.cab.unipd.it/metalib/helpV3

IL KnowledgeBase di SFX Il KnowledgeBase (KB) del Link server definisce la collezione della biblioteca allo scopo di determinare la copia appropriata del documento e i servizi estesi da offrire all’utente da presentare all’utente nel menu di SFX Il KB di SFX contiene Elenchi di source e target 435.000+ periodici (di cui 25.000 e–journals), e-books un set di regole per il linking gli strumenti per localizzare gli objects, per personalizzare il KB con le indicazioni di posseduto e condizioni di accesso locali meccanismi di aggiornamento. Il KB è regolarmente aggiornato e gli aggiornamenti non sovrascrivono le personalizzazioni locali strumenti Web-based per la configurazione, la gestione, l’export e il reporting statistico.

Tesi e tesi di dottorato online Digital repositories locali Targets Sources Database A&I E-Journals OPAC archivi E-print (OAI) Tesi e tesi di dottorato online Digital repositories locali Targets E-Journals OPAC ILL/DocDel Citazioni/A&I DB Database di brevetti Enciclopedie Copyright Clearance Motori di ricerca Ecc. Le Source devono fornire un’OpenURL I Target devono avere una sintassi di link-to Entrambi hanno un portfolio di servizi disponibili

1 2 Sources Compatibilità con l’OpenURL Le source devono fornire un’OpenURL. Una source è abilitata per l’OpenURL quando è in grado di: 1 Identificare un utente che ha accesso a un componente di servizio Fornire un’OpenURL con metadati che descrivano l’oggetto che interessa all’utente e che è contenuto nella risorsa che l’utente sta utilizzando 2 Cosa deve essere in grado di fare un fornitore abilitato per l’OpenURL 1) Se l’utente si collega ad una sua risorsa e l’istituzione alla quale l’utente è affiliato non ha SFX il pulsante SFX non deve venire visualizzato. Se l’istituzione ha SFX l’utente deve vedere il pulsante SFX e dietro tale pulsante deve esserci l’OpenURL che punta al server SFX della sua Istituzione(base URL) 2) Per ciascun record del proprio database il fornitore deve essere in grado di fornire un’OpenURL

Sources Il riconoscimento dell’utente Le source devono sapere quale BASE_URL (resolver) inserire nelle OpenURL per poter fornire servizi SFX corretti e basati sul contesto locale. I metodi per introdurre una OpenURL che punti al componente di servizio appropriato sono: includere la BASE-URL nel profilo dell’utente, se ne viene mantenuto uno presso la risorsa informativa; - costringere la risorsa informativa a scrivere la BASE-URL come cookie sul browser dell’utente, per mezzo di un meccanismo CookiePusher; derivare la BASE-URL da una tavola che collega gli indirizzi IP alle BASE-URL Maggiori dettagli sull’item 1) della slide precedente: Come riconoscono gli utenti? I fornitori devono sapere quale base_url inserire nelle loro OpenURLs altrimenti non sarebbero in grado di fornire servizi locali SFX corretti. Il profilo utente può essere determinato in base a indirizzo IP oppure identificazione via login/pwd Esiste anche la possibilità di utilizzare il CookiePusher. Il CookiePusher è attualmente usato solo per due sorgenti: IOP e ArXiv. Questo perché i ‘fornitori’ non tengono una registrazione degli utenti che hanno un server SFX oppure, nel caso di LosAlamos, non vogliono registrare la baseURL nel profilo dei loro clienti. Digital Certificates è qualche cosa in divenire, EXL lavora al progetto Shibolleth nell’ambito del quale si stanno definendo nuove modalità per l’autenticazione e autorizzazione degli utenti.

Target, target services e object portfolio I target è il contenitore di servizi e (a volte) di object, punto di arrivo della ricerca dell’utente I portfolio contengono l’elenco degli object (entità bibliografiche) proprie del target e/o del service per quel target I Targets devono avere una sintassi di link-to in grado di supportare il servizio richiesto dall’utente Maggiori dettagli sull’item 1) della slide precedente: Come riconoscono gli utenti? I fornitori devono sapere quale base_url inserire nelle loro OpenURLs altrimenti non sarebbero in grado di fornire servizi locali SFX corretti. Il profilo utente può essere determinato in base a indirizzo IP oppure identificazione via login/pwd Esiste anche la possibilità di utilizzare il CookiePusher. Il CookiePusher è attualmente usato solo per due sorgenti: IOP e ArXiv. Questo perché i ‘fornitori’ non tengono una registrazione degli utenti che hanno un server SFX oppure, nel caso di LosAlamos, non vogliono registrare la baseURL nel profilo dei loro clienti. Digital Certificates è qualche cosa in divenire, EXL lavora al progetto Shibolleth nell’ambito del quale si stanno definendo nuove modalità per l’autenticazione e autorizzazione degli utenti.

TARGETS SOURCES Service: collegamento tra source e target Springer offre: getFullTxt, getTOC CContents richiede: getFullTxt getTOC getAuthor getCitedAuthor getAbstract getWebService getCitedReference getCitedJournal BIOSIS offre: getAuthor, getAbstract Link concettuali che verranno creati (realmente) se certi requisiti (Threshold) vengono soddisfatti . Wiley offre: getFullTxt, getTOC WWW Search Engines offre: getWebService Web of Science offre: getCitedReference getCitedAuthor getAuthor

Strumenti per i bibliotecari Colleghiamoci all’ interfaccia di amministrazione di SFX

Statistiche SFX richieste e click su target per data SFX richieste e click su target per source Periodici più richiesti per target Periodici richiesti che non hanno full text Full text journals non utilizzati … Si impostano le richieste attraverso un’interfaccia Web o si schedulano per essere eseguite off-line e consegnate via e-mail Le statistiche vengono prodotte in file HTML o tab-delimited per Excel

Statistiche

AIRE/SFX statistiche 5-11 settembre 2005

Consultazioni delle risorse elettroniche via SFX (ago-dic 2005)

Risorse elettroniche attive e accessibili via in SFX AIRE/SFX statistiche (ancora statistiche!) Risorse elettroniche attive e accessibili via in SFX Indici di periodici 1.230 Abstract 11.169 FullText di articoli di periodici e libri 16.750 (+ 6000 via EZB) AIRE/SFX dà accesso alle piattaforme di 102 editori/fornitori di full-text di periodici elettronici.

AIRE/SFX statistiche (ancora statistiche!)

Le risorse più consultate nei mesi di ottobre/novembre 2005 AIRE/SFX statistiche (ancora statistiche!) Le risorse più consultate nei mesi di ottobre/novembre 2005 OPAC WEB di ATENEO ( getHolding) 7621 JCR (getCitedJournal) 1734 ACNP (getWebService) 1379 OPAC SBN (getWebService) 950 EBSCO PSYCHOLOGY & BEHAVIORAL SCIENCE (getFullTxt) 922 ELSEVIER SCIENCE DIRECT (getFullTxt) 733 GOOGLE_SCHOLAR (getWebSearch) 657 OVID PSYCARTICLES (getFullTxt) 607 SYNERGY (getFullTxt) 581 SPRINGER_LINK_JOURNALS (getFullTxt) 523 CAPERE (getWebService) 481 SWETSWISE (getFullTxt) 458 ELSEVIER PERGAMON (getFullTxt) 452 EZB REGENSBURG (getFullTxt) 390 OVID JOURNALS_AT_OVID (LWW) (getFullTxt) 369 AMERICAN CHEMICAL SOCIETY (getFullTxt) 353 DOCUMENT DELIVERY DI UNIPD (getDocumentDelivery) 345 CAPTURE CITATION (getReference) 304 ELSEVIER ACADEMIC_PRESS (getFullTxt) 299 WWW SEARCH ENGINES getWebSearch 199 DOAJ DIRECTORY OPEN ACCESS JOURNALS FREE (getFullTxt) 184 HIGHWIRE PRESS FREE (getFullTxt) 180 LIBRARY OF CONGRESS (getAuthor) 168

AIRE/SFX statistiche (ancora statistiche!) tipo di servizio richieste al server SFX: set-nov 2005 click per accedere ai servizi dal menu di SFX: set-nov 2005 getMessageNoFullTxt 19438 getCitedRecord 3079 9 getDOI 770 15 getTOC 1315 35 getBookReview 1095 111 getAbstract 9615 253 getAuthor 18884 299 getReference 31830 382 getDocumentDelivery 21169 392 getWebSearch 26897 898 getCitedJournal 26751 1896 getWebService 2879 getHolding 8263 getFullTxt 10620 8528

Bello, ma.. Il KB non è mai perfettamente aggiornato OPAC Web non è source di SFX BD SAR non sono nè source nè target Molte risorse online non sono OpenUrl compliant La qualità dei risultati dipente dalla qualità dei metadati forniti dalla source La “profondità” dei collegamenti varia da target a target

Ulteriore lavoro per noi: Integrazione con Aleph Sviluppi di SFX Ulteriori integrazioni con Electronic Resource Management (ERM) Strumenti per il Course management Autenticazione: Shibboleth Localizzazione dei documenti: LOCKSS Ulteriore lavoro per noi: Integrazione con Aleph

Grazie e in bocca al lupo!

bibliografia Linking to the Appropriate Copy: Report of a DOI-Based Prototype, Oren Beit-Arie et al., September 2001 <http://www.dlib.org/dlib/september01/caplan/09caplan.html> . Reference Linking in a Hybrid Library Environment Part 3: Generalizing the SFX solution in the "SFX@Ghent & SFX@LANL" experiment, Herbert Van de Sompel and Patrick Hochstenbach, October 1999 <http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html> Reference Linking in a Hybrid Library Environment Part 2: SFX, a Generic Linking Solution, Herbert Van de Sompel and Patrick Hochstenbach, April 1999 <http://www.dlib.org/dlib/april99/van_de_sompel/04van_de_sompel-pt2.html> Reference Linking in a Hybrid Library Environment Part 1: Frameworks for Linking, Herbert Van de Sompel and Patrick Hochstenbach, April 1999 <http://www.dlib.org/dlib/april99/van_de_sompel/04van_de_sompel-pt1.html> CABRef: Cross-Referencing into an Abstracts Database, Ann Apps and Ross MacIntyre, July 2001 http://epub.mimas.ac.uk/papers/appsmacep2001.html Generalizing the OpenURL Framework beyond References to Scholarly Works: The Bison-Futé Model, Herbert Van de Sompel and Oren Beit-Arie, July 2001 <http://www.dlib.org/dlib/july01/vandesompel/07vandesompel.html> OpenResolver: a Simple OpenURL Resolver, Andy Powell, June 2001 <http://www.ariadne.ac.uk/issue28/resolver>/CrossRef Turns One, Amy Brand, May 2001 <http://www.dlib.org/dlib/may01/brand/05brand.html> Open linking for libraries: the OpenURL framework, Jenny Walker, 2001 <http://www.sfxit.com/news/SFXartNLW2001.pdf> Open Linking in the Scholarly Information Environment Using the OpenURL Framework, Herbert Van de Sompel and Oren Beit-Arie, March 2001<http://www.dlib.org/dlib/march01/vandesompel/03vandesompel.html> Encoding OpenURLs in Dublin Core metadata, Andy Powell and Ann Apps, March 2001 <http://www.ariadne.ac.uk/issue27/metadata/intro.html> Automating Enhanced Discovery and Delivery: The OpenURL Possibilities, David Stern, March 2001 <http://www.onlineinc.com/onlinemag/OL2001/stern3_01.html> The UPS Prototype, Herbert Van de Sompel et al., February 2000 http://www.dlib.org/dlib/february00/vandesompel-ups/02vandesompel-ups zetoc: a Dublin Core Based Current Awareness Service, Ann Apps and Ross MacIntyre, October 2001 (Accepted for DC 2001) <http://epub.mimas.ac.uk/papers/appsmacdc2001.html>

bibliografia OpenURL Syntax Description. 2000, Van de Sompel H, Hochstenbach P, Beit-Arie O (editors). <http://www.openurl.info/registry/docs/pdf/openurl-01.pdf> Open Linking in the Scholarly Information Environment Using the OpenURL Framework, Van de Sompel H, Beit-Arie O. D-Lib Magazine, 2001. 7(3). doi:10.1045/march2001- <http://www.dlib.org/dlib/march01/vandesompel/03vandesompel.html> Generalizing the OpenURL Framework beyond References to Scholarly Works: the Bison-Futé model, Van de Sompel H, Beit-Arie O. D-Lib Magazine, 2001. 7(7/8). doi:10.1045/july2001 <http://www.dlib.org/dlib/july01/vandesompel/07vandesompel.html> National Information Standards Organization. The OpenURL Framework for Context-Sensitive Services. Standards Committee AX. Charge. <http://www.niso.org/committees/committee_ax.html> Bibliografia aggiornata sul sito della comunità degli utenti SMUG : http://www.smugnet.org

Glossario Componente di servizio: il modulo software (esterno alla source) che risiede nel link server ed è pensato per ricevere una OpenURL e risolverla in servizi (in link) Context : L’ambiente elettronico in cui un Referent trova la citazione e in cui un servizio richiesto dal Referent viene fornito. Nel ContextObject, il Context è espresso da cinque entità: la ReferringEntity, il Requester, il ServiceType, il Resolver, e il Referrer. ContextObject : un costrutto informativo che riunisce la descrizione dell’entità primaria (la risorsa citata) con le descrizioni delle entità che indicano il contesto. Istanza locale: Installazione locale e personalizzabile di SFX (ogni installazione prevede un’istanza locale, una globale e un’istanza di test) Knowledge Base di SFX: elemento centrale dell’architettura SFX: tabelle relazionali che registrano le conoscenze generali e contestuali necessarie al funzionamento context sensitive del componente di servizio Link-source: il record (o comunque la citazione) per cui si chiedono servizi estesi di linking Object: Record di periodici, libri, tesi, brevetti,… presenti nel portfolio di un target\target service Service: Tipologia di servizio legata a source e target sourceParser: uno script (un pezzo di sw) che rientra nell’architettura del componente di servizio, capace di analizzare i metadati provenienti da una particolare link-source Source / referrer: la risorsa da cui parte la ricerca Target: la risorsa/il record a cui conduce il link che parte dalla link-source TargetParser: uno script (un pezzo di sw) che rientra nell’architettura del componente di servizio, capace di implementare il collegamento all’interno di un particolare target (costruendo il link secondo una particolare sintassi di link-to)

ANSI/NISO Z39.88 -2004 The OpenURL Framework for Context-Sensitive Services Abstract: The OpenURL Framework Standard defines an architecture for creating OpenURL Framework Applications. An OpenURL Framework Application is a networked service environment, in which packages of information are transported over a network. These packages have a description of a referenced resource at their core, and they are transported with the intent of obtaining context-sensitive services pertaining to the referenced resource. To enable the recipients of these packages to deliver such context-sensitive services, each package describes the referenced resource itself, the network context in which the resource is referenced, and the context in which the service request takes place. This Standard specifies how to construct these packages as Representations of abstract information constructs called ContextObjects. To this end, the OpenURL Framework Standard defines the following core components: Character Encoding, Serialization, Constraint Language, ContextObject Format, Metadata Format, and Namespace. In addition, this Standard defines Transport, a core component that enables communities to specify how to transport ContextObject Representations. Finally, this Standard specifies how a community can deploy a new OpenURL Framework Application by defining a new Community Profile, the last core component. This Standard defines the OpenURL Framework Registry and the rules that govern the usage of this Registry. The OpenURL Framework Registry contains all instances of all core components created by communities that have deployed OpenURL Framework Applications. This Standard defines and registers the initial content of the OpenURL Framework Registry, thereby deploying two distinct OpenURL Framework Applications. http://www.niso.org/standards/standard_detail.cfm?std_id=783