LOD4Culture: Easy Exploration of Cultural Heritage Linked Open Data

Tracking #: 3250-4464

Authors: 
Guillermo Vega-Gorgojo

Responsible editor: 
Guest Editors Interactive SW 2022

Submission type: 
Application Report
Abstract: 
LOD4Culture is a web application that exploits Cultural Heritage (CH) 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 CH sites that can be filtered by type and that uses cluster markers to adapt the view to different zoom levels. LOD4Culture also includes a CH entity browser that builds comprehensive visualization of sites, artists, and artworks. All data exchanges are facilitated through a CRAFTS API that translates REST API calls into SPARQL queries over multiple Linked Open Data sources, including Wikidata and DBpedia. Since March 2022, more than 1.1K users have employed LOD4Culture. The application has been mentioned many times in social media and has been featured in the DBpedia Newsletter and in the open data applications list of datos.gob.es.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 03/Nov/2022
Suggestion:
Reject
Review Comment:

This paper describes the application called LOD4Culture. This is an application that extracts data about cultural heritage sites from wikidata and wikipedia and makes that data available in a nice graphical interface. The interface allows a user to select an area, show the cultural heritage sites and drill down into the details of the site. The developers took great pains to ensure that the application was fast, responsive , easy to use, and well documented.

Quality: The application appears to be of very high quality. The engineering issues are carefully thought out and described in the paper.

Importance: This is a rather straightforward application that is taking the cultural heritage sites and showing them on a map and then allowing a user to drill into the individual sites. There is nothing particularly innovative about this application. It is well engineered, but doesn’t provide any new ideas that go beyond just putting the sites on a map and allowing a user to drill down. Given the wealth of data available in the LOD, it seems like there is so much more one could do with the data and the related information. For example, placing cultural heritage sites and the related artwork into their historical context, such as the interface described in [Knoblock et al., ISWC 2017], although not clear if that was ever implemented. There are previous systems that have also presented cultural heritage sites with similar functionalty (e.g., LODAC [Matsumura et al., 2012]) and certainly ones that are not using semantic web technologies, such as a major site in Canada but I can’t find the reference. The use of the semantic web here is just integrating the data across Wikipedia and Wikidata and not clear if that data is actually combined for just aggregated across sites.

Knoblock et al., Lessons Learned in Building Linked Data for the American Art Collaborative. In ISWC 2017 - 16th International Semantic Web Conference, 2017.

Matsumura, F., Kobayashi, I., Kato, F., Kamura, T., Ohmukai, I., Takeda, H.: Producing and consuming linked open data on art with a local community. In: Proceedings of the COLD Workshop, Volume 905, CEUR-WS.org (2012) 51–62

Impact: The application may make an impact in terms of making cultural heritage data available to many users, but I don’t believe it will make much of an impact in terms of how people build other applications of semantic web technologies.

(2) Clarity and readability of the describing paper: the paper is very clear and well written, although it goes into a level of detail about the engineering of the application that would be more appropriate for the internal documentation of the application than the publication in a paper. I like reading about applications, but I found this paper was down in the weeds in details and didn’t give me any new insights about how to exploit the semantic web data.

The application does have a github repository that appears to be well organized and documented.

I think a better venue for a paper on this work would be the demo track of ISWC.

Review #2
Anonymous submitted on 04/Dec/2022
Suggestion:
Major Revision
Review Comment:

This paper describes a web application that allows users get information about cultural places extracted from RDF sources (wikidata and DBpedia).

As application report this submission should be reviewed along the following dimensions: (1) Quality, importance, and impact of the described application (convincing evidence must be provided). (2) Clarity and readability of the describing paper, which shall convey to the reader the key ideas regarding the application of Semantic Web technologies in the application.

Regarding (2): The paper is well written and it is easy to follow. In addition links to the software and reused artefacts are provided.

Regarding (1): The author explains the motivation for the application, it development showing examples and comment on the impact based on the attention attracted by the application. In this regards there are also some questions that arise when reading the paper.

1. Introduction

-- It is claimed that the application is thought for tourism and educational purposes. However, from the information shown it seems that the application provides the user with information about entities in a map. While it is easy to image the use case for tourism it is more difficult to image it for educational purposes apart from providing students with such information. Is there any feature of the application oriented to educational purposes or the use case is left to the use than an educator can make of it?

-- Some approaches for API generators are mentioned ad OBA or RAMOSE but the application is built on top of the his own system, which seems more practical from the development point of view but it is not well explained why this approach suits better the needs. Also, other systems could be included in the comparison as:

[1] RESTful-API for RDF data (R4R). Badenes-Olmedo, C., Espinoza-Arias, P., and Corcho, O. (2021). R4R: Template-based REST API Framework for RDF Knowledge Graphs. In Proceedings of the ISWC 2021 Posters, Demos and Industry Tracks: From Novel Ideas to Industrial Practice co-located with 20th International Semantic Web Conference, Virtual Conference, 2021. CEUR Workshop Proceedings.

[2] OWL2OAS. Hammar, K. (2020). The OWL2OAS Converter. https://github.com/RealEstateCore/OWL2OAS.

[3] Walder. Heyvaert, P., De Meester, B., Pandit, H., and Verborgh, R. (2020). Walder. https://github.com/KNowledgeOnWebScale/walder.

3. Design of LOD4culture

-- It should be better explained how the requirements have been defined and the roles involved in the process. Have the requirements have been influenced by defined by target users? Again, the application is claimed to target tourism and educational setting but the requirements seems to be general browsing requirements specialized for the case of CH entities.

3.2 Data sources

