A Language for Modeling Declarative Knowledge Bases in the Context of Model-Driven Engineering

Abstract

End-user development (EUD) and model-driven engineering (MDE) are particularly valuable for building classical intelligent systems that rely on declarative knowledge bases. In these knowledge bases, the key dependencies of the domain can be described in the form of logical rules. The general-purpose modeling language used in MDE, specifically UML, enables modeling of static data structures and the dynamics of object behavior; however, it does not primarily support the modeling logical rules. In this paper, we propose a rule visual modeling language inspired by UML—Rule Visual Modeling Language (RVML)—which expands the capabilities of MDE in terms of using domain-specific visual languages. This approach substantially supports end-users in constructing declarative knowledge bases. We present the formal semantics, visual syntax, and features of RVML, along with two industrial case studies. We empirically evaluate the effectiveness of RVML in development compared to other graphic notations used for modeling logical rules. Our evaluation demonstrates that RVML provides superior expressiveness and better preservation of semantic integrity.

1. Introduction

The effective application of end-user development (EUD) [1,2] and model-driven engineering (MDE) [3,4] to the construction of classical intelligent systems requires robust support for the visual modeling of knowledge base structures. In such contexts, Unified Modeling Language (UML) and its variants and extensions (such as jsUML2, OctoUML, PlantUML, and SysML) [5,6] are most commonly used as general-purpose modeling languages. These languages provide a unified approach to describing domain structures and business processes, offering diagram types for representing both static structures and system behavior. However, specifying property constraints typically requires the use of Object Constraint Language (OCL). Moreover, defining conditions for logical relationships remains challenging, as it depends on complex associations and the use of stereotypes. The absence of a generally accepted interpretation for model relationships prevents unambiguous transformation into executable knowledge base code. As a result, there is a lack of appropriate tools or extension modules (plugins) for UML.

The development of a UML-inspired domain-specific visual language is therefore essential. Such a language should support both platform-independent and platform-specific models and enable the representation of declarative knowledge bases using logical rules as the core formalism.

This paper introduces the Rule Visual Modeling Language (RVML), which extends model-driven engineering (MDE) capabilities through the integration of domain-specific visual constructs. As a result, it provides substantial support for end-users in the construction of declarative knowledge bases. Through automated model transformation operators, RVML models can be derived from Unified Modeling Language (UML) class diagrams as well as from concept maps (e.g., mind maps).

The development of RVML is motivated, in part, by the need to support the creation of knowledge bases for rule-based systems implemented in environments such as CLIPS/FuzzyCLIPS [7] and Drools [8] through visual modeling techniques.

Our contributions can be summarized as follows:

• We propose a visual language for modeling declarative knowledge bases, termed RVML, which supports mapping to core constructs of CLIPS/FuzzyCLIPS. These include fact templates; facts as elements of rule conditions and actions; rule nodes; operators for manipulating facts in working memory; linguistic (fuzzy) variables; and terms.
• We develop a supporting software tool, the Personal Knowledge Base Designer (PKBD), which enables the practical application of RVML.
• We evaluate the proposed approach through task-based assessment, a user study, and multiple case studies, demonstrating its effectiveness and applicability.

Our primary contribution is a UML-inspired language that simplifies cause-and-effect rule modeling. It natively supports rule priorities, confidence factors, and property constraints, eliminating the need for supplementary textual languages. It also ensures a clear separation of notation elements. Furthermore, it integrates visually distinct elements with enhanced semantic expressiveness, which is particularly valuable for non-programming end-users.

The paper is organized as follows: Section 2 reviews related works in the modeling of declarative knowledge bases. Section 3 outlines our knowledge base modeling language, including its meta-model, visual elements, examples of transformation into code, advantages, and a comparison with similar approaches. Section 4 discusses the RVML evaluation and presents industrial case studies. Finally, Conclusions highlight final remarks and future research directions.

2. Related Works

AI research has produced numerous methods and tools for knowledge representation, including domain-specific languages (DSLs). These approaches can be integrated into MDE workflows to model declarative knowledge bases containing logical rules. Building on the classification in [9,10] and subsequent refinements, we identify the following primary categories of DSLs:

• Textual, which provides direct manipulation of language constructs and is mainly aimed at programmers. Examples of the approach are specialized languages such as CLIPS [7] and DROOLS [8], as well as markup languages such as RuleML [11], SWRL [12,13], and R2ML [14]; implementation tools: specialized editors, for example, Visual JESS for JESS (Java Expert Systems Shell), supporting mechanisms for contextual assistance, and color highlighting of basic language constructions.
• Graphical, which provides manipulation of visual elements corresponding to the elements of language constructions, in some cases, followed by their direct mapping into program code or specifications. This approach enables end-users to be involved in the development process by supporting visual modeling/programming.

Further, within the graphical DSLs, the following are distinguished:

