Archivi tag: cattura

Cattura titoli di natura D

Un vecchio problema che si pongono i catalogatori e che nelle regole ufficiali non è affrontato è se si possano catturare titoli di natura D legati ad altre notizie, o se essi siano da considerare intrinsecamente legati all’edizione per la quale sono stati creati.

Qui non  vorrei mettermi io a formulare un insieme di regole sistematiche che non ci sono nei manuali ufficiali (vedremo se la nuova Guida SBN dirà qualcosa), ma solo provare a dare qualche idea che possa essere utile ai catalogatori.

Per la verità, lo stesso problema si potrebbe porre anche per i P e i T, ma in questi casi mi sembra più facile da risolvere generalmente in senso negativo, perché per questi titoli è evidente il legame con la specifica edizione: al massimo si potrebbero riutilizzare per edizioni che fanno parte di una stessa serie (prima, seconda, terza edizione ecc.), ovviamente se si presentano identici in tutte le edizioni (mi pare invece che il problema non si presenti per gli N, che corrispondono a tutti gli effetti ad una manifestazione, quindi non vanno catturati anche se lo stesso articolo appare in diverse pubblicazioni).

I titoli D invece hanno identità un po’ meno definita, quindi mi pare che per loro il problema sia più avvertito.

Poiché questi titoli sono dati descrittivi e non elementi controllati di accesso come i titoli uniformi, è chiaro che anch’essi derivano da una specifica edizione, per cui non si può assumere come criterio generale quello di catturarli.

Si consideri che nell’opac l’effetto della ricerca per un tale titolo è quello di produrre una lista registrazioni (eventualmente anche una sola registrazione) in cui esso appare, quindi tale lista non può essere troppo eterogenea, altrimenti l’utente rischia di non comprenderne il rapporto con la ricerca effettuata, e comunque deve perdere tempo per selezionare il materiale.

In particolare, a mio parere non si devono assolutamente catturare titoli D materialmente uguali a quello che serve ma creati per edizioni di altre opere, perché questo potrebbe far pensare a qualche rapporto tra tali opere od edizioni che in realtà non esiste, e l’uguaglianza dei titoli è del tutto casuale.

Il caso opposto invece è quello di un titolo D uguale per il titolo uniforme di un’opera e per una o più edizioni della stessa opera: in questo caso mi pare che duplicare il D possa portare più confusione che utilità, per cui sarebbe legittimo utilizzare la stessa notizia. Questo vale se tale titolo è riportato sul documento, poiché altrimenti andrà legato al solo titolo uniforme. Viceversa, potrebbe esserci un D da legare al titolo proprio ma non al titolo uniforme, come può avvenire per varianti scarsamente attestate nelle edizioni e giudicate irrilevanti come elementi di accesso all’opera.

Quando un possibile titolo D si ripete uguale in numerose pubblicazioni, bisogna anche valutare se non possa trattarsi di un titolo di collezione, specialmente se è associato ad una numerazione.

A proposito dei titoli D legati ai titoli uniformi, se non c’è dubbio che possano e debbano essere fatti, è anche vero che per ora negli opac il loro trattamento sarà spesso ben lontano dall’ideale: basti pensare che il campo unimarc 500, che contiene il titolo uniforme e non è un record autonomo ma un campo del record base, non prevede il dato per cui non si potrebbe neppure passarlo all’opac in questo modo.

Se qualcuno ha commenti o proposte sull’argomento si faccia avanti.

Titoli o localizzazioni in indice ma non in polo

Sono stati riscontrati alcuni problemi apparentemente eterogenei che in realtà derivano da cause simili:

  1. talvolta, tentanto di inventariare un bid dopo averlo catturato apparentemente senza problemi, appare il messaggio error.documentofisico.null   (oppure Inventario inesistente se si sceglie Non presente nel sistema)
  2. nel CBL un titolo sicuramente posseduto dalla biblioteca e localizzato in indice non viene trovato se è attivo il filtro per biblioteca, mentre viene trovato senza filtro.

