Data Sharing in Agricultural Supply Chains: Using semantics to enable sustainable food systems

The authors have done a tremendous job incorporating the reviewer feedback into the manuscript. It reads extremely well, is well organized, and highlights the semantic and technological innovations of the Ploutos project in a clear and concise manner. The reuse of other ontologies is much clearer and the worked example is fabulous. The GitLab documentation also seems more thorough. I greatly enjoyed reading this version and recommend the publication of this work. Well done!

This review is in response to Review #1 from the previous revision. It assesses whether or not all comments from that reviewer have been adequately addressed.

I find that authors have done an excellent job at responding to each remark and find no other cause for content revisions at this time.

Data has been appropriately shared via a persistent/archival link; it does not seem to have obvious licensing.

I have some suggestions regarding figures:

* Figure 5 would be better slightly enlarged (font size is still quite small).
* Figure 11 should probably be moved to [t] instead of under the footnote

Finally, I believe that SWJ has transitioned to a two-column format, but you will receive such direction from the typesetter.

This work reports a data sharing architecture in agricultural supply chain where actors control and access their own data. The proposed architecture is supported by a semantic framework. The underlying problem addressed by this paper is a challenging one since there are multiple, heterogeneous actors in ag supply chains with varying levels of technological sophistication and IT infrastructures and resources. The paper is well motivated and structured. One valuable contribution of this work is that it is based on real use cases supported real datasets. Other widely used ontologies (such as ENVO, SSN, SOSA) are reused appropriately. The ontologies and related sparql queries are publicly available on gitlab repos that are appropriate for long-term repository discoverability. The provided data artifacts are complete well. The validation step is credible and useful.

A few comments about the ontology (ploutos.ttl):
-The ontology is not sufficiently axiomatized. This may limit its formality and reusability.
-The ontology can use better annotation. Providing natural language definition for classes makes the intended meaning more clear. Currently only rdfs:comment is used to provide clarification on some classes. However, those comments are themselves misleading and ambiguous in some cases. For example, the class Product Operation includes a comments : "An operation on a product where it changes in a meaningful way, e.g., packaging". What do you mean by "meaningful way"? Is a change in the physical properties of the product considered to be meaningful change or you are referring to some other types of changes?
-The class PART is problematic. It is indicated that it is a 'model-technical' term that domain experts should ignore. In general mixing model-technical terms and domain terms in an ontology is not a good idea since it can confuse the users. Also, from an ontological perspective, it is not clear why this class is needed. If this class is supposed to be treated a 'defined' class that is only added for ontological convenience (for example to make queries simpler), then 'necessary and sufficient' conditions must be provided. Sub-classing entities such as Soil, Farm, Corp under Part is semantically not sound. An instance of Farm can be classified by the reasoner as an instance of Part only if the appropriate Equivalence axiom is provided.

- There are some classes that are duplicates of imported classes (such as Farm). Is there any reason for this duplication?

-Not clear how Farm can be a sub-class of Agent. How do you define Agent?

-If Cutting Operation is a sub-class of Product Operation, then any cutting operation on items that are not finished products (such as raw material or semi-finished products) cannot be considered as an instance of Cutting Operation. This seems to be too restrictive. Again, the recommendation is to treat "Product Operation" as a defined class with no explicit sub-classes.