From Rule Engines to Ontologies: An OWL 2 DL Approach for Domain-Specific Evaluation Information Systems

Abstract

Domain-specific information systems often maintain their data model, rule base, and application infrastructure as separate artifacts, complicating maintenance and pre-deployment verification. This study investigates whether these artifacts can be unified in a verifiable ontology-to-code pipeline without changing the expected classifications. The proposed Model-Driven Architecture uses the Business Application Builder framework and a Web Ontology Language 2 Description Logic ontology to represent domain structure, classification rules, and generation metadata. HermiT verifies consistency, satisfiability, and subsumption under open-world semantics before code generation. The generator produces persistence, business-logic, data-transfer, and presentation layers, while the generated Java application evaluates stored records under closed-world semantics and resolves overlapping categories using ontology-declared priorities. In a Serbian research-evaluation case study, the generated system reproduced the M30 and M33 classifications of an established Jess implementation. An internal secondary experiment generated and executed a prenatal-diagnosis application; all six runtime classifications matched the HermiT entailments and expected outcomes. The public artifact independently reproduces the ontology-level experiments but excludes the proprietary generator and generated source code. The results support the feasibility of ontology-driven generation for static-classification systems, whereas arithmetic risk computation and temporal event processing remain better suited to complementary procedural technologies. No performance superiority is claimed.

1. Introduction

Numerous software systems are designed primarily to encode domain-specific expert knowledge into formal, machine-executable rules. These systems span remarkably different domains while sharing a common architecture. In the research evaluation domain, national bodies prescribe rulebooks that define how scientific publications are categorized and scored, determining researcher appointments, institutional rankings, and funding allocations [1]. In the clinical domain, prenatal care requires tracking dozens of parameters across trimesters, screening tests for chromosomal abnormalities, symptom-based disease diagnosis, and real-time cardiotocography (CTG) monitoring, each governed by established medical protocols that can be expressed as conditional rules [2,3]. In both cases, the core challenge is identical: expert knowledge must be captured in machine-executable form, embedded within a functioning software system, and maintained as the underlying rules evolve.

The dominant approach to building such systems relies on procedural rule engines. Procedural rule engines, including the C Language Integrated Production System (CLIPS), originally developed by NASA [4], Jess, and Drools, have been the standard tools for such systems for over three decades. In research evaluation, Nikolić et al. [5] used the Jess expert system shell to automate the classification of conference papers according to the Serbian national rulebook, where rules were written in Jess’s rule language (forming the knowledge base) and facts were instances of Common European Research Information Format (CERIF) entity objects, with the inference engine performing pattern matching, salience-based conflict resolution, and rule execution. The system categorizes conferences as international (M30) or national (M60) based on criteria including committee composition, presentation language, and organizer type, and then assigns result categories (M31–M36) to individual publications. In prenatal care, Filipović et al. [6] developed a pregnancy monitoring system using Drools, a modern open-source rule engine integrated with Spring Boot. This solution comprises three subsystems: disease diagnosis using backward chaining through a decision tree of symptom groups (preeclampsia, eclampsia, kidney disease, gestational diabetes), chromosomal abnormality detection from double, triple, and quadruple screening tests using template-based rules, and real-time CTG monitoring using template-based rules together with Complex Event Processing (CEP) for temporal pattern detection of fetal heart rate and contraction events, with all rules utilizing salience.

Despite addressing fundamentally different domains, science policy and clinical medicine, and using different rule engines separated by two decades of software evolution (Jess, introduced in 1995, and the more recent open-source Drools engine), both systems exhibit the same architectural pattern: (1) a manually developed data model for domain entities, (2) a procedural rule base written in an engine-specific language, and (3) a manually coded application infrastructure (persistence layer, service layer, web interface). We refer to this recurring decomposition as the three-artifact pattern: a development style in which the structural domain model, the executable rule logic, and the surrounding application infrastructure are authored as three independent artifacts in three distinct languages, with no shared formal source from which they can be derived or against which they can be checked. This three-artifact pattern introduces three recurring limitations that are inherent to the approach rather than specific to any rule engine.

First, there is no formal mechanism for verifying whether the rule base is internally consistent. In research evaluation, contradictory rules could assign different categories to the same conference; in prenatal care, conflicting diagnostic rules could suggest incompatible conditions for the same symptom pattern. Such errors are detectable only through exhaustive testing or by encountering incorrect results in deployment. Second, changes to domain knowledge require coordinated updates across all three artifacts: the data model, the rule files, and the application code, creating a maintenance burden that grows with system complexity. When the Serbian Ministry revises evaluation thresholds or when new diagnostic criteria emerge for gestational diabetes, the change must propagate manually through multiple files in different languages (Java, Jess/Drools, and SQL). Third, the engine-specific rule language creates an interoperability barrier: Jess rules cannot be consumed by Drools, Drools rules cannot be processed by Semantic Web tools, and neither format supports formal reasoning over the rule base as a whole.

Model-Driven Architecture (MDA) [7] offers a principled solution to the synchronization problem by establishing a formal chain from a Platform-Independent Model (PIM) to generated code. However, the dominant MDA toolchain, Unified Modeling Language (UML) for modeling and Query/View/Transformation (QVT) for transformation, has well-documented weaknesses in the context of automated code generation: UML lacks the formal rigor to express complex domain constraints, and QVT transformations tend to evolve into imperative scripts that are themselves difficult to verify [8].

This paper proposes an alternative approach based on the Business Application Builder (BAB) framework [9,10]. This approach replaces UML with an ontology conforming to the Web Ontology Language 2 Description Logic profile (OWL 2 DL), which serves as the PIM. Furthermore, it employs reified implementation mappings, treating transformation rules as first-class ontological entities rather than storing them in external configuration files [11]. Domain rules are formalized as OWL-defined classes rather than procedural rule statements, enabling a Description Logic (DL) reasoner (HermiT) to verify rule base consistency and class satisfiability prior to any code generation. The BAB code generator then automatically produces a complete, multi-layered information system from the validated ontology, eliminating the manual infrastructure development that constitutes the majority of effort in both the Jess-based and Drools-based approaches.

The approach is validated on the research evaluation domain by generating a system that evaluates conference papers according to the Serbian national rulebook, producing results identical to the established Jess-based implementation [5]. A three-way comparative analysis demonstrates that the ontological approach addresses the architectural limitations shared by both Jess and Drools, while also identifying domains, such as real-time CTG monitoring, in which procedural engines’ runtime flexibility provides capabilities that the current ontology-driven approach does not replicate.

This study pursues four objectives and makes four corresponding contributions. First, it formalizes the research-evaluation case in OWL 2 DL, enabling pre-generation checks of consistency, satisfiability, and subsumption. Second, it uses the validated ontology as input to the BAB generation pipeline, avoiding the separate maintenance of a data model, rule file, and application layer. Third, it validates the generated system against the established ICIST 2014 Jess case by comparing the resulting M30 and M33 classifications and by applying fault-injection tests. Fourth, it evaluates cross-domain transferability through a secondary end-to-end prenatal-diagnosis experiment and uses comparison with a Drools-based pregnancy-monitoring system to delimit where ontology-driven static classification is appropriate and where arithmetic or temporal processing still requires procedural engines.

The evaluation is aligned with these objectives and focuses on architectural feasibility rather than runtime superiority. Specifically, it examines whether a unified OWL 2 DL source model can reproduce established classification results, detect semantic defects before code generation, drive the deterministic generation of application layers, and preserve traceability from domain axioms to executable artifacts. A secondary static-classification case is used to examine whether the same pipeline can be transferred across domains without framework-level modifications. BAB is not proposed as a competing runtime inference engine for Jess or Drools; therefore, comparative throughput, CPU and memory utilization, and enterprise-scale load testing are outside the scope of this study, and no performance superiority is claimed.

To properly contextualize this architecture within modern automated software engineering, the proposed approach must be contrasted with recent advancements in Large Language Models (LLMs) for code generation [12,13]. While probabilistic LLM-based tools synthesize code through pattern prediction [12,13,14], the BAB generator operates as a deterministic transformation engine driven by Resource Description Framework (RDF) queries expressed in the SPARQL Protocol and RDF Query Language (SPARQL) [15] and template-based transformations over a validated OWL ontology [16]. This distinction is critical: ontology-driven generation provides traceability and structural correctness verified by DL reasoning [17], in contrast to the stochastic nature of LLM-based code composition. Recent surveys and position papers on LLM-based and neurosymbolic software engineering indicate a growing interest in combining neural code synthesis with symbolic reasoning and traditional software-engineering techniques [18,19]; however, the present work deliberately focuses on a deterministic ontology-first pipeline rather than on LLM-assisted or hybrid code synthesis.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 analyzes two representative rule-based domains, research evaluation and prenatal care, and identifies recurring architectural patterns. Section 4 presents the ontological formalization. Section 5 describes the code generation architecture. Section 6 validates the approach. Section 7 discusses the results and limitations, and Section 8 concludes the paper.

2. Related Work

2.1. Rule-Based Systems: A Cross-Domain Pattern

Rule-based expert systems have encoded domain-specific knowledge for automated decision-making for over four decades [20]. Although the domains differ, the underlying software architecture has remained remarkably stable. We examine two representative systems that illustrate this persistence.

In the context of research evaluation, Nikolić et al. [5] proposed a CERIF-compatible extension for automated assessment of conference papers. Through a comparative analysis of ten national evaluation rulebooks, they identified three sets of evaluation metadata, for conferences, proceedings, and publications, and formalized them as extensions to the CERIF standard [21]. Each evaluation rule was expressed as a Jess rule with pattern-matching conditions over CERIF entity instances. For example, the rule srRuleBook_international_conference checks six paragraphs of conditions: conference existence, language requirements, organizer classification, committee composition metrics, and paper volume, using salience 900 to ensure it fires before lower-priority national conference rules. The system was validated by evaluating a conference paper at ICIST 2014, categorizing the conference as M30 (international) and the paper as M33 (full paper). The surrounding infrastructure (Java classes for CERIF entities, the Jess integration layer, and the evaluation interface) was manually developed. Earlier work on CERIF-based evaluation includes extensions for bibliometric indicators [22] and journal article evaluation [23,24].

For pregnancy monitoring, Filipović et al. [6] developed a prenatal care system with three rule-based subsystems. The first subsystem diagnoses diseases (preeclampsia, eclampsia, kidney disease, gestational diabetes) through backward chaining over symptom groups organized in a decision tree. Symptoms are categorized into groups (headaches, swelling, weight gain, nausea in group one; low thrombocyte levels, high blood pressure, high protein in group two; seizures, loss of consciousness in group three), and diagnosis depends on which groups are activated and the pregnancy week. The second subsystem calculates risk scores for chromosomal abnormalities (Down, Patau, Edwards syndromes) from double, triple, and quadruple screening tests using a variety of rules with different salience values. Specifically, the highest salience parameter used in the system reaches 10,000, establishing an execution hierarchy that ensures critical, higher-priority rules are evaluated and fired before rules with lower salience. Parameters including nuchal translucency, free beta HCG, PAPP-A, AFP, and inhibin-A are compared against week-specific reference values and multiplied by risk coefficients. The third subsystem monitors CTG in real time using Drools’ CEP. By employing template-based rules, this subsystem avoids the need to write multiple similar rules for various fetal heart rate and variability conditions. It aggregates fetal heart rate and contraction data into one-minute windows, classifying variability and heart rate status (normal, non-reassuring, abnormal), and triggering doctor alerts when critical conditions persist (bradycardia for 3 min triggers an alarm; bradycardia for 9 min triggers delivery). The application stack, i.e, Spring Boot, Vue.js, PostgreSQL, and Drools, was manually developed and integrated. Related expert systems for prenatal care include forward-chaining diagnostic systems [25,26] and rule-based CTG classification algorithms [27].

Despite the seven-year gap, different domains, different rule engines (Jess vs. Drools), and different technology stacks (Enterprise JavaBeans (EJB) vs. Spring Boot), both systems exhibit the same three-artifact architecture. Both lack formal verification of rule consistency, both require manual synchronization across artifacts when domain knowledge changes, and both use mutually incompatible, engine-specific rule formats that impede interoperability.

2.2. Decision Model and Notation and Decision-Table Approaches

