Transforming SHACL Shape Graphs into HTML Applications for Populating Knowledge Graphs

Abstract

Creating applications to manually populate and modify knowledge graphs is a complex task. In this paper, we propose a novel approach for designing user interfaces for this purpose, based on existing SHACL constraint files. Our method consists of taking SHACL constraints and creating multi-form web applications. The novelty of the approach is to treat the editing of knowledge graphs via multi-form application interaction as a business process. This enables user interface modeling, such as modeling of application control flows by integrating ontology-based business process management components. Additionally, because our application models are themselves knowledge graphs, we demonstrate how they can leverage OWL reasoning to verify logical consistency and improve the user experience.

1. Introduction

Creating applications that facilitate the manual population and modification of Knowledge Graphs (KGs) is a demanding task. Such applications can take different forms, such as web applications with user-friendly graphical interfaces or conversational clients that generate graphs through a series of questions. The modeling of HTML form applications using KGs for the manual KG population is an active research topic since the early days of the field of Linked Data. In our previous work, we presented the use of ontology concepts to model User Interfaces (UIs) for editing KGs. This approach exploits the Ontology for Ontology-Based Ontology Population (OBOP) [1] to model web applications [2] and chatbots [3]. The knowledge graphs created using these applications conform to specific shapes defined by the underlying model.

The problem addressed in this paper is designing multi-form web applications encoded in KGs, where the entire user interaction is treated as a business process. These web applications are designed to populate Linked Data [4] in a more user-friendly way. A significant benefit of an application modeled in a KG is the ability to apply OWL reasoning to verify the application’s logical consistency, improve user interaction, and automatically detect design flaws. We present the application modeling through a use case example.

Imagine a restaurant manager who wants to create a machine- and human-readable description of his restaurant, including menus and the dishes on those menus, with defined ingredients of those dishes. In the context of Linked Data, the restaurant manager wants to build a restaurant knowledge graph. Let us assume that the restaurant KG is already described by SHACL shapes and that the restaurant manager now wishes to enter restaurant’s data interacting with an application consisting of a set of forms, rather than using a general-purpose expert tool like Protégé [5] or similar. Our approach designs such a “smart” form application that integrates reasoning into the process. For the restaurant manager, this means that if, for example, a vegan menu is selected, the next form generated will automatically exclude any non-vegan products from the available options for the dishes on that menu.

To clarify our approach and the tool being developed in light of existing tools, we define a set of requirements. These requirements are either already satisfied by existing tools or can serve as criteria for the design of future tools:

R1:

The system facilitates the editing KGs by generating form-based UIs.

R2:

The system parses SHACL (ShEx) shapes to generate forms.

R3:

The system generates web forms.

R4:

The system defines application logic through an ontology.

R5:

Ontology reasoning is applied to generate specific components of UI elements.

R6:

Interactions with different forms are considered as components of a business process.

The remainder of this paper is structured as follows: Next, Section 2 examines related work and our approach through the defined set of requirements. Section 3 proposes the architecture of our system and identifies elements for the modeling of HTML forms. Section 4 provides details on the architecture of our form generator. In Section 5, we present our results, while Section 6 discusses some properties of our approach. Section 7 concludes the paper and provides an outlook for future work.

2. Related Work

This section discusses the related work based on the defined set of requirements and modeling aspects relevant to our approach. We primarily consider open-source tools with freely accessible repositories.

Since the Shapes Constraint Language (SHACL) [6] and Shape Expression Schema (ShEx) [7] are used to specify the vocabulary and structure of KGs, they can also be used to generate interfaces for populating such graphs. The structure of RDF graphs in both languages is defined through corresponding graph shapes that can be used for RDF data validation. However, graph shapes and application forms are related by a one-to-many relationship [8], any graph satisfying a single graph shape can be edited by multiple distinct forms. Consequently, several approaches have been proposed to generate web and application forms based on these shapes.

In the case of ShEx, a canonical traversal of the graph and the ordering of elements can be defined and further utilized for UI generation. Tools that meet requirements R1, R2 and R3 include shapeForms [9,10] that generates UI forms from ShEx schemas, and react-shex-forms [11] that generates forms from ShEx schemas using additionally the React framework.

SHACL, on the other hand, is a language for describing and validating RDF graphs, which constrains the structure of data graphs and enforces data and value restrictions. Although properties in SHACL shapes do not impose an explicit order of elements, there appear to be even more software solutions for generating HTML forms from SHACL shapes than from ShEx schemas. These tools typically require designers to specify an additional ordering of elements alongside SHACL shapes. Two distinct tools (both sharing the same name) can be distinguished, namely, shacl-form [12], developed by CSIRO Environmental Informatics, and shacl-form [13,14] developed by the University and State Library Darmstadt.

SHAPEness [15] provides some functionalities similar to our solution, enabling users without technical expertise in ontology editing to edit KGs. To this aim, SHAPEness provides three views in a single interface: graph-based, form-based, and tree-based view. It combines form-based editing with a graph-based visualisation of the edited data. The graph-view serves as the central component, presenting an overview of entities and relationships of the created KG, while the properties of nodes and edges are edited in the form-based view, which is designed to ensure SHACL compliance. This form-based view provides suitable form elements such as text fields, dropdown lists, tables, and other widgets. SHAPEness supports numerous widgets, which are not web-based components, but form elements implemented in the Eclipse Rich Client Platform.

Yet another tool that reads SHACL shape files and generates forms to insert graphs is Schímatos [16]. The data entered using these generated forms are RDF KGs conformant to the given SHACL shapes. These applications focus on creating one form from one SHACL shape and fulfill requirements R1,R2, and R3.

Before the introduction of graph shapes, there were attempts to facilitate knowledge graph population through the definition of RDF templates. One such RDF template is the RaUL [17] ontology, which is used in the web service ActiveRaUL [18] to generate web form-based UI(s) (R1, R3). ActiveRaUL web forms enable the creation of KGs of an arbitrary ontology. In contrast to solutions that leverage shape files (R2), ActiveRaUL does not include validation and instead relies on the correctness of the defined templates.