• Universal semantic structures [15] in the form of concept maps and ontologies; however, the lack of standardized relationship semantics complicates model transformation, limiting their adoption in intelligent system development. For example, VisiRule [16] and RULING [17] offer the color indication of nodes; Shigarov et al. [18] defined the rules for naming concepts and their properties; and Pavlov et al. [19] used a certain color scheme when naming arcs. Some of the languages in this group, for example, BiDaML [20], SCg (Semantic Code graphical) [21], and DESIRE [22], contain original graphic elements that are not widespread among domain specialists and software developers.
• Tables (tabular representations) intended for their subsequent conversion into codes and specifications, for example, classic decision tables [23] or specialized ones—eXtended Tabular Trees (XTT2) [24].
• Domain-specific visual languages focused on specific tasks, for example, big data analytics solutions [20], block-based programming [25], and engineering multi-layered IoT systems [26].
• Extensions/profiles/specializations of general-purpose modeling languages focused on the representation of cause-and-effect relationships, for example, UML-Based Rule Modeling Language (URML) [27] and MML (Moka Modeling Language) [28], which are inspired by the Unified Modeling Language (UML).

These categories, however, exhibit significant conceptual overlap.

At the same time, most of the textual languages were originally designed for professional programmers, and their use by end-users with limited programming expertise was not considered at the initial stages of their development. Subsequently, various extensions and add-on tools were introduced in the form of specialized software supporting end-user development (EUD) approaches, including templates, wizards, and domain-specific interfaces. In contrast, graphical languages were developed to engage non-programming specialists in software modeling and design processes. However, the majority of existing graphical languages are primarily oriented toward entity–relationship modeling and do not adequately address the specific requirements of intelligent system development. In particular, they lack formalized mechanisms for representing cause-and-effect relationships, including operations, confidence factors, and logical inference constructs, which are essential for the development of knowledge-based and intelligent systems. Solutions that address this specificity (e.g., URML, SCg) instead rely on semantically complex graphical elements.

Creating domain-specific visual languages seems promising. These languages can be inspired by general-purpose modeling languages, such as UML. However, they should use more semantically understandable visual elements.

The visual representation of fuzziness and uncertainty remains underdeveloped in specialized DSLs. Examples of such languages are fuzzy ER models [29], fuzzy UML models [30], etc., but they are not used in the development of intelligent systems and their applications. Thus, support for fuzziness is also relevant in the language being developed.

3. RVML: A Language for Modeling Declarative Knowledge Bases

As part of developing EUD tools for intelligent decision support systems [31] and solving applied tasks [32,33], we developed the RVML. Its primary purpose is the visual modeling of declarative knowledge bases, followed by automated program code generation. This enables a seamless transition from computation-independent models, such as concept maps or UML class diagrams, to structured sets of logical rules. The language is based on the formalism of “IF–THEN” logical rules. RVML can be regarded as an extension profile of Unified Modeling Language (UML), utilizing modified core elements such as “class” and “association.” RVML enables the representation of logical rules in a generalized form, abstracting from the specifics of particular programming languages. At the same time, it provides mechanisms for rule prioritization and for assigning default values to slots.

RVML also includes an extension, FuzzyRVML, which supports the use of linguistic (fuzzy) variables and confidence factors to account for uncertainty in reasoning. The value of a linguistic variable is defined using so-called fuzzy sets [34]. A fuzzy set is characterized by a base scale (i.e., a set of elementary values) and a membership function µ(x), which determines the degree to which each element of the domain belongs to the set, with values in the interval [0, 1]. Thus, the membership function reflects the subjective degree of confidence of an expert that a particular value of the base scale corresponds to a given fuzzy concept. Two primary approaches are used to define membership functions: tabular and analytical. In the analytical approach, the most common types of membership functions include triangular, trapezoidal, S-shaped, Z-shaped, and U-shaped forms.

3.1. Formal Semantics of RVML

Formal semantics of RVML can be presented in the extended Backus–Naur notation (EBNN):

RVML = {Fact}, {Template}, {Rule}, {Relationship}, {FuzzyVar}, {GeneralizedRule}.

Rule = (Condition {Condition}), Core, (Action {Action}).

Condition = ConditionElement {ConditionElement}.

Action = ActionElement {ActionElement}.

ConditionElement = ConditionOperator, Fact {Fact} | ConditionOperator, ConditionElement.

ActionElement = ActionOperator, (Fact {Fact}).

ActionOperator = “Add” | “Delete” | “Modify” | “Stop”.

ConditionOperator = “AND” | “OR” | “NOT”.

Fact = Name, ConfidenceFactor, Slot {Slot}.

Slot = Name, Constraint, Value, [DataType], [Term].

Core = Name, ConfidenceFactor, Priority.

Name = String.

Value = Number | String | Set.

String = Symbol {Symbol}.

Symbol = “A”| “B” | “C” | “D” | “E” | “F” | “G” | “H” | “I” | “J” | “K” | “L” | “M” | “N” | “O” | “P” | “Q” | “R” | “S” | “T” | “U” | “V” | “W” | “X” | “Y” | “Z” | “a” | “b” | “c” | “d” | “e” | “f” | “g” | “h” | “i” | “j” | “k” | “l” | “m” | “n” | “o” | “p” | “q” | “r” | “s” | “t” | “u” | “v” | “w” | “x” | “y” | “z” | “-” | “_” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9” | “0”.

Set = Value “;” {Set}.

Constraint = “>“ | “<“ | “=“ | “>=“ | “<=“ | “<>“.