Beyond procedural rule engines, decision-table-based formalisms represent an important standardization track. The most prominent is Decision Model and Notation (DMN), standardized by the Object Management Group (OMG), which separates decision logic from process logic via Decision Requirements Diagrams, decision tables, and the Friendly Enough Expression Language (FEEL); explicit hit policies (Unique, First, Priority, Any, Collect) define behavior when zero, one, or multiple rules match a given input, providing a clearer alternative to engine-specific salience [28,29]. DMN is therefore directly relevant to rulebook-based evaluation: many of the conditions encoded in the Serbian rulebook (organizer type, presentation language, committee composition, paper counts) take a tabular form that DMN can express transparently and that DMN-compliant engines can execute natively.

The objective of the present work is broader than decision modeling alone. Whereas DMN targets the specification and execution of decision logic, the proposed approach treats the domain model, the evaluation rules, the implementation mappings, and the code-generation metadata as parts of a unified OWL 2 DL ontology; a single source from which both DL reasoning (consistency, satisfiability, subsumption) and a multi-layered information system can be derived. DMN does not provide DL reasoning over class definitions or subsumption hierarchies, and it does not by itself address the generation of persistence, business-logic, data-transfer, or web-presentation layers; conversely, OWL 2 DL is not designed to subsume all decision-table semantics, particularly hit policies, arithmetic aggregation, and procedural execution order.

Hybrid architectures that combine OWL-based domain modeling with DMN-based decision logic have been explored, for example in BIGOWL4DQ [30], which uses DMN tables alongside an OWL and Semantic Web Rule Language (SWRL) rule layer for data-quality reasoning. We adopt OWL 2 DL as the central formalism in the present paper because the validation target (research evaluation) consists primarily of classification rules over static domain individuals, and because the same ontology is intended to drive both reasoning and full-stack generation. A future extension of the BAB framework in which DMN tables specify the decision-rule layer while OWL remains the source artifact for the domain model, reasoning and code-generation metadata is a plausible direction; we discuss this briefly in Section 7.5.

2.3. MDA and Its Limitations

MDA [7] addresses the general problem of synchronizing models and implementations by establishing a formal separation between PIM and Platform-Specific Model (PSM), connected through model transformations. The OMG standardized this transformation process through the QVT specification [31], while the Eclipse ecosystem provided practical tooling through the Eclipse Modeling Framework (EMF) and its Ecore meta-model [32].

However, in the context of generating complete, domain-specific information systems, these standard approaches exhibit significant limitations. UML, even in its executable variants, Foundational UML [33] and Action Language for Foundational UML [34], remains a semi-formal notation: class diagrams lack the expressiveness to capture complex domain constraints without extensive Object Constraint Language (OCL) annotations, and the visual notation is inherently subject to interpretive ambiguity [8]. QVT transformations, originally conceived as declarative mappings, tend in practice to evolve into complex imperative scripts that are themselves difficult to test and verify. The Ecore meta-model, while pragmatically effective, is tightly coupled to Java semantics, which compromises its role as a genuinely platform-independent model [32].

These limitations are particularly acute in the research evaluation domain, where evaluation rules involve complex conditional logic (e.g., a conference is international if its organizer is an international association OR if its committee spans at least five countries AND at least ten papers have foreign authors). Encoding such rules in OCL or QVT is possible but produces artifacts that are difficult to maintain and impossible to formally reason over.

A concrete illustration of these MDA limitations in the same domain is the Kroki tool [35], which produces executable CERIF specifications through a UML-based model-driven pipeline: the CERIF 1.5 model consisting of more than 280 classes is partitioned into 31 packages and edited through mockup-based and lightweight-UML editors, and code generation proceeds from those diagrams into user interface (UI) panels and a Java persistence layer based on the Java Persistence API (JPA). Kroki therefore demonstrates that the UML/QVT/EMF toolchain can deliver a working CERIF-compliant Current Research Information System (CRIS) prototype in the same domain as the BAB framework of Section 2.5, but it also re-introduces the manual synchronization burden that BAB addresses at the ontology layer. Per [35], “developer has to decide how to map CERIF classes to UI of the generated CRIS application”; the entity-to-UI mapping is delegated back to the developer. Equally significant is the scope of what Kroki generates; per [35], “operations common to all entities include search (query by form), display, addition, update, and removal,” which together amount to standard create, read, update, and delete (CRUD) functionality applied uniformly to every CERIF entity. The generated research-information system therefore supports retrieval and persistence of research records but makes no claim about research-evaluation rule logic. Research-evaluation scenarios, such as the priority-resolution mechanism of Section 4.5 and the disjunctive classification rules of Section 4.1, must therefore be added procedurally by the developer on top of the generated CRUD services. The BAB framework of Section 2.5 addresses this gap only within the Conference + Publication showcase of the ResearchEvaluation ontology module, in which BAB extends BAB Core with the babcore:Entity subclasses enumerated in Section 4.1 rather than importing a full CERIF model. Because BAB Core and the BABj platform-specific ontology already supply a uniform PSM persistent-entity mapping, every babcore:Entity subclass is projected to a JPA-annotated Java class without per-entity developer decisions; the entity-to-UI mapping step that [35] reports as a developer responsibility is therefore eliminated for this showcase scope. Ref. [35] documents per-entity transactions, related screen-forms, and report invocation beyond the common CRUD set, yet research-evaluation rule logic is not addressed there, while BAB instead encodes it declaratively in a single OWL 2 DL ontology, as Section 4.1, Section 4.2, Section 4.3, Section 4.4 and Section 4.5 and the Java realization of Section 5 show.

2.4. Ontology-Driven Software Development

Ontology-driven software development (ODSD) represents an alternative to traditional MDA that replaces semi-formal modeling languages with formal knowledge representation languages, primarily OWL [16]. The integration of ontological and software engineering techniques has been explored from multiple directions: using MDA to generate ontologies from UML models [36], using ontologies to enrich and validate UML models [8], and using ontologies as the primary modeling artifact from which software is generated [37,38].

The key advantage of using OWL 2 DL as a modeling language is access to DL reasoning. Standard reasoners such as HermiT [39] can automatically verify model consistency, check satisfiability of class descriptions, and compute subsumption hierarchies, capabilities that are either rudimentary or absent in UML-based toolchains. Recent work demonstrates that formal verification can also be applied to business-process artifacts beyond ontologies: Stoica and Stoica [40] verify workflow constraints by translating workflow specifications into concurrent game structures and expressing the desired properties as Alternating-time Temporal Logic (ATL) formulas evaluated by a database-embedded model checker. Such approaches address process-level correctness but operate downstream of the artifact-generation pipeline, whereas the present approach performs verification at the source-ontology level, before any code or workflow artifact is produced. Furthermore, OWL’s open-world semantics and its grounding in formal logic make ontological models inherently interoperable through established standards (RDF, SPARQL, OWL), unlike the proprietary or tool-specific formats common in the EMF ecosystem.

Several researchers have explored using ontologies specifically for code generation. Strmečki and Magdalenić [41] proposed an ontological model for generating form-based web applications, demonstrating that ontological concepts can be mapped to application components. Pan et al. [37] provided a comprehensive treatment of ODSD, establishing theoretical foundations for integrating ontological and software engineering techniques. More recently, Kompuš [42] argued for ontology as a backbone of future-proof software development, using knowledge graphs populated with ontological data to dictate structures throughout the development pipeline.

However, existing ODSD approaches generally treat ontologies and code generation as loosely coupled activities, relying on ad hoc scripts or external transformation tools to bridge the gap between the ontological model and executable code. None of the existing approaches provides a mechanism for encoding the transformation rules themselves as first-class ontological entities.

The Semantic Web provides several reasoning and validation mechanisms that can support an ontology-driven evaluation framework. Following De Meester et al. [43], rule-based reasoning over RDF graphs covers validation in Shapes Constraint Language (SHACL) and grammar-oriented validation in Shape Expressions (ShEx) as two complementary families with different audit semantics; Hagedorn et al. [44] demonstrate one SHACL application at cross-domain building data. SWRL extends OWL with Horn-like rules that can derive additional class and property assertions about existing individuals, whereas SHACL and ShEx are primarily used to validate graph conformance. Oudshoorn et al. [45] formalize SHACL validation in the presence of ontologies and develop a rewriting technique that reduces ontology-aware SHACL validation to standard validation for ontologies expressed in Horn-ALCHIQ. The BAB framework employs OWL 2 DL with HermiT [39] to derive class membership for each Conference–Proceeding–Publication triple and to establish subsumption relationships between the classification classes. Because the M30 and M60 conditions may overlap, the final evaluation category is selected by the deterministic priority-resolution mechanism described in Section 4.5. Although equivalent classification rules could be expressed in SWRL, OWL 2 DL class axioms were selected because they allow the reasoner to derive and verify the class hierarchy through consistency, satisfiability, and subsumption analysis, which are central to Phase 1 of Section 6.2. The choice of OWL 2 DL is therefore motivated by the need to represent the classification conditions as formally verifiable class definitions and to perform the subsumption checks required in Phase 1 of Section 6.2.

2.5. The BAB Framework

The BAB framework [9] addresses this gap by introducing an architecture where the entire development pipeline, from domain modeling through validation to code generation, is driven by a single OWL 2 DL ontology. The BAB Core ontology [10] serves as a PIM that formally defines the structural and behavioral elements of enterprise information systems: entities, attributes, relations, processes, tasks, validation rules, UI elements, and security constructs. Semantic and taxonomic constraints are expressed as native OWL restrictions, enabling DL reasoning over consistency, satisfiability, and subsumption. Data-integrity validation is treated as a separate application-level concern. OWL 2 DL reasoning retains open-world semantics during ontology verification and classification, whereas the generated Java application evaluates persisted records under closed-world assumptions by explicitly rejecting missing required values. A complementary SHACL layer is identified as a future extension for declarative structural validation of RDF input data [43,46].

The central innovation of the BAB framework is the concept of reified implementation mappings. Rather than encoding transformation rules in external QVT scripts or template configurations, BAB treats each mapping rule as an ontological individual of the ImplementationMapping class, linked to the concept it maps through the hasImplementationMapping property. Each mapping specifies how a PIM concept projects onto a specific technology stack, for instance, how an Entity maps to a JPA-annotated class, how a Form maps to a Vaadin component, or how a Process maps to an EJB service bean. This reification makes the transformation chain transparent, versionable, and queryable via SPARQL.

The code generation process follows a two-step transformation: the first mapping projects the BAB Core ontology to a platform-specific ontology (e.g., BABj for Jakarta EE/Vaadin stack), and the second mapping projects the PSM into the final code via Apache FreeMarker templates, driven by SPARQL queries that extract the structural information needed for each template. The BAB tool prototype accepts an OWL ontology as input and produces a complete Maven project with all architectural layers: persistence (JPA/Hibernate entities), business-logic (EJB service beans), web layer (Vaadin views and forms), and client layer [9].

This architecture has been validated on a proof-of-concept postal information system [10] and through detailed analysis of key framework components such as the AbstractHome class [11]. The present paper extends the application of this architecture to the domain of research evaluation, testing its applicability beyond conventional business information systems.

Because BAB is an author-developed framework with limited prior empirical evaluation, it is treated in this study as an experimental transformation platform rather than as an independently established industrial standard. It was selected because the research question requires three capabilities in combination: an OWL 2 DL source model that supports DL verification, ontology-reified implementation mappings, and deterministic generation of complete persistence, business-logic, data-transfer, and presentation layers. The MDA and ontology-driven software-development approaches reviewed in Section 2.3 and Section 2.4 do not provide this combination within a single pipeline. To reduce framework-specific bias, the evaluation compares the generated classifications with an independently published Jess reference result, reports a traceable input–reasoning–generation–execution chain, and applies fault-injection tests to the verification pipeline. These experiments establish feasibility and internal validity for the two static-classification cases investigated; they do not establish industrial maturity, large-scale performance, or broad generalizability beyond these cases.

The BAB framework occupies a distinct position on the spectrum between ontology-centered validation and full application generation. BIGOWL4DQ [30] couples an OWL quality metasystem with SPARQL-based selection patterns and produces a quality-rule executor targeting Big Data workflows; the framework presented in this work differs in that its generation target is not a quality-rule executor but a full Jakarta EE persistence-service-web tier, and its generated Java layer explicitly separates application-level closed-world evaluation from the deterministic priority-resolution mechanism described in Section 4.5. The CERIF-compatible CRIS extension of Nikolić et al. [5] serves as the procedural comparator used throughout Section 6 and is the only system that has been exercised against the ICIST 2014 test case in the published literature. Bogdanović et al. [9] document the same BAB framework with a focus on rapid development, while the framework version exercised in this work is the one of Bogdanović et al. [10], which adds extensibility and continuous ontology-driven software engineering. Taken collectively, references [5,9,30] define the comparative context within which the BAB framework is currently positioned.

