A Semantic Approach to Reducing GHG Emissions

I would like to thank the authors for their response to the review comments and for the additional content added to the paper.

However, after reviewing the proposed changes I still remain unconvinced by the research contributions presented in this article - what are the research questions? The work, in my opinion, now even more resembles an application or resource paper rather than a research paper.

More specifically, applying bridge ontology is not a novel idea and as I note later in my comments I have some questions regarding the quality of the resource. the integration of geographical information that relies on the use of owl:sameAs also seems straight forward. Even for more difficult tasks such as matching of unusual location names (e.g., RER w/o CH & DE) there are no mentions of innovative approach to automate this task.

On the other hand, the challenge of comparing different assessement standard presented in the section 5 and 6.2 has a potential for novel contribution if (semi)automated, however, as authors noted what they describe is only a first step towards achieving this goal. I have not been able to find the mentioned category mappings nor any of the scripts for data conversions mentioned in the section. Overall, in my opinion, the descriptions lack required detail and thorough evaluation.

The online resources on Github have also not been improved. For example, https://purl.org/wiser# or https://purl.org/wiser/ will not resolve, there is no human readable documentation, wiser concepts don’t have labels or comments, location of the individual ontologies is poorly signposted from the paper, etc.

Mor edetailed comments:

re: subclassing pattern
lines 40 - 42 page 4 and lines 1-3 page 5: the description mentions that this pattern is used when classes are conceptually identical. Further clarification is needed why A ≡ B relationship is not sufficient/suitable. If I am not mistaken (looking at the epic:Unit example in [16] which details how to create bridge ontologies) a subclassing pattern would be defined in an opposite direction - i.e. BActivity is a subclass of ilcd:DatasetInformationType and ecoSpold:TActivity.

What is the rationale for the intermediary properties like wiser:ilcdbGeography. Are these used for any specific purpose an is it important to define them as subproperties? The example in Listing 1 only motivates the wiser:bGeography whcih I understand. but is there a reason why we could not just have multiple owl:propertyChainAxiom chains associated with this property directly?

Author state "For cases where the structure of one data format (e.g., ILCD) 5
6 differs fundamentally from another one (e.g., EcoSpold01), making subclassing or property chaining infeasible, ...". This is confusing because EcoSpold01 and ILCD are given as examples of fundamentally different data formats "making subclassing or property chaining infeasible" but they are used in examples of subclassing and property chaining. I think more specific examples are needed.

"We then use SPARQL INSERTs to transform the data to the newly created class structure and store it in our KG." please provide an example as for the previous two cases. currently this paragraph is unclear.

After reading section 3 I still don't understand many things about the bridge ontology such as the coverage, structure, etc. Which of the ontologies in the GitHub repository corresponds to the bridge ontology?

On page 7, it would be helpful to include an example of using the gn:ParentFeature for ranking purposes. Is the simple count of "hops" between parent feature suitable for comparisons at global scale. for example, will it work well for cases where Geonames might have more detailed structure for regional division in one country but not in the other?

In Fig 4: What do the arrows mean? Is it skos:narrower?

The evaluation now contains implementation of the dashboards, however, there don't seem to be any analysis that would support/demonstrate their usefulness. The new material focusing on identifying the success factors is fine, however, in my opinion, it does not evaluate the resources discussed earlier in the paper so now the paper is missing evaluation as the performance based evaluation mentioned int the previous version has been removed. Have the dashboards been by the manufacturing partner? if not, have these been evaluated in any structured way (e.g., interviews, questionnaires, etc.)?

Minor:

Is the second contribution really a "foundational ontology"? the term usually refers to an upper ontology that would modelled concepts at a very high level and would be domain agnostic.

"valid Scope 3 emissions data (i.e., GHG emissions emerging from companies upstream in the company’s value chain)" -> this should be probably e.g. not i.e as Scope 3 emissions can emerge form downstream as well if I am not mistaken.

What is the purpose of footnote 12 - is it menat to be a hyperlink?

spelling
Can equivalent categories be determined across different assessment standards base on activity classifications? base -> based

Thanks to the authors for providing an updated version of the paper, and for providing a detailed response to the reviews in their response letter. However, while the authors have updated many parts of the paper, which makes it much more clear, they have not addressed my two main comments regarding review criteria (1) and (2), i.e. originality and significance of the contribution, respectively. Neither do they reply to these major comments in their response letter, but focus on the minor details instead. Basically, the paper still lacks any significant scientific contribution in my opinion, which is the main motivation for my suggested decision.