The W3C User Interface ontology [19] is one of the earliest ontologies for specifying forms and their field types, titles, grouping, labels, and related elements. This ontology is developed by Tim Berners-Lee and used in the context of the Solid project [20,21]. The Solid project team plans to develop a specification to extend SHACL to define shape-driven user interface [22] and use it with UI ontology. The UI ontology is also employed in another RDF-based interface framework called SPARQL Web Pages (SWP) [23], to describe the UIs, such as HTML forms. SWP is a part of the TopBraid suite, which supports SHACL shapes (R2), combines them with UI ontology vocabularies (R3) and uses SPARQL queries to automatically render HTML Forms (R4) based on SHACL shapes.

Ontologies have also been applied to represent various aspects of software processes, from the software process ontology [24], over the ontologies to create REST APIs [25] and Ontology for OpenAPI REST Services Description [26,27] to the ontology for ontology-driven UI development [28]. The difference between ontologies and other types of software models, as well as the presentation of another formal ontology for UIs, is discussed in [29].

In this paper, we present an approach that considers application activities as the execution of a business process. To represent process elements such as control flows, we use an ontology for Business Process Modeling called BPMN 2.0 Based Ontology for Business Process Representation (BBO) [30,31], as specified in requirement R4. BPMN provides graphical representation of processes, and there exist tools to convert business process models into KGs, such as BPMN2KG [32].

A comparison of software tools for HTML form generation that satisfy the given requirements is provided in

Table 1. The compliance of software tools for HTML form generation with the specified requirements.

Form Generating Tool	R1	R2	R3	R4	R5	R6
shapeForms [9,10]	Yes	Yes(ShEx)	Yes	No	No	No
react-shex-forms [11]	Yes	Yes(ShEx)	Yes	No	No	No
shacl-form [12]	Yes	Yes(SHACL)	Yes	No	No	No
shacl-form [13,14]	Yes	Yes(SHACL)	Yes	No	No	No
SHAPEness [15]	Yes	Yes(SHACL)	No	No	No	No
Schímatos [16]	Yes	Yes(SHACL)	Yes	No	No	No
ActiveRaUL [18]	Yes	No	Yes	Yes	No	No
Solid [20,21]	Yes	No 1	Yes	Yes	No	No
TopBraid	Yes	Yes	Yes	Yes	Yes	No

¹ The SHACL support is planned in the specification [22].

.

In spite of the long and vibrant research in this area of Linked Data, none of the reviewed tools fully satisfy all the criteria specified in our requirements list. Aforementioned solutions address dominantly a single SHACL shape with single-form applications. We propose that this gap can be filled by modeling multi-form applications within our approach. The outline of the system architecture for our form generator prototype is provided in the following section.

3. System Architecture and Form Application Model Definition

The idea of this paper is to use SHACL shapes and extend them to model multi-form applications with advanced application logic. To achieve this, the SHACL shapes are integrated with elements from the BBO (business processes) and OBOP (ontology-based ontology population) ontologies. This integration enables the modeling of web applications designed for the KG population. We propose a novel web application modeling approach, which we refer to as the Form Application Model (FAM), an acronym we use throughout the rest of the paper.

FAM is an RDF graph. It incorporates BBO ontology concepts to model application control flows and OBOP ontology concepts to better represent HTML form elements, such as automatic ordering of form fields (since SHACL shapes do not impose any particular order). Additionally, FAM includes the representation of the application logic necessary to create the desired resulting KGs.

Figure 1 schematically illustrates components of the system used for creating and running web application models. The system comprises three main parts: Use Case Design (left), the Form Application Generator (center), and the Runtime Interaction (right). The system begins with the Use Case Design, where FAM models are created. A completed FAM is then passed to the Form Application Generator, where the execution of the generated web application starts. Finally, in the Runtime Interaction, end users interact with the application to input data for the corresponding use case. This paper presents a prototype of the application generator tool that takes manually created FAMs and serves the application to end users. The data entered by users through the application forms is automatically stored as output knowledge graphs in an RDF database. For our prototype, this RDF database is implemented as an in-memory triple store.

While the model design remains a manual process in our current system, we plan to develop a visually assisted FAM designer to facilitate application design. Given that business process elements are integral components of FAMs, this visual designer could either resemble existing BPMN modeling tools (e.g., Camunda [33]) or be implemented as a plugin for such tools. As discussed in Section 1, a BPMN-to-RDF converter similar to the tool described in [32] could be used to generate the actual FAMs as RDF graphs.

Therefore, our system can be represented in Algorithm 1 as two procedures, each managed by a different type of user. The first procedure represents the creation of FAM models through model designers that extend the SHACL shapes with additional elements representing multi-form applications.

Algorithm 1 Populate knowledge graphs according to SHACL shapes

1: procedure  Design-FAM-Model 2:     Load SHACL shapes file 3:     FAM ← Extend SHACL shapes to create application model 4: end procedure  End-user interaction 5: procedure  Populate-Knowledge-Graph 6:     Select a suitable FAM model 7:     Load FAM into application generator 8:     Run the application 9:     while there exists a next form do 10:         Preview HTML form to the user 11:         User enters data into the form 12:         User initiates corresponding form action 13:         Server executes the selected action 14:         Server stores data as KG triples in the triple store 15:     end while 16:     Validate entered data against SHACL shapes 17: end procedure

The second procedure of the system is the actual population of KGs by end-users, who represent the second group of actors. The end-users enter data using user-friendly multi-form applications and do not necessarily have to be ontology experts.

The following subsections present the essence of our modeling approach through a concrete example, demonstrating the manual design using elements from the FAM models.

3.1. Form Application Model

The design of Form Application Models begins with defining of business process components. We focus on the mentioned use case of a restaurant manager who enters restaurant data using a generated application. The application consists of four HTML forms, which are opened consecutively to capture the data. The whole application interaction can therefore be considered as a business process composed of four subprocesses (Figure 2).

The first subprocess serves to enter general restaurant information, such as the restaurant name, address, and other basic details. After this, the next step (subprocess) is to insert the various restaurant menus. The third step (subprocess) consists of adding dishes to the corresponding menus, and the final step serves to enter dish ingredients. Each of these subprocesses is supported by a distinct HTML form provided by the application, and one possible result of the whole application interaction is represented at the end of this section in Figure 6.

The subprocesses shown in Figure 2 include activity markers for collapsed subprocesses (indicated by the "+" sign) and are described in more detail in the following subsections. The first subprocess, “Insert general restaurant data”, is decomposed in Section 3.4, while the  “Insert dishes in menus” subprocess is further expanded in Section 3.7. The remaining subprocesses, “Insert restaurant menus” and “Insert dish ingredients”, are structurally similar to the “Insert dishes in menus” subprocess and are therefore not discussed in detail.

