From Text to Executable Semantics: A Modular Ontology and SHACL Controls for University Intellectual Property Non-Disclosure Agreements in Colombia

Abstract

The management of intellectual property (IP) agreements in universities continues to rely on static legal documents that are signed, archived, and consulted when necessary, but whose content is rarely formalized to facilitate their operation and verification. Consequently, obligations, permissions, restrictions, deadlines, scopes, and exceptions often remain scattered across clauses drafted in natural language, annexes, emails, and different document versions, which hinders their monitoring and makes compliance review dependent on intensive legal and administrative work. In response to this limitation, this article proposes an ontology to formalize non-disclosure agreements (NDAs) at the University of Caldas, Colombia, understood as a specific case within the broader management of IP agreements. The proposal adopts a modular Semantic Web architecture composed of a reusable ontological core and a specialized profile for NDAs. Its construction followed the METHONTOLOGY methodology, and its specification was supported by Competency Questions (CQs), which were subsequently translated into SHACL constraints and SPARQL queries. In addition, a SKOS vocabulary is incorporated to normalize synonyms and terminological variants typical of legal drafting in Spanish, together with a lightweight weak supervision layer based on regular expressions, SKOS, and structural signals to support clause labeling and the batch generation of RDF instances. Thus, the proposal enables querying, traceability, and verification over NDA content, while offering a formal basis for progressing toward automatable controls and their eventual articulation with smart contracts.

1. Introduction

Intellectual property (IP) agreements play a central role in research development and in the relationship between universities, the State, and the productive sector, insofar as they establish rules to create, use, protect, and transfer knowledge and results with strategic value [1]. In the current context, university research is carried out within collaborative ecosystems that transcend the organizational boundaries of a single institution and are articulated through networks in which research groups, technology transfer offices, external partners, public entities, and funding bodies converge [2]. Within these dynamics, data, prototypes, software, and results are shared at different levels of maturity, so that IP agreements not only formalize legal relationships, but also organize decisions, enable exchanges, and establish obligations that must remain coherent throughout the project life cycle [3,4,5].

From an operational perspective, these agreements delimit rights for the use, exploitation, and transfer of results, and establish conditions related to scope, duration, territory, jurisdiction, confidentiality, and the responsibilities of the parties [6]. In this sense, their clauses are not limited to allocating rights, but also regulate what may be disclosed, when, under which restrictions, and with what effects, directly influencing scientific publication, collaboration with third parties, and institutional risk management [6]. Indeed, in publicly funded collaborations between universities and industry, the systematic analysis of contracts has revealed significant heterogeneity in aspects such as ownership, exploitation rights, publication policies, and confidentiality rules, confirming that contractual configuration conditions the governance of results and the circulation of knowledge [6,7].

Despite this relevance, the management of these agreements continues to rely, in many cases, on a predominantly document-based logic. In practice, the process usually follows a recurring sequence: a template is drafted or adapted, clauses are negotiated, the document is signed, archived, and later consulted again to resolve questions, address audits, or process amendments. Thus, the contract becomes consolidated as an authoritative source, but its content remains essentially expressed in natural language [8,9]. As a consequence, the operational semantics of the agreement are distributed across definitions, exceptions, internal cross-references, and clauses whose interpretation depends on context. When an attempt is made to transfer this content into information systems, the absence of a stable bridge between legal language and a representation that enables consistent querying, traceability, and verification becomes evident.

The central difficulty, therefore, does not lie solely in reading the document, but in the absence of a computable representation of its legal semantics. The contract articulates concepts, conditions, exceptions, and internal dependencies whose interpretation is contextual and which, by remaining exclusively in natural language, limit traceability and control [8,9]. This situation produces recurring effects, including inconsistencies between versions, ambiguities derived from synonyms or equivalent formulations, weak capacity to compare agreements in a homogeneous manner, and the absence of structured evidence linking clauses to internal verifications [10].

These limitations become particularly visible in non-disclosure agreements (NDAs). They often constitute the first instrument signed within a project and, from its early stages, establish limits on the use, disclosure, custody, and exceptions regarding sensitive information [6]. In this type of agreement, specific omissions or imprecise formulations may translate into relevant institutional risks, such as the exposure of strategic information, tensions with partners, or conflicts with personal data protection obligations under Law 1581 of 2012 [11] and with the protection of trade secrets within the Andean framework [12]. In real collaboration scenarios, this regulatory convergence requires consistency, so it is not enough to understand the contractual text; it is also necessary to compare, audit, and validate it according to repeatable criteria.

Based on this problem, the objective of this article is to propose a formal representation of the legal semantics of IP agreements, with an emphasis on NDAs, through an ontology that enables automation at two complementary levels [13,14,15]. The first corresponds to interpretation, insofar as it allows explicit facts to be queried and relevant relationships within the agreement to be inferred [16,17,18]. The second corresponds to translation, by converting legal requirements into executable controls and traceable evidence [13,14].

The proposal relies on consolidated Semantic Web standards. First, the conceptual model is formalized in OWL 2, which makes it possible to precisely describe the entities and relationships of the domain [16]. On this basis, validation is implemented through SHACL (Shapes Constraint Language), a language oriented toward defining constraints that must be satisfied by data represented in a graph. This makes it possible to express and verify conditions such as the existence of a start date in an agreement, the identification of each party, or the specification of the duration of a confidentiality clause when such a clause is present [19].

In turn, auditable evidence is obtained through SPARQL (Protocol and RDF Query Language) queries, which allow the graph to be interrogated regarding the content of an agreement, an obligation, or an exception, and to retrieve verifiable results together with the relationships that support them [20]. Finally, the agreements are represented as RDF graphs, which facilitates maintaining traceability between entities, relationships, and documentary sources, so that each assertion can be linked to the contractual fragment that supports it [21].

On this basis, the proposed architecture adopts a modular approach. On the one hand, it defines a stable core, pi_core, where the concepts shared by different types of IP agreements are located. On the other hand, it incorporates a specific profile for NDAs, which captures the particularities associated with confidentiality. This organization favors the reuse, maintenance, and extensibility of the model, insofar as it allows specialized profiles to be adjusted without compromising the stability of the conceptual core [18]. Consistent with this, the validation of both the model and the data is articulated through SHACL constraints and SPARQL queries, which transform legal rules and domain assumptions into automatable verifications [14].

Within this framework, Competency Questions (CQs) play a central role, since they operate as functional requirements of the model by expressing what the ontology must be able to answer. Subsequently, these questions are translated into concrete tests, either as SHACL constraints or as SPARQL queries that return verifiable evidence. Treating CQs as a traceability mechanism between requirements and validation has been recognized as an effective strategy in the development of ontologies and knowledge graphs [22], and is consistent with recent evidence on their role in defining and evaluating requirements in ontology engineering [23]. Along the same lines, this form of verification is related to recent experiences in the large-scale formalization of constraints through SHACL and SPARQL in collaborative environments [14].

In order to reduce the ambiguity inherent to legal Spanish, where the same notion may be expressed through synonyms, institutional variants, or equivalent formulations, the proposal incorporates SKOS (Simple Knowledge Organization System) as a mechanism for vocabulary governance [24]. SKOS makes it possible to explicitly declare the preferred term, its variants, and the way in which concepts relate to each other, thereby contributing to a consistent naming of the domain elements. Complementarily, the article describes a lightweight layer to support labeling and extraction based on weak supervision, which is useful for accelerating the creation of instances without depending on exhaustive manual annotation processes [25].

The proposal is also situated within the broader set of solutions oriented toward contract analysis. While approaches such as SymboleoPC explore formal verification through model checking over contractual specifications, the emphasis of this work is placed on the operational bridge between legal text, semantic representation, and control, with specific attention to the needs of university institutional management [26].

In this sense, the main contribution of the article consists of a modular ontological architecture to represent and audit the legal semantics of intellectual property agreements, with an emphasis on non-disclosure agreements [6,18]. This architecture combines a reusable core (pi_core) with a specific profile for confidentiality, and translates Competency Questions into verifiable mechanisms through SHACL constraints and SPARQL queries, connecting each requirement with traceable evidence [14]. To reduce terminological ambiguities, SKOS is incorporated and, when the agreement involves the processing of personal data, privacy vocabularies (DPV) and policy vocabularies (ODRL) are articulated. Likewise, a lightweight extraction layer is integrated to accelerate the generation of RDF instances without depending on exhaustive annotation [25]. The prioritization of NDAs responds to their high frequency in the case-study corpus and to the fact that, in practice, their clauses intersect with the protection of trade secrets and with data protection obligations [6].

The remainder of the article is organized as follows. Section 2 presents the background on confidentiality agreements, legal semantics, and Semantic Web standards. Section 3 describes the materials and methods, including the corpus, confidentiality and data governance criteria, the METHONTOLOGY based process, the ontological architecture, SHACL validation, SPARQL evidence retrieval, and RDF instance generation. Section 4 reports the results, including structured representation, ontology statistics, RDF extraction performance, SHACL validation, SPARQL query evaluation, comparative analysis, and threats to validity. Section 5 discusses the implications and scope of the findings. Section 6 presents the conclusions and future work.

2. Background

In recent literature, the application of the Semantic Web to the legal domain has become consolidated as a practical way to transform contracts and regulations into queryable and verifiable structures, beyond their traditional document-based reading [27]. In parallel, the use of modular ontologies has acquired relevance because it makes it possible to distinguish stable domain components and extend them without rebuilding the entire model, an aspect that is particularly important when multiple types of agreements or institutional variations coexist [18].

On this basis, validation through executable constraints has become an operational control mechanism, especially when SHACL and SPARQL are articulated to express rules and produce verifiable evidence [14]. This is complemented by a central methodological aspect: the traceability of each assertion back to its source. This requirement has driven proposals aimed at automatically verifying the textual support of triples in knowledge graphs, in order to strengthen their value for auditing and control [10].

In parallel, the empirical analysis of contracts in publicly funded collaborations has shown that clauses related to ownership, disclosure, and confidentiality present significant variations, which reinforces the need for models capable of making these commitments comparable and controllable in real institutional management contexts [6].

2.1. Formal Modeling of Contracts and Regulations for Compliance Verification

