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