ConfidenceFactor = [0,1].

Priority = [1,100].

Template = Name, Slot {Slot}, FuzzyVar {FuzzyVar}.

DataType = “String” | “Number” | “Fuzzy”.

Relationship = Element, Connection, Element.

Connection = Kind, Name.

Kind = “Association” | “Dependences”.

Element = Condition | Action | Template | Core | FuzzyVar | Term | Fact.

Term = Name, FunctionType, TermValue {TermValue}.

TermValue = Value, Probability.

Probability = [0,1].

FuzzyVar = Name, Term {Term}, Domain, Units, FunctionType.

FunctionType = Tabular | Analytical.

Tabular = “T”.

Analytical = “A”.

Domain = “[“ Number {Number} “,” Number {Number} “]”.

Number = “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9” | “0”.

Units = String.

GeneralizedRule = Template {Template}, Core, Template {Template}.

3.2. The Meta-Model of RVML/FuzzyRVML

Following core MDE principles, we developed the RVML/FuzzyRVML meta-model (Figure 1). This design integrates formalization results and explicitly defines language constructs to support automated transformations.

3.3. Visual Elements of RVML

The design of novel visual languages should be grounded in established cognitive theories and design principles, for example, Moody’s “Physics of Notations” [35]. Our design builds on UML visual elements [36], specifically adapting components from class and object diagrams. We intentionally increased the graphical distinction between symbols to align with Moody’s concept of “visual distance.”

RVML includes eight visual elements (Figure 2 and Figure 3), with five basic and three used in the FuzzyRVML extension.

Basic elements:

• The fact template (Figure 2, (1)) is used to describe fact templates and parts of generalized rules (rule templates), such as condition and action. It includes the name and description of the slots. Additionally, each slot contains its own name, data type, and default value.
• The nodal element (or core) of the rule (Figure 2, (2)) is the connecting conditions and actions in the form of facts. The nodal element allows one to represent the name of the rule, the confidence factor (CF), and the priority (P).
• The fact, as the action element (or the consequence) of the rule (Figure 2, (3)), is used to represent facts that are manipulated in working memory. This element enables representation of the name of the fact and its description through certain slots, as well as the confidence factor (CF).
• The fact, as the condition element (or the antecedent) of the rule (Figure 2, (4)), is used to represent the facts that activate the rules in the working memory. To indicate their controlling nature, and by analogy with control flow diagrams, a dotted image of all lines of a graphic element is used. This element enables representation of the name of the fact and its description through certain slots, along with the confidence factor (CF).
• The connection between the elements (Figure 2, (5)) is represented as an association containing a node for displaying an operation with facts in working memory: “+”—adding; “−”—deleting; “~”—changing; “!”—stopping logical inference.

Extension elements are depicted using thin dotted lines to convey inherent uncertainty or fuzziness:

• A fuzzy or linguistic variable (Figure 3, (1)) contains information about the name of the variable, the range of possible values, units of measurement, the type of membership function, and terms.
• A term (Figure 3, (2)) defining the value of a certain fuzzy variable according to a membership function. It contains the name, type of membership function, and possible values indicating their probability.
• The connection between the elements (Figure 3, (3)) is presented as a relationship that captures the relationship between a fuzzy variable and its terms (Figure 3, (4)), as well as between patterns and fuzzy variables (Figure 4, (1)), and between facts and terms (Figure 4, (2)).

The basic elements and extensions can be used together (Figure 4).

3.4. The Transformation of RVML/FuzzyRVML Elements to Program Code

One of the purposes of RVML is to bridge the semantic gap between visual models and program code. In this regard, an unambiguous correspondence is ensured between the graphic elements of RVML/FuzzyRVML and the language constructs of programming languages for intelligent systems, in particular, CLIPS/FuzzyCLIPS and DROOLS. This correspondence is further used to implement automated code generation.

Table 1. Examples of mapping RVML/FuzzyRVML elements to CLIPS/FuzzyCLIPS code.

RVML/FuzzyRVML	CLIPS/FuzzyCLIPS
The confidence factor in the rules

shows examples of correspondences.

3.5. Advantages of RVML/FuzzyRVML and Comparison with Other Languages

The current RVML specification (3.2024) [37] targets simple rule descriptions. Consequently, several programming constructs remain unsupported. These include procedures, functions, variables, and calculated values. In the future, it is planned to add support for OCL [38].