-- Is is well explained how the data and which data is used but, are there any interactive feature in terms of users contributing to the semantic web?

-- Use of English DBpedia: Why the English DBpedia is used instead of the dbpedia of the main language in the users area? In line with FR0 the exploration is based on the location then, more localized dbpedias could provide extended and more accurate information depending on the area selected. It might be difficult to translate the information for particular languages but it could be done for Spanish speaking languages as NFR3 includes Spanish. Also adding localized DBpedia could be a configurable feature for the application.

-- It is not so clear why in Table 3 there are no religious places but they appear in the search. Please clarify whether they are considered in another category.

-- footnote 10: it would be better to provide a more stable URI for the sparql endpoint, for example under http://chsites.gsic..

3.4 Navigating the map

-- "If this value is between 1 and 10, it makes sense to plot a marker for each CH site in the map;..": Does it make sense to change the limit of 10 based on the screen size?

4 Impact of LOD4Cloud

-- In this section some figures about access and attention attracted by the app are provided. However, there is no user evaluation provided by the author. There is no evidence of access using them in real tourist or educational settings or if the users are people following links from the social media out of curiosity. It would be better to validate the usability of the application in real or experiment-oriented basis and provide the results of the experiments or real users feedback.

Review #3
By Fouad Zablith submitted on 21/Dec/2022
Suggestion:
Major Revision
Review Comment:

The paper presents LOD4Culture, an online application that relies on linked open data (LOD) to enable the exploration and discovery of cultural heritage sites, artists, and artworks.

The paper is submitted as an "Application Report" type and is being reviewed according to two main dimensions: (1) clarity and readability, and (2) Quality, Importance, Impact.

Overall the paper showcases an interesting application based on LOD. The application is well described, and the paper flows nicely.

With respect to clarity and readability, the paper is overall clearly written. There are some improvements that can be introduced, which I believe would strengthen the paper.

At the abstract level, it is better not to use acronyms that require referencing (e.g., CRAFTS). It makes it harder to read. Either such acronyms should be fully described at the abstract level, or maybe it’s better to introduce them in the main paper.

The related work in the field is well developed, with a list of related applications that were developed in the cultural heritage domain and rely on semantic web technologies. It would be better to further elaborate on the limitations of existing systems to flesh out the gap in these tools. This would improve the impact of the proposed work, and make the paper stand out more. For example, is the current limitation of existing tools at the level of processing time of the data? Data coverage? Difficulty in translating SPARQL queries across different triplestores? Or lack in a map-driven exploration of cultural heritage entities? Currently, the related works do not guide the application design decisions.

It was great to see the list of requirements covered in Section 3. However, it wasn't clear in the paper how such requirements were derived. Were they based on a comparison performed to other existing systems? Or were the requirements generated from user interviews/observations? Or empirically derived? It would be good to further elaborate on this.

On page 6, it is mentioned that the queries were "adapted to the ontologies employed in the CHsites dataset, as discussed above". Maybe I missed it, but it's not clear which ontologies you are referring to. Please add more details on this.

I would really like to try running the CRAFTS configuration provided in the Appendix, but I didn't know how. It would be great to add (maybe at the beginning of the Appendix or on Page 8 where you mention the CRAFTS link) some pointers on how to use it. This would improve the access to the data used in LOD4Culture.

I think section 3.4 should be labelled "Rendering Maps" rather than Navigating Maps? This aligns the section better with the Framework labels.

The popularity score computation was not very clear. From where are "sitelinks" and "statements" derived? Wikidata? Please elaborate on this.

With respect to the usability of the application, I was expecting to be able to seamlessly navigate artists and artworks through the map entities. For example, I was expecting to move from The Louvre Museum, and visually navigate to the list of artworks there like the Mona Lisa. Is there a way to exploit the links to reach artworks and artists without leaving the map? It's a design/usability comment. Also, I discovered that there was a missing link between Mona Lisa and the Louvre museum. On LOD4Culture it's mentioned that Mona Lisa is located in "Salle Des Etoiles", which is part of the Louvre, but couldn't reach it through the app. This could be originating from the data source, as I discovered that on Wikidata it's located in both the Louvre and Salle Des Etoiles. So it seems in your data extraction you are only picking one location when an entity is located in several related locations? I think it would be could to keep such connections as well, or there may be disconnects while navigating/exploring some entities.

Another point related to the usability of LOD4Culture is that initially it took a lot time to load. I thought the application was stuck. It would be great to have a more visible way to show that the application is still loading the data on the map.

Concerning the impact, it is good to see that the application has been promoted in the media. You also mentioned that it was used by more than 1.1k users. It would be good to support those numbers with additional data/insights. Are those website visitors? Are there any demographics? Which features are they mainly using? I am sure the more than 5000 Twitter impressions enabled access from a wide variety of users in different locations. If you have additional data to discuss this would make the impact even more visible!

Minor comments:
- On Page 1: "web developers which" --> web developers who
- Please fix the dashes (—) in the sentences (you don't need to have a dash at the end of a sentence, e.g. Section 3.2, end of paragraph 2). Check throughout the paper.
- Footnote 7: "assumable" --> Do you mean assumed? or acceptable?
- "lay users that consumes" --> lay users that consume
- Page 7: "ZOOMz" --> ZOOM
- Page 11, line 1: "populous" --> popular?
- Page 11: "Figure 3(b) and Figure 3(c) shows" --> Figure 3(b) and Figure 3(c) show
- Appendix A doesn't have to be numbered as there is only one appendix.

I tried to list the minor issues as much as I can. Please thoroughly recheck the paper for further typos.

I hope my comments would help improve the paper!