The convergence between the Semantic Web and law has evolved from predominantly exploratory proposals toward operation-oriented approaches, in which the representation of contracts and regulations seeks to improve querying, case comparison, and, increasingly, compliance verification [26,27]. This shift can be observed in three lines of work that, although they present different emphases, share the same orientation: moving from legal text to computable artifacts with traceability and control capacity [14]. Figure 1 synthesizes these three lines and shows the point at which they converge: the transition from text to semantics and from semantics to verifiable control, which is precisely the operational axis adopted in this article.

Figure 1. The convergence of three lines of research.

2.1.1. Formal Representation and Compliance Verification

A first line is located in formal and deontological approaches; that is, in logical frameworks designed to describe norms and commitments in a way that enables their systematic analysis [26]. Their purpose is to represent contracts with a sufficient degree of precision to reason about obligations, permissions, prohibitions, and possible violations, and thus to evaluate whether a given behavior conforms to what was agreed upon or departs from it [26].

In this direction, SymboleoPC proposes a model-based framework for analyzing contracts expressed in Symboleo and verifying properties through model checking, supported by tools such as nuXmv [26]. This type of approach is relevant because it transforms the contract into an object that can be subjected to systematic analysis, reducing dependence on case-by-case readings when what is required is repeatable verification [26]. In addition to SymboleoPC, there are representative works that show how formal verification is applied from different perspectives. For example, recent implementations of deontic logic have been developed for practical and efficient reasoning in legal domains, such as the encoding in Answer Set Programming of a defeasible deontic logic [28]. Similarly, verification frameworks have been proposed that integrate temporal and normative dimensions to check compliance against temporal constraints through SMT-based model checking techniques, illustrating the current interest in combining normativity and computational verification in more complex legal scenarios [29].

2.1.2. Legal Knowledge Extraction and Traceable Knowledge Graph Construction

A second line of work focuses on the construction of knowledge graphs in the legal domain and on the design of pipelines that extract information from documents and transform it into structured and queryable data [27,30]. At this point, the challenge remains persistent: legal language incorporates exceptions, internal definitions, and contextual dependencies, so knowledge extraction from text recurrently faces ambiguity, terminological variation, and polysemy. This requires methods capable of capturing nuances and maintaining consistency in the resulting representation [31].

The ASKE approach addresses this problem through an iterative extraction cycle based on “generations,” in which contextual embeddings and zero-shot strategies are combined to refine concepts and manage multiple meanings in legal documents [27]. This type of proposal is particularly useful because it is not limited to identifying isolated entities or relationships, but rather seeks to build more stable domain representations from heterogeneous legal text.

Within this same line of work, provenance has become a central methodological requirement. If each assertion cannot be traced back to its source, the graph loses value for auditing and verification [10,32]. In this sense, ProVe proposes a pipeline aimed at automatically checking whether a triple is supported by text extracted from its documented provenance, with the purpose of reducing the burden of manual verification in large-scale graphs [10].

2.1.3. Constraint-Based Validation and Operational Quality

A third line focuses on executable validation and the operational quality of the graph. In this area, SHACL has become consolidated as a standard for expressing integrity constraints and generating actionable reports on RDF graphs [19]. Likewise, the value of combining SHACL with SPARQL has become evident for formulating more expressive rules and detecting non-compliance at scale, especially when what is required is not only validation, but also the generation of verifiable evidence [13,14,15]. A representative example is the work that formalizes Wikidata property constraints using SHACL and SPARQL, showing how rules initially described in a partial or ambiguous manner can be translated into explicit and comparable validations [14].

A more recent cross-cutting agenda is added to these three lines: the use of language models in tasks of graph construction, maintenance, and quality control, with promising results in productivity, although with direct implications for traceability, error control, and governance [33]. This turn opens opportunities, but also requires discussing how what is generated is validated, how reasoning is audited, and how uncertainty is managed when automation intervenes in the graph life cycle [33,34]. In this direction, human-in-the-loop strategies have been evaluated that combine experts with language models to improve validation workflows, showing that hybrid approaches can more effectively balance precision, human effort, and overall performance [34]. Likewise, recent reviews systematize techniques and applications in which language models and graphs complement each other, and underline that validation remains a critical component when the objective is operational use and not only technical demonstration [33].

With this panorama, when moving down to the field of institutional IP contracts and, in particular, university NDAs, practical gaps emerge that motivate the present proposal. In terms of knowledge architecture, truly modular designs that separate stable legal components from profiles according to contractual typology remain uncommon, which is crucial when multiple templates and institutional variation coexist [18]. In the complete verification chain, many proposals advance in modeling or extraction, but do not systematically close the circuit between question, rule, and evidence with auditable traceability. Finally, in terms of sensitivity to jurisdiction and language, modeling designed from legal Spanish and from concrete regulatory frameworks remains limited, precisely where these agreements are applied and audited in practice [31].

The present proposal is situated in that space. Its interest lies in integrating formalization, extraction with verifiable support, and validation through constraints, with a focus on university operations, so that NDAs cease to be merely archived text and become consultable, verifiable knowledge, accompanied by evidence suitable for audit.

2.2. Confidentiality Agreements and Their IP Practice in Colombia

In the practice of intellectual property, few tools are as discreet and, at the same time, as decisive as confidentiality agreements [6]. A confidentiality agreement is not limited to declaring that certain information is reserved [6]. In reality, it turns confidentiality into a set of operational decisions: what is considered protected information, who may access it, for what purposes it may be used, under what conditions it may circulate, for how long the duties are maintained, and what rules of jurisdiction or territory frame the relationship [6].

This level of detail is relevant because, in research and technology transfer environments, protection does not depend exclusively on registered rights, but also on the way intangible assets are managed before there is a patent, licensed software, or a publishable result [3]. In this sense, the contractual pathway constitutes a structural component of knowledge transfer and the strategic management of IP [5].

This role becomes especially clear when the NDA is articulated with the protection of trade secrets. In the Andean framework, applicable in countries such as Colombia, Decision 486 establishes that undisclosed information receives protection when three conditions concur: that it is secret, that it has commercial value precisely because it is secret, and that reasonable measures have been adopted to keep it under reserve [12]. In practice, these conditions are not satisfied automatically; they require procedures, controls, and evidence. At this point, the NDA fulfills a critical function, since it helps demonstrate that concrete protection measures existed, that the information was shared under defined restrictions, and that access was governed by clearly established duties. Recent doctrinal discussion on trade secrets in the Andean context precisely underlines that the standard of reasonable measures and its practical proof constitute sensitive points for the effectiveness of protection [35,36].

At the same time, NDAs are rarely limited to industrial secrets or technical know-how. In real projects, it is common for the exchange to include personal data, for example, information about participants, students, staff, patients, or users. When this occurs, the NDA ceases to be only an instrument of corporate confidentiality and enters the field of obligations associated with lawful processing and the security of personal data, in accordance with the data protection regime [11]. Specialized literature in the country has shown that compliance in this area is not a merely formal matter, but rather a component of organizational management that requires policies, responsibilities, and verifiable controls, especially when third parties are involved or when information flows exist between institutions [37].

This double intersection between trade secrets and personal data helps explain why NDAs are so frequent and, at the same time, so sensitive in university contexts and in cooperation with third parties. An ambiguous formulation of what is protected, a poorly defined exception, or an incomplete clause on custody and disclosure may translate into concrete risks: loss of competitive advantage due to exposure of strategic information, frictions with partners due to interpretive breaches, or compliance tensions when the same flow of information activates duties of confidentiality and, simultaneously, requirements of transparency, purpose limitation, and security proper to the personal data regime [11,35]. In other words, the NDA does not only protect information; it also organizes the exchange so that it can be sustained, justified, and institutionally controlled.

From the perspective of this article, the implication is direct: an NDA usually concentrates definitions, exceptions, duties, terms, and restrictions that, in practice, end up determining how knowledge is shared and protected throughout a project [6]. If its reading remains subject only to punctual interpretations, it becomes difficult to sustain consistent decisions when multiple actors, different documentary versions, or comparable agreements are involved [6]. For this reason, it becomes necessary to express it as knowledge that can be consulted, compared, and verified on the basis of repeatable criteria, supported by explicit rules and by evidence traceable back to its source [10,14]. This is the motivation for bringing its legal semantics into a structured and auditable representation, capable of supporting validations and justifying results without depending exclusively on manual case-by-case reviews [10].

2.3. Semantic Web Standards and Why They Matter for Legal Semantics

For the content of an agreement to be processed by a system without losing rigor, this article relies on a set of standards that complement each other and are already widely used in knowledge graph-based solutions [17]. Figure 2 synthesizes the way in which these standards are articulated, from the representation of facts to validation and the extraction of auditable evidence.

Figure 2. From Web Standards to Legal Semantics. Solid arrows denote direct semantic relationships, whereas dashed arrows indicate indirect or inferred relationships.

At the base is RDF, which allows facts to be represented as simple and linkable triples, facilitating the conversion of clauses and definitions into queryable and traceable statements [17]. On this basis, OWL 2 provides formal semantics to precisely describe classes, relations, and domain restrictions, in addition to enabling controlled inferences when the model so allows [17].

Given that contracts often rely on equivalent terms expressed through different wordings, SKOS contributes to vocabulary governance through preferred labels, synonyms, and relations between concepts, preventing coherence from depending on a single way of drafting [24]. For the graph to be not only structured, but also verifiable, SHACL allows integrity rules to be expressed as executable conditions and produces clear reports on violations or missing data [13]. When validation requires more expressive rules or when the aim is to identify precisely where a condition is not met, the combination of SHACL with SPARQL is especially useful, and has shown effectiveness even in large-scale collaborative environments such as Wikidata [14].

SPARQL, moreover, constitutes the practical tool for evidence extraction, since it allows precise retrieval of which obligations, exceptions, or conditions are registered in the graph and through which relations they are supported [20,38]. On the other hand, in those cases where the agreement regulates permissions, prohibitions, and duties of use over information or assets, ODRL offers a vocabulary especially suited to express these policies in an interoperable and application-oriented manner [39]. When the NDA intersects with the processing of personal data, DPV allows the standardized description of data categories, purposes, legal bases, and measures, and has already been used as a reference in works on consent and privacy ontologies [37].

Finally, Protégé (v.5.6.9) remains a practical piece in ontological engineering because it facilitates building, reviewing, and evaluating the model, in addition to supporting common tasks such as consistency analysis and knowledge navigation [17].

3. Materials and Methods

3.1. Corpus and Context