Compared to other languages (

Table 2. Comparison of DSLs that can be used for visual modeling/programming declarative knowledge bases containing logical rules.

DSL	The Main Advantages	The Main Disadvantages	Software Support	Related Languages/Standards
URML	Standard UML elements are used: class and association.	A complex mechanism for denotation of conditions through associations; the use of a new graphical element for the rule node (non-UML); there is no code generation/transformation for knowledge base programming languages (only visualization of structures).	Yes	UML, OCL
DESIRE (DEsign and Specification of Interacting REasoning components)	The ability to form chains of actions (component execution).	The complexity of detailing the description of states and transition conditions; there is no code generation/transformation for knowledge base programming languages.	Yes
Flowchart	The ability to form chains of actions in the form of tree-like structures.	The ability to describe only simple states and transition conditions; there is no code generation/transformation for knowledge base programming languages.	Yes
XTT2	The ability to form chains of actions.	There is no code generation/transformation for knowledge base programming languages	Yes
MML	Standard UML elements are used: class and association.	There is no code generation/transformation for knowledge base programming languages.	No	UML
SCg	The ability to form chains of actions in the form of graphs.	Original node elements with additional semantics; interpretation of knowledge bases is carried out within the framework of the author’s platform.	Yes	SC (Semantic Code)
Concept maps	The ability to form structures describing logical dependencies (cause-and-effect relationships) in the form of graphs.	There is no code generation/transformation for knowledge base programming languages	Yes
Fishbone diagrams	The ability to form structures describing logical dependencies (cause-and-effect relationships).	Limited popularity mainly among domain experts; there is no code generation/transformation for knowledge base programming languages (only visualization of structures).	Yes
UML	It is widely used in software engineering; it contains diagrams both for describing static data structures and their dynamics.	The complexity of setting constraints for the values of properties (OCL is used) and conditions through associations and the mechanism of stereotypes; there is no code generation/transformation for knowledge base programming languages (only visualization of structures).	Yes	OCL
SysML	It is widely used in software and system engineering (as well as UML); it provides the description of static data structures and their dynamics.	The complexity of setting constraints for the values of properties (OCL is used) and conditions through associations and the mechanism of stereotypes; there is no code generation/transformation for knowledge base programming languages (only visualization of structures).	Yes	OCL
RVML	Elements based on standard UML elements are used: class, association, and dependency; the ability to set priorities for rules, confidence factors, and constraints for property values without using OCL; explicit support for fuzziness; code generation/transformation for knowledge base programming languages (CLIPS, DROOLS).	Limited popularity among specialists; the difference between the basic RVML elements and the standard elements of UML.	+	UML

), RVML/FuzzyRVML is not a commonly used modeling language. Its visual elements are similar to UML elements, and it has the following advantages:

• RVML uses specialized graphical elements for all components of the rules, rather than one typical element characterized by a stereotype (as in UML).
• It provides an unambiguous visual indication of the actions produced by the rules: adding, deleting, changing facts, and stopping logical inference.
• RVML provides setting priorities for rules, confidence factors, and constraints for property values without using OCL.
• It can be considered as a UML extension profile using the terminology of class diagrams (“class”, “association”, “dependency”) and focused on modeling logical rules.
• RVML abstracts away from specific knowledge representation and programming languages by expressing logical rules in a generalized form.
• It can be used to model incompleteness and fuzziness and contains specialized elements: a data type (Fuzzy); a linguistic (fuzzy) variable (FuzzyVar), a set of fuzzy terms as possible values of the linguistic variable, and a confidence factor.
• RVML can be used to generate program code (supports direct mapping of graphic elements to code) for CLIPS, FuzzyCLIPS, Drools, etc.

The main conceptual difference in RVML is the presence of graphically distinguishable symbols for modeling elements of logical rules.

RVML differs methodologically from most DSLs in its core application scope. It is specifically designed to build both platform-independent and platform-specific knowledge base models, enabling their direct transformation into executable code within an MDE workflow.

RVML demonstrates remarkable alignment with the 2024 GI-Dagstuhl seminar priorities on human factors in MDE [39]:

(a) Modeler Experience (MX) Factors. RVML directly addresses several identified MX factors:

• Language Complexity: RVML reduces complexity through specialized graphical elements for each rule component (vs. UML’s stereotype-based approach).
• Intrinsic Motivation: Clear visual separation of rule components enhances perceived benefits.

(b) Cognitive Effectiveness. RVML applies Moody’s “Physics of Notations” principles:

• Visual Distance: Intentionally increased graphical distinction between symbols.
• Semantic Transparency: Elements directly represent their meaning (dotted lines for conditions, solid for actions).

Conceptual Novelty of RVML:

(a) Specialized Visual Syntax for Rule Components. Unlike UML extensions (URML, MML) that use stereotypes, RVML provides: five basic elements, three FuzzyRVML extensions, unambiguous action indication.

(b) Native Support for Declarative Knowledge Base Features: rule priorities (1–100), confidence factors [0, 1], property constraints without OCL, fuzzy logic support;

(c) Automated Code Generation Bridge. Unlike most visual DSLs (VisiRule, DESIRE, concept maps) that only visualize structures, RVML enables: direct transformation to CLIPS/FuzzyCLIPS, DROOLS, PHP; MDE pipeline integration.

4. Evaluation and Discussion

In earlier work [31], we evaluated RVML tools for developing declarative knowledge bases in CLIPS format within an MDE context using task completion time, and error rate scores. Experiments indicated up to 50% faster development of classical expert systems in some cases. However, that evaluation did not account for learning time or knowledge base complexity.

This study focuses exclusively on evaluating the language itself, rather than the supporting software tool. Therefore, firstly, based on the test examples from [31], we created a new dataset of 20 tasks to test whether the RVML elements were sufficient to cover the modeling of declarative knowledge bases containing logical rules. Secondly, we ran a group user study in which participants evaluated the properties of RVML in the context of modeling logical rules, as well as its preference in the presence of other languages. Finally, we summarize our findings on using RVML in two industrial cases.