The following subsection explains the modeling of the first form in the subprocess for entering general restaurant information.

3.2. Basic Form

The first HTML form is used to insert general information about the restaurant, as shown in Figure 3. This part of the application allows the end user (restaurant manager) to input a string as the literal value of the gr:legalName data property. To insert this literal value, the form shown on the right side of the figure consists of a single input field along with “Save” and “Cancel” buttons.

The SHACL shape describing the structure of the output knowledge graph, which is populated via this application form, is presented in the following subsection.

3.3. Basic Form Through SHACL Properties

SHACL shapes play a significant role in our modeling approach, as they are used to define certain form elements and behaviors. Our basic form is derived from the SHACL shape instance called :RestaurantShape that belongs to the shacl:NodeShape class (see Listing 1). :RestaurantShape declares that the restaurant instance, generated by the form in the output graph, must be an instance of the classes env:ENVO_01000934 (Environment Ontology—ENVO [34,35]), gr:BusinessEntity (GoodRelations Ontology [36,37]), and schema:FoodEstablishment (Schema.org vocabulary [38]) as defined by the shacl:targetClass property. The restaurant instance in the output graph generated by the form will thus be an individual (instance) of all three classes.

Additionally, restrictions presented in the blank nodes, serving as the objects of the shacl:property, are transformed into validation constraints that apply to the corresponding data generated by the HTML form. The shape :RestaurantShape includes four constraints. The first SHACL property enforces the requirement that exactly one gr:legalName (i.e., restaurant name) object property must be provided for the restaurant instance upon form submission. The cardinality constraint is explicitly defined using the shacl:maxCount and shacl:minCount predicates, both set to 1. The value must be a literal with the datatype xsd:string. The second and third SHACL properties specify that the restaurant must have gr:offers and schema:hasMenu object properties pointing to instances of the schema:MenuShape class.

Listing 1: SHACL shape describing the first form.

@prefix : <http://example.org/logicinterface/testing/> . @prefix bbo: <https://www.irit.fr/recherches/MELODI/ontologies/BBO#> . @prefix obop: <http://purl.org/net/obop/> . @prefix shacl: <http://www.w3.org/ns/shacl#> . @prefix dash: <http://datashapes.org/dash#> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix gr: <http://purl.org/goodrelations/v1#> :RestaurantShape  rdf:type shacl:NodeShape ;    obop:modelBelongsTo :Block1 ;    shacl:property _:genid1 , _genid2, _genid3;    shacl:targetClass env:ENVO_01000934, schema:FoodEstablishment,    gr:BusinessEntity~. _:genid1 shacl:datatype xsd:string ; # legal name property    shacl:path gr:legalName ;    shacl:maxCount 1 ;    shacl:minCount 1 ;    dash:singleLine "true"^^xsd:boolean ;    obop:specifiedBy :Field1 . _:genid2 shacl:datatype xsd:string ; # propery for menus    shacl:path gr:offers;    shacl:node :MenuShape ;    shacl:minCount 1 ;    obop:specifiedBy :RestaurantOffersConnector . _:genid3 shacl:datatype xsd:string ;    shacl:path shape:hasMenu;    shacl:node :MenuShape ;    shacl:minCount 1 ;    obop:specifiedBy :RestaurantHasMenuConnector .

Since SHACL alone cannot fully specify HTML form components, we extend it with elements from our OBOP ontology and the Data Shapes Vocabulary (DASH) [39]. To simplify blank node handling and to define UI elements, we associate an instance :Block1 of class obop:Block with :RestaurantShape, which represents the HTML form in Figure 3, and an instance :Field1 of class obop:Field with the SHACL property representing gr:legalName. These instances are illustrated in Listing 2. Using :Field1 as an IRI (unlike SHACL’s blank nodes) enables straightforward referencing in both SPARQL queries and generator application code.

User interface elements like buttons, input fields, and layouts that cannot be modeled in SHACL are described here. obop:Block instance represents a form, while obop:Button instances represent Cancel and Save buttons in the form. These buttons activate instances of obop:SubmitBlockAction and obop:CancelBlockAction classes. As their names indicate, these subclasses of the obop:Action class represent functions which pertain to a single block (form). In this case, the instance SubmitAction1 saves triples that introduce a new restaurant instance belonging to the classes specified in :RestaurantShape and an instance of the property gr:legalName. A click on the button activates the action but the action itself is executed when it reaches the control flow activity that executes it, which is explained in the next subsection.

Listing 2: OBOP elements describing the first form.

@prefix : <http://example.org/logicinterface/testing/> . @prefix obop: <http://purl.org/net/obop/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . :Block1 rdf:type obop:Block ;    rdfs:label "Restaurant"^^rdfs:Literal. :Field1 rdf:type obop:Field ;    obop:belongsTo :Block1 ;    obop:hasLabel "Restaurant name" ;    obop:belongsToVisual :VerticalLayout1 ;    obop:hasPositionNumber "0"^^xsd:int. :CancelButton1 rdf:type obop:Button ;    rdf:type owl:NamedIndividual ;    obop:belongsToVisual :horizontal_layout_1 ;    obop:activatesAction :CancelAction1 ;    obop:hasLabel "Cancel" ;    obop:hasPositionNumber "1"^^xsd:int ;    obop:belongsTo :Block1. :SubmitButton1 rdf:type obop:Button ;    rdf:type owl:NamedIndividual ;    obop:belongsToVisual :horizontal_layout_1 ;    obop:activatesAction :SubmitAction1 ;    obop:hasLabel "Save" ;    obop:hasPositionNumber "2"^^xsd:int ;    obop:belongsTo :Block1. :SubmitAction1 rdf:type obop:SubmitBlockAction ;    rdfs:label "Basic save of data in the knowledge graph". :CancelAction2 rdf:type obop:CancelBlockAction ;    rdfs:label "Cancel action".

It can be noted that the SHACL properties for gr:offers and schema:hasMenu are not considered by this block action. Data about menus are entered in a separate HTML form, which is not a mandatory subform in the same window, as it is done in the Solid project form designer and some tools mentioned Section 2.

3.4. Modeling Control Flows Using the BBO Ontology

