A Web GIS-Based Integration of 3D Digital Models with Linked Open Data for Cultural Heritage Exploration

Abstract

In recent years, considerable efforts have been made by cultural heritage institutions across the globe to digitise cultural heritage sites, artifacts, historical maps, etc. for digital preservation and online representation. On the other hand, ample research projects and studies have been published that demonstrate the great capabilities of web-geographic information systems (web-GIS) for the dissemination and online representation of cultural heritage data. However, cultural heritage data and the associated metadata produced by many cultural heritage institutions are heterogeneous. To make this heterogeneous data more interoperable and structured, an ever-growing number of cultural heritage institutions are adopting linked data principles. Although the cultural heritage domain has already started implementing linked open data concepts to the cultural heritage data, there are not many research articles that present an easy-to-implement, free, and open-source-based web-GIS architecture that integrates 3D digital cultural heritage models with cloud computing and linked open data. Furthermore, the integration of web-GIS technologies with 3D web-based visualisation and linked open data may offer new dimensions of interaction and exploration of digital cultural heritage. To demonstrate the high potential of integration of these technologies, this study presents a novel cloud architecture that attempts to enhance digital cultural heritage exploration by integrating 3D digital cultural heritage models with linked open data from DBpedia and GeoNames platforms using web-GIS technologies. More specifically, a digital interactive map, 3D digital cultural heritage models, and linked open data from DBpedia and GeoNames platforms were integrated into a cloud-based web-GIS architecture. Thus, the users of the architecture can easily interact with the digital map, visualise 3D digital cultural heritage models, and explore linked open data from GeoNames and DBpedia platforms, which offer additional information and context related to the selected cultural heritage site as well as external web resources. The architecture was validated by applying it to specific case studies of Australian cultural heritage and seeking expert feedback on the system, its benefits, and scope for improvement in the near future.

1. Introduction

Tangible cultural heritage (e.g., monuments, sites, artifacts, historical maps) is often exposed to a variety of natural disasters such as earthquakes and flooding, as well as human-made hazards such as fires or human negligence. Digital preservation of tangible cultural heritage is, therefore vitally, important to ensure that the shape and texture of the cultural heritage are not lost in case of damage by natural or human-made disasters [1]. Hence, in the last 20 years, considerable efforts have been made by cultural heritage institutions across the globe to digitise cultural heritage sites, artifacts, and historical maps, etc. for digital preservation and online representation [2,3].

On the other hand, ample research projects and studies were published that demonstrate the high potential of web-geographic information systems (web-GIS) for the dissemination and online representation of cultural heritage data [4,5]. This high potential of web-GIS in the dissemination and online representation of cultural heritage data is mainly due to the fact that the data derived from monuments, sites, and artifacts often contain spatiotemporal information such as geolocation on the Earth and time references, two critical data qualities for any web-GIS system. However, cultural heritage data and the associated metadata produced by cultural heritage institutions are heterogeneous in different file formats and languages, typically interconnected in content, and are distributed in different web services across cultural heritage institutions and even countries [6].