L’origine di questi fenomeni è un disallineamento tra polo e indice: nel primo caso il titolo è localizzato in indice per la biblioteca, ma non è presente in polo e quindi non si può inventariare perché l’inventario viene registrato in polo, nel secondo caso il bid è presente in polo (altrimenti non sarebbe neanche nel CBL) ma è privo di inventario e collocazione e quindi non risulta localizzato in nessuna biblioteca.
Questi disallineamenti derivano di solito da qualche errore nei programmi (SbnWeb o l’Indice) o forse da problemi transitori di rete, e non da errori dei catalogatori, soprattutto il primo, perché il secondo potrebbe anche derivare dal fatto che ci si è dimenticati di inventariare e collocare. Che siano stati individuati due casi in due giorni (30 e 31 gennaio 2012) può benissimo essere solo una coincidenza, tuttavia è bene osservare con attenzione per verificare se questi comportamenti non siano in aumento, quindi invito tutti coloro che li riscontrassero a segnalarli.

Verificarne la presenza è molto facile: basta cercare il bid in polo e in indice e si vede subito se ci sono differenze.
Per fortuna è facile anche rimediare:

  • se il titolo non è in polo bisogna eliminare la propria localizzazione dall’indice (Vai a – Gestione bibliografica – Operazioni di servizio su localizzazioni) e poi ricatturare
  • se il titolo è in polo è sufficiente inventariarlo e collocarlo (consiglierei di cliccare anche su Aggiorna dati di possesso in indice)

In realtà il primo tipo di disallineamento (titolo localizzato in indice e non presente in polo) dal punto di vista strettamente tecnico potrebbe avere anche un’altra spiegazione: qualcuno infatti, tramite le operazioni di servizio sulle localizzazioni, potrebbe aver aggiunto la propria localizzazione in indice invece di catturare il titolo.

Normalmente ad un catalogatore non viene neppure in mente di fare questa operazione (che con il vecchio indice non era possibile), ma qualche volta è stata fatta, quindi non si può mai dire …

Sulla modifica della localizzazione in indice e sui casi in cui può essere utile:
https://pololig.wordpress.com/2011/08/08/modificare-dati-solo-in-indice/.

Modificare dati solo in Indice (aggiornato alla versione 16-6-2014)

Il testo che segue è stato aggiornato alle modifiche intervenute con la versione 16-6-2014 di Sbnweb.

Il protocollo SBNMARC ci dà una possibilità che prima non avevamo e che in alcuni casi può essere molto utile, ma va usata con estrema cautela: si tratta della possibilità di correggere in indice dati bibliografici che non sono in polo.

Vediamo innanzitutto quando serve questa possibilità: serve quando non è possibile catturare qualche cosa a causa di errori nei dati che il polo non accetta. Potrebbe trattarsi di squadrature oppure di dati incoerenti che si trovano in indice in seguito ad importazioni di dati esterni, oppure in seguito a difetti nei controlli del software dell’indice (magari non quello di oggi ma quello di molti anni fa, non dimentichiamo che l’indice funziona dalla fine del 1992). Ad esempio, pochi giorni fa è stata trovata una monografia con il tipo di data C che si applica solo a periodici e continuazioni.

Questi problemi sono diventati più frequenti da quando, nel 2015, è stata resa obbligatoria la data anche col tipo di data F, perché ci sono molti bid che ne sono privi e ora non si possono più catturare perché non passano il controllo.

Attraverso il menu Vai a -> Gestione bibliografica -> Modifica localizzazioni per gestione è possibile modificare la localizzazione in indice, assegnando alla propria biblioteca la localizzazione per gestione, che è quella che permette di intervenire sulla catalogazione. La schermata mostra innanzitutto le localizzazioni presenti: per aggiungere la propria bisogna cliccare sull’icona con la matita presente all’estremità destra nella barra blu in testa alla tabella delle localizzazioni. Questa operazione presuppone una specifica abilitazione del bibliotecario che, non essendo prevista prima della versione 16-6-2014, va aggiunta appositamente con la solita procedura di gestione bibliotecari.

A questo punto – sempre compatibilmente con il livello di autorità della notizia – si possono fare le correzioni necessarie: SbnWeb avverte che si sta correggendo una notizia non in polo, ma permette di fare l’operazione.

Fatte le correzioni, bisogna finalmente catturare la notizia. Non si può però fare la cattura normale,  perché l’indice, vedendo la notizia già localizzata, la considererebbe già catturata e quindi non permetterebbe di catturarla di nuovo. Bisogna invece: posizionarsi sulla notizia in indice ed utilizzare (dal Vai a) la funzione Allinea reticolo (questa normalmente è la via più comoda), oppure cancellare la localizzazione per gestione prima inserita e poi fare la cattura normale.