3. Scope Boundary: Static Classification vs. Temporal Event Processing

This section delimits the scope of the proposed ontology-driven approach by analyzing two domains that exhibit the three-artifact pattern but differ fundamentally in their computational requirements. The research evaluation domain consists of static classification rules over fixed metadata; the prenatal care domain combines static diagnostic rules with weighted-arithmetic risk computation and real-time temporal event processing. Comparing the two reveals a suitability spectrum that determines which subset of rule-based systems is amenable to ontological formalization and where procedural engines remain unavoidable. The research evaluation analysis draws primarily on the comparative study by Nikolić et al. [5], which examined evaluation rulebooks from ten countries (Serbia, Macedonia, Montenegro, Bosnia and Herzegovina, Croatia, Slovenia, Czech Republic, Hungary, United Kingdom, and Australia), supplemented by our own examination of the Serbian rulebook as the primary validation target.

3.1. Research Evaluation: Structure and Rules

National evaluation frameworks follow two broad approaches to assessing conference publications. The first is direct expert evaluation, where panels of domain experts assess individual publications on their merit. This approach is used by the Research Excellence Framework in the United Kingdom, Excellence in Research for Australia, and the Czech Republic, where conference papers are evaluated directly by experts without requiring a prior categorization of the conference itself. The second approach, used by Serbia, Macedonia, Montenegro, Bosnia and Herzegovina, Croatia, and Slovenia, is commission-based evaluation that applies formal rules. In this model, a conference first receives a category based on measurable criteria (language, committee composition, indexing status), and then each publication inherits a score determined by the conference category and the publication’s own attributes (e.g., number of pages distinguishing a full paper from an abstract).

The ontology-driven approach proposed in this paper is applicable to the second category of evaluation frameworks, where the rules are sufficiently formal to be encoded as logical axioms. The expert panel approach, by contrast, involves subjective judgment that cannot be fully automated, though the metadata infrastructure formalized here could support it as well.

3.2. Prenatal Care: Structure and Rules

The pregnancy monitoring domain [6] involves entities such as patients, pregnancies, screening tests, symptoms, diseases, medications, and CTG sessions. Its rule logic can be grouped into three main types: screening, diagnosis, and real-time monitoring.

Screening rules compute risks for chromosomal abnormalities by comparing test parameters from double, triple, and quadruple tests with gestational-week-specific reference values and applying risk coefficients. Diagnostic rules classify conditions such as preeclampsia, eclampsia, kidney disease, and gestational diabetes based on symptom groups, pregnancy week, and Oral Glucose Tolerance Test (OGTT) results. In Drools, these rules combine salience-based execution, backward chaining for symptom-based diagnosis, and forward chaining for laboratory-test interpretation.

The third group consists of CTG monitoring rules, which process temporal fetal heart rate and contraction data. Unlike screening and diagnostic rules, CTG monitoring relies on CEP with sliding time windows, making it a fundamentally different computational model from static rule evaluation.

Having characterized the time-dependent, multi-subsystem architecture of the prenatal care rule base, we now return to the research-evaluation domain in order to examine the static metadata structures on which its rulebook operates. This return is deliberate: contrasting the metadata dimensions of the two domains is what enables the suitability-spectrum analysis of Section 3.4, in which the ontological approach is shown to be well matched to the classification-type rules of research evaluation while remaining unsuited to the CEP-bound rules of CTG monitoring.

3.3. Research-Evaluation Rulebook Metadata

The comparative analysis of rulebooks reveals that evaluation metadata is organized into three distinct sets, corresponding to three levels of the publication hierarchy: the conference (event), the conference proceedings (publication container), and the individual publication.

3.3.1. Conference Metadata

All analyzed rulebooks require the conference name as a basic identifier. Most also require the year and place of the conference. Beyond these universal attributes, the metadata diverges: some rulebooks require information about the conference organizer and its type (international or national), the presentation language, and quantitative data about the conference committee structure, specifically, the total number of committee members, the number of countries represented, and in the case of Macedonia, the number of members from the most represented country. Several rulebooks also require conference results data: the total number of accepted papers, the number of submitted papers, and the number of papers whose authors are from foreign countries.

3.3.2. Proceedings Metadata

The conference proceedings serve as an intermediary entity between the conference and the individual publication. All rulebooks require the proceedings title. Additional metadata varies: ISBN, publication language, publisher information (name and headquarters), indexing status in citation databases (CPCI, Scopus, or a predefined list), and in the case of Montenegro, the editorial committee structure.

3.3.3. Publication Metadata

The individual conference publication is described by title, author(s), publication year, and total number of pages across all analyzed rulebooks. Additional metadata include conference and proceedings references, DOI or URL, scientific area, abstract (required only by the UK’s REF), type of evaluation entity (distinguishing invited talks from regular papers, posters, and abstracts), and citation data. Citation requirements vary significantly: the UK requires total citations, Slovenia requires pure citations within 5-year and 10-year windows, and Hungary requires pure citations excluding self-citations from the author’s affiliation and citations found in a predefined list of databases [5].

This heterogeneity directly motivates an ontology-driven alternative, in which each of the three citation policy variations, including total, windowed, and self-citation excluded, becomes a separate rule block embedded in the procedural engine, written in engine-specific rule syntax, and manually kept in sync with the Java persistence schema. Encoding the same logic declaratively as a specialized OWL 2 DL ontology inverts the structure: citation requirements become class restrictions and property axioms, the reasoner verifies that a given publication instance satisfies the relevant rulebook’s class assignment, and any policy revision reduces to ontology edits that are simultaneously verifiable by the DL reasoner and regenerable into the persistence, business-logic, and presentation layers. This inversion is precisely what the three-artifact pattern of Section 1 makes impossible in procedural settings.

3.4. Cross-Domain Analysis: What Can Be Ontologized?

Comparing the two domains reveals a spectrum of rule complexity relevant to ontological formalization, as summarized in

Table 1. Rule characteristics across domains.

Characteristic	Research Evaluation	Prenatal Screening	Prenatal Diagnosis	CTG Monitoring
Rule Type	Classification	Risk computation	Classification	Temporal pattern
Input Data	Static metadata	Static test values	Static symptoms	Real-time stream
Logic Structure	Conjunction with disjunction	Weighted arithmetic	Decision tree	Sliding window CEP
Temporal Dependency	None	Week-specific reference values	Week-dependent	Continuous real-time
Suitable for OWL Formalization	High	Medium (arithmetic limits)	High	Low (requires CEP)

.

This analysis reveals that research evaluation rules and prenatal diagnostic rules, both classification tasks over static data with conjunction, disjunction, and negation, are well-suited for OWL class definitions. Prenatal screening test rules, which involve arithmetic computation of weighted risk scores, can be partially formalized in OWL with SWRL extensions for arithmetic. CTG monitoring rules, which require temporal event processing over continuous data streams, are fundamentally unsuited for OWL formalization and benefit from Drools’ CEP capabilities.

A possible SWRL-based extension could represent the arithmetic part of a prenatal-screening rule by using SWRL built-ins over explicitly asserted input coefficients. For example, a simplified risk calculation could be expressed as follows (Listing 1):

Listing 1. Illustrative SWRL rule for a simplified prenatal-screening risk calculation.

PrenatalRecord(?r) ^ hasBaseRisk(?r, ?base) ^ hasBetaHCGCoefficient(?r, ?hcg) ^ hasPAPPACoefficient(?r, ?pappa) ^ swrlb:multiply(?partialRisk, ?base, ?hcg) ^ swrlb:multiply(?calculatedRisk, ?partialRisk, ?pappa) → hasCalculatedRisk(?r, ?calculatedRisk)

This example (Listing 1) illustrates how arithmetic values could be derived from asserted screening parameters. It is not implemented or evaluated in the current BAB pipeline. A complete implementation would additionally require explicit handling of missing coefficients, datatype validation, gestational-week-specific reference values, and threshold comparison. These requirements motivate the hybrid SWRL/DMN direction discussed in Section 7.5 rather than an extension of the present static-classification experiment.

This finding motivates a two-part validation strategy. First, the complete BAB pipeline is applied to the research-evaluation domain, which represents a fully suitable static-classification case and permits comparison with the published Jess-based results. Second, the transferability of the architecture is examined using the static diagnostic subset of prenatal care, specifically the classification of preeclampsia and eclampsia. Arithmetic screening rules and real-time CTG monitoring are deliberately excluded from the second experiment because they require weighted computation and temporal event processing, respectively. The purpose of this experiment is to determine whether the same ontology–verification–generation architecture can be reused in a different domain without changes to BAB’s framework-level transformation mechanisms; it does not constitute clinical validation of the generated application.

This boundary also suggests where complementary standards may fit: DMN can express explicit decision-table logic, while SHACL can support closed-world structural validation, but neither replaces the OWL-based source model and generation pipeline that are central to BAB.

4. Materials and Methods

This section presents the core contribution of the paper: the formalization of the research evaluation domain as an OWL 2 DL ontology that extends BAB Core and serves simultaneously as a domain model and as input to the BAB code generator. We describe the ontology structure (Section 4.1), the formalization of evaluation rules as class definitions (Section 4.2), the reified implementation mappings that drive code generation (Section 4.3), and the pre-generation consistency verification using DL reasoning (Section 4.4).

4.1. The ResearchEvaluation Ontology Module

The ResearchEvaluation ontology is designed as a modular extension of BAB Core, importing the BABCore namespace and reusing its foundational constructs, Entity, Attribute, Relation, ValidationRule, and ImplementationMapping. The domain concepts identified in Section 3.3 and Section 3.4 are formalized as subclasses of babcore:Entity, inheriting all BAB Core mechanisms for attribute definition, validation, and implementation mapping.

The class hierarchy introduces six primary entity classes (Figure 1):

• reseval:Conference
• reseval:Proceeding
• reseval:Publication
• reseval:Organization
• reseval:Person
• reseval:EvaluationRulebook

These six classes are declared mutually disjoint via owl:AllDisjointClasses, following the same pattern used in BAB Core for its top-level concepts. This axiom prevents any individual from being simultaneously classified as, for example, both a Conference and a Publication, an error that would be undetectable in a UML-based model but is immediately flagged by a DL reasoner.

Conference is defined with the following attributes (each formalized as a babcore:Attribute individual linked via hasAttribute): conferenceName (xsd:string, mandatory), startDate and endDate (xsd:date), cityTown (xsd:string), countryCode (xsd:string), and presentationLanguage (xsd:string). Quantitative indicators are modeled as attributes with RangeValidation constraints: totalCommitteeMembers (xsd:integer, min 0), countriesRepresented (xsd:integer, min 0), foreignAuthoredPapers (xsd:integer, min 0), totalPapers (xsd:integer, min 0), and submittedPapers (xsd:integer, min 0). These attributes constitute the structural definition of the Conference class itself; subsequent class definitions extend this base by adding the discriminating constraints that distinguish each evaluation category.

Proceeding carries attributes for proceedingTitle (xsd:string, mandatory), isbn (xsd:string), publicationLanguage (xsd:string), and three boolean attributes for indexing status: isIndexedInCPCI, isIndexedInScopus, and isIndexedInPredefinedList.

Publication is defined with publicationTitle, publicationYear (xsd:integer), totalPages (xsd:integer, mandatory), doi (xsd:string), scientificArea (xsd:string), and publicationType, an enumerated attribute constrained to one of: ConferenceProceedingsArticle, ConferencePoster, ConferenceAbstract, InvitedTalk, or EditorialOfProceedings.

Organization carries organizationName (xsd:string) and organizerType, an enumerated attribute restricted to InternationalOrganizer or NationalOrganizer.

Relationships between entities are formalized as babcore:Relation individuals with explicit cardinality:

• Conference hasProceeding Proceeding (1..*)
• Conference hasOrganizer Organization (1..1)
• Proceeding containsPublication Publication (1..*)
• Publication hasAuthor Person (1..*)
• Publication presentedAt Conference (1..1)
• Conference evaluatedBy EvaluationRulebook (1..*)