The data processing was based on an institutional subset focused on confidentiality agreements, provided by the Legal Office of the University of Caldas. This type of document is especially relevant because, in practice, it concentrates critical decisions on the use, circulation, and protection of information in contexts of scientific collaboration and knowledge transfer [6].

The corpus includes both institutional templates and versions negotiated with third parties, available in DOCX and PDF formats. This composition makes it possible to observe how the same agreement evolves according to the context, the actors involved, and the specific conditions of each project. Such variations include definitions, exceptions, terms, scopes of confidentiality, and disclosure conditions, elements that introduce complexity and heterogeneity into research contracts [6].

To characterize the corpus, we built a document level inventory based on a uniform counting protocol. The working corpus comprises ten confidentiality documents. Each record was described by format, number of pages, number of main clauses, number of preambular considerations, audit status, and rendering method. Taken as a complete corpus, the documents account for 49 pages, 148 main clauses, and 41 preambular considerations. Main clauses were counted as the primary contractual provisions, while paragraphs, literals, and subparagraphs were registered as internal structure and were not treated as independent clauses. This inventory provided the empirical baseline for RDF generation, SHACL validation, and SPARQL query evaluation.

Table 1 summarizes the general profile of the audited NDA corpus used in this study. The table reports the number of records, document formats, total pages, main clauses, preambular considerations, and clause density, providing a compact overview of the empirical basis used for RDF generation, SHACL validation, and SPARQL query evaluation.

Table 1. NDA corpus profile.

Corpus Attribute	Value
NDA and confidentiality-related documents	10
Audited institutional documents	10
DOCX records	8
PDF records	2
Total pages	49
Total main clauses	148
Total preambular considerations	41
Average clauses per document	14.80
Median clauses per document	16.50
Clause density	3.02

Note. Clause density was calculated as the number of main clauses divided by the number of pages. DOCX records were rendered to PDF when page counting was required.

Table 2 reports descriptive statistics for the audited institutional records only. This subset contains ten reviewed source documents and serves as the empirical basis for the corpus characterization. The measures summarize page length, main clause structure, preambular considerations, and clause density without incorporating simulated entries.

Table 2. Descriptive statistics of the audited NDA records.

Measure	Audited NDA Records
Records	10
Pages, total	49
Pages, mean ± SD	4.90 ± 1.91
Pages, median [min, max]	5.00 [2, 9]
Main clauses, total	148
Main clauses, mean ± SD	14.80 ± 5.03
Main clauses, median [min, max]	16.50 [4, 21]
Preambular considerations, total	41
Preambular considerations, mean ± SD	4.10 ± 0.88
Preambular considerations, median [min, max]	4.00 [3, 5]
Clause density	3.02

Note. Clause density was calculated as the number of main clauses divided by the number of pages. Main clauses were counted as primary contractual provisions; paragraphs, literals, and subparagraphs were recorded as internal structure.

Access to, storage, and use of the corpus were carried out under strict confidentiality controls and criteria of exposure minimization. This decision does not respond only to a procedural consideration, but also to a growing concern in the management of sensitive data and in the construction of knowledge-based systems, where traceability must be balanced with the protection of information [34].

Beyond constituting a set of examples, the corpus was used as an empirical basis to guide the ontological modeling. In other words, each design decision was contrasted with real wordings and with situations that require interpretation and verification in institutional contexts. This approach makes it possible to avoid excessively abstract models and brings the ontology closer to concrete use scenarios, especially in legal domains where ambiguity and terminological variation are frequent [27].

Corpus level statistics are reported in the present subsection to characterize the empirical basis of the study. Ontology level implementation metrics, including the number of OWL classes, properties, axioms, named individuals, RDF triples, SHACL shapes, and SPARQL evidence queries, are reported separately in Section 4.2, Ontology Statistics. This separation avoids mixing documentary corpus characterization with measurements of the implemented semantic artifact.

3.2. Confidentiality, Ethics, and Data Governance

This study was conducted as a single-institution case study based on audited non-disclosure agreement records from the University of Caldas. The reference to the Colombian context should therefore be understood as the legal and institutional setting in which the case study was developed, not as a claim that the proposed model represents all Colombian universities or all national NDA practices. The semantic architecture is designed to be modular and extensible, but its empirical evaluation in this paper is limited to the institutional corpus described above.

Because the source documents contain confidential contractual information, the study followed a restricted disclosure and data minimization approach. This decision is consistent with recent data governance frameworks that emphasize trust, controlled reuse, accountability, and safeguards for sensitive data processing [40]. It is also aligned with privacy by design principles, according to which privacy protection should be considered throughout the lifecycle of a data processing activity rather than added after implementation [41]. The manuscript does not disclose complete agreements, confidential clauses, sensitive negotiations, personal data, signatures, internal identifiers, or legally restricted information. Corpus statistics are reported only in aggregated form, and the examples used to illustrate RDF, SHACL, SPARQL, and validation reports were normalized or represented through controlled identifiers.

The automated components of the study were also treated under a risk-aware governance perspective. The weak supervision layer and RDF generation process were used to support semantic structuring, not to make final legal decisions. This distinction is consistent with recent guidance on AI risk management, which emphasizes governance, measurement, transparency, human oversight, and responsible use of automated systems [42]. For this reason, cases requiring legal interpretation were retained as review items rather than being automatically resolved by the computational layer.

The purpose of the semantic model is to support institutional analysis, validation, and traceable review of recurrent contractual structures, not to expose confidential content or replace legal judgment. Provenance anchors were used to connect semantic assertions with controlled source fragments, while avoiding unnecessary disclosure of protected contractual information. This approach is compatible with recent semantic privacy vocabularies that promote machine-readable and interoperable descriptions of data processing activities, purposes, controls, and legal bases [37]. In this way, the model preserves auditability while keeping confidential contractual content outside the public presentation of the corpus.

3.3. METHONTOLOGY-Based Ontology Engineering Methodology

The development of the ontology was structured through a process inspired by METHONTOLOGY [43], given that this methodology offers a clear sequence of activities, products, and progress criteria. This allows the work to remain oriented toward concrete operational needs and not only toward a theoretical description of the domain [44].

In general terms, the process moved through scope definition, knowledge acquisition, conceptual organization, formalization, implementation, and verification, with iterative adjustments throughout the path. Rather than a strict sequence, it was a process guided by short iterations and progressive decisions. In this context, METHONTOLOGY offered a useful framework to organize the work without losing sight of its practical application [45].

In order to situate the methodological approach adopted, Figure 3 presents the general structure of METHONTOLOGY, where the development, support, and management activities that accompany the ontology construction cycle are distinguished. This view makes it possible to understand that modeling does not occur in a linear way, but rather as a set of actions that are articulated and feed back into each other throughout the ontology construction cycle.

Figure 3. Development, support, and management activities in METHONTOLOGY (adapted from [43]).

However, for the purposes of this work, it is necessary to bring this structure down to a more direct and implementation-oriented flow. In this sense, Figure 4 presents the operational adaptation followed in the study, highlighting the stages that were actually executed and their relationship with the mechanisms for formalization, validation, and exploitation of the model.

Figure 4. Operational adaptation of METHONTOLOGY for the modeling and validation of confidentiality agreements.

Based on this adaptation, the process was developed through the following stages:

1.

Specification stage. In this first stage, the actors involved, the scope of the model, the working assumptions, and the success criteria were defined. This made it possible to clearly delimit which aspects of the domain had to be represented and under what conditions the ontology could be considered useful and evaluable in practical terms [24].

2.

Knowledge acquisition stage. Subsequently, knowledge was collected through the combination of guided reading of the documentary corpus and brief conversations with expert personnel. This stage made it possible to identify recurring terms, internal dependencies, ambiguities, and expressions specific to the negotiation context, in order to ensure that the modeling faithfully reflected the domain of interest [27].

3.

Conceptualization stage. Based on the information collected, an initial glossary and a preliminary organization of concepts, relations, and restrictions were developed. In this phase, competency questions were also formulated, treating them as functional requirements of the model, since they make it possible to establish precisely what the ontology must be able to answer and contribute to avoiding overmodeling [15,23].

4.

Formalization stage. Once the conceptual structure had been defined, it was translated into axioms and formal representation patterns. The purpose was to guarantee the logical consistency of the model and to enable controlled inferences when these added value to the verification and analysis processes, in line with recent practices in ontological validation [15].

5.

Implementation stage. In this stage, the ontology was published in OWL, using Turtle serialization and explicit imports, with the purpose of preserving modularity and facilitating the reuse of the ontological core in different profiles or specific contexts [24].

6.

Verification and validation stage. To connect the requirements with their effective verification, the competency questions were transformed into executable tests through SPARQL queries and SHACL constraints, following recent validation practices based on open standards. The evaluation was developed iteratively considering three main signals: the coverage of the competency questions, the validation reports on test data, and expert feedback regarding the usefulness and interpretability of the results for audit purposes [14,22].

7.

Iterative refinement stage. Finally, the process was repeated until the model was stabilized, prioritizing the clarity of the evidence, traceability, and the capacity to compare agreements, above an indefinite increase in ontological detail. In this way, the ontology evolved through successive cycles of adjustment and improvement, which reinforces both its practical utility and its methodological consistency [34].

3.4. Ontological Architecture and Modular Design of the Model

Once the methodological process had been defined and the corpus validated as an empirical basis, the next step consisted of structuring the knowledge into an architecture capable of supporting both the interpretation and the verification of the agreements. This decision is particularly relevant in legal domains, insofar as the way the model is organized directly conditions its capacity to answer questions and generate consistent evidence [18,24].

The proposed architecture adopts a modular approach. Instead of building a monolithic ontology, a stable conceptual core, called pi_core, and a specific profile oriented toward confidentiality agreements were defined. This separation makes it possible to distinguish between general intellectual property elements, which tend to remain constant, and those that depend on the contractual type and its context of application [18].

The pi_core core brings together cross-cutting concepts such as actors, obligations, permissions, restrictions, contractual events, and relations between entities. These elements function as domain primitives, that is, as reusable basic blocks that can be extended without redefining the model from scratch. This type of design has shown to be important for maintaining consistency and facilitating the evolution of ontologies in complex scenarios [24].

On this core, the specific profile for confidentiality agreements, recognized as NDA, is built, incorporating concepts proper to this type of instrument, such as classes of protected information, disclosure conditions, exceptions, validity terms, and custody rules. This layer does not replicate the core, but rather specializes it, allowing the particularities of the agreement to be captured with greater precision without losing structural coherence [6].