Si tratta evidentemente di una cosa da fare con molta cautela e solo in vista di una successiva cattura: non è nostro compito correggere in indice cose che non abbiamo in polo, quindi attenzione agli eccessi di entusiasmo.

Se gli errori in indice non impediscono la cattura non ha nessun senso seguire questo procedimento, basta catturare e correggere poi quello che serve.

Chi dovesse abusare di questa possibilità senza dubbio prima o poi verrà scoperto e pagherà il fio della sua nequizia.

Da ricordare che è stata introdotta anche la funzionalità Aggiorna dati di possesso che permette analoghe operazioni con la localizzazione per possesso, cosa che però naturalmente non serve per poter intervenire sulla catalogazione. Si intende che si parla di dati di possesso in indice, perché per modificare quelli di polo si interviene sulla gestione documento fisico.

La localizzazione per possesso in indice può essere eliminata solo con la funzionalità Delocalizza documento.

Reticoli rossoblu

Osservando in polo e in indice reticoli come RAV0152172 si può notare che diverse notizie inferiori che appaiono blu in polo sono rosse in indice, cosa che non dovrebbe succedere perché il colore rosso in indice significa che il bid in polo non è presente.

Esaminando questi bid in polo si osserva poi che sono privi di posseduto.

In teoria potrebbe anche trattarsi di un errore del programma, ma siccome non sembra che SbnWeb sia incline ad errori così grossolani, soprattutto in gestione bibliografica, ritengo che la spiegazione più probabile sia che qualcuno ha catturato delle notizie inferiori per errore, ovviamente non le ha né inventariate né collocate, e per rimediare l’errore ha eliminato la localizzazione in indice (si fa da Vai a->Gestione bibliografica->Operazioni di servizio sulle localizzazioni).

Il risultato è corretto dal punto di vista dell’indice, che non segnala la presenza nel polo di queste notizie, ma non dal punto di vista del polo, in cui le notizie rimangono anche se non dovrebbero esserci.

Quando si cattura erroneamente qualcosa dall’indice, una cosa che prima o poi succede a tutti, bisognerebbe invece utilizzare la cancellazione titolo che elimina del tutto il titolo dal polo (se non posseduto da altre biblioteche, altrimenti elimina solo la localizzazione della biblioteca interessata), oltre ad eliminare la localizzazione in indice.

La cancellazione titolo, come tutte le operazioni di gestione bibliografica, è possibile solo dall’analitica di indice, quindi chi ha cancellato la propria localizzazione in indice non può più farla: deve prima reinserire la sua localizzazione per gestione (si fa sempre da Vai a->Gestione bibliografica->Operazioni di servizio sulle localizzazioni) e poi potrà fare la cancellazione.

 

Come funzionano le localizzazioni

Ringrazio Gabriella Contardi dell’ICCU per i preziosi consigli e chiarimenti. Si intende che la responsabilità del testo, compresi gli eventuali errori, è interamente mia.

La logica delle localizzazioni, e di conseguenza delle catture, col protocollo SBNMARC di colloquio con l’indice, cioè quello che usano tutti i software comptabili con l’Indice 2 e quindi anche anche SbnWeb, subisce alcune innovazioni di un certo rilievo: non è che il lavoro quotidiano sia completamente rivoluzionato, ma ci sono conseguenze pratiche che è bene sapere per evitare errori e incertezze immotivate.

Da premettere che SbnWeb non ha più la distinzione tra il database di biblio e quello di polo, che era peculiare di client/server e sconosciuta a tutti gli altri software SBN, quindi abbiamo solo due livelli di base dati, cioè il polo e l’indice.

Conviene anche ricordare che SBNMARC prevede diversi livelli di interazione tra i poli e l’indice (su cui ritorneremo in un altro messaggio), e che noi lavoriamo al massimo livello (catalogazione partecipata), cioè possiamo compiere, con l’indice, tutte le operazioni previste per i poli (creare, catturare, correggere notizie), e nello stesso tempo dobbiamo allinearci all’indice, cioè le modifiche apportate in indice da altri poli a notizie da noi possedute vengono automaticamente riportate sul nostro polo. Con il vecchio protocollo di colloquio con l’indice era l’unica modalità di lavoro, e quella che noi abbiamo sempre usato in client/server, mentre le nuove modalità rendono possibili anche interazioni più deboli.