The EvaluationRulebook entity provides a reification point for representing different national rulebooks as ontological individuals. The Serbian rulebook, for instance, is represented as an individual of type EvaluationRulebook whose datatype properties specify the numeric thresholds used in its evaluation rules (minCountries, minForeignPapers, minTotalPapers, minFullPaperPages) and the set of accepted languages. In addition to these primitive thresholds, each EvaluationRulebook individual references a set of EvaluationCategory sub-individuals ordered by their priorityPosition value; each EvaluationCategory carries a code (e.g., “M30”, “M60”, “M33”), a priority position within the rulebook, and a mapsToOntologyClass property linking it to the corresponding OWL-defined class (reseval:InternationalConference, reseval:NationalConference, reseval:FullPaperAtInternationalConference). EvaluationCategory individuals are scoped to their parent rulebook rather than constituting a top-level domain entity, which preserves the six-entity structural decomposition introduced above while keeping rulebook-specific classification metadata reified within the ontology. The category list is consumed by the generated post-classification step (Section 5.2), to assign the highest applicable category from the ontology-derived class memberships collected for a record. Conference-level and publication-level categories are declared in the same priority-ordered list; the class-membership set collected for a record is what determines which of them can apply to it, so no category code is hard-coded in the generated code.

4.2. Evaluation Rules as OWL Class Definitions

The central design decision that distinguishes this approach from the Jess-based system is the encoding of evaluation rules as OWL-defined classes rather than procedural rules. In the Jess approach, a rule such as srRuleBook_international_conference is a procedural statement with explicit priority (salience 900) that fires when its left-hand-side conditions are matched and asserts a new fact on its right-hand side. In our approach, the equivalent semantics are captured as a class definition that a DL reasoner can use for automatic classification.

The class InternationalConference (corresponding to category M30) is defined as a necessary and sufficient condition, as shown in Listing 2:

All numeric data properties used in evaluation rules (totalPapers, countriesRepresented, foreignAuthoredPapers, totalPages) are declared as owl:FunctionalProperty in the domain ontology, ensuring at most one asserted value per individual. Under this declaration, the construct some xsd:integer[>= N] (an OWL 2 DL datatype facet restriction) is semantically equivalent to “the value is greater than or equal to N.” This construct is used rather than the qualified cardinality restriction min N xsd:integer, since the latter denotes “the property has at least N distinct values,” which is unintended and, under functional declaration, unsatisfiable.

Listing 2. OWL 2 DL definition of the InternationalConference class.

Class: reseval:InternationalConference      EquivalentTo:           reseval:Conference           and (reseval:presentationLanguage some {“en”, “fr”, “de”, “es”})           and (reseval:hasProceeding some (                reseval:Proceeding and (reseval:publicationLanguage some {“en”, “fr”, “de”, “es”})                ))           and (                (reseval:hasOrganizer some (                     reseval:Organization and (reseval:organizerType value “InternationalOrganizer”)                ))                or                ((reseval:countriesRepresented some xsd:integer[>= 5])                and (reseval:foreignAuthoredPapers some xsd:integer[>= 10]))           )           and (reseval:totalPapers some xsd:integer[>= 10])

Threshold values are shown inline because OWL 2 DL datatype restrictions require concrete facet values. In the deployed validation ontology, the Serbian rulebook thresholds are materialized into the corresponding rulebook-specific class definitions, while the EvaluationRulebook individual stores the same thresholds as metadata consumed by the generated application code.

NationalConference (M60) is defined positively by the structural conditions every Serbian conference must satisfy, as illustrated in Listing 3:

Listing 3. OWL 2 DL definition of the NationalConference class.

Class: reseval:NationalConference      EquivalentTo:           reseval:Conference           and (reseval:totalPapers some xsd:integer[>= 10])

Note that NationalConference is defined positively, without negating InternationalConference. Under the OWL Open World Assumption (OWA), a class-level negation cannot capture the priority semantics of Jess salience: a conference satisfying both definitions would be classified as both InternationalConference and NationalConference, with neither classification suppressing the other. The priority resolution that Jess achieves through salience ordering is handled by the generated Java application after the OWL class conditions have been translated into executable predicates. At runtime, these predicates determine the applicable categories from the persisted conference data, after which the highest-priority category is selected. This separation cleanly partitions concerns: At the ontology level, DL reasoning verifies the class definitions and their subsumption relationships under OWA. At runtime, Java predicates generated from those definitions evaluate persisted records under the closed-world assumption (CWA), while a separate procedural step applies the rulebook’s tie-breaking policy by consuming the category set ordered by priorityPosition reified in the selected EvaluationRulebook individual. Neither Jess nor Drools provides this separation; in both, classification logic and priority resolution are entangled within rule definitions. Empirically, this is confirmed by the deployed ontology: when HermiT is invoked on the ResearchEvaluation terminological box (TBox), it infers InternationalConference ⊑ NationalConference, since every conference satisfying the M30 conditions also satisfies the strictly weaker M60 condition. The inferred subsumption is therefore not a defect of our formalization but a consequence of the rulebook’s semantics under DL classification and motivates the explicit post-classification priority step described below.

Publication categories reference the conference classification, as shown in Listing 4:

Listing 4. OWL 2 DL definition of publication categories.

Class: reseval:FullPaperAtInternationalConference      EquivalentTo:           reseval:Publication           and (reseval:presentedAt some reseval:InternationalConference)           and (reseval:publicationType value “ConferenceProceedingsArticle”)           and (reseval:totalPages some xsd:integer[>= 6])

The OWL union operator replaces the explicit OR constructs needed in both Jess and Drools. Where Jess and Drools entangle classification with priority through salience, our approach separates the two: OWL handles classification declaratively, while priority resolution becomes an explicit, auditable step in the generation pipeline. A DL reasoner can additionally determine satisfiability and subsumption relationships; capabilities absent from both procedural approaches.

To illustrate the contrast with prenatal care, consider how the pregnancy monitoring system’s disease diagnosis rules would map to OWL. The preeclampsia diagnosis, requiring symptoms from groups 1 and 2 manifesting after week 20, translates naturally to an OWL-defined class (Listing 5):

Listing 5. OWL 2 DL formalization of preeclampsia and eclampsia diagnoses.

Class: prenatal:Preeclampsia      EquivalentTo:           prenatal:Diagnosis           and (prenatal:hasSymptom some prenatal:HighBP)           and (prenatal:hasSymptom min 2 prenatal:Group1Symptom)           and (prenatal:hasSymptom min 1 prenatal:Group2SupportingSymptom)           and (prenatal:pregnancyWeek some xsd:integer[> 20]) Class: prenatal:Eclampsia      EquivalentTo:           prenatal:Preeclampsia           and (prenatal:hasSymptom min 1 prenatal:Group3Symptom)

This formalization enables a DL reasoner to automatically compute and verify the class hierarchy. For example, it correctly infers that Preeclampsia subsumes Eclampsia, as the latter simply imposes an additional intersection condition (group 3 symptoms) onto the former. In Drools, such cross-rule consistency and taxonomic hierarchy must be validated manually. It is important to note, however, a fundamental difference in computational paradigms. Procedural engines like Drools operate under both the Unique Name Assumption (UNA) and CWA: distinct Java object references inherently represent distinct entities, and facts in working memory are explicitly enumerated, which allows the engine to natively count objects. Conversely, OWL operates under the OWA and lacks the UNA. Therefore, evaluating cardinality restrictions (e.g., min 2) in OWL requires that the asserted symptom individuals be explicitly declared as distinct using owl:DifferentFrom; otherwise, the DL reasoner cannot assume they represent separate entities.

However, the screening test rules, which compute weighted risk scores (risk = baseRisk × coeffNT × coeffPAPPA × coeffHCG × coeffSmoker), require arithmetic operations that OWL 2 DL cannot express natively. These rules would require SWRL extensions or hybrid processing, a limitation acknowledged in Section 7.

4.3. Reified Implementation Mappings via BAB Core and the PSM Ontology

The BAB framework separates what is mapped (declared in the BAB Core ontology) from how it is realized (declared in a PSM ontology, e.g., BABj for the Jakarta EE/Vaadin stack). Implementation mappings are therefore not specified per domain ontology; instead, the ResearchEvaluation ontology declares only that its concepts are subclasses of babcore:Entity, and the BAB Core ontology already provides a hierarchy of mapping classes (babcore:ImplementationMapping, refined into babcore:EntityMapping, babcore:PersistentEntityMapping, babcore:ServiceMapping, babcore:FormMapping, babcore:ViewMapping, and others) together with properties such as babcore:hasImplementationMapping, babcore:emitsAnnotation, and babcore:realizesDatatype that bind these mappings to concrete artifacts.

The realizations themselves live in the PSM ontology. For example, when the BABj ontology is loaded, it contributes an individual of babcore:PersistentEntityMapping whose babcore:emitsAnnotation values include @Entity and @Table, with the table name template derived from the entity’s rdfs:label. The same individual carries babcore:realizesDatatype triples that bind PIM-level XML Schema datatypes (xsd:string, xsd:integer, xsd:date) to PSM-level Java/JPA realizations.

This separation has three consequences for the research evaluation case study. First, the ResearchEvaluation ontology contains no domain-specific mapping individuals; the BAB generator v1.0 processes every babcore:Entity subclass uniformly through the PSM ontology’s persistent-entity mapping. Second, retargeting the same domain ontology to a different stack (e.g., a Python-based BAB realization) requires only swapping the imported PSM ontology, not modifying ResearchEvaluation. Third, when the rulebook’s evaluation logic must be projected into procedural code, the projection is governed by the same PSM ontology that drives entity generation, so the procedural priority-resolution layer is itself a generated artifact rather than a manually written extension.

Listing 6 illustrates the relevant fragment of BAB Core that the generator consumes for any persistent entity, including Conference:

Listing 6. Excerpt of BAB Core mapping declarations consumed during code generation for persistent entities.

Class: babcore:PersistentEntityMapping SubClassOf: babcore:EntityMapping ObjectProperty: babcore:hasImplementationMapping Range: babcore:ImplementationMapping ObjectProperty: babcore:emitsAnnotation Domain: babcore:ImplementationMapping Class: babcore:Entity // Every subclass is automatically processed through the mapping individuals contributed by the loaded PSM ontology.

The actual JPA annotations applied to Conference, Proceeding, and Publication are emitted by the generator from the PSM ontology’s mapping individual, parameterized by the structural information extracted from the ResearchEvaluation ontology via SPARQL.

4.4. Pre-Generation Consistency Verification

HermiT [39] performs three verification tasks before code generation.

• Ontology consistency checks for contradictions, errors that in Jess would surface only through unexpected evaluation results and in Drools only through conflicting rule firings.
• Class satisfiability verifies each defined class can have instances. An unsatisfiable InternationalConference class would mean the M30 category can never be assigned, analogous to discovering in the pregnancy monitoring system that no combination of symptoms could ever trigger a preeclampsia diagnosis, which would indicate a rule design error.
• Subsumption checking verifies the classification taxonomy. In research evaluation, FullPaperAtInternationalConference must be subsumed by Publication. In a hypothetical prenatal ontology, Preeclampsia must subsume Eclampsia, since Eclampsia adds further conditions to it.

In addition to DL reasoning, the generator performs SPARQL-based structural extraction and availability checks over the loaded PSM ontology. These checks ensure that the PSM ontology contributes the mapping constructs required by the generation pipeline, while entity-level completeness is enforced during structural extraction and template instantiation.

This two-layer verification (DL reasoning + SPARQL) is not part of the ordinary execution model of procedural rule engines such as Jess and Drools. Their support environments primarily assist with syntax checking, run-time debugging, and rule management, while verification of inconsistent, incomplete, redundant, or semantically unsatisfiable rule combinations is treated in the literature as a separate rule-base quality-assurance problem [47,48]. In the BAB pipeline, this verification is moved before code generation through OWL 2 DL consistency, satisfiability, and subsumption checks.

Both verification stages were applied to the deployed ResearchEvaluation ontology described in Section 4.1: HermiT confirmed consistency, established satisfiability of all six domain entity classes and all three defined evaluation classes (InternationalConference, NationalConference, FullPaperAtInternationalConference), and produced a subsumption hierarchy that empirically motivates the post-classification priority step (Section 4.2), since InternationalConference ⊑ NationalConference is inferred as a logical consequence of the rulebook. The complementary SPARQL-based extraction and availability checks confirmed that the loaded PSM ontology provides the mapping constructs required by the generation pipeline. Entity-level completeness is enforced during structural extraction and template instantiation. The full reasoning logs and reproducibility scripts accompany the artifact package described in Section 6.1.

