Ontology and Software Tools for the Formalization of the Visualisation of Cultural Heritage Knowledge Graphs
Round 1
Reviewer 1 Report
I find the focus of the paper difficult to determine. It is certainly related to ontologies, visualisation and cultural heritage, but I am unsure of how these three elements are related. On the one hand, there is an extensive body of literature on ontologies of cultural heritage (e.g. https://doi.org/10.1007/978-3-540-92673-3_21, https://doi.org/10.1007/978-3-319-72652-6), and also on the visualisation of cultural heritage. There is also a lot of literature on the conceptualisation of visual representations. However, and after reading the paper twice, I am still unable to understand how the authors want to relate these three elements.
For example, they start by identifying two problems: low reusability of visualisation solutions, and neglect of cultural heritage peculiarities such as "uncertainty, spatial and temporal granularity". They proceed to propose a solution for the visualisation of cultural heritage, but they fail to explain how visualisation can mitigate the reusability and uncertainty/granularity issues. In the regard, I find the paper weakly motivated. What is the research problem? How does the solution (the STEVO ontology) solve or mitigate this problem? I suggest the authors revise the initial sections of the paper (including title and abstract) and develop a better motivation for their work.
In addition, authors state that "The solutions used to visualise the information in these works are usually highly oriented to the project objectives, and many of them are not open-source projects". I find it very reasonable that solutions are oriented to the project objectives. if the authors want to discuss reusability, then I encourage them to assess reusability as an engineering factor and evaluate tradeoffs between standardisation and customisation. Also, authors present the fact that "many of them are not open-source" as if that were, in itself, a problem, but do not indicate why this is so. Overall, there is a strong lack of motivation and explanation of how these issues compelled them to invest in a particular research line.
Also in relation to the this issue, the paper seems to confuse the conceptual representation of cultural heritage elements and their visual representation. A coin is a coin, no matter how (or if) you visualise it. Digitisation efforts are about describing things in digital form and storing that information for further use. Any visualisation that you want to do must sit on top of this previous conceptual representation; otherwise, you will end up with visually-capable solutions that cannot do anything other than visualise, which would worsen the reusability problem. I encourage the authors to apply some layering or modularity to their approach, which are good and proven software engineering techniques, to describe a visually-oriented solution that leverages conceptual representations.
A further issue on the conceptualisation of cultural heritage, the paper seems to ignore much of the existing work about it. Works such as the above-mentioned (https://doi.org/10.1007/978-3-319-72652-6), which are central to the conceptualisation of cultural heritage, are not even mentioned. Also, many works on vagueness and uncertainty of cultural heritage data exist, such as https://doi.org/10.5209/cmpl.72488 or http://hdl.handle.net/20.500.12708/57384.
As a third issue, the paper insinuates much but shows little. For example, the authors repeatedly refer to "most of the projects studied" or "the examined works", but there is no clear list of what solutions or works they have looked at. What specific set of works are they referring to?
A fourth major issue is the fact is related to some of the solution decisions that have been made. On the one hand, the paper seems to base the proposed conceptualisation on the CIDOC CRM E22 Man-Made Object concept. What if the cultual heritage element is not man-made, such as a manuport? What if it is an immaterial element such as a song or a performance?
On the other hand, the approach to visualise uncertainty is trivial and probably not very intuitive. In figure 6 b, for example, the two overlapping pins look like two very close elements rather than one uncertain element. Have the authors empirically validated this visual strategy?
A fifth issue is that much of the ideas presented in the paper look like plans for the future rather than accomplished facts. For example, in Section 4, authors say that "The objective is to 393 develop a computer system", seemingly indicating that the system has not been built yet. Similarly, in Section 3, the repeated use of "would" seems to indicate that this is just an idea rather than a result. I suggest the authors to be more explicit about what has been done and what is a plan for the future.
Finally, and probably the biggest issue, is that the paper does not show the proposed solution. I cannot find a comprehensive description of STEVO. A paper proposing an ontology should at least show a list of concepts, attributes and associations, and/or a diagram. This paper has neither.
Overall, the paper lacks a clear motivation, does not show the solution proposed, and makes some arguably decisions in relation to conceptual and visual approaches. I encourage the authors to rework it by addressing these concerns, as the visualisation of cultural heritage is indeed an important matter.
English must be improved. I suggest the authors ask a proficient English speaker to proofread the paper. Phrases such as "This makes it difficult to reuse these jobs" or "Uncertainty, references to the fact that in cultural heritage it is common not to know for sure where or when an object was created" read awkwardly.
Author Response
Comment >>
However, and after reading the paper twice, I am still unable to understand how the authors want to relate these three elements.
Sorry, we didn't explain this well in the first version of the paper. We hope that the changes made in the last week help to clarify. Anyway, we try to summarise here how we relate the three elements.
We design a model that takes into account the aspects needed to visualise the content of cultural heritage data.
We also design and create an ontology that implements the model.
And finally, we develop a web application framework that receives the data to be visualised:
- The data to be visualised (a list of URIs / queries to execute and retrieve the URIs)
- A link to an instantiated STEVO ontology that formalises how to visualise the data.
The web application processes all this information, displays the data and allows the user interaction defined by the STEVO ontology.
Comment >>
They proceed to propose a solution for the visualisation of cultural heritage, but they fail to explain how visualisation can mitigate the reusability and uncertainty/granularity issues.
We hope that in this version it was clear.
Anyway, we explain it here.
When we talk about reusability we were talking about reuse the visualisation tools, not the whole project.
To develop a visualisation tool implies a high cost. We developed a tool that the users only need to integrate a web application and instantiate an ontology with the mappings and visualisation specification.
This allows the generation of a visualisation system very quick and it was very use to reuse. If anyone like how a project A performs the visualisation only needs to adapt the STEVO ontology of A in order to get similar outcomes.
It is difficult to solve the granularity/uncertainty problems. At the moment we haven’t done nothing in this direction, we want help in the process to visualize this feature. We think that is important the user knows that he/she doesn’t see the real position, real time, real categorization ,etc.
Comment >>
Also in relation to the this issue, the paper seems to confuse the conceptual representation of cultural heritage elements and their visual representation. A coin is a coin, no matter how (or if) you visualise it.
Yes, you are right, a coin is a coin, but we think that it is important how is visualized and we try to conceptualize how to do it considering the problems associated to cultural heritage data. The scene, the object and the user interaction possibilities.
Comment >>
A further issue on the conceptualisation of cultural heritage, the paper seems to ignore much of the existing work about it. Works such as the above-mentioned (https://doi.org/10.1007/978-3-319-72652-6), which are central to the conceptualisation of cultural heritage, are not even mentioned. Also, many works on vagueness and uncertainty of cultural heritage data exist, such as https://doi.org/10.5209/cmpl.72488 or http://hdl.handle.net/20.500.12708/57384.
You are right again. We know some of the papers, but another we haven’t known. We read the references you sent to us and we cite and linked in the paper. Thank you for them. They are very interesting.
Commnet >>
As a third issue, the paper insinuates much but shows little. For example, the authors repeatedly refer to "most of the projects studied" or "the examined works", but there is no clear list of what solutions or works they have looked at. What specific set of works are they referring to?
You are right. In this version we cite some of the works consulted.
Comment >>
A fourth major issue is the fact is related to some of the solution decisions that have been made. On the one hand, the paper seems to base the proposed conceptualisation on the CIDOC CRM E22 Man-Made Object concept. What if the cultual heritage element is not man-made, such as a manuport? What if it is an immaterial element such as a song or a performance?
The CIDOC CRM E22 Man-Made Object concept reference is only used as an example. The model, the ontology and of course the software framework can work with any model. In this version of the paper we try to be clearer.
The process of working with songs or paintings is exactly the same. You just need to instantiate a VIsualConcept painting or song with the appropriate VisualProperty instances and relate them.
Comment >>
On the other hand, the approach to visualise uncertainty is trivial and probably not very intuitive. In figure 6 b, for example, the two overlapping pins look like two very close elements rather than one uncertain element. Have the authors empirically validated this visual strategy?
Yes, we did it, but only with a reduced number of people (3 groups of 5-6 people). It is a work that we plan to carry out in the next course with a larger group of users.
In the test we carried out, we didn't find any problems, but this may be due to the fact that the colour difference was very visual and also, of course, to the reduced number of people.
Comment >>
A fifth issue is that much of the ideas presented in the paper look like plans for the future rather than accomplished facts. For example, in Section 4, authors say that "The objective is to 393 develop a computer system", seemingly indicating that the system has not been built yet. Similarly, in Section 3, the repeated use of "would" seems to indicate that this is just an idea rather than a result. I suggest the authors to be more explicit about what has been done and what is a plan for the future.
Sorry, we didn't explain it well. The ontology and the software framework are being developed and integrated in two large projects. We have improved the quality of the English in this paper
Comment >>
Finally, and probably the biggest issue, is that the paper does not show the proposed solution. I cannot find a comprehensive description of STEVO. A paper proposing an ontology should at least show a list of concepts, attributes and associations, and/or a diagram. This paper has neither.
You're right, we don't include these aspects in the paper to reduce the number of pages. The STEVO ontology is large. We cited a phd that explains it in detail, but it is in Spanish. We also cited a Gihub repository with documentation in English detailing the design process.
However, in this version of the paper we have included a diagram and a list of the main concepts and relationships.
Reviewer 2 Report
SUMMARY
The paper proposes the use of an ontology to formalize the visualization of cultural heritage data, considering its unique characteristics such as uncertainty, spatial and temporal granularity, and relationships between data. A platform is also developed for visualizing this information through a web application, and its use is evaluated in projects such as SILKNOW and Arxiu Valencià del Disseny.
COMMENTS
This paper is generally very well written and easy to read.
I also found the paper very interesting and the proposed approach has its merits. Indeed, it presents a substantial contribution on top of previously published papers and developed research projects, both in terms of the techniques used to represent data and the evaluation of the developed platform.
The architectural contribution is important from an experience perspective. In the sense, that it corroborates what previous works have advocated in the ontology-driven software development community for many years, that is, making ontologies central to the development and visualization process.
However, there are some issues that require clarification and elaboration in the paper:
To begin with, it is not evident how the information from the STEVO ontology is utilized to create the interactive maps illustrated in Figure 8. Given that the paper's main contribution is the model-based formalization of visualization information, it is crucial to explain the role of the model in producing the visualizations shown in Figure 8.
Furthermore, the authors should provide a summary of the main results from the System Usability Scale (SUS) evaluation for the SILKNOW and Product Map visualization tools.
In addition, the paper would benefit from a discussion on interactive visualization systems in the cultural heritage field that portray the relationships between cultural heritage objects. For example, works such as 10.14236/ewic/EVA2010.10, which employs graphs to visualize metadata relationships, and 10.1145/2254556.2254658, which utilizes graphs and color rings to depict ontology metadata relationships, should be discussed.
Moreover, the paper lacks adequate citations to pertinent sources that display the current state of the art and identify gaps that need to be filled. For instance, ontologies have been extensively used for digital restoration and preservation in projects such as SYNAT and IndianaMas. Hence, it would be valuable to explore how the proposed ontology-based approach can be integrated within digital libraries.
Additional comments:
Line 54: “Additionally, cultural heritage data are associated with two characteristics on which have been little studied: uncertainty and granularity variation, both in space and time. “
could be rewritten in
“Additionally, two characteristics related to cultural heritage data that have received limited attention in research are uncertainty and granularity variation, both in space and time.”
Line 63: “can be quite different between different domain data” -> “can vary significantly among different domain data”
The caption of Figure 1 is not clear. In particular, the description is too long and does not clearly explain what is shown in (a) and what in (b).
SEMAP projet -> SEMAP project
Line 93: “the content the ontology” > “the content of the ontology”
Line 287: “Figure 4 shows a schematic that” -> “Figure 4 shows a schematic diagram that”
Line 372: “in 2 and three dimensions” -> “in two and three dimensions”
Line 375: “architecture. Where” -> “architecture, where”
Line 383: “According to several works,” which ones? Please add some reference.
It is not clear how Figure 6(a) represents uncertainty
Line 387: Assesment
Figure 7 should be translated in English.
Line 401: Gthub
Line 438: Usabiity
Line 441: Figure 9 is not explained.
The English language proficiency in the paper needs improvement, as some sentences are convoluted and difficult to comprehend.
Author Response
Comment >>
It is crucial to explain the role of the model in producing the visualizations shown in Figure 8.
We think the same and apologise for not explaining it properly. The authors work in the paper to clarify this issue.
We try to summarise it here and hope that we have explained it better in the paper this time.
The software framework processes the ontology to know the type of scene (dynamic map, a 3D space, a plane, a 2D/3D axis, etc.), the types of objects to be represented (pictures, textiles, etc.), and the properties to be considered in the visualisation (painter, material, etc.) Then the framework maps the concepts and their properties with the data domain, thanks to the mapping specification instanced in the ontology.
Once it is clear what is to be visualised and how, the software processes the URIs to be visualised (a parameter that could be a list of URIs or queries to be executed) and distributes the data in the internal structure of the visualisation component. The data is then displayed on the scene.internal structure of the visualization component. Then, display the data on the scene.
Comment >>
The authors should provide a summary of the main results from the System Usability Scale (SUS) evaluation for the SILKNOW and Product Map visualization tools.
Yes, you are right, but the paper is long and there are two SUS tests. The first one is published in the SILKNOW deliverable, which is referenced in the paper, and the other one is part of a paper from the Arxiu Valencia de Disseny, which is still under review and we cannot reference it.
We didn't write the details so as not to extend the length of the paper, but we do write the score and a short description of the tests that were carried out.
Comment >>
In addition, the paper would benefit from a discussion on interactive visualization systems in the cultural heritage field that portray the relationships between cultural heritage objects.
Yes, you are right again. We know the first paper, but not the second, and the same with the IndianaMas project. We have read the papers and we have linked the content of the papers to our work. Thank you for the references, they are very interesting.
Comment >>
English language proeficiency.
Thank you very much for your comments, we have improved the quality of the English in the paper.
Anyway, we have considered your comments and made the changes you suggested.
Reviewer 3 Report
This interesting paper introduces an ontology that represents a visualisation model based on other created models (i.e. VUMO and VISO). The proposed ontology called STEVO have been incorporated and evaluated in the SILKNOW and L'Arxiu Valencià del Disseny (AVD) projects.
The article has a relatively good structure, but there are still a number of flaws. In particular, I would have liked a clearer abstract of what the problem is, the objectives of the work and the results. The introduction needs rewording because one cannot easily understand the purpose of the article. I would suggest a clearer structure: problem statement, the aims and scopes of the paper and the structure of the paper. All other information should be transferred in previous work section. In some cases, there is no connection between the paragraphs.
In general, English language needs revision because the text is hard to follow. Smaller sentences and consistency in terminology.
The numbering of sections should be revised. There are two “3 sections”.
Major revisions in English language.
The biggest part of the paper needs rephrase.
The structure should be more coherent.
Author Response
Comment>>
The article has a relatively good structure, but there are still a number of flaws. In particular, I would have liked a clearer abstract of what the problem is, the objectives of the work and the results. The introduction needs rewording because one cannot easily understand the purpose of the article. I would suggest a clearer structure: problem statement, the aims and scopes of the paper and the structure of the paper. All other information should be transferred in previous work section. In some cases, there is no connection between the paragraphs.
In general, English language needs revision because the text is hard to follow. Smaller sentences and consistency in terminology.
We apologise for any inconvenience.
We have greatly improved the English quality in this new version of the paper.
We have also changed the abstract and the introduction in order to generate a better content in these points.
We have noticed some mistakes, such as the number of sections, and are changing them.
Thank you very much again.
Reviewer 4 Report
The paper is about the ontological support of visualisations for cultural heritage knowledge graphs.
The first section introduces some visualisation problems related to CH data. Section 2 provides the related work in this area. Two sections are numbered with 3, the first one highlights some issues of the visualization model. However, I miss the overview of the structure of the ontology, and some examples stressing the key capabilities and decisions made for the ontology.
The next section is about implementation. It is positive that the ontology is on GitHub, but the documentation of the ontology is in Spanish, so again the reader cannot get an overall view of Stevo. Figure 7 text is Spanish.
The section on assessment describes how Stevo has been applied successfully in two CH projects. The implemented visualization tools have been evaluated using SUS, which is an evaluation methodology for usability and user interfaces. It cannot say anything about the usability, usefulness and semantic correctness of the ontology.
The planned future tasks are very relevant, and altogether a very useful toolset is presented based on a new ontology called Stevo. However, it is unclear when the authors speak in general and when about applied solutions in Stevo. Is really hard to see the role of Stevo in the presented solutions and the benefits of using Stevo compared to other visualisation description techniques. I think a running example to explain Stevo features could make the paper much more informative. Overall, I feel the some sections are too long, while important details are missing or very shortly covered in the paper. The balance and structure in the line of the story could be improved.
There are many grammatical errors in the text.
Author Response
Comment>>
The first section introduces some visualisation problems related to CH data. Section 2 provides the related work in this area. Two sections are numbered with 3, the first one highlights some issues of the visualization model. However, I miss the overview of the structure of the ontology, and some examples stressing the key capabilities and decisions made for the ontology.
You're right, we don't include these aspects in the paper to reduce the number of pages. The STEVO ontology is large. We cited a doctoral thesis that explains it in detail, but it is in Spanish. We also cited a Gihub repository with documentation in English detailing the design process.
However, in this version of the paper we have included a diagram and a list of the main concepts and relationships.
Comment >>
The next section is about implementation. It is positive that the ontology is on GitHub, but the documentation of the ontology is in Spanish, so again the reader cannot get an overall view of Stevo. Figure 7 text is Spanish.
We have added an English translation version to the Gihub. Thank you for your suggestion.
Comment >>
The section on assessment describes how Stevo has been applied successfully in two CH projects. The implemented visualization tools have been evaluated using SUS, which is an evaluation methodology for usability and user interfaces. It cannot say anything about the usability, usefulness and semantic correctness of the ontology.
Yes, you're right, we didn't include it in order to reduce the length of the paper, but also because we didn't work too much in this area, only in the correction of the ontology. It is an area that we need to improve.
Comment>>
The planned future tasks are very relevant, and altogether a very useful toolset is presented based on a new ontology called Stevo. However, it is unclear when the authors speak in general and when about applied solutions in Stevo. Is really hard to see the role of Stevo in the presented solutions and the benefits of using Stevo compared to other visualisation description techniques.
Sorry, we are changing the text throughout the document to clarify this.
Sorry again, we are adding new text to the discussion section to fix this.
Comment >>
I think a running example to explain Stevo features could make the paper much more informative. Overall, I feel the some sections are too long, while important details are missing or very shortly covered in the paper. The balance and structure in the line of the story could be improved.
In this version of the paper, we have included a link to a video with a running example.
https://youtu.be/GM5cDWv-P0k
Round 2
Reviewer 1 Report
Many thanks for addressing my concerns. I think that the paper is much improved in this version, and I amhappy to recommend it for publication.
Author Response
Thank you.
Reviewer 2 Report
All issues have been solved.
Please fix the following typos:
Two dots in line 464
Line 557: Wordl -> World
Line 581: base don -> based on
Whilst the content is clear, the standard of English needs to be improved throughout , the manuscript would benefit from a thorough.
Author Response
Thank you for your suggestions.
In the short time we have had, we have improved the English of the studio again, but not with a professional review.
Reviewer 3 Report
The authors implemented the majority of the comments mentioned.
However, I still think that the introduction should be more concise and targeted. A lot of information mentioned should be given in the related work.
But if the information helps the authors for their argumentation, let them leave the text like that.
A minor revision of the english language is necessary.
Author Response
Thank you for your comments.
We agree that the introduction could be more concise. However, as the study works with very different research areas, we think it is worthwhile to explain the connections between them in order to better understand the publication.
If we wrote a more concise introduction, we would probably have to include some additional sections, which would make the article longer.
So we prefer to leave it as it is.
We have further revised the English, but not in depth due to time constraints.
Reviewer 4 Report
The paper has improved a lot, and only a few minor remarks remained on my side.
Fig. 7. does not fit well to the page. Also it is not clear what line colours mean. My suggestion would be to differentiate only the subclass and object property relations in a colour-independent way.
What is the meaning of Domain concept? Is it a taxonomy of various data domains?
Why is an emoty section on Patents is needed?
Some typos detected:
line 264: explining -> explaining
line 415: schematic of -> schema of
Author Response
Thank you for your suggestions.
Comment >> Fig. 7. does not fit well to the page. Also it is not clear what line colours mean. My suggestion would be to differentiate only the subclass and object property relations in a colour-independent way.
You are right about Figure 7. In this version we have drawn the is-a relationships with solid lines and the rest with dashed lines. We have commented on this in the description of the figure.
Comment >> What is the meaning of Domain concept? Is it a taxonomy of various data domains?
The "domain concept" represents a data domain concept that is associated with a VisualConcept of STEVO.
This is not only the URI concept, it has property relations (e.g. to define its temporal and spatial environment).
For example, a VisualConcept in SILKNOW is a "Textile" (An object that the end user see in the scene), but it is related to the "E22-Man_made_Object". The E_22_Man_Made_Object instances in the SILKNOW KG use a time environment that uses years as a time unit reference, but in the scene the textile uses a time environment that uses centuries as a time unit reference.
In the first case the VisualProperty instance is related to an rdf:property of the object, in the second case it is related to the data domain with a sparql query to get the string with the name of the material.
But in the scene there could be many VisualConcepts and each one could be mapped to concepts from different DataDomains.
I hope I understand the question and have explained it satisfactorily.
Comment >> Why is an emoty section on Patents is needed?
Sorry for the Patents section. It was a missundertanding with the sections of the journal template. We have removed it, and write "Funding", and "Conflicts of Interest" sections.
Comment >>Some typos detected:
line 264: explining -> explaining
line 415: schematic of -> schema of
Thank you for the typos, we have corrected them. We also have improve the english.