Le localizzazioni sono ora di due tipi:

  • localizzazione per gestione: significa che la biblioteca gestisce il dato bibliografico, cioè l’ha creato o catturato dall’indice, lo può modificare (compatibilmente con il suo livello di autorità) non solo in polo ma anche in indice, e lo mantiene allineato, ossia se il dato viene modificato in indice da parte di un altro polo, questa modifica viene a sua volta, tramite gli allineamenti, ricevuta da tutti gli altri poli che lo hanno localizzato per gestione; questa localizzazione in SbnWeb è indicata dal colore blu, ed evidentemente corrisponde alla localizzazione prevista nel precedente protocollo di colloquio con l’indice
  • localizzazione per possesso: significa che la biblioteca possiede una copia del documento oggetto della catalogazione che si trova in indice; è prevista solo per i titoli corrispondenti a documenti fisici ed è segnalata dal colore verde se il documento è registrato in Polo, dal colore giallo se è registrato in Indice con la localizzazione per possesso, ma non è presente in Polo. Il primo caso (localizzazione per possesso espressa dal colore verde) può verificarsi sia per documenti condivisi con l’Indice, che per documenti catalogati solo in locale, che siano stati collocati e interrogati sulla base dati di Polo (si tratta infatti per questi ultimi di documenti assenti in Indice). Il secondo caso (localizzazione per possesso espressa dal colore giallo) si verifica solo interrogando in Indice titoli di documenti che siano entrati sulla base dati di Indice tramite la migrazione di altre basi dati (es. con la migrazione della base dati di Musica o con Edit16) e che non siano mai stati catturati dal Polo: attualmente non dovrebbero esserci documenti di questo tipo localizzati nel nostro polo.

Concetto fondamentale: noi catalogando e collocando in linea non possiamo avere localizzazione per possesso senza avere anche la localizzazione per gestione (questo invece è possibile in altri livelli di interazione con l’Indice previsti dal protocollo SBNMARC: con la sola localizzazione per possesso una biblioteca può avere una sua versione locale della catalogazione anche molto diversa da quella dell’indice, non può modificare le catalogazioni in indice e non è obbligata ad allinearsi alle modifiche fatte in indice da altri poli).

In pratica, ecco quello che avviene:

  • quando la prima biblioteca del polo crea o cattura un reticolo lo localizza in indice per gestione per se stessa: ciò significa che a questo punto tutte le biblioteche del polo possono utilizzarlo per ordini, inventariazione, collocazione e anche per la gestione bibliografica, in quanto l’Indice abilita la correzione sulle notizie localizzate sul Polo, senza distinguere per biblioteca; pertanto non esiste più la cattura dal polo perché, a differenza di client/server, non esistono altri livelli di base dati su cui i record debbano essere replicati.
  • la localizzazione per gestione in indice per le altre biblioteche del polo avviene quando la biblioteca inventaria la prima copia;
  • per tutte le biblioteche – sia per la prima che ha catturato/creato la notizia, sia per le successive biblioteche del Polo –  la localizzazione per possesso viene automaticamente aggiunta in Indice all’atto della collocazione;
  • eventuali attributi della localizzazione (consistenza, mutilo, disponibilità in formato digitale, etc.) sono inviati in Indice  con il bottone Aggiorna dati di possesso in indice; a differenza di client/server gli attributi della localizzazione sono registrati non solo in Indice, ma anche in Polo.
  • sulla base dati di Polo è registrata la sola localizzazione per possesso; pertanto l’informazione che si ottiene con Esamina localizzazioni:
    •  se la notizia è stata interrogata in Indice, prospetta le localizzazioni sia per gestione che per possesso (o per entrambi i valori) e tutti gli attributi della localizzazione per possesso che sono stati eventualmente registrati in Indice  (consistenza, mutilo, disponibilità in formato digitale, etc.);
    • se la notizia è stata interrogata in Polo, prospetta la sola localizzazione per possesso e i relativi attributi (consistenza, mutilo, disponibilità in formato digitale, etc.) registrati in Indice e replicati in Polo, per i documenti condivisi, o registrati solo in Polo per i documenti solo locali;
    • per i documenti solo locali l’eventuale inserimento su Polo degli attributi di localizzazione si effettua attualmente selezionando la voce Varia dati di possesso della Biblioteca all’interno del menu del Vai a: => Gestione bibliografica.