4.5. Open-World Reasoning and Closed-World Runtime Evaluation

A natural concern about ontology-based rule formalization is the mismatch between OWL’s OWA and the closed-world semantics typically required during application execution. Under the Serbian rulebook, for example, a conference for which countriesRepresented is unavailable cannot be evaluated as a valid M30 candidate, whereas OWL treats the missing value as unknown. The proposed architecture separates these semantic regimes: OWL 2 DL and HermiT are used under OWA to verify the ontology before code generation, while the generated Java application evaluates persisted records under application-level closed-world assumptions.

Ontology-level reasoning under OWA. HermiT is used before code generation to verify ontology consistency, class satisfiability, and subsumption relationships. It is also used with the validation assertional boxes (ABoxes) to obtain reference entailments for the experiments. Missing property values remain unknown and therefore cannot be interpreted as false or invalid at this level. These results validate the semantic source model, but they do not constitute the runtime execution semantics of the generated Java application.

Runtime evaluation under CWA. During code generation, the relevant OWL class conditions are translated into Java predicates. At runtime, these predicates are evaluated over the finite state stored in the application database. Before classification, the application-level validation checks whether all values required by the selected rulebook are present. A missing required value is treated as an invalid input rather than as an unknown fact, and the record is rejected or assigned the EXCLUDED result. Consequently, only explicitly stored values participate in runtime evaluation, which establishes application-level closed-world semantics. After the Java predicates determine the set of applicable categories, a separate deterministic step selects the category with the highest priorityPosition.

This separation confines OWA to ontology-level verification and reference classification, while runtime evaluation operates over complete application records under CWA. Structural ontology faults, such as datatype violations, disjointness violations, and contradictory class definitions, can be detected by the DL reasoner. Missing application data, by contrast, must be detected by explicit Java validation because absence cannot be interpreted as falsity under OWA. Priority resolution is an additional deterministic operation that resolves overlapping applicable categories and should not be conflated with completeness validation.

While the BAB framework uses OWL 2 DL for formal consistency checking, satisfiability analysis, subsumption reasoning, and classification, this should not be understood as treating OWL as a complete replacement for structural data validation. SHACL provides a complementary closed-world validation mechanism for checking whether RDF data conforms to explicitly defined shapes, cardinalities, datatypes, and value constraints [43,46]. In the current implementation, closed-world completeness checks are performed by deterministic Java validation at the application boundary. The current pipeline does not use SHACL during runtime evaluation. A future extension could generate SHACL shapes from the BAB Core metadata, thereby externalizing mandatory-value checks, datatype constraints, numeric ranges, and rulebook-specific completeness requirements into a declarative RDF validation layer. Such an extension would complement, rather than replace, OWL 2 DL reasoning and the Java priority-resolution mechanism.

4.6. Secondary Cross-Domain Validation Protocol

To assess whether the proposed architecture can be transferred beyond the research-evaluation domain, a second experiment was designed using the static diagnostic subset of the prenatal-care system described in Section 3.2. The experiment is deliberately limited to the classification of preeclampsia and eclampsia, whose conditions can be expressed as OWL 2 DL class definitions, as illustrated in Listing 5. Screening-test risk calculations and CTG monitoring are excluded because they require arithmetic and temporal event-processing capabilities that fall outside the expressiveness of the current OWL-first pipeline.

The prenatal ontology module imports BAB Core and represents the pregnancy week, asserted symptoms, symptom-group membership, and the diagnostic conditions required by the two class definitions. Six synthetic diagnostic records are used: two positive cases and four negative or boundary cases. They vary the pregnancy week, the presence of high blood pressure, the number of asserted group-one and group-two symptoms, and the presence of a group-three symptom. Because OWL does not adopt the Unique Name Assumption, symptom individuals used in cardinality restrictions are explicitly declared as distinct. The records are synthetic and are used solely to test software behavior; the experiment does not use patient data or claim clinical validity.

The validation followed the same sequence as the research-evaluation experiment. First, HermiT checked ontology consistency, class satisfiability, and the inferred subsumption relationship between Eclampsia and Preeclampsia. Second, the six records were classified, and the inferred memberships were compared with the expected outcomes derived from the formalized conditions. Third, the prenatal ontology was processed internally using the proprietary BAB generator, with the same BAB Core concepts, BABj platform-specific mappings, SPARQL projections, and FreeMarker template families used for the research-evaluation application. The same six records were then executed in the generated application, and all runtime classifications matched the HermiT entailments and expected outcomes. No prenatal-specific modification to the BAB generator or its transformation mechanisms was required. The public artifact reproduces the ontology-level validation and the six expected classifications but does not redistribute the proprietary BAB generator or the generated application source code.

The experiment is considered successful if: (i) both diagnostic classes remain satisfiable; (ii) HermiT infers Eclampsia as a subclass of Preeclampsia; (iii) all six records receive the expected ontology and generated-application classifications; and (iv) the required persistence, data-transfer, service, and presentation artifacts are generated without framework-level changes. Section 6.5 reports the test records and results.

5. Code Generation Architecture

This section describes the end-to-end pipeline that transforms the ResearchEvaluation ontology into a deployable evaluation information system. The pipeline follows the BAB framework’s two-step transformation: the ontology is first projected through SPARQL queries that extract structural information, and then FreeMarker templates consume that information to produce Java source files organized into a standard EJB layered architecture.

5.1. Transformation Pipeline Overview

