RePlanIT Ontology for FAIR Digital Product Passports of ICT: Laptops and Data Servers

Although I confirm my positive impression about the paper, I am frankly a bit disappointed by the replies to my comments which, in my opinion, have been treated all as minor points, but this is definitely not always the case. Most of them have not been addressed at all, which is a pity, as they could be useful to improve the quality of the paper.

The first comment is a clear example of what I am saying: my point was that, if one decides to use very general terms in the vocabulary, these can be intended in many different ways, so their interpretation should be constrained. Otherwise, if one keeps the ambiguity, the result is that the ontology is reusable but not interoperable, the worst possible case, as it could be misinterpreted but anyhow reused, bringing with it errors and misuses. My suggestion, which is still valid in my opinion, is to explain such terms by leveraging top level ontologies, or at least, specific core ontologies. I do not think it is enough to motivate the use of a term based on the fact that it belongs to an ontology that has been successfully (…) used in past projects.

My second comment was not aimed at having exemplifications of the concepts, but (at least concise) definitions. I do believe that a reader of the paper should be put in the position of understanding what the ontology is about without looking at the documentation, at least to decide whether to use the ontology for their purposes or not.

I find also the answer to my comment on MaterialRecyclability unsatisfactory: I believe that, when building an ontology, one should draw classes and relations as general as possible to be applied to different variants within the same domain. So, I don’t understand how the fact that the use cases at hand were simple enough to be qualified with a Boolean is enough not to build the property in a way as to make it applicable to more complex cases, which are the majority. Still, I don’t understand how you may judge a laptop (what you mentioned as use case) as either recyclable or not, as it was not a composite object.

Also unsatisfactory is the answer to my comment about the class Reason. My question is: what is reason ontologically? I don’t think that the two lines of text that have been added answer the question.

Again, I don’t think it is acceptable that the frameworks consider just activities that are relevant for the use cases, as it is not good practice to “extend” the concept, as the authors suggest: I believe they should proceed the other way around (in order to gain interoperability), first build the general concept and then specify it until having a granularity which is tailored on the use cases.

Finally, though I hadn’t spotted the issue in my previous review, I agree with the other two referees that the centrality given to the FAIR approach in the title cannot then be found in the text, so I also believe that the paper needs a new, more adequate title.

The authors have properly addressed most of the reviewers' comments. I'd like to highlight a couple that have been answered in the rebuttal but I believe should be addressed in the paper.
My previous review comment: page 7, line 39 (now line 36). Serial number and model are mentioned as device characteristics that change over their lifetime. I was curious about examples of devices that change their serial numbers or their models after they are build.
Answer: Here we discuss devices that are components of other devices. For example, a laptop’s camera or any sensor in it. If a laptop’s light or temperature sensor is faulty it can be replaced via repair, refurbishment etc. In such cases, a sensor of a different brand and model can be selected. It will have a different serial number as well.
I completely agree with the answer, that components in a computer can be exchanged and the computer remains the same entity. However, the text and Figure 3 define that the class ICT Device has serial number and model properties (among others), and has a relation hasComponent with the class Hardware Component. From the answer to the review comment, I can understand that the authors mean that the replaceable parts (sensors, camera, etc) are subclasses of the class Hardware Component. Nowhere in the text nor on the diagrams the class Hardware Component has properties such as serial number or model. Therefore, the question about the mutability of a serial number or model for an ICT Device remains.

My previous review comment: page 5, line 39, the authors state that “ For consistency, an "isA" relationship was followed when defining classes and their sub-classes.”. However, in the diagrams, the predicate rdfs:subclassOf is used instead. By the way, commonly, predicate names have the first letter in lower case.
Answer: We have used “isA” relationship only as a guideline when defining classes and subclasses before the actual ontology implementation. This helped as we collaborated with domain experts who did not have experience in ontology engineering. We have “translated” the “isA” relationship to the more formal “rdfs:subclassOf”. We hope this clarifies.
The answer is fine and does clarify for me. However, a reader of the paper, who does not have access to the rebuttal document would still be puzzled with the inconsistency between the text and the diagrams. I suggest to either adjust the text to simply mention rdfs:subClassOf or include this explanation.

Figure 3: I assume that the relation between ICT Device and Data Server, dogont:Computer and Switch is rdfs:subClassOf, correct? If so, I suggest to add the relation label to the diagram.

The authors have addressed my concerns in this new version of the manuscript.