--- INTERR GUIDA [2000-03-22. - 600 righe, 30'000 caratteri] ------------------------------------------------------------------------ Esempi di ricerca negli archivi di AIB-CUR / Eugenio Gatto. Torino : Politecnico, 1995-02-19 (rev. 1995-03-09). Su casi concreti, un'illustrazione delle possibilita` di ricerca negli archivi dei gruppi di discussione. 1996-11-06. Nome precedente dello stesso documento: AIB-CUR G9502A. 2000-03-22. Con l'entrata in funzione del nuovo LISTSERV (1999-12) le tecniche d'interrogazione sono parzialmente diverse da quelle qui descritte: ma, soprattutto, l'interrogazione e selezione e` direttamente accessibile (agli iscritti) da WWW, e con milgiori possibilita` di quelle qui descritte, alla voce "Ricerche in archivio" a URL . Per le altre funzioni relative ad AIB-CUR, l'indirizzo del nuovo LISTSERV e` . Informazioni sul gruppo di discussione sono sempre mantenute aggiornate su AIB-WEB, a URL , dove anche sono disponibili in versione WWW le rubriche e i documenti generali. ------------------------------------------------------------------------ Automaticamente, LISTSERV non solo distribuisce agli iscritti i messaggi che riceve (questa e` la sua funzione primaria), ma anche li archivia ordinatamente nelle filze mensili, che si chiamano ad esempio AIB-CUR LOG9501, AIB-CUR LOG9502, e cosi` via. Volendo, gli iscritti possono recuperare un archivio mensile mandando (a LISTSERV @ICINECA) un appropriato comando GET (ad esempio, GET AIB-CUR LOG9407), ma si tratta di filze massicce, poco maneggevoli, e il contenuto e` semplicemente in ordine d'arrivo. Per rendere effettivamente piu` utilizzabili gli archivi, LISTSERV (sempre automaticamente) ne deriva anche un semplice ma efficace database su cui interrogare ed estrarre selezionando, e lo tiene aggiornato man mano che archivia. Il manuale che ufficialmente spiega le molte possibilita` di questa tecnica si ottiene inviando a LISTSERV @ICINECA il comando INFO DATABASE (o il suo equivalente GET LISTDB MEMO: si riceve un testo, in inglese, 29 pagine, una volta messo su carta). Quel che segue e` una breve introduzione agli usi piu` comuni, basata sulla discussione di esempi pratici. Quel che vale per gli archivi di AIB-CUR, vale analogamente per quelli di tutti gli altri gruppi di discussione che fanno uso di LISTSERV (software di Eric Thomas, attualmente distribuito da L-Soft). --- Il registro cronologico di spedizione Cominciamo da un uso semplicissimo che, prima o poi, capitera` a tutti di voler sfruttare: come sapere se da LISTSERV abbiamo ricevuto tutto quel che ha distribuito agli iscritti AIB-CUR ? Il database associato ad AIB-CUR si puo` considerare innanzitutto un registro cronologico ("protocollo", se vogliamo) delle lettere ricevute e ridistribuite, consultabile da tutti gli iscritti (si tratta di posta pubblica). A prima vista, e` impressionante quel che bisogna usare per porre domande, ma lo ridurremo presto ai minimi termini. Supponiamo che sia il 17 febbraio (tra mezzogiorno e le tre), e che vogliamo controllare cosa sia stato distribuito da ieri. Bisogna spedire (sempre a LISTSERV @ICINECA) questo (che dev'essere il testo di una lettera, o (per chi puo`) un file BITNET: variante che non discutiamo qui): //db JOB ECHO=NO DATABASE SEARCH DD=cmd OUTLIM=2000 //cmd DD * SEARCH * IN aib-cur SINCE 95-02-16 INDEX /* //db EOJ Ora, i due comandi efficaci (dal nostro punto di vista) sono SEARCH e INDEX: tutte le righe che li precedono o seguono devono esserci, ma possono essere prese di peso da quest'esempio (tranne che per speciali necessita`, in cui non entriamo: il manuale appropriato in questo caso si ottiene mandando a LISTSERV il comando GET LISTJOB MEMO). D'ora in poi quindi non parleremo piu` delle parti fisse (intendendo che ci siano), e concentriamo l'attenzione su: SEARCH * IN aib-cur SINCE 95-02-16 INDEX I due comandi devono essere su due righe diverse, e l'insieme vuol dire: "individuare negli archivi AIB-CUR (IN aib-cur) tutto (*) quel che risulta a partire dal 16 febbraio (SINCE 95-02-16), e darne una lista leggibile (INDEX)". Questo il risultato (se la richiesta e` partita come lettera, la risposta arriva come lettera intitolata DATABASE OUTPUT): > SEARCH * IN aib-cur SINCE 95-02-16 --> Database AIB-CUR, 6 hits. > INDEX Item # Date Time Recs Subject ------ ---- ---- ---- ------- 001371 95/02/16 08:44 64 UMBRIALIBRI 18-26/2/1995 001372 95/02/16 14:15 21 seminari di Reggio Emilia 001373 95/02/16 11:30 21 Re: Privatizzazione Di Internet 001374 95/02/17 08:18 18 Partecipazione a seminari della Regione Lom 001375 95/02/17 07:46 39 Biblioteche civiche di Torino e WWW 001376 95/02/17 11:38 34 Re: Guida per l'utenza Non andiamo nel dettagli delle singole colonne: somiglia molto a quanto qualunque sistema di lettura della posta mostra, e puo` bastare per un controllo con quel che si e` ricevuto effettivamente. Naturalmente bisogna tener conto che la posta elettronica viaggia a velocita` variabili e imprecisate, quindi non e` detto che tutti ricevano nello stesso ordine in cui LISTSERV ha distribuito. Gia` in questo esempio si vede che LISTSERV stesso ha ricevuto il messaggio "protocollato" 1373 con parecchio ritardo (visto che s'era occupato prima del messaggio # 1372, il cui mittente dichiara una spedizione di quasi tre ore posteriore). LDBASE (chiamiamo la parte di LISTSERV che si occupa dell'interrogazione) ammette diverse forme di data: io preferisco quella indicata, che e` "quasi-ISO". Se avessimo voluto controllare solo le spedizioni del 16, avremmo aggiunto anche una clausola UNTIL: SEARCH * IN aib-cur SINCE 95-02-16 UNTIL 95-02-16. E la forma SINCE TODAY e` quella per indicare la posta del giorno (potrebbe interessarci per verificare, con un po' di pazienza, se una lettera nostra mandata ad AIB-CUR sia stata effettivamente ridistribuita: ma se si e` apprensivi, conviene lasciare abilitata la caratteristica di iscrizione ACK: normale per AIB-CUR (non per altri gruppi), prescrive a LISTSERV di mandare al mittente originale un messaggio di conferma quando ha finito il giro di ridistribuzione). Semplice quindi dare una scorsa agli argomenti discussi, ad esempio al rientro da un periodo d'assenza (p di malfunzionamento della posta). LISTSERV stesso usa queste tecniche di selezione cronologica per mandare quanto deve agli iscritti DIGEST o INDEX (per AIB-CUR, alla chiusura della giornata). --- Criteri di selezione non cronologici Sono possibili usi ben piu` complessi e significativi. Discuteremo attorno al problema seguente (domande effettivamente poste da un iscritto, ma questo non importa: non se n'abbiano a male le persone citate, non si esplora null'altro che posta che e` gia` stata pubblicamente letta in AIB-CUR): 1. Come trovare un messaggio dell'inizio di febbraio 1995 che non aveva SUBJECT, ma veniva da Silvana Congiu. 2. A quale domanda di Silvia Zoletto quella lettera rispondeva. 3. Cosa s'e` detto recentemente sul "cambio librario". Abbiam gia` detto che non parleremo piu` delle parti fisse, e le istruzioni efficaci per il primo quesito possono essere: SEARCH * IN aib-cur SINCE 95-02-01 - WHERE sender CONTAINS congiu INDEX E` una domanda piuttosto restrittiva: artificiosamente l'ho spezzata su piu` righe per mostrare l'uso del segno '-', che indica la continuazione alla riga successiva del comando SEARCH (come al solito: maiuscolo e minuscolo non importano, li uso solo per distinguere parole che hanno un significato speciale da quelle che si variano di volta in volta). Vuol dire: "isolare negli archivi di AIB-CUR (IN aib-cur) tutti (*) i documenti, a partire dall'inizio di febbraio (SINCE 95-02-01), il cui mittente contenga 'congiu' (WHERE sender CONTAINS congiu)". SENDER e` l'indirizzo di spedizione, che nelle "buste" delle lettere compare nel campo "From:". Quindi, ci basiamo sull'assunzione (diciamo, su un passeggero ricordo) che effettivamente nell'indirizzo "From:" di quelle lettere ci sia un frammento di testo che corrisponde a 'congiu' (LISTDB ricerca sempre frammenti di testo, non "parole"; 'ongi' andrebbe altrettanto bene, in una domanda gia` cosi` restrittiva). Il risultato e` questo (sotto forma di lettera, e viaggia a tempi di posta elettronica, anche se l'esecuzione della ricerca e` rapidissima): > SEARCH * IN aib-cur SINCE 95-02-01 - > WHERE sender CONTAINS congiu --> Database AIB-CUR, 2 hits. > INDEX Item # Date Time Recs Subject ------ ---- ---- ---- ------- 001310 95/02/02 18:16 13 001333 95/02/07 17:20 20 Si vede che gli spazi iniziali (davanti a 'WHERE') sono stati trascurati, che sono stati individuati due documenti corrispondenti alle caratteristiche (2 hits), e INDEX ci mostra l'elenco. Effettivamente queste due lettere mancano di SUBJECT, sono la # 1310 e 1333 (item number: nell'intera storia di AIB-CUR, LISTDB (comodamente) non tiene conto della suddivisione degli archivi in filze mensili, o annuali, o altro), 'Recs' dichiara la lunghezza (in righe) di ciascuna. Ovvio il significato di 'Date' e 'Time' (e abbiam gia` detto che e` quanto il sistema del mittente ha dichiarato alla spedizione nel campo "Date:" delle "buste", non il momento in cui LISTSERV ha ricevuto e distribuito). --- Il recupero dei documenti (e i problemi dell' "interrogazione disconnessa") Bene, non resta che recuperare i documenti veri e propri: si rispedisce il tutto, aggiungendo un PRINT dopo INDEX (che vuol dire: "far seguire l'intero testo dei documenti isolati da SEARCH ed elencati da INDEX"): SEARCH congiu IN aib-cur SINCE 95-02-01 INDEX PRINT Perche' richiedere di nuovo INDEX, visto che abbiamo gia` ricevuto una copia di quell'elenco ? Semplice comodita`, cosi` avremo tutto in una lettera sola, ben documentato. Ma (molto piu` importante) perche' ripetere la domanda ? Questo e` un punto delicato, che forse aiuta a capire immediatamente quali siano i problemi dell' "interrogazione disconnessa". LISTSERV, quando ricevera` questa domanda, avra` completamente dimenticato che l'avevamo gia` posta poco (o tanto) tempo prima, e quindi dobbiamo esser noi a rimetterlo in condizione di sapere di quali lettere ci interessa il PRINT: il modo piu` ovvio che abbiamo per ottenerlo e` fargli ripetere l'identica ricerca. Un'altro aspetto di questo modo di funzionamento e` il modo di indicare (validamente) i reperti di una ricerca precedente: finche' usiamo semplicemente PRINT (che equivale a PRINT ALL: tutti i documenti rispondenti alla domanda), possiamo alla peggio scoprire che (essendosi nel frattempo aggiornato l'archivio) qualcosa non c'e` piu` e qualcosa di nuovo e` comparso. Ma vedremo in seguito che e` possibile in PRINT ulteriormente selezionare, indicando i numeri (item #) dei documenti: allora dovrebbe essere garantita (anche a distanza di tempo) la permanenza dei numeri attribuiti (visto che non sono un dato "oggettivamente" presente nel documento, ma "soggettivamente" attribuito dal sistema di archiviazione). Chiaramente, la cosa importa poco per un archivio cronologico di corrispondenza, che viene fondamentalmente incrementato soltanto in coda: e (anche se LDBASE e` piuttosto semplice in questo) si puo` contare sul fatto che i numeri restino validi, in un ragionevole lasso di tempo. Torniamo al problema pratico: in realta`, il SEARCH che chiediamo ora e` molto piu` semplice (e grossolano) di quello originale, ma (dato che limitiamo la ricerca al materiale di pochissimi giorni) siamo abbastanza certi che non si trattera` di gran fatica in piu` (molto piu` cauti bisogna essere se una domanda del genere si fa sull'intera storia di AIB-CUR, cioe` senza specificare restrizioni di data). La domanda ora significa: "tutti i documenti che contengano il frammento 'congiu' in qualunque parte della lettera, intestazioni e testo (prima limitavamo al solo SENDER), a partire dal 1. febbraio". Questo e` il risultato (per quanto brevi, tronco la maggior parte dei testi, naturalmente): > SEARCH congiu IN aib-cur SINCE 95-02-01 --> Database AIB-CUR, 2 hits. > INDEX Item # Date Time Recs Subject ------ ---- ---- ---- ------- 001310 95/02/02 18:16 13 001333 95/02/07 17:20 20 > PRINT >>> Item number 1310, dated 95/02/02 18:16:09 -- ALL Date: Thu, 2 Feb 1995 18:16:09 GMT Reply-To: AIB-CUR Sender: AIB-CUR From: silvana congiu From congiu Thu Feb 2 18:10 UTC 1995 forwarded by congiu In risposta a Silvia Zoletto, seconda parte della richiesta: ho trovato un fornitore che oltre a non praticare il cambio librario, fornisce [...] >>> Item number 1333, dated 95/02/07 17:20:05 -- ALL Date: Tue, 7 Feb 1995 17:20:05 GMT Reply-To: AIB-CUR Sender: AIB-CUR From: silvana congiu From congiu Tue Feb 7 17:13 UTC 1995 forwarded by congiu Cari AIB-Curisti, dopo un lungo black out dovuto a problemi tecnici sulla mia rete locale ecco che riesco nuovamente a leggervi! Avrei tante domande in sospeso... [...] Se andrete a controllare nei dettagli (ripetendo prove analoghe) scoprirete, se amate la precisione, che le lunghezze dichiarate per le lettere in INDEX ('Recs') sono quelle del testo vero e proprio, incluse quelle poche intestazioni che vengono conservate in archivio (una selezione, a partire dalle "buste" della lettera originale, normalmente 5 o 6 righe). --- Ricerca per nomi (di autori e nel testo) Per sapere a quale domanda quella lettera rispondesse (2. problema) bisogna evidentemente risalire all'indietro: di quanto ? Nella seconda lettera si dice "dopo un lungo black out" (certamente piu` che dal 2 al 7 febbraio): la domanda potrebbe allora anche essere di molto precedente. Proviamo a cercare quando, nell'intera storia di AIB-CUR, 'congiu' abbia scritto e smesso di scrivere (domanda non pesante, perche' ci basiamo esclusivamente sul SENDER, soltanto eliminando i limiti cronologici): SEARCH * IN aib-cur WHERE sender CONTAINS congiu INDEX Risposta deludente: nulla risulta prima di quelle due lettere (o non aveva mai scritto, o l'aveva fatto sotto altro nome): > SEARCH * IN aib-cur WHERE sender CONTAINS congiu --> Database AIB-CUR, 2 hits. > INDEX Item # Date Time Recs Subject ------ ---- ---- ---- ------- 001310 95/02/02 18:16 13 001333 95/02/07 17:20 20 Strano, comunque. Con un po' di testardaggine, allarghiamo la domanda all'intero testo (ma, per non appesantire, limitiamoci a poco piu` di un anno di archivi): SEARCH congiu IN aib-cur SINCE 94 LIST #.4R0 date.8 #recs.4R sender.25 subject.26 #.0 '94' equivale a '94-01-01'. Per saperne di piu` (visto che potrebbero essere lettere senza subject), invece del semplice INDEX, pretendiamo di specificare quali contenuti vogliamo che abbiano le diverse colonne. Piu` che spiegare nel dettaglio il comando LIST e la sua "specifica di formato", conviene vederne l'effetto: > SEARCH congiu IN aib-cur SINCE 94 --> Database AIB-CUR, 10 hits. > LIST #.4R0 date.8 #recs.4R sender.25 subject.26 #.0 # DATE #REC SENDER SUBJECT - ---- ---- ------ ------- 0421 94/03/01 70 BIBLIO@IMICILEA.CILEA.IT Seminario "electr.inform.i+ 0423 94/03/02 57 BIBLIO@IMICILEA.CILEA.IT SEMINARIO ELCTR.INF.LIBRAR+ 0425 94/03/03 61 BIBLIO@IMICILEA.CILEA.IT seminario Universita' Catt+ 0500 94/03/31 71 CID@POLITO.IT Esercitazioni Internet a T+ 0524 94/04/12 189 BIBLIO@IMICILEA.CILEA.IT workshop: electronic infor+ 0573 94/05/04 194 BIBLIO@IMICILEA.CILEA.IT workshop ELECTRONIC INFORM+ 0699 94/07/25 132 CID@POLITO.IT Ricerca in archivio AIB-CU+ 0806 94/09/22 57 CID@POLITO.IT Seminario AIDA-ADBS (Torin+ 1310 95/02/02 13 congiu@ndchem1.dicm.unica+ 1333 95/02/07 20 congiu@ndchem1.dicm.unica+ Il curioso avra` capito che in LIST si possono precisare campi, lunghezze, allineamenti: INDEX non e` altro che una stenografia per LIST INDEX (dove INDEX e` una specificazione predefinita, buona per usi generali). Vedendolo esplicitamente, ci accorgiamo che SENDER non indica l'intero contenuto che di solito vediamo in "From:", ma soltanto la sua parte efficace (l'indirizzo di posta elettronica). Tornando invece alla sostanza, a quanto pare da titoli e provenienze, tutte le lettere che precedono le due gia` note probabilmente nominano la persona cercata, ma non provengono direttamente da lei. Non riusciamo quindi in questo modo a delimitare il periodo di "black out". (Cio` non vuol affatto dire, cavillando, che abbiamo non abbiamo avuto risposta: il metodo era corretto, la risposta e` informativa, pur se negativa). --- Ricerche per autore (cioe`, per indirizzo) Vediamo allora cosa ha scritto ultimamente Silvia Zoletto. Se vogliamo fare una domanda precisa (basata sul SENDER), escludendo i casi in cui sia semplicemente nominata nel testo, dobbiamo sapere da quale indirizzo di posta elettronica scriva. E abbiamo il sospetto (il solito fuggevole ricordo, diciamo) che in quel caso l'indirizzo non somigli affatto al nome. Potremmo esplorare la corrispondenza, ma forse per quest'uso e` piu` comoda la consultazione di un repertorio: se non abbiamo sottomano una copia di AIB-CUR INDIR, possiamo chiedere a LISTSERV l'elenco degli iscritti attuali (comando REVIEW AIB-CUR), e ne otteniamo (riduco al minimo le 470 righe): * AIB-CUR * Discussione Associazione Italiana Biblioteche * Commissione Universita' Ricerca [...] BIBLIO@LADSEB.PD.CNR.IT Silvia Zoletto [...] * * Total number of users subscribed to the list: 442 Questa quindi la domanda, usando il frammento piu` caratteristico (sempre che l'indirizzo attuale valesse anche per il passato): SEARCH * IN aib-cur SINCE 94 WHERE sender CONTAINS ladseb > LIST #.4R0 date.8 #recs.4R sender.25 subject.26 #.0 e questa la risposta: > SEARCH * IN aib-cur SINCE 94 WHERE sender CONTAINS ladseb --> Database AIB-CUR, 14 hits. > LIST #.4R0 date.8 #recs.4R sender.25 subject.26 #.0 # DATE #REC SENDER SUBJECT - ---- ---- ------ ------- 0722 94/08/08 46 BIBLIO@LADSEB.PD.CNR.IT sos document delivery 0758 94/09/08 26 BIBLIO@LADSEB.PD.CNR.IT informazioni qua e la' 0787 94/09/15 15 BIBLIO@LADSEB.PD.CNR.IT Re: richiesta informazioni 0804 94/09/21 14 BIBLIO@LADSEB.PD.CNR.IT re colleghi CNR 0826 94/10/05 20 BIBLIO@LADSEB.PD.CNR.IT informazioni DBI-LINK 0845 94/10/10 22 BIBLIO@LADSEB.PD.CNR.IT Re: fascicoli doppi 0848 94/10/10 46 BIBLIO@LADSEB.PD.CNR.IT FWD: RE: fascicoli doppi 0889 94/10/20 25 BIBLIO@LADSEB.PD.CNR.IT catalogo periodici cercasi 0892 94/10/20 74 BIBLIO@LADSEB.PD.CNR.IT progetto Gestione Scambi 0955 94/10/27 17 BIBLIO@LADSEB.PD.CNR.IT informazioni MEDTETXT 0987 94/11/07 21 BIBLIO@LADSEB.PD.CNR.IT richiesta informazioni di + 1012 94/11/10 17 BIBLIO@LADSEB.PD.CNR.IT standard abbreviazioni per+ 1186 95/01/02 17 BIBLIO@ladseb.pd.cnr.it funzionalita' di ebsconet 1298 95/02/02 16 BIBLIO@ladseb.pd.cnr.it servizio ebsco-libri Non l'avremmo messo in dubbio, ma qui e` evidente che maiuscolo e minuscolo non fanno differenza (ma diverso sarebbe l'effetto se scrivessimo tra virgolette: con una clausola WHERE sender CONTAINS "Ladseb" il risultato qui sarebbe '0 hits'). Ci son buone probabilita` che proprio la lettera del 2 febbraio sia quella interessante (ha il # 1298, quindi precede la # 1310: Silvana Congiu potrebbe averla letta). Ma (dalla somiglianza di SUBJECT) converrebbe dare un'occhiata anche alla precedente, e (visto che son poche righe ciascuna) risaliamo comunque fino alle lettere di novembre: SEARCH * IN aib-cur SINCE 94 WHERE sender CONTAINS ladseb INDEX #.4R0 date.8 #recs.4R sender.30 subject.30 PRINT 987-9999 Potremmo cambiare la domanda (considerando la precedente solo esplorativa): non val la pena, specifichiamo soltanto nel comando PRINT che ci interessano solo le ultime (PRINT 987-9999). Ecco (elimino i testi e l'indice gia` visto, lascio solo il frammento cui Silvana Congiu si riferiva, che effettivamente e` nell'ultima lettera): > SEARCH * IN aib-cur SINCE 94 WHERE sender CONTAINS ladseb --> Database AIB-CUR, 14 hits. > LIST #.4R0 date.8 #recs.4R sender.25 subject.26 #.0 # DATE #REC SENDER SUBJECT - ---- ---- ------ ------- 0722 94/08/08 46 BIBLIO@LADSEB.PD.CNR.IT sos document delivery [...] 0987 94/11/07 21 BIBLIO@LADSEB.PD.CNR.IT richiesta informazioni di + 1012 94/11/10 17 BIBLIO@LADSEB.PD.CNR.IT standard abbreviazioni per+ 1186 95/01/02 17 BIBLIO@ladseb.pd.cnr.it funzionalita' di ebsconet 1298 95/02/02 16 BIBLIO@ladseb.pd.cnr.it servizio ebsco-libri > PRINT 987-9999 >>> Item number 987, dated 94/11/07 10:26:48 -- ALL [...] >>> Item number 1012, dated 94/11/10 10:25:38 -- ALL [...] >>> Item number 1186, dated 95/01/02 14:44:24 -- ALL [...] >>> Item number 1298, dated 95/02/02 10:57:38 -- ALL Date: Thu, 2 Feb 1995 10:57:38 +0100 Reply-To: AIB-CUR Sender: AIB-CUR From: Silvia Zoletto Subject: servizio ebsco-libri [...] E ancora per quanto riguarda l'acquisto dei libri, il cambio librario vige ancora presso i vostri fornitori? e quali sono i pro e quali i contro della sua scomparsa (o della sua permanenza)? Saluti e grazie Silvia Zoletto LADSEB-CNR e-mail biblio@ladseb.pd.cnr.it --- La ricerca sul testo Infine, il "cambio librario", che ci permette di mostrare la forma piu` comune di ricerca: quella per frammenti di parole, nell'intero testo. Una tecnica che, proprio per la generalita` d'usi per cui e` concepita, richiede circospezione, per avere risultati significativi. SEARCH cambi librar IN aib-cur SINCE 95 INDEX Uso forme troncate delle parole (avesse mai qualcuno parlato di "cambi librari" invece che di "cambio librario"). Indicare consecutivamente piu` parole implica una ricerca per intersezione: cioe` "tutti i documenti (del 1995) che contengano sia un frammento 'cambi' che un frammento 'librar'". Si potrebbe anche scrivere 'cambi AND librar', ma non e` necessario (e` invece, ovviamente, necessario, se si vuole una ricerca per unione 'cambi OR librar': meno utile e meno usuale, se restiamo alle applicazioni elementari). La ricerca e` sull'intera lettera (testo e intestazioni): dove e in che ordine compaiano i frammenti non importa. > SEARCH cambi librar IN aib-cur SINCE 95 --> Database AIB-CUR, 10 hits. > INDEX Item # Date Time Recs Subject ------ ---- ---- ---- ------- 001218 95/01/18 20:04 195 convegno catania - richiesta scheda infrom. 001233 95/01/23 14:05 38 Re: opac italiani 001271 95/01/30 15:59 68 Anteprima "AIB Notizie" 001298 95/02/02 10:57 16 servizio ebsco-libri 001302 95/02/02 14:12 35 Re: servizio ebsco-libri 001309 95/02/02 16:46 10 Re: servizio ebsco-libri 001310 95/02/02 18:16 13 001334 95/02/07 15:56 58 Riunione EFILA 001349 95/02/09 13:13 36 Re: RICHIESTA INFORMAZIONI 001353 95/02/10 12:24 88 Libri stranieri e fornitori (Siamo tornati alla forma "semplice" di LIST: INDEX). Ci son poche probabilita` che i primi tre documenti siano rilevanti: il discorso dev'esser stato aperto proprio dalla lettera # 1298. Potremmo farci stampar tutto (sono soltanto 557 righe, in totale, quindi largamente all'interno del limite fissato OUTLIM=2000: suggerisco di non modificare con leggerezza questo parametro, 2000 righe sono normalmente gia` molte). Ma sfruttiamo l'occasione per mostrare una diversa forma che puo` assumere il comando PRINT (in particolare per escludere la lettera # 1334, anch'essa certamente irrilevante): SEARCH cambi librar IN aib-cur SINCE 95 INDEX PRINT 1298-1310 1349-1353 Tutto bene (cancello tutte le lettere recuperate, tranne qualche frammento della # 1349): > SEARCH cambi librar IN aib-cur SINCE 95 --> Database AIB-CUR, 10 hits. > INDEX Item # Date Time Recs Subject ------ ---- ---- ---- ------- 001218 95/01/18 20:04 195 convegno catania - richiesta scheda infrom. [...] 001353 95/02/10 12:24 88 Libri stranieri e fornitori > PRINT 1298-1310 1349-1353 >>> Item number 1298, dated 95/02/02 10:57:38 -- ALL >>> Item number 1302, dated 95/02/02 14:12:30 -- ALL >>> Item number 1309, dated 95/02/02 16:46:52 -- ALL >>> Item number 1310, dated 95/02/02 18:16:09 -- ALL >>> Item number 1349, dated 95/02/09 13:13:25 -- ALL Date: Thu, 9 Feb 1995 13:13:25 -0600 Reply-To: AIB-CUR Sender: AIB-CUR Subject: Re: RICHIESTA INFORMAZIONI [...] Biblioteca d'Ateneo - Ufficio Scambi e Letteratura grigia ^^^^^ Library - Exchange and Grey Literature Unit ^^^^^^ [...] >>> Item number 1353, dated 95/02/10 12:24:36 -- ALL --- Il "rumore documentario" e la struttura del database Perche' lasciare qualcosa proprio dall'unica lettera che non ha nulla a che fare con il problema posto ? E` un caso (lieve, qui, ma spesso molto piu` pesante e difficile da controllare) di "rumore documentario". Ho indicato con segni '^^^' quali sono i frammenti di testo che rendono il documento effettivamente rispondente alla domanda: sarebbe bastato dire 'librari' invece che 'librar', per non avere questo inciampo. Ma e` un comportamento da attendersi normalmente in un database a struttura cosi` semplice (ed e` problema che affligge anche strutture e tecniche ben piu` raffinate di queste). Sara` normalmente del tutto inefficace, negli archivi AIB-CUR, cercare di "isolare" documenti basandosi su frammenti del genere 'bibliot', 'libr', 'AIB' ... il risultato sara` sempre inutilmente abbondante. La limitazione di piu` immediato uso in una ricerca esplorativa sara` di solito una clausola WHERE subject CONTAINS (che non ci e` servita in questi esempi proprio perche' partivamo da lettere senza SUBJECT): e questo puo` aiutare a capire l'importanza di attribuire alle lettere buoni titoli, e mantenerli uguali (rispondendo con il REPLY) per creare catene logiche di lettere facili da isolare (e viceversa, non usando un titolo vecchio per un argomento nuovo). Ma questo e` buon senso, non tecnica d'interrogazione: certo e` che LDBASE non puo` intervenire per "migliorare" il materiale che mette a disposizione. In qualunque sistema di IR (information retrieval) testuale, un progettista d'archivi che abbia a cuore la felicita` degli utenti cerca di minimizzare i problemi di "rumore" con ben noti artifici, ciascuno con i suoi pro e i suoi contro. Aumento della varieta` di indici (fino talvolta ad arrivare a troppi indici, piu` di quanti l'utente medio abbia mai occasione di sfruttare). Normalizzazione delle voci negli indici, con opportune elaborazioni a partire dai "dati grezzi" che costituiscono i documenti (o, piu` spesso, schede). Diminuzione del numero di voci negli indici, garantendo di non includervi nulla che realisticamente non serva. Il tutto si somma volutamente in un effettivo aumento del "potere risolvente" delle tecniche effettivamente disponibili in un certo sistema. LDBASE, nella genericita` d'uso che prevede quando e` applicato agli archivi dei gruppi di discussione, non puo` intervenire in questi modi (ne' d'altra parte puo` essere localmente adattato a speciali esigenze: perderebbe l'innegabile pregio di funzionare identicamente in tutti i LISTSERV). I "campi" definiti per le lettere sono due soltanto (HEADER e TEXT: ALL e` il loro insieme); cui se ne aggiungono altri due, derivati automaticamente (usabili pressoche' solo per stamparne il valore: DATABASE e #RECS). Se escludiamo # (item number, che e` da considerare la numerazione primaria di sequenza), gli "indici" (o qualcosa che loro somiglia) sono tre: SUBJECT e SENDER (controllabili con clausole WHERE) e DATE e TIME (da vedere di solito congiuntamente, e controllabili con clausole SINCE e UNTIL). Tutto qua. Mi paiono comunque notevoli i risultati ottenibili con una struttura tanto semplice. --- Precisazioni, e altre possibilita` Nessuna precisazione, per ora: chi abbia seguito con pazienza fin qui, e voglia andar oltre, non potra` fare a meno di provvedersi del manuale ufficiale (LISTDB MEMO), e lascio vuota quest'ultima parte: vi si raccoglieranno critiche, suggerimenti e aggiunte che ciascuno vorra` mandare a CID@POLITO.IT perche' compaiano in un'eventuale successiva edizione. Esiste anche un gruppo di discussione (assai poco vivace) dedicato all'argomento: LDBASE-L @UKANVM.BITNET (o @UKANVM.CC.UKANS.EDU). ------------------------------------------------------------------------ Note editoriali Scritto per CIDEM (Centro di Documentazione e Museo del Politecnico di Torino), e messo a disposizione di AIB-CUR in data 1995-02-21. Esempi basati su interrogazioni svolte in data 1995-02-17. Nel testo degli esempi, tacitamente troncate al 72. carattere alcune righe originariamente piu` lunghe (o lievemente alterata l'impaginazione del testo). 1995-03-09, -06-07, 1996-06-27. Ritoccato, non sostanzialmente. 1996-12-09. Corretto errore di datazione (la riga d'intestazione portava 1995-... invece di 1996-06-27). 1998-04-25. Corretto errore materiale in un esempio.