Digitization of Archival Data and Metadata in Archaeology: The Case of Ancona ^†

Abstract

During the development of the digital archaeological map of the city of Ancona, in the Marche region, around 12,000 files were digitized relating to the documents associated with the individual archaeological contexts, coming from the administrative archive, the historical archive, the drawing archive, excavation diaries, and all of the scientific documentation associated with them. Given the amount of data and their importance from an information point of view, to prevent them from remaining as “silent” documents, it was envisaged to associate each of them with a metadata system based on the Dublin Core Metadata Initiative (DCMI) standard.

1. Introduction

The Archaeological Map of Ancona is a project born in 2019 thanks to the synergy between the Superintendency of Archaeology, Fine Arts and Landscape of Ancona and the University of Bologna and has seen various work steps that have taken place over the last four years.

The project started with a massive digitization of the paper documents contained in the various archives of the Superintendency divided into historical, administrative, dossier sector, excavation diaries, drawings, and photographs, for a total of about 12,000 files, scanned at 300 dpi resolution (the value recommended by the Guidelines for the digitization of cultural heritage, for web resources, issued by Docs-Italia in collaboration with AgID). To manage the enormous amount of information contained in the documents, we created an ad hoc web application called Punto Zero [1], which, in its administrative part, made it possible to file about 209 archaeological sites, with a data entry system based on the Site Card 3.0 model of the Italian Central Institute of Cataloging and Documentation (ICCD). The public part consists of a website where it is possible to consult all of the contexts inserted into the system, for each of which the description, chronological phases, an image gallery, and the related documents present in the various archives are available, such as the list of drawings present or folders associated with a particular archaeological site. Two different cartographic versions can be consulted on the website, one for tourism, developed with the Javascript Leaflet library connected to the PostgreSQL database of the Punto Zero application, and another, dedicated to professionals and public administrations, developed on Geonode open-source software.

The amount of data present in digital format has given rise to the need to associate a complete information set that accompanies each published resource, a wish that was implemented through the use of the Dublin Core metadata system.

2. The Cultural Heritage’s Metadata

As is known, the rules for describing a digital resource are defined by the W3C Consortium using an abstract model called Resource Description Framework (RDF), which is represented using the XML metalanguage or more commonly with other syntaxes such as Terse RDF Triple Language (Turtle), JavaScript Object Notation for Linked Data (JSON-LD), and N-Triples. The RDF model is based on three types of objects: resources, which can be a web page, an image, or an element that has a URI (universal resource identifier), the properties of a resource, and the assertions, which are made up of a resource, a property, and its value, essentially describing the characteristics of a resource and possibly the relationships with others. In recent years, the Central Institute of the Catalog has focused on the application and potential of the semantic web as a method for overcoming the problems of interoperability between the various institutes involved in the management of cultural heritage in Italy. In the semantic web, the concept of ontology, i.e., a formal representation of reality and knowledge, plays a fundamental role. Ontology is a data structure that allows you to describe entities and their relationships in a given domain of knowledge, in this case, that of cultural heritage. We talk about “ontologies” because there are numerous of them, among which, we can mention CIDOC-CRM, Europeana Data Model (EDM), and Cultural-ON.

The most common type of ontology in the Semantic Web has a classification—defined through RDFS schemas and a set of rules for extracting knowledge. The description of cultural heritage, given the complexity of its nature, requires the use of different ontologies.

For example, CIDOC-CRM does not define any terminology present in the domain of cultural heritage but describes its characteristics and their relationships at a high level of abstraction, classifying its concepts and related properties. This ontology can be used together with the Dublin Core schema which can describe and represent the actual contents of catalog card fields. This scheme has already been used, starting from 2005 with the PICO project [2,3] created by the Scuola Normale Superiore for the MIBAC to develop the portal of Italian culture, i.e., CulturaItalia.it. This portal is one of the national metadata repositories relating to cultural heritage, which flows into the wider Europeana project. The PICO metadata schema is based on a total of 94 elements aligned with the Dublin Core [4], which was deemed the most suitable metadata schema to represent elements as diverse as those that are part of the domain of cultural heritage.

The ontologies mentioned above could not express the complexity of the ICCD cards, and this is why the ArCo project was born, which today presents itself as a network of ontologies released by the institute itself in collaboration with the ISTC of the CNR [5,6,7,8,9,10].

Since 2017, the ICCD has been actively collaborating in the ArCo project, the Knowledge Graph of the Italian cultural heritage which includes a network of seven dictionaries describing the domain of Cultural Heritage and the data extracted from the General Catalog of Cultural Heritage of the ICCD-MiBAC and transformed into the RDF. ArCo’s goal is to maintain the analytical nature of the catalog cards elaborated by the ICCD and at the same time enrich them with information that restores the complexity of the cultural heritage.