To make these heterogeneous data more interoperable, an ever-growing number of cultural heritage institutions are adopting linked data principles [7,8]. Linked data refer to data that are published in a way that is machine understandable; the data have explicit meaning to machines defined by ontologies, and the data are linked to external data sources and can also be linked from external data sources [9]. As an early adopter of various digital technologies and tools for digitisation, management, dissemination, and analysis, the cultural heritage domain has already implemented domain-specific ontologies such as CIDOC-CRM (http://www.cidoc-crm.org/, accessed on 29 July 2021) and many cultural heritage institutions have already successfully adopted linked data publishing principles [10,11,12].

There have also been some relatively large-scale projects that offer a purpose-built platform for publishing cultural heritage data as linked data such as Wisski (http://wiss-ki.eu/, accessed on 29 July 2021), Arches (https://www.archesproject.org/, accessed on 29 July 2021), ResearchSpace (https://www.researchspace.org/, accessed on 29 July 2021), Omeka S (https://omeka.org/, accessed on 29 July 2021), etc. Furthermore, in a previous study, the authors compared and evaluated the features and functionality of the current state-of-the-art resource description framework (RDF) generation tools and interlinking frameworks, provided a comprehensive methodology for generating geospatial linked open data, and demonstrated how the geospatial linked open data could be interlinked with other external RDF data sources such as DBpedia [13]. The abovementioned platforms, including our previous study, essentially deal with publishing data according to linked data principles, as well as an online representation of linked data. Although a cultural heritage domain has already started implementing linked open data concepts for the display of cultural heritage data, there are not many research studies presenting an easy-to-implement, free, and open-source (FOSS)-based web-GIS architecture that integrates 3D digital cultural heritage models with cloud computing and linked open data.

This study presents a novel cloud architecture (https://unesco-chv.curtin.edu.au/mapplatform accessed on 5 October 2021) that attempts to enhance digital cultural heritage exploration by integrating cloud computing concepts, digital interactive map, linked open data from the well-known RDF knowledge base of DBpedia, and the geographical database of GeoNames, along with locally stored 3D digital cultural heritage models and the associated metadata.

Thus, the architecture promotes the re-use of the existing data, which is one of the four principles of FAIR data (https://www.ands.org.au/working-with-data/fairdata, accessed on 29 July 2021) (findable, accessible, interoperable, and reusable). The conceptual design of the architectures is shown in Figure 1. As can be seen from Figure 1, through the web-GIS architecture, the users can interact with the digital map, visualise 3D digital cultural heritage models, and explore linked open data extracted from GeoNames and DBpedia platforms, offering additional information and context related to the selected cultural heritage site or artefact, including information from external web resources.

Regarding the technical aspects of the architecture, first, the architecture extracts the geolocation of cultural heritage places from the DBpedia RDF data (Australian World Heritage Sites and Australia’s National Heritage List), the GeoNames RDF data (any Australian cultural heritage site searched by the user), and the locally stored 3D digital cultural heritage models.

Second, if the cultural heritage places retrieved from DBpedia and the locally stored 3D digital cultural heritage models are overlapped or within 3 m from each other, it clusters them into a single clickable marker on the digital interactive map. If the retrieved cultural heritage places and the locally stored 3D digital cultural heritage models are not overlapped and more than 3 m away from each other, they are displayed separately. This 3-m distancing for clustering was intentionally implemented as the geolocations might contain minor inaccuracies.

Additionally, it is worth mentioning that this 3-m distance is flexible and can easily be increased or decreased. As for the cultural heritage places retrieved from the GeoNames platform, they are placed on top of the other markers. This was also purposely designed in this way to make cultural heritage places retrieved from the GeoNames search result easily noticeable on the interactive map. The architecture utilises web-GIS technologies to offer a digital interactive map to users and a webGL-based 3D visualisation library (three.js) for visualisation of 3D digital cultural heritage models. For storing 3D models, the architecture uses Amazon Elastic Block Store (EBS) storage of the AWS, while metadata about the 3D digital cultural heritage models such as cultural heritage place name, geolocation in the form of latitude and longitude, basic additional text information about the cultural heritage place, and the Uniform Resource Locator (URL) path to the 3D model on the EBS are stored in the NoSQL database of MongoDB.

The architecture was validated by applying it to typical use cases of Australian cultural heritage. Moreover, the study presents some expert suggestions and recommendations that may also be helpful to other cultural heritage researchers who are working on similar research topics related to digital cultural heritage exploration and dissemination.

The architecture presented in this article extends previous research of the authors on the cloud-based platform for visualisation and dissemination of digital 3D cultural heritage models [14]. Thus, the 3D visualisation part in the presented architecture was derived from the previous work of the authors. More specifically, this study extends the previous work of the authors by providing the following features:

• A novel cloud architecture that integrates digital interactive map and linked open data from DBpedia and GeoNames platforms with the locally stored 3D digital cultural heritage models. Thus, the users of the architecture can easily interact with the digital map, visualise 3D digital cultural heritage models, and explore linked open data from GeoNames and DBpedia platforms, which offers additional information related to the selected cultural heritage place, including external web resources. The architecture is facilitated by utilising FOSS frameworks except for cloud hosting. Since the architecture consists of FOSS frameworks, it allows an easy and cost-free replication of the architecture for CH institutions such as museums, galleries, and libraries.
• A completely re-designed digital interactive map that includes updated map controls, clustering of overlapped markers on the map, and visualisation of raster data in the form of a digital elevation model, among others.
• Recommendations and suggestions on the platform, which were collected from cultural heritage researchers. In total, seven cultural heritage researchers provided recommendations and suggestions, which may also be helpful to other cultural heritage researchers working on similar research topics related to digital cultural heritage exploration and dissemination.

2. Related Work

In recent years, there have been a few related projects that aimed to enhance the digital exploration of cultural heritage by utilising linked open data and other different technologies such as natural language processing, 3D visualisation, and Heritage Building Information Modelling (H-BIM), to name just a few. Cultural Heritage Conversational Agent (CulturalERICA) [15] is a great example that aimed to enhance digital exploration of cultural heritage by deploying natural language interaction technologies. It offers a natural language-based interaction with the Europeana semantic web knowledge base. The authors of the CulturalERICA project believe this project assists users in exploring digital cultural heritage content from Europeana.

Europeana (https://www.europeana.eu/en, accessed on 29 July 2021) is a platform created by the European Union that contains digital cultural heritage data from more than 3,000 cultural heritage institutions across Europe. CulturalERICA project achieved a natural language interaction interface by deploying a Dialogflow natural language platform provided by Google, while Europeana REST API was used to retrieve the data from the Europeana platform. A custom node.js web service was implemented which works as a middleware application between the Dialogflow agent and the Europeana platform.

Another related large-scale project is INCEPTION—Inclusive Cultural Heritage in Europe through 3D Semantic Modelling (2015–2019) [16], which was a project funded by the European Union within the Horizon 2020 program. One of the aims of this project was to semantically enrich 3D digital cultural heritage models using H-BIM and semantic web technologies.

Another relatively recent project is 3D-IMP-ACT (https://3dimpact.italy-albania-montenegro.eu/, accessed on 29 July 2021), which implemented an architecture that offers a web-GIS platform. The web-GIS platform integrates 360 panoramic images and 3D models for digital cultural heritage exploration and tourism [17]. According to the authors of the 3D-IMP-ACT, the project creates a “virtual network” of ancient architectures and sites. This project was funded under the program IPA CBC Interreg-Albania-Montenegro. The web-GIS platform in the project employed QGIS Server and PostGIS database at the server-side of the system. QGIS is an open-source framework that offers GIS logic and map rendering, while PostGIS is an open-source plugin for the PostgreSQL database. The front-end rendering of the map was achieved using the Lizmap application (https://www.lizmap.com/, accessed on 29 July 2021), which is a front-end open-source application for the QGIS server.

There were also other projects, such as the study by Candela et al. [18] or Quattrini et al. [19] that demonstrated how linked open data principles, together with other technologies such as H-BIM, could be applied to enhance cultural heritage exploration. However, this work differs from previous works insofar as it provides a novel architecture utilising cloud computing concepts, web-GIS, linked open data from DBpedia and GeoNames platforms, and 3D digital cultural heritage models to enhance cultural heritage exploration, as explained in the previous section.

3. Literature Review

In the following paragraphs, we present background literature relating to DBpedia and GeoNames platforms. DBpedia is one of the preeminent examples of linked open data, while GeoNames is a geographical database that provides geolocation-related information about places. However, at the time this article was written, the GeoNames platform also provided information about places in the linked-open-data-compatible format of RDF. Interested readers who would like to know more about the semantic web, ontologies, and the geospatial semantic web concepts pertinent to the cultural heritage field may refer to the previous work of the authors [20].

3.1. DBpedia

DBpedia is a crowd-sourced community project that extracts structured content from Wikipedia and serves them as linked data. It extracts Wikipedia articles and converts them into a single shared DBpedia ontology complaint format, which has more than 320 classes and 1650 properties. The project provides downloadable DBpedia data also known as DBpedia knowledge bases. It also offers a SPARQL endpoint that can be used to query the DBpedia data using a standardised SPARQL query language.

One of the greatest advantages of DBpedia over Wikipedia is Wikipedia only offers free text-based search against Wikipedia articles, whereas DBpedia offers a SPARQL endpoint that can answer complex queries [21,22]. For instance, using a Wikipedia search, it is very difficult to find all the cultural heritage places in Australia that are located within 200 km from the coast, whereas this could be easily achieved by sending a custom query to the SPARQL endpoint of the DBpedia.

Additionally, a SPARQL query language allows sending queries to multiple SPARQL endpoints within a single query statement, which is also known as a federated query. This allows merging content from different SPARQL endpoints to provide more meaningful and contextual information to users. A basic technical diagram of the DBpedia architecture is shown in Figure 2. As can be seen from Figure 2, DBpedia is deployed on top of the Virtuoso Universal Server which stores RDF data in the RDF Quad Store and offers a SPARQL endpoint alongside HTML browser and RDF browser support.

3.2. GeoNames

GeoNames (https://www.geonames.org/, accessed on 29 May 2021) is a geographical database that covers all counties in the world and contains over 11 million placenames. These placenames can be downloaded and used for free under a creative commons licence. It also offers a Representational State Transfer Application Programming Interface (REST API) which can accept a request over the Internet and respond in different file formats including in the RDF data model. Nevertheless, GeoNames REST API has a daily and hourly free usage limit per application. At the time of writing this article, GeoNames does not support a SPARQL endpoint; however, as mentioned previously, it can return the requested data in the RDF data model. Since GeoNames data sources have been interlinked with the DBpedia, most of the data in GeoNames contain RDF links that point to the relevant DBpedia URI. However, there are some placenames that are available in GeoNames but are missing in DBpedia. In these placenames, there is no RDF link to the DBpedia URI.

4. Materials and Methods

To accomplish the cloud-based integration of linked open data from DBpedia and GeoNames platforms with the locally stored 3D digital cultural heritage models, the architecture shown in Figure 3 was implemented. The next paragraphs elaborate on this architecture in more detail.

4.1. Server-Side Part of the Architecture

As shown in the top left of Figure 3, the architecture deploys the KeystoneJS framework into the Amazon Web Services cloud platform. More specifically, the architecture utilises Amazon Elastic Compute Cloud (EC2) instance which is a web service that provides secure and resizable compute capacity on the AWS cloud. Amazon EC2 runs the Red Hat Enterprise Linux operating system, which was the preferred operating system, as it is the world’s leading enterprise Linux platform. KeystoneJS was selected as a content management system that handles the content management including uploading, editing, and publishing of 3D digital cultural heritage models and the related metadata to the architecture.

KeystoneJS is a completely FOSS database-driven content management system that makes it very easy to implement web applications and application programming interfaces (APIs). KeystoneJS is based on Node.js server-side framework and comes with the default database of MongoDB. MongoDB is one of the most popular cross-platform, document-oriented databases for web applications.

In the architecture, uploaded 3D digital cultural heritage models were stored in the AWS service—namely, Amazon EBS, while the MongoDB database stored metadata and the path to the 3D model sources in the Amazon EBS. The architecture also used a web server called NGINX which is a web server software application that acts as an intermediary server between the KeystoneJS and the clients. In our case, the clients for NGINX are front-end applications. Finally, the architecture had a PM2 process manager, and an Elastic Load Balancing service provided by AWS. The former is an advanced production process manager for Node.js-based web applications. The main aim of the PM2 process manager is to ascertain that the web application runs continuously without downtime. If the web application crashes or experiences downtime, it will restart the web application, whereas the latter aims to automatically distribute incoming application traffic across multiple Amazon EC2 instances, thus allowing the development of more fault-tolerant and highly available web architectures.

4.2. Front-End Application for Users and Administrators

KeystoneJS provides an auto-generated admin user interface that handles the authentication system; the related subdiagram is shown in the “front-end application for administrators” section in Figure 3. This admin interface allows administrators to upload, edit, and publish content, including 3D digital cultural heritage models on the architecture. The front-end application for the users was implemented by utilising several front-end frameworks including a web-GIS and 3D visualisation framework; the related subdiagram is shown in the “front-end application for users” section in Figure 3.

As the front-end offers a web mapping application, an interactive web map was accomplished using the latest version of the web mapping framework of Openlayers 6, while the user interface buttons and other widgets were achieved using Bootstrap and JQuery frameworks. Openlayers 6 was used for web mapping in the architecture, as it is an open-source and mature web mapping library that supports various vector and raster formats including geospatial web mapping standards of Open Geospatial Consortium (OGC) such as web mapping service (WMS), web feature service (WFS), web map tile service (WMTS), etc.

Bootstrap was used for implementing the graphical user interface of the architecture because it is the world’s most popular framework for the front-end development of web applications, which is also known for its responsive and mobile-first concepts. Furthermore, Bootstrap significantly simplifies the development of front-end web applications and offers several ready-to-use templates and components such as navigation, forms, and typography.

Three.js was used to visualise 3D digital cultural heritage models, which offers numerous customisations and additions in addition to the default features. Three.js was chosen because of its non-proprietary licence, integration with all web browsers that support webGL, being relatively well documented, etc. Interested readers may refer to the previous study of the authors, which discusses three.js customisations and additions in more detail [4].

4.3. External Data Providers

As mentioned previously, DBpedia offers a SPARQL endpoint, while GeoNames offers to query their linked open data using REST API, the architecture utilises those query endpoints and retrieves the geolocation of the cultural heritage places from the query result along with some other related metadata; the related subdiagram is shown in the external data providers section in Figure 3. For instance, from the DBpedia SPARQL endpoint, the query retrieves the World Heritage Site located in Australia, as well as cultural heritage sites that are in the Australian National Heritage List.

An example of the SPARQL query that retrieves all World Heritage Sites in Australia is shown in Figure 4. As can be seen from Figure 4, the query requests place, heritage site name, geolocation in the form of longitude and latitude, and a short description of the Australian World Heritage Sites. In the query, a variable—“?place” held a Uniform Resource Identifier (URI) of the cultural heritage site. A URI could be used to retrieve additional information about the cultural heritage site. Thus, in the architecture, users could visit the provided URI to obtain additional information and links related to the cultural heritage site.

A sample of the result that was obtained from the DBpedia SPARQL and is illustrated in Figure 5, while Figure 6 shows a sample result from the GeoNames. Both sample results are returned in an RDF format. GeoNames only returns a name, URI of the cultural heritage place, and the geolocation in the form of longitude and latitude, as it is a geographical database. Furthermore, for the GeoNames REST API, the query was restricted to Australia only, which means it only returned places that are geographically located in Australia. This GeoNames search restriction guaranteed that the user would not be forwarded to other regions outside Australia.

4.4. Clustering Overlapped Cultural Heritage Places

The architecture clusters cultural heritage places into a single clickable marker according to the geolocation of cultural heritage places, as shown in Figure 7. Upon the launch of the web application, the architecture sends a request to the local REST API to retrieve the metadata of the locally stored 3D digital cultural heritage models. Simultaneously, it sends the SPARQL query to the DBpedia SPARQL endpoint to retrieve Australian World Heritage Sites and cultural heritage places that are in the Australian National Heritage List. Afterwards, the architecture starts comparing the geolocations of the locally stored 3D cultural heritage models against the geolocations of the DBpedia cultural heritage sites. Since the 3D models are stored on the local server, and the DBpedia is an external data provider, the metadata including geolocations of the locally stored 3D models are retrieved slightly faster than the DBpedia data. However, this relatively delayed response from the DBpedia is not an issue in the architecture, as it can dynamically update the clustering of cultural heritage places.

The architecture clusters cultural heritage places as follows: If cultural heritage sites from DBpedia and the locally stored 3D cultural heritage models are overlapped or within 3 m apart from each other, they are placed under a single marker on the digital interactive map. If the cultural heritage places and the locally stored 3D cultural heritage models are located more than 3 m apart from each other, they are placed into individual markers and shown separately. In the architecture, users can also search for any cultural heritage place located in Australia which is retrieved from the GeoNames platform and placed on top of other markers. This was purposely designed in this way to make cultural heritage places retrieved from GeoNames search result easily noticeable on the interactive map.

5. Results

The front-end interface of the architecture consists of three sections, as shown in Figure 8. The left sidebar provides map controls which allows changing the base map and switching on and off the cultural heritage sites and digital elevation model layers. A map in the central part of the user interface has clickable markers that represent cultural heritage sites from different data sources—namely, DBpedia, local data with 3D models, and the GeoNames platform. A search box can be used to search for any Australian cultural heritage place which is retrieved from the GeoNames platform. The right section of the user interface displays cultural heritage data, which dynamically changes upon the selection of any marker on the map. Finally, the user interface has some other additional controls and map widgets such as an overview map that shows the current extent of the map, a scale bar that shows a drawing scale of the map, an info-box that acknowledges the data sources, and zoom buttons that makes the map content larger or smaller.

As mentioned previously, the right sidebar of the interface changes according to the selected marker on the map. For example, Figure 9 shows that Uluru–Kata Tjuta National Park has been selected on the map. Hence, the marker has changed the colour to orange, and the right sidebar displays the content relating to this particular cultural heritage place. As this marker has clusters three cultural heritage places into a single one, the right sidebar displays content for these three cultural heritage places. The first and the second cultural heritage places are from the same data source (DBpedia) and do not have a 3D cultural heritage model in them, while the third cultural heritage place was retrieved from the locally stored data and includes a 3D model of the place. The first and the second cultural heritage places are duplicates because Uluru–Kata Tjuta National Park is on both the Australian World Heritage List and National Heritage List.

A GeoNames search result for the same cultural heritage place (Uluru–Kata Tjuta National Park) is shown in Figure 10. It can be seen from Figure 10 that a GeoNames marker is placed on top of the other markers. Since GeoNames does not provide any additional content relating to a cultural heritage place, a right sidebar only shows a cultural heritage place name and a link to the corresponding DBpedia URI.

Figure 11 shows the 3D visualisation of the cultural heritage place in the architecture. In the architecture, a 3D model can be zoomed in and out, panned around, and moved across the 3D scene. This 3D visualisation is achieved using the three.js 3D visualisation library. Three.js offers many easy-to-implement customisations, which could be implemented on top of the existing default features. Interested readers may refer to the previous study of the authors, which provides more detailed information on customisation and additions in the three.js framework [4].

As mentioned previously, the architecture provides a DBpedia URI to the cultural heritage place if a Wikipedia page is available for that particular cultural heritage place. DBpedia URI then allows users to explore web resources related to the cultural heritage place. Figure 12 shows the DBpedia URI for the Uluru–Kata Tjuta National Park. As can be seen from Figure 12, there are some external web links that users can visit to obtain some additional information about the cultural heritage place.

To better demonstrate the benefits and usefulness of the architecture, it was employed in a sample use case, which is described in the next paragraphs.

In this use case, it is assumed that a person or a user wants to explore cultural heritage places located in Australia. In such cases, this web-GIS application can easily fulfill this requirement. A user can visit the web application via any modern web browser. Upon the visit of the user, the web-GIS application visualises a digital interactive map with the cultural heritage places shown as a clickable marker. The user can then visualise 3D models available in the web-GIS application and read the provided short information about the cultural heritage places. Furthermore, if the user wants to obtain some more information about the cultural heritage place, they can visit the provided DBpedia page that presents additional information and context relating to the cultural heritage place. For instance, Figure 13 shows a 3D digital model of the previously discussed Uluru–Kata Tjuta National Park. Once the user has seen the 3D model and has read the text information of the cultural heritage place, they can visit the DBpedia page to further explore external web resources related to this cultural heritage place. As this cultural heritage place belongs to the Australian national parks category, they might be interested in opening the link in the DBpedia page that provides a list of all Australian national parks. Since a DBpedia page offers linked pages to other DBpedia pages, the user can continuously explore and gain more contextual information about the cultural heritage place.

If the digital interactive map does not have a cultural heritage place that the user is looking for, they can use a search box that finds Australian cultural heritage places from GeoNames API. The search result is then plotted on the map as a marker, and the DBpedia page is offered to the user.

6. Discussion

This study presented a novel architecture that integrates a digital interactive map and linked open data from DBpedia and GeoNames platforms with the locally stored 3D digital cultural heritage models. Although this integration works well for clustering 3D digital CH models with different CH data sources using geolocation, it might not work for cases in which a more granular clustering is needed. For instance, if the cultural heritage place occupies a large area, and the task is to link DBpedia resources to certain areas of the 3D model of the CH place, it might require linking DBpedia resources to those areas of the 3D model.

The clustering approach presented in this article can handle a broad clustering based on the geolocation; however, it does not offer a more granular linking on the 3D model level. Nevertheless, it could be feasible to use a polygon geometry on the interactive map rather than the point geometry to denote the areas of interest that should be linked to related DBpedia URI. This approach might require a text-based linking using names of the cultural heritage places rather than the geolocation, as the geolocation-based clustering might not provide sufficiently accurate matchings in this case. Once the clustering is achieved, the 3D model should only show the area to which the linking has been made by restricting the view of the 3D scene.

The architecture presented in this study utilises linked open data from DBpedia and GeoNames platforms. As mentioned previously, DBpedia is one of the greatest projects relating to linked open data, which derives the data from Wikipedia. Hence, DBpedia shares many similarities with Wikipedia, including varying content quality. In the past, there were many research articles that analysed the content quality of Wikipedia articles using various methodologies such as natural language processing and deep learning [23], assessment based on the historical edits that employ both deep neural networks and feature engineering [24], etc. [25,26].

As Wikipedia is a community-driven project, it receives content contributions from many people all over the world. Hence, the content quality of the articles in Wikipedia varies from article to article. Thus, the geolocation retrieved from the DBpedia in the architecture is not verified and might include inaccuracies including imprecise geolocation, incorrect description of places, and obsolete links to the related places. Nevertheless, many Wikipedia articles have a quality grading class assigned to them such as FA, FL, A, GA, B, C, Start, Stub, and List.

For instance, FA class is assigned to articles that have passed an in-depth quality examination, whereas GA for good quality articles and Stub for basic articles which may include significant content issues. Arguably, this Wikipedia article quality classification could be employed to improve the cultural heritage content in the platform. For instance, the architecture should only retrieve articles with at least GA—good article—grading and eliminate the ones with lower quality gradings.

On the other hand, GeoNames is a geographical database that has been deployed in many research and commercial projects. The GeoNames platform is generally assumed to contain sufficiently accurate geolocation of places. However, Ahlers [27] conducted research on the quality and accuracy of the GeoNames data and concluded that it may contain data inaccuracies including imprecise geocoordinates, overlapped places, repetitions, and misclassifications of places. Thus, a dynamic search from the GeoNames API in the architecture might also include data inaccuracies including plotting the places in the wrong location.

6.1. Recommendations and Suggestions on the Architecture by Cultural Heritage Researchers

As mentioned previously, the authors contacted cultural heritage researchers who have experience in GIS, the semantic web, and digital cultural heritage management to collect feedback and recommendations on the architecture. In total, seven cultural heritage researchers provided constructive feedback on the architecture. The feedback and recommendation were collected through an online anonymous survey (https://curtin.au1.qualtrics.com/jfe/form/SV_9mfIkNL6e9Nm7FH, accessed on 7 October 2021), as well as an online meeting with cultural heritage researchers who have expertise in GIS, linked open data, and digital cultural heritage management. The following paragraphs present these construct feedback and recommendations.

6.2. Interlinking Words in the Unstructured Text Document to DBpedia Resources

Currently, the architecture clusters overlapped cultural heritage places into a single marker. The source of these overlapped cultural heritage places might be DBpedia or locally stored 3D digital cultural heritage models. In addition to this clustering, the authors were suggested to consider implementing entity-based interlinking of text to DBpedia resources. DBpedia has Spotlight Entity Linking which automatically interlinks unstructured text into relevant DBpedia resources.

For instance, Figure 14 shows a demo of the DBpedia Spotlight which has the unstructured text for Uluru-Kata Tjuta National Park. As can be seen from Figure 14, wherever there is a match between the words in the text and DBpedia resources, DBpedia Spotlight found and interlinked the relevant DBpedia pages to the words. This functionality of the DBpedia Spotlight could be implemented in the architecture, which could potentially interlink unstructured text to DBpedia pages upon the publication of the 3D digital cultural heritage models. Specifically, once 3D models are uploaded to the architecture and the related metadata of the 3D models entered, the architecture should run the DBpedia Spotlight to interlink the text information in the metadata with the relevant DBpedia resources. Afterwards, users of the architecture can view 3D digital cultural heritage models and visit the DBpedia pages interlinked to the words, which could potentially provide more contextualised information about the cultural heritage place.

6.3. Geospatial Search and Filter

Currently, the architecture allows users to search for any cultural heritage place located in Australia. In addition to the text-based search available in the architecture, the authors were suggested developing geospatial search functionalities. Geospatial search based on the buffer is one type of geospatial search, which works by creating a buffer around the point. For instance, a user enters a 10 km buffer and pins a point on the map. The architecture then searches for cultural heritage places located within 10 km around the point and displays the results on the map.

Another geospatial search is finding the cultural heritage places based on the drawn polygon. This search works by asking the user to draw a polygon using a free-hand drawing tool, which enables a user to draw arbitrarily any polygon geometry on the map. Once the polygon geometry is drawn, the architecture should find the cultural heritage places that are geographically within the drawn polygon and display the results. Furthermore, the authors were also suggested including filter options to enable users to filter out the cultural heritage places. For instance, filter by certain types of cultural heritage (e.g., natural, or human-made cultural heritage), filter by year or era to which the cultural heritage places belong, etc.

6.4. DBpedia Links in the Architecture

As discussed in the previous sections, the architecture currently provides links to DBpedia pages, which are retrieved from the GeoNames search result and the DBpedia SPARQL result. In turn, these DBpedia pages include links to external web resources which could be visited to gain more contextualised information about the cultural heritage place. However, the DBpedia pages have a relatively complicated structure, which might not be user friendly to many people. Thus, people might have difficulty finding those external web resources and other related links.

For future development, the authors of this research project were advised to include more web links relating to cultural heritage sites. For instance, most DBpedia pages of cultural heritage places include information such as related external web links, the nearest city to the cultural heritage place, a subject topic of the cultural heritage place (e.g., cultural landscapes in Australia, World Heritage Sites in Australia, national parks managed by the Australia government, etc.). These additional links and information could be retrieved from the DBpedia pages and displayed in the architecture.

7. Conclusions

This study presented a novel architecture that aimed to enhance digital cultural heritage exploration by integrating cloud computing concepts, 3D web-based visualisation, and digital interactive map along with linked open data from the well-known RDF knowledge base of DBpedia and the geographical database of GeoNames. These distinct technologies were brought together to enable users of the architecture to interact with the digital map, visualise locally stored 3D cultural heritage models, and explore linked open data from GeoNames and DBpedia platforms, which offers additional information related to the selected cultural heritage place including external web resources.

All frameworks used in the architecture are FOSS which allows easy and cost-free replication of the architecture for CH institutions such as museums, galleries, and libraries. Furthermore, the study discussed some limitations of the architecture such as data inaccuracies that might be present in the received DBpedia and GeoNames data and the limitations of clustering of overlapped cultural heritage places presented in the article. We also presented expert recommendations and suggestions, which may also be helpful to other cultural heritage researchers and professionals working on similar research topics related to digital cultural heritage exploration and dissemination.