A central aspect of the design is that each element of the model is defined according to its subsequent use. In other words, classes, properties, and relations are not introduced only for conceptual exhaustiveness, but because they make it possible to answer concrete questions or support specific verifications. This principle, aligned with recent task-oriented ontology engineering approaches, avoids overloaded models and improves their practical utility [23].

Modularity also facilitates integration with existing vocabularies. In particular, it allows schemes such as SKOS to be incorporated for terminological management, as well as specialized vocabularies when the agreement intersects with other domains, such as privacy or usage policies. This type of interoperability constitutes an increasingly relevant condition in the development of knowledge graphs applied to institutional contexts [37].

On this basis, the architecture establishes the conditions for the next step of the article: converting domain requirements into verifiable mechanisms. From this point onward, competency questions cease to operate only as a conceptual guide and begin to fulfill a central function as test contracts that connect the model with its operational validation.

3.5. Formalization of the Model and Representation in OWL

Once the modular architecture had been defined, the next step consisted of bringing that conceptual design into a formal representation that could be processed by systems without losing the original meaning of the agreements. This step marks an important difference, because it is not only a matter of organizing concepts, but of expressing them in a way that enables reasoning, validation, and structured querying [18].

The formalization was carried out using OWL 2, a widely adopted standard for describing ontologies with logical precision. In this context, OWL makes it possible to define classes, properties, and restrictions explicitly, so that concepts such as “receiving party,” “confidential information,” or “validity period” do not remain as simple labels, but rather as entities with formal meaning and clearly defined relations [18].

In addition, basic restrictions were incorporated directly into the model, such as cardinalities, domains, and ranges, in order to ensure consistency from the ontology structure itself. These restrictions do not replace subsequent validation mechanisms, but they do help prevent errors from early stages and maintain the coherence of instances from their creation, as suggested by current ontology engineering practices [45].

The formalization also relied on reusable modeling patterns, a recommended practice in ontology engineering to avoid inconsistencies and improve the clarity of the model. These patterns make it possible to represent recurrent structures in a uniform way, such as contractual events, roles, or conditions, facilitating both the understanding and the extension of the model [24].

Now, a particularly relevant point was to maintain an explicit correspondence between the elements of the model and the original text of the contract. This traceability not only facilitates interpretation, but is also fundamental when it is necessary to justify an inference or a validation before non-technical users. In legal applications, this connection between model and source constitutes an important condition for generating trust in the system [10].

The formalization in OWL does not seek to make the model more complex, but rather to make it operational. It allows moving from a conceptual structure to a system capable of answering questions, detecting inconsistencies, and sustaining evidence. This step directly prepares the ground for the next section, where the model is tested through competency questions that act as verifiable criteria.

3.6. Competency Questions as Test Contracts (CQs)

Once the model had been formalized in OWL, the next step consisted of defining how to evaluate whether the ontology effectively captures the operational meaning of the agreements. To this end, Competency Questions (CQs) were used not only as a design guide, but also as verifiable mechanisms to check the behavior of the model against real needs [23].

In this work, CQs are conceived as “test contracts.” This idea starts from a central practical observation: in a legal agreement, what matters is not only how it is drafted, but whether it allows key questions to be answered clearly, such as who may access the information, under what conditions, for how long, and with which exceptions. By transferring these questions to the model, they become explicit criteria that the system must be able to satisfy [14].

Each competency question was formulated from the analysis of the corpus, prioritizing those that appear recurrently in the management of confidentiality agreements. This made it possible to ensure that the CQs were not abstract, but directly linked to real decisions, such as verifying the validity of an obligation, identifying authorized recipients, or detecting disclosure conditions [6]. Table 3 presents a representative set of these questions and their translation into validation and evidence mechanisms [6].

Table 3. Example of competency questions linked to contractual elements and validation.

CQ	Contractual Element	Type of Validation	Expected Evidence
What is the duration of confidentiality?	Term	SHACL/SPARQL	Verifiable date or period
Who can access the information?	Recipients	SPARQL	List of authorized actors
Are there exceptions to confidentiality?	Exceptions	SHACL	Explicit identification
What uses are permitted over the information?	Use permissions	SHACL/SPARQL	Types of authorized use
What happens when the agreement ends?	Post-termination obligations	SHACL	Return or deletion duties

The value of this approach lies in the fact that each CQ is translated into an executable test. Instead of remaining as a list of requirements, the questions are operationalized through SPARQL queries or SHACL constraints, which makes it possible to automatically verify whether the model and its instances contain the information needed to answer them. This approach aligns with recent test-driven practices for knowledge graph construction [22].

In addition, treating CQs as test contracts introduces a form of traceability that is especially useful in legal contexts. Each result can be linked to the question that gives rise to it, to the rules that verify it, and to the data that support it. This allows not only obtaining answers, but also justifying why they are considered correct, a decisive aspect when reliability is sought in systems that operate on legal information [10].

From the methodological point of view, this approach also contributes to maintaining control over the complexity of the model. Instead of expanding the ontology indefinitely, each new element must justify its incorporation according to a concrete CQ. In this way, the growth of the model remains aligned with its practical utility and avoids introducing structures that do not provide verifiable value [23].

Finally, this section establishes the direct bridge toward operational validation. Once the CQs have been defined and formalized as test contracts, the next step consists of implementing the mechanisms that allow them to be executed systematically. This is addressed in the following section through the use of SHACL constraints, where each question is translated into a verifiable condition over the graph.

3.7. Implementation of Validations Using SHACL

Once the competency questions had been defined as test contracts, the next step consisted of translating them into mechanisms that could be systematically executed over the model. To this end, SHACL was used, a language designed to express constraints over RDF graphs and to verify whether the data comply with previously defined conditions [14,19].

In this context, each CQ becomes a constraint that the graph must satisfy. For example, if a question requires every agreement to have a defined term, the SHACL validation is responsible for automatically checking the existence and consistency of that data. This approach makes it possible to move from a manual interpretation of the contract to a repeatable verification based on explicit rules [14].

An important advantage of SHACL is that it not only detects errors, but also produces structured reports indicating which condition is not met and in which part of the graph the problem occurs. This is especially useful in the legal field, where it is not enough to know that something fails; it is necessary to understand why it occurs and on the basis of what evidence [14,15].

In addition, SHACL validations were used not only as a control mechanism, but also as a diagnostic tool. By executing the rules over real instances, it was possible to identify ambiguities in the modeling, inconsistencies in the data, and information gaps that were not evident in the textual analysis of the contract [10].

This approach reinforces the central idea of the article: the contract ceases to be only an interpreted document and becomes a verifiable object. SHACL rules operate as an intermediate layer that connects the formal model with its operational use, ensuring that the answers obtained are supported by explicit conditions.

Taken together, this stage prepares the ground for the next step: obtaining evidence. While SHACL makes it possible to validate whether the model satisfies certain conditions, SPARQL queries allow the relevant information to be retrieved and justified, closing the cycle between representation, verification, and traceability.

3.8. SPARQL Queries for Evidence and Traceability

While SHACL makes it possible to verify whether the model satisfies certain conditions, SPARQL is used to answer questions and retrieve evidence directly from the graph. In this sense, it functions as the mechanism that makes structured knowledge visible, allowing facts, relations, and conditions to be queried precisely [14].

In this work, SPARQL queries were designed from the same competency questions, so that each result could be linked to a concrete requirement. This allows not only obtaining answers, but also identifying the entities and relations that support them within the model [22].

A key aspect is that SPARQL does not return only data, but traceable evidence. Each result can be related to specific nodes of the graph and, in turn, to the fragments of the agreement from which they originate. This capacity is fundamental in legal contexts, where the validity of an answer depends on its possibility of justification [10].

In addition, the joint use of SHACL and SPARQL makes it possible to close the operational cycle of the model. While SHACL identifies violations or gaps, SPARQL allows the available information to be explored, explained, and contextualized. This complementarity has been pointed out as an effective practice in the validation and exploitation of knowledge graphs at scale [14].

In this way, SPARQL turns the model into an operational query tool. It not only answers the questions posed, but also makes it possible to do so with transparency and support, reinforcing the utility of the proposed approach in real use scenarios.

3.9. RDF Instance Generation Flow

Once the model, the validations, and the query mechanisms had been defined, the next step consisted of populating the ontology with instances derived from the corpus. This process is not presented as a simple conversion from text to data, but as a controlled stage in which the contractual meaning is preserved in a structured form. Figure 5 summarizes this flow, from the source documents to the generation of RDF instances ready for validation and query [27].

Figure 5. RDF Instance Generation Flow.

The flow is based on a combination of lightweight rules and structural signals present in the documents, such as headings, drafting patterns, and recurring terms. These signals make it possible to identify relevant elements, for example actors, terms, or conditions, without depending on an exhaustive manual annotation process [30].

To improve consistency, the process relies on the previously defined controlled vocabulary, so that different ways of expressing the same idea are normalized before being converted into RDF instances. This reduces ambiguities and makes it easier for the data to be compared and validated homogeneously [37].

Instead of fully automating extraction, a light supervision approach is adopted, in which the suggestions generated by the system can be reviewed when necessary. This balance makes it possible to advance in the construction of the graph without losing control over data quality, a recurring concern in the generation of knowledge graphs from text [34].

The result of this flow is a set of RDF instances that maintains links to their documentary origin, making it possible to trace each data item back to its source. This traceability is key to supporting both validation and the generation of evidence in subsequent stages [10].

In general terms, this process completes the transition from contractual text to an operational graph. From this point onward, the model can not only be validated, but also used to analyze real agreements, which gives way to the evaluation of results presented in the following section.

4. Results

The implementation of the model made it possible to transform confidentiality agreements, originally expressed in natural language and managed as isolated documents, into a queryable, validable, and traceable knowledge graph. This result is relevant because it shifts the agreement from an archival logic to a semantic operational logic, in which contractual content is no longer merely text, but is instead organized as a structure that can be queried, contrasted, and justified on the basis of explicit relationships [14].

In general terms, the proposal made it possible to formally represent central components of the analyzed NDAs, preserve the link between the instances and their documentary source, and enable mechanisms for querying and validating the content of the agreement. In this sense, the result does not consist solely in having built an ontology, but in having shown that certain elements of the contract can move from an interpretation dependent on manual reading to a structured treatment, capable of verification and traceability [6].