The digitization of cultural heritage and its description as digital objects is one of the main assets of the National Plan for the Digitization of Cultural Heritage (PND), which was drawn up by the Central Institute for the Digitization of Cultural Heritage—Digital Library of the Ministry of Culture. The PND was born from the comparison with the many Italian cultural institutes that for various reasons own or manage cultural assets and dictate the guidelines with which the MIC arranges their digitization activity in the period between 2022 and 2026. The National Digitization Plan of Cultural Heritage will use METS, or the Metadata Encoding and Transmission Standard, as a standard, a metadata scheme widely used at an international level which will also be used at a national level for the description and management of digital objects in digitization projects.

The METS standard constitutes the interchange language between the related systems and the Central Institute for the Digitization of Cultural Heritage—Digital Library, allowing for the encoding of descriptive, administrative, and structural metadata concerning digital resources, in connection with other external schemes. A METS document consists of seven main sections:

• Header (metsHdr): This segment contains metadata that delineates the METS document itself, encompassing details like the author, publisher, and related information.
• Description (dmdSec): Within this section, the descriptive metadata of the asset resides, linked to specific metadata tailored to each domain.
• Administrative Data (amdSec): This part encompasses both data concerning the created files, including intellectual property rights, and metadata pertaining to the source object from which the digital object originates. Additionally, it contains information about file origins and relationships between digital objects.
• File (fileSec): Here, electronic versions of the digital object are housed.
• Structural Map (structMap): Describing the hierarchical structure, be it physical or logical, of the digital object, this segment establishes connections between files and their associated metadata.
• Structural Links (structLink): This component facilitates the management of hyperlinks among nodes outlined in the structural map’s hierarchy.
• Behavior: This facet can be utilized to link behaviors, such as visualization methods, with the content contained within the METS object.

The METS can connect to other external schemes (for example, Dublin Core and DDI—Data Documentation Initiative), EAC-CPF (Encoded Archival Context—Corporate Bodies, Persons, and Families), EAD (Encoded Archival Description finding aid), FGDC [11] (Federal Geographic Data Committee metadata), and ISO 19115:2003 NAP [12] that define, for example, a vocabulary with an adequate XML syntax, such as the Dublin Core or the ISO 19115 scheme [13], which are the two standards that we have decided to use for the description of the digital resources of the Archaeological Map of Ancona.

3. The Metadata System of the Archaeological Map of Ancona

Currently, as far as the archaeological field is concerned, the ICCD files are those relating to the archaeological complexes (CA), archaeological monuments (MA), archaeological finds (RA), stratigraphic sages (SAS), archaeological sites (SI), and table of materials (TMA), while the authority files, which are responsible for acquiring information that is closely related to the cultural heritage, are those relating to archaeological excavations (DSC) and reconnaissance (RCG). Other files that may be useful for the filing of archaeological cultural heritage are those relating to the US-USM, the photographic funds (FF), and the drawings (D), even if connected to historical and artistic heritage more than specifically to archaeological heritage, and the MOPR-MOSI file related to preventive archaeology.

In accordance with the public purpose of the Superintendencies’s datasets, the archival files of the archaeological sites of Ancona have been structured on the basis of the Archaeological Site 3.0 model of the Italian Central Institute of Cataloging and Documentation (ICCD) to allow for dialogue and the transfer of immediate data in XML format to the SigecWeb platform.