We conducted all our experiments at the Institute of Information Technology and Data Analysis of the National Research Irkutsk Technical University (INRTU). Since 2018, RVML has been included in educational process of INRTU, so every year an average of 60 students studying the courses “Information Systems Design” and “Information Systems Tools” are introduced to this language and specialized software. Thus, the study participants are familiar with the basics of software design and the construction of conceptual models (UML and concept maps). They also have some background in the field of creating classical expert systems and knowledge bases. It was these students who voluntarily and without compensation participated in the group study.

4.1. An Experiment to Check the RVML Completeness of Use

In this section, we evaluated the completeness of using the basic RVML elements when creating declarative knowledge bases.

4.1.1. Data

Currently, there are no standard datasets for evaluating the effectiveness or completeness of visual languages for modeling declarative knowledge bases and their support tools, so we evaluated RVML on tasks from the INRTU educational process. We used our own dataset of 20 tasks (a fragment available in Supplementary Materials) involving the development of declarative knowledge bases for intelligent diagnostic and forecasting systems in different domains based on the principles of visual modeling. To ensure replicability and constrain session duration, we imposed limits on the number of model elements (

Table 3. Constraints on the number of model elements for test tasks.

No. Entities	No. Properties of Entities	No. Connections Between Entities	No. Cause-and-Effect Relationships (Possible Generalized Rules)	No. Instances of Cause-and-Effect Relationships (Possible Concrete Rules)
4–8	1–3	3–9	2–5	10–15

). Statistical data on tasks are presented in

Table 4. Test tasks’ statistics.

Task No.	Domain	No. Entities	No. Properties of Entities	No. Connections Between Entities	No. Cause-and-Effect Relationships (Possible Generalized Rules)	No. Instances of Cause-and-Effect Relationships (Possible Concrete Rules)
01	Diagnosis of a car	8	28	9	5	10
02	Diagnosis of TVs	7	22	6	4	10
03	Toaster troubleshooting	6	19	5	4	10
04	Computer troubleshooting	5	15	5	3	11
05	Diagnosis of the flu incidence rate	7	17	6	3	12
06	Diagnosis of angina	5	14	4	4	10
07	Electric kettle troubleshooting	5	19	4	3	14
08	Diagnosis of cell phone malfunctions	4	11	3	3	14
09	Diagnosis of the iron	5	14	5	3	15
10	Weather prognosis	5	14	4	3	12
11	Forecasting the currency exchange rate	5	13	5	3	10
12	Forecasting the price of gasoline	5	11	5	3	10
13	Crop forecasting	6	13	7	3	10
14	Forecasting public opinion	5	10	7	4	10
15	Mood forecasting	6	12	5	4	10
16	Forecasting the crime rate	5	14	4	4	10
17	Morbidity prediction	6	18	5	2	10
18	Wildfires prognosis	6	15	7	3	10
19	River flood hazard prognosis	6	19	5	3	11
20	Forecasting the birth rate	6	20	7	3	12

.

4.1.2. Implementation Protocol

In our investigation, we developed different types of models for each of the tasks, including concept maps, UML, and RVML diagrams using basic elements. We evaluated the completeness of RVML element usage and assessed how well RVML preserved the key concepts and relationships found in concept maps and UML class diagrams. Semantic correspondence was evaluated using a qualitative criterion. The scale includes three values: “no semantic correspondence” (−), “partial correspondence” (+/−), and “complete correspondence” (+). Semantic correspondence was determined by group expert analysis. It was attended by three experts from the staff of the Laboratory of Information and Telecommunication Technologies for the Study of Technogenic Safety at the Matrosov Institute for System Dynamics and Control Theory, Siberian Branch of the Russian Academy of Sciences. Experts determined the presence of key domain entities and relationships in the constructed models. The final assessment was formulated by summarizing their individual assessments.

4.1.3. Results

The results for the tasks are presented in

Table 5. Usage results of the basic RVML elements in test tasks, as well as on the semantic correspondence of the constructed models.

Task No.	No. Fact Templates	No. Nodal Elements	No. Fact Elements	No. Condition Elements	No. Connections	Semantic Correspondence
01	8	15	16	12	42	+
02	7	14	20	16	36	+
03	6	14	19	15	35	+
04	5	14	14	14	34	+
05	7	15	11	21	39	+
06	5	14	10	10	36	+
07	5	17	10	14	34	+
08	4	17	10	10	16	+
09	5	18	10	17	35	+
10	5	15	20	10	35	+
11	5	13	13	13	34	+
12	5	13	13	13	34	+
13	6	13	16	16	42	+
14	5	14	14	13	38	+
15	6	14	12	10	31	+
16	5	14	10	10	28	+
17	6	12	10	25	42	+
18	6	13	16	16	42	+
19	6	14	13	14	27	+
20	6	15	16	16	42	+

. The analysis of the obtained results shows all basic RVML elements were used in modeling logical rules.

4.2. Group User Study

In this section, we present a group user study to evaluate the effectiveness and user-friendliness of the RVML, and to determine the extent to which it is preferred over modeling languages in the context of creating declarative knowledge bases.

4.2.1. Data