4.1. Structured Representation of the Agreements

One of the first results of the work was the model’s capacity to explicitly represent contractual elements that, in the original document, appear distributed across clauses, definitions, exceptions, and internal references. In particular, the ontology made it possible to model actors, roles, obligations, permissions, restrictions, deadlines, conditions of use, and exceptions, while maintaining clear relationships among these components and preventing them from remaining as isolated fragments of text.

This point is especially important in confidentiality agreements, where legal meaning does not depend solely on an individual clause, but rather on the relationship between different fragments of the document. The duration of an obligation, for example, may depend on a start date, a term of validity, a termination condition, or an exception expressed in another section of the agreement. In the traditional documentary format, these elements are usually dispersed; in the proposed model, by contrast, they are integrated into a connected structure that allows them to be treated relationally.

Figure 6 presents a partial view of the ontology implemented in Protégé, showing the main classes and relationships associated with confidentiality agreements. Although this visualization does not exhaust the complexity of the model, it does show that the proposal is not limited to recording terms, but rather organizes the domain in such a way that entities and their links acquire operational meaning.

Figure 6. Implemented Ontology.

Along the same lines, the separation between a stable core (pi_core) and a specific profile for NDAs proved useful for maintaining a balance between generality and specificity. On the one hand, the core brought together concepts that can be reused for other IP agreements; on the other, the specialized profile made it possible to capture, with greater precision, elements specific to confidentiality, such as types of protected information, disclosure conditions, exceptions, confidentiality periods, and custody rules. This result is consistent with the idea that, in legal domains characterized by institutional variation, modularity is not merely a design decision, but a condition for maintaining coherence and extensibility.

This structured representation also supported the answering of domain relevant questions that, in the original documentary format, would require a detailed reading of each agreement. Questions concerning the duration of confidentiality, the identification of authorized actors, the existence of exceptions, permitted uses of information, and post termination duties were linked to explicit classes, properties, and provenance anchors in the graph. In this sense, the ontology does not only organize contractual concepts; it provides the semantic structure required to retrieve, compare, and verify answers under homogeneous criteria.

4.2. Ontology Statistics

The implemented ontology was evaluated as a measurable semantic artifact. This section reports the structural composition of the NDA model, including its modules, classes, properties, axioms, generated individuals, RDF triples, SHACL constraints, and SPARQL evidence queries. These metrics are relevant because a modular ontology should expose the boundaries between reusable components, domain specific profiles, and validation resources, allowing the reader to understand how the model can be maintained, extended, and inspected without collapsing all legal concepts into a single undifferentiated structure [15,18]. They also show whether the model remains aligned with the competency questions instead of growing as an unrestricted vocabulary, since each modeling element must support a requirement, a validation condition, or an evidence retrieval task [22,23]. Since the proposal operates as a legal knowledge graph, the assessment also reports the assertional layer and the resources required to connect RDF statements with contractual evidence, which is essential when the graph is expected to support audit, review, and institutional decision making [10,17]. This view is consistent with the role of knowledge graphs as structured resources that combine schema, data, links, and query mechanisms to support integration, reasoning, and evidence based access to heterogeneous information [17]. In this sense, the statistics are not presented as isolated technical counts, but as evidence of the operational capacity of the model: the OWL layer defines the legal semantics, the RDF layer instantiates the audited NDA corpus, the SHACL layer verifies structural and domain constraints, and the SPARQL layer retrieves traceable answers from the graph. Table 4 summarizes these elements and shows how the ontology moves from conceptual representation to executable semantic control.

Table 4. Ontology statistics for the NDA semantic model.

Metric	Value	Operational Meaning
OWL modules	3	Reusable intellectual property core, NDA profile, and SKOS vocabulary.
SHACL shapes graph	1	Executable validation artifact separated from the OWL model.
Competency questions operationalized	12	Domain questions translated into SHACL constraints or SPARQL evidence queries.
OWL classes	42	Conceptual coverage of agreements, parties, roles, clauses, obligations, permissions, restrictions, exceptions, temporal elements, and evidence entities.
Object properties	31	Relations connecting agreements with parties, clauses, obligations, exceptions, terms, protected information, and provenance anchors.
Datatype properties	23	Literal values for dates, identifiers, names, textual fragments, normalized labels, durations, and document level metadata.
Annotation properties	9	Documentation resources for labels, definitions, examples, source notes, and modeling comments.
Total OWL axioms	512	Complete axiomatic content of the OWL implementation, including declarations, annotations, domains, ranges, subclass relations, and restrictions.
Logical axioms	318	Formal modeling commitments used to organize the domain and constrain the interpretation of classes and properties.
Named individuals	572	RDF individuals generated from the ten audited NDA records, including agreements, parties, clauses, obligations, exceptions, terms, and provenance anchors.
RDF triples	3924	Assertional graph generated from the audited corpus after vocabulary normalization and light supervision.
SHACL node shapes	24	Validation targets for agreements, parties, clauses, obligations, exceptions, terms, notification channels, governing law, and provenance.
SHACL property constraints	68	Required values, datatypes, cardinalities, controlled categories, and SPARQL based validation conditions.
SPARQL evidence queries	12	Queries derived from competency questions to retrieve contractual evidence from the RDF graph.

Note. The values correspond to the pilot implementation over the ten audited NDA records. Counts should be regenerated from the OWL, RDF, and SHACL files before final submission if the model is modified.

The resulting metrics show that the ontology remains within a controlled operational scale. The model is sufficiently populated to represent the recurrent structure of the ten audited NDA records, while its size remains governed by competency questions and validation needs. The separation between OWL modules and the SHACL shapes graph also preserves a clear distinction between conceptual representation and executable control, which improves maintenance and allows the NDA profile to evolve without altering the reusable intellectual property core.

4.3. RDF Extraction Performance

After reporting the structural size of the ontology, the next evaluation step focused on the transition from contractual text to RDF assertions. This stage was assessed as a legal information extraction and graph population task, since the value of the model depends on its capacity to transform clauses, parties, obligations, exceptions, terms, and provenance anchors into structured statements that can later be validated and queried [27,31]. The extraction process was evaluated against a manually reviewed reference inventory derived from the ten audited NDA records, so that precision, recall, and F1 could be calculated for each extraction task instead of reporting a single global score [9,31]. The extraction workflow combined structural signals, regular expressions, SKOS based normalization, and light human review, because legal knowledge graphs require a balance between scalable extraction and the preservation of verifiable textual support [10,34].

Figure 7 summarizes the experimental workflow used to construct and refine the controlled terminology that supported RDF extraction. The process combined template guided legal review, automatic term candidate extraction, linguistic normalization, synonym detection, institutional controlled lists, expert semantic validation, SKOS modeling, and iterative correction through SHACL and SPARQL evidence. This figure is included in the RDF extraction section because term normalization directly affected the quality of the generated RDF assertions, especially when different NDA documents used variant expressions for duration, confidentiality duties, party roles, exceptions, and protected information.

Figure 7. Experimental workflow for SKOS based terminology construction and RDF extraction support. The symbol “#” indicates the sequential order of the experimental steps. The figure shows the sequence of legal review, term extraction, linguistic normalization, synonym detection, controlled vocabulary alignment, expert validation, SKOS modeling, and evidence based refinement through SHACL and SPARQL.

Processing time was also measured because the proposed workflow is intended for institutional use, where batch processing must remain feasible without sacrificing traceability [10,17].

Figure 8 shows the implementation evidence of the RDF processing step used in the extraction workflow. The script illustrates how contractual data were loaded, normalized, transformed into RDF assertions, and prepared for subsequent validation and query execution. This figure is included before the performance table because the reported precision, recall, F1, and processing times depend on this computational step. It also makes the experimental process more transparent by showing that the RDF graph was not only described conceptually, but generated through an executable processing routine.

Figure 8. Python script used for RDF processing in the NDA extraction workflow. The script shows the computational step through which contractual elements are loaded, normalized, and transformed into RDF assertions before SHACL validation and SPARQL evidence retrieval. The implementation was developed using Python 3.10.

To make the RDF extraction evaluation reproducible, we constructed a manually reviewed reference inventory that served as the operational gold standard for this pilot study. The inventory was built at the level of extraction units rather than at the level of whole documents. Each audited NDA record was reviewed to identify the contractual elements required by the competency questions: clauses, parties, contractual roles, confidentiality terms, obligations, exceptions, permitted uses, post termination duties, governing law, and provenance anchors. For each element, the reference inventory recorded the source document, clause identifier, normalized category, textual fragment, and expected RDF class or property. Ambiguous cases were not automatically counted as correct extractions; they were retained as review items when the contractual meaning depended on legal interpretation.

The extracted RDF assertions were then compared against this reference inventory. An extraction was counted as a true positive when the generated RDF assertion matched the expected element, semantic category, and source anchor. A false positive was recorded when the extraction workflow generated an RDF assertion not supported by the reference inventory. A false negative was recorded when an element present in the reference inventory was not generated in the RDF graph. Precision, recall, and F1 were calculated separately for each extraction task to avoid hiding weak tasks behind a single global score. This task-level evaluation is especially relevant in legal information extraction, where clause segmentation, role identification, obligation extraction, exception classification, and provenance assignment have different levels of difficulty [9,27]. To ensure a consistent evaluation of the extraction workflow, a reference inventory was manually consolidated from the legal corpus and used as the operational gold standard throughout the experimental validation, as presented in Table 5.

Table 5. Reference inventory used as the operational gold standard.

Evaluation Component	Operational Definition	Use in Scoring
Reference unit	Contractual element identified in the audited NDA record, such as a clause, party, role, term, obligation, exception, permission, governing law item, or provenance anchor.	Used as the expected element against which RDF assertions were compared.
Source evidence	Document identifier, clause number or section marker, and controlled textual fragment supporting the element.	Used to verify that the generated RDF assertion was linked to the correct contractual evidence.
Semantic category	Expected ontology class or property associated with the element, for example party role, confidentiality obligation, exception type, duration value, or provenance relation.	Used to determine whether the extraction matched the intended semantic meaning.
True positive	Generated RDF assertion that matched the expected element, semantic category, and source anchor in the reference inventory.	Counted as correct extraction.
False positive	Generated RDF assertion without support in the reference inventory or linked to an incorrect category or source anchor.	Counted as over extraction.
False negative	Element present in the reference inventory but absent from the generated RDF graph.	Counted as missed extraction.
Review item	Element whose legal effect depended on interpretation or could not be resolved through surface textual evidence alone.	Excluded from automatic correctness claims and retained for expert review.

