Approfittando della domanda di Pierfranco, apro un thread dedicato a cui invito chi ne sa qualcosa a partecipare con altre osservazioni. Questo potrebbe essere utile a pubblicare un documento in merito, nella beata attesa che l'ICCU pubblichi un suo intervento.
*Pierfranco: "A me servirebbe anche chiedergli una precisazione: quando Clavis invia in Indice un record che in Clavis è scomposto nei campi MARC, l'insieme di procedure automatiche richieste per la conformità al protocollo SBN-MARC lascia il record come è oppure i contenuti di quelli che sarebbero i tag da 200 a 300 vengono assemblati nel blob unico di quella che per SBN è la descrizione in aree ISBD?*"
Non credo di essere il più esperto riguardo SBN, però ho accesso a Paolo Pezzolo, che credo sia quello che conosce meglio le difformità tra SBN e UNIMARC.
Ad ogni modo, questo è il record come lo codifichiamo in XML in Clavis:
<d200 i1="1" i2=" "> <sa>*Russi, caffé e avanguardie</sa> <se> aspetti della Parigi musicale all'epoca delle Histoires naturelles di Ravel</se> <sf> Liana Püschel</sf> </d200> <d210 i1=" " i2=" "> <sa>Milano</sa> <sc>Edizioni Amici della Scala</sc> <sc>Feltrinelli</sc> <sd>©2013</sd> </d210> <d215 i1=" " i2=" "> <sa>V, 221 p.</sa> <sc>ill.</sc> <sd>21 cm.</sd> </d215> <d300 i1=" " i2=" "> <sa>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</sa> </d300>
Lo stesso record SBN-MARC come lo trovi in Indice
<T200 id1="1"> <a_200>*Russi, caffé e avanguardie</a_200> <e_200> aspetti della Parigi musicale all'epoca delle Histoires naturelles di Ravel</e_200> <f_200> Liana Püschel</f_200> </T200> <T210> <ac_210> <a_210>Milano</a_210> <c_210>Edizioni Amici della Scala</c_210> <c_210>Feltrinelli</c_210> </ac_210> <d_210>©2013</d_210> </T210> <T215> <a_215>V, 221 p.</a_215> <c_215>ill.</c_215> <d_215>21 cm</d_215> </T215> <T3XX tipoNota="300"> <a_3XX>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</a_3XX> </T3XX>
Il blob unico di cui partli *non dipende da SBN-MARC ma dall'interfaccia del programma usato*, che converte il tracciato ricevuto per renderlo più "chiaro" al catalogatore, variando così il margine di errore umano dovuto a usi sbagliati della punteggiatura ISBD (o permettendo varianti a ISBD per sopperire ai limiti dell'interfaccia).
A proposito di area 300 un problema sono le tipologie di note ammesse da SBN-MARC, che sono un po' meno rispetto a UNIMARC:
Per SBN-MARC sono: 300=nota informativa 323=nota al cast 327=nota di contenuto 330=abstract 336=tipo di risorsa elettronica 337=note tecniche risorsa elettronica FILI=filigrana DATA=note sulla datazione POSS=nota sul posseduto PROV=nota sulla provenienza ORIG=note sull'origine
Per UNIMARC rimando a questa pagina: http://unimarc-it.wikidot.com/#blocco3
Ma magari non servono mica tutte :P
Ciao Giulio
Grazie. L'esempio è chiaro e la sequenza di operazioni. 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?
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?
pierfranco
Il giorno 28 giugno 2013 10:57, Giulio Bonanome gbonanome@gmail.com ha scritto:
Approfittando della domanda di Pierfranco, apro un thread dedicato a cui invito chi ne sa qualcosa a partecipare con altre osservazioni. Questo potrebbe essere utile a pubblicare un documento in merito, nella beata attesa che l'ICCU pubblichi un suo intervento.
*Pierfranco: "A me servirebbe anche chiedergli una precisazione: quando Clavis invia in Indice un record che in Clavis è scomposto nei campi MARC, l'insieme di procedure automatiche richieste per la conformità al protocollo SBN-MARC lascia il record come è oppure i contenuti di quelli che sarebbero i tag da 200 a 300 vengono assemblati nel blob unico di quella che per SBN è la descrizione in aree ISBD?*"
Non credo di essere il più esperto riguardo SBN, però ho accesso a Paolo Pezzolo, che credo sia quello che conosce meglio le difformità tra SBN e UNIMARC.
Ad ogni modo, questo è il record come lo codifichiamo in XML in Clavis:
<d200 i1="1" i2=" "> <sa>*Russi, caffé e avanguardie</sa> <se> aspetti della Parigi musicale all'epoca delle Histoires naturelles di Ravel</se> <sf> Liana Püschel</sf> </d200> <d210 i1=" " i2=" "> <sa>Milano</sa> <sc>Edizioni Amici della Scala</sc> <sc>Feltrinelli</sc> <sd>©2013</sd> </d210> <d215 i1=" " i2=" "> <sa>V, 221 p.</sa> <sc>ill.</sc> <sd>21 cm.</sd> </d215> <d300 i1=" " i2=" "> <sa>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</sa> </d300>
Lo stesso record SBN-MARC come lo trovi in Indice
<T200 id1="1"> <a_200>*Russi, caffé e avanguardie</a_200> <e_200> aspetti della Parigi musicale all'epoca delle Histoiresnaturelles di Ravel</e_200> <f_200> Liana Püschel</f_200> </T200> <T210> <ac_210> <a_210>Milano</a_210> <c_210>Edizioni Amici della Scala</c_210> <c_210>Feltrinelli</c_210> </ac_210> <d_210>©2013</d_210> </T210> <T215> <a_215>V, 221 p.</a_215> <c_215>ill.</c_215> <d_215>21 cm</d_215> </T215> <T3XX tipoNota="300"> <a_3XX>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</a_3XX> </T3XX>
Il blob unico di cui partli *non dipende da SBN-MARC ma dall'interfaccia del programma usato*, che converte il tracciato ricevuto per renderlo più "chiaro" al catalogatore, variando così il margine di errore umano dovuto a usi sbagliati della punteggiatura ISBD (o permettendo varianti a ISBD per sopperire ai limiti dell'interfaccia).
A proposito di area 300 un problema sono le tipologie di note ammesse da SBN-MARC, che sono un po' meno rispetto a UNIMARC:
Per SBN-MARC sono: 300=nota informativa 323=nota al cast 327=nota di contenuto 330=abstract 336=tipo di risorsa elettronica 337=note tecniche risorsa elettronica FILI=filigrana DATA=note sulla datazione POSS=nota sul posseduto PROV=nota sulla provenienza ORIG=note sull'origine
Per UNIMARC rimando a questa pagina: http://unimarc-it.wikidot.com/#blocco3
Ma magari non servono mica tutte :P
Ciao Giulio
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Ottima domanda. Il lavoro di conversione lo deve fare il client. L'Indice accetta solo messaggi strutturati come l'esempio, non si preoccupa di "decodificare" stringhe testuali. * * *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?*
Bella domanda a cui non ho risposta, dovresti chiederlo a chi ha creato il protocollo SBN-MARC. Tutta la documentazione è a firma: Finsiel S.p.A. - Akros Informatica s.r.l. - Data Management http://www.iccu.sbn.it/opencms/opencms/it/main/sbn/evoluz_indice_sbn/pagina_...
Voci ufficiose mi dicono che l'attuale reticolo dell'SBN-MARC rappresenta più o meno pedissequamente la struttura del record nei gestionali che già interloquivano con SBN prima di SBN-MARC. Ma ovviamente non so se questo sia vero.
Ciao Giulio
Il giorno 28 giugno 2013 11:13, Pierfranco Minsenti < pierfranco.minsenti@gmail.com> ha scritto:
Grazie. L'esempio è chiaro e la sequenza di operazioni. 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?
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?
pierfranco
Il giorno 28 giugno 2013 10:57, Giulio Bonanome gbonanome@gmail.com ha scritto:
Approfittando della domanda di Pierfranco, apro un thread dedicato a cui invito chi ne sa qualcosa a partecipare con altre osservazioni. Questo potrebbe essere utile a pubblicare un documento in merito, nella beata attesa che l'ICCU pubblichi un suo intervento.
*Pierfranco: "A me servirebbe anche chiedergli una precisazione: quando Clavis invia in Indice un record che in Clavis è scomposto nei campi MARC, l'insieme di procedure automatiche richieste per la conformità al protocollo SBN-MARC lascia il record come è oppure i contenuti di quelli che sarebbero i tag da 200 a 300 vengono assemblati nel blob unico di quella che per SBN è la descrizione in aree ISBD?*"
Non credo di essere il più esperto riguardo SBN, però ho accesso a Paolo Pezzolo, che credo sia quello che conosce meglio le difformità tra SBN e UNIMARC.
Ad ogni modo, questo è il record come lo codifichiamo in XML in Clavis:
<d200 i1="1" i2=" "> <sa>*Russi, caffé e avanguardie</sa> <se> aspetti della Parigi musicale all'epoca delle Histoires naturelles di Ravel</se> <sf> Liana Püschel</sf> </d200> <d210 i1=" " i2=" "> <sa>Milano</sa> <sc>Edizioni Amici della Scala</sc> <sc>Feltrinelli</sc> <sd>©2013</sd> </d210> <d215 i1=" " i2=" "> <sa>V, 221 p.</sa> <sc>ill.</sc> <sd>21 cm.</sd> </d215> <d300 i1=" " i2=" "> <sa>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</sa> </d300>
Lo stesso record SBN-MARC come lo trovi in Indice
<T200 id1="1"> <a_200>*Russi, caffé e avanguardie</a_200> <e_200> aspetti della Parigi musicale all'epoca delle Histoiresnaturelles di Ravel</e_200> <f_200> Liana Püschel</f_200> </T200> <T210> <ac_210> <a_210>Milano</a_210> <c_210>Edizioni Amici della Scala</c_210> <c_210>Feltrinelli</c_210> </ac_210> <d_210>©2013</d_210> </T210> <T215> <a_215>V, 221 p.</a_215> <c_215>ill.</c_215> <d_215>21 cm</d_215> </T215> <T3XX tipoNota="300"> <a_3XX>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</a_3XX> </T3XX>
Il blob unico di cui partli *non dipende da SBN-MARC ma dall'interfaccia del programma usato*, che converte il tracciato ricevuto per renderlo più "chiaro" al catalogatore, variando così il margine di errore umano dovuto a usi sbagliati della punteggiatura ISBD (o permettendo varianti a ISBD per sopperire ai limiti dell'interfaccia).
A proposito di area 300 un problema sono le tipologie di note ammesse da SBN-MARC, che sono un po' meno rispetto a UNIMARC:
Per SBN-MARC sono: 300=nota informativa 323=nota al cast 327=nota di contenuto 330=abstract 336=tipo di risorsa elettronica 337=note tecniche risorsa elettronica FILI=filigrana DATA=note sulla datazione POSS=nota sul posseduto PROV=nota sulla provenienza ORIG=note sull'origine
Per UNIMARC rimando a questa pagina: http://unimarc-it.wikidot.com/#blocco3
Ma magari non servono mica tutte :P
Ciao Giulio
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Io credo che la progettazione del protocollo SBN-MARC sia stata influenzata anche dall'esigenza di gestire la fase di transizione da SBN1 a SBN2 in cui convivono (forse ancora adesso?) 2 modalità di colloquio con l'Indice: quella usata dai gestionali vecchi che colloquiavano con l'Indice usando il protocollo ultra proprietario SBN e quella usata dai nuovi gestionali capaci di inviare all'Indice messaggi XML conformi al nuovo protocollo SBN-MARC.
Quindi il problema doveva essere: se l'ICCU fa una transizione e non può imporre, come nel caso del passaggio all'Euro, che dalla mezzanotte del giorno X tutti passano a un nuovo protocollo, deve gestire la compresenza.
Ma:
1) perché non poteva "mettersi d'accordo" per partire tutti uguali dalla mezzanotte del giorno X e chi non c'era, era fuori? 2) perché la fase di transizione non poteva comunque prevedere un protocollo di comunicazione basata su UNIMARC XML?
Detto questo, resta il fatto che dal punto di vista semantico non tutto in SBN è realmente traducibile in UNIMARC: se nei casi semplici come SBN-MARC a_200 abbiamo una ovvia corrispondenza con UNIMARC 200$a, non è sempre così. Per es. nel caso di vari legami tra periodici: il significato di certi legami in SBN è diverso da come sono descritti nel manuale UNIMARC.
Quindi: è risolvibile uno scollamento che c'è fin dall'inizio? Forse sì se fai delle bonifiche ben fatte e poi adotti modalità diverse.
pierfranco
Il giorno 28 giugno 2013 11:37, Giulio Bonanome gbonanome@gmail.com ha scritto:
Ottima domanda. Il lavoro di conversione lo deve fare il client. L'Indice accetta solo messaggi strutturati come l'esempio, non si preoccupa di "decodificare" stringhe testuali.
*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?*
Bella domanda a cui non ho risposta, dovresti chiederlo a chi ha creato il protocollo SBN-MARC. Tutta la documentazione è a firma: Finsiel S.p.A. - Akros Informatica s.r.l. - Data Management
http://www.iccu.sbn.it/opencms/opencms/it/main/sbn/evoluz_indice_sbn/pagina_...
Voci ufficiose mi dicono che l'attuale reticolo dell'SBN-MARC rappresenta più o meno pedissequamente la struttura del record nei gestionali che già interloquivano con SBN prima di SBN-MARC. Ma ovviamente non so se questo sia vero.
Ciao Giulio
Il giorno 28 giugno 2013 11:13, Pierfranco Minsenti < pierfranco.minsenti@gmail.com> ha scritto:
Grazie. L'esempio è chiaro e la sequenza di operazioni.
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?
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?
pierfranco
Il giorno 28 giugno 2013 10:57, Giulio Bonanome gbonanome@gmail.com ha scritto:
Approfittando della domanda di Pierfranco, apro un thread dedicato a cui invito chi ne sa qualcosa a partecipare con altre osservazioni. Questo potrebbe essere utile a pubblicare un documento in merito, nella beata attesa che l'ICCU pubblichi un suo intervento.
*Pierfranco: "A me servirebbe anche chiedergli una precisazione: quando Clavis invia in Indice un record che in Clavis è scomposto nei campi MARC, l'insieme di procedure automatiche richieste per la conformità al protocollo SBN-MARC lascia il record come è oppure i contenuti di quelli che sarebbero i tag da 200 a 300 vengono assemblati nel blob unico di quella che per SBN è la descrizione in aree ISBD?*"
Non credo di essere il più esperto riguardo SBN, però ho accesso a Paolo Pezzolo, che credo sia quello che conosce meglio le difformità tra SBN e UNIMARC.
Ad ogni modo, questo è il record come lo codifichiamo in XML in Clavis:
<d200 i1="1" i2=" "> <sa>*Russi, caffé e avanguardie</sa> <se> aspetti della Parigi musicale all'epoca delle Histoires naturelles di Ravel</se> <sf> Liana Püschel</sf> </d200> <d210 i1=" " i2=" "> <sa>Milano</sa> <sc>Edizioni Amici della Scala</sc> <sc>Feltrinelli</sc> <sd>©2013</sd> </d210> <d215 i1=" " i2=" "> <sa>V, 221 p.</sa> <sc>ill.</sc> <sd>21 cm.</sd> </d215> <d300 i1=" " i2=" "> <sa>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</sa> </d300>
Lo stesso record SBN-MARC come lo trovi in Indice
<T200 id1="1"> <a_200>*Russi, caffé e avanguardie</a_200> <e_200> aspetti della Parigi musicale all'epoca delle Histoiresnaturelles di Ravel</e_200> <f_200> Liana Püschel</f_200> </T200> <T210> <ac_210> <a_210>Milano</a_210> <c_210>Edizioni Amici della Scala</c_210> <c_210>Feltrinelli</c_210> </ac_210> <d_210>©2013</d_210> </T210> <T215> <a_215>V, 221 p.</a_215> <c_215>ill.</c_215> <d_215>21 cm</d_215> </T215> <T3XX tipoNota="300"> <a_3XX>Sul front.: Premio per la ricerca in discipline musicologiche - Together for culture - Amici della Scala 2013</a_3XX> </T3XX>
Il blob unico di cui partli *non dipende da SBN-MARC ma dall'interfaccia del programma usato*, che converte il tracciato ricevuto per renderlo più "chiaro" al catalogatore, variando così il margine di errore umano dovuto a usi sbagliati della punteggiatura ISBD (o permettendo varianti a ISBD per sopperire ai limiti dell'interfaccia).
A proposito di area 300 un problema sono le tipologie di note ammesse da SBN-MARC, che sono un po' meno rispetto a UNIMARC:
Per SBN-MARC sono: 300=nota informativa 323=nota al cast 327=nota di contenuto 330=abstract 336=tipo di risorsa elettronica 337=note tecniche risorsa elettronica FILI=filigrana DATA=note sulla datazione POSS=nota sul posseduto PROV=nota sulla provenienza ORIG=note sull'origine
Per UNIMARC rimando a questa pagina: http://unimarc-it.wikidot.com/#blocco3
Ma magari non servono mica tutte :P
Ciao Giulio
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
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
Grazie Paolo per questa superdettagliata spiegazione che a questo punto meriterebbe di essere integrata nel wiki per far capire tante cose.
Per quanto riguarda le interfacce a campi: a me Data Management aveva detto che volendo potrebbe essere attivata una interfaccia di creazione del record a campi in SOL, o forse che lo avevano anche fatto al tempo di Sebina 4 ma poi nessuno la usava. Così come sostengono che la visualizzazione dell'opac SOL con la descrizione bibliografica tutta di seguito e non a campi come qualsiasi opac straniero (e anche quello dell'Indice) è dovuta a specifiche preferenze dei bibliotecari che loro hanno consultato. Impressione mia: hanno chiesto a bibliotecari anzianotti che hanno imparato a fare schede con la macchina da scrivere e quindi preferiscono replicare la cosa anche con il computer.
Rispetto a quello che dici sui cataloghi bibliografici come strumenti per gli utenti: io aggiungerei anche una funzione complementare, almeno per i grandi cataloghi nazionali: potersi rivolgere all'utenza internazionale, che sta sul web o usa i tuoi records su altre interfacce. Insomma: agire sia a livello local, che global. Richiede un'attenzione in più alla standardizzazione. È uscito un articolo in cui ho spiegato quello che sta succedendo negli Stati Uniti nel ripensare la figura professionale di chi gestisce cataloghi e strumenti di ricerca in genere: ci sono le doppie dimensioni del local e global. Si trova a partire da qui: http://aibstudi.aib.it/article/view/8876in mezzo ad altri 4 articoli dedicati alle nuove figure professionali.
Ma grazie anche per un altro motivo: finalmente non sono più il solo a scrivere risposte lunghe dettagliate. Eh, sì, perché certe cose non si possono scrivere nella lunghezza di un tweet. Perlomeno se vogliamo farci capire.
pierfranco
Il giorno 28 giugno 2013 13:06, Paolo Pezzolo paolo@comperio.it ha scritto:
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:
- 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à...
- Le aree 2XX (che nel BLOB precedono le note) non possono essere più di
- 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
-- Paolo Pezzolo Comperio SRL Via Nazionale 154 - 35048 Stanghella (PD) tel. 0425 072294 fax 0425 1662008ppezzolo@comperio.it
Bibliotecari mailing list Invio messaggi in lista: Bibliotecari@wikimedia.it Configurazione utente: http://mailman.wikimedia.it/listinfo/bibliotecari
bibliotecari@liste.wikimedia.it
-
Giulio Bonanome -
Paolo Pezzolo -
Pierfranco Minsenti