ISKO Italia. Documenti. La bottega del sapere
| Home page | Iscrizione | Documenti | Bibliografia | Collegamenti |
|---|
Una piccola selezione dei messaggi inviati da Eugenio Gatto alla redazione di AIB-WEB
(gennaio 1996 - giugno 1997)
a cura di Riccardo Ridi
Come già descritto e documentato altrove (aib.it/aib/editoria/n17/0509aibweb.htm, aib.it/notizie/addio-a-eugenio-gatto/), Eugenio Gatto è stato fra i fondatori e fra i principali responsabili del sito web dell’Associazione Italiana Biblioteche, a partire dai primi progetti (fine 1995) fino al debutto pubblico (inizio 1997) e poi almeno fino al 2009. Uno dei suoi numerosi contributi a tale iniziativa fu la creazione e la gestione di numerosi “gruppi di discussione” attraverso cui coordinatori, redattori e collaboratori del sito si scambiavano messaggi di posta elettronica. Dagli archivi di tali gruppi ho estratto quindici messaggi risalenti ai primi due anni dei lavori, che ne hanno gettato le fondamenta e impostato il metodo. Tutti (eccetto uno, brevissimo, mio) sono opera di Eugenio, spesso in risposta, più o meno esplicita, a quelli inviati dai membri della redazione. Di Eugenio è anche il titolo di questa raccolta, ripreso dal sottotitolo di uno dei suoi messaggi.
I messaggi selezionati — non solo perché particolarmente significativi ma anche in quanto sufficientemente comprensibili senza troppo contesto — sono stati trascritti in ordine cronologico e includono quelle che sono probabilmente state le prime (o, quanto meno, fra le prime) manifestazioni di alcuni fra i più fortunati “slogan” di Eugenio, come: “WWW da bibliotecari”, “WWW da scrivere”, “WWW come database”, “pestarsi i piedi”, “password di Pulcinella” e “rename di archiviazione”. La loro lettura, sia all'epoca che — forse ancora di più — dopo quasi trent'anni, mostra chiaramente quanto per Eugenio progettare e gestire un sito web (soprattutto, ma non solo, se di una associazione professionale di bibliotecari) non fosse una questione esclusivamente informatica, ma anche (e principalmente) di knowledge organization.
La curatela redazionale si è limitata (oltre alla selezione) al grassetto con cui sono state evidenziate le intestazioni, alla correzione di un paio di banali refusi e, in un solo messaggio, a una omissione e una integrazione fra doppie parentesi quadre, mentre le parentesi quadre semplici sono tutte originali dell'autore, così come gli “a capo” precoci, gli apostrofi al posto degli accenti e l’assenza di corsivi: tutti accorgimenti finalizzati a facilitare la lettura con qualunque tipo di schermo e software. Ultime avvertenze: alcuni degli acronimi utilizzati da Eugenio corrispondono alle lettere iniziali dei nomi e cognomi di membri della redazione AIB-WEB e di fornitori esterni di servizi informatici; inoltre, quando scrive “in AIB-WWW”, Eugenio intende “nei gruppi di discussione postali della redazione di AIB-WEB”.
--- Prove e password / Eugenio Gatto. - Torino, 1996-01-27
--> Redazione WWW AIB <cid+aib-www@polito.it>
Ho gia` annunciato che sarei intervenuto sull'argomento, sul versante
retorico e su quello strutturale. In realta` si tratta di due facce
dello stesso problema, per accordare la duplice necessita` di stabilita`
e modificabilita`.
Se mostrare dei rinvii che non funzionano e` cattiva tecnica (credo si
possano avere o scrivere dei marchingegni che verifichino la solidita`
dei riferimenti locali almeno), mostrarli per poi chiedere una password
e` cattiva retorica: da` l'idea di privilegi, di possibilita` vietate ai
comuni mortali, &c.
Quindi: quel che c'e` c'e` e si raggiunge, quel che non c'e` non si
vede del tutto (cioe`, non e` un rinvio, al massimo e` un testo che fa
da segnaposto). Questo implica che se diverso e` il modo di accedere
(utenti - redazione) diverse sono le basi (problema generale di
qualunque sistema al mondo, versione leggibile "in produzione", versione
scrivibile (in un certo senso, e piu` o meno completa) "in prova" e ad
accesso protetto).
Quindi, nella voluta semplicita` di HTML, dato che il tutto si basa su
legami interni ai testi, almeno da un certo punto in la` il testo "in
prova" e quello "in produzione" divergono, perche' quello pubblico deve
contenere rinvii in meno, o comunque diversi.
L'unico compromesso semplice che mi viene in mente e` quello della
doppia struttura, per cui la versione pubblica sia un sottoinsieme
stabile derivato da quello di lavoro: l'accesso di lavoro essendo
diverso, e noto e usabile soltanto agli addetti (e li` la password va
benissimo, ed e` sufficiente associarla sul testo d'ingresso). Forse ci
sono modi astuti per evitare lo spreco della brutale duplicazione, ma
semplicisticamente forse non e` quello dello spazio su disco il
problema maggiore.
Questo varrebbe al centro dove tutto confluisce: ma possiamo vederlo
come una riproposizione del problema generale generale dei cataloghi
collettivi, se teniamo presente che ulteriori copie (temporanee,
parziali, anche d'un testo solo, ma a volte necessariamente d'un intero
ramo) coesistono presso chi possa o intenda modificare qualcosa.
Mi fermo: non ha senso che vada oltre se sto parlando arabo, o se mi sto
ponendo un falso problema.
--- WWW come database / Eugenio Gatto. - Torino, 1996-01-30
--> Redazione WWW AIB <cid+aib-www@polito.it>
[[…]] Questi obiettivi [[di automazione e flessibilità nella gestione
del sito web dell’AIB]] per me implicano soprattutto che l'insieme di
testi che costituiscono il server sia considerato e trattato come un database
(ma, per favore, non pensate immediatamente a DB3 o alle tabelline: non
hanno mai offerto facilitazioni degne di considerazione a chi tratti
testi, e ai bibliotecari in particolare). Un database a livello di
sistema operativo (le "schede" sono file, in realta`), ma non per questo
privo degli strumenti fondamentali per un aggiornamento corretto ed
efficace.
Su qualunque server decisioni strutturali vanno prese. Nulla vieta che
le si prenda in modo da realizzare qualcosa nel senso che ho detto: la
tecnica di rinvio WWW (ripeto) permette facilmente di disgiungere i due
aspetti. Come bibliotecari, dovremmo perfettamente saper gestire rinvii
d'ogni genere, da sempre tecnica di base nel nostro mestiere (anche
quando il mezzo d'espressione era la scheda 75x125).
--- Pinocchioware / Riccardo Ridi. - Firenze, 1996-12-18
--> Coordinamento WWW AIB <cid+aw-coord@polito.it>
Ma sono impazziti a Anyware? Ecco cosa vedo chiedendo <http://www.aib.it>:
Index of /
Name Last modified Size Description
Parent Directory 24-Oct-95 16:52 -
aib/ 25-Oct-95 13:30 -
pinocchio/ 27-Oct-95 11:51
--- Pinocchioware / Eugenio Gatto. - Torino, 1996-12-18
--> AIB-WEB. Coordinamento <cid+aw-coord@polito.it>
Ah, credo stiano solo pasticciando su quel povero Macintosh (o chissa`
qual altro catorcetto). E` tipico dei "sistemisti" non avere nessun
pudore nei confronti di quel che il pubblico potrebbe vedere ... tanto
nessuno e` abilitato a capirci qualcosa. Non ne farei una caratteristica
specifica di particolari tribu` o scuole (non per nulla da molti anni
cerco di essere considerato un bibliotecario, a scanso di confusioni
autolesionistiche).
--- Rapporti con i fornitori / Eugenio Gatto. - Torino, 1997-01-14
--> Redazione WWW AIB <cid+aib-www@polito.it>
Io credo che l'esperienza attuale debba soprattutto servirci per
imparare come ci si comporta con i fornitori (il mestiere bibliotecario
ha anche questa sfaccettatura). Non dobbiamo immaginare che questo
fornitore sia particolarmente peggio di altri: ma, come tutti, deve
rispettare gli impegni per cui intende essere pagato (server WWW e FTP,
come minimo, quindi). Personalmente non sono molto favorevole a lasciar
correre: non e` questione di sostanza (possiamo anche buttar via tutto
quel che c'e`, e in mezza giornata ricostruire: a discrezione nostra,
non loro), ma di abituarci a distinguere bene ruoli e mestieri diversi.
Sappiamo gia` per certo che non c'e` corrispondenza esatta tra file
dello stesso nome sui due sistemi; neanche, talvolta, tra omonimi su
WWW.ANYWARE.IT, e su questo stavamo lavorando. Quest'ultimo punto e`
curioso, perche' risale in massima parte proprio ad un'operazione
sistemisticamente sconsiderata (in particolare quando si sappia che il
tutto dovra` migrare o, addirittura, essere reso integralmente
disponibile su piu` siti diversi) cui si sono dedicati i nostri
fornitori: "... a causa di errori (ho dovuto cambiare molti link
all'interno delle pagine in quanto erano relativi e non assoluti) ..."
[lettera non passata in AIB-WWW: AV -> RR, 1996-12-11].
In questi particolari tecnici lo "stile" dev'essere unico, e ben noto a
chi scrive pagine HTML o (meglio, e spero di arrivarci presto)
indifferente per gli autori perche' verificato e garantito via software,
per ogni pagina creata o modificata. Dubito che questa parte sia
attualmente disponibile presso i fornitori (visto che alle modifiche han
lavorato manualmente: la macchina non garantisce di per se' la
correttezza, ma almeno l'uniformita` (e un uniforme cambiamento quando
risulti necessaria o preferibile una tecnica diversa)).
Quindi, anche solo per esercizio mio, avrei davvero bisogno di
continuare a lavorare su questo genere d'infrastruttura. Non amo
"lasciare la via vecchia" se non sono certissimo che la nuova sia
migliore o equivalente, e vorrei effettivamente verificare l'equivalenza
(al limite, trasferendo fisicamente io le parti utili da WWW.ANYWARE.IT
ad un WWW.AIB.IT vuoto o appositamente svuotato). Ho bisogno per questo
dei due FTP: il fornitore non mi pare abbastanza accurato da poter
certificare la validita` del trasporto, e (se ritenente utile una
responsabilita` da parte mia in questa direzione) la coerenza
sistemistica dell'insieme e` un minimo che intenderei garantire per
levare un pensiero a tutti. Esempio: la domanda di AM su quale file
indicare nel rinvio dovrebbe avere una risposta semplice e univoca (un
singolo nome, senza preoccuparsi di dove per accidenti stia).
Dovremo probabilmente rinunciare anche ad affidare la sicurezza (cioe`,
il non pestarci i piedi lavorando a piu` mani) a quei sistemi: non ha
senso avere password se non si ha un comando per cambiarsele da se',
tanto vale una password "di Pulcinella". Questo implica l'inutilita` (al
di la` delle questioni nomenclatorie) di suddivisioni gerarchicamente
separate, artificio che e` stato proposto, con mio tiepidissimo
consenso, esclusivamente come modo pratico per associarci le password.
Credo convenga semplicemente fidarci, per ora, che nessuno modifichi
roba non sua.
--- Prove di scrittura / Eugenio Gatto. - Torino, 1997-01-29
--> Redazione WWW AIB <cid+aib-www@polito.it>
Per favore, tutti provino a scrivere almeno un file fasullo, in modo che
io riesca ad avere l'elenco delle correzioni da far fare al sistemista.
Son gia` parecchie (alcune prevedibili e previste, ma preferirei avere
documentazione direttamente visibile sul WWW, visto che poi mi tocca
spiegare per telefono: almeno potro` aiutarmi dicendo "Guarda qui,
guarda la`").
VB e` a posto: scrive in SEZIONI, i suoi file sono marcati BERTINI
SEZIONI. (Faccio notare che non e` cambiato nulla, che io sappia, da
quando riscontrava invece che non gli funzionava).
SG e` quasi a posto: scrive in COMMISS, ma i suoi file escono marcati
GIACCAI AIBCUR.
Su EB ho dubbi: il file che ha scritto in COMMISS (AIB-COM) e` marcato
GIACCAI AIBCUR (non dovrebbe essere cosi` se per fare FTP ha usato il
suo nome e password ... meglio riprovare, diciamo scrivendo un fasullo X.EB).
AZ (Andreas Zanzoni) ha scritto in EDITORIA un file MAZZITELLI EDITORIA
(dimostra quindi che GM e` a posto); appena si faranno le varie
rettifiche avra` nome proprio, sempre nel gruppo EDITORIA.
RR e` a posto, i suoi file escono RIDI AIB. Ma, se non l'ha ancora
fatto, sarebbe bene che provasse a piazzare un suo file di prova
(diciamo X.RR) in tutti i rami, in modo da vedere in quali punti non
riesca a scrivere (ammettiamo per il momento che sia credibile, volendo,
che non possa scrivere in rami di lavoro usati da me per archiviazione e
simili lavori accessori: questa ce la possiamo vedere tra noi due).
Avevo gia` anticipato che per me stesso sara` meglio avere in vigore due
nomi: attualmente le mie marche risultano GATTO AIB (se son lavori che
ha fatto FRANK) o GATTO AIBCUR (se ho fatto io in FTP). Dovrebbe invece
risultare GATTO AIBCUR per quel che sta in AIBCUR, con le consuete
limitazioni a quei confini, e qualcos'altro (ad esempio EG AIB) per
eventuali interventi altrove.
Resta da vedere la situazione di tutti gli altri.
--- META tags / Eugenio Gatto. - Torino, 1997-02-04
--> Redazione WWW AIB <cid+aib-www@polito.it>
"... <META name="keywords" content="Italian library association,
Associazione italiana biblioteche, MIDAS">" [RR]
"... esiste il <meta name="author"....> e il <meta name="generator".....>
quest'ultimo indica il programma utilizzato ..." [AZ]
Direi che siamo in piena giurisdizione bibliotecaria (indicizzazione a
beneficio di algoritmi di ricerca, piu` o meno noti).
In attesa che ne sappiamo di piu` (conto in particolare sulla buona
volonta` e abilita` nello star dietro alle norme di AC), suggerirei di:
1. [metalinguistico, non insisto] Chiamare in genere 'campi' i 'tag':
termine consolidato, mentre TAG indica solo il loro nome? Nel caso
specifico META sarebbe un campo, AUTHOR un suo sottocampo (eventualmente
in notazione gerarchica META.AUTHOR, quando possano nascere equivoci).
2. Non usare campi o sottocampi di cui non siano certi impiego e
utilita`; META.GENERATOR, ad esempio, mi pare di alta inutilita`, al
momento.
3. Per quelli che si usano, in modo uniforme ovunque (quindi costruibile
"a macchina"), se serve a unificare e non a differenziare: nei primi
tempi ci servira` che WWW.AIB.IT venga reperito come un tutt'uno, le
esigenze di differenziazione verranno poi (quando il materiale sia
molto, la struttura consolidata o resa piu` flessibile, il numero di
accessi tale da giustificare la fatica). Al momento, se mai si dovesse
usare META.AUTHOR (non credo) tenderei a dire che sia uniformemente
"AIB", posto che serva a far saltar fuori automagicamente dai "motori"
(scusate, ne ho poca pratica).
4. Da bibliotecari, META.KEYWORDS dovrebbe essere usato come ripetibile
esplicito, cioe`
<META name="keywords" content="Italian library association">
<META name="keywords" content="Associazione italiana biblioteche">
<META name="keywords" content="MIDAS">
invece che implicito:
<META name="keywords" content="Italian library association,
Associazione italiana biblioteche, MIDAS">
Ricordo di aver letto da qualche parte (DIGLIB ? ... non importa) sulla
correttezza dell'usarlo cosi` per un caso in cui serviva a riutilizzare
i soggetti LC.
5. Su META.DESCRIPTION mi pare che RR sia d'accordo sull'uso di una
dicitura fissa ovunque; da quel che propone toglierei solo il preambolo
"Website of the" (contestualmente inutile) e le "parole vuote".
Insomma: "Associazione italiana biblioteche (AIB, Italian library
association) : official information, members, publications". Se si
escogitera` poi di meglio (e succedera`) cambieremo "a macchina" tutti i
META gemelli.
Ma (fuori numerazione) siamo certi che vogliamo i META ovunque?
Non sara` solo per dare qualcosa in pasto, visto che esistono, ai
marchingegni di ricerca? Dopotutto (esagero) potrebbe essere piu`
produttivo averli solo nel frontespizio, se il nostro WWW e` "da
bibliotecari", e ci interessa che ci arrivino soprattutto per quella via
(e altrove metter quindi, se necessario, dei META insignificanti per
"narcotizzare" i marchingegni). Secondo me il miglior modo di essere
trovati da chi ci interessa che ci trovi resta il fatto che basti sapere
(una volta tanto difendo il valore mnemonico delle parole) che il
"nostro" si chiama semplicemente WWW.AIB.IT.
--- Meta-metodologico / Eugenio Gatto. - Torino, 1997-02-07
--> Redazione WWW AIB <cid+aib-www@polito.it>
Uno degli aspetti che trovo affascinanti (per la tangibilita` che
acquisisce, nel povero mezzo postale) e` l'intrico di livelli a cui ci
muoviamo, e che, in gradi e con artifici diversi, cerchiamo di tenere
distinti. A me pare che il rifletterci sia parte del mestiere, e non mi
fa sentire un perdigiorno, ma non voglio certo che ci investiate un
tempo che certamente e` per voi piu` scarso che per me. Tollerate solo,
ogni tanto, che si scriva qualcosa anche solo perche' s'ammucchi in
archivio.
Da parte mia vuole essere, a spizzico, il sostituto di una relazione che
avevo promesso in occasione di una riunione, a Roma, a fine maggio
(quella da cui derivo` il contratto con Anyware &c &c). In
quell'occasione facevo poco chiari schemini su un pezzo di carta, e
lanciavo slogan come "WWW da scrivere", "WWW da bibliotecari", "WWW come
database": tre aspetti diversi su cui sapevo difficile andare al di la`
della proclamazione entusiastica, finche' non avessi potuto almeno
basarmi su esempi pratici.
Detto questo, uno dei livelli (che restera` praticamente indecifrabile
nel risultato finale quale si vedra` in pubblico) e` il lavoro stesso in
AIB-WWW, che sta funzionando in modo impressionante (anche troppo, puo`
essere la sensazione: ma stiamo riuscendo a fare, semplicemente per
posta, un effettivo lavoro cooperativo [uno degli stadi del "WWW da
scrivere"]). L'archivio di gennaio e` di 120 lettere, 5'400 righe: poco
meno di AIB-CUR, e con molte meno "impertinenze". A quante ore di
riunione corrisponde? Non importa, in realta`: mi pare che il mezzo
diverso (con la possibilita`, ma senza l'assillo, della risposta
immediata) aiuti a rendere gli scambi piu` densi e ponderati.
Mi fermo. Ritengo che non debba spaventare il volume di AIB-WWW, non
tutto e` per tutti, inevitabilmente si creeranno specializzazioni.
Manterrei comunque un'unica sequenza, quale non disprezzabile forma di
documentazione di un lavoro che potrebbe anche non avere molti altri
riconoscimenti (e` gia` stato ricordato che ci muoviiamo su base
esplicitamente volontaristica). E, al contrario di temere "archivi
sporchi", direi che uno degli aspetti del "WWW da bibliotecari" puo`
essere anche il fatto che ci chiediamo e spieghiamo impudicamente in
AIB-WWW anche quelle minuzie (o enormita`) che alcuni percepiscano come
banalita` tecniche e altri invece come vergognosi "buchi culturali":
resterei sul fatto sostanziale che siamo bibliotecari (non informatici,
grafici, tipografi, editori, venditori &c), il resto (ben venga, ma) e`
accidente, e non ci sfigura.
--- Pagina CNUR, come pretesto / Eugenio Gatto. - Torino, 1997-02-12
--> Redazione WWW AIB <cid+aib-www@polito.it>
Ovviamente, citando da AM (lettera e relativi file), vado sui
particolari di applicabilita` generale: dopo essermi associato ai
complimenti (anche se non compensano dei faticosi dubbi e titubanze che
tutti patiamo quando, anche dove in teoria sembri tutto chiaro, in
pratica bisogna buttarcisi davvero: a me, ad esempio, bruciano assai le
due ore e mezza passate ieri a cincischiare, per competenza nettamente
insufficiente, tra telnet, mail di UNIX e suo [orrore] editor).
Una sola precisazione sul testo: ho tolto la 'e' tra Universita` e
Ricerca, nel nome della Commissione (sono certo che non dovrebbe
esserci, anche se non son certo se ci voglia invece un trattino).
"nella cartella commissioni". Ci intendiamo, ma tanto vale chiamarla
COMMISS. COMMISS/, anzi, per specificare rapidamente che e` un ramo
(directory, cartella). /AIB/COMMISS/ (forma da usare negli URL
semi-assoluti) sarebbe strafare, visto che tutto e` in /AIB/. Il
maiuscolo denuncia l'artificialita` del nome (e aiuta a forse a
ricordare che sul server e negli URL invece usiamo sempre il tutto
minuscolo).
"un ...commiss_cnur.index e un commiss_cnur_progr.htm." Gli ho ben
presto cambiato nome: il primo era AIB_COM_COMMISS_CNUR.INDEX,
iperlungo, viene ovvio tralasciare qualcosa. I nuovi nomi sono CNUR.HTM
e CNUR-P.HTM (ho aggiustato i rinvii interni, ovviamente). "inserire
... nella pagina aib-com. htm. Lo fai tu o lo faccio io?": EB, nel
modificare AIB-COM, ha gia` tenuto conto del nuovo nome.
Se ne possono fare molti piccoli discorsi particolari. [Ma non e` il
manualetto che MLR [1997-02-08] vedrebbe come "estrazione ragionata e
coordinata": quello, appunto, dovra` descrivere la prassi consolidata e
voluta, non i miei capricci.]
- Gerarchia delle modifiche. La strutturazione gerarchica (che, ricordo,
e` per la gestione del lavoro, non perche' obbligatoriamente traspaia a
chi consulta il nostro WWW) e` stata proposta e adottata per questioni
di abilitazioni, password &c. All'interno di ciascun ramo, chiaramente,
tutti possono modificare tutto: ma mi pare bene che ciascuno modifichi
quanto e` suo (riproducendo, senza bisogno di formalizzarle, le
gerarchie: alla radice [tronco?] di tutto c'e` /AIB/DEFAULT.HTM, che RR
modifica man mano perche' i rami siano correttamente "attaccati", e
cosi` discendendo; in questo discorso ci importa solo l'impalcatura
principale, e attualmente da AIB-COM si dirama CNUR, quindi tocca a EB
eseguire l'innesto).
- Tipi dei file. "un ...commiss_cnur.index". INDEX non va bene (non
viene automaticamente trattato come un testo interpretabile secondo il
linguaggio HTML). Abbiamo gia` stabilito che, attualmente, usiamo tipi
di lunghezza 3 (non contando il punto, che ci vuole). Quindi, per le
immagini abbiamo GIF JPG e PIC; per i testi HTM e TXT (ne trovate uno
mio, AIBCUR/WELCOME.TXT: sarebbe scorretto contrabbandare per HTML quel
che non lo e`); fa eccezione (ne parleremo un'altra volta) il solo
INDEX.HTML (che e` fuori giurisdizione, e` solo un diverso nome di
/AIB/DEFAULT.HTM e serve a far funzionare il piu` semplice URL assoluto
che vogliamo sia noto per il nostro WWW, <http://www.aib.it>).
- Alfabeto usabile. "abc...xyz0...9-". La sottolineatura e` scartata
(per totale illeggibilita` in un testo che venga presentato tutto
sottolineato: orrore estetico, certo [quanti tipografi seri avete mai
visto usare la sottolineatura?], ma sui terminali non grafici viene
sparso a piene mani). L'iniziale WXYZ e` riservata per marcare file
definitivamente o temporaneamente "non pubblici" (cioe` non richiamati
esplicitamente in testi HTML, da /AIB/DEFAULT in poi).
- Lunghezza dei nomi. Anche cercando la mnemonicita` [non la sto
difendendo], accontentatevi di quel vi basti localmente. Al di la` del
buon senso e della comodita` di scrittura, bisogna tener conto di vari
sistemi operativi (non solo il povero MS-DOS) con forti limitazioni
(tipicamente 8 caratteri). E se tenete conto che vi puo` spesso servire
aggiungere una X iniziale, per una versione di prova dello stesso file,
siamo a 7. [Il suggerimento di AZ [1997-01-30], 10 caratteri, forse
deriva da considerazioni del tutto analoghe basate sul fatto che certe
versioni e parti di UNIX hanno o avevano 14 come massimo, da cui
usualmente sottrarre 4 per il tipo del file e il punto che lo precede].
- Struttura dei nomi. Date per scontato il contesto: cioe` usate tecnica
di soggettazione, piu` che di classificazione (la mia tendenza sarebbe
opposta, e forse riusciro` a convincervene, ma non c'e` bisogno che
spieghi a bibliotecari che i nomi classificati sono fondamentalmente
incompatibili con la mnemonicita` semplice, cioe` con l'uso di nomi
espressivi a prima vista). Nei vecchi nomi abbiamo pesanti ridondanze
notazionali (molti che cominciano per AIB-: chiaramente inutile visto
che AIB e` l'universo del discorso); eliminandole ci sara` possibilita`
per giochi piu` significativi.
- Forma dei rinvii. Per la maggior parte dovrebbe trattarsi di rinvii
locali-locali (nel proprio ramo), quindi semplicemente del tipo
HREF=”cnur-p.htm". Se sono esterni al proprio ramo, sempre in forma
semi-assoluta: HREF="/aib/redazione.htm". Se sono al frontespizio,
sempre nella forma assoluta piu` semplice: HREF="http://www.aib.it"
(AC ha sperimentato anche l'elegante HREF="/": se a tutti risulta che
funziona ovunque, potremo adottare quello). I rinvii ad immagini
attualmente sono sempre dei SRC="/aib/wi/nome.tipo". Sono d'accordo che
(per uniformita` e conseguente eliminazione di dubbi) anche RR nei file
"del tronco" mantenga queste convenzioni (non necessarie, dato che li`
potrebbe scrivere COMMISS/AIB-COM.HTM, invece di
/AIB/COMMISS/AIB-COM.HTM: gli utenti vedrebbero comunque lo stesso URL).
- Commenti interni. Nel "dare un'occhiata" (si trattava soprattutto di
normalizzare i rinvii) ho aggiunto anche in HEAD quello che considero il
commento minimo indispensabile (per tutto il resto si puo` anche voler
pensare che il testo si spieghi da se'), nel caso specifico questa data
e sigla di nascita: <!-- 970210.AM -->
--- Completezza della struttura / Eugenio Gatto. - Torino, 1997-02-13
= Per i WWW non e` mai inverno, ci siano sempre anche tutte le foglie.
--> Redazione WWW AIB <cid+aib-www@polito.it>
Ultimo, e il piu` importante: gia` detto, ripeto e lo ridiro` ancora.
Per quanto facciate, un WWW e` pubblico anche se non pubblicizzato: come
minimo (non sto ad annoiare con le statistiche di accesso) stanno gia`
ampiamente scorrazzando i robot indicizzatori; ma non solo loro: il nome
WWW.AIB.IT e` volutamente appetibile.
Se preferite lavorare top-down, e nei file ci sono i rinvii (ed e`
giusto che ci siano: non e` male che anche chi ci caschi per caso abbia
un'idea dei "lavori in corso"), devono essere TUTTI rinvii soddisfatti,
quindi a file col nome giusto e nella posizione giusta: solo, il loro
contenuto deve essere un bigliettino che dica "Presto ci sara` davvero:
per ora chiedetene a <A HREF="<mailto:...>...</A>". Per molti puo` avere
lo stesso significato di un "404 File not found", ma ad alcuni puo` far
apprezzare cosa puo` essere un "WWW da scrivere".
Ho quindi aggiunto in tutti i rami un "segnaposto" fisso (WORK.HTM) da
ricopiare (GET, seguito da PUT con nome diverso) come tappabuchi: rinvia
a RR, ma forse e` bene che ciascun responsabile di ramo lo modifichi in
modo che il MAILTO rinvii piu` correttamente. L'ho gia` ricopiato in
COMMISS/ come INDIR0 INDIR1 CONV FORM OPAC STATUTI.
Usi laterali (o fondamentali?) di una procedura del genere. Dato che i
nomi si stanno inventando a piacere, e` bene "occuparli subito", in modo
che ad altri che collaborano nello stesso ramo non venga in mente
proprio lo stesso nome (la fantasia, lo state gia` vedendo, si esaurisce
presto: ed in particolare se si vuole essere mnemonici).
Naturalmente, prima di scegliere un nome, dovete badare a che non sia
gia` in uso; altrimenti ben sapete che il nome e` solo un recipiente,
ed il contenuto che arriva per ultimo vince: e` quel che chiamo
"pestarsi i piedi" (e, se sono di umore peggiore, "farsi le scarpe",
cosa che, per semplice dimenticanza, uno riesce benissimo a fare a se
stesso). Qui ci vorrebbe tutto un discorso legato all'idea di "WWW come
database", dato che e` il tipico e ben noto problema dei conflitti per
accesso multiplo sulla medesima scheda (record) ... un'altra volta.
Ma e` per difesa elementare da questi avvenimenti che insisto nel
richiedere che venga sempre usata (anche per i propri file) la
sostituzione col metodo della "cancellazione reversibile", cioe` basato
su cambiamenti PREVENTIVI del nome del file, prima che rischi di essere
irreversibilmente sovrascritto. Quando poi si e` certi che davvero la
copia vecchia non serve piu` (neanche per archiviazione e
documentazione, perche' troppo poco diversa dalla nuova, garantita,
funzionante non meno bene della vecchia) si puo` fare il DELETE. In
questi casi di semplice ritocco (miglior giudice dovrebbe essere
l'autore) non c'e` bisogno di usare il RENAME di archiviazione (es.
CNUR.HTM -> CNUR-970212.HTM), basta qualcosa di piu` semplice ed
economico (CNUR.HTM -> CNUR-X.HTM).
--- NAP o MIDAS? / Eugenio Gatto. - Torino, 1997-02-17
--> Redazione WWW AIB <cid+aib-www@polito.it>
Dica MLR se i vincoli europei richiedono il cambiamento di nome di quel
ramo, perche' allora probabilmente e` da fare entro il fatidico 22. Per
noi e` fattibilissimo: basta cambiare nome, e aggiornare i rinvii (non
dovrebbero essercene molti, per ora). Diventerebbe il ramo MIDAS, su cui
sono abilitati a lavorare coloro che appartengono al gruppo NAP.
Lo dico in AIB-WWW per precisare (al di la` della nascita di questo
altro [previsto] livello di nomenclatura, per cui non necessariamente
rami e abilitazioni sono in corrispondenza stretta) il metodo necessario
per lavorare senza incoerenze.
Dev'essere possibile che qualcuno/qualcosa "aggiusti" d'ufficio i rinvii
ovunque, in casi di questo genere (anche solo perche' in qualche punto
il diretto responsabile non ha avuto occasione di farlo: e non e`
proprio il caso di emanare la prescrizione e poi aspettare che tutti
abbiano confermato d'aver eseguito, altrimenti le calende greche sono
dietro l'angolo).
Allora, anche se solo per micro-differenze tecniche, l'unica copia
credibile di un file e` quella che risiede sul WWW (anche per l'autore,
che comunque e` bene tenga la "sua" ultima copia, cui ricorrere in caso
di incidenti).
E quindi ogni modifica comincia con un prelievo (GET, DOWLOAD), continua
(in locale) con gli aggiornamenti del caso, si conclude con una
riscrittura (PUT) [preceduta da un RENAME di archiviazione, se si tratta
di modifiche significative].
L'originale che resta all'autore e` (in quel momento, ma poi, forse,
chissa` quando, non piu`) conforme alla copia in WWW. Diversamente,
spesso si scoprira` che si e` ripartiti dalla PENULTIMA versione (ed e`
quel che si fa, volutamente o perche' costretti, quando si usa un "backup").
--- Procedura di sostituzione / Eugenio Gatto. - Torino, 1997-02-25
--> AIB-WEB. Segreteria tecnica <cid+aib-whelp@polito.it> + AM
[Rispondere a CID+AIB-WHELP, non a CID o altro indirizzo privato. Ho da
poco inventato questo gruppetto, per i particolari tecnici. Vediamo se
funziona (a mezza strada tra pubblico e privato: una pioggia di dubbi su
uno stesso argomento ovviamente consiglierebbe di riparlare della cosa
piu` in grande).]
"Ho pronti due file rivisti cnur.htm e cnur-p.htm: come faccio a
sostituirli? Poiche' non posso sovrascrivere e non devo cancellare il
file attualmente esistente (o posso farlo?), pensavo di rinominare il
file vecchio e sostituirlo con il mio nuovo." [AM]
Benissimo quel che hai pensato: ed allora la procedura sarebbe questa:
prima un RENAME CNUR.HTM CNUR-970225.HTM, e poi PUT CNUR.HTM (stessa
cosa per l'altro). Il nome cambia, non c'e` sicuramente pericolo di
interferenze con altri nomi, e l'aggiunta '-970225' dichiara la data in
cui quella versione e` stata messa in pensione (cosa che puo` poi
servire per un eventuale archivio storico).
Nota che questo merita farlo se le modifiche sono un pochino
significative (anche se non tali da dichiarare una diversa data di
ultimo aggiornamento in coda al testo: quella che si vede in pubblico,
e che non si cambia per semplici aggiustamenti).
Perche' invece PUOI tranquillamente sovrascrivere il file esistente
(basta fare PUT, e la versione vecchia e` del tutto e subito persa):
quindi, per sicurezza (per non mordersi le dita poi), forse conviene nei
primi tempi usare comunque sistematicamente la tecnica del "rename di
archiviazione" (da cui si puo` sempre tornare indietro). Poi sfoltiremo
gli archivi; lo spazio su disco non costa nulla.
Ultima cosa (riscrivi tranquillamente, se restano dubbi). Spero tu ti
sia basata, per aggiornare, su CNUR e CNUR-P come erano sul server, e
non su tue copie precedenti: avevo ritoccato io qualche rinvio. Ma
altrimenti non importa: fai i RENAME e PUT, poi vediamo se resta qualche
dettaglio tecnico da ritoccare.
--- Dubbi sui doppi rinvii / Eugenio Gatto. - Torino, 1997-04-01
--> AIB-WEB. Redazione <cid+aib-www@polito.it>
Mi pare una questione abbastanza generale: ma dico in base al mio
comportamento (si tratta di psicologia dell'utente, soprattutto), ed e`
possibilissimo che le mie idee risultino troppo personali (quindi
considerate quelle che seguono come indicazioni che cerco di valutare e
far valere per me stesso).
Secondo me, solo in caso di strutture molto particolari possono esserci
nella stessa pagina (1) piu` punti di rinvio alla stessa cosa; e qualora
ci siano (2) devono presentarsi in modo che la voluta ripetizione sia
evidente. La ragione psicologica e` quella di evitare che, attivando
rinvii a prima vista diversi, l'utente non sia deluso ritrovando
esattamente quel che ha visto poco prima.
Al di la` delle false aspettative, ho poi tecnicamente sempre il timore
di divergenze (possibili tra pagine diverse e nella stessa pagina).
La non duplicazione (interna o tra livelli adiacenti) mi piacerebbe in
particolare nelle pagine strutturate come elenchi (sezioni, commissioni
&c): secondo me non c'e` vantaggio per l'utente a dare attivabili
ovunque tutte le voci che potenzialmente lo sarebbero, ma al contrario
(finche' le nostre strutture non sono troppo complesse) credo ci
convenga incentivarlo un pochino a "salire sull'albero" (anche solo per
un'onesta promozione a quelle zone dove l'albero e` un po' piu` folto).
In futuro, con un WWW piu` ricco, certamente saranno preferibili
strategie diverse.
Esempio: se la suddivisione X ha la sua pagina, sia attivabile quella,
che all'interno avra` attivabili i MAILTO dei vari componenti e tutto
quel che serve; se (per completezza e omogeneita` di presentazione
[logica ed utile]) la pagina iniziale di elenco riassume queste
informazioni, queste siano attivabili di li` solo per le suddivisioni di
cui non segua la pagina specifica.
Mi pare invece "troppo pubblicitario" accentuare isolandole (come ad
esempio in AIB-REG) le suddivisioni che hanno una pagina propria,
rispetto a quelle che non ce l'hanno. O si ritiene utile un elenco
iniziale per saltare rapidamente alle varie suddivisioni (tutte, pero`),
o niente: e propendo per questa, come sempre quando si tratti di pagine
piuttosto corte ed omogenee (anche qui, mi sembra lecito che attualmente
abbiamo interesse a che gli utenti effettivamente facciano un po' di
"browsing" anche all'interno della pagina). Ma mi sembra
sufficientemente distintivo che il nome della suddivisione si presenti
(e tutti i client fanno la differenza) come rinvio attivabile o come
semplice testo, per chiarire il diverso impegno di presenza in WWW.
(Tecnicamente: con 'elenco iniziale per saltare' ne intendo uno basato
su rinvii interni alla pagina, non su ripetizioni di URL uguali, per
quanto detto sopra; ma questo si basa comunque un po' su come funzionano
queste cose in Lynx, mentre mi pare che in Netscape la resa pratica dei
rinvii interni HREF -> NAME sia meno utile, forse perche' e` dato per
scontato che con un dito solo [sul mouse] si fa tutto).
--- Artifici per documenti lunghi / Eugenio Gatto. - Torino, 1997-05-07
--> AIB-WEB. Redazione <cid+aib-www@polito.it>
"Tra l'altro e' buona norma avvisare della consistenza del file: meglio
che incappare per sbaglio in queste pagine mentre si consulta il web!"
[EB 970507]
Concordo, ovviamente; un po' se n'era accennato in passato, ma il
discorso (forse per poca chiarezza mia) era scivolato sulle opinioni su
quale fosse la dimensione massima, invece che quella oltre cui e` bene
avvertire.
Al di la` di certe convenienze tecniche (che varieranno rapidamente con
lo stato della rete) a spezzare in piu` parti, la dimensione massima e`
determinata dal documento in se', e non ha senso fissarla: alla peggio
si puo` decidere che nelle condizioni attuali un certo documento non e`
adatto alla distribuzione in rete (WWW, FTP o MAIL non fanno grande
differenza: quel che e` troppo e` troppo).
Per le mie poche produzioni (in AIBCUR.HTM, ad esempio) ho preso come
regola, molto prudenziale, di dichiarare le dimensioni dai 10 k in su`:
se fosse usata come regola generale, i naviganti nel nostro WWW
saprebbero che un rinvio senza dichiarazione non fa correre il rischio
di arenarsi in lunghe attese, e potrebbero rilassare il dito (che troppo
spesso, in giro per la rete, bisogna tener pronto ad interrompere il
prelievo).
Dato che la cosa importa soprattutto su pagine "di smistamento" (con
molti rinvii a documenti che cambiano frequentemente), ho chiesto di
attivare un artificio (SSI, server side includes, o SPML, server-parsed
html documents). Inutile entrare in dettagli: una piccola prova e` in
AIB/W/XSPML.HTM3 (tipo di file speciale, per vederlo "al naturale"
dovete prendere il suo gemello XSPML.HTM).
Per nulla tecnologicamente, mi pare invece psicologicamente
(bibliotecariamente?) utile, per aiutare a non "incappare per sbaglio",
far sistematicamente precedere documenti lunghi da uno ragionevolmente
breve, ma gia` informativo in se' (scheda? riassunto? incipit?). Se
ne puo` considerare un esempio l'indice SEZIONI/MSG0.HTM (rispetto ai
grossi MSG1 e MSG2); ma ovviamente non intendono esser altro i vari
CATALOGO associati ad AIB-CUR.
Certamente, il comune senso di "ragionevolmente breve" e
"tollerabilmente lungo" sono destinati a variare di molto. Ma credo che,
pur pronti a cambiare, sia utile fissare una misura (elastica, non c'e`
gusto ad essere iper-precisi su una cosa come questa) che faciliti i
nostri utenti ad imparare cosa aspettarsi.
--- Ramo sperimentale GRIS / Eugenio Gatto. - Torino, 1997-06-23
--> AIB-WEB. Redazione <cid+aib-www@polito.it>
A scanso di equivoci, ho "protetto" il ramo GRIS, che avevo creato
venerdi` sera lasciandolo appositamente visibile come esempio per la
riunione del 21. La protezione, come potete ben immaginare, e`
costituita dall'esistenza nel ramo di un INDEX.HTML, che viene fornito
all'utente (invece dell'elenco dei contenuti del ramo) qualora richieda
<http://www.aib.it/aib/gris/>.
Si tratta di semplice "protezione per ignoranza": per non esagerare in
semplicioneria, il punto d'accesso per chi di noi voglia guardarci NON
e` l'ordinario GRIS.HTM, ma il piu` criptico
<http://www.aib.it/aib/gris/d9611i.htm>. Naturalmente con FTP potete
vedere invece l'intera struttura (e, come gia` accennato brevemente
sabato, DOVETE prelevare con FTP, se volete vedere il contenuto di un
file .HTM3: altrimenti WWW ve lo mostra con tutti i misteri risolti,
cioe` come un ordinario .HTM).
Piu` che parlarne in AIB-WWW, probabilmente mi sara` piu` semplice
mettere le spiegazioni e giustificazioni varie in una "nota tecnica"
direttamente in quel ramo, in modo da riutilizzarla semplicemente
qualora si abbia la possibilita` di fare un uso pubblico di quel
materiale. Eventualmente passero` invece in AIB-WWW il breve scambio tra
me e il GRIS (tramite VB) che ha preceduto l'esperimento.
Per i WWW non è mai inverno, ci siano sempre anche tutte le foglie = (ISKO Italia. Documenti. La bottega del sapere) — <https://www.iskoi.org/doc/gatto/ridi.htm> : 2025.04.22 - 2025.04.22 -