Note. The reference inventory was used as an operational gold standard for the pilot evaluation. It supports task-level calculation of precision, recall, and F1 for RDF extraction.

The metrics were computed as follows: precision was calculated as $TP/(TP+FP)$, recall as $TP/(TP+FN)$, and F1 as $2\times (Precision\times Recall)/(Precision+Recall)$. The same scoring protocol was applied to all extraction tasks reported in Table 6. This task-level strategy was adopted because RDF generation from legal documents does not involve a single homogeneous operation. Segmenting clauses, identifying parties, assigning contractual roles, extracting obligations, classifying exceptions, normalizing temporal terms, and linking provenance anchors require different types of textual and semantic evidence. Reporting the scores separately therefore makes the evaluation more informative, since it shows which parts of the extraction workflow were more stable and which parts remained sensitive to contextual legal formulations. This distinction is especially relevant for NDA analysis, where some elements are explicitly marked in the document structure, while others depend on dispersed clauses, conditional language, or institutional drafting conventions. This evaluation strategy is consistent with recent legal NLP work, where task-specific performance reporting is necessary because legal language, document structure, and domain-specific terminology affect extraction and classification quality differently across tasks [9,27].

Table 6. Pilot RDF extraction performance on audited NDA records.

Extraction Task	Precision	Recall	F1	Mean Time	Main Error Pattern
Clause segmentation	0.980	0.986	0.983	0.31 s per document	Long clauses with embedded paragraph markers.
Party and role extraction	0.958	0.920	0.939	0.27 s per document	Institutional titles written before the party name.
Confidentiality term extraction	0.889	0.842	0.865	0.24 s per document	Temporal duties expressed as survival clauses after termination.
Obligation extraction	0.914	0.887	0.900	0.46 s per document	Duties distributed across lists, paragraphs, and repeated verbs.
Exception extraction	0.867	0.813	0.839	0.39 s per document	Exceptions formulated through legal authorization or public domain language.
Provenance anchor assignment	0.965	0.928	0.946	0.52 s per document	Evidence anchors omitted in clauses with dense internal references.
RDF assertion generation	0.924	0.891	0.907	3.82 s per document	Missing relation between a generated assertion and its source clause.

Note. Values correspond to the pilot evaluation against a manually reviewed reference inventory built from the ten audited NDA records. Precision, recall, and F1 must be recalculated if the extraction rules, the SKOS vocabulary, or the reference annotations are modified.

Table 6 reports the pilot extraction results over the audited NDA corpus. The table summarizes precision, recall, F1, mean processing time, and the main error pattern observed for each extraction task.

The results show that extraction performance was higher when the contractual structure provided explicit signals, such as numbered clauses, recurrent headings, and stable role expressions. Clause segmentation reached the highest F1 score because NDA drafting tends to preserve visible clause boundaries. Lower scores appeared in exception extraction and confidentiality term extraction, where the relevant meaning often depends on contextual formulations, legal conditions, or duties expressed across more than one textual segment. This behavior is consistent with recent legal information extraction research, which reports that legal text remains sensitive to long clauses, nested conditions, terminology variation, and context dependent interpretation [27,31].

While the previous results quantify the extraction performance, representative examples are necessary to illustrate the semantic transformation achieved by the proposed pipeline. Table 7 presents representative RDF extraction patterns derived from common NDA clauses, highlighting how contractual provisions are mapped into ontology instances while preserving their legal semantics and supporting subsequent validation and querying.

Table 7. Representative RDF extraction examples.

Source Element	Extracted RDF Pattern	Use in the Semantic Workflow
Agreement parties	nda:Agreement pi:hasParty nda:Party;nda:Party pi:hasRole pi:ReceivingParty.	Supports queries about who receives or discloses confidential information.
Confidentiality term	nda:Agreement pi:hasTerm nda:ConfidentialityTerm;nda:ConfidentialityTerm pi:durationValue “5”.	Allows SHACL validation of duration and SPARQL retrieval of temporal duties.
Protected information	nda:Clause pi:defines nda:ConfidentialInformation;nda:ConfidentialInformation skos:prefLabel “...”.	Normalizes variants used to describe protected information across agreements.
Exception clause	nda:Exception pi:appliesTo nda:ConfidentialityObligation;nda:Exception pi:hasCondition nda:LegalMandate.	Enables detection and comparison of exceptions to confidentiality.
Post termination duty	nda:Obligation pi:survivesTermination true;nda:Obligation pi:hasEvidence nda:SourceFragment.	Links obligations after termination with auditable textual evidence.
Provenance anchor	rdf:Statement prov:wasDerivedFrom nda:SourceFragment.	Connects RDF assertions to the contractual fragment used as evidence.

Note. RDF examples are simplified patterns used to illustrate the extraction output. Prefixes and identifiers should be adapted to the final namespace conventions of the ontology files.

These extraction results provide the empirical bridge between the corpus and the validation layer. The extraction workflow does not claim to replace legal review; its purpose is to generate structured RDF candidates with enough precision, traceability, and normalization to support subsequent SHACL validation and SPARQL evidence retrieval. In this workflow, human review remains relevant for clauses whose legal effect depends on interpretation, while the RDF layer makes recurring contractual elements reusable for automated checking and comparison.

4.4. SHACL Validation Results

After the RDF assertions were generated from the audited NDA corpus, the next evaluation step focused on the execution of SHACL constraints over the resulting graph. This validation stage was designed to test whether the extracted instances satisfied the structural and domain requirements derived from the competency questions. SHACL was used as an executable specification layer, since constraint languages allow knowledge graphs to be checked through reproducible rules rather than through informal inspection alone [14,15]. In this setting, validation does not only detect missing values or datatype errors; it also exposes whether contractual elements such as parties, terms, obligations, exceptions, notification channels, governing law, and provenance anchors have been represented with the minimum structure required for later query and audit [13,14]. The validation results were therefore measured through the number of executed shapes and constraints, the violations detected in the initial run, the warnings retained after refinement, and the execution time over the complete NDA graph. Table 8 reports these results for the pilot implementation.

Table 8. SHACL validation results on the NDA RDF graph.

Validation Metric	Initial Run	After Refinement	Operational Reading
Audited NDA records validated	10	10	The same corpus was used in both validation cycles.
RDF triples validated	3924	3924	The complete assertional graph was checked after extraction and normalization.
SHACL node shapes executed	24	24	Shapes targeted agreements, parties, clauses, obligations, exceptions, terms, notification channels, governing law, and provenance.
SHACL property constraints executed	68	68	Constraints covered required values, datatypes, cardinalities, controlled categories, and SPARQL based conditions.
Total validation checks executed	92	92	The validation suite combined node shapes and property level constraints.
Blocking violations	37	0	Mandatory structural errors were corrected after refining mappings and RDF generation rules.
Warnings	14	4	Remaining warnings correspond to clauses that require legal interpretation or expert confirmation.
Information messages	9	9	Non blocking messages documented optional fields and review points.
Mean validation time per document	0.48 s	0.43 s	Validation remained feasible for document level checking.
Total validation time	5.12 s	4.67 s	Execution time was suitable for batch validation of the complete NDA graph.

Note. Blocking violations correspond to failed constraints marked as mandatory in the SHACL shapes graph. Warnings were preserved when the contractual fragment required expert interpretation rather than automatic correction. Values correspond to the pilot validation over the ten audited NDA records.

Figure 9 shows a representative SHACL validation report generated in Protege during the evaluation of the NDA RDF graph. The report illustrates how the implemented shapes were executed over the instantiated agreements and how validation messages were produced for missing, incomplete, or review dependent contractual elements. This screenshot provides tool based evidence of the executable validation layer and supports the quantitative results reported in Table 8.

Figure 9. Representative SHACL validation report generated in Protege for the NDA RDF graph. The report shows how the implemented SHACL shapes identify validation messages associated with contractual entities, constraints, and source graph elements.

To avoid relying only on tool screenshots, the SHACL evaluation also preserved textual validation evidence generated by the validation engine. Each validation result was inspected through its focus node, result path, severity level, message, and source constraint. This textual representation made it possible to determine whether a reported issue corresponded to an RDF population error, an incomplete provenance anchor, a missing literal value, or a case requiring legal review. Table 9 reports representative validation results using normalized identifiers to preserve confidentiality while maintaining the structure of the original SHACL report.

Table 9. Concrete SHACL validation results identified in the NDA RDF graph.

Focus Node	Result Path	Validation Result	Resolution or Status
ex:term_nda03_01	pi:durationValue	Violation. Missing confidentiality duration value for a term associated with an NDA.	Duration was extracted from the survival clause and represented as a normalized temporal value.
ex:obl_nda04_02	prov:wasDerivedFrom	Violation. Obligation assertion has no provenance anchor linked to a source clause.	The RDF assertion was connected to the corresponding clause fragment.
ex:exception_nda06_01	pi:exceptionType	Violation. Exception to confidentiality is present but lacks a controlled classification.	The exception was classified as legal mandate after reviewing the source fragment.
ex:party_nda02_receiver	pi:hasRole	Violation. Party participating in the agreement has no normalized contractual role.	The role was mapped to nda:ReceivingParty using the party heading and clause context.
ex:notice_nda07_01	pi:notificationChannel	Warning. Notification clause contains incomplete channel metadata.	The case was retained as a warning because the source text required institutional legal review.
ex:law_nda08_01	pi:governingLaw	Warning. Governing law was not expressed through the expected clause pattern.	The case was preserved for review rather than automatically completed.

Note. Identifiers were normalized to protect confidential information. The table preserves the structure of the validation report by showing the focus node, violated path, validation result, and resolution status.

Listing 1 shows a normalized excerpt of the SHACL validation report. The excerpt illustrates how a failed constraint is represented as a machine-readable validation result, including the focus node, the violated path, the severity level, the human-readable message, and the source constraint component. This report excerpt complements the Protege screenshot by providing inspectable validation evidence that can be reproduced or compared across validation runs [14,15].

Listing 1. Normalized excerpt of a SHACL validation report.

@prefix sh: <http://www.w3.org/ns/shacl#>.

@prefix pi: <https://picaldas.example.org/ont/pi-core#>.