For our evaluation, we used the dataset from the previous section (Table 4). For each of the 20 tasks, in addition to the formal text description, we developed sets of diagrams: concept maps, UML, and RVML diagrams.

An example of fragments of models for one of the tasks is shown in Figure 5, Figure 6 and Figure 7.

4.2.2. Implementation Protocol

A total of 464 students participated in our study; they were senior students who had already completed courses in modeling and designing intelligent systems. The consent was voluntary; participants could terminate their participation in the study at any time, as well as withdraw their results. The consent form is provided in the Supplementary Materials.

Participants reviewed the constructed models. They then completed a structured questionnaire. Prompts included the following: “RVML is easier to learn,” “RVML is easier to use,” “RVML is more semantically expressive,” and “RVML is more user-friendly.” The full instrument is in the Supplementary Materials. Participants were also asked to evaluate the preferred modeling notation/language (UML/RVML/Concept (mind) maps). When processing the survey results for the entire study period, we used Likert scales [40] with the following values: strongly disagree, disagree, neutral, agree, strongly agree.

4.2.3. Results

The results of statistical processing of responses after anonymization and generalization are presented in Figure 8 and Figure 9, and also in

Table 6. Survey statistic summary table. The survey prompts are indicated as follows: (I.1) “RVML is easier to learn.”, (I.2) “RVML is easier to use.”, (I.3) “RVML is more semantically expressive.”, (I.4) “RVML is more user-friendly.”, (II.1) “I prefer the mind (concept) maps when modeling declarative knowledge bases.”, (II.2) “I prefer the UML when modeling declarative knowledge bases”, (II.3) “I prefer the RVML when modeling declarative knowledge bases.”.

Statistic/Prompt.	I.1	I.2	I.3	I.4	II.1	II.2	II.3
N	464	464	464	464	464	464	464
Mean	4.33	4.21	3.94	4.03	1.34	2.64	4.66
Median	4	4	4	4	1	2	5
Mode	4	4	4	4	1	2	5
Standard Deviation	0.51	0.41	0.73	0.36	0.51	0.85	0.51
Standard Error	0.024	0.019	0.034	0.017	0.027	0.040	0.024
One-sample t-test, t	56.12	63.68	27.73	61.68	−62.64	−9.11	70.04
Chi-square GOF, χ2	742.97	1089.10	367.91	1312.50	843.18	494.32	822.89
Binomial test, z	20.69	21.55	8.62	19.40	19.40	2.16	20.69
Cohen’s d	2.61	2.95	1.29	2.86	−2.91	−0.42	3.25
Cramer’s V	0.63	0.77	0.45	0.84	0.67	0.52	0.67
Probability of Superiority, P	0.98	1.00	0.70	0.95	0.95	0.87	0.98

.

Survey results (Figure 8) indicate that RVML is an accessible visual DSL. Specifically, 63% of respondents agreed that it is easy to learn, 35% strongly agreed, and only 2% remained neutral. However, respondents noted that the ease of learning is due to RVML’s similarity to the basic elements of UML. Respondents with a neutral opinion explained that their assessment was due to some difficulties in understanding the elements of FuzzyRVML. Statistical analysis reveals strong respondent consensus and uniformly positive evaluations (Table 6, Col. I.1). The data show no polarization and high estimation reliability. Detailed results are provided in the Supplementary Materials.

All respondents noted the ease of using RVML: 79% agreed and 21% strongly agreed. They attributed this to the clear visual separation of RVML graphical elements when describing distinct logical rules components (core, condition, and action). According to Table 6 (Col. I.2), exceptional respondent consensus, uniformly positive evaluation, and genuinely high levels of approval are observed.

The assessment of RVML’s semantic expressiveness was mixed: 46% agreed; 24% strongly agreed (positive responses accounting for 70% in total), while 30% were neutral. Respondents explained their neutral assessment primarily by certain expectations of RVML: considering it as an extension of UML, they did not find some mechanisms in it, in particular the implementation of the inheritance relationship. Addressing this may be a further direction for improving RVML. Statistical analysis (Table 6, Col. I.3) confirms positive evaluation consensus, no negative ratings, and moderate variability.

RVML’s user-friendliness score turned out to be quite high: 87% agreed and 8% strongly agreed (positive responses accounting for 95% in total), with 5% neutral. As with ease of learning, neutral respondents noted some difficulties in modeling fuzziness. According to Table 6 (Col. I.4), it can be noted that there is almost complete agreement among the respondents, whose opinions are closely grouped around value 4 (“agree”).

When determining the most preferred modeling language for designing declarative knowledge bases, the majority of respondents showed a clear preference for RVML (Figure 9). The survey results (Figure 9) suggest that concept maps are not very attractive to users when modeling declarative knowledge bases in the form of logical rules. No respondents agreed that they were more preferable: 71% strongly disagreed, 24% disagreed, and 5% remained neutral. The overall high negative rating (95%) stems from the excessive detail of this notation, which leads to “visual overload” of diagrams, as well as semantic limitations in the context of the task being solved. Neutral respondents noted usefulness of concept maps in modeling the structural aspects of the domain and indicated that these models can be considered computation-independent as a basis for transitioning to logical rules. Based on the results of statistical processing of data (Table 6, Col. II.1), the following conclusions can be drawn: exceptional negative consensus, dominance of the minimum rating, and genuinely low levels of approval.

