Review Comment:
The manuscript entitled “Data Sharing in Agricultural Supply Chains: Using semantics to enable sustainable food systems” describes work performed as part of the Ploutos Project to create and implement a semantic framework to enable greater interoperability between agricultural and other food system platforms and databases. The Project has resulted in the development of a new application ontology that provides new ontological classes/terms and integrates a number of existing agriculture/environment/sensor domain ontologies based on RDF and OWL, as well as tools based on the ontology framework to enable translation between service/platform-specific languages so that users can query information across a spectrum of (until now) disparate data collection and integration platforms. This work was performed to enable traceability of food products and information about their production, and has potential in a wide number of areas such as sustainable development.
Originality
I think that the work described in this manuscript is of interest as it brings to the forefront the real challenges of integrating different types of data that are often ignored and assumed to be a minor problem/fact of life in industry, and also helps to showcase the power of ontologies. The authors state in the paper that until now food/Ag related ontologies have largely been used to annotate research data (which is not strictly true as ontologies like FoodOn are being used to standardize and enhance pathogen surveillance data in real world public health and food safety surveillance networks and investigations but that is a minor point) and have not been used to integrate data in more powerful ways. This is very true. There are reasons for why this has largely been the case, but the fact remains that in the semantics world, particularly in the food semantics world, we lack good examples of the types of transformative things you can do with ontologies that can entice uptake in the community where it is sorely needed (they just don’t know it yet because we lack good “before” and “after” implementation stories).
Significance of the results
This paper could be of great interest to a range of audiences, including the agricultural, semantics, and the software development communities. Because of that, the story should be told in a direct way that clearly describes and separates what was done from what is needed/what is the vision. A lot of time and writing real estate is currently spent setting up the vision and what is needed, and that confounds the expectations of the reader. Also, starting by laying out the semantic framework bogs the reader down in heavy details so that the implementation near the end is likely to be skimmed over, which is a great disservice to your work. It’s like telling me how a magic trick is going to be performed before you do it, so that when you actually show me the trick, I’ve lost interest because the magic is gone.
Quality of Writing
The authors are clearly skilled in writing, but I feel like the story could be better structured to engage the reader. To this end, I have a number of suggestions to better improve the flow and readability.
1. The “magic” of Ploutos is in its ability to transform and integrate data across multiple disparate platforms, and to enable users to query it. Start with that idea. Start with what you’ve actually built (a framework for translating data between different existing databases and platforms) which has been applied in a proof-of-concept study but that will be expanded to achieve a wider vision in the future. Then describe the needs assessment that you did (where you have the other use cases), then describe the platform architecture in more detail, then the semantic framework to achieve this transformational capacity. The other stuff about the principles, access controls and the data governance (users have control over their data), is that actually implemented yet? It was not clear to me from the peaches example that that is in place. So that should probably go into future work in the discussion where you can expand on what is needed. If I’m wrong, you should work that into the implementation description in the beginning e.g. what information can different users differentially access regarding the peaches?
2. You give a list of questions that highlight user needs. It would be helpful to show and explain why those questions can’t be directly answered right now (which is why you needed to build the ontological framework). Provide a diagram based on the peaches example that highlights the points where the data gets stuck. Figures 13 and 14 almost serve this purpose. Can you walk us through one of the questions and show us how Ploutos (via the transformation enablers and the knowledge mappers) enables users to get answers where previously it was difficult or it couldn’t be done? You do that in a complicated way in the text and provide conceptual diagrams in Fig 13 and 14. Could you put the query and the answers (in simple terms) on Figs 13 and 14? I think it’s just a matter of more clearly spelling out for the reader where the blockages were before, and where Ploutos provides bridges to get the user from the question to the answer using a specific example.
3. You did not create Alterra and GaiaSense, correct? It would help if you briefly described what these things were and what they visualize/analyze and clearly state that currently they are separate platforms/databases so a user can’t seamlessly connect their data/services. The Gaiasense dashboard in Fig 11 is generated by that platform right, not Ploutos? But Ploutos offers Gaiasense dashboards?
4. The manuscript is quite long. Can sections be cut down/removed e.g. Table 4? It seems highly general and not directly pertinent to what was actually built.
Regarding the Ploutos ontological framework:
1. It’s not clear to me how big the Ploutos ontological framework is. Can you provide a number of the classes and relationships?
2. You provide process diagrams for different data integration/transformation examples, but could you provide a list or diagram spelling out what types of vocabulary are currently available (distinct from what could be included to address the other use cases)? For example, you mention things like agricultural/supply chain certifications, is there vocabulary in Ploutos right now for structuring that information or is that on the to-do list?
3. You mention that EnvO richly describes their terminology (as that is part of the OBO Foundry best practices - to provide definitions and unique IDs for all the classes, subclasses, and instances). Can you describe if you provide definitions for all the “concepts” contained in your OWL file and how people can go about requesting the integration of new services into the Ploutos framework?
4. Do you have plans to integrate parts of any other OBO Foundry ontologies that might align with Ploutos use cases e.g. you mention FoodOn, AgrO, and there could be others like Uberon (for anatomical parts of animals) etc.? Can you mention this in the text?
5. OBO Foundry ontologies share a common upper level ontology (everything is basically classified as a thing, a process or a quality/property). Does this not cause logical errors with your upper level ontology (Part, Observation, Property)?
Accompanying Data File
https://gitlab.com/Ploutos-project/
The ontological framework does not appear to have a README or Wiki which makes it difficult for a user to navigate and assess. There is a traceability demo that has a very basic README that could benefit from more details. A docker image of the software is provided. Little else is provided regarding actual code. Because of this, I can’t say if the provided resources are complete or could be used to replicate the peaches implementation. I don’t see information about the API for example, or the Registry. GitLab is sufficient for long-term discoverability.
Taken together, I think this is an interesting project deserving of discussion within the community, and publication providing what work has been completed vs the potential of the Ploutos framework has been more clearly articulated, and more supporting documentation is provided in GitLab.
|