The question of modeling dynamic aspects of the application such as control flow specification is resolved in our approach by using the elements of the BBO ontology. Figure 4 shows a simple BPMN 2.0 diagram with a sequence of tasks for the first subprocess “Insert general restaurant data”.

There are six tasks that present program functionalities in this subprocess, and in the model, these tasks are represented by instances of bbo:UserTask or bbo:ScriptTask subclasses of the bbo:Task class. Additionally, BBO elements that represent control flows are instances of the bbo:NormalSequenceFlow or bbo:ConditionalSequenceFlow, which are subclasses of the bbo:SequenceFlow class. The part of the model graph for the subprocess “Insert general restaurant data” with tasks and sequence flows is shown in Listing 3.

Listing 3: BBO elements describing tasks.

@prefix : <http://example.org/logicinterface/testing/> . @prefix bbo: <https://www.irit.fr/recherches/MELODI/ontologies/BBO#> . @prefix obop: <http://purl.org/net/obop/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . :InsertGeneralRestaurantData a  bbo:SubProcess ;       rdfs:label "SubProcess: Insert general restaurant data"@en. :StartEvent1 a  bbo:SubProcessStartEvent ;   rdfs:label "Event: Starting the subprocess". :GenerateFormRepresentation a bbo:ScriptTask ;   rdfs:label "Generate Form Representation". :UserEntersData a bbo:UserTask ;   rdfs:label "Enter User Data". :VerifyDataCorrectness a bbo:ScriptTask ;   rdfs:label "Verify Data Correctness". :SaveData1 a bbo:ScriptTask ;   obop:executesAction  :SubmitAction1   rdfs:label "Save Data in RDF Store". :AbortDataInsert a bbo:ScriptTask ;   obop:executesAction  :CancelAction1   rdfs:label "Abort the data insert". :EndEvent1 a bbo:EndEvent ;   rdfs:label "End of Subprocess". ### Gateway to decide the next action :DecisionGateway1 a bbo:ExclusiveGateway ;   rdfs:label "Submit button clicked?". :FlowSubmit1 a bbo:ConditionalSequenceFlow ;   bbo:has_sourceRef :DecisionGateway ;   bbo:has_targetRef :SaveData1 ;   # Adding the condition for the "Submit" flow   bbo:has_conditionExpression "SelectedAction==":CancelAction1"" ;   rdfs:label "User clicked Save". :FlowCancel1 a bbo:ConditionalSequenceFlow ;   bbo:has_sourceRef :DecisionGateway ;   bbo:has_targetRef :AbortDataInsert ;   # Adding the condition for the "Cancel" flow   bbo:has_conditionExpression "SelectedAction==":SubmitAction1"" ;   rdfs:label "User clicked Cancel" .

To model decision-making in the control flow, i.e., the branching in our applications, an instance of the class bbo:ExclusiveGateway named :DecisionGateway is used. The decision depends on whether the user selects the Submit or Cancel button. Only one of the sequence flows (:FlowSubmit1 and :FlowCancel1) can be activated, as specified by the corresponding bbo:has_conditionExpression properties. The conditions of decision flows are defined as SelectedAction == :SubmitAction1 and SelectedAction == :CancelAction1, indicating that the user has chosen the action associated with the respective ConditionalSequenceFlow. The remaining control flows are not shown in Listing 3 for brevity.

An action is performed when the corresponding task is executed, which is specified by the obop:executesAction property in those tasks and represents what should be done with the data. These two actions are instances of the obop:BlockAction class which indicates that their focus is a single form. For actions that address data in two separate forms, we use the strategy explained in the next subsection.

3.5. Connecting Data from Different SHACL Shapes

To show how the data modeled in Listing 1 are related to the data representing restaurant menus, we explain the content of the SHACL shape for the restaurant menu (see Listing 4).

Listing 4: SHACL shape modeling menu nodes.

@prefix : <http://example.org/logicinterface/testing/> . @prefix bbo: <https://www.irit.fr/recherches/MELODI/ontologies/BBO#> . @prefix obop: <http://purl.org/net/obop/> . @prefix shacl: <http://www.w3.org/ns/shacl#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix foodon: <http://purl.obolibrary.org/obo/FOODON_> :MenuShape rdf:type shacl:NodeShape ;   shacl:targetClass schema:Menu, gr:Offering ;   obop:modelBelongsTo :Block2 ;   shacl:property _:genid4, _:genid5. _:genid4 shacl:path gr:name ; # Property for the menu name   shacl:datatype xsd:string ;   shacl:minCount 1 ;   shacl:maxCount 1 ;   obop:specifiedBy :Field2. # Property for the menu type that constraints dish ingredients _:genid5 shacl:path obop:constraintedWithClass ;   shacl:datatype xsd:string ;   shacl:minCount 1 ;   shacl:maxCount 1 ;   obop:specifiedBy :ListField1 ;   sh:class foodon:00001000. # The value must be a subclass of                             # a generic food~type. _:genid6 shacl:path gr:includes ;   shacl:node ex:MDishShape ; # Link to the :DishShape   shacl:minCount 1 ;   obop:specifiedBy :MenuIncludesConnector .

Here, the instance of the obop:Block class called :Block2 is similar to the block of the subprocess for inserting general restaurant data. However, the activities started by clicking the submit button are more complex this time, and they consist of two tasks, which are executed sequentially (see Listing 5). The first task performs the action (represented by an instance of obop:Action class) to save the menu name, and the second task performs the action to make a connection obop:Connection element which specifies how to connect two parts of the KG.

The connection element is additionally referred to by the “obop:specifiedBy :RestaurantHasMenuConnector” in the :RestaurantShape (Listing 1), which ensures that the object property obeys the proposed description.

3.6. Advanced Control Flows

In BPMN 2.0, various elements can be defined to model complex processes. Creating loops is, for example, one of the fundamental aspects of representing repetitive process behavior, and there are many ways to model such behavior in BPMN. The first is standard loop that represents a classic “do-while” construct, and the second way is multi-instance loop that resembles a “foreach” construct, which iterates through a list of elements. A multi-instance loop can perform repeating tasks either in parallel or sequentially.

Code and functionality repetition represents an inherent challenge in our application modeling. The next subsection presents our modeling approach for multi-instance loop functionality through iterative form repetition, demonstrated using our application case study.

Listing 5: Action that models connection of data entered in two forms.

