Dublin Core e ISAD(G)
Una evoluzione che esige tempo e risorse specifiche, metodologiche e culturali
Considerazioni metodologiche sulla eventuale e possibile transizione “DC → ISAD(G)”
La scelta recente dell’Archivio di adottare uno standard come il Dublin Core (DC), standard sintetico, da applicare al “non standard” precedente e proprietario dell’ASC per la classificazione della documentazione è stata di ordine pragmatico e funzionale. I motivi sono stati la carenza di personale, il budget limitato, la relativa tipologia di documentazione associata al titolario, la facilità di implementazione sui record già disponibili.
Passare da un “non standard” al DC è stata una conquista. Passare da uno standard “piatto” (un solo livello) come il Dublin Core a uno standard gerarchico e multi-livello come l’ISAD(G) o General International Standard Archival Description, cioè la norma internazionale generale per la descrizione archivistica, elaborata dal Consiglio Internazionale degli Archivi (ICA), sarebbe un obiettivo di eccellenza a lungo termine. Infatti questo investimento comporta una sfida cruciale: il Dublin Core soffre della “perdita di contesto archivistico”. Quando parte della documentazione classificata d’archivio è stata tradotta in Dublin Core, le relazioni gerarchiche (la struttura che lega il Fondo alla Serie, al Fascicolo e al singolo Documento) sono state probabilmente “schiacciate” in schede singole e isolate. Ma non del tutto a motivo delle informazioni sulle scatole archivistiche e sui titoli delle medesime che danno ordine sistematico ai documenti dei diversi fondi composti e organizzati nel passato in modi differenti. Anche la presenza di alcune chiavi relazionali per ora non del tutto utilizzate conferiscono potenzialità nascoste al sistema attivo e pubblico.
Nel fare il percorso per procedere verso un sistema maturo, e ricchissimo come l’ISAD(G) siamo consapevoli che si dovranno affrontare tre nodi principali:
- La ricostruzione della gerarchia: L’ISAD(G) richiede obbligatoriamente di dichiarare il Livello di descrizione (elemento 3.1.4). Nel Dublin Core questa informazione è spesso nascosta in dc:type o, peggio, confusa nel testo di dc:description. Sarà necessario un lavoro umano importante e lento di ri-ordinamento per raggruppare le schede DC sotto i rispettivi “padri” (Fondi o Serie).
- L’esplosione dei campi descrittivi: Il Dublin Core usa pochissimi elementi. Ad esempio, usa dc:description per qualsiasi cosa. Nell’ISAD(G), quel singolo blocco di testo dovrà essere analizzato e “spacchettato” tra la storia del produttore (3.2.2) e l’effettivo contenuto dei documenti (3.3.1).
- Il recupero dell’identità (Il Vincolo Archivistico): I codici identificativi in DC (dc:identifier) sono spesso pensati come stringhe univoche per il web o ID di database. In ISAD(G), il Codice di riferimento (3.1.1) deve rispecchiare la catena gerarchica (es. IT-ASRM-F1-S2-b1-f3). Questa stringa andrà spesso riveduta e nel caso rigenerata da zero.
L’operazione sarebbe comunque estremamente virtuosa: permetterebbe di conferire un’ulteriore dignità scientifica all’archivio e di valorizzare le relazioni storiche tra i documenti, cosa che il Dublin Core non può fare.
Tabella di associazione comparata (Mappatura: Dublin Core → ISAD(G))
Di seguito viene proposta a grandi linee la mappatura per associare i dati dal Dublin Core ai corrispondenti descrittori ISAD(G), evidenziando l’azione metodologica necessaria per ciascun passaggio.
| Elemento sorgente (Dublin Core) | Elemento destinazione (ISAD(G)) | Azione di bonifica / Considerazione archivistica |
|---|---|---|
| dc:identifier | 3.1.1 Codice di riferimento | Critica: L’ID piatto del DC va convertito o integrato in una segnatura gerarchica (es. Codice Nazione-Codice Archivio-Fondo-Serie-Unità). |
| dc:title | 3.1.2 Titolo | Diretta: Il titolo della risorsa DC diventa il titolo dell’unità archivistica. Spesso richiede normalizzazione (es. eliminare titoli troppo generici). |
| dc:date | 3.1.3 Data/e | Diretta: Diventa la cronologia dell’unità. Bisogna prestare attenzione a formattare gli intervalli di anni secondo le regole ISAD (es. 1920 - 1945). |
| dc:type | 3.1.4 Livello di descrizione | Cruciale: qualora nel DC sia stato usato per indicare la tipologia del documento, in ISAD viene mappato per ricostruire l’albero (es. specificare se la scheda è un Fondo, Serie, Fascicolo). |
| dc:format | 3.1.5 Consistenza e supporto | Ibrida: Se in DC indica il formato digitale (es. PDF, TIFF), in ISAD(G) va spostato nell’area digitale o note, mentre il 3.1.5 esige la consistenza fisica (es. “1 busta, 4 registri”). |
| dc:creator | 3.2.1 Soggetto produttore | Diretta: L’autore o ente creatore in DC diventa formalmente il Soggetto Produttore (collegabile in prospettiva allo standard ISAAR-CPF). |
| dc:description | 3.3.1 Ambito e contenuto (e/o 3.2.2 Storia istituzionale) | Complessa: Il testo libero del DC va analizzato. Il regesto o abstract va in Ambito e contenuto (3.3.1); se contiene note storiche su chi ha scritto la carta, quelle vanno scorporate in Storia istituzionale/biografica (3.2.2). |
| dc:rights | 3.4.1 Condizioni di accesso | Diretta: Le note di copyright o privacy del DC si traducono nelle regole di consultabilità e disponibilità della risorsa fisica/digitale. |
| dc:language | 3.4.3 Lingua/Scrittura dei documenti | Diretta: Mappatura immediata della lingua dei testi (es. “it”, “lat”). |
| dc:source o dc:relation | 3.5.2 Esistenza e localizzazione di copie | Ibrida: quando il DC usa questi campi per legare la scheda a faldoni originari o riproduzioni, in ISAD(G) servono a tracciare la presenza di duplicati, digitalizzazioni o microfilm. |
| dc:contributor o dc:publisher | 3.6.1 Note o 3.7.1 Nota dell’archivista | Variabile: Figure secondarie registrate nel DC (es. chi ha digitalizzato o pubblicato sul web) non hanno un campo proprio nella struttura ISAD primaria e occorrerebbe spostarle nelle aree di controllo o nelle note generali. |
Questa pagina e questa tabella in particolare vogliono solo informare gli addetti ai lavori che, nonostante tutto, la classificazione “non standard” realizzata progressivamente, coadiuvata dalle notevoli possibilità di query mirate tramite i motori di ricerca, dall’associazione di campi “vecchio stile” a quelli del DC favorisce un efficace reperimento delle fonti che è di aiuto al ricercatore di oggi. L’archivista di domani potrà migliorare il sistema in base alle esigenze e agli sviluppi che l’Istituzione vorrà e potrà concretamente seguire. Anche l’ausilio dell’AI nei processi di revisione potrà portare benefici e rapidità all’adattamento (MBay, 2026).