Semantic Programming Framework for developing ontology-controlled Applications

The paper addresses the interesting topic of simplifying the visualization and editing of RDF data.
For this reason it introduces SPrO, the Semantic Programming Ontology, and a related Java middleware.

1. It is a bit misleading that the paper introduces SPrO and SCO (Source Code Ontology). At first sight I thought that SCO is some kind of extension of SPrO with additional classes or properties.
But after reading further I discovered that it represents the code model of a specific application in terms of SPrO. Maybe it would be better to just name it "code model" or "application model" instead of using the term Source Code Ontology.
2. The introduction of the topic is very general and mainly only introduces RDF, OWL and related technologies.
Related work is largely missing. At least the following papers and technologies are related to the topic and should be discussed:
Shinavier, Joshua. "Functional Programs as Linked Data." SFSW. 2007.
Rodriguez, Marko A. "The RDF virtual machine." Knowledge-Based Systems 24.6 (2011): 890-903.
Battle, S., Wood, D., Leigh, J., & Ruth, L. (2012, November). The Callimachus project: RDFa as a web template language. In Proceedings of the Third International Conference on Consuming Linked Data-Volume 905 (pp. 1-14). CEUR-WS. org.
Luggen, M., Gschwend, A., Anrig, B., & Cudré-Mauroux, P. (2015). Uduvudu: a Graph-Aware and Adaptive UI Engine for Linked Data. In LDOW@ WWW.
Linked Data Platform https://www.w3.org/TR/ldp/
Fresnel - Display Vocabulary for RDF https://www.w3.org/2005/04/fresnel-info/
RDForms https://rdforms.org
TopBraid Composer Forms (http://www.topbraid.org/2007/01/forms.owl)
3. SPrO seems to be based on the concept of describing the program logic The paper addresses the interesting topic of simplifying the visualization and editing of RDF data.
For this reason it introduces SPrO, the Semantic Programming Ontology, and a related Java middleware.

1. It is a bit misleading that the paper introduces SPrO and SCO (Source Code Ontology). At first sight I thought that SCO is some kind of extension of SPrO with additional classes or properties.
But after reading further I discovered that it represents the code model of a specific application in terms of SPrO. Maybe it would be better to just name it "code model" or "application model" instead of using the term Source Code Ontology.

2. The introduction of the topic is very general and mainly only introduces RDF, OWL and related technologies.
Related work is largely missing. At least the following papers and technologies are related to the topic and should be discussed:

Shinavier, Joshua. "Functional Programs as Linked Data." SFSW. 2007.
Rodriguez, Marko A. "The RDF virtual machine." Knowledge-Based Systems 24.6 (2011): 890-903.
Battle, S., Wood, D., Leigh, J., & Ruth, L. (2012, November). The Callimachus project: RDFa as a web template language. In Proceedings of the Third International Conference on Consuming Linked Data-Volume 905 (pp. 1-14). CEUR-WS. org.
Luggen, M., Gschwend, A., Anrig, B., & Cudré-Mauroux, P. (2015). Uduvudu: a Graph-Aware and Adaptive UI Engine for Linked Data. In LDOW@ WWW.

Linked Data Platform https://www.w3.org/TR/ldp/
Fresnel - Display Vocabulary for RDF https://www.w3.org/2005/04/fresnel-info/
RDForms https://rdforms.org
TopBraid Composer Forms (http://www.topbraid.org/2007/01/forms.owl)

3. SPrO seems to be based on the concept of describing the program logic in the form of an expression tree but no formal definition for the generic structure of an SPrO program is given.
The paper introduces concepts like process definitions, commands/executions steps, subcommands and annotations but gives no clear explanation how these things relate to each other and how they are interpreted when a given process definition is executed.
The paper does also not explain how UI (HTML) widgets are generated from the process definitions and how user interactions occur. There are also no screenshots or mockups of the generated UI.

4. It is unclear how ordering indexes of execution steps are represented. The paper says "Within the application’s SCO, an index is assigned as a value to this annotation property, specifying the position of the corresponding execution step within the particular sequence of execution steps describing a particular process or feature for the application (Fig. 2)." which indicates that the ordering index is just a sortable/numeric value. But, for example, when looking at Fig. 3 it seems that the ordering index is the URI of a complex object that itself has further annotation properties representing attributes and subcommands.

5. Ontology design: I think it is a weak point of the SPrO that it merely defines a list of properties without defining a class hierarchy.
For example, instead of using the property "execution step: application operation" SPrO could also have defined a class 'Operation' with a subclass 'ApplicationOperation' that in turn can have multiple attributes as well as sub-operations as child elements.
Furthermore, the properties defined by SPrO are only introduced by examples and their existence is not justified by any requirements.
It is also unclear what is meant by "(root) entry component" as mentioned in tables 1 to 3.

6. It is unclear how the model for UI components is structured. Is it some kind of hierarchical structure with nested components (panels, text and selection widgets etc.)? How is layouting accomplished?

7. There is no clear description how events are propagated from UI components to the interpreter. It seems that this works using the annotation "execution step trigger" but it is not described in the paper.

Overall, I find the topic of the paper very interesting but the proposed ontology is not very well structured (no classes, no constraints etc.) and the interpretation of the processes described by SPrO is also unclear (execution of commands, generation and composition of UI widgets etc.).
I would suggest restructuring the ontology in that it has a clear separation of concerns between business logic (control flow with if-then-else, loading/saving/deleting of triples etc.), UI components (widgets, component structure, layouts) and events. It would also be helpful to give a (semi-)formal definition how SPrO programs are interpreted (like "The RDF virtual machine.").

This manuscript was submitted as 'full paper' and should be reviewed along the usual dimensions for research contributions which include (1) originality, (2) significance of the results, and (3) quality of writing.

The paper argues that ontologies can be used as a kind of programming language and presents the programming Semantic Programming Ontology (SPrO)framework and related Java-based middleware. The idea is to integrate the RDF world with the HTML world and allow domain experts to develop their own data-centric Semantic Web applications with as little programming experience required as possible.

In section 1 the paper presents an introduction to semantic web recommendations RDF and OWL. This part is very generic and does not really provide new insights.
By SPrO the auhors want to "close the gap between computer-parsable data represented in form of semantic graphs on the one hand and a user-friendly
visualization of data in form of HTML-based data entry forms on the other hand". However, the paper does not make it very clear, what problem is actually addressed and how.
It remains also unclear how the work actually advances the state-of-the-art. Although some references [17–25] are given, related works are not really discussed in relation to the paper.

In section 2, the idea of Semantic Programming and SPrO are in focus, with some examples. Even if programs could be formulated using ontologies, the authors should also explain and show why this useful. Presenting the large tables 2 and 3 do not provide much insight for this, and it is difficult to understand their meaning and why properties are selected as they are. The relationship between RDF and HTML worlds should be clarified, since a major claim of the paper is that in this approach "as little programming experience is required as possible".

In section 3, some use cases are given as proof of concepts. However, the cases remain largely unclearly explained: what results have actually been achieved here and how does the approach compare with traditional frameworks like using SPARQL that is critized? The paper's key argument that "semantic programming approach can provide HTML-based data views that are easily comprehensible" remains unsubstantiated, and more than major revision is needed in finishing the paper.