ICCU - Istituto Centrale per il Catalogo Unico delle Biblioteche Italiane e per le Informazioni Bibliografiche Laboratorio per le Informazioni Bibliografiche Schema XML per lo scambio dei dati relativi a biblioteche italiane Revisione a cura di Carla Di Loreto, Ornella Napoli, Andrea Giuliano, Annamaria Mandillo Redazione dello schema a cura di Andrea Giuliano Storia delle revisioni $Author: pflorio $ $Id: biblioteca-1.1.xsd,v 1.3 2006-07-12 08:44:56 giuliano Exp $ $Log: biblioteca-1.1.xsd,v $ Revision 1.3 2006-07-12 08:44:56 giuliano - Modificati o creati alcuni elementi per aderire quanto più possibile al modulo di rilevamento predisposto dalle regioni. In particolare: - reso opzionale il codice iccu, con l'idea di gestire biblioteche senza codice, ma almeno con provincia, come vengono gestite attualmente dall'applicativo - servizi: aggiunta carta-servizi, ore-settimanali, ore-settimanali-pomeridiane, settimane-apertura - patrimonio: aggiunti elementi acquisti-ultimi-quindici-anni, totale-posseduto e totale-posseduto-ragazzi; aggiunto attributo acquisti-ultimo-anno a materialeType - amministrativa: aggiunto elemento minori-quattordici-anni a utenti - Trasformati in nonNegativeInteger tutti gli integer. - Individuata la necessità di concordare liste d'autorità per: - servizi in carta-servizi (quali possono essere i servizi?) - categoria-ammessa in accesso (quali categorie possono accedere?) - Piccole correzioni qua e là. Revision 1.2 2006/03/14 09:25:54 giuliano Aggiunte: - citazione bibliografica per i cataloghi a volume - superficie totale e al pubblico - carta dei servizi (non gestita da ICCU) - quantità dei prestiti dei vari tipi (non gestiti da ICCU) Correzioni: - "fondo-antico" diventa "fondi-antichi", non ripetibile - "fondoAnticoType" ha ora solo un attributo "volumi", che a sua volta è solo una enumerazione di valori che indica i tre possibili intervalli numerici di posseduto (-1000, 1000-5000, e 5000-) Revision 1.1 2006/03/07 13:17:23 giuliano Alla copertura bibliografica di catalogoType sono stati aggiunti due elementi con formato "YYYY", in modo da rappresentare un intervallo di anni. Data della creazione del file XML (generato con un esport). L'elemento "biblioteca" è la radice di un documento di questo tipo. Tale elemento fa parte di un content model "xsd:all", che non obbliga a rispettare l'ordine in cui si presentano gli elementi, a differenza di "xsd:sequence". In tutto il resto dello schema si tende ad usare questo content model, perché meno rigido. Non dovrebbe comportare eccessivo carico per il parser. La maggior parte degli elementi e attributi risultano opzionali e ripetibili, ma questi aspetti saranno oggetto di una revisione futura dell'intero schema alla luce delle possibilità e delle richieste dei diversi partner interessati a scambiare dati nel formato qui descritto. Nei casi più elementari si è ritenuto opportuno fissare l'obbligatorietà e la ripetibilità degli elementi. Questo tipo raggruppa tutte le informazioni di tipo strettamente anagrafico. Data in cui è stata censita la biblioteca (raccolta dati). Formato: AAAA Ultima data in cui è stata modificata la biblioteca (dal gestionale) (x export ICCU). Formato: AAAA-MM-GGTHH:mm:ss Nomi di una biblioteca. È un insieme in cui solo il nome attuale è obbligatorio e non ripetibile, mentre quelli precedenti e quelli alternativi sono opzionali e ripetibili. Codici di una biblioteca. È un elemento che raggruppa diversi codici. Nessuno è ripetibile. I nomi degli elementi dovrebbero essere auto-esplicativi. Si sfruttano qui le possibilità offerte da XML Schema per effettuare una prima validazione dei codici attraverso opportune espressioni regolari. È però importante capire che si tratta di una validazione superficiale: ad esempio, per i codici basati sulle sigle di provincia non viene controllato che la sigla sia corretta, ma solo del tipo "AA". Il codice "iccu" può essere omesso nel caso la biblioteca in esame non sia mai stata censita dall'ICCU. Essa sarà trattata come una nuova biblioteca, come avviene tramite l'applicativo web dell'ICCU. Per questo motivo, è necessario che nell'anagrafica sia specificata la provincia, altrimenti non è possibile assegnare la parte iniziale del codice. Nota r.eschini: tolte tutte le restirction e messo a required il codice iccu Questo tipo descrive un indirizzo di biblioteca. È opzionale come tutti i suoi sotto-elementi, ma forse almeno uno dovrebbe essere reso obbligatorio, altrimenti si potrebbe istanziare un "indirizzo" vuoto. Per il CAP, il comune, la provincia, la regione e lo stato valgono le osservazioni fatte circa i codici di biblioteca: la validazione si ferma alla semplice struttura. Per comuni e provincie si adottano i codici ISTAT. Per lo stato si usa il codice ISO di due lettere, senza distinguere fra maiuscolo e minuscolo. Al momento non viene fatto alcun controllo sulla regione, ma è un elemento che la base dati ricevente dovrebbe essere in grado di ricavare a partire dal solo codice ISTAT del comune, attraverso proprie tabelle di raggruppamento. Varie modalità per contattare la biblioteca e il suo personale. Un contatto di tipo telefonico. Il prefisso è ovviamente quello internazionale. Nelle note, opzionali e ripetibili, si dovrebbe indicare, ad esempio, se si tratta di un centralino, o del numero di una persona etc... L'attributo "tipo" serve a distinguere un telefono da un fax. Numero e prefisso sono obbligatori e non ripetibili, altrimenti non avrebbe senso istanziare questo elemento. Prefisso e numero sono validati in modo molto elementare. I contatti di questo tipo prevedono solo le note e un valore, oltre a un attributo "tipo" che, al momento, consente di specificare solo un indirizzo e-mail, una URL o un telex. Ovviamente la stringa "valore" può contenere qualsiasi cosa, quindi non c'è garanzia che tale stringa sia conforme al tipo specificato. Le note sono opzionali e ripetibili, sebbene la ripetibilità sia discutibile. Il valore è invece obbligatorio e non ripetibile, altrimenti si potrebbe istanziare un elemento vuoto. Una linea di sviluppo potrebbe prevedere dei pattern per la validazione dei valori. Questo comporterebbe però l'uso di sotto-elementi invece che di attributi, altrimenti non sarebbe possibile vincolare i valori con pattern. Dati relativi all'edificio. Sono tutti opzionali, ma potrebbe essere più sensato renderne obbligatorio almeno uno. Data in cui è stata istituita formalmente l'attuale biblioteca. È possibile anche indicare l'anno di prima istituzione o fondazione, nel caso che la biblioteca abbia avuto nel tempo gestioni amministrative diverse. Tipo utilizzato per descrivere il patrimonio di una biblioteca. I sotto-elementi sono tutti ripetibili, e sarebbe opportuno istanziare questo elemento solo se contiene almeno un sotto-elemento non vuoto, ma si è preferito comunque non rendere obbligatori i sotto-elementi. L'elemento "materiale" va ripetuto per ciascun tipo di materiale. Non è prevista una gerarchia fra i materiali, anche se alcune basi dati, fra cui quella ICCU, organizzano i materiali in gerarchie a due o più livelli. Imporre in questo contesto una gerarchia non gestita in modo uniforme dalle base dati appare superfluo e limitante. Anche l'elemento "fondo-speciale" va ripetuto per ciascuna istanza di fondo. Inventario e catalogo topografico sono invece non ripetibili. L'elemento "fondi-antichi", invece, serve solo a conteggiare in modo approssimativo i volumi dei diversi fondi antichi della biblioteca, e quindi non è ripetibile. I tre valori dell'attributo "volumi" sono da intendersi "fino a 1000", "da 1000 a 5000", e "oltre 5000". L'inventario, opzionale, può essere informatizzato o cartaceo (oppure, ovviamente, entrambi). Il catalogo è trattato esattamente come l'inventario. Totale degli acquisti, indipendentemente dal tipo di materiale, effettuati negli ultimi quindici anni. Totale del posseduto, indipendentemente dal tipo di materiale. Si pone il problema della coerenza di questo dato con quello del posseduto per i singoli materiali. Si presume che l'applicativo ricevente non sia tenuto a verificare questa coerenza. Totale del posseduto destinato ai minori di 16 anni, indipendentemente dal tipo di materiale. Anche per questo dato, si presume che l'applicativo ricevente non sia tenuto a verificarne la coerenza con gli altri dati patrimoniali ricevuti. Tipo che raccoglie i diversi cataloghi. Un elemento di questo tipo può dunque contenere i tre tipi di cataloghi di seguito definiti. Tutti i tre sotto-elementi sono opzionali e ripetibili in un ordine qualsiasi. Nel definire i tre sottotipi sono sfruttate dove possibile le somiglianze fra i tre, attraverso la derivazione di un tipo da un altro. Tipo di elemento relativo ai servizi offerti da una biblioteca. Fra questi, gli orari di apertura, il prestito, le informazioni bibliografiche, tipo e condizioni di accesso e diverse altre informazioni. Questo elemento non ripetibile raggruppa tutte le informazioni relative agli orari di accesso alla biblioteca. I sottoelementi, tutti opzionali, sono per lo più ripetibili, eccetto ovviamente l'orario ufficiale. L'elemento serve solo da contenitore. Non è necessario dal punto di vista applicativo, ma agevola la leggibilità dello schema, che in questa parte è piuttosto articolato. Questo elemento contiene almeno un elemento "orario" di tipo "orarioType", da non confondere con l'elemento soprastante. Si veda più avanti la descrizione di questo tipo di elemento. Le variazioni di orario sono espresse da eventuali elementi di questo tipo. Esso è identico ad un orario ufficiale (orarioType), salvo per l'aggiunta di una nota esplicativa (e del periodo di validità, attualmente deprecato e non considerato in import e export). La nota esplicativa può essere di qualsiasi forma. Un periodo di chiusura è semplicemente una nota esplicativa (e del periodo di validità, attualmente deprecato e non considerato in import e export). La nota esplicativa può essere di qualsiasi forma. (dal-al, periodo natalizio,...). Totale delle ore di apertura settimanali. Questo elemento può essere presente insieme all'orario dettagliato (di tipo orarioType), e il suo valore può essere incoerente con l'orario dettagliato, ma gli applicativi che ricevono i dati sono liberi di verificare la congruità dei dati segnalati oppure no. Totale delle ore di apertura pomeridiana settimanali. Ovviamente dovrebbe essere minore di ore-settimanali, ma circa la congruità di questo dato con gli altri, vale quanto già detto per ore-settimanali: non è garantito un controllo da parte degli applicativi riceventi. Numero di settimane di apertura della biblioteca in un anno. Anche per questo dato, gli applicativi riceventi non dovrebbero essere costretti a verificare la coerenza con gli altri dati di questo gruppo. Varie informazioni relative al servizio di prestito. Ci sono diversi sotto-elementi di ovvio significato, tutti opzionali. A parte l'elemento "automatizzato", che serve ad indicare se il prestito avviene con procedure automatizzate oppure no, e che pertanto è di tipo "siNoType", gli altri sono soltanto stringhe, anche se la durata potrebbe essere vincolata con un pattern opportuno, e gli altri due possono contenere valori controllati, che però è meglio lasciare fuori dallo schema. In particolare, il materiale escluso potrebbe essere normalizzato in base alle apposite norme ISO. Qualcosa del genere andrebbe studiato anche per gli utenti ammessi. Questo elemento conteggia il totale dei prestiti di questo tipo effettuati nel periodo di osservazione. Dev'essere un numero. In questo elemento, pur opzionale, si è ritenuto opportuno rendere obbligatorio almeno il sotto-elemento "tipo", escludendo la paradossale situazione di una biblioteca che offre il servizio, ma non sa di che tipo. L'elemento è ripetibile al più due volte perché la biblioteca può offrire due tipi di prestito interbibliotecario, ed è opportuno che essi siano descritti in elementi separati. Tuttavia non si può escludere che vengano descritti due elementi dello stesso tipo, sebbene un applicativo dovrebbe produrne tipicamente sempre al più due, e di tipi diversi. Ovviamente l'elemento "sistema-ill" è opzionale e ripetibile, in quanto la biblioteca può partecipare a più d'uno. Questo elemento conteggia il totale dei prestiti di questo tipo effettuati nel periodo di osservazione. Dev'essere un numero. Per segnalare la disponibilità del servizio interno si usa l'elemento vuoto omonimo, soluzione discutibile ma funzionante. Essa ha il vantaggio di mettere questo servizio allo stesso livello del "servizio-esterno", com'è logico. Quest'ultimo però è più articolato. Se è specificato il servizio esterno, sarebbe opportuno indicare almeno un "modo" di espletamento del servizio stesso. Come in altri casi, anche un elemento vuoto potrebbe essere accettato, come semplice segnalazione di un servizio disponibile. Starà poi all'applicativo ricevente decidere se ignorare tale informazione, perché troppo vaga, o tenerne comunque conto. Accesso a Internet da postazioni locali. La modalità "limitato" potrebbe essere fonte di equivoci. In ogni caso, la modalità è opzionale e ripetibile. Riguarda le modalità di accesso alla biblioteca, sia in termini logistici (e.g. portatori di handicap), sia in termini amministrativi (chi può accedere ai servizi e a quali condizioni può farlo). La presenza di questo elemento, che può essere vuoto, segnala semplicemente la possibilità di accesso ai portatori di handicap, ma per ora non viene qui attribuito alcun significato particolare al suo eventuale contenuto. Le categorie dipendono molto dalle diverse basi dati, per cui in questo schema non si è ritenuto opportuno elencarne alcuna. Possono essere specificate più categorie, sotto forma di semplici stringhe non controllate. I valori qui utilizzati andrebbero però concordati, stabilendo una lista d'autorità. Condizioni di accesso. Tutti i sotto-elementi sono opzionali, anche se avrebbe poco senso un elemento vuoto. I documenti, a loro volta, possono non essere specializzati. Questo potrebbe indicare la necessità di esibire un generico documento di riconoscimento, non meglio specificato. Le condizioni raggruppate andrebbero intese in AND logico. I documenti nell'apposito elemento sono invece equivalenti, cioè in OR logico. Infine, più elementi "condizioni-accesso", con gli opportuni sottoelementi, sono da considerarsi in OR logico. Ad esempio, il tipico caso "almeno 18 anni e un documento valido" si traduce in opportuni elementi "età" e "documenti", ma senza un elemento "appuntamento". Se in alternativa la biblioteca è accessibile incondizionatamente per appuntamento, va aggiunto un apposito elemento "condizioni-accesso", col solo sotto-elemento "appuntamento". Se la biblioteca partecipa a uno o più sistemi di biblioteche, questi devono essere dichiarati in questo elemento, utilizzando sottoelementi "sistema". È obbligatorio almeno uno di questi sottoelementi. I sottoelementi "sistema" contegono semplicemente il nome di ciascun sistema di biblioteche. Se la biblioteca ha delle sezioni speciali, queste vanno inserite in altrettanti elementi "sezione". Nella maschera di ricerca avanzata dell'anagrafe, alla voce "Sezione speciale", è disponibile l'intero elenco delle sezioni speciali registrate dal sistema. Tipo di elemento recante informazioni di carattere amministrativo. È la parte che più probabilmente richiederà aggiustamenti per soddisfare le esigenze di vari enti. Molti elementi sono auto-esplicativi. Eventuale autonomia di spesa. Dati relativi all'ente da cui la biblioteca dipende. Almeno il nome è obbligatorio. Inoltre, andrebbe discussa l'opportunità di fare riferimento ad una lista controllata di enti, individuati tramite il solo codice fiscale o la partita IVA. Devono esistere certamente simili liste, e le diverse basi dati dovrebbero attenersi ad esse, almeno in parte. La funzione-obiettivo corrisponde al COFOG. Questo elemento opzionale indica se la biblioteca si è dotata di una carta dei servizi o meno, e per quali servizi specifici. Gli eventuali singoli servizi devono essere elencati in altrettanti elementi "servizio", sotto forma di stringhe alfanumeriche. Se l'elemento è vuoto, vuol dire solo che esiste una carta dei servizi, ma mancano altre informazioni. I valori andrebbero standardizzati attraverso un'opportuna lista d'autorità concordata. Questo elemento e i suoi sotto-elementi descrivono sommariamente le strutture di cui la biblioteca dispone. I valori dei sotto-elementi sono ovviamente da intendersi in metri. Trattandosi di decimali, non sono ammessi valori come "30m" o "30 metri". I valori dei sotto-elementi sono ovviamente da intendersi in metri quadrati. Trattandosi di decimali, non sono ammessi valori come "100mq" o "100 metri quadri". Le postazioni si dividono in diversi elementi, tutti opzionali. Se un elemento è presente, deve avere un valore, e questo è forse scomodo se si vuole solo indicare che la biblioteca dispone genericamente di postazioni internet o audio, senza indicare quante. Per consentire la semplice segnalazione si dovrebbe usare un costrutto più complesso. Informazioni relative agli utenti della biblioteca. Informazioni relative al personale impiegato a vario titolo nella biblioteca. Informazioni relative al bilancio della biblioteca. La specializzazione di una biblioteca è semplicemente una CDD più una descrizione libera opzionale. Un tipo di materiale è descritto semplicemente da un nome e da un posseduto (opzionale). Quest'ultimo dev'essere un intero non negativo. A parte alcuni elementi dall'ovvio significato, la "descrizione" corrisponde ad una descrizione libera del fondo speciale, mentre "digitalizzazione" registra in forma libera lo stato dell'eventuale digitalizzazione del fondo. Un elemento di questo tipo ammette solo valori del tipo {S:schede, M:microforme, V:Volumi, O:Online(informatizzato)} I fondi antichi vanno classificati in base al posseduto: fino a 1000, da 1000 a 5000, oltre 5000. Non è quindi possibile specificare esattamente un posseduto. I cataloghi hanno diverse caratteristiche comuni. Vale la pena di definire un tipo che raccoglie queste caratteristiche, per poi derivare da esso, tramite restriction, i diversi tipi di cataloghi. Tutti contengono le quattro forme "schede", "volume", "microfilm" e "digitale", ciascuna con la sua percentuale di copertura (vedi "formaType"), e tutti hanno una copertura temporale. La forma "digitale" ha un tipo particolare, "digitaleType", che aggiunge a "formaType" il solo sott-elemento "supporto". La copertura bibliografica deve essere espressa tramite un anno iniziale (elemento "da-anno") e un anno finale (elemento "ad-anno"). Entrambi devono avere il formato "YYYY", cioè esattamente quattro cifre (non è ammesso alcun altro carattere). Catalogo speciale. Deriva da "catalogoType", con l'aggiunta del "nome" del catalogo e del "materiale". Notare come tale tipo di elemento costituisce la base per il "catalogoSpecialeType". La copertura bibliografica deve essere espressa tramite un anno iniziale (elemento "da-anno") e un anno finale (elemento "ad-anno"). Entrambi devono avere il formato "YYYY", cioè esattamente quattro cifre (non è ammesso alcun altro carattere). Catalogo collettivo. Deriva da "catalogoSpecialeType", con l'aggiunta della "zona", a sua volta specializzata in un "nome" e in un "tipo". Il nome della zona può essere ad esempio "Toscana", "Triveneto", "Centro-Sud", "Castelli Romani"... Il tipo della zona può essere invece "regionale", "comunale" ... La forma di un catalogo ha di solito un solo attributo, la percentuale di copertura, riferita al patrimonio inventariato o supposto, relativo alla forma particolare. Un'eccezione è la forma "digitale", che aggiunge un elemento (o attributo che sia) relativo al tipo di catalogo digitale (CD-ROM, web o altro). La forma "digitale" di un catalogo richiede l'indicazione di un supporto. Per il momento, nel caso on-line non si può indicare la URL. Si noti che comunque questo tipo è derivato da "formaType" e quindi eredita le sue caratteristiche. La forma "volumeType" deriva dalla generica "formaType" con l'aggiunta della citazione bibliografica, specifica di questa forma. La citazione è comunque opzionale. Un elemento di questo tipo serve solo a specificare una forma cartacea e una forma informatizzata di qualcosa, tipicamente un catalogo, ma non solo. Entrambi gli elementi che definisce sono semplici siNoType. Questo tipo descrive sostanzialmente l'orario ufficiale, ma è anche un tipo base da cui derivare le variazioni di orario. Poiché le variazioni sono all'interno dei servizi, questo tipo base deve essere globale. La struttura di questo tipo è molto semplice: un giorno della settimana, un orario iniziale e un'orario finale. Sebbene il questionario ICCU preveda una struttura più articolata, queste informazioni sono sufficienti a descrivere qualsiasi ragionevole situazione, e dovrebbero essere gestibili da qualsiasi base dati. Strutture più articolate possono essere ricondotte a questa, ripetendo opportunamente gli elementi. Per i limiti orari si potrebbe specificare un vincolo più fine, perché quello attuale accetterebbe anche un orario come "35:72". Un elemento di questo tipo ammette solo valori del tipo "si/no" (ma non esattamente questi due...) Un elemento di questo tipo contiene una stringa come valore, e ha un attributo "tipo" che serve ad indicare se tale valore è un anno o un secolo. Questo non esclude un elemento con valore "XVI" e tipo "anno", per cui sarebbe auspicabile un costrutto più coerente.