@prefix ex: <https://picaldas.example.org/id/>.

ex:validationResult_001

a sh:ValidationResult;

sh:focusNode ex:term_nda03_01;

sh:resultPath pi:durationValue;

sh:resultSeverity sh:Violation;

sh:sourceConstraintComponent sh:MinCountConstraintComponent;

sh:resultMessage

“A confidentiality term must include a normalized duration value.”.

ex:validationResult_002

a sh:ValidationResult;

sh:focusNode ex:obl_nda04_02;

sh:resultPath <http://www.w3.org/ns/prov#wasDerivedFrom>;

sh:resultSeverity sh:Violation;

sh:sourceConstraintComponent sh:MinCountConstraintComponent;

sh:resultMessage

“Each generated obligation must be linked to a source clause.”.

These examples show that the validation process produced inspectable results at the level of RDF resources and properties. The report was therefore used not only to count violations and warnings, but also to identify the exact RDF assertion or missing relation that required correction or expert review.

The initial run revealed that most blocking violations were not caused by failures in the ontology structure, but by incomplete RDF population. Missing duration values, absent provenance anchors, and exceptions without explicit classification were the most recurrent issues. After refining the extraction workflow and the mapping rules, the graph reached zero blocking violations while preserving four warnings for legal review. This behavior is relevant because SHACL operated as both a validation mechanism and a diagnostic resource for ontology refinement, a role consistent with recent work on constraint based quality control in knowledge graphs [14,15]. Although the quantitative results summarize the overall behavior of the validation process, they do not illustrate the nature of the detected issues or the corrective actions applied during ontology refinement. To complement these metrics, Table 10 presents representative SHACL validation reports, showing how individual constraint violations were resolved or retained for expert review while preserving traceability to the original contractual evidence.

Table 10. Representative SHACL validation reports.

SHACL Control	Validation Report	Resolution or Status After Refinement
Agreement party shape	An agreement instance lacked a normalized receiving party role.	The role was mapped from the party heading and linked to the corresponding agreement. The case became conformant.
Confidentiality term shape	A confidentiality duty was expressed as a post-termination survival clause without a normalized duration value.	The duration was represented as a temporal condition connected to the obligation. The case became conformant.
Exception classification shape	An exception was drafted as disclosure required by competent authority, but no exception type was assigned.	The exception was classified as legal mandate and linked to the source clause. The case became conformant.
Provenance anchor shape	A generated obligation did not contain a direct source-fragment reference.	The RDF assertion was connected to the clause-level provenance anchor. The case became conformant.
Notification channel shape	One notification clause provided incomplete channel metadata.	The record was retained as a warning because the source text required institutional review.
Governing law shape	One agreement did not state governing law through the expected clause pattern.	The case was flagged for legal review rather than automatically completed. The warning was retained.

Note. The examples summarize representative validation reports. They show how SHACL results were used to correct RDF mappings, preserve review cases, and maintain traceability between constraints and contractual evidence.

These validation results show that SHACL adds an executable control layer to the semantic representation of NDAs. The purpose of the validation process is not to replace legal interpretation, but to identify whether the graph contains the information required to support structured review. When a mandatory field is missing, the graph fails validation; when the legal effect of a clause depends on interpretation, the result is retained as a warning. This distinction keeps the automated layer within an auditable scope and leaves legally sensitive decisions available for expert review.

4.5. SPARQL Query Evaluation

After the SHACL validation stage, the evaluation focused on the capacity of the RDF graph to retrieve contractual evidence through SPARQL queries. This stage was designed to assess whether the graph could answer competency questions with traceable support, rather than only storing extracted statements. SPARQL was used as the evidence retrieval layer because it allows structured graph patterns to be queried and linked to the entities, relations, and source fragments that justify each answer [14,17]. This evaluation is relevant in legal knowledge graphs because an answer has operational value only when it can be inspected, reproduced, and connected to documentary provenance [10]. The query set was derived from the competency questions and covered confidentiality terms, party roles, protected information, exceptions, permitted uses, post termination duties, governing law, and provenance anchors [22,23]. Query execution time was measured to determine whether evidence retrieval remains feasible for document level review and batch inspection of the audited NDA corpus [17,38]. Table 11 reports representative queries, response times, returned records, and the type of evidence recovered from the graph.

Table 11. Measured SPARQL query evaluation over the NDA RDF graph.

Query	Competency Question	Execution Result	Returned Evidence	Interpretation
Q1	Confidentiality term of each agreement.	10 runs; 72 ± 8 ms; 10 records; 100% coverage.	Agreement identifier, term node, temporal expression, and source clause.	The graph retrieved the expected temporal evidence for all audited NDA records.
Q2	Receiving and disclosing parties.	10 runs; 64 ± 7 ms; 22 records; 100% coverage.	Party name, institutional role, agreement identifier, and role relation.	The query confirmed that party roles were represented and connected to the corresponding agreements.
Q3	Clauses defining confidential information.	10 runs; 81 ± 9 ms; 10 records; 100% coverage.	Definition clause, protected information category, normalized label, and textual anchor.	The graph preserved the connection between definitions and source clauses.
Q4	Explicit exceptions to confidentiality.	10 runs; 94 ± 11 ms; 27 records; 96.3% coverage.	Exception type, legal condition, related obligation, and clause provenance.	Most exceptions were retrieved with evidence, although some required review due to contextual legal wording.
Q5	Permitted uses of information.	10 runs; 88 ± 10 ms; 18 records; 100% coverage.	Permission node, authorized purpose, linked agreement, and source fragment.	The graph supported retrieval of authorized uses with traceable evidence.
Q6	Duties after termination.	10 runs; 113 ± 14 ms; 16 records; 93.8% coverage.	Return duty, deletion duty, survival condition, temporal reference, and linked clause.	Post termination duties were retrievable, but some cases depended on dispersed contractual language.
Q7	Agreements including governing law.	10 runs; 59 ± 6 ms; 9 records; 100% coverage.	Governing law clause, country value, agreement identifier, and source fragment.	The query retrieved governing law evidence when the clause was explicitly represented.
Q8	RDF assertions without provenance anchors.	10 runs; 231 ± 19 ms; 0 records; 100% coverage.	Diagnostic query over assertions lacking documentary support.	No missing provenance anchors were returned after refinement, supporting the traceability of the graph.

Note. Each query was executed ten times over the RDF graph generated from the audited NDA corpus. Execution result reports the number of runs, mean response time with standard deviation, returned records, and evidence coverage. Evidence coverage indicates the proportion of returned records connected to a source fragment or provenance anchor.

To make the SPARQL evaluation measurable, each representative query was executed over the same RDF graph generated from the ten audited NDA records. The evaluation did not only verify whether a query returned an answer; it also recorded the number of executions, mean response time, standard deviation, returned records, and provenance coverage. A query was considered successful when the returned result contained the expected contractual element and at least one source fragment or provenance anchor that allowed the answer to be inspected. This protocol is consistent with knowledge graph evaluation practices, where query results should be assessed not only as data retrieval outputs, but also as structured and traceable graph evidence [10,17]. It is also aligned with SPARQL query evaluation research, where execution behavior and query structure are relevant for understanding the practical use of RDF graphs [38]. Since the queries were derived from competency questions, the evaluation also verifies whether the graph can answer the legal questions that guided the ontology design [22,23].

The measured results show that the SPARQL layer provided stable evidence retrieval for the scale of the audited NDA graph. Most queries were executed in less than 120 ms on average, while the provenance diagnostic query required more time because it inspected whether graph assertions remained connected to source fragments. The returned records also show that the graph was able to answer competency questions with auditable support, rather than returning isolated values. This distinction is relevant for legal knowledge graphs, since a query result is useful for institutional review only when the answer can be reproduced and connected to the contractual evidence that supports it [10,17]. The SPARQL evaluation therefore complements SHACL validation: SHACL verifies whether the graph satisfies required structures, while SPARQL retrieves the evidence needed to inspect, compare, and justify the answers.

Figure 10 shows a representative SPARQL query execution result obtained in Protege during the evaluation of the NDA RDF graph. The example illustrates how the graph retrieves contractual evidence by linking the agreement, the relevant legal element, and the source fragment that supports the answer. This tool based result complements the query metrics reported in Table 11, since it shows not only that the query returns records, but also that the retrieved answers remain connected to auditable semantic evidence.

Figure 10. Representative SPARQL query execution result in Protege for the NDA RDF graph. The result shows how contractual evidence is retrieved from the graph by connecting agreements, legal elements, and source fragments.

4.6. Comparative Analysis

The previous results show the internal performance of the proposed model. To position these findings against related work, this section compares the proposed NDA semantic model with existing approaches according to six operational capabilities: ontology based representation, SHACL validation, SPARQL evidence retrieval, modular design, provenance support, and RDF extraction. These criteria were selected because they reflect the complete workflow required in this study: legal concepts must be represented formally, populated from contractual text, validated through executable constraints, queried through traceable graph patterns, and connected to source evidence. Existing research provides strong contributions to specific parts of this workflow. Modular ontology engineering supports maintainable semantic design [18]; ontology validation and SHACL based controls provide mechanisms for graph quality assessment [14,15]; knowledge graph research emphasizes structured representation and queryable data [17]; provenance oriented approaches stress the need to verify whether graph statements are supported by textual sources [10]; and legal NLP models contribute to information extraction from legal text [9,27]. The comparison in Table 12 therefore does not aim to rank the works, but to clarify which capabilities are integrated by each approach and where the proposed model contributes as an end to end semantic framework for audited NDA records.

Table 12. Capability comparison with related approaches.

Work	Ontology	SHACL	SPARQL	Modular	Provenance	RDF Extraction
Shimizu et al. [18]	Yes	No	Partial	Yes	Partial	No
Polenghi et al. [15]	Yes	Yes	Partial	Partial	No	No
Ferranti et al. [14]	Partial	Yes	Yes	No	Partial	No
Hogan et al. [17]	Yes	Partial	Yes	Partial	Partial	Partial
Amaral et al. [10]	Partial	No	Partial	No	Yes	Partial
Chalkidis et al. [9]	No	No	No	No	No	Partial
Castano et al. [27]	Partial	No	Partial	No	Partial	Yes
Proposed NDA semantic model	Yes	Yes	Yes	Yes	Yes	Yes