Looking more closely at the paper, the authors list 4 contributions at the bottom of page 2. Contributions 1 and 2 are ontologies, and 3 is an application built on top of the ontologies, i.e. while these may be of great practical value they are not scientific contributions. Especially since they seem to be quite standard applications of ontology engineering and semantic applications, although to a new use case. Contribution 4 on the other hand is interesting, but it both appears as an add-on or afterthought in the paper, and is not very well described in the text. For instance, while section 7 is now dedicated to this post-project analysis of methodology, the results are poorly described and I lack a full account of the ranking results of factors. Also, the study is very small, with only 8 participants, divided into two groups of participants treated separately, making it unclear how reliable these results are. Finally, if such a study should make sense, then the paper should be more focused on methodology in general, and the methodology used to develop the ontologies in the first place should be describe din detail, so that this methodology analysis can be related to that.

Overall, my conclusion is that the paper still does not meet the standards of a research paper for the SWJ. My suggestion would be to either (1) transform it into an ontology paper or an application paper (once resources have been sufficiently used outside the project context), or (2) submit this work to another community. In the letter case, the paper could be refocused to more show the opportunities that come with these technologies, which may potentially be considered novel in research areas related to sustainability and environmental reporting. In the former case the authors should notice that for an ontology paper the publishing and documentation of the ontologies need to still be improved. In their response letter the authors claim to have improved this, but I have a hard time to see what has been improved. Namespace URIs in the paper still do not resolve, and while the authors may have added some annotations somewhere in the ontology files, I still see many places without labels and comments. Additionally, no human readable HTML documentation seems to have been published, and theres is a lack of description of the ontology engineering methodology, requirements and testing/evaluation.

This work proposes an approach called WISER to integrate several sources of information regarding assessing greenhouse gas emissions. This proposal consists of a bridge ontology, a description of the process of constructing the dataset, a description of the developed tools, and the experiences of the project.

The problem studied in this paper is relevant. However, the elaboration of the paper is poor, and the solutions are not novel enough. The integration problem is much more complex than what this paper describes. For example, to my understanding, integrating datasets to assess greenhouse gas emissions requires encoding uncertainty on the different measures. I am not saying that the paper should describe how these uncertainties can be combined, but that there are complex issues that this paper omitted.

It may be worth recording the project experiences if the contributions are better explained. However, I do not recommend the paper for publication in this state. Next, I described some issues the authors should fix before the publication.

The related work section does not allow me to understand the contributions regarding the existing solutions. For example, the authors said that the ontology proposed by Zhang et al. [5] is only validated through a case study. This validation may be insufficient, but it does not mean that the ontology is not good enough for the use case that this paper is addressing. The authors should have a good reason not to use the ontology described in [5], but the paper's argument to differentiate from the related work is unclear.

On page 5, the property chaining is described with Turtle syntax, while in the following sections, the ontology is described with description logic notations. Notations should be uniform.

The competency questions in Section 4 are too simple, and the solution is direct. So, this Section can be more succinct. Something similar happens with the competency questions in Section 5. Moreover, the paper never explains how the proposed solutions address the competency questions. Even when it may be evident, the authors should show that the proposed solutions work.

Figures 2 and 3 are difficult to understand because the notation is not described. I guess that diamonds represent instances and circles represent classes. However, the edges do not follow this pattern. For example, the edge with label gn:ParentFeature in the box Geonames ontology of Figure 2 is a relationship between two individuals. On the other hand, a similar edge between classes :BGeography and :BActivity is not a relationship, but states the domain and range of the property :bGeography to be the classes :BGeography and :BActivity, respectively. Then, in the same figure, the property :bGeographyTerms depicts that a class is the domain of the property, and that the "CH" is an example of the range. So, the edge notations are used with different meanings, and not well described.

Figure 4 talks about a transformation between the GHC Protocol and the ISO 14064-1 standard. However, I see no arrows connecting from one box to the other box, so I cannot understand how the transformation works. Also, I do not understand the meaning of the colors used in the different boxes.

Figures 5, 6, and 7 are so small and hardly readable.

Page 3, line 13: It is said: "The knowledge acquisition layer focuses on creating RDF statements from different information sources." Because it said "focuses," it suggests that this layer also does other things. However, these other things are not described. Otherwise, it should be said that "The knowledge acquisition layer creates RDF statements from different information sources."

The first paragraph of Section 4 combines two topics. First, it talks about bridge ontology, and then it talks about an agile approach to ontology engineering. Mixing topics in the same paragraph makes the document difficult to follow.

Page 8, line 4, mentions the "ILCD format." I guess that it intended to mean the ILCD ontology because the figure is illustrating an ontology, instead of a file format.

The paper uses unnecessary acronyms that complicate the reading. For example, DE is defined on page 14 and then twice on page 16. It is really unnecessary to introduce this acronym. It only makes me read back to understand what it means. In another case, the acronym API is defined on page 13, line 43, but used before on page 12, line 14.