The BAB code generator is implemented as a Java application that takes as input an OWL ontology file (RDF/XML OWL ontology file serialized using the RDF/XML syntax and produces as output a complete Maven project. The generator uses the Apache Jena framework for ontology loading, SPARQL query execution, and programmatic access to the ontological model. Code generation is performed by Apache FreeMarker templates that receive structured data extracted from the ontology and emit Java source files (Figure 2).

The transformation proceeds in four phases. Phase 1 (Ontology loading and reasoning): The generator loads the ResearchEvaluation ontology into a Jena OntModel and invokes the HermiT reasoner to compute the inferred class hierarchy. It performs consistency and satisfiability checks; if it detects an unsatisfiable class, the generator halts and reports the error.

Phase 2 (Structural extraction via SPARQL): A set of predefined SPARQL projections extracts the information required by each architectural layer. Each projection is implemented as a SPARQL SELECT query whose result set is materialized by the generator into a structured data model and supplied to the corresponding FreeMarker template as named template input. The entity projection retrieves BAB Core Entity subclasses together with their attributes, datatypes, validation rules, relations, target entities, cardinalities, and the mapping artifacts contributed by the loaded PSM ontology. Additional projections are used for transfer objects, service/home classes, form definitions, view definitions, and, in the research-evaluation case, rulebook categories used by the post-classification priority step. Listing 7 illustrates the common extraction pattern: mandatory information is matched directly, optional ontological constructs are retrieved through OPTIONAL blocks, and ORDER BY is used to ensure stable iteration order during generation.

Listing 7. SPARQL query for extracting entity structural information.

SELECT ?entityName ?attrName ?attrType ?mandatory ?relName        ?targetEntity ?cardinality ?mapsEntityTo ?mapsHomeTo WHERE {   ?entity rdfs:subClassOf* babcore:Entity .   ?entity rdfs:label ?entityName .   ?entity babcore:hasAttribute ?attr .   ?attr rdfs:label ?attrName .   ?attr babcore:attributeType ?attrType .   OPTIONAL { ?attr babcore:hasValidationRule ?vr .              ?vr rdf:type babcore:MandatoryValidation .              BIND(true AS ?mandatory) }   OPTIONAL { ?entity babcore:hasRelation ?rel .              ?rel rdfs:label ?relName .              ?rel babcore:hasTargetEntity ?te .              ?te rdfs:label ?targetEntity .              ?rel babcore:cardinality ?cardinality }   ?mapping rdf:type babcore:PersistentEntityMapping .   ?mapping babcore:mapsEntityTo ?mapsEntityTo .   ?mapping babcore:mapsHomeTo ?mapsHomeTo . } ORDER BY ?entityName ?attrName

Phase 3 (Template-based code generation): The SPARQL projections are consumed by Apache FreeMarker templates, with one template family corresponding to each generated artifact type. The entity template emits JPA-annotated persistence classes whose fields and relations are derived from the entity projection. The data-transfer object (DTO) template emits data-transfer classes derived from the same structural metadata. The service/home template emits the business-logic layer, including CRUD operations and the generated predicates required for evaluation-category resolution. In these generated predicates, ontology-level class conditions are translated into imperative checks: conjunctions become logical AND expressions, disjunctions become OR expressions, datatype restrictions become comparison predicates, and relation restrictions become checks over the corresponding generated associations. Form and view templates emit Vaadin-based UI components, using the extracted attribute, relation, and validation metadata to configure fields, binders, and grid views. The templates are executed in a deterministic order: persistence artifacts are generated first, followed by DTO and service/home artifacts, and finally the form and view layers, so that cross-layer references can be resolved from the name and mapping tables populated during structural extraction.

Phase 4 (Project assembly): The generated Java source files are written into a standard Maven project structure, organized by architectural layer and package namespace. The generator also emits the project configuration files required by the selected PSM stack, including the Maven pom.xml and runtime configuration descriptors for persistence and web deployment. The dependency set is determined by the BABj PSM and includes the libraries required for Jakarta EE/JPA persistence, validation, Vaadin presentation components, ontology loading and querying through Apache Jena, DL reasoning, and template execution through FreeMarker. After source generation, the assembled project can be built through the accompanying Maven script. Re-running the generator with the same domain ontology, BAB Core ontology, loaded PSM ontology, SPARQL projections, and template set produces the same generated project structure, apart from non-semantic metadata such as generation timestamps when these are enabled.

5.2. Generated Artifacts

For each entity in the ResearchEvaluation ontology, the generator produces artifacts across all five layers of the BAB architecture. We illustrate this with the Conference entity.

5.2.1. Persistence Layer

The entity template generates a JPA-annotated class with fields corresponding to ontological attributes, appropriate column mappings, and validation annotations derived from ValidationRule individuals. Listing 8 shows a representative fragment of the generated entity class, while an extended generated excerpt is provided in Appendix A (Listing A1):

Listing 8. Representative fragment of the generated JPA entity class for the Conference entity.

@Entity @Table(name = “Conference”) public class Conference extends AbstractEntity {     @Serial     private static final long serialVersionUID = 4471902265518843301L;     private String conferenceName;     private Integer countriesRepresented;     private Organization organizer;     private Set<Proceeding> proceedings = new HashSet<>();     @Column(name = “ConferenceName”, length = 250, nullable = false)     @NotNull(message = “Field is required”)     public String getConferenceName() {         return conferenceName;     }     @Column(name = “CountriesRepresented”)     @Min(value = 0, message = “Value cannot be negative”)     public Integer getCountriesRepresented() {         return countriesRepresented;     }     @ManyToOne(fetch = FetchType.LAZY)     @JoinColumn(name = “Org_ID”)     @NotNull(message = “Field is required”)     public Organization getOrganizer() {         return organizer;     }     @OneToMany(mappedBy = “conference”)     public Set<Proceeding> getProceedings() {         return proceedings;     }     // Remaining generated properties, setters, toString and getCompareValue }

Every structural decision in this generated class traces directly to the ontology. Following the BAB convention, the mapping annotations are attached to the property getters rather than to the fields. The @NotNull constraint and the nullable = false column setting on conferenceName originate from the MandatoryValidation rule; the @Min(0) annotations originate from RangeValidation rules; the @ManyToOne and @OneToMany annotations derive from cardinality specifications on Relation individuals; and attributes typed as xsd:date are realized as java.time.LocalDate properties, because the platform-specific mapping targets the java.time API rather than the legacy java.util.Date and @Temporal combination. Each generated property takes its name from the rdfs:label of the corresponding BAB Core attribute or relation individual, which is what keeps the projection deterministic where a property name differs from the name of the OWL property it realizes: the object property reseval:hasOrganizer is reified as a Relation individual labeled organizer, and the generator therefore emits an organizer property carrying the @ManyToOne annotation.

5.2.2. Business-Logic Layer

The Home (service) template generates a stateless EJB that extends AbstractHome. For the Conference entity, the generator additionally produces the evaluation method, whose structural conditions are derived from the OWL class definitions of Section 4.2 and whose priority resolution consumes the EvaluationCategory metadata ordered by priorityPosition in the selected EvaluationRulebook individual (Section 4.1). Listing 9 shows a representative fragment of the generated EJB stateless session bean containing the evaluation logic, while an extended generated excerpt is provided in Appendix A (Listing A2).

Listing 9. Representative fragment of the generated EJB stateless session bean containing evaluation logic.

@LocalBean @Stateless @Primary public class ConferenceHome extends AbstractHome<Conference, ConferenceDTO> {     public ConferenceHome() {         super(Conference.class, ConferenceDTO.class);     }     public String evaluateConference(Conference conf, EvaluationRulebook rulebook) {         if (!hasCompleteBasicData(conf, rulebook)) {             return “EXCLUDED”;         }         Set<String> applicableClasses = collectApplicableClasses(conf, rulebook);         for (EvaluationCategory category : rulebook.getCategoriesOrderedByPriority()) {             if (applicableClasses.contains(category.getMappedOntologyClass())) {                 return category.getCategoryCode();             }         }         return “EXCLUDED”;     }     // Additional generated methods }

The procedural form of Listing 9 should not be interpreted as a relocation of business logic from the ontology to Java. The generated method evaluates Java predicates translated from the OWL class definitions over the persisted runtime data and collects the applicable categories. The final category is then selected by iterating over the category set ordered by priorityPosition stored in the selected EvaluationRulebook individual. Thus, the Java code does not hard-code the priority order between M30 and M60; it consumes the rulebook-declared priority metadata in a deterministic runtime form. Closed-world semantics are introduced separately by the required-data checks performed before these predicates are evaluated. Threshold values, accepted languages, and category priorities are all obtained from the EvaluationRulebook entity, enabling the same generated system to support multiple rulebooks.

The structural correspondence between this method and the OWL class definitions in Section 4.2 is straightforward: each conjunction (⊓) becomes a logical AND (&&), the disjunction (⊔) becomes an OR (||), and the numeric restrictions become comparison operators. The threshold values are not hard-coded but injected from the EvaluationRulebook entity, thereby allowing the system to support various rulebooks.

5.2.3. DTO Layer, Web Layer, and Evaluation-Specific UI

They are similarly generated from the ontology, producing DTOs, Vaadin-based grid views, edit forms, and an evaluation dashboard where the user selects a conference, chooses a rulebook, and triggers evaluation with a full explanation trace. Each run is stored as an evaluation-result record holding the assigned conference and publication categories, the explanation trace, and the moment of evaluation. That record is an application-level audit artifact rather than a projection of a domain class, so it is generated from the BAB Core entity mechanism but has no counterpart among the six ontology entities.

5.3. Traceability

Every generated line traces through a deterministic chain: OWL entity → SPARQL query → FreeMarker template → Java artifact. A rulebook threshold change is made in the rulebook metadata, from which the corresponding rulebook-specific class definitions are re-materialized before code generation. In the pregnancy monitoring system, by contrast, adding a new disease diagnosis requires updating the Drools.drl file, potentially modifying the JPA entity model, updating the Vue.js interface, and ensuring consistency across all changes.

6. Results and Validation

This section validates the proposed ontology-driven approach by applying it to the same reference case used by Nikolić et al. [5]: the evaluation of a conference paper presented at the 4th International Conference on Information Society and Technology (ICIST 2014), according to the Serbian national rulebook. The purpose of the validation is not to introduce a new evaluation dataset, but to test whether the BAB-generated system reproduces the classifications obtained by the established Jess-based implementation while deriving the domain model, rule logic, and application layers from a unified OWL 2 DL source.

6.1. Experimental Setup

The validation reproduces the ICIST 2014 case study from Nikolić et al. [5], using the evaluation metadata summarized in

Table 2. Evaluation metadata for the ICIST 2014 case study.

Entity	Attribute	Value
Conference	conferenceName	International Conference on Information Society and Technology
Conference	startDate/endDate	9 March 2014/13 March 2014
Conference	cityTown/countryCode	Kopaonik/RS
Conference	presentationLanguage	en
Conference	countriesRepresented	17
Conference	foreignAuthoredPapers	29
Conference	totalPapers	85
Organization	organizerType	NationalOrganizer
Proceeding	publicationLanguage	en
Publication	publicationTitle	System for modeling rulebooks
Publication	totalPages	6
Publication	publicationType	ConferenceProceedingsArticle
Rulebook	minCountries/minForeignPapers/minTotalPapers/minFullPaperPages	5/10/10/6

. ICIST 2014 was selected as the validation target for three reasons. First, it is documented in the Jess-based reference implementation as a worked example with a known expected result, namely an international conference classification and a full-paper publication category. Second, its metadata cover the complete static-classification chain required by the Serbian rulebook: conference-level thresholds, proceedings language, organizer type, publication type, and page-count threshold. Third, the dataset is intentionally small, consisting of one Conference, one Proceeding, one Organization, one Publication, and one selected EvaluationRulebook instance, which makes the reproduction traceable from input metadata to final category assignment.

For reproduction, the metadata from Table 2 were materialized as individuals in the database of the BAB-generated application. The Conference individual was linked to its Proceeding and Organization, the Publication individual was linked to the Proceeding and to the Conference at which it was presented, and the Conference was evaluated against the selected Serbian EvaluationRulebook. The Serbian rulebook instance was configured with the following threshold values: minCountries = 5, minForeignPapers = 10, minTotalPapers = 10, minFullPaperPages = 6, and acceptedLanguages = {en, fr, de, es}.

Before presenting the validation output, it is important to clarify that the input was not uploaded as an external file during execution (Figure 3). Instead, the database schema and stored entities were generated from the ResearchEvaluation ontology, and the ICIST 2014 data were entered into the generated application database. During execution, the generated application reads these records, evaluates the Java predicates generated from the ontology under application-level closed-world semantics, and then applies the deterministic priority-resolution step and produces the final evaluation categories. These categories are then compared with the Jess-based reference result reported in [5].

The reproduction process consists of three steps. First, the ontology and the selected rulebook metadata are loaded and checked before generation. Second, the BAB generator produces the persistence, service, data-transfer, and web-presentation layers from the ontology and the BABj PSM mappings. Third, the generated application evaluates the ICIST 2014 data by applying the conference-level rules for InternationalConference and NationalConference, followed by the rulebook-declared priority resolution, and then applies the publication-level rule for FullPaperAtInternationalConference.

To provide partial performance evidence, HermiT reasoning and BAB generation times were measured separately for both ontologies. All measurements were performed on a Windows 11 workstation equipped with an Intel Core Ultra 7 155H processor and 32GB of physical memory, using Eclipse Temurin OpenJDK 24.0.2. The ontology-level measurements used HermiT 1.3.8.1099 through Owlready2 0.51. Five warm-up runs were followed by 30 measured repetitions for each ontology, with the execution order alternated between the two cases. Each HermiT repetition used a fresh Owlready2 World and a fresh HermiT Java Virtual Machine process. Ontology loading was excluded from the primary HermiT timing boundary. Code-generation measurements were performed in a single Java Virtual Machine and covered only the execution of BabProjectGenerator.generate() after the ontology had been loaded, validated, and extracted into the generator’s application model. Verification of the generated project and removal of generated files were performed outside the measured interval. Mean, sample standard deviation, median, minimum, and maximum values were calculated for each operation and ontology.

6.2. Evaluation Results

6.2.1. Phase 1: Pre-Generation Reasoning

HermiT was invoked on the ResearchEvaluation ontology together with its imported BAB Core foundation. The reasoner reported the ontology as consistent, all six domain classes (Conference, Proceeding, Publication, Organization, Person, EvaluationRulebook) and all three defined evaluation classes (InternationalConference, NationalConference, FullPaperAtInternationalConference) as satisfiable, and produced the inferred subsumption hierarchy reproduced in

Table 3. Inferred subsumption hierarchy after HermiT classification.

Class	Direct Superclass (Inferred)	Ancestors
InternationalConference	NationalConference	Conference, Entity
NationalConference	Conference	Entity
FullPaperAtInternationalConference	Publication	Entity

.

The inferred subsumption InternationalConference ⊑ NationalConference is the empirical confirmation of the priority-resolution argument made in Section 4.2: under DL semantics, every conference satisfying the M30 conditions also satisfies the strictly weaker M60 condition, so the rulebook’s highest-applicable tie-breaking rule cannot be enforced by class definitions alone and is therefore handled by a deterministic post-classification step.

6.2.2. Phase 2: Code Generation

The BAB generator processed every subclass of babcore:Entity declared in ResearchEvaluation through the BABj PSM ontology’s PersistentEntityMapping individual, producing Java source files for the persistence, service, data-transfer, and web-presentation layers, together with the configuration artifacts required by the BAB application shell. The generation process is deterministic: identical input ontologies produce byte-identical output up to comment timestamps.

6.2.3. Phase 3: Evaluation Execution

The generated system was deployed, and the ICIST 2014 case study data were entered into the generated application database (Table 2). During application execution, the generated evaluation code classified the ICIST 2014 conference as InternationalConference according to the ontology-derived conditions: the asserted presentationLanguage value “en” is in the rulebook’s accepted-language enumeration; the asserted proceeding’s publicationLanguage is also “en”; the asserted organizer is a NationalOrganizer, so the first disjunct of the international-character condition is not satisfied, but countriesRepresented = 17 ≥ 5 and foreignAuthoredPapers = 29 ≥ 10 cause the second disjunct to succeed; and totalPapers = 85 ≥ 10. The post-classification priority step assigns category M30 based on the applicable ontology-derived class memberships and the rulebook’s category ordering. The accompanying paper, individual srModelingPaper, was classified as FullPaperAtInternationalConference (presentedAt an InternationalConference, publicationType = “ConferenceProceedingsArticle”, totalPages = 6 ≥ 6), receiving category M33.

Both classifications are identical to those reported by Nikolić et al. [5] for the same input data.

6.3. Three-Way Comparative Analysis

Table 4. Architectural comparison of procedural and ontology-driven rule systems.

Dimension	Jess (Research Evaluation) [5]	Drools (Pregnancy Monitoring) [6]	BAB Ontology-Driven (This Paper)
Rule language	.clp (Lisp-like, proprietary, discontinued)	.drl (Java-like, open source, active)	OWL 2 DL defined classes (W3C standard)
Inference	Forward chaining, salience priority	Forward/backward chaining, CEP, templates	DL reasoning (consistency, satisfiability, subsumption)
Pre-deployment verification	No ontology-level semantic verification	Syntax/static checks; no ontology-level satisfiability checking	HermiT: consistency + satisfiability + subsumption
Data model development	Manual (CERIF extension in Java)	Manual (JPA entities in Spring Boot)	Generated from ontology
Application infrastructure	Manual (Java EJB)	Manual (Spring Boot + Vue.js + PostgreSQL)	Fully generated (EJB + Vaadin + JPA)
Rule–code synchronization	Manual across Jess + Java	Partial (Drools separated, but data model manual)	Automatic (single ontology drives all layers)
Change propagation	Update .clp + update Java	Update .drl + possibly update entities + update UI	Modify ontology; re-generate
Multi-rulebook/protocol support	Separate .clp per rulebook	Separate .drl or agenda-group per protocol	Multiple ontological individuals; SPARQL comparison
Interoperability	Jess-proprietary (discontinued)	Drools-specific (active open-source ecosystem)	W3C standards (OWL/RDF/SPARQL)
Runtime inference	Yes (Jess engine)	Yes (Drools engine + CEP)	No (generated static code)
Real-time event processing	No	Yes (CEP for CTG monitoring)	No
Validation result	M30, M33	Disease diagnosis, risk scores, CTG alerts	M30 and M33 identical to Jess; six prenatal classifications matching HermiT entailments and expected outcomes

presents a comparative analysis of the three architectural approaches. The comparison confirms that three architectural limitations are shared by both Jess and Drools regardless of engine modernity: no formal verification, manual code synchronization, and engine-specific formats. The BAB approach addresses these limitations. Drools retains a unique advantage in runtime flexibility and CEP for temporal event processing, which the current ontology-driven approach does not replicate.

6.4. Fault-Injection Validation

To empirically assess the error-detection capabilities of the verification pipeline, five representative faults and one baseline case were deliberately introduced into the ontology, and the verification procedure was then reapplied to determine which mechanisms detected each fault class (Figure 4).

Table 5. Fault-injection results: mechanism detection by fault class.

#	Injected Fault	Inconsistency	Unsatisfiable Class	Detection Mechanism
F0	None (baseline)	–	–	Positive classification: icist2014 → InternationalConference
F1	totalPapers not asserted	No	No	HermiT does not infer category membership under OWA; Java required-data validation rejects the incomplete record under CWA. (Section 4.5)
F2	totalPapers = 5 (below threshold of 10)	No	No	The record is complete. HermiT does not infer category membership under OWA; the corresponding generated Java predicate evaluates to false and the application returns EXCLUDED.
F3	countriesRepresented = “seventeen” (string in xsd:integer slot)	Yes	No	HermiT consistency check: range violation on functional datatype property
F4	Single individual asserted as both Conference and Publication	Yes	No	HermiT consistency check: owl:AllDisjointClasses violation
F5	Defined class with contradictory thresholds (totalPapers ≥ 100 ∧ totalPapers ≤ 5)	No	Yes	HermiT satisfiability check: equivalent to owl:Nothing

summarizes the outcome.

Two observations are noteworthy. Structural data and modeling faults (F3, F4) and contradictory rule definitions (F5) are detected purely by DL reasoning, demonstrating that such semantic errors are rejected before code generation rather than at runtime. The F1 and F2 cases are neither ontology inconsistencies nor unsatisfiable-class defects. Under OWA, HermiT simply does not infer the corresponding classification. F1 represents an incomplete application record and is therefore rejected by the Java required-data validation under CWA. F2 is a complete record whose asserted value does not satisfy the classification threshold; the corresponding generated Java predicate consequently evaluates to false and the application returns EXCLUDED. Neither Jess nor Drools provides, as part of the ordinary rule-engine execution model, a pre-generation semantic verification step comparable to the OWL 2 DL checks used in the BAB pipeline. Existing analyses of rule-engine support environments indicate that tools around classic rule engines such as Jess and Drools primarily assist with syntax checking, run-time debugging, and rule management, rather than inspecting the semantic knowledge encoded in the rule base [48]. Rule-base verification for detecting inconsistent, incomplete, or redundant production rules is therefore treated in the literature as a separate quality-assurance problem requiring dedicated verification techniques [47,48]. In this respect, the BAB validation does not claim to replace the execution capabilities of procedural rule engines, but shows that, for static classification rules, ontology-level satisfiability and consistency checks can be performed before code generation and application execution.

The supplementary package separates the inputs and outputs of the two verification levels. For F3–F5, the inputs are deliberately modified ontology axioms and the outputs are the corresponding HermiT consistency or satisfiability results recorded by the fault-injection script. For F1 and F2, the inputs are modified validation records, while the ontology-level output shows that HermiT reports neither inconsistency nor an unsatisfiable class and simply does not infer the requested classification under OWA. Application-level handling of these cases is specified by the generated Java validation logic shown in Listing 9 but is not executed by the public ontology-level fault-injection script. The complete fault-injection script, ontology modifications, reasoning logs, and execution instructions are provided in the Supplementary Materials. For every fault, the repository also stores the reasoner’s own output as captured during the run, so the inconsistency reported for F3 and F4, the equivalence of the contradictory class to owl:Nothing for F5, and the entailments obtained in the remaining cases can be read directly from HermiT rather than only from the summary in Table 5.

6.5. Cross-Domain Validation

The secondary experiment applies the validation protocol from Section 4.6 to the static prenatal-diagnosis subset. The test matrix was constructed directly from the necessary and sufficient conditions encoded in Listing 5. The required high-blood-pressure symptom is considered separately from the additional group-two supporting symptom. Counts in

Table 6. Synthetic diagnostic records and classification results.

Case	Pregnancy Week	High Blood Pressure	Group-One Symptoms	Group-Two Supporting Symptoms	Group-Three Symptoms	Classification Result
P1	28	Yes	2	1	0	Preeclampsia
P2	31	Yes	2	1	1	Preeclampsia, Eclampsia
B1	20	Yes	2	1	0	None
N1	28	No	2	1	0	None
N2	28	Yes	1	1	0	None
N3	28	Yes	1	1	1	None

refer to explicitly distinct symptom individuals.

Cases P1 and P2 test the two positive diagnostic paths. Case B1 tests the strict pregnancy-week boundary because the formalized condition requires a value greater than 20. Cases N1 and N2 independently omit the required high-blood-pressure condition and the minimum number of group-one symptoms. Case N3 verifies that the presence of a group-three symptom is not sufficient for an Eclampsia classification when the necessary Preeclampsia conditions are not satisfied.

The ontology-level experiment was executed with HermiT over the prenatal module and the six-case validation ABox. The combined ontology was consistent; both Preeclampsia and Eclampsia were satisfiable, and HermiT entailed Eclampsia as a subclass of Preeclampsia. P1 was classified as Preeclampsia, P2 was classified as both Preeclampsia and Eclampsia, and neither diagnostic membership was entailed for B1, N1, N2, or N3. All six ontology-level outcomes therefore matched the expectations in Table 6.

Following the ontology-level validation, the prenatal module was processed by the unchanged BAB generator using the same BAB Core concepts, BABj platform-specific mappings, SPARQL projections, and FreeMarker template families as in the research-evaluation experiment. The generated application was then executed with the same six records. It classified P1 as Preeclampsia, P2 as both Preeclampsia and Eclampsia, and B1, N1, N2, and N3 as belonging to neither diagnostic class. All runtime classifications matched both the HermiT entailments and the expected outcomes in Table 6. No prenatal-specific modification to the BAB generator or its transformation mechanisms was required. These internally obtained results provide evidence that the complete ontology-to-code pipeline can be transferred across static-classification domains. The accompanying public artifact independently reproduces the ontology-level entailments and expected classifications, but it does not reproduce the execution of the proprietary generator or the generated application.

6.6. Partial Timing Measurements

Table 7. Partial HermiT reasoning and BAB code-generation times.

Ontology	Operation	n	Mean ± SD (ms)	Median (ms)	Minimum–Maximum (ms)
ResearchEvaluation	HermiT reasoning	30	1465.684 ± 243.356	1405.392	1184.527–2240.665
PrenatalDiagnosis	HermiT reasoning	30	1369.898 ± 258.580	1293.901	1116.119–2091.937
ResearchEvaluation	BAB code generation	30	100.208 ± 66.049	89.467	36.126–309.954
PrenatalDiagnosis	BAB code generation	30	106.654 ± 109.054	70.265	19.347–433.398

reports the repeated HermiT reasoning and BAB code-generation measurements for the ResearchEvaluation and PrenatalDiagnosis ontologies. All measured repetitions completed successfully and produced the expected reasoning or generation results. The HermiT measurements included consistency, satisfiability, subsumption, and expected-entailment verification for the corresponding ontology-level validation package. The generation measurements produced 44 managed files for ResearchEvaluation and 24 managed files for PrenatalDiagnosis in every repetition.

HermiT reasoning required approximately 1.37–1.47 s on average, whereas generation of the corresponding BAB project structure required approximately 0.10–0.11 s. The dispersion, particularly for code generation, reflects workstation-level effects such as Java Virtual Machine activity, just-in-time compilation, operating-system scheduling, and file-system operations. The measurements are therefore reported as descriptive evidence for these two ontology instances. They do not constitute a scalability evaluation or demonstrate performance superiority over Jess, Drools, or other rule-processing technologies.

7. Discussion

7.1. The Three-Artifact Pattern as Architectural Anti-Pattern

The comparison shows that the three-artifact pattern appears in both examined systems. The pregnancy monitoring system (Drools, Spring Boot, Vue.js, 2022) and the research evaluation system (Jess, Java EJB, 2015) share this pattern despite having nothing else in common. In the BAB approach, these three concerns are represented in one ontology-based source model, which makes the difference architectural rather than merely technological.

The important practical difference is the point at which errors can be detected. In research evaluation, detecting that a rulebook contains an unsatisfiable category before generating the system prevents deployment of a tool that would silently fail to classify certain conferences. In prenatal care, detecting that a diagnostic rule set contains unreachable conditions, perhaps a disease definition whose required symptom combination is logically impossible given the symptom group definitions, would prevent a clinical decision support system from containing dead diagnostic paths. This type of semantic verification is not part of the ordinary execution model of Jess or Drools. Drools provides syntax validation and selected static checks, while broader verification of semantically inconsistent, incomplete, redundant, or unreachable rule combinations requires dedicated rule-base verification techniques [47,48].

7.2. The Suitability Spectrum

The cross-domain analysis in Section 3.4 reveals that ontological formalization is not universally superior; it occupies a specific niche on the suitability spectrum. Classification rules over static data (conference evaluation, symptom-based diagnosis) map directly to OWL-defined classes and benefit most from DL reasoning. Arithmetic computation rules (screening test risk scores) require SWRL extensions, introducing complexity that diminishes the advantage over standard Drools rules, which natively handle these static values and basic computations. Temporal event processing rules (CTG monitoring) are fundamentally unsuited for the current approach and benefit from Drools’ CEP capabilities.

For mixed systems, hybrid architecture is therefore more realistic: ontology-driven generation for the structural and classification components (entities, forms, CRUD operations, static rule evaluation), combined with a Drools CEP module for real-time processing components. The pregnancy monitoring system [6] exemplifies this boundary: its disease diagnosis and screening subsystems could be ontologically formalized and generated, while its CTG subsystem would remain Drools-powered.

7.3. Software Engineering Perspective

Beyond reproducing the Jess-based or Drools-based classification results, the proposed architecture has practical implications for long-term enterprise software engineering. Because the domain model, evaluation rules, and generation metadata are maintained within a single ontology, modifications to business policies are localized to one source artifact rather than being propagated manually across data models, rule files, and application code. The regenerated persistence, business-logic, and presentation layers remain structurally synchronized, reducing the maintenance effort associated with the evolution of domain knowledge and business rules.

The ontology also enables formal consistency verification before deployment through DL reasoning, allowing contradictory or unsatisfiable rule definitions to be detected before application generation. In conventional procedural rule-based approaches, equivalent defects are typically discovered only during testing or production execution.

From a software engineering perspective, the proposed framework facilitates the development of enterprise-scale information systems by automatically generating a standardized multi-layer architecture comprising persistence, business-logic, data-transfer, and presentation layers from a single validated ontology. This enables developers to focus on domain knowledge and application-specific requirements rather than on repetitive implementation tasks, while ensuring that all generated architectural layers remain consistent with the underlying conceptual model. The approach is particularly suitable for enterprise information systems whose business logic is primarily governed by declarative rules and domain knowledge. As discussed in Section 1 and Section 2, this includes rule-based systems, or parts of them, that are centered on static classification rather than CEP, such as research evaluation, accreditation, certification, grant and procurement evaluation, quality assurance, compliance management, document classification, clinical diagnostic support, insurance underwriting, academic credentialing, and similar domains in which business policies are expressed as declarative rule sets and traceability between domain knowledge and executable software is essential.

7.4. Limitations

7.4.1. Validation Scope

The complete ontology-to-code pipeline was executed internally in two application domains. In the research-evaluation domain, the generated application reproduced the established Jess-based classifications. In the prenatal-diagnosis domain, six synthetic records were first validated at the ontology level and were subsequently evaluated in an application produced by the unchanged BAB generator. The generated-application results matched the HermiT entailments and expected diagnostic outcomes. However, because the proprietary BAB generator and the generated application source code are not included in the public artifact, the end-to-end execution results should be interpreted as internal feasibility evidence rather than as an independently reproducible validation of the complete pipeline. The public artifact supports independent reproduction of the ontology-level reasoning experiments.

The architecture itself is domain-independent, whereas the evaluated ontology content is domain-specific. Consequently, validating additional application domains would primarily demonstrate the portability of the architectural workflow rather than introduce fundamentally different reasoning mechanisms.

Nevertheless, external validity remains limited to two case studies dominated by static classification rules, and further evaluation is required across additional domains and larger datasets.

7.4.2. OWL 2 DL Expressiveness

Arithmetic operations, temporal reasoning, and procedural computation exceed OWL 2 DL’s native capabilities. SWRL can partially express arithmetic predicates, but at the cost of increased reasoning complexity and reduced separation from procedural rule execution. This limitation should be understood as a limitation of the current OWL-first BAB validation pipeline, not as a claim that such computations cannot be handled in hybrid semantic architectures. Recent hybrid decision-management approaches combine DMN with machine-learning-based analysis, while ontology-oriented approaches have explored the integration of decision-tree rules with OWL/SWRL through external Python modules [49,50]. These approaches confirm the relevance of hybridization, but they also reinforce the architectural boundary adopted in this paper: OWL remains appropriate for semantic classification and consistency checking, whereas arithmetic decision logic, learned decision models, and temporal event processing are better delegated to complementary decision-management, machine-learning, or procedural components.

7.4.3. Priority Resolution

OWL classification cannot capture salience-based rule ordering, since under the OWA overlapping categories cannot be made exclusive through class negation. This overlap is a consequence of open-world ontology classification and is distinct from closed-world completeness checking at runtime. The deployed ontology demonstrates this concretely: HermiT infers InternationalConference ⊑ NationalConference as a logical consequence of the rulebook, because every M30 conference also satisfies the weaker M60 condition. The rulebook’s intended semantics, namely assigning the highest applicable category, is therefore not expressible by OWL class axioms alone. Priority is handled by a deterministic post-classification step driven by EvaluationCategory metadata ordered by priorityPosition and declared in the selected EvaluationRulebook individual; the generated procedural layer implements this step but does not author the priority policy itself. We consider this a principled decomposition rather than a leak of business logic into the application layer: classification semantics remain DL-verifiable in the ontology, while the finite priority list is reified ontologically and consumed deterministically. The generated Java layer therefore performs two separate operations: it evaluates the translated class predicates over complete runtime records under CWA, and it subsequently resolves overlapping positive results according to the ontology-declared priority order.

SHACL can complement this decomposition, but it does not replace the priority-resolution step. In a future extension, SHACL shapes could validate the closed-world structural preconditions of the priority mechanism, for example, that every EvaluationCategory has exactly one categoryCode, one priorityPosition, and one mapsToOntologyClass value, that priority positions are well formed within a selected rulebook, and that the final evaluated result contains exactly one assigned category. Such SHACL validation would strengthen data-integrity checking around the priority mechanism, while the actual selection of the highest applicable category would remain a deterministic post-classification operation over the ontology-derived class memberships [43,46].

7.4.4. Generated Code Characteristics

The BAB generator produces correct, functional code optimized for maintainability rather than runtime performance. Large-scale deployments may require optimization.

7.4.5. Learning Curve

OWL/SPARQL require more specialized knowledge than Drools’ Java-like syntax.

7.4.6. Framework Maturity and External Validity

BAB remains an author-developed research prototype that has not yet been independently evaluated at scale. The present study provides end-to-end feasibility evidence in two static-classification domains, but it does not assess comparative development effort, runtime scalability, or broad generalizability beyond the investigated cases.

The primary validation outcomes reported in this study (ontology consistency, class satisfiability, inferred subsumption, generated-project structure, and agreement between expected and observed classifications) are deterministic functional results. In addition, repeated wall-clock measurements were collected for the HermiT reasoning and BAB code-generation stages to characterize their execution time and observed dispersion on the evaluation workstation. These timing measurements are reported descriptively and are not used for inferential statistical testing or claims of comparative performance superiority.

7.4.7. Partial Timing Measurements and Benchmarking Boundary

Partial wall-clock measurements were collected for HermiT reasoning and BAB code generation over the two evaluated ontologies, as reported in Section 6.6. These measurements address only two stages of the ontology-to-code workflow. Deployment time, application-execution latency, throughput, memory consumption, CPU utilization, concurrent load, and scalability were not measured. Accordingly, the reported values should not be interpreted as evidence of run-time efficiency or industrial-scale performance.

A direct experimental performance comparison with procedural rule engines such as Jess and Drools remains beyond the scope of the present study. Such an evaluation would require implementing equivalent benchmark applications in all three approaches under identical software and hardware conditions, using the same domain model, datasets, runtime environment, and experimental protocol. The existing Jess-based, Drools-based, and BAB-based applications were developed independently over different technological generations, using different Java versions, frameworks, hardware platforms, and, in the case of Drools, a different application domain. Consequently, a direct comparison of execution time, throughput, or other performance metrics would not isolate the contribution of the underlying methodology and could therefore lead to misleading conclusions. The partial measurements reported here therefore characterize only the two BAB ontology instances examined and do not provide a comparative baseline.

7.5. Implications

The approach is most appropriate when the rules classify already structured records. Examples include regulatory checks, insurance underwriting, academic credentialing, and quality grading. In such cases, the rules should be stable enough to justify regeneration, and the cost of an incorrect classification should be high enough to make pre-generation verification worthwhile. Domains combining classification with real-time processing (clinical monitoring, industrial process control) would benefit from hybrid architectures.

Concretely, such a hybrid partitioning of the pregnancy monitoring system [6] would generate the disease diagnosis and screening test subsystems, comprising approximately two-thirds of the system’s entity model and UI, from the ontology, while retaining the Drools CEP implementation only for the real-time CTG monitoring module. Changes to diagnostic criteria would then require only ontology modification and re-generation, limiting manual development to the temporal processing component alone.

A second hybridization direction concerns the integration of DMN decision tables into the BAB pipeline. In such an architecture, OWL would remain the source artifact for the domain model, implementation mappings, reasoning checks, and code-generation metadata, while DMN tables would specify parts of the decision-rule layer where tabular rules, explicit hit policies, and arithmetic decision logic are more naturally expressed. The BAB generator could then treat DMN models as rule-layer artifacts linked to OWL-defined domain entities, generating the surrounding persistence, service, and UI layers from the ontology while delegating selected decision evaluations to a DMN engine. This direction is outside the scope of the present validation, but it provides a natural path for combining ontology-level reasoning with standardized decision-table execution.

Finally, the present paper does not re-derive the full formal semantics of the BAB transformation chain. The preservation of structural mappings across the PIM–PSM–code pipeline follows from the BAB framework itself, where ontology concepts, implementation mappings, and code templates are related through deterministic model transformations. In this work, the BAB transformation semantics is adopted as an architectural assumption and applied to OWL-defined classification rules in two domains. The contribution comprises the reproduction of the established Jess-based research-evaluation classifications and an internal end-to-end transfer experiment in the prenatal-diagnosis domain, in which all six runtime classifications matched the HermiT entailments and expected outcomes. The accompanying artifact independently reproduces the ontology-level results, whereas execution of the proprietary generator and generated application was performed internally.

7.6. Prospective LLM-Assisted Rule Acquisition and Verification Workflow

Large Language Models could support the BAB pipeline during rule acquisition, but they should not directly modify the verified ontology or generated application. Their role would be limited to extracting candidate entities, conditions, thresholds, exceptions, and provenance information from regulatory or clinical documents. Each extracted candidate rule would be represented in a controlled intermediate format containing the source passage, involved domain concepts, antecedent conditions, expected conclusion, and confidence metadata.

The candidate rule would then pass through a deterministic normalization and verification workflow. First, its terminology would be mapped to existing ontology classes and properties. Second, the normalized rule would be transformed into a candidate OWL class axiom, SWRL rule, or external decision-table representation, depending on its logical structure. Third, HermiT would evaluate ontology consistency, class satisfiability, and newly introduced subsumption relationships. Candidate rules producing inconsistency, unsatisfiable classes, unintended equivalence, or unexpected category overlap would be rejected and returned for human revision. Regression ABoxes with expected classifications would provide an additional behavioral check before the candidate rule could be accepted.

This workflow would filter several common classes of LLM errors, including the use of nonexistent ontology terms, incompatible datatypes, contradictory thresholds, and logically inconsistent conditions. However, ontology reasoning cannot determine whether a syntactically and logically consistent rule correctly represents the meaning of the source document. Human validation and traceability to the original passage would therefore remain mandatory. Only approved and formally verified rules would enter the BAB ontology-to-code generation pipeline. This prospective integration preserves the deterministic and auditable character of BAB while using the LLM solely as an assisted rule-acquisition component.

8. Conclusions

This paper examined whether a rule-based information system can be generated from an OWL 2 DL source model instead of being built around a separately maintained data model, rule base, and application layer. Through analysis of two representative systems, a Jess-based research evaluation system and a Drools-based pregnancy monitoring system, we identified a recurring three-artifact architectural pattern that persists across domains, decades, and rule-engine generations. This recurring architectural pattern exposes common software engineering challenges that persist independently of the underlying rule engine.

In the BAB setting, the domain model, rule definitions, and generation metadata are represented in one OWL-based source model. Validated on the ICIST 2014 Serbian research evaluation case study, the generated system produces results identical to the Jess-based implementation (M30, M33) while providing pre-generation logical consistency, satisfiability, and subsumption checking before deployment, capabilities that are not available in conventional procedural rule-engine development. The approach further enables full traceability from domain axioms to executable artifacts and standards-based interoperability through World Wide Web Consortium (W3C)-compliant RDF, OWL, and SPARQL.

The three-way comparative analysis demonstrates that the limitations of procedural rule-based development are architectural rather than engine-specific: both Jess and Drools share the absence of formal verification, the manual synchronization burden, and engine-specific rule formats. The ontological approach addresses these limitations for classification-type rules, while procedural engines retain advantages for arithmetic computation and real-time CEP capabilities.

A secondary internal end-to-end experiment in the prenatal-diagnosis domain provided additional feasibility evidence that the same ontology-to-code pipeline can be transferred without framework-level modifications. The unchanged BAB generator produced the prenatal application, and execution of the six validation records reproduced the HermiT entailments and expected diagnostic outcomes. Together, the two experiments indicate that the approach is not restricted to the original research-evaluation case study and may support cross-domain transfer for static-classification systems. The public artifact enables independent reproduction of the ontology-level validation, while the proprietary generator execution remains internally evaluated.

Future work is organized into three phases corresponding to the limitations identified in Section 7.4. Building on the partial reasoning and generation measurements reported in Section 6.6, Phase 1 will strengthen empirical validation through controlled comparative experiments involving equivalent implementations, shared datasets, and identical hardware and software environments. The evaluation will extend beyond reasoning and generation to deployment time, application-execution latency, throughput, CPU and memory consumption, concurrent load, and scalability, with repeated runs and dispersion reported for every metric. The pipeline will also be evaluated in additional domains, on larger ontologies and datasets, and in settings where static-classification rules coexist with temporal processing requirements. Phase 2 will extend the supported validation and decision semantics. SWRL built-ins and DMN decision tables will be investigated for arithmetic expressions, tabular rules, and explicit hit policies, while OWL will remain responsible for domain modeling and consistency verification. SHACL will also be investigated for closed-world structural validation of RDF instance data before ontology reasoning or classification. In the current implementation, equivalent completeness decisions remain embedded in the generated Java validation layer; SHACL would externalize these constraints at the RDF boundary without changing the OWA semantics of OWL reasoning. Phase 3 will investigate hybrid and assisted development workflows by integrating the generated OWL-based components with a Drools CEP module for systems requiring both static classification and real-time monitoring, and by evaluating the prospective LLM-assisted rule-acquisition and verification workflow described in Section 7.6.

The reusable architectural pattern derived from this study comprises five stages: (1) representing the domain model, classification rules, and generation metadata in an OWL-based platform-independent model; (2) verifying consistency, satisfiability, and subsumption under open-world semantics; (3) projecting the verified model to a platform-specific ontology; (4) generating the persistence, service, data-transfer, and presentation layers; and (5) evaluating persisted records in the generated Java application under closed-world runtime semantics, followed by deterministic resolution of overlapping categories. This pattern is applicable to information systems whose principal business rules classify structured records, while arithmetic, probabilistic, or temporal rules may be delegated to complementary components.

In conclusion, this work demonstrates that ontology-driven development, grounded in formal DL reasoning and deterministic code generation, provides a viable and advantageous alternative to procedural rule-engine-based development for static classification systems. By unifying the domain model, declarative rule definitions, and implementation metadata within a single, formally verifiable source artifact, the proposed approach addresses the architectural limitations of traditional rule-based systems, enhances maintainability and traceability, and offers a foundation for future hybrid architectures that combine ontological reasoning with procedural event processing.