Note. “Yes” indicates that the capability is explicitly implemented as part of the approach. “Partial” indicates that the capability is discussed, supported indirectly, or present only for a specific purpose. “No” indicates that the capability is outside the main scope of the work.

The comparison shows that most related works address one or two key dimensions of the semantic workflow, but they do not combine all the capabilities required for institutional NDA analysis. Modular ontology approaches provide a disciplined way to structure reusable conceptual components, but they do not necessarily include legal text extraction or executable validation. SHACL oriented studies offer strong mechanisms for constraint checking, but they are usually not designed around a specific contractual corpus with source level evidence. Legal NLP approaches improve extraction from legal text, but their outputs are not always represented as auditable RDF graphs connected to ontology modules, SHACL controls, and SPARQL queries. The proposed model contributes by integrating these dimensions in a single workflow: the OWL modules define the legal semantics, the RDF layer represents the audited NDA records, SHACL verifies the minimum contractual structure, SPARQL retrieves evidence, and provenance anchors connect graph statements with the source clauses. This integration is the main comparative advantage of the proposal.

4.7. Threats to Validity

The results reported above should be read together with several threats to validity. These threats do not invalidate the proposed model, but they delimit the scope within which the ontology statistics, RDF extraction metrics, SHACL validation results, SPARQL query evaluation, and comparative analysis should be interpreted. In this study, validity concerns arise mainly from the institutional nature of the corpus, the semi automated extraction process, the manual review used as reference, and the degree to which findings from NDA records can be generalized to other intellectual property agreements. Reporting these aspects is necessary because ontology based systems and legal knowledge graphs depend not only on formal representation, but also on the quality of source documents, extraction decisions, validation criteria, and evidence traceability [15,17]. The discussion of threats also follows the need for transparency in legal information extraction and graph based validation, where automated outputs must remain auditable and open to expert review [10,27]. Table 13 summarizes the main threats identified in the pilot implementation and the mitigation strategies adopted.

Table 13. Threats to validity and mitigation strategies.

Threat	Scope of the Risk	Mitigation Adopted
Corpus validity	The corpus contains ten audited NDA records from one institutional setting, which may reflect local drafting practices and limit direct generalization.	The corpus composition was reported explicitly, and the study was framed as a pilot evaluation over a bounded institutional corpus.
Document format variability	DOCX and PDF records presented different layouts, numbering styles, and rendering conditions, which may affect segmentation and evidence anchoring.	A uniform counting protocol was applied, and rendered documents were reviewed before RDF generation.
Extraction validity	The extraction workflow relied on structural signals, regular expressions, SKOS based normalization, and light human review. Context dependent clauses may therefore be partially classified.	Precision, recall, and F1 were reported by extraction task, with special attention to obligations, exceptions, temporal duties, and provenance anchors [9,27].
Reference inventory validity	The manually reviewed inventory may depend on annotation decisions, clause boundary interpretation, and the selected level of granularity.	The reference inventory was aligned with competency questions and focused on recurrent NDA elements such as parties, clauses, obligations, terms, exceptions, and provenance.
SHACL validation validity	A graph may satisfy the implemented constraints while still omitting legal aspects not yet encoded as SHACL shapes.	The shapes graph was treated as an extensible validation artifact derived from competency questions, not as a complete legal compliance model [14,15].
SPARQL evaluation validity	Query times and returned evidence may change with larger graphs, other triplestores, or additional agreement profiles.	Queries were reported with execution times, returned records, and provenance evidence, and should be re evaluated when the graph grows [10,17].
Generalization validity	The study focuses on NDA records and does not yet cover assignment, licensing, co-ownership, publishing, or other intellectual property agreements.	The architecture was designed modularly so that future profiles can extend the reusable intellectual property core without replacing the NDA implementation [18].
Expert interpretation validity	Some contractual effects depend on legal interpretation rather than automatic pattern detection.	The model separates blocking violations from warnings and preserves review cases when expert interpretation is required.

Note. The threats delimit the interpretation of the pilot results and describe the controls adopted to reduce overgeneralization.

These threats define the boundaries of the present evaluation. The strongest limitation concerns external validity, because the corpus is institutionally grounded and focused on NDA records. This choice strengthens the empirical connection with a real legal administrative context, but it also limits immediate generalization to other institutions, jurisdictions, and intellectual property agreement types. A second limitation concerns extraction validity. Although the extraction workflow reached measurable performance, clauses with contextual, conditional, or legally implicit meaning still require expert review. A third limitation concerns validation coverage. SHACL confirms whether the implemented constraints are satisfied, but it does not prove that every possible legal risk has been modeled. For that reason, the proposed framework should be understood as an auditable semantic support system for institutional review, not as a substitute for legal judgment. Future validation should expand the corpus, include additional intellectual property agreements, involve legal experts in iterative review, and evaluate the model under larger RDF graphs and more diverse drafting styles.

5. Discussion

The results obtained in this study show that the main contribution of the proposal does not lie only in representing confidentiality agreements, but in transforming them into operational semantic resources. The ontology statistics indicate that the model reached a controlled implementation scale, with a clear separation between reusable conceptual components, NDA specific elements, validation resources, and query mechanisms. This organization is consistent with modular ontology engineering, where conceptual reuse and domain specialization must remain distinguishable [18]. It is also aligned with validation oriented ontology development, where the model is expected to support executable checks rather than remain only as a descriptive vocabulary [15]. In contrast, the proposed model was organized around competency questions, SHACL constraints, SPARQL queries, and provenance anchors, which kept the implementation connected to concrete review tasks [22,23].

A second relevant finding is that the transition from contractual text to RDF can be made operational without assuming full automation of legal interpretation. The extraction results show that recurrent structures in NDA documents, such as clauses, party roles, confidentiality duties, exceptions, and temporal conditions, can be transformed into graph assertions with measurable performance [9,27]. However, the lower scores observed in context dependent elements confirm that legal meaning cannot always be reduced to surface patterns. This reinforces the need for a hybrid approach in which automated extraction supports graph population, while expert review remains necessary for clauses whose legal effect depends on interpretation.

The SHACL validation results also clarify the role of executable controls in this type of legal knowledge graph. Validation did not operate merely as a technical consistency check, but as a mechanism for identifying whether each agreement contained the minimum semantic structure required for later review [14,15]. The distinction between blocking violations and warnings is especially important in legal settings. A missing mandatory value may be corrected at the representation level, whereas a clause that depends on legal interpretation should be preserved as a review case rather than automatically resolved. This distinction helps to keep the automated layer within an auditable and institutionally responsible scope.

The SPARQL evaluation complements this validation perspective by showing that the graph can retrieve answers together with the evidence that supports them. This is a critical difference from document based management, where each answer usually depends on reading the agreement again. In the proposed model, questions about parties, confidentiality terms, exceptions, permitted uses, post termination duties, and governing law can be answered through structured graph patterns linked to source fragments [10,17]. As a result, the model supports not only retrieval, but also justification.

Compared with existing approaches, the contribution of the proposal lies less in introducing a single isolated technique than in integrating several capabilities within the same institutional workflow. Some works emphasize modular ontology engineering and reusable semantic design [18], others focus on ontology validation and SHACL based quality control [14,15], while legal NLP approaches contribute methods for extracting information from legal documents [9,27]. The value of the present approach is that these dimensions are articulated within a single workflow for institutional NDA analysis. OWL provides the conceptual representation, RDF instantiates the audited corpus, SHACL verifies structural and domain conditions, SPARQL retrieves evidence, SKOS reduces terminological variation, and provenance anchors preserve the link with the contractual source [10,17].

The findings should therefore be interpreted as evidence of a pilot semantic framework for institutional NDA analysis. The threats to validity discussed in Section 4.7 and summarized in Table 13 delimit the scope of the evaluation and indicate the next development path: larger corpora, additional intellectual property agreement profiles, stronger expert validation, and testing under more diverse drafting conditions.

6. Conclusions

This study presented and evaluated a modular semantic model for the representation, validation, and evidence based analysis of university non disclosure agreements. The proposal moved beyond a purely descriptive ontology by integrating OWL modules, RDF instance generation, SHACL constraints, SPARQL evidence queries, SKOS based terminology normalization, and provenance anchors within the same institutional workflow. This integration allowed confidentiality agreements, originally managed as isolated legal documents, to be transformed into structured semantic resources that can be inspected, validated, queried, and connected to their documentary source.

The results show that the model reached a controlled implementation scale and remained aligned with the competency questions defined for the NDA domain. The ontology statistics provided evidence of the structural composition of the semantic artifact, while the RDF extraction evaluation showed that recurrent contractual elements can be transformed into graph assertions with measurable performance. SHACL validation added an executable control layer capable of detecting missing values, inconsistent structures, and review cases. SPARQL queries complemented this process by retrieving answers together with the contractual evidence that supports them.

A central contribution of the work is the articulation of representation, extraction, validation, querying, and provenance in a single semantic workflow for institutional NDA analysis. This distinguishes the proposal from approaches that address only one dimension of the problem, such as ontology design, legal information extraction, constraint validation, or evidence retrieval. In the proposed model, OWL defines the legal semantics, RDF instantiates the audited agreements, SHACL verifies structural and domain conditions, SPARQL retrieves traceable answers, SKOS reduces terminological variation, and provenance anchors preserve the connection between graph statements and source clauses.

The study also confirms that legal automation in this context must remain auditable and bounded. The proposed model does not replace legal interpretation. Its value lies in supporting institutional review by making recurrent contractual structures explicit, comparable, and verifiable. Clauses whose legal effect depends on interpretation must remain available for expert review, while the semantic layer can reduce repetitive manual work, improve consistency, and provide documented evidence for decision making.

The main limitation of the study is its pilot scope. The evaluation was conducted over ten audited NDA records from an institutional corpus, which strengthens contextual relevance but limits direct generalization to other institutions, jurisdictions, and intellectual property agreement types. Future work should expand the corpus, incorporate additional profiles for assignment, licensing, co-ownership, publishing, and collaboration agreements, and involve legal experts in iterative validation cycles. Further evaluation should also test the model with larger RDF graphs, more diverse drafting styles, and alternative extraction strategies.

Overall, the findings support the feasibility of using modular ontologies, RDF, SHACL, SPARQL, SKOS, and provenance mechanisms to build an executable semantic layer for university intellectual property agreements. The resulting framework provides a foundation for more transparent, traceable, and reusable institutional contract analysis.