# A Cloud-Native Web Application for Assisted Metadata Generation and Retrieval: THESPIAN-NER +
## 2 Origin of the Work: A Cloud-Based Services for Cultural Heritage Science  
As already pointed out, one of the main goals of the 4 CH project is to design, devise, and deploy the CC cloud platform, which will host 4 CH partners' big data services (such as THESPIAN), as well as a cultural heritage knowledge base, with a focus on the most advanced 3D and semantic technologies for monuments and sites, with the goal of building their digital heritage twins.  
The purpose of the THESPIAN suite is to create a web ecosystem for storage, retrieval, and analysis of scientific data coming from physical analysis on cultural heritage, and their metadata, modelled according to the state-of-the-art ontologies and standards, making them interoperable with other services according to the FAIR principles for data [3].  
In this respect, THESPIAN is aimed at offering a suite of cloud-oriented services to store, access, and analyse data in the field of cultural heritage. The data storage is making use of metadata, based on a shared ontology, following the guidelines of the FAIR program established within the context of the European science cloud (EOSC).  
The implementation of such FAIR data principles are materialized in the THESPIAN-Mask [9,10] web service hosted in the CHNet cloud environment. THESPIAN-Mask consists of a web application for assisted metadata generation and a service for persistent storage of scientific data and their metadata. The tool relies on a metadata model based on CRMhs, an extension of the CIDOC-CRM ontology [11], designed by INFN and VAST-LAB PIN for modelling the complex entities typical of heritage science [9]. To ease and standardise the metadata filling procedure, a set of tools based on open-source third-party application program interfaces (APIs) have been used and integrated into the service (see Figure 1 for more details). As an example of API, GEOdata URIs can be filled by a map tool offered by using OpenStreetMap [12], where users may either search for a location by manually inserting the latitude (or the longitude), or by clicking the point on the map, or by querying the GeoNames database to find the wanted location.  
From the technical perspective, THESPIAN-Mask is composed of the following components.  
1. First, we have the front-end, hosting an endpoint furnishing the HTML, CSS, and JavaScript (JS) bundle to be rendered in the client browser.
2. Secondly, we have the back end, offering a set of representational state transfer (REST)-ful APIs contactable via HTTP/2 protocol, for metadata/data upload and retrieval, and offering a set of tools, based on third-party APIs for metadata standardisation.
3. Lastly, we have MongoDB, a No-SQL database for storing the metadata entries.  
A visual representation of the service is available in Figure 2. To ensure file persistency, the back end and DB use persistent (virtual) volumes that are not mutually accessed for security reasons.  
The connections between the front end and back end are mediated by the authentication/authorization reverse proxy service; only authenticated and authorized users can access those services. The DB can only be contacted by the back end and is shielded from  
Figure 1: View of the THESPIAN-Mask page devoted to the insertion of a new metadata record. The buttons for accessing third-party APIs are shown.  
Figure 2: Visual representation of the three services forming the THESPIAN-Mask web application.  
outside. The requests formulated by the front end used the HTTP/2 protocol and are sent to the back end via reverse proxy through an authenticated and authorized connection. The back end contacts the third-party APIs, get the replies and, again through the reverse proxy, replies to the front end.