LOD4Culture: Easy exploration of cultural heritage linked open data
Abstract
LOD4Culture is a web application that exploits Cultural Heritage Linked Open Data for tourism and education purposes. Since target users are not fluid on Semantic Web technologies, the user interface is designed to hide the intricacies of RDF or SPARQL. An interactive map is provided for exploring world-wide Cultural Heritage sites that can be filtered by type and that uses cluster markers to adapt the view to different zoom levels. LOD4Culture also includes a Cultural Heritage entity browser that builds comprehensive visualizations of sites, artists, and artworks. All data exchanges are facilitated through the use of a generator of REST APIs over Linked Open Data that translates API calls into SPARQL queries across multiple sources, including Wikidata and DBpedia. Since March 2022, more than 1.7K users have employed LOD4Culture. The application has been mentioned many times in social media and has been featured in the DBpedia Newsletter, in the list of Wikidata tools for visualizing data, and in the open data applications list of datos.gob.es.
1.Introduction
Cultural Heritage (CH) is one of the most vibrant application domains of the Semantic Web (SW), as demonstrated by the two recent special issues on CH and SW in the Semantic Web journal [1,3]. Institutions such as museums, libraries, or galleries invest substantial resources in the publication of their collections as Linked Open Data (LOD). Aggregators such as Europeana [19] contribute to consolidate CH digital resources in the LOD cloud. Moreover, cross-domain datasets like Wikidata and DBpedia provide an extensive coverage of the CH domain; in this regard, organizations such as the Smithsonian Institution are adapting their strategies to interlink their archives with Wikidata and other Wikimedia projects to increase their visibility [21].
All these efforts have crystallized in the creation of an emergent CH LOD cloud. Despite the availability of large amounts of CH content as LOD, its exploitation is challenging. On this subject, the primary concern in [11] is the remaining work in democratizing the use of CH LOD. [26] also raises this problem, giving as justification the lack of technical competencies in query languages and difficulties in understanding data models. Access to LOD is not a specific challenge of the CH domain, affecting the whole SW community [7,8,15]. This is especially problematic for web developers who are not familiar with SW technologies such as SPARQL, RDF, and OWL. Instead, this group of users is more used to Representational State Transfer (REST) [13] Application Programming Interfaces (APIs) and the JavaScript Object Notation (JSON) data interchange format [5]. Due to this, there are several proposals of API generators for LOD such as RAMOSE [10], OBA [14], or our previous work CRAFTS [30].
In this paper, we propose LOD4Culture, a novel web application that exploits CH LOD for tourism and arts learning purposes. The application offers an interactive map for exploring world-wide CH sites [4,6], i.e. immovable heritage, typically buildings, monuments, historic places, museums, archaeological sites, etc. LOD4Culture also provides a browser of CH entities of different types (sites, artists, and artworks). Wikidata and DBpedia are employed as LOD sources, using a CRAFTS API to simplify data access. Contributions of this work include (1) the proposal of an interactive application based on CH LOD that can be enjoyed by lay users, and (2) a demonstrator of REST-based access to various LOD sources through a CRAFTS API that is especially meaningful to web developers.
The rest of the paper is organized as follows: Section 2 reviews existing proposals consuming CH LOD. Section 3 provides a technical description of LOD4Culture, including its requirements, its data sources, its architecture, its main functionalities, and its implementation details. Section 4 reports about the impact of LOD4Culture so far. The paper ends with a discussion in Section 5.
2.Related work
The CH community is carrying out a tremendous effort in digitalizing their contents and publishing them as LOD. This is the case of individual institutions, such as Rijksmuseum [12]. To avoid fragmentation of CH datasets, aggregators like Europeana [19] provide single access to myriads of artworks. CH consortiums like American Art Collaborative [22] or Sampo Model and Portal Series [17] have also contributed to the emergent CH LOD. Studies such as [11,26] survey some of the most relevant initiatives in CH data publication. Nonetheless, cross-domain community-based datasets like Wikidata and DBpedia are also a rich source of CH LOD. Indeed, Wikidata aims to establish itself as a central hub for data integration, data enhancement, and data management in the CH domain.11
The availability of CH LOD has fueled the development of websites and portals for browsing and searching CH content, making it more accessible for educational use [25]. It is often the case that CH LOD publishers provide their own websites and portals over their data. One example is the Europeana website22 that includes faceted search over the Europeana Data Model.33 The Sampo series of portals [17] is another remarkable example in the CH field; its foundation is a collaborative publication model for CH LOD, embraced by several Finnish institutions. This model has been followed to publish CH datasets as LOD that can be browsed through portals like WarSampo.44 The American Art Collaborative also offers a prototype browser over their collection,55 while CH content in Wikidata and DBpedia is also available as web pages, e.g. Museo del Prado.66 These websites and portals typically expose dedicated HTML pages about the artworks in their respective collections that are built using the source RDF data. Web links to other related CH entities (artists or artworks) are commonly provided, as well as some kind of text search. Some Sampo portals such as BiographySampo77 provide more innovative visualizations, for example showing people’s lifetime events on a map.
Other initiatives reuse existing CH LOD for proposing new interactive applications. One example is openArtBrowser [16], an artwork browser that uses Wikidata as source. This application does not directly access Wikidata; instead, openArtBrowser employs an offline batch process for extracting artworks from Wikidata, converting them to JSON objects, and uploading the output into a text-based search engine, supporting faceted search over the extracted artwork collection. This workflow simplifies web application design by eliminating the need for interaction with the Wikidata endpoint, resulting in lower latency due to the use of a dedicated text-based datastore. However, this component must be maintained and the transformation process must be frequently updated in order to keep consistency with Wikidata.
In our previous work we have proposed CasualLearn [27], a mobile application for CH education. It exploits a dataset of 10K geolocalized learning tasks that were generated from DBpedia, Wikidata, and the Open Data portal of Castile and León.88 CasualLearn tracks the physical location of learners to offer these tasks. For example, it may ask about the characteristics of the Gothic style when passing by a Gothic Cathedral. The application also includes an interactive mode for browsing tasks in a map view. The main challenge of CasualLearn is the generation of the task dataset from multiple sources; access to CH LOD is relatively straightforward due to the simplicity of the employed data model.
[26] addresses the challenge of CH LOD exploitation following the question answering paradigm through virtual assistants (VAs). Their approach consists of a generator of VAs that can be employed with SPARQL endpoints, enabling users to pose questions in natural language through their smartphones. This solution has been tested in several case studies in the CH domain.
Beyond the aforementioned initiatives, the usage of CH LOD is still scarce [11]. [18] discusses the difficulties in creating CH LOD-based applications, requiring expertise in SW technologies not common among the CH community; moreover, it identifies a lack of tools for dealing with LOD to facilitate its exploitation in particular application cases. In addition, we can identify several factors that contribute to the complexity of accessing CH LOD: intricate ontologies, multiple endpoints, and a lack of control over the triplestores. The surveyed approaches address this complexity by utilizing a single endpoint, which they commonly manage. An alternative is to transform CH LOD into other types of data stores, as in the case of openArtBrowser, but this path entails other problems such as inconsistencies that can hinder some of the benefits of LOD.
All the previous approaches but [26] provide visualizations for accessing CH LOD. They typically expose HTML pages about artworks built over RDF data. Text search is the main mechanism for accessing CH contents. Faceted search and interlinking to other entities are employed in some cases, providing new ways of discovering CH content. Some applications like BiographySampo and CasualLearn employ maps, but this is not so common in this domain. While artworks are not normally geolocalized, CH sites like monuments or museums (typically containing artworks) are – this could be exploited with map visualizations in a new breed of CH LOD-based applications, providing highly contextual information and allowing users to quickly and easily grasp the cultural sites of interest in a specific area. Note that visualizations of geospatial data have their own challenges [29], such as providing suitable representations at different scales or processing large volumes of data in an efficient way.
3.Design of LOD4Culture
The analysis in Section 2 evidenced the existence of a deluge of CH LOD, although applications that exploit them are relatively scarce. This section describes LOD4Culture, a novel application that aims to harness the wealth of CH contents in Wikidata and DBpedia for tourism and arts education in informal learning – a popular trend in the educational domain that refers to learning processes which occur spontaneously, outside a formal educational setting [23]. Wikidata and DBpedia are community-based sources that are especially suitable for such purposes, as they have a global scope, are frequently updated, and offer multilingual content. The key idea of LOD4Culture is to offer an interactive map to display CH sites, allowing users to discover interesting cultural places in a contextual manner, such as in the vicinity of their current location or a chosen area of interest. In addition, users should be able to filter CH sites by specific types, such as palaces. The application will also offer a resource view for browsing detailed information about CH sites and related entities, such as artists and artworks. The target audience of LOD4Culture are lay users, and, therefore, the application will be designed to hide RDF and SPARQL, as well as to be responsive and portable to cater to a wide range of devices, including mobile phones. The following subsections present the requirements, the employed data sources, the architecture of LOD4Culture, and further design and implementation details. Employed prefixes and namespaces are listed in Table 1.
Table 1
Prefixes and namespaces employed in this paper
3.1.Requirements
The previous paragraph succinctly describes the design principles of LOD4Culture that are derived from our own experience in the field, from the gaps found in the literature (see Section 2), and from the feedback obtained with prospective users in testing early prototypes of LOD4Culture. Table 2 summarizes the main requirements for LOD4Culture. This application should provide two main functionalities: exploration of CH sites through an interactive map (FR0) and browsing of CH entities (FR1). The former functionality is purposed for discovering CH sites in an area of interest defined by the user. The scope should be world-wide and the map view should be adaptable to different zoom levels (FR2), thus allowing the exploration of small areas – showing a marker for each site, as typical in map applications – but also large ones, providing appropriate aggregating mechanisms to avoid cluttering the map view with too many markers. The application should allow the user to filter CH sites by a specific type (FR3).
Table 2
Requirements for LOD4Culture
| ID | Requirement |
| FR0 | Exploration of world-wide CH sites through an interactive map |
| FR1 | Browsing of CH entities (sites, artists, and artworks) |
| FR2 | Map view adaptable to different zoom levels |
| FR3 | Filtering of CH sites by type |
| FR4 | Provide comprehensive visualizations of CH entities (labels, descriptions, images, locations…) |
| FR5 | Facilitate interlinking of CH entities in the entity browser view |
| FR6 | Support searching of CH entities by label |
| NFR0 | Portable (mobile phones, tablets, and desktop computers) |
| NFR1 | Effective hiding of RDF annotations and SPARQL querying |
| NFR2 | Provide mechanisms to keep latency low |
| NFR3 | Localized to English and Spanish |
With respect to browsing of CH entities, LOD4Culture should provide suitable visualizations (FR4) with the information available in the target LOD sources (labels, descriptions, images, locations, etc.). A CH entity may correspond to a CH site, an artwork, or an artist. Along a session, the user will typically navigate the map and then switch to the entity browser by selecting a site of interest. Entity browsing should be further facilitated by interlinking sites with their artworks, these with their creators, and so on (FR5). In addition, the application should include a textbox for searching CH entities by label (FR6).
Beyond the aforementioned functionalities, LOD4Culture has to comply with a number of non-functional requirements. First, the application should be portable to facilitate its usage in a wide range of devices, including mobile phones, tablets, and desktop computers (NFR0). Since prospective users are not necessarily fluent in Semantic Web technologies, LOD4Culture should provide a user interface that effectively hides RDF annotations or SPARQL queries from end users (NFR1). Furthermore, the application should be responsive in order to keep user engagement; this may be difficult to achieve with third-party services (especially SPARQL endpoints), but LOD4Culture should provide mechanisms to keep latency low (NFR2). Finally, the application should be localized to English and Spanish (NFR3).
3.2.Data sources
LOD4Culture uses Wikidata and DBpedia as sources of CH LOD. Both datasets are well-known by the Semantic Web community; they are open and collaborative projects that are used in a myriad of applications by researchers and industry practitioners. While the scope of Wikidata and DBpedia is cross-domain, CH is well covered in both sources; lots of CH entities can be found from every place in the world and with very detailed annotations in many cases. CH entities are not uniformly annotated in Wikidata and DBpedia though; well-known items commonly include very rich descriptions, but not so popular CH entities are sparsely annotated.
Wikidata and DBpedia contain complementary information about CH entities. Wikidata includes very fined-grained annotations such as inception dates, creators, heritage designations, materials, architects, subelements, widths, heights…DBpedia shines at providing very thorough comments, Wikipedia categories, images, and mappings to Wikidata. Some CH entities include image annotations in DBpedia, but not in Wikidata – this is very typical of contemporary paintings, e.g. Picasso’s Three Musicians (check dbr:Three_Musicians in DBpedia and wd:Q1113293 in Wikidata).
Interestingly, population completeness of CH entities is significantly higher in Wikidata than in DBpedia. As an example, querying the number of castles gives a value of 28,678 in Wikidata99 (members of wd:Q23413 and its subclasses) and 4,845 in English DBpedia (members of dbo:Castle and its subclasses) in July 2022. With other classes of the CH domain, population completeness of Wikidata was systematically higher (4–8 times) than English DBpedia. For this reason, Wikidata is the main source of LOD4Culture, while English DBpedia is used as a secondary source, taking advantage of the Wikidata mappings already available. We also considered the use of Spanish DBpedia as a source, but ultimately decided against utilizing it due to several limitations, particularly the absence of key type annotations, such as dbo:Castle or dbo:Museum, for CH entities.
Unfortunately, the Wikidata endpoint is not responsive enough for supporting the exploration of CH sites (FR0) with a low latency (NFR2). Listing 1 presents a typical query for fulfilling requirement FR0, but the Wikidata endpoint takes several seconds to answer it.1010 Further tests with the custom geospatial box search extension of Wikidata1111 did not serve to reduce latency below one second. In order to address this limitation, we set up a new dataset, henceforth named CHsites.
Listing 1.
Query to the Wikidata endpoint for retrieving the number of castles in a bounding box with the following WGS84 coordinates: South 41°, North 42°, West −5°, East −4°
CHsites contains the essential information about CH sites to fulfill functionality FR0 of LOD4Culture. This dataset was created by submitting a series of SPARQL CONSTRUCT queries to the Wikidata endpoint. Listing 2 shows the prototypical query for castles that retrieves labels, descriptions, and images for presentation purposes; types for supporting type filtering (FR3); geocoordinates and administrative territorial location for positioning; and sitelinks and statements for measuring CH site popularity. We decided to borrow terms from the DBpedia and W3C Geo ontologies – such as dbo:thumbnail instead of wdt:P18 – because they are more mnemonic and easier to grasp than the corresponding Wikidata terms. More importantly, Table 3 includes the types of CH sites that were extracted using a trivial reformulation of the query in Listing 2. Note that the majority of the extracted CH sites require a heritage designation,1212 the rationale of this is to prefer quality over pure quantity as the main purposes of LOD4Culture are tourism and CH education. The dataset was completed with the subclasses of the extracted types of CH sites and the geocoordinates of the administrative territorial locations.
Listing 2.
SPARQL CONSTRUCT query for generating a graph of RDF triples about castles with a heritage designation from the Wikidata endpoint
Table 3
Types of CH sites extracted from Wikidata
| Type of CH site | Wikidata term | # of extracted sites |
| Archaeological site | wd:Q839954 | 75K |
| Castle | wd:Q23413 | 13K |
| Factory | wd:Q83405 | 3K |
| Fountain | wd:Q483453 | 3K |
| Green space | wd:Q22652 | 6K |
| Monument | wd:Q4989906 | 73K |
| Multistorey building | wd:Q79146420 | 4K |
| Museum | wd:Q33506 | 35K |
| National heritage site | wd:Q45580643 | 1K |
| Neighborhood | wd:Q123705 | 2K |
| Office building | wd:Q1021645 | 10K |
| Palace | wd:Q16560 | 4K |
| Place of worship | wd:Q1370598 | 156K |
| Public building | wd:Q294422 | 11K |
| Square | wd:Q174782 | 1K |
| Tower | wd:Q12518 | 12K |
| UNESCO World Heritage Site | wd:Q9259 | 2K |
| Wall | wd:Q42948 | 16K |
CHsites is currently published in a SPARQL endpoint1313 using Openlink Virtuoso v07.20.3230. Table 4 provides some statistics of the dataset that were computed in February 2023. Noteworthy, geospatial queries such as the one in Listing 1 – slightly adapted to the terms employed in the CHsites dataset, check the differences with Wikidata in the SPARQL CONSTRUCT in Listing 2 – are now performant, taking 100–300 milliseconds and thus serving to fulfill requirement NFR2.
Table 4
Statistics of the CHsites dataset
| Item | Total |
| # of CH sites | 521.3K |
| # of types of CH sites | 4.4K |
| # of administrative territorial locations | 87.4K |
| # of triples | 5.3M |
3.3.Architecture
LOD4Culture is designed as a web application to facilitate portability (NFR0), allowing its deployment in multiple devices and platforms as a web browser is ubiquitous nowadays. Traditional web applications require full-page reloads from the server that negatively impacts performance. This limitation is addressed in single-page applications (SPAs), web applications that initially load a single web document and then update their body content with data from the server, resulting in performance gains and a more dynamic experience [28]. Given the latency requirement of LOD4Culture (NFR2), the SPA approach is embraced in this application.
LOD4Culture exposes the routes in Table 5. R0 is a landing page that presents the application and includes links to R1 and R2. Route R1 corresponds to the interactive map functionality (FR0); loc is a required query parameter that refers to a specific position and zoom level with format LAT,LONG,ZOOMz,1414 while siteType is optional and sets a specific CH site type, e.g. http://www.wikidata.org/entity/Q2977, a cathedral in the Wikidata ontology. In this way, R1 can be used to specify the location of any place in the world, with a specific zoom level, and with an optional CH site type filter such as the route /app/?loc=42.879958,-8.544381,15z&siteType=http://www.wikidata.org/entity/Q2977.
Table 5
Routes exposed in LOD4Culture. Query parameters marked with ∗ are required
| ID | Operation | Path | Query parameters | Description |
| R0 | GET | / | – | Landing page of LOD4Culture |
| R1 | GET | /app/ | loc∗, siteType | Map centered in loc with an optional siteType filter |
| R2 | GET | /app/ | type∗, uri∗ | Entity of a specific type and a specific uri |
Route R2 is used to get a representation of a CH entity (functionality FR1). type is a required query parameter for setting the type of CH entity – allowed values are Site, Artwork, and Artist. uri is also required, referring to a Wikidata entity. With this route design, R2 can be employed to specify arbitrary CH entities such as painter Picasso, /app/?type=Artist&uri=http://www.wikidata.org/entity/Q5593, or the Spanish National Sculpture Museum, /app/?type=Site&uri=http://www.wikidata.org/entity/Q1581475.
After embracing the SPA principles and defining the routes, the architecture of LOD4Culture can be designed; it is graphically depicted in Fig. 1. The Router component is in charge of performing client-side routing. If the browser URL changes, the Router detects it and checks its validity. A valid URL has to follow one of the routes in Table 5, as discussed above. The Router dispatches R1-compliant URLs to the Map renderer and R2-compliant URLs to the Entity renderer. A Renderer updates the view according to the incoming request, i.e. the refreshed URL; in order to do it, a Renderer will make data requests to the Data manager. This component is in charge of gathering the necessary data by making calls to LOD4Culture API. Responses from the API are locally stored in the Data cache to minimize future exchanges. Indeed, the Data manager first checks the Data cache and in case of a miss will make a call to the API.
Fig. 1.
Architecture of LOD4Culture.
LOD4Culture API is built with Configurable REST APIs For Triple Stores (CRAFTS) [30]. The case of LOD4Culture is quite suitable for using CRAFTS since it allows a highly flexible access over three different endpoints (Wikidata, DBpedia, and CHsites) that can provide a simple REST API exposing RDF resources and parametrized SPARQL queries, using JSON as interchange format, and caching SPARQL queries from the source endpoints. In other words, the use of a CRAFTS-based API serves to reduce the complexity of creating a LOD-based application such as LOD4Culture. This complexity is transferred to the creation of a configuration file that is used in a CRAFTS site for translating REST calls into SPARQL queries. [30] describes the elements of a CRAFTS configuration file, while the OpenAPI specification of CRAFTS is browsable (and actionable) at https://crafts.gsic.uva.es/docs/. Alternatives to CRAFTS include API generators for LOD such as RAMOSE [10], R4R [2], OBA [14], grlc [24], BASIL [9], and Walder.1515 Only the latter supports multiple endpoints, and all of these API generators provide one-to-one mappings between API calls and SPARQL queries. CRAFTS, on the other hand, uses one-to-many mappings, offering greater control over data exposure – a key requirement for LOD4Culture.
The Appendix depicts the configuration file of LOD4Culture API – essentially a JSON object with a collection of keys and values. apiId contains the identifier of the API, chsites.1616 endpoints includes the information for accessing the three endpoints in LOD4Culture. model contains an array of the different RDF resources exposed by the API; each one defines mappings of RDF data to JSON by referring to datatype properties (dprops), object properties (oprops), and class membership (types). Finally, queryTemplates includes four parametrized SPARQL queries. Table 6 includes a comprehensive sample of the API calls used in LOD4Culture. They will be analyzed in the following two subsections that focus on the main functionalities of the application.
Table 6
Sample calls to the LOD4Culture API
3.4.Rendering maps
The Map renderer is in charge of supporting the map navigation functionality (FR0), showing the CH sites in the map view using LOD as source (the CHsites dataset in this case, as discussed in Section 3.2). An interactive map is used for this purpose, supporting typical panning and zooming operations that are naturally supported for both point-and-click and touchscreen interfaces. The Map renderer carries out this task by handling R1-compliant routes. Upon an incoming request, the map view is centered in the location extracted from the browser URL, and with the indicated zoom level. Then, a rectangular grid, centered in point LAT=0, LONG=0, is employed to fill the map view; the cell side is configured to 9° for zoom level 4 and scaled to other zoom levels.1717 In this way, the size of a cell is fixed and independent of the device. Screen size can vary a lot across devices, so a mobile phone will typically use 15–25 cells, while a desktop computer with a 21" screen can easily display 80–100. Nevertheless, a location at a given zoom level will always correspond to the same grid cell.
A grid cell is the unit of work for displaying CH sites in the map. After computing the grid, the Map renderer processes each cell autonomously. For every cell, a request is sent to the Data manager for gathering the necessary data from the CHsites dataset – the user interface will display a progress bar as long as there are cells waiting for data. The Data manager first obtains the number of CH sites by using query template countSitesInbox in the Appendix, parametrized with the bounding box of the cell and the optional CH site type filter – see sample calls C0 and C1 to the LOD4Culture API in Table 6. The response is an integer value that is stored in the Data cache for future usage. If this value is between 1 and 10, it makes sense to plot a marker for each CH site in the map; thus, the Data manager will request the information about the CH sites by using query template sitesInbox with the cell bounding box and the optional CH site type filter as before (calls C2 and C3). The response now includes a list of CH sites with their geocoordinates, labels, number of sitelinks and statements, images and descriptions (check query template sitesInbox in the Appendix) – this answer is also cached, as any request to the LOD4Culture API.
Once cell data is ready, the Map renderer will plot the corresponding markers in the map. Markers are 50 pixel-wide circles that embed an image of the CH site if available. As markers can still overlap, we employ an estimator of CH site popularity to set the z-index CSS property1818 of markers. This ensures that more popular CH sites are displayed on top of less popular ones. We use the following formula for this purpose:
When a marker of a CH site is first clicked, the Map renderer immediately displays a popup with the site image and a loading spinner labeled “Loading artworks…”; behind the scenes, it sends a request to the Data manager for obtaining the 10 most popular artworks at the CH site. The Data manager uses query template mostPopularArtworksAtSite for fulfilling this request (call C5). The Wikidata endpoint is employed for this request, with the IRI of the CH site as parameter; equation (1) is used to estimate artwork popularity. Once the data is received, the Map renderer checks if there are any artworks and in that case updates the popup with a slideshow component. This allows the user to easily view the most popular artworks at a site and navigate to a dedicated page for further information if desired.
The threshold of 10 CH sites per cell is a configuration parameter of the application. It is employed to avoid plotting too many markers in a cell since they will look cluttered in the map. This is especially relevant with low zoom levels (0–9) in which a cell can concentrate hundreds or even tens of thousands of CH sites – it is also quite inefficient to gather the information of all the CH sites in a very large area. Instead, LOD4Culture will plot a single cluster marker with the number of CH sites in the cell. A simple approach for positioning a cluster marker is to use the center of the cell; however, the result does not look good as the grid division is too evident to the user and, worse, cluster markers may be positioned in awkward places, e.g. in the middle of the ocean. Instead, the Data manager will use query template mostPopularLocationInbox to find a more suitable location for plotting a cluster marker (call C4). This corresponds to the regional administrative location that contains more CH sites in the cell. Figure 2 includes several snapshots of the interactive map of LOD4Culture, illustrating the use of individual and cluster markers at different zoom levels.
Fig. 2.
Snapshots of the map interface of LOD4Culture. (a) Route /app/?loc=41.623655,3.801270,5z: the map covers a very large area that includes South-West Europe and North Africa; cluster markers aggregating CH sites are shown in Europe and the Mediterranean coast of Africa, while single CH site markers are displayed in the rest of Africa. (b) Route /app/?loc=42.757188,-6.908581,8z: the map is positioned in the last part of the Way of St James (North-West Spain); cluster markers are positioned in the main cities of the view, while single CH site markers are plotted along the North-East border of Portugal and Spain; the taxonomy of CH site types is displayed in the top-left form. (c) Route /app/?loc=42.757188,-6.908581,8z&siteType=http://www.wikidata.org/entity/Q2977: the map covers the same area as (b), but only cathedrals are shown due to the type filter set in the top-left form; a popup of León Cathedral is displayed. (d) Route /app/?loc=41.893061,12.482765,15z: the map is centered in a tiny area, corresponding to the city center of Rome; the search textbox shows a list of 10 suggestions for input text vatican that are sorted by popularity and including a distinguishing icon to differentiate the type of CH entity.
In order to support filtering of CH sites by type (FR3), the Data Manager performs a bootstrapping routine for building the taxonomy of CH site types at launch time. API calls like C6 are used for this purpose, initially employing the full list of CH site types in Table 3. For a given CH site type such as wd:Q23413 (castle), call C6 will retrieve its labels, number of members, and subclasses – check model element SiteType in the Appendix Listing 3. The Data Manager will recursively employ API call C6 with the found subclasses until the full taxonomy is built. Once computed, the Site type button in the top-left bar of the user interface (see Fig. 2(a)) will be enabled. Upon clicking this button, the taxonomy of CH site types can be browsed (Fig. 2(b)) or simply searched by using the provided text search box. The CH site types in Table 3 are the top elements in the taxonomy; their subclasses can be expanded or collapsed with the provided buttons. Figure 2(b) displays a portion of the CH site type taxonomy, sorted by the number of extracted sites and matching the types in Table 3 – Place of worship is the top CH site type and Religious building is its most popular subclass.2020 Selecting a CH site type updates the browser URL with the siteType parameter set, triggering a validation of the new URL by the Router component. Then, the Map renderer will follow a new cycle for updating the map according to the new route.
3.5.Browsing CH entities
During a session with LOD4Culture, a user will navigate the map and may find a CH site of their interest, e.g. Cathedral of León in Fig. 2(c), or one of the artworks at a site. Alternatively, a user may use the search text box to find CH sites, artists, or artworks (FR6) – see Fig. 2(d) for an example. LOD4Culture supports browsing of such CH entities (FR1) that employ R2-compliant routes. Refreshing the browser URL will activate the Router that will validate the route and then dispatch the request to the Entity renderer. The functioning of this component is quite simple: it will extract the type and the entity IRI from the URL, and then make a request to the Data manager with these two parameters. The latter component will return a JSON object with the data about the requested entity that will be employed by the Entity renderer to create an HTML page (FR4). Figure 3 shows several snapshots of HTML pages of CH entities.
Fig. 3.
Snapshots of the CH entity interface of LOD4Culture. (a) Extract of the visualization of CH site National Sculpture Museum – route /app/?type=Site&uri=http://www.wikidata.org/entity/Q1581475 – showing label, short description, types and image from Wikidata; and long description and Wikipedia categories from DBpedia; source pages and social media buttons are also included. (b) Extract of the visualization of CH site Museo del Prado – route /app/type=Site&uri=http://www.wikidata.org/entity/Q160112 – showing basic information, e.g. country, and a browsable list of the 5K artworks retrieved from Wikidata; clicking on an artwork will lead to a new CH entity in LOD4Culture, e.g. painting ‘Las Meninas’. (c) Extract of the visualization of artwork ‘Nighthawks’ – route /app/?type=Artwork&uri=http://www.wikidata.org/entity/Q83872 – showing an image and a list of factual information; blue buttons link to other CH entities in LOD4Culture, e.g. artist Edward Hopper; gray buttons display modal windows with the corresponding source Wikidata or DBpedia pages. (d) Extract of the visualization of artist Leonardo da Vinci – route /app/?type=Artist&uri=http://www.wikidata.org/entity/Q762 – showing label, short and long descriptions, types, and Wikipedia categories; the search textbox shows a list of suggestions for picas.
In order to answer an entity request from the Entity renderer, the Data manager will first look up the Data cache. In case of a miss, the Data manager will make an API call such as C7–9 with the type and entity IRI parameters. Therefore, all the complexity is translated to the authoring of the configuration file of LOD4Culture API. Specifically, three RDF resources from the model are exploited for this functionality; namely, Site, Artist, and Artwork. They all extend DetailedThing to reuse common properties: labels, descriptions, number of sitelinks and statements, types, images, and Wikipedia categories (see the Appendix). Configuring the extraction of this data is trivial in some cases, e.g. setting property wdt:P18 for retrieving images from Wikidata, but some cases are more involved, e.g. all data obtained from English DBpedia makes use of property owl:sameAs for finding the corresponding DBpedia entity from the given Wikidata entity.
Site, Artist, and Artwork define their own properties, e.g. latitude and longitude WGS84 coordinates for Site. Figure 3(b) and Fig. 3(c) show that different data is retrieved depending on the entity type. Interestingly, Site and Artist are configured to extract lists of artworks pertaining to the site collection (through property wdt:P276) and created by the corresponding artist (through property wdt:P170), respectively. As some sites (and maybe some artists) host very large collections,2121 a generous limit of 5,000 artworks is set, using equation (1) for sorting (check subelement works of Site and Artist in the Appendix). Moreover, contained artworks are configured with the embed flag and shaped as LabeledThing, so LOD4Culture API will first obtain the IRIs of the 5,000 most popular artworks and then retrieve their corresponding labels – this is sufficient for listing the collection of artworks through a paginated view with support for text search, as shown in the bottom part of Fig. 3(b). Note that a browsing session is naturally supported by interlinking CH sites with their artworks, these with their creators and hosting sites, and artists with their artworks (FR5). Search of CH entities (FR6) is also supported through a search textbox, again using equation (1) for sorting – see Fig. 3(d).
3.6.Implementation
LOD4Culture is coded in JavaScript; this programming language is the natural choice for developing web applications. The implementation effort has been considerably reduced by the usage of a number of JavaScript libraries. Notably, the Map renderer relies on Leaflet2222 for the interactive map. All mapping functionality needed in LOD4Culture is supported with this library through the use of markers, popups, map controls and interaction capabilities. OpenStreetMap2323 is used as the underlying base map.
The user interface is built with Bootstrap2424 to easily accommodate different browsers and screen sizes in a responsive way. The top-left bar of the map interface in Fig. 2 uses Bootstrap components. The CH entity interface – see Fig. 3 – is entirely based on Bootstrap. For the creation of HTML pages, the Entity renderer makes usage of Mustache2525 templates – one for each type of CH entity. In this way, the transformation of a JSON object into an HTML page is almost automatic. The utility functions of Underscore2626 are employed for handling collection in all parts of the code. Lastly, usage of LOD4Culture is tracked with Google Analytics.2727
LOD4Culture API is deployed on a test site of CRAFTS, accessible at https://crafts.gsic.uva.es/apis/chsites/. LOD4Culture includes a configuration file with the URL of this API along with a read token for accessing CRAFTS through Bearer authentication [20]. This file also contains access data to a Solr2828 text search server for retrieving CH entities by label (functionality FR6). Figures 2(d) and 3(d) shows how this functionality is integrated in the user interface.
Since LOD4Culture needs to be localized to English and Spanish (requirement NFR3), LOD4Culture API is configured to extract all labels and descriptions in these two languages. Moreover, the application includes a multilingual strings file with all the labels employed in the user interface. When LOD4Culture starts, it gets the browser language preferences to decide the session language that will be applied to every text shown.
The source code of LOD4Culture is available on GitHub.2929 A live version of the application3030 is openly available for anybody who wants to use it.
4.Impact of LOD4Culture
Before releasing LOD4Culture to the public, we conducted several user tests with early prototypes of the application. We engaged approximately 18 prospective users with a mixed background, including secondary school art teachers, secondary school students, retirees, computer scientists, technology education experts, and computer science graduate students – note that no Semantic Web experts participated and that this group adequately represents both the tourism and education cases. We received feedback from most of the users (but not all) through email messages, informal talks, and observations. This was key in improving the prototype, resulting in the release of a more refined application. Initially, the prototype only displayed museums on the map, but user feedback led us to expand the scope to include other CH sites, which are listed in Table 3 of the manuscript. Some users challenged us to show in LOD4Culture lesser-known CH sites, such as the abandoned village of Castrotorafe3131 – this kind of suggestions were quite helpful to refine the types of CH sites to be displayed.
We also obtained very valuable feedback on usability issues. For example, we observed a user struggling to zoom in on a picture in the entity interface of LOD4Culture. This was due to a viewport meta tag3232 with maximum-scale=1 disallowing zoom. This property makes sense for the map view, but not for the entity browser – we have adjusted this property to only apply to the map interface since them. Other users provided direct feedback, such as requesting modal windows for embedding Wikidata and DBpedia pages instead of opening new tabs.
The test site of LOD4Culture3333 was launched in March 2022. We shared the application link with some colleagues and prepared several Twitter threads to promote LOD4Culture. One of these threads gain some visibility with more than 5.7K impressions and hundreds of engagements (likes, comments, retweets, etc.). Many of the interactions came from Semantic Web practitioners, CH experts, librarians, and organizations like Wikidata and DBpedia (the data providers of LOD4Culture), datos.gob.es (Spanish open government data site), Gobierno Abierto JCyL (regional open government data site in Castile y León), or Spanish Society for Scientific Documentation and Information (SEDIC).
As a result of this activity in social networks, we were contacted by DBpedia to feature a short community article about LOD4Culture in the DBpedia Newsletter of April 2022.3434 In May 2022, Universidad de Valladolid, our employer, released a press note about LOD4Culture,3535 while a Spanish newspaper published an article about this application.3636 In June 2022, datos.gob.es included LOD4Culture in its list of featured open data applications.3737 In September 2022, we were invited to give a talk about this application in ‘I Seminario internacional y II nacional Territorios Activos’,3838 a seminar on the use of ICTs for fostering innovation in rural settings. LOD4Culture is also included in a list of Wikidata visualization tools.3939
Since traffic in the test site is tracked with Google Analytics, the uptake of LOD4Culture can be easily analyzed. Table 7 summarizes the collected data, obtained in February 2023. In a period of barely a year, more than 1.7K users have employed the application in 2.8K sessions (with an average time of 1 minute and 57 seconds). 64.6% of new users came to LOD4Culture directly, i.e. entering the URL in the browser, 17.2% were acquired through organic4040 social media, 13.1% from referral traffic, 4.6% from organic search, and 0.6% from email. Users mainly come from Spain (63.0%), Canada (7.6%), Germany (6.0%), United States (4.9%), and France (2.9%). The employed devices include mobiles (49.5%), desktop computers (47.6%), and tablets (3.6%). We also track page views, finding that the map interface (77.6% of all the page views) is more intensively used than the entity interface (9.1%). Users have carried out 10.1K text searches in LOD4Culture, resulting in 3.1K entity page views, with the most viewed entities being the Prado Museum, Michelangelo, Louvre Museum, Diego Velázquez, Edgar Degas, and Pablo Picasso.
Table 7
Uptake of the test site of LOD4Culture
| Item | Value |
| # of users | 1.7K |
| # of sessions | 2.8K |
| Average time per session | 1 m 57 s |
| # of page views | 33.8K |
| % of landing page views (route R0) | 13.3% |
| % of map page views (route R1) | 77.6% |
| % of CH entity page views (route R2) | 9.1% |
Tracked data also includes latencies of the pages served with LOD4Culture. A map page takes 1.4 seconds on average; the time elapsed in mobile devices is just 0.8 seconds due to small screens requiring less grid cells than desktop computers. In the case of CH entity pages, the average latency is 2.4 seconds.
5.Discussion
LOD4Culture is a CH LOD-based application that fulfills all the requirements in Table 2. LOD4Culture adheres to the REST principles of web design [13], so all the application state is encapsulated in the URL (see Table 5). As a result, URLs will refresh as a result of the user interaction, allowing them to be shared and ensuring that a URL will produce the same view regardless of the device employed.
The interactive map of LOD4Culture is arguably the most challenging part of the application, especially for accommodating different zoom levels (FR2). The solution devised is highly adaptable by partitioning the map view in a grid and by retrieving cell data in a two-step process: first requesting the number of CH sites in a cell, and then obtaining site data if it makes sense to plot it. In this way, network exchanges are reduced and client resources are not wasted by plotting hundreds or thousands of markers in a tiny area. In contrast, the browser of CH entities is much simpler, as the Entity renderer only has to produce an HTML page out of a JSON object.
The complexity of the application is greatly reduced by the use of a CRAFTS API. The interactive map only needs four template queries to gather the required data. Similarly, the CH entity browser just uses three RDF resources defined in the API model to fulfill its data needs (see sample calls C7–9 in Table 6). From the point of view of the application, it only sees JSON data and REST API calls. Behind the scenes, the CRAFTS API provides single access to three different endpoints by translating API requests into SPARQL queries. Despite this simplicity of use, the configuration file of LOD4Culture has been carefully crafted to match the needs of the application. In the case of template queries, this involves the selection of the prototype queries and then defining the parameters, e.g. the SPARQL query in Listing 1 is mapped to the countSitesInbox query template in the Appendix. Regarding RDF resources, the process begins with the identification of the object and data properties to be extracted; more fine-grained decisions can be made for embedding data or for setting additional restrictions – check the examples given in Section 3.5. This process is entirely declarative and can be repurposed without requiring changes in the application or the sources, e.g. the limit of 5,000 artworks in a site collection can be set to something else or the sorting equation can be modified (check subelement works of Site and Artist in the Appendix).
Since LOD4Culture is an interactive application, we have taken special care to meet latency requirements (NFR2). We employ client-side caching along a user session to avoid duplicated requests to the API. Server-side caching in CRAFTS can benefit the whole community of LOD4Culture users, as well as data providers that will receive less traffic. In this regard, the use of a common grid with fixed lengths per zoom level contribute to make server-side caching more effective. Despite all these measures, latency is quite dependent on data providers. As discussed in Section 3.2, we had to set up our own dataset due to latency problems with Wikidata. Thanks to SW technologies, the burden to gather the data and upload it into a new endpoint was negligible and can be easily replicated.
All in all, LOD4Culture can be used for tourism and CH education purposes by lay users, i.e. without requiring knowledge of SW technologies. More than 1.7K users have employed the application in a year. We have received very positive feedback through social media and the application has been featured in DBpedia Newsletter and in the open data applications list of datos.gob.es. Our future work includes user studies in educational and tourism settings in order to better assess the potential of LOD4Culture. While the application can be useful in detecting inaccuracies or gaps in CH data, we aim to investigate how it can also facilitate contributions to the LOD sources.
Notes
9 Note that the query in Listing 2 also requires a heritage designation, a geolocation, sitelinks, statements, and a label in English or Spanish. This is why only 13K castles were extracted, as shown in Table 3.
10 The latency of a similar query in the English DBpedia endpoint is one order of magnitude lower, i.e. hundreds of milliseconds, which is acceptable for an interactive application.
12 Only museums, national heritage sites, and UNESCO World Heritage Sites did not require a heritage designation; in these cases the triple pattern ?site wdt:P1435/wdt:P279* wd:Q358 was removed from the corresponding SPARQL CONSTRUCT queries.
13 Endpoint URL http://chsites.gsic.uva.es/sparql and graph IRI http://chsites.gsic.uva.es.
14 LAT and LONG assume WGS84 as a reference datum. ZOOM represents the zoom level in powers of two, typically ranging from 0 (the whole world is entirely represented in a tile) to 20 (∼1 trillion tiles are needed to show the entire world).
16 Note that this identifier was chosen before naming the application as LOD4Culture.
17 As map applications typically employ a spherical Mercator projection, vertical sides of cells will look longer near the poles than near the Equator.
19 Check https://ad-wiki.informatik.uni-freiburg.de/research/HowTos/WikidataCheatSheet for an example.
20 Note that the counting of the CH site members shown in the application is an approximation. For performance reasons – there are more than 4.4K CH site types – only the direct members of each CH site type are retrieved (check model element SiteType in the Appendix Listing 3). For a given CH site type the actual figure is obtained by summing the count of its direct members and all of its subtypes; thus, a single entity may be counted multiple times if it is a member of several CH site types. This is why Fig. 2(b) shows 192K members for Place of worship, while Table 3 specifies 156K. Despite the figures shown in the application are imprecise, they serve for sorting in a performant way.
21 For example, Wikidata includes more than 22K artworks in the collection of Metropolitan Museum of Art (wd:Q160236).
31 Accessible on the LOD4Culture map, check https://lod4culture.gsic.uva.es/app/?loc=41.727640,-5.787649,13z.
33 See footnote 30.
40 Organic means that traffic is earned, not paid.
Acknowledgements
This work has been partially funded by the European Commission through Virtual Forests (Erasmus+ 2020-1-ES01-KA226-HE-09583) and by the Spanish Ministry of Science and Innovation through LOD.For.Trees (TED2021-130667B-I00) and H2O (PID2020-112584RB-C32) projects.
Appendices
Appendix
AppendixCRAFTS API configuration of LOD4Culture
We include here the CRAFTS API configuration file employed in LOD4Culture. It is also available at https://crafts.gsic.uva.es/apis/chsites/ and can be retrieved with the following curl command:
curl -X "GET" \ "https://crafts.gsic.uva.es/apis/chsites" \ -H "accept: application/json" \ -H "Authorization: Bearer a53f0d88-c8a6-4dfb-aa77-1a204826fece"
This command uses the read token required for accessing the LOD4Culture API. Every API call must include this token, such as the following command for call C0 in Table 6:
curl -X "GET" \ "https://crafts.gsic.uva.es/apis/chsites/query?id=countSitesInbox &lngwest=-5&lngeast=-4&latnorth=42&latsouth=41" \ -H "accept: application/json" \ -H "Authorization: Bearer a53f0d88-c8a6-4dfb-aa77-1a204826fece"
For further information on using CRAFTS, refer to [30].
Listing 3.
CRAFTS API configuration of LOD4Culture
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
Listing 3.
(Continued.)
References
[1] | M. Alam, V. de Boer, E. Daga, M. van Erp, E. Hyvönen and A. Meroño-Peñuela, Editorial of the special issue on cultural heritage and semantic web, Semantic Web 14: ((2023) ), 155–158. doi:10.3233/SW-223187. |
[2] | C. Badenes-Olmedo, P. Espinoza-Arias and O. Corcho, RESTful-API for RDF data (R4R), in: Proceedings of the ISWC 2021 Posters & Demonstrations and Industry Tracks Co-Located with 20th International Semantic Web Conference (ISWC 2021), O. Seneviratne, C. Pesquita, J. Sequeda and L. Etcheverry, eds, CEUR Workshop Proceedings, Vol. 2980: , Aachen, Germany, (2021) . |
[3] | A. Bikakis, E. Hyvönen, S. Jean, B. Markhoff and A. Mosca, Editorial: Special issue on semantic web for cultural heritage, Semantic Web 12: (2) ((2021) ), 163–167. doi:10.3233/SW-210425. |
[4] | J. Blake, On defining the cultural heritage, International & Comparative Law Quarterly 49: (1) ((2000) ), 61–85. doi:10.1017/S002058930006396X. |
[5] | T. Bray (ed.), The JavaScript Object Notation (JSON) data interchange format, Standards Track, RFC 8259, Internet Engineering Task Force (IETF), 2017, URL: https://datatracker.ietf.org/doc/html/rfc8259, last visited May 2023. |
[6] | C. Brumann, Cultural heritage, in: International Encyclopedia of the Social and Behavioral Sciences, Elsevier, (2015) , pp. 414–419. doi:10.1016/B978-0-08-097086-8.12185-3. |
[7] | A.-S. Dadzie and E. Pietriga, Visualisation of linked data – reprise, Semantic Web 8: (1) ((2017) ), 1–21. doi:10.3233/SW-160249. |
[8] | A.-S. Dadzie and M. Rowe, Approaches to visualising linked data: A survey, Semantic Web 2: (2) ((2011) ), 89–124. doi:10.3233/SW-2011-0037. |
[9] | E. Daga, L. Panziera and C. Pedrinaci, A BASILar approach for building web APIs on top of SPARQL endpoints, in: Proceedings of the Third Workshop on Services and Applications over Linked APIs and Data (SALAD2015), Co-Located with the 12th European Semantic Web Conference (ESWC 2015), Vol. 1359: , Portoroz, Slovenia, (2015) , pp. 22–32. |
[10] | M. Daquino, I. Heibi, S. Peroni and D. Shotton, Creating restful APIs over SPARQL endpoints with RAMOSE, Semantic Web 13: (2) ((2022) ), 195–213. doi:10.3233/SW-210439. |
[11] | E. Davis and B. Heravi, Linked data and cultural heritage: A systematic review of participation, collaboration, and motivation, Journal on Computing and Cultural Heritage (JOCCH) 14: (2) ((2021) ), 1–18. doi:10.1145/3429458. |
[12] | C. Dijkshoorn, L. Jongma, L. Aroyo, J. Van Ossenbruggen, G. Schreiber, W. Ter Weele and J. Wielemaker, The Rijksmuseum collection as linked data, Semantic Web 9: (2) ((2018) ), 221–230. doi:10.3233/SW-170257. |
[13] | R.T. Fielding, Architectural styles and the design of network-based software architectures, PhD thesis, University of California, Irvine, 2000. |
[14] | D. Garijo and M. Osorio, OBA: An ontology-based framework for creating REST APIs for knowledge graphs, in: Proceedings of the 19th International Semantic Web Conference (ISWC 2020), J.Z. Pan, V. Tamma, C. d’Amato, K. Janowicz, B. Fu, A. Polleres, O. Seneviratne and L. Kagal, eds, LNCS, Vol. 12507: , Springer, Cham, Switzerland, (2020) , pp. 48–64. |
[15] | T. Heath, J. Domingue and P. Shabajee, User interaction and uptake challenges to successfully deploying semantic web technologies, in: Proceedings of the 3rd International Semantic Web User Interaction Workshop (SWUI2006), Co-Located with the 5th International Semantic Web Conference, Athens, GA, USA, (2006) . |
[16] | B. Humm, Fascinating with open data: openArtBrowser, in: Proceedings of the Conference on Digital Curation Technologies (Qurator 2020), A. Paschke, C. Neudecker, G. Rehm, J.A. Qundus and L. Pintscher, eds, CEUR Workshop Proceedings, Vol. 2535: , Aachen, Germany, (2020) . |
[17] | E. Hyvönen, Digital humanities on the semantic web: Sampo model and portal series, Semantic Web 14: (4) ((2020) ), 729–744. doi:10.3233/SW-223034. |
[18] | E. Hyvönen, Using the semantic web in digital humanities: Shift from data publishing to data-analysis and serendipitous knowledge discovery, Semantic Web 11: (1) ((2020) ), 187–193. doi:10.3233/SW-190386. |
[19] | A. Isaac and B. Haslhofer, Europeana linked open data – data.europeana.eu, Semantic Web 4: (3) ((2013) ), 291–297. doi:10.3233/SW-120092. |
[20] | M. Jones and D. Hardt, The OAuth 2.0 authorization framework: Bearer token usage, Standards Track, RFC 6750, Internet Engineering Task Force (IETF), 2012, URL: https://datatracker.ietf.org/doc/html/rfc6750, last visited May 2023. |
[21] | E. Kapsalis, Wikidata: Recruiting the crowd to power access to digital archives, Journal of Radio & Audio Media 26: (1) ((2019) ), 134–142. doi:10.1080/19376529.2019.1559520. |
[22] | C.A. Knoblock, P. Szekely, E. Fink, D. Degler, D. Newbury, R. Sanderson, K. Blanch, S. Snyder, N. Chheda, N. Jain et al., Lessons learned in building linked data for the American art collaborative, in: Proceedings of the 16th International Semantic Web Conference (ISWC 2017), LNCS, Vol. 10588: , Springer, Cham, Switzerland, (2017) , pp. 263–279. doi:10.1007/978-3-319-68204-4_26. |
[23] | D.W. Livingstone, Adults’ informal learning: Definitions, findings, gaps and future research, NALL Working Paper, 21, Centre for the Study of Education and Work, OISE/UT, 2001, URL: https://tspace.library.utoronto.ca/retrieve/4484/, last visited May 2023. |
[24] | A. Meroño-Peñuela and R. Hoekstra, grlc makes GitHub taste like linked data APIs, in: Proceedings of the 13th European Semantic Web Conference (ESWC 2016), H. Sack, G. Rizzo, N. Steinmetz, D. Mladenić, S. Auer and C. Lange, eds, LNCS, Vol. 9989: , Springer, Cham, Switzerland, (2016) , pp. 342–353. |
[25] | M. Ott and F. Pozzi, Towards a new era for cultural heritage education: Discussing the role of ICT, Computers in Human Behavior 27: (4) ((2011) ), 1365–1371. doi:10.1016/j.chb.2010.07.031. |
[26] | M.A. Pellegrino, V. Scarano and C. Spagnuolo, Move cultural heritage knowledge graphs in everyone’s pocket, Semantic Web 14: ((2023) ), 323–359. doi:10.3233/SW-223117. |
[27] | A. Ruiz-Calleja, P. García-Zarza, G. Vega-Gorgojo, M.L. Bote-Lorenzo, E. Gómez-Sánchez, J.I. Asensio-Pérez, S. Serrano-Iglesias and A. Martínez-Monés, Casual learn: A linked data-based mobile application for learning about local cultural heritage, Semantic Web 14: ((2023) ), 181–195. doi:10.3233/SW-212907. |
[28] | E.A. Scott Jr., SPA Design and Architecture: Understanding Single-Page Web Applications, Manning Publications, (2015) . |
[29] | J. Tandy, L. van den Brink and P. Barnaghi, Spatial data on the Web best practices, W3C Working Group Note, OGC 15-107, OGC & W3C, 2017, URL: https://www.w3.org/TR/sdw-bp/, last visited May 2023. |
[30] | G. Vega-Gorgojo, CRAFTS: Configurable REST APIs for triple stores, IEEE Access 10: ((2022) ), 32426–32441. doi:10.1109/ACCESS.2022.3160610. |
