Dublin Core and ISAD(G)
An evolution that requires time and specific methodological and cultural resources
Methodological considerations on the potential and possible “DC → ISAD(G)” transition
The Archive’s recent choice to adopt a standard such as Dublin Core (DC), a concise standard, to be applied to the ASC’s previous proprietary “non-standard” for classifying its documentation was pragmatic and functional. The reasons were the shortage of staff, the limited budget, the particular type of documentation associated with the classification scheme, and the ease of implementation on the records already available.
Moving from a “non-standard” to DC was an achievement. Moving from a “flat” (single-level) standard such as Dublin Core to a hierarchical, multi-level standard such as ISAD(G), or General International Standard Archival Description, that is, the general international standard for archival description developed by the International Council on Archives (ICA), would be a long-term goal of excellence. This investment in fact involves a crucial challenge: Dublin Core suffers from a “loss of archival context”. When part of the classified archival documentation was translated into Dublin Core, the hierarchical relationships (the structure linking the Fonds to the Series, the File and the single Item) were probably “flattened” into single, isolated records. But not entirely, thanks to the information on the archival boxes and their titles, which give systematic order to the documents of the various fonds, composed and organised in different ways in the past. The presence of some relational keys, not yet fully used, also gives hidden potential to the active, public system.
On the way towards a mature and very rich system such as ISAD(G), we are aware that three main issues will have to be addressed:
- Rebuilding the hierarchy: ISAD(G) makes it mandatory to declare the Level of description (element 3.1.4). In Dublin Core this information is often hidden in dc:type or, worse, mixed into the text of dc:description. Significant, slow human work of re-ordering will be needed to group the DC records under their respective “parents” (Fonds or Series).
- The expansion of the descriptive fields: Dublin Core uses very few elements. For example, it uses dc:description for everything. In ISAD(G), that single block of text will have to be analysed and “unpacked” between the history of the creator (3.2.2) and the actual content of the documents (3.3.1).
- Recovering identity (the Archival Bond): identification codes in DC (dc:identifier) are often conceived as unique strings for the web or as database IDs. In ISAD(G), the Reference code (3.1.1) must reflect the hierarchical chain (e.g. IT-ASRM-F1-S2-b1-f3). This string will often have to be revised and, if need be, regenerated from scratch.
The operation would nonetheless be extremely worthwhile: it would give the archive further scholarly standing and bring out the historical relationships between documents, something Dublin Core cannot do.
Comparative association table (Mapping: Dublin Core → ISAD(G))
The following broadly outlines the mapping to associate Dublin Core data with the corresponding ISAD(G) descriptors, highlighting the methodological action needed for each step.
| Source element (Dublin Core) | Target element (ISAD(G)) | Clean-up action / Archival consideration |
|---|---|---|
| dc:identifier | 3.1.1 Reference code | Critical: the flat DC ID must be converted into, or supplemented by, a hierarchical reference (e.g. Country code-Archive code-Fonds-Series-Unit). |
| dc:title | 3.1.2 Title | Direct: the title of the DC resource becomes the title of the archival unit. It often needs normalisation (e.g. removing overly generic titles). |
| dc:date | 3.1.3 Date(s) | Direct: it becomes the chronology of the unit. Care is needed to format year ranges according to ISAD rules (e.g. 1920 - 1945). |
| dc:type | 3.1.4 Level of description | Crucial: where DC used it to indicate the document type, in ISAD it is mapped to rebuild the tree (e.g. stating whether the record is a Fonds, Series, File). |
| dc:format | 3.1.5 Extent and medium | Hybrid: if in DC it indicates the digital format (e.g. PDF, TIFF), in ISAD(G) it moves to the digital area or notes, while 3.1.5 requires the physical extent (e.g. “1 folder, 4 registers”). |
| dc:creator | 3.2.1 Name of creator | Direct: the author or creating body in DC formally becomes the Creator (linkable in future to the ISAAR-CPF standard). |
| dc:description | 3.3.1 Scope and content (and/or 3.2.2 Administrative history) | Complex: the DC free text must be analysed. The summary or abstract goes into Scope and content (3.3.1); if it contains historical notes on who wrote the document, these must be moved to Administrative/biographical history (3.2.2). |
| dc:rights | 3.4.1 Conditions governing access | Direct: the DC copyright or privacy notes translate into the rules on consultation and availability of the physical/digital resource. |
| dc:language | 3.4.3 Language/scripts of material | Direct: immediate mapping of the language of the texts (e.g. “it”, “lat”). |
| dc:source or dc:relation | 3.5.2 Existence and location of copies | Hybrid: where DC uses these fields to link the record to original folders or reproductions, in ISAD(G) they serve to track duplicates, digitisations or microfilms. |
| dc:contributor or dc:publisher | 3.6.1 Note or 3.7.1 Archivist’s note | Variable: secondary figures recorded in DC (e.g. who digitised or published on the web) have no field of their own in the primary ISAD structure and would need to be moved to the control areas or the general notes. |
This page, and this table in particular, are only meant to inform professionals that, in spite of everything, the “non-standard” classification built up progressively, supported by the considerable possibilities of targeted queries through search engines and by the association of “old-style” fields with those of DC, enables effective retrieval of sources, which helps today’s researcher. The archivist of tomorrow will be able to improve the system according to the needs and developments that the Institution will wish and be able to pursue in practice. AI assistance in review processes may also bring benefits and speed to the adaptation (MBay, 2026).