In particular, for the automatic creation of this file, the XSD file was adopted, which can be downloaded directly from the Github page (https://github.com/ICCD-MiBACT/Standard-catalografici (accessed on 20 February 2024)) of the Central Institute of the Catalogue. The XSD file provided by the ICCD in turn describes the content of the XML file by defining constraints, which elements and attributes can appear, their relation to each other, and what type of data it can contain.

In addition to transferring data in XML format to the general catalog system, the Ancona Archaeological Map project also digitized all paper documents that do not specifically fall within an ICCD file or authority file, such as diaries of excavation or the administrative dossiers, especially historical ones, which trace the life of the cultural heritage, from its discovery to its conservation. For this reason, it was decided to associate an essential information scheme to each document stored in the database by applying the RDF Dublin Core metadata scheme.

The Dublin Core is precisely a metadata schema consisting of a core of essential elements for the purpose of describing any digital material, created in Ohio in March 1995 during a conference on this topic. For this scheme, there are fifteen essential information fields: title; creator; subject; description; publishers; contributor; date; type; format; identifier (URI, URL, DOI, ISBN, etc.); source; language; relationship; coverage; and rights management. In the same SigecWeb, there is a module that manages requests according to the Oai-pmh protocol (Open Archives Initiative—Protocol Metadata Harvesting), developed by the Open Archives Initiative and used for the recovery (or harvesting) of the metadata of the records belonging to an archive, which must normally be in XML in Dublin Core format. The OAI-PMH is based on the HTTP protocol for the transport of data that must be represented in XML.

In practice, a description of a digital resource in the Dublin Core is an XLM document that contains a set of tags, which are part of that namespace (defined in the document with the prefix dc:), through which the properties of the object are made known. For example, if we analyze a metadata file that accompanies a digital archaeological resource included in the Ancona Archaeological Map system, we will find these codes:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<csw:GetRecordByIdResponse

xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"

xmlns:dc="http://purl.org/dc/elements/1.1/"

xmlns:dct="http://purl.org/dc/terms/"

• xmlns:gmd="http://www.isotc211.org/2005/gmd"

xmlns:gml="http://www.opengis.net/gml"

xmlns:ows="http://www.opengis.net/ows" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd">

 <csw:Record>

  <dc:identifier>d5e78287-a2dc-4f15-bd42-e7f6c3eb4a3c</dc:identifier>

  <dc:title>ANC138 Tombe ellenistiche via Indipendenza</dc:title>

  <dc:type>dataset</dc:type>

  <dc:subject>Ancona</dc:subject>

  <dc:subject>Epoca ellenistica</dc:subject>

  <dc:subject>Necropoli</dc:subject>

  <dc:subject scheme="http://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_TopicCategoryCode">Beni Culturali</dc:subject>

  <dc:format>vector</dc:format>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">https://cartaarcheologica.it/datasets/geonode:anc138_tombe_ellenistiche_via_indipendenza/dataset_download</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WMS&amp;request=GetMap&amp;layers=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;format=image%2Fjpeg&amp;height=550&amp;width=550&amp;srs=EPSG%3A4326&amp;bbox=13.5170317%2C43.6193038%2C13.5171160%2C43.6193501</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WMS&amp;request=GetMap&amp;layers=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;format=application%2Fpdf&amp;height=550&amp;width=550&amp;srs=EPSG%3A4326&amp;bbox=13.5170317%2C43.6193038%2C13.5171160%2C43.6193501</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WMS&amp;request=GetMap&amp;layers=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;format=image%2Fpng&amp;height=550&amp;width=550&amp;srs=EPSG%3A4326&amp;bbox=13.5170317%2C43.6193038%2C13.5171160%2C43.6193501</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WFS&amp;version=1.0.0&amp;request=GetFeature&amp;typename=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;outputFormat=SHAPE-ZIP&amp;srs=EPSG%3A4326&amp;format_options=charset%3AUTF-8</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WFS&amp;version=1.0.0&amp;request=GetFeature&amp;typename=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;outputFormat=gml2&amp;srs=EPSG%3A4326</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WFS&amp;version=1.0.0&amp;request=GetFeature&amp;typename=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;outputFormat=text%2Fxml%3B+subtype%3Dgml%2F3.1.1&amp;srs=EPSG%3A4326</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WFS&amp;version=1.0.0&amp;request=GetFeature&amp;typename=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;outputFormat=csv&amp;srs=EPSG%3A4326</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WFS&amp;version=1.0.0&amp;request=GetFeature&amp;typename=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;outputFormat=excel&amp;srs=EPSG%3A4326</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WFS&amp;version=1.0.0&amp;request=GetFeature&amp;typename=geonode%3Aanc138_tombe_ellenistiche_via_indipendenza&amp;outputFormat=json&amp;srs=EPSG%3A4326&amp;srsName=EPSG%3A4326</dct:references>

  <dct:references scheme="WWW:LINK-1.0-http--link">https://cartaarcheologica.it/catalogue/#/dataset/147</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">http://cartaarcheologica.it/geoserver/ows?service=WMS&amp;request=GetLegendGraphic&amp;format=image/png&amp;WIDTH=20&amp;HEIGHT=20&amp;LAYER=geonode:anc138_tombe_ellenistiche_via_indipendenza&amp;STYLE=anc138_tombe_ellenistiche_via_indipendenza&amp;version=1.3.0&amp;sld_version=1.1.0&amp;legend_options=fontAntiAliasing:true;fontSize:12;forceLabels:on</dct:references>

  <dct:references scheme="OGC:WMS">http://cartaarcheologica.it/geoserver/ows</dct:references>

  <dct:references scheme="OGC:WFS">http://cartaarcheologica.it/geoserver/ows</dct:references>

  <dct:references scheme="WWW:DOWNLOAD-1.0-http--download">https://cartaarcheologica.it/uploaded/thumbs/dataset-d5e78287-a2dc-4f15-bd42-e7f6c3eb4a3c-thumb-84f9eb5a-5608-4758-b786-5e3ed64f77de.jpg</dct:references>

  <dct:modified>2023-07-31T08:20:00Z</dct:modified>

  <dct:abstract>In via Indipendenza in proprietà ex Morlacchi/ Gioacchini nel corso degli anni sono state trovate alcune tombe riferibili alla necropoli ellenistico-romana di Ancona per un totale complessivo di sei sepolture, di cui tre tombe ad inumazione, due tombe alla cappuccina ed una a cassa in pietra. I primi rinvenimenti risalgono al 1903 quando sono state recuperate due tombe ad inumazione prive di corredo, successivamente nel 1905 venne rinvenuta un’altra tomba ad inumazione di epoca romana, durante i lavori di scavo per un pozzo a circa - 1.50 mt. di profondità. Nel 1947 durante lo scavo di un collettore fognario lungo il lato destro di via Indipendenza vicino al marciapiede all’altezza del civico n°7, è stata rinvenuta una tomba a cassa rettangolare con tetto a spiovente in lastre di tufo, orientata in senso Est/ Ovest ad una profondità di -2.40 metri. La tomba aveva una lunghezza di 2.40 mt., le lastre erano spesse circa 0.88 cm., la larghezza interna era di 0.88 cm., l’altezza del cassone lapideo era di 0.59 cm., l’altezza totale della tomba era di 1.40 mt. La copertura a tetto era composta da lastre di arenaria tagliate nella parte superiore per formare l’angolo acuto del tetto e nella parte inferiore erano scanalate per infilarsi nella lastra verticale che forma le pareti della cassa, così le lastre del tetto non potevano slittare. I lati del tetto erano chiusi con lastre triangolari. Il defunto era appoggiato direttamente a terra; la tomba doveva essere già stata manomessa, probabilmente al momento della costruzione degli edifici, dato che all’interno vi era della terra con materiale moderno. Durante questi lavori furono scoperte altre due tombe alla cappuccina con copertura in tegoloni di laterizi, andate distrutte durante i lavori, orientate diversamente rispetto a quella a cassa lapidea, in senso Nord/ Sud; le tombe non hanno restituito nè corredo nè bolli.</dct:abstract>

<dc:date>2023-07-31T08:20:00Z</dc:date>

<dc:creator>Eleonora Iacopini</dc:creator>

<dc:publisher>Eleonora Iacopini</dc:publisher>

<dc:contributor>Eleonora Iacopini</dc:contributor>

<dc:language>ita</dc:language>

• <dct:alternative>geonode:anc138_tombe_ellenistiche_via_indipendenza</dct:alternative>

 <dct:spatial scheme="http://www.opengis.net/def/crs">EPSG:4326</dct:spatial>

 <ows:BoundingBox crs="urn:x-ogc:def:crs:EPSG:6.11:4326" dimensions="2">

 <ows:LowerCorner>43.61930381369913 13.517031685849151</ows:LowerCorner>

 <ows:UpperCorner>43.619350126328946 13.51711603624021</ows:UpperCorner>

 </ows:BoundingBox>

</csw:Record>

• </csw:GetRecordByIdResponse>

In addition to the Dublin Core schema, other namespaces such as the CSW are used to describe the geographical resource.

The Catalog Service for the Web is a standard of the Open Geospatial Consortium (OGC), which defines an interface for search, navigation, and metadata query services on geographic data and services. Metadata are managed according to ISO 19115 (for spatial applications and geospatial data) [13] and ISO 19119 (for geo-services) standards [14].

Both the Dublin Core and the ISO 19115 standards are the basis of the metadata system of the open-source software Geonode, which has been used for the publication of geographic data and their sharing [13].

The Geonode system allows you to compile the metadata in a guided way when entering the platform or to upload it in ISO, FGDC, and Dublin Core format. This procedure has a “Completeness score system” on the insertion of metadata, as a preliminary data quality operation of the repository, a problem that is becoming increasingly important given the amount of metadata on the net [15].

The Geonode Metadata system contains all of the information related to the resources, making the document more easily retrievable through the search form. The editing metadata has three steps: (1) Basic Metadata, (2) Location and Licenses, (3) Optional Metadata.

In Basic Metadata, the user must give the essential information of the resource like the title; the abstract; the creation/publication/revision dates; the keywords; and the category, which are the standard available with the ISO 19115 metadata schema [13].

On the Location and Licenses page, the following information should be filled in: the language; the regions; the data quality; and the potential restrictions to sharing the document.

The last section is the Optional Metadata page; here, the user can add complementary information like the edition; the purpose; supplemental information that can provide a better understanding of the uploaded document; the maintenance frequency of the document; and the spatial representation type used.

The resources’ metadata are very important for the internal search and harvesting from external systems.

4. Conclusions

The case of Ancona allowed us to experiment with the metadata in an archaeological context, with excellent results in terms of content search and the description of digital resources. Furthermore, the Geonode CMS for the management of geographical data certainly makes the application of metadata according to current standards, such as the Dublin Core and ISO 19115, simpler and more intuitive [13]. The metadata system has certainly prevented the documents from remaining as only silent resources, solving a problem that could arise when someone works with material sources such as those deposited in archives.