@prefix : <http://example.org/logicinterface/testing/> . @prefix bbo: <https://www.irit.fr/recherches/MELODI/ontologies/BBO#> . @prefix obop: <http://purl.org/net/obop/> . @prefix shacl: <http://www.w3.org/ns/shacl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . :SaveMenuData a bbo:ScriptTask;   rdfs:label "Save the data on the Menu form in the RDF store";   obop:executesAction ::SubmitAction2. :SubmitAction2 rdf:type obop:SubmitBlockAction ;   rdfs:label "Basic save of data in the knowledge graph". :Flow_2_8  a bbo:ConditionalSequenceFlow ;   bbo:has_sourceRef :SaveMenuData ;   bbo:has_targetRef :InsertRestaurantMenuConnection. :InsertRestaurantMenuConnection a bbo:ScriptTask;   rdfs:label "Save the object property from restaurant to menu." ;   obop:executesAction :ConnectionAction1. :ConnectionAction1 a obop:MakeConnectionAction;   obop:hasConnection  :RestaurantMenuConnnection. :RestaurantMenuConnnection a obop:Connection;   obop:connectionHasSource :RestaurantNodeShape ;   obop:connectionHasTarget :MenuShape ;   obop:hasConnector :RestaurantOffersConnector ;   obop:hasConnector :RestaurantHasMenuConnector ; :CancelAction2 rdf:type obop:CancelBlockAction ;   rdfs:label "Cancel action" .

3.7. Modeling of Multi-Instance Iterations

The second, third, and fourth HTML forms in our example application serve the following purposes: (1) to insert menu data for the existing restaurant, (2) to register dishes within their respective menus, and (3) to add ingredients to corresponding dishes. Each of these data-entry operations, regarded as formal subprocesses, requires the repetition of data insertion functionality, as shown in the example of the subprocess “Insert dishes in menus”, illustrated in Figure 5.

The subprocess for inserting dishes into menus is a multi-instance subprocess, indicated by the three parallel bars at the bottom center in the diagram. These parallel bars specify that dishes are added sequentially, one after another like in a foreach loop in a programming language. Instead of having a collection of elements as in the standard BPMN we use the output of a SPARQL query that retrieves all instances of menus already entered in the previous subprocess.

A SHACL shape is also utilized in this part of the model, and is extended with elements from the OBOP ontology, in a manner similar to the modeling of menu insertion. For the sake of brevity, this section omits a detailed explanation, and instead focuses on the modeling of the repeating form. To illustrate this, we repeat the process of inserting dishes as many times as there are different menus, which are already stored in the output KG. Listing 6 shows a portion of the model graph with the loop definition for this subprocess.

Listing 6: Repeating the insert in a form.

@prefix : <http://example.org/logicinterface/testing/> . @prefix bbo: <https://www.irit.fr/recherches/MELODI/ontologies/BBO#> . @prefix obop: <http://purl.org/net/obop/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . :InsertMenuItems a  bbo:SubProcess ;   rdfs:label "SubProcess: Enter dishes in restaurant menus"@en ;   bbo:has_multiInstanceLoopCharacteristics :MenusMILoopCharacteristics. :MenusMILoopCharacteristics a bbo:MultiInstanceLoopCharacteristics ;   bbo:isSequential "true"^^xsd:boolean ;   bbo:has_loopResourceInputRef :DynamicMenuItemsCollection. :DynamicMenuItemsCollection a bbo:Resource ;   rdfs:label "Dynamically retrieved Menu Items"@en ;   obop:isMaterializedBy :FetchMenuItemsQuery. :FetchMenuItemsQuery a obop:SPARQLQuery ;   obop:sparqlText "SELECT ?menu WHERE { ?menu a schema:Menu . }" ;   obop:extractedFirstOnlyVariable "true"^^xsd:boolean .

An instance of the bbo:MultiInstanceLoopCharacteristics class is associated with the subprocess, which represents the loop whose iterations are carried out sequentially. This is confirmed by the data property bbo:isSequential being set to true. This sequential execution of subprocesses, which is specified in this example, can be change to parallel processing by setting the bbo:isSequential to false. One possible scenario for that would be, when multiple employees need to simultaneously enter dishes using client application on different computers, all of which access the same server application. The :MenusMILoopCharacteristics instance is further linked to an instance of the bbo:Resource class. The bbo:Resource class, which is defined in the BBO ontology as an abstract class, represents here a resource that is dynamically populated with the result of a SPARQL query.

The provided SPARQL query retrieves all menus that were previously entered in the KG. The user interacts with a generated master-detail form, allowing him to add dishes to a specific menu. After the user finished entering dishes in one menu and clicks the “Finish” button, the next menu is displayed, ready to enter its dishes. An important building block that enables the master-detail form is the establishing of object properties between instances of the menu (master) and the dishes belonging to that menu (details). This building block is represented in the model by an instance of the obop:Connection class (see Listing 7). The connection has its source and target, which, in our example, are :MenuShape and :DishShape. These elements stipulate that the properties linking the instances defined by those shapes should be established.

In our example, links between menu and dish instances are instances of the gr:includes object property, as already specified in Listing 4. Additionally, it is necessary that the connection be linked to the corresponding properties in the SHACL shape, which is here implemented with an :MenuIncludesConnector instance.

After execution of the entire process of the application, the output KG must be valid according to the initial SHACL shape graph. In our approach we emphasize the role of the actions, which lead to the next activity in the KG editing process. A example of the KG that can be created through the user interaction with our example web-application is illustrated in Figure 6.

After explaining the primary aspects of the model, the next section introduces the structure of the Form Generator.

Listing 7: Action that connects the menu and dishes.

@prefix : <http://example.org/logicinterface/testing/> . @prefix bbo: <https://www.irit.fr/recherches/MELODI/ontologies/BBO#> . @prefix obop: <http://purl.org/net/obop/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . :SaveDishData a bbo:ScriptTask;    rdfs:label "Save the data received from the Dish form in the RDF store" ;    obop:executesAction :SubmitAction3. :SubmitAction3 rdf:type obop:SubmitBlockAction ;     rdfs:label "Basic save of data in the knowledge graph" ; :Flow_3_9  a bbo:ConditionalSequenceFlow ;    bbo:has_sourceRef :SaveDishData ;    bbo:has_targetRef :InsertDishConnection. :InsertMenuDishConnection a bbo:ScriptTask;    rdfs:label "Create an object property linking a menu to a dish." ;    obop:executesAction :ConnectionAction2. :ConnectionAction2 a obop:MakeConnectionAction ;    obop:hasConnection  :MenuDishConnnection. :MenuDishConnnection a obop:Connection;    obop:connectionHasSource :MenuShape ;    obop:connectionHasTarget :DishShape ;    obop:hasConnector :MenuIncludesConnector. :CancelAction3 rdf:type obop:BlockCancelAction ;    rdfs:label "Cancel action" .