Si comprende quindi facilmente che le notizie per le quali non possono esistere collocazioni, come i titoli A, P, o D, non saranno mai verdi.

A margine osserviamo che, per una caratteristica abbastanza sgradevole di SbnWeb, dopo aver collocato un titolo questo non appare verde finché non si rifà la ricerca, anche se la localizzazione per possesso è stata regolarmente registrata.

Poiché non esiste più la cattura da polo, tutte le biblioteche possono lavorare immediatamente su tutto ciò che c’è in polo, anche con conseguenze pericolose: possono infatti collocare e correggere anche ciò che non hanno! Occorre quindi particolare attenzione: ad esempio, se si cerca un BID da inventariare e collocare, lo si digita sbagliato e poi non si controlla bene il titolo, si inventaria tranquillamente un libro altrui; lo stesso vale per la correzione, anche in questo caso è più difficile non accorgersene.

Correggere ciò che non si ha potrebbe essere legittimo in qualche caso particolare, ad esempio per aiutare un collega inesperto in difficoltà, ma farlo in modo arbitrario è molto scorretto e anche fonte di errori, visto che non si può controllare il documento. In ogni caso, è evidente che ci vuole molta cautela e che bisogna limitarsi a correggere gli errori verificabili senza esaminare il documento, come errori formali nella punteggiatura e simili. Se qualcuno dovesse abusare di questa possibilità creando danni e confusione gli verrà tolta l’abilitazione a correggere.

Cattura reticoli a livelli

In SbnWeb c’è una importante novità nella cattura dei reticoli a livelli.

Se si cattura senza fare la selezione delle notizie inferiori, viene catturata solo la notizia base (ovviamente insieme ad eventuali titoli A, B, D e P collegati) ma non le inferiori, a differenza di quanto avveniva in client/server dove la stessa operazione catturava tutto il reticolo.

In questo modo se si cattura trascurando di selezionare le inferiori, cosa che capitava per errore, ma che qualcuno purtroppo faceva per metodo, non vengono localizzate notizie non possedute che si devono poi delocalizzare (a mno di lasciarle localizzate dando così una informazione errata).

La cattura della sola notizia base è da fare in due casi:

  • quando non si possiede nessuna delle inferiori già esistenti, ma se  ne possiedono altre (che verranno create dopo la cattura della notizia base)
  • quando si fa un recupero da cataloghi preesistenti che non hanno la catalogazione a livelli, per cui non si hanno informazioni sulle  inferiori; in questi casi però sarebbe meglio verificare la pubblicazione.

 

BID RLZ

I BID RLZ erano molto famosi qualche anno fa, ma è bene parlarne per chi allora non era nella nostra compagnia.

La sigla RLZ non identifica un polo vero e proprio, ma un polo temporaneo della Regione Lazio, che consisteva in pratica in una importazione in SBN di cataloghi realizzati con Isis.

Questa importazione, realizzata nel 2002, ebbe un risultato molto infelice perché produsse un gran numero di duplicati. Inoltre questi dati dovevano essere di pessima qualità già all’origine, perché spesso erano pieni di errori gravi che verosimilmente non saranno stati prodotti dall’importazione.

Per questo all’epoca fu data dall’ICCU indicazione di non catturare i BID RLZ, cosa che comunque nessun bibliotecario ragionevole avrebbe fatto quando c’era qualche altro BID da catturare.

Ora sono passati molti anni, senza che ci siano state altre indicazioni su come trattare questi BID, e la situazione si presenta nel modo seguente.

Si vedono meno RLZ, perché certamente alcuni duplicati sono stati fusi con altre notizie. Inoltre alcuni di questi BID sono stati corretti, e quindi ora sono notizie perfettamente normali.

La maggior parte degli RLZ che si vedono ancora comunque sono duplicati, e quasi sempre di qualità peggiore degli altri: il criterio generale di tenersi alla larga dagli RLZ quindi vale sempre.

Nello stesso tempo, non bisogna assolutamente creare duplicati solo per non catturare un RLZ: se questo è l’unico BID corrispondente al documento da catalogare bisognerà evidentemente catturarlo e correggerlo se necessario, non certo crearne un altro.

Se invece ci sono diverse alternative in genere il RLZ è l’ultima scelta: se tuttavia si accertasse che è di qualità superiore alle altre catalogazioni, cosa peraltro molto rara, non vedo che obiezioni ci sarebbero a catturare proprio quello.