Il 28/06/2013 11:13, Pierfranco Minsenti ha scritto:
Non capisco però una cosa: chi lavora in Sebina, per fare un esempio, in fase di creazione crea un "blob" unico per area descrizione + note. Ma in fase di invio: viene inviato quel blob? Cioè: in quel caso è il client che si preoccupa di ricodificare il messaggio parserizzando la punteggiatura, sostituendola con tag di campo e sottocampo e quindi inviando all'Indice un messaggio XML granulare con <T200 id1="1"> ecc.? O è l'Indice che quando riceve il blob fa tutte queste operazioni?
Per quello che ne so, nella prima versione dell'indice la descrizione ISBD comprensiva delle note veniva prodotta dai poli e memorizzata nell'Indice in un unico campo di testo (anzi: credo in molti campi di lunghezza fissa accodati, se la struttura era la stessa di Sebina4). Con la creazione del cosiddetto "Indice2" e del protocollo di dialogo denominato SBN/MARC la descrizione e le note vengono "spacchettati" nei singoli campi e sottocampi UNIMARC, scritti nel formato XML proprio del protocollo SBN/MARC, a cura dei signoli gestionali di polo, nel momento in cui inviano/ricevono record dall'Indice. Quindi: sono i singoli software di polo a preoccuparsi di predisporre i dati in questo formato, e di accettarli in questo formato quando li ricevono dall'indice.
La possibilità di creare una corrispondenza tra "BLOB" ISBD e campi/sottocampi UNIMARC ha ovviamente dei limiti, oltre a quelli dovuti ad errori umani di scrittura dei separatori di campo (. - ) e dalla fastidiosa ambiguità (soprattutto nella descrizione dei libri antichi) del carattere ".", specie nella sequenza sospensiva "..." (spesso il catolgatore per ragioni estetiche finisce l'area del titolo con "... - ", ma poiché l'ultimo punto della sequenza dei tre punti viene "mangiato" dall'indicatore di fine campo ". - ", l'UNIMARC poi restituisce un dato che ci fa risultare gli unici al mondo ad usare i DUE PUNTINI di sospensione anziché i canonici TRE. (vabbè: dettagli da antichista, solo Simona Turbanti mi potrà apprezzare in tali quisquiglie...).
Ma i problemi più gravi derivano dal fatto che SBN/MARC, pur ospitando i campi e i sottocampi "spacchettati" in XML/MARC a cura dei gestionali di polo, per motivi di "gratitudine storica" verso i programmi con descrizione "BLOB", ha portato al suo interno e si preoccupa di mantenere il limite della conversione BLOB -> UNIMARC / UNIMARC -> BLOB, il che, almeno per la descrizione bibliografica, porta con sé molti limiti nell'utilizzo di UNIMARC specialmente per il materiale non librario. Esempi:
1) Le note (Unimarc 3XX) devono essere isolate per permettere di isolare a loro volta le aree della descrizione (Unimarc 2XX). Questo porta a introdurre nel "BLOB" una punteggiatura "non standard" (la famosa sequenza "punto-spazio-doppia parentesi tonda"). La maggior parte delle note sono "indifferenziate" (ricadono quasi tutte nella nota generica "300"), e quindi i gestionali che utilizzano le possibilità date dall'UNIMARC di "battezzare" le singole note con un campo specifico che ne precisi il contenuto, non lo possono fare nel dialogo con l'Indice o quando ricevono allineamenti.. Consideriamo che "etichettare" le note non è solo un esercizio di iper-precisione catalografica, ma ha impatti significativi nei sistemi di ricerca, perché il contenuto delle note può avere un peso diverso nella ricerca "per rilevanza" (ad esempio: una nota di contenuto, una nota al cast, una nota sui premi, o una nota alle bibliografie, "pesa" più - dal punto di vista dell'ordinamento per rilevanza - di una nota alla descrizione fisica o di una nota sulla periodicità...
2) Le aree 2XX (che nel BLOB precedono le note) non possono essere più di 4. Infatti il BLOB quando viene "processato" per creare l'XML/MARC fa un semplice conteggio: Caso A: Le aree sono 3: quindi la prima è l'area del titolo (200), la seconda della pubblicazione (210), la terza delladescrizione fisica (215). Coso B: Le aree sono 4: quindi la prima è l'area del titolo (200), la seconda della edizione (205), la terza della pubblicazione (210) la quarta della descrizione fisica (215). Tertium non datur, per il solito motivo che i software non sono dotati di "esprit de finesse" (per fortuna). Il caso B viene ulteriormente raffinato per le tipologie di materiale, quindi se si tratta di un "seriale" la seconda area non sarà della edizione, ma della numerazione (207); e così via in modo da mappare i vari significati della cosiddetta "area 3" di ISBD (numerazione, scala per le carte geografiche, ecc.).
In soldoni ne consegue che nessun gestionale che intenda applicare interamente le regole ISBD accolte dall'UNIMARC può dialogare serenamente con l'INDICE. Solo alcuni esempi: - L'area della collezione (225) non può essere mai compilata (Infatti SBN permette solo il collegamento con una notizia di tipo "collezione"). - Se per un periodico esiste sia un'area dell'edizione che un'area della numerazione, non è possibile metterle entrambe, e così se abbiamo carte geografiche in formato elettronico, e vogliamo inserire sia l'area della "scala" (area 3 per il materiale cartografico) sia l'area delle caratteristiche delle risorse elettroniche (area 3 delle ER), non lo possiamo fare. - Le aree ISBD ripetibili per l'UNIMARC non possono essere ripetute. Questo impedisce, ad esempio, la duplicazione dell'area della descrizione fisica per i materiali complessi (es.: kit multimediali), oppure inibisce l'uso della bella possibilità data da UNIMARC di duplicare l'area adella pubblicazione dei periodici per indicare le singole sequenze editoriali del primo editore, editore intermedio, ultimo editore (costringendo alle fastidiose diciiture "poi..", "poi...", fino alla resa delle armi con la nota "l'editore varia").
Tutto questo perchè? Se penso male mi vien da dire per mantenere in vita il BLOB di Sebina, perché anche SBNweb, a quanto mi consta, ha ormai un'interfaccia che divide le aree ISBD, e quindi potenzialmente potrebbe attivare la duplicazione delle aree in caso di necessità. -
Il punto è: se lo fa già il client, perché allora non è stata adottata per SBN una struttura tutta MARC compliant già in sede di creazione del record, cosa che sarebbe stata anche più trasparente rispetto a come è strutturato il record SBN-MARC? E quindi non si detto ai produttori: dotavi di una struttura MARC?
Penso per motivi economici e per non fare un dispetto agli amici di Datamanagement.
Concludo con un'ovvietà: i cataloghi bibliografici non sono strumenti scientifici, ma strumenti eminentemente pratici che servono alle biblioteche per effettuare i loro servizi al pubblico. Un catalogo è "buono" quando ci permette di fare tanti, tanti buoni servizi.... e su questo vi inviterei, cari amici, ad una bella pensata.
Scusate per lo sproloquio, che mi auguro non del tutto oscuro.
Cari saluti
Paolo Pezzolo