4. Form Generator Architecture

This section describes the architecture of our web application generator. The generator is available in the GitHub repository [onto-app-models] (https://github.com/ontosoft/onto-app-models.git (accessed on 30 July 2025)). The repository contains several manually created FAM models that are loaded into the generator to launch the corresponding applications. These applications are executed within the generator, allowing users to populate output RDF graphs.

The prototype of the application generator is implemented as a client-server REST application. The client side consists of a single page application that shows HTML forms, enables data entry into the corresponding fields, and sends the data to the server. The client-side application is implemented in TypeScript and makes use of the React framework together with JSON Forms [40] for rendering the HTML forms, as demonstrated in Figure 7. State management on the client side is handled using the Redux library, which serves as a state container for JavaScript applications.

The server side stores application models as RDF graphs that consist of SHACL shapes extended with BBO and OBOP concepts defining constraints for HTML applications. During the loading of an application model on the server, an internal static representation of the application is created. When the user runs the application, a dynamic representation of the corresponding application is generated from its internal static representation. This dynamic representation represents practically serves as a process execution engine that maintains a token, which moves through the business process elements. Therefore, the process execution engine maintains the current application state.

During the creation of both the static and dynamic representations, the Python libraries RDFLib and Owlready2 are used, along with the semantic reasoner Pellet. The resulting output KG is also stored using RDFLib, which functions as an in-memory triple store.

The data exchange between the client and the server is carried out using pairs of HTTP requests. The first request is a PUT request, which sends data to the server to initiate the exchange—specifically, to begin the generation of the form layout specification. When the form layout specification is completed, it represents a set of JSON files containing all elements for the JSON Forms and for some client-side functions. The second request from the client is a GET request, which receives the corresponding set of JSON files containing UI models in order to preview the encoded layout from the model. The sequence diagram of the client-server data exchange is shown in Figure 8.

Since the client side uses JSON Forms, the form specification consists practically of three JSON files: (1) UI schema for the layout specification, (2) JSON Schema for specifying of form element names, and (3) data file with default values. When the user enters data in the form and submits the form then the PUT requests sends that data to the server side.

After the server side receives data the process execution manager executes the action according to the current process activity and the specific obop:Action which was selected by the application end user.

4.1. JSON Forms

Since the architecture includes communication with the REST application in the backend, HTML forms are described using JSON Forms. JSON Forms proves to be a good fit for many scenarios, and meets the requirements of our form layouts. The prototype currently uses JSON Forms with React-based renderer sets. JSON Forms supports four different layout types: (1) VerticalLayout, (2) HorizontalLayout, (3) Group (a slightly modified version of VerticalLayout), and (4) Categorization. To support those layouts, we extended the OBOP ontology accordingly.

Regarding different renderer sets implemented in JSON Forms has, the React Material renderer was chosen because, alongside Vue Vuetify, it currently provides the most complete support for JSON Schema elements.

However, JSON buttons are not part of the JSON Schema specification, and we addressed this issue by a defining buttons within the UI-schema. For these buttons, we implement custom-tailored renderers.

4.2. Layout Elements

The OBOP ontology implements the layout structures used by JSON Forms (see Listing 8). This example presents two layouts - instances of obop:VerticalLayout and obop:HorizontalLayout. Layouts can be used independently of HTML forms, for example, to represent a page containing notifications, and they can also be nested, as is the case in this example. It is common for a single form to include more than one layout. FAM visual elements are associated not only with forms but also with their corresponding layouts.

Listing 8: Representation of layouts.

@prefix : <http://example.org/logicinterface/testing/> . @prefix obop: <http://purl.org/net/obop/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . :vertical_layout_1 rdf:type obop:VerticalLayout ;      obop:hasPositionNumber "1"^^xsd:int ;      obop:belongsTo :Block1 ;      rdfs:label "Vertical-Block1"^^rdfs:Literal. :horizontal_layout_1 rdf:type obop:HorizontalLayout ;      obop:hasPositionNumber "1"^^xsd:int ;      obop:belongsToVisual :vertical_layout_1 ;      rdfs:label "Horizontal-Layout1"^^rdfs:Literal .

The vertical layout :vertical_layout_1 represents the main layout of the form generated for the shape :RestaurantShape (:block_1). The layout :horizontal_layout_1 is nested within :vertical_layout_1 and contains the Cancel and Save buttons of the form. Since buttons are not represented in SHACL shapes, we use the definition of obop:Button to specify them.

4.3. Validation

The output KG is not valid at every stage of the application execution. At certain points, only a part of the SHACL shapes is satisfied. For this reason, validation is performed at the end of the application interaction. The prototype uses pySHACL [41] to ensure that the application creates valid graphs with respect to the defined SHACL shapes. Applications can also include a dialog to initiate SHACL validation as the final step in the workflow, as demonstrated in the examples available in the Git repository.

5. Results

An essential aspect of our modeling approach is the integration of a static KG representation with the dynamic activity of data entry. SHACL shapes define the static structure of the resulting KG, while business processes represent the dynamic behavior involved in generating that graph. Consequently, one of the key results of this work is the establishment of a framework for studying the dynamic process of creating data that must conform to a predefined static structure. The final outcome of the modeled applications is the generation of KGs that fully comply with all constraints specified in the original SHACL files.

5.1. Business Process Management and Interface Models

This approach proposes decomposing a global application process into multiple independent subprocesses or activities, each designed to fulfill a single purpose, thereby reducing component complexity. As a result, these components become easier to test and maintain. Moreover, this decomposition promotes the development of non-monolithic applications, enabling different parts, particularly on the client side, to be implemented using diverse technologies rather than a single framework. Consequently, application components can leverage various programming languages and frameworks, including microservices, to enhance modularity and flexibility.

Furthermore, tasks can be distributed among workers, where each worker represents an individual or a group. Different processing logic can be applied depending on the application type (e.g., web applications, chat bot clients, etc.). The primary contribution of this approach goes beyond modeling individual forms to encompass multi-form applications and their dynamic interactions. Specifically, BPMN processes, combined with OBOP:Actions, formally define connections between the existing parts of KGs and the newly entered form data.

5.2. Application Logic and Reasoning

An important benefit of KGs as models is to exploit reasoning to infer new data and detect problems in the application models. We can broadly distinguish two general types of use cases to apply reasoning in our applications. The first type is the reasoning on the consistency of the actual model, and the second type is using reasoning during the user interaction with the application.

5.2.1. OWL Reasoning for the Model Consistency

To ensure the validity of FAMs, we define RDFS and OWL inference rules. These rules are defined on concepts from the OBOP and BBO ontologies, and also incorporate concepts from the target ontologies.

An example with the inference rules for the obop:Connection class (already discussed in Section 3) and related properties is given in the following equation:

$$\begin{array}{cc}\hfill \mathtt{obop}:\mathtt{Connection}& ⊑(=1\mathtt{obop}:\mathtt{connectionHasSource}.\top )\hfill \\ \hfill & \sqcap (=1\mathtt{obop}:\mathtt{connectionHasTarget}.\top )\hfill \\ \hfill & \sqcap (\exists \mathtt{obop}:\mathtt{hasConnector}.\top )\hfill \end{array}$$

(1)

In this manner, the validity of FAM models is tested to ensure that every obop:Connection instance must have its source, target and at least one associated obop:Connector instance. For example, if a connection is missing but a SHACL property exists that links two node shapes, then the system automatically proposes an extension to include this connection.

Even though SHACL Core shapes do not express certain behaviors, our FAM models can define some output KGs shapes that can be expressed by SHACL-SPARQL. This is shown in Listing 5, where the connection has two connectors that join two SHACL properties between the two node shapes. This leads to the creation of pairs of properties between corresponding instances during the application execution.

Another important aspect of application completeness is ensuring that the model allows users to perform all permitted operations on the data. For instance, while it may be possible to add a menu for a restaurant, deleting that menu from the KG might not be permitted. This enabling of CRUD operation within an application can, in some cases, be automated.

5.2.2. RDFS Reasoning During the Application Interaction

One of the advantages of our model is its ability to express dependencies among interface elements. This dynamic feature is illustrated through a concrete use case. Suppose a user (the restaurant manager) wants to have a feature to create a vegan menu. In the subsequent form, the user should be able to insert names of vegan dishes, followed by a third form allowing the entry of only those ingredients of non-animal origin.

This type of inter-form constraint cannot be expressed using a standard shacl:class ex:SuperClass or any SPARQL Core property constraint, because  there is no SHACL property linking the :MenuShape and :DishIngredientShape. As shown in the output KG in Figure 6, instances of menus (constrained by MenuShape) are directly linked to instances of dishes - menu items (modeled by :DishShape), which are subsequently linked to their respective dish ingredients (defined by:DishIngredientShape). In this sense, that dish ingredients are transitively dependent on menus (MenuShape –> :DishShape –> :DishIngredientShape)). Therefore, modeling this dependency requires a more expressive mechanism than what is available through traditional SHACL property constraints.

