Review Comment:
In this study, the author aims to solve the integration of various computational models (optimization and simulation) exposed as services using web-based technologies. They address the automatic discoverability, orchestration, and invocation of such computational models as services as part of distributed semantic queries. Regarding discoverability, authors used hypermedia API to increase the FAIRness, for orchestration, authors adopted a pragmatic proof algorithm, and for invocation, authors used various web tools for federation. With a lofty goal, the authors have put a considerable amount of effort into providing a proof of concept with a substantial volume of comparative analysis and discussion on various concerns related to their proposed solution. Most impressive is the FAIR and lose coupling analysis (Although done without any consensus from the community). However, the structure and writing style makes the article hard to read. Below, I point to the ways the readability of the paper may be improved:
I. The paper uses many web tools, protocols, and principles in their implementation and therefore refers to them with some abbreviation frequently throughout the paper. It will be easier to read the paper if a glossary of these terms is given at the beginning of the paper.
II. The authors combined the methodology and implementation in a single section (3). Therefore, the technical solutions hinder the understanding of the overall methodology and system architecture. A separate methodology section with generic system diagrams (e.g., functional modules, activity diagram, flowchart) in standard UML (or SysML, BPMN if preferred) will help in understanding the overall system before going into technologies for realizing such a system.
III. Where not necessary, it is better to use the generic term of the component instead of the name of a particular technology that implements it. E.g., service metadata instead of RESTdesc, service instead of hypermedia APIs. These technologies need to be contained in a separate implementation section instead of being scattered around the entire paper.
IV. Most importantly, the authors aimed to tackle multiple problems in a single system including FAIRness of M&S, automatic discovery, and orchestration, as well as federated service/query execution to ensure loose coupling. The paper however narrates the system in a way that it becomes difficult to identify what component does what.
Furthermore, the following list mentions many issues which require resolution.
1) In abstract: “systems of systems” -> “system of systems”
2) “Therefore, it is desirable to increase the FAIRness (Findability, Accessibility, Interoperability, and Reuse) of M&S capabilities; to enable their use in loosely coupled systems of systems; and to support their use by intelligent software agents.” – The abstract does not mention the goal completely as increasing FAIRness is one of the goals of the authors as they included service composition and loose coupling in the research questions.
3) “models allow inferring new information based on what is already known by means of reasoning” – the paper refers to different entities as a model, e.g., model of data (e.g., ontology), computational model (e.g., simulation), system (e.g., the proposed solution). They need to be distinguished.
4) “Ontologies encode concepts, roles, and their interrelations based on Description Logics (DL); computational reasoning is the process by which satisfiability, classification, axiom entailment, instance retrieval et cetera are computed.” – the paper starts with ontology whereas ontology is one of the tools used in a larger system that is proposed. Ontology is not the goal of the paper. Also, not all ontologies are based on DL.
5) “As a consequence of this formalization, a limit in scope and expressivity and therefore a limit on the class of problems that can be solved using a certain language, including its ecosystem such as model libraries, Integrated Development Environments (IDEs) and expert communities, is imposed.” – not understood how formalization may cause a problem in scope and expressivity. They may be caused by the choice of language by developers but it is not to blame on the formalization. For example, an ontology written in full first-order logic is more expressive than OWL.
6) “…this raises the question of whether two distinct modelling approaches and the corresponding ecosystems can be meaningfully combined in order to enlarge the class of problems that can be investigated” – If authors mean Web Ontology Language (OWL) for ontologies or Modelica for DAE are two distinct modelling languages, then it is required to be noted that they are for different purposes not different approaches for the same purpose. Also, it is not known what the authors mean by “class of problem”, is it complexity class? Problems for different domains? Problem types?
7) “we focus on dynamic models for the time-varying behaviour of quantities in technical, multi-domain systems that can be represented as a system of DAEs … Other uses of the terms Modelling and Simulation are equally valid in their respective contexts, but out of scope for this work.” – It is not clearly understood how the methodology and application are only specific to this type of models and not others.
8) “a set of conceptual resources such as “today’s air temperature on campus” – What is a resource here? Air temperature or campus? If Air temperature, why it is a resource? If “resource” is used here as a concept from REST community, this needs to be mentioned.
9) Please provide a table comparing HTTP, REST-API, and Hypermedia-API
10) “…which is neither RESTful (even though such APIs often denote themselves as such)…” – please justify such opinion.
11) “For realizing software that exposes M&S capabilities FAIRly, it is desirable to support loose coupling” – it is not explained what the relationship or dependence between FAIRness and loose- coupling is.
12) “What are generic or intelligent software agents, though?” --> “What are generic or intelligent software agents?”
13) “Therefore, the PPA can be seen as an intelligent software agent.” – it is not fully justified why PPA is selected for service composition.
14) “We see hypermedia APIs, as an exemplary specific interface to RDF data,…” – Why hypermedia API is exemplary specific to RDF data? What is the relation?
15) “…machine-actionability of capabilities…” – this phrase is not ambiguous; needs clarification.
16) H3 and H4: “Researchers and software engineers can use…” These research questions cannot be evaluated without a survey. No such survey is presented in the paper.
17) “…using any RESTdesc-enabled hypermedia API…” RESTdesc is not defined before that.
18) “…methodological and referential ontologies…” – this is not a standard distinction and comes from Hoffman’s conceptualization. I think methodological are upper level and referential are domain-level ontologies. This needs to be clarified.
19) “OSLC has a strong focus on human end-users, as for example shown through the ‘resource preview’ [18] and ‘delegated dialogs’ [19] features” – why this is relevant to the topic of discussion.
20) “The creation of the links that encode this trace, facilitated through delegated dialogs and resource preview, is identified as the functionality implemented most [20, tbl. 7, p. 25].” – incomplete sentence. Please rephrase for clarity.
21) “Second, these descriptions should be generated automatically as far as possible, starting from the FMUs used” – It is not understood how they are automatically generated. Do authors mean translating the model description in RDF format?
22) “…developed ontologies in combination with established ones needs to be implemented” – What are the established ones?
23) Ontology based metadata for services such as Web Service Modeling Ontology (WSMO), Semantic Web Service Language (SWSO), and OWL-S need to be included as part of SoTA. The developed ontology may reuse many parts of them.
24) There are many problems with the ontology models proposed. E.g., if a System is a ClassOfSystem then every specific System also represents the entire group of similar systems. My bicycle does not represent all the bicycles.
25) “Fig. 2. The implementation is structured in distinct API- and worker components which exchange data via queues; a reverse proxy provides a HTTPS connection to users. An instance of https://github.com/LinkedDataFragments/Server.js enables querying (proxied through the API)” – a technology-neutral system architecture will explain the proposed system better (please see II).
26) “…an <#about>-graph is created that is explicitly linked…” – what is <#about>-graph?
27) “…of the Hydra core vocabulary [37] in lines 30 to 32.” – Why is Hydra vocabulary used? Is it standard for hypermedia API?
28) “Several advantages of the TPF interface have been observed [39, p. 203]: a reduced load on the server; better support for more clients sending requests simultaneously; and increased potential for benefiting from HTTP caches…. Moreover, TPFs are compliant with REST and thus well suited for integration into a hypermedia API.” – Such justifications for the choice of a particular technology are useful and needed for all sorts of technological choices. However, instead of scattering them in the text, these justifications should be presented in a separate section under implementation.
29) “The PPA is visualized in Figure 3. It can be summarized as follows:” – It is not required to describe the algorithm if directly adopted from Verborgh et al. [14, p. 34]. Referring to the original description is enough. Only the improvement part needs to be mentioned.
30) It is necessary to justify the choice of PPA over many other similar algorithms from Answer Set Programming which also need to be included in SoTA.
31) Goal state, Initial state, and resolution paths need to be described more rigorously.
32) “goal state g shown in Listing 3” – listing 3 is a rule with the same body and head. How can it describe a state (preferably a fact)? Why the rule has the same body and head as such rule will not change anything in the KG?
33) “…the RESTdesc descriptions can be obtained through an OPTIONS * request, this means that only knowledge of RESTdesc, RDF and HTTP are assumed and any hypermedia API using these technologies can be used for achieving goals without programming.” – It needs to be clarified that the RESTdesc needs to be coded by somebody, especially the shapes in the OPTIONS.
34) “…precondition in Listing 2 is now met and, as a consequence, the request fully specified.” – The listing 2 is part of the methodology/implementation. This is another example of mixing up the structure. Similar to the suggestion in II, that methodology needs to be separated from implementation, the application also needs to be separated from implementation.
35) “Furthermore, no static service interface description is needed” – What do the authors refer to by static service interface?
36) “Since the M&S hypermedia API only exposes a TPF endpoint…” – this is due to the author’s implementation choice, they do not necessarily only exposes the TPF endpoint.
37) “The ability to execute SPARQL requests against the M&S hypermedia API makes it a source of linked data which can be used in applications or to build KGs. However, these applications should consider that resources do not necessarily exist forever, either because they expire or because they are deleted by a user. These considerations are out of scope here, though.” – This paragraph is not well written, please improve clarity.
|