Respondents showed a stronger preference for UML in rule modeling compared to concept maps. Specifically, 55% disagreed with its suitability, 32% were neutral, 7% agreed, and 6% strongly agreed. While UML is universally used in software engineering and well suited for describing key software abstractions, some researchers note its shortcomings in terms of expressive power [41]. In the context of our study, the negative assessment of UML as the main means of modeling logical rules was due to the difficulty (or the impossibility) of defining constraints for property values (without using OCL) and conditions through associations and the mechanism of stereotypes. Respondents with neutral or positive ratings cited reluctance to learn additional modeling languages, even UML-like notations, for immediate tasks. The main argument, after generalization, can be expressed as follows: “With the aid of UML, any static and dynamic aspects of the domain (software) can be modeled.” Using the statistical data (Table 6, Col. II.2), we can conclude that a concentration of 87% of responses on options 2–3 indicate general agreement among respondents in their cautiously negative evaluation.

The respondents’ preference for RVML in logical rule modeling turned out to be quite high: 2% were neutral, 30% agreed, and 68% strongly agreed. The majority of respondents noted that they consider it a specialized add-on to UML, focused on modeling logical rules. A statistical analysis of the responses showed (Table 6, Col. II.3) an exceptional positive consensus and dominance of the maximum rating. It should be noted that we also do not consider RVML a substitute for UML within MDE. We developed RVML as an additional domain-specific visual language for solving a specific task—modeling declarative knowledge bases. Moreover, the use of automatic transformation implemented in our tool allows one to obtain RVML from other conceptual models, including UML class diagrams and concept maps.

The results obtained also do not contradict the principles of Moody’s “Physics of Notations” [41] and Frank’s DSL design guidelines [42], which are not related to icons, color, and text. RVML identifies individual categories of concepts. It also defines distinct graphical elements for each category. In contrast, concept maps and UML class diagrams use a single graphic element to display all concepts. Of course, it was stated in [42] that there is no convincing precise definition of visual distance, but in our survey, RVML has a larger one, which, according to [42], provides faster recognition of concepts and more efficient use of the modeling language in the case of modeling cause-and-effect relationships.

4.3. Industry Experiences with RVML

This section presents two industrial case studies that further demonstrate RVML’s practical utility in modeling declarative knowledge bases and generating executable code. Several more examples of industrial applications are provided on the website [43].

4.3.1. An Overview of the Software for RVML

In these cases, we used our EUD software [44], which provides the RVML support. Figure 10 shows the screen of the Personal Knowledge Base Designer (PKBD). The main features of PKBD are the following capabilities:

• loading/importing a computation-independent model in the form of concept maps (IHMC Cmap Tools) [45], state transition diagrams and event trees (Knowledge Base Development Service) [46], OWL ontologies (Protege), UML class diagrams (IBM Rational Rose, StarUML, XMind), and canonical spreadsheets (TabbyXL) [47];
• automatic transformation of imported computation-independent models into platform-independent models, advising the RVML metamodel (Figure 1);
• representing knowledge base elements in RVML format and defining them for code generation;
• generation of program code for the following platforms: CLIPS, DROOLS, PHP.

4.3.2. Case 1: Designing a Knowledge Base for Interpretation of Emotion Signs

In cooperation with Smart Technologies LLC (Irkutsk, Russia), the task of creating a prototype of one of the modules of the HR Robot recruitment system was solved. The HR Robot supports recruitment decision-making, evaluates candidate suitability, assesses staff motivation, and analyzes team psychological dynamics based on video interview analysis. One of the main modules of the system is the module for interpreting signs of emotions detected on video based on logical rules [33].

Class diagrams describing the main parts of the face and their elements were used as the initial information for the formation of the module’s knowledge bases. This model, together with information from a psychologist, was interpreted as a computation-independent model (Figure 11, (1)).

We uploaded class diagrams to PKBD, and a knowledge base was formed, the elements of which were represented in the form of RVML (Figure 11, (2)). Based on RVML, program code was generated in CLIPS (for debugging) and PHP (for integration into the software) (Figure 11, (3)). Multiple knowledge base variants were developed for different emotions, with the largest containing 225 rules. In particular, for the “fear” emotion the generated CLIPS code contained 1327 lines.

The use of RVML in conjunction with decision tables enabled a psychologist to directly participate in describing the domain and formulating specific logical rules. Furthermore, the specialist noted a preference for RVML over UML due to its higher intuitive clarity (user-friendliness).

4.3.3. Case 2: Designing a Knowledge Base for Forecasting the Risk of a Forest Fire

RVML and its supporting software were used to solve the task of predicting the risk of wildfires in certain forest areas [32] based on AI methods. The work was carried out under the projects of the Ministry of Science and Higher Education of the Russian Federation, Grants Nos. 075-15-2020-787 and 075-15-2024-533 [48].

When solving this task, three approaches to forming fire risk assessments in forest areas were considered:

• Based on a statistical analysis of information about fires in the previous period, taking into account a specific forest section and time interval.
• Based on classical artificial intelligence methods, in particular, rule-based and case-based expert systems [49]. These methods involve not only statistical processing of large amounts of data but also conceptual modeling and data mining in order to find patterns and formalize them subsequently in the form of logical rules and cases.
• Based on machine learning methods, in particular, Random Forest [50].

In the second case, we developed a knowledge base for analyzing and predicting the risk of a forest fire using information about the fire hazard class of forests, weather conditions, and other factors. The main model used was adapted from [49] (Figure 12), which describes key concepts and relationships in the form of a UML class diagram.

We used RVML to design a logical rule structure (Figure 13, (1)), which enabled the automated generation of decision tables. These tables integrate satellite data on thermal points across the Baikal Natural Territory from 2017 to 2020. Each generated rule could be viewed and edited in the form of an RVML model (Figure 13, (2)). This task is discussed in more detail in [49,50].

4.3.4. Analysis of RVML Usage Completeness in Case Studies

Analysis of the case studies demonstrates complete utilization of basic RVML elements, while the FuzzyRVML extension remained unused. This reflects the nature of the selected tasks, as none required fuzzy modeling. As this experience shows, the experts tended to use simple constructs when describing logical dependencies.

4.4. Threats to Validity

Our experiments evaluated RVML’s element completeness, learnability, usability, and user preference. However, we identified several factors that may limit the validity of our findings, particularly for the group user study:

• The level of understanding of the principles of developing declarative knowledge bases: Despite initial training, some participants may have misunderstood RVML’s purpose, interpreting it as a language for static conceptual modeling rather than for defining cause-and-effect rules.
• Prior modeling expertise: Participants had completed courses in UML and expert systems, potentially biasing results toward UML-inspired notations and inflating perceived ease of learning. However, due to having certain preferences, some respondents maybe have found it quite difficult to perceive RVML ideas.
• Ease of representation when modeling: Case studies revealed that developers preferred simple rule constructions and actively avoided fuzzy logic elements. This preference significantly reduced the perceived relevance of the FuzzyRVML extension.
• Subjective evaluation metrics: User study relied primarily on Likert-scale self-reports rather than objective performance measures (task completion time, error rates, and model correctness).
• Homogeneous participant pool: All 464 participants were senior students from a single institution (INRTU), limiting demographic, cultural, and professional diversity.

5. Conclusions

In this work, we propose RVML, a domain-specific visual language that assists end-users in modeling declarative knowledge bases containing logical rules. RVML supports code generation in multiple languages for rules corresponding to its meta-model. Building on refined UML graphical elements, RVML serves as a UML extension profile for modeling logical rules. Within MDE workflows, it provides explicit visual notation for rule actions, priorities, confidence factors, and property constraints (slots).

The theoretical and practical implications of the proposed language are as follows:

• Advances DSL design theory: Demonstrates how UML-inspired visual elements can be systematically adapted for rule modeling while preserving semantic clarity and cognitive accessibility.
• Formalizes fuzzy rule semantics: Provides a structured approach to representing uncertainty through FuzzyRVML, integrating membership functions and confidence factors into visual rule modeling.
• Contributes to MDE methodology: Suggests a new formalism for building platform-independent and platform-specific models. Based on RVML’s features, we define its role within the standard MDE pipeline. The pipeline systematically transforms models across varying abstraction levels to generate executable code or specifications (Figure 14). This scheme is very often implemented in an abbreviated form, but in our case studies, we used exactly this sequence. We expand the stage of building a platform-independent model by creating specialized RVML models that describe the logical rules of declarative knowledge bases.

• Enables end-user development: Non-programming domain experts can construct declarative knowledge bases through intuitive visual modeling, reducing reliance on specialized developers. Moreover, our tool explicitly assumes a description of key abstractions in the form of a UML class diagram, followed by their automatic transformation into RVML structures that can guide end-users in constructing simple logical rules.
• Supports automated code generation: PKBD tool enables transformation from RVML models to executable code in CLIPS, FuzzyCLIPS, DROOLS, and PHP, facilitating deployment across platforms.
• Validated in industrial contexts: Case studies in HR analytics (emotion recognition) and environmental monitoring (wildfire risk forecasting) demonstrate real-world applicability and scalability.

Key limitations of our language include the current focus on simple “IF-THEN” rules; complex rules with procedures, functions, or calculated values remain unsupported, which limits applicability to advanced knowledge engineering tasks. We have experimentally validated the user-friendliness and effectiveness of RVML and its associated software, showing its superiority over other visual languages for declarative knowledge base engineering. Case studies reveal limited practical demand for FuzzyRVML, reflecting both the complexity of fuzzy logic frameworks and the prevalence of simple rule structures in real-world applications. Despite this, all basic RVML elements were fully utilized.

Future research will address the following directions:

• Integrate OCL support: Extend RVML syntax and semantics to support OCL for expressing complex property constraints without textual code.
• Extend to procedural knowledge: Evolve RVML to support hybrid knowledge representations combining declarative rules with procedural constructs (functions, loops, variables).
• Develop automated model validation: Create testing frameworks for RVML models to verify logical consistency, rule coverage, and transformation correctness prior to code generation.