This constraint can be expressed using the SHACL Advanced Features [42] and SHACL-SPARQL [43]. SHACL-SPARQL is currently a Working Draft that defines features not covered in SHACL Core. Our constraint is presented in Listing 9 with the definition of :DishShape.

The obop:constrainedWithClass property is already specified in :MenuShape in Listing 4. If the user selected food products of plant origin (FOODON:00002131), representing the vegan superclass in the FoodOn ontology [44] as a constrained class, then all dish ingredients in every dish of that menu must be instances of classes that are subclasses of FOODON:00002131. The ingredients are related to dishes via the object properties BFO:0000051 from the Basic Formal Ontology (BFO) [45], which represents parts of the respective dishes.

Since creating functional UIs directly from SPARQL queries is a complex task, we propose an alternative method to describe these dependencies, as presented in the following subsection.

Listing 9: SHACL-SPARQL definition of a complex dependency.

@prefix : <http://example.org/logicinterface/testing/> . @prefix bbo: <https://www.irit.fr/recherches/MELODI/ontologies/BBO#> . @prefix obop: <http://purl.org/net/obop/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . :DishShape a shacl:NodeShape ;   shacl:targetClass schema:MenuItem ;   obop:modelBelongsTo :Block4 ;   shacl:property [     shacl:path BFO:0000051 ;      # has part (has ingredient)     shacl:minCount 1 ;           # must have at least one ingredient     shacl:message "Every dish must have at least one ingredient." ;     obop:specifiedBy :ListField2 ;     shacl:constraint [        a shacl:SPARQLPropertyConstraint ;        shacl:message "Each ingredient must be a subclass of                the menu’s constrained class." ;        shacl:select """         SELECT $this  ?value         WHERE {           $this ro:0000051 ?value .           ?menu gr:includes $this .           ?menu obop:constraintedWithClass ?menuType .           FILTER NOT EXISTS {             ?value rdfs:subClassOf ?menuType .           }         }        """ ;     ]   ] .

5.3. Expressing Inference Rules

To represent indirect dependency, where an instance of one class determines another instance that is not directly linked to first instance in SHACL shapes, we introduce the class obop:InferenceDependency and its subclass obop:SubClassOfDependency. The latter is exploited to express the rdfs:subClassOf inference rule, as illustrated in Listing 10.

Listing 10: Representing rdfs:subClassOf inference rule.

@prefix : <http://example.org/logicinterface/testing/> . @prefix obop: <http://purl.org/net/obop/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . :SubclassInferenceRule a obop:SubClassOfDependency;   obop:hasSourceOfDependency :ListField1 ;   obop:hasTargetOfDependency :ListField2 ;

The use of reasoning in the validation of SHACL shapes has recently gained traction in RDF-based applications [46]. In our approach the reasoning in performed in two stages. First, during the model loading, OWL reasoning is applied to ensure the correctness of the model. If an inference dependency lacks either a source or a target, the model is flagged as inconsistent. In the second stage, RDFS reasoning is applied dynamically, which takes place when the user enters ingredients. For example, if a menu is declared as vegan using the FOODON:00002131 class, then only subclasses of that class can appear in the drop-down menu when the user selects a food ingredient for any dish in that vegan menu.

The usefulness of OWL inference rules in our application is also demonstrated when the user employs a boolean switch in one form which includes or excludes multiple choice in the subsequent form, depending on the value of shacl:maxCount property.

6. Discussion

The field of generating user interfaces from SHACL and ShEx shapes has yielded numerous software tools, as discussed in Section 2. A comparison analysis of the reviewed form generation tools against our prototype, onto-based-model, is summarised in

Table 2. Feature comparison of reviewed form generation tools with our onto-app-models prototype.

Form Generating Tool	R1	R2	R3	R4	R5	R6
shapeForms [9,10]	Yes	Yes(ShEx)	Yes	No	No	No
react-shex-forms [11]	Yes	Yes(ShEx)	Yes	No	No	No
shacl-form [12]	Yes	Yes(SHACL)	Yes	No	No	No
shacl-form [13,14]	Yes	Yes(SHACL)	Yes	No	No	No
SHAPEness [15]	Yes	Yes(SHACL)	No	No	No	No
Schímatos [16]	Yes	Yes(SHACL)	Yes	No	No	No
ActiveRaUL [18]	Yes	No	Yes	Yes	No	No
Solid [20,21]	Yes	No 1	Yes	Yes	No	No
TopBraid	Yes	Yes	Yes	Yes	Yes	No
onto-app-models	Yes	Yes	Yes	Yes	Yes	Yes

¹ The SHACL support is planned in the specification [22].

. The comparison is structured according to the requirement set defined in Section 2.

We considered only tools that generate form applications (reqirement R1). As most reviewed solutions onto-app-models also includes SHACL parsing to generate forms (reqirement R2) and generates web applications (R3). Similar to the Solid project [20,21] and TopBraid suite onto-app-models utilizes ontologies to define application logic (requirement R4). TopBraid also employs ontology reasoning to generate specific components (R5). However, none of the reviewed tools addresses the challenges of complex application flows (R6), which are useful for practical, real-world KG population tasks. FAM models designed in onto-app-models specifically address this gap by formally integrating business process concepts and OBOP concepts in order to apply ontology reasoning into the application model.

Unlike Schímatos [16] that offers the modificaton of the SHACL shapes, our tool does not have that feature. In comparison to Schímatos we offer an additional ontolgy-based modeling language. This modeling language described by OBOP and BBO ontologies is used to precisely specify the GUI of generated applications such as the outlook of form applications as well as the application logic itself. This expressivity of the model extends standard SHACL shapes. Moreover, the modeling language is suitable for the application of technologies for the automatic generation of application models. If the model does not define explicitly display settings for an element then the system proposes a default setting. onto-app-model also lacks graph-based visualization that can be convenient in combination with form application, as is the case with SHAPEness [15].

On the other hand, decoupling SHACL from its form representation, which we achived through an additional ontology-based modeling, enables the sharing of these models. This brings our solution conceptually closer to the Solid project’s sharing of applications. Furthermore, this separation allows the use of technologies such as Large Language Models (LLMs) to modify existing models, adapt exiting applications, and generate new applications from other SHACL shapes.

Consequently, our application generator operates as a process execution engine, where the core process for each application is the KG graph population process itself. Produced KGs are SHACL-valid graphs, ensuring structural and semantic consistency. Unlike existing tools, our implementation supports comprehensive application modeling with multi-form workflows. The integration of JSON Forms, with its support for React, Angular, and Vue, further enhances the adaptability of our models across different UI types.

6.1. Detecting Model Problems Before Application Execution

Ontology-based modeling provides the opportunity to apply reasoning for detecting potential issues in application models. For example, reasoning can help identifying cases where an HTML form lacks a submit button, where a button is not linked to any form, or where a button has no associated action. Furthermore, it is possible to identify BBO elements that could potentially violate SHACL constraints (e.g., falsely defined loops with BBO elements for functional properties). Such automated detection of modeling issues prevents designers to define false constructs, thereby reducing runtime errors.

6.2. Adaptive Model Refinement During Application Execution

One of the main challenges of our modeling approach is defining dynamic application behavior through the integration of OBOP, BBO, and other target ontologies, along with inference rules. This ontology-based modeling is particularly challenging when it depends on data entered during the interaction with the application. For instance, when users select specific fields and options in one form, these choices influence the content and options of a subsequent form, or even multiple forms, as demonstrated with RDFS reasoning in Section 5. Such actions could be as simple as enabling or hiding certain input fields, or arbitrarily complex logic implemented using a general-purpose programming language. Therefore, future iterations of our modeling approach might introduce “smart”, context-aware forms that dynamically appear based on user behavior and can extend the output graph beyond underlying SHACL shapes if those shapes are not closed.

6.3. Evaluation and Future Directions

In future work, we plan to investigate temporal changes of the generated output KGs. A key aspect of that study will be evaluating how ontological inferences applied to our business process models and the already inserted data adapt to changes in the output KG over time. A comprehensive evaluation of our approach will be presented in a subsequent paper and will be conducted in the following key categories: (i) the correctness of the generated A-Box, (ii) quantifiable measuring of user experiences with the generated applications, and (iii) empirical evaluation of the complexity of the generated interfaces for modifying a given knowledge graph.

7. Conclusions

In this paper, we presented an improved approach for generating web applications from SHACL shape files. Our core innovation lies in treating application logic as a business process, explicitly represented using the BPMN ontology. BPMN, being a mature and standardized technique, provides comprehensive means to represent sequences of actions, branching, and iterations, thereby achieving Turing completeness for our application models. Furthermore, leveraging OWL reasoning on these model knowledge graphs allows for the implementation of dynamic application features, and the detection of certain inconsistencies within the application logic during the design phase. An important fact is that the corresponding web-application generated from the model inherently ensures that created knowledge graphs are valid with respect to the corresponding SHACL shapes.

For future work, we plan to integrate existing methods for modeling interactive aspects of dynamic applications and explore creating our models over automatically generated SHACL files from pre-existing knowledge graphs. This can enable us to investigate the automatic creation of application models that can edit existing graphs, where generated application models can be used to change only certain aspects of knowledge graphs. Another important direction is the use of LLMs to support the automatic generation of form application models. Ultimately, this could facilitate the generation of web application interfaces capable of creating and modifying arbitrary knowledge graphs.