AI-Driven Semantic Processing of Notices to Air Missions for Aeronautical Information Management: Ontology-Grounded Type-Aware Extraction

Abstract

Timely and accurate interpretation of Notices to Air Missions (NOTAMs) is essential for effective aeronautical information management (AIM). Although NOTAMs follow a standardized format, their abbreviated textual content and heterogeneous operational semantics make automated processing difficult. Existing methods often address type classification, information extraction, and semantic representation independently, leaving a gap between textual interpretation and ontology-grounded information management. To address this gap, this paper presents NOTE, an AI-driven ontology-grounded type-aware extraction framework for NOTAMs. NOTE is supported by a dynamic semantic ontology that combines a shared semantic module with seven type-specific sub-ontologies. Guided by the predicted semantic type, the framework activates the corresponding ontology-aligned schema contract, extracts and validates the relevant information, and materializes the result as Resource Description Framework (RDF) triples. Experiments on 25,341 operational NOTAMs and a manually curated ontology-mapping set produced a macro-$F_1$ of 0.9424 for type-aware routing and an $F_1$ of 0.9053 for structured extraction, with a schema conformance rate of 0.9976. The dynamic ontology achieved slot- and relation-level $F_1$ scores of 0.9472 and 0.9835, respectively. Compared with a scale-matched static ontology, type-specific activation improved relation mapping by 13.06 percentage points while producing semantic richness close to the human-annotated reference. These findings indicate that NOTE provides an effective connection between abbreviated NOTAM text and validated ontology-grounded representations for AIM.

1. Introduction

Safe and efficient air traffic management (ATM) depends on the timely and accurate interpretation of aeronautical information. Notices to Air Missions (NOTAMs) communicate time-sensitive changes in aeronautical facilities, airspace, procedures, and operating conditions [1,2]. Transforming these messages into machine-interpretable representations is important for aeronautical information management (AIM), particularly for information integration, semantic retrieval, consistency checking, and operational decision support.

In current NOTAM processing, standardized fields support message distribution, storage, filtering, and presentation. However, the operational content of Item E still requires substantial human interpretation. Its abbreviated and context-dependent expressions can make relevant information difficult to identify, particularly when users must review large numbers of notices within limited time [3,4]. Operational personnel must determine the affected object, its changed state, and the principal constraints before assessing the significance of a notice. Existing automated approaches assist with classification, extraction, filtering, or visualization, but do not always produce validated and machine-interpretable semantic records.

This limitation arises because a standardized message format does not imply fully structured operational semantics. Aviation texts contain specialized terminology, coded expressions, and compact descriptions that complicate automatic interpretation [5,6]. Effective NOTAM processing must recover not only individual information elements but also the objects, events, states, parameters, constraints, and relations expressed in the message.

The task is further complicated by semantic heterogeneity. Different NOTAM categories involve different operational objects, event structures, parameters, and constraints. Applying a single semantic structure to all notices can introduce irrelevant fields, obscure category-specific information, and increase ambiguity during semantic mapping. A suitable representation must therefore preserve concepts shared across NOTAMs while adapting its active scope to the semantic characteristics of each notice.

Recent advances in large language models (LLMs) offer greater flexibility for interpreting specialized text [7]. Nevertheless, linguistically plausible output is insufficient for a safety-relevant transportation application. Extracted fields and relations must be supported by the source message, conform to an explicit structure, and remain consistent with the domain model used by downstream systems [8]. Existing approaches generally address classification, information extraction, and semantic representation as separate tasks, leaving a gap between flexible textual interpretation and type-specific formal representation.

The resulting research problem is to maintain a consistent semantic scope from NOTAM interpretation to ontology instantiation. Without such coordination, extraction may generate fields unrelated to the relevant operational category, while ontology mapping may apply inappropriate concepts or relations. An explicit association among NOTAM type, extraction structure, and ontology representation is therefore needed to transform textual notices into reliable semantic information.

To address this problem, this paper proposes the NOTAM Ontology-Grounded Type-Aware Extraction (NOTE) framework. NOTE integrates AI-driven structured extraction with a domain-specific dynamic semantic ontology comprising a shared module and seven type-specific sub-ontologies. The predicted NOTAM type determines the active ontology module and extraction scope, allowing heterogeneous notices to be processed within a consistent but type-appropriate semantic structure. Here, “dynamic” refers to classification-driven activation of a predefined sub-ontology rather than online ontology generation or evolution.

From an operational perspective, NOTE complements rather than replaces existing NOTAM processing and professional judgment. Its validated and traceable outputs make relevant information easier to identify and reuse and can support semantic retrieval, consistency checking, and integration with downstream AIM systems. This assistance has the potential to reduce repeated manual reading and the risk of information omission or misinterpretation, although these benefits require further validation in operational environments. NOTE thus represents an initial exploration of large language models for expert-assisted NOTAM processing, following a human–AI collaboration pattern in which AI organizes information while qualified personnel retain responsibility for its interpretation and use [4,9].

The main contributions of this study are summarized as follows:

• A seven-type semantic system and a dynamic semantic ontology are developed to represent shared and type-specific NOTAM semantics within a modular structure.
• NOTE establishes an explicit type–ontology–schema association that connects type-aware extraction with validated ontology instantiation and RDF materialization.
• Comprehensive experiments evaluate type-aware routing, structured extraction, ontology mapping, component contributions, and type-level semantic differences, including a scale-controlled comparison with static ontology structures.

2. Related Work

2.1. Ontology-Based Aeronautical Information Representation

Ontologies formally define domain concepts, relations, and constraints, enabling heterogeneous information to be interpreted within a shared semantic framework. Modular designs support the reuse of common concepts while separating domain- or task-specific structures [10,11], which is particularly relevant to aeronautical information management (AIM).

The Aeronautical Information Exchange Model (AIXM) and Digital NOTAM specification provide structured models for aeronautical information exchange and operational event encoding [12,13]. Building on these standards, Gringinger [14] investigated ontology-based representation and querying of Digital NOTAMs, while Burgstaller et al. [15] applied AIRM-based semantics to fine-grained NOTAM filtering. Semantic technologies have also been used to integrate heterogeneous ATM data, represent spatio-temporal aeronautical information, model Digital NOTAMs, and construct aeronautical knowledge graphs [16,17,18,19].

These studies demonstrate the value of formal semantics for aeronautical information integration and retrieval. However, most employ predefined common structures or fixed mapping paths. Such approaches are suitable for digitally encoded information but provide limited adaptability to textual NOTAMs whose objects, events, parameters, and constraints vary across operational categories. Classification-driven selection of a type-specific semantic scope before instance mapping remains insufficiently explored.

Ontology learning provides a related direction by deriving concepts and relations from textual resources [20,21]. Recent studies have further used LLMs for ontology learning, knowledge graph construction, and conversational ontology engineering [22,23,24]. Whereas these methods aim to generate or refine ontology structures, the present study focuses on selectively activating predefined modules of a domain ontology during NOTAM processing.

2.2. Automated Understanding of NOTAMs

Automated NOTAM understanding has progressed from classification and entity recognition to knowledge extraction and semantic parsing. Attention-based classification has demonstrated the discriminative value of domain-specific textual patterns [25], while BiLSTM-CRF and BERT-BiLSTM-CRF models have been applied to entity recognition in Chinese NOTAMs [26,27]. These approaches identify local textual elements but do not directly construct type-specific semantic records.

More structured interpretations have been obtained through self-supervised language models [28] and pipelines combining classification, entity recognition, rules, and knowledge graphs [19]. Knowledge graphs have also supported NOTAM error correction [29], while extracted information has been used for visualization and operational information access [30,31,32].

Recent LLM-based studies have extended NOTAM processing toward semantic parsing and knowledge-grounded interpretation. KNOTS generates structured records through domain-informed prompting [33], while NOTAM-Evolve incorporates knowledge grounding and schema-based reasoning [34]. These studies substantially extend earlier classification and entity-recognition approaches. However, they do not maintain type-driven alignment among ontology modules, extraction schemas, validation, and RDF instantiation.

2.3. AI-Driven Structured Extraction

Structured information extraction has evolved from token-level sequence labeling to generative record construction. Models such as BiLSTM-CRF are effective for recognizing local entities and slots but are less suited to nested records, cross-field dependencies, and type-dependent structures [35,36]. Generative methods offer greater flexibility by producing entities, events, relations, or complete records through a unified process [37,38].

LLMs extend this flexibility through instruction-based structured generation, but their outputs are not inherently reliable. Generated records may contain unsupported values, missing fields, or malformed structures despite appearing linguistically plausible [39,40,41]. Operational applications must therefore consider structural validity and source consistency in addition to extraction accuracy.

Schema-guided methods improve control by specifying target fields, event structures, or output formats. Existing studies have applied schema-guided prompting to task-oriented and domain-specific generation, while adaptive schema-aware methods retrieve relevant schemas for heterogeneous events [42,43,44]. Type-aware extraction also shows that semantic types can guide entity representation and argument identification [45,46]. However, schemas are commonly treated as prompts, templates, or representation aids rather than as projections of formal domain ontologies.

To clarify the functional differences among representative NOTAM processing approaches and position the contribution of NOTE, Table 1 summarizes their methods, semantic bases, and outputs.

Table 1. Functional comparison of representative approaches to automated NOTAM processing.

Research Content	Method and Semantic Basis	Output
Digital NOTAM representation and querying [14]	Ontology modeling of encoded semantics	Queryable semantic representations
Semantic filtering and enrichment [15,47]	AIRM ontology and operational rules	Filtered and enriched notices
Knowledge extraction from NOTAM text [28]	Self-supervised language modeling	Labels, entities, and Airlang records
Knowledge-graph-based processing [19]	Neural NER, rules, and graph relations	Entities and graph-based results
LLM-based semantic parsing [33]	Knowledge-informed field discovery and prompting	Inference-rich structured records
Knowledge-grounded deep parsing [34]	KG retrieval and schema reasoning	Grounded structured records
Type-aware ontology grounding (this study)	Type routing and modular ontology constraints	Validated records and RDF instances

The comparison reveals a progression from processing digitally encoded notices to extracting and interpreting textual NOTAMs. Ontology-based approaches provide formal semantics but generally operate on Digital NOTAMs, whereas learned and LLM-based methods mainly produce entities or structured interpretations. Even recent knowledge-grounded methods do not directly connect textual parsing with type-specific ontology instantiation.

NOTE provides a more complete processing path for ontology-based AIM integration. The predicted NOTAM type activates the corresponding ontology module and extraction schema, ensuring a consistent semantic scope throughout extraction and ontology instantiation. This restriction reduces confusion among fields and relations from different NOTAM categories. The generated records are then checked against explicit constraints before being materialized as RDF. Consequently, NOTE produces validated, traceable, and machine-interpretable ontology instances that can be directly reused by downstream AIM applications.

3. Preliminaries

3.1. Structure and Semantic Characteristics of NOTAMs

NOTAMs provide essential information for preflight planning and operational control. A NOTAM is a semi-structured aeronautical message comprising standardized fields and a free-text description [3]. The standardized fields specify the location, validity period, scope, and related operational conditions, while the free-text field describes the event or change affecting flight operations.

As shown in Figure 1, the Q-line encodes the subject, condition, traffic, purpose, scope, altitude range, and geographical coverage of a NOTAM. The subject and condition components provide standardized prior information about the affected object and its operational state. Item A identifies the affected aerodrome or flight information region; Items B and C define the validity period; Item D specifies recurring or intermittent schedules; and Items F and G may provide lower and upper altitude limits [48]. Their relatively stable formats generally permit deterministic parsing.

Figure 1. Structure and semantic characteristics of NOTAMs.

However, a standardized message format does not imply fully structured operational semantics. Item E is a free-text field that describes operational events through abbreviations, codes, numerical values, and compact natural-language expressions. Its semantic content varies substantially across NOTAM categories, and the affected object, state, reason, restriction, exception, and their relations are not represented as separate machine-readable fields. Because Item E is manually composed, it may also contain non-standard abbreviations, elliptical expressions, variable word order, or deviations from prescribed phraseology. The Q-line provides a compact semantic prior, but its relation to the detailed evidence in Item E remains implicit. Rule-based parsers and conventional task-specific learning models are therefore less able to accommodate such flexible expressions and type-dependent semantic structures. AI is used here not to parse the regular fields, but to interpret these heterogeneous semantics and map them into type-specific structured records.

3.2. Semantic Type System for NOTAMs

Item E contains the primary description of the operational event [3]. It combines abbreviations, codes, numerical values, and concise natural-language expressions to describe affected objects, states, parameters, reasons, restrictions, and exceptions. These elements often lack explicit boundaries, and their semantic structures vary across operational categories. Processing all notices through a uniform representation may therefore omit type-specific information, introduce irrelevant fields, or produce incorrect semantic mappings.

This study uses the Q-code and Item E as complementary inputs for semantic type identification. The Q-code provides standardized prior information, whereas Item E supplies contextual evidence about the operational condition. The input is represented as    

$$x=(q,e),$$

(1)

where q denotes the subject and condition information derived from the Q-code, and e denotes the free-text content of Item E. Other structured fields are parsed separately and retained for subsequent semantic integration.

The proposed type system distinguishes NOTAMs according to their primary aeronautical objects, operational events or states, and required relations and constraints. For example, runway-related notices concern availability, declared distances, and operational restrictions, whereas navigation-aid notices emphasize facility status and performance changes. The types are therefore determined from the combined operational semantics of the Q-code and Item E rather than from individual codes or surface expressions alone.

The type system was developed by analyzing airline operational scenarios and NOTAM user requirements. Experienced flight dispatchers and senior aeronautical information engineers reviewed representative handling procedures to ensure that the resulting categories reflected operational priorities and information-processing requirements. Table 2 summarizes the seven semantic types.

Table 2. Expert-derived seven-type semantic system for NOTAMs.

Type	Operational Semantic Category
Type-A	Aerodrome and runway availability and declared distances
Type-B	Maneuvering-area and apron operational restrictions
Type-C	CNS/ATM and navigation-aid availability and performance changes
Type-D	ATS routes, flight-level constraints, and airspace activities
Type-E	Instrument procedures and operating-minima amendments
Type-F	Meteorological conditions, runway surface conditions, and braking performance
Type-G	Operational advisories and information notices

Each type defines a local semantic scope containing the objects, attributes, and relations required to represent its operational events. The type system thereby provides semantic boundaries for subsequent ontology-grounded extraction.

3.3. Problem Formulation

This study addresses two coupled tasks. The first is to construct a modular semantic ontology that represents the shared and type-specific semantics of NOTAMs. The second is to transform each input $x=(q,e)$ into a validated ontology-grounded representation under the semantic scope associated with its type. The problem therefore extends beyond field extraction and requires consistency among the source evidence, structured information, and formal semantic representation.

The structured NOTAM fields are parsed deterministically, while the operational content of Item E is interpreted according to one of the seven types defined in Section 3.2. The resulting information is integrated into a type-consistent semantic representation. Section 4 presents the dynamic semantic ontology, and Section 5 describes its application within the NOTE framework.

4. Dynamic Semantic Ontology for NOTAMs

This section presents the construction and structure of the NOTAM dynamic semantic ontology that underpins NOTE. Formalized in Web Ontology Language (OWL), the ontology combines a shared semantic module with seven type-specific sub-ontologies to represent both common and category-dependent NOTAM semantics [49]. Here, “dynamic” denotes the classification-driven activation of a predefined sub-ontology rather than online ontology generation or evolution [50].

4.1. Ontology Architecture

NOTAM categories share general concepts and relations but differ in their operational objects, events, parameters, and constraints. A modular architecture separates these common and type-specific elements while preserving their semantic compatibility [51].

As shown in Figure 2, the shared semantic module contains the upper-level classes NOTAMNotice, OperationalObject, OperationalEvent, Parameter, Restriction, Reason, and Reference, together with reusable concepts and relations. The type-specific semantic module comprises seven sub-ontologies corresponding to Types A–G. Each sub-ontology defines a local semantic scope while reusing the shared upper-level structure.

Figure 2. Architecture of the dynamic semantic ontology for NOTAMs.

The classification result acts as a semantic routing signal that selects the corresponding sub-ontology. This operation neither creates a new ontology nor modifies the existing classes. Instead, it activates a predefined local structure and combines it with the shared module. The architecture therefore maintains semantic consistency across NOTAM types while limiting irrelevant concepts and type-inconsistent mapping paths.

4.2. Type-Specific Sub-Ontologies

The shared module captures semantic elements that recur across NOTAM categories, whereas the type-specific sub-ontologies provide the operational detail required by individual categories. For each type defined in Section 3.2, representative NOTAMs were examined to identify recurring objects, events, parameters, and constraints.

The seven resulting sub-ontologies define the local semantic structures required by their respective NOTAM categories. Their core elements are summarized in Table 3.

Table 3. Semantic scopes and core elements of the seven type-specific NOTAM sub-ontologies.

Type	Semantic Scope	Core Objects	Core Events	Parameters and Constraints
A	Aerodrome/runway	Aerodrome; Runway	Aerodrome/Runway Status	Declared Distance; Reason; Exception
B	Ground movement	Taxiway; Apron; Stand	Status; Parking Restriction; Ground Work	Equipment; Affected Segment; Reason
C	Navigation service	NAVAID; Runway	NAVAID Status	Frequency; Channel; Affected Segment
D	Airspace activity	Airspace Activity	Airspace Activity	Area; Altitude; Time; Route Impact
E	Flight procedure	Procedure; Runway	Procedure Status	Transition; Constraint; Route Impact; Reference
F	Weather/surface	Runway; Aerodrome	Runway/Weather Observation	Surface Condition; Deicing; Reference
G	Facility service	Facility	Facility Service	Location; Time; Altitude; Reference

The sub-ontologies differ in their combinations of object, event, parameter, and constraint classes. For example, Type A represents aerodrome and runway status events together with declared distances, operational reasons, and restriction exceptions. Type D instead represents airspace activities through spatial, temporal, altitude, and route-related constraints. This organization accommodates category-specific semantics without duplicating the shared upper-level model. At runtime, activating only the relevant sub-ontology restricts interpretation to the semantic elements associated with the identified NOTAM type.

4.3. Shared Object Properties

Class modularization alone does not ensure relational consistency across NOTAM types. The ontology therefore employs a common property layer to represent the principal relations among notices, events, affected objects, parameters, constraints, reasons, and references.

Following the distinction between object and data properties in OWL [49], object properties connect ontology individuals, whereas data properties associate individuals with literal values. The core object properties shared by the seven sub-ontologies are summarized in Table 4.

Table 4. Core object properties shared across the type-specific NOTAM sub-ontologies.

Property	Domain	Range	Semantic Meaning
hasEvent	NOTAMNotice	OperationalEvent	Links a NOTAM to the operational event it describes.
concernsObject	OperationalEvent	OperationalObject	Links an operational event to the affected aeronautical object.
hasParameter	OperationalEvent	Parameter	Links an operational event to its associated parameter information.
hasConstraint	OperationalEvent	Restriction	Links an operational event to a restriction, exception, or limiting condition.
hasReason	OperationalEvent	Reason	Links an operational event to the reason for a state change or restriction.
hasReference	OperationalEvent	Reference	Links an operational event to supplementary or referenced information.

These object properties form a shared relation layer across the seven sub-ontologies. Type-specific differences arise from the classes connected through the properties and from the parameters and constraints permitted within the activated semantic scope. Data properties record identifiers, status descriptions, time expressions, numerical values, units, and other literal information. This separation maintains relation-level consistency while keeping the type-specific structures compact.

4.4. Instance Representation

Ontology classes and properties define the admissible semantic model but do not themselves represent individual notices. The ontology therefore adopts an event-centered instance structure to connect each NOTAM with the operational event, aeronautical objects, and associated conditions that it describes.

A NOTAM is represented as an individual of NOTAMNotice, while its primary operational meaning is represented as an individual of the corresponding OperationalEvent subclass. The event individual is connected to the affected object and, where applicable, to parameter, constraint, reason, and reference individuals.

For a NOTAM assigned to type t, its ontology-based representation is defined as

$$R_t=({\mathrm{Inst}}_t,{\mathrm{Attr}}_t,{\mathrm{Rel}}_t),$$

(2)

where ${\mathrm{Inst}}_t$ denotes the set of ontology individuals, ${\mathrm{Attr}}_t$ denotes their data-property assertions, and ${\mathrm{Rel}}_t$ denotes the object-property assertions connecting them.

This representation separates the ontology schema from NOTAM-specific instances. Classes specify the admissible semantic structure, whereas individuals represent the objects, events, and constraints expressed in a particular notice. The resulting assertions can be materialized as RDF triples for semantic storage, retrieval, and consistency checking [52].

5. Ontology-Grounded Type-Aware Extraction Framework

This section presents the NOTAM Ontology-Grounded Type-Aware Extraction (NOTE) framework, which operationalizes the dynamic semantic ontology through type-aware routing, ontology-aligned schema activation, constrained extraction, validation, and semantic instantiation. Its central principle is that structured extraction and RDF materialization are governed by the same type-specific semantic model. The structured record therefore serves as an intermediate representation between NOTAM text and ontology-grounded aeronautical information.

5.1. Overview of the Pipeline

NOTE processes a raw NOTAM through three coordinated layers: an input layer, an extraction layer, and an ontology support layer, as illustrated in Figure 3. The input layer constructs the dual-channel representation $x=(q,e)$ from the Q-code and Item E. Other standardized fields, including location and temporal information, are parsed deterministically and retained for semantic instantiation.

Figure 3. Overall workflow of the NOTE framework.

The extraction layer predicts the semantic type $\widehat{t}$ and retrieves the corresponding ontology module $O_{\widehat{t}}$ and schema contract $S_{\widehat{t}}$. It then generates a candidate record $\widehat{y}$, applies deterministic validation and conservative repair to obtain $\tilde{y}$, and combines the accepted record with the parsed metadata to construct an ontology-grounded representation. The ontology support layer provides the classes, properties, and constraints associated with the activated semantic scope. The overall process is expressed as

$$m\to x=(q,e)\to \widehat{t}\to (O_{\widehat{t}},S_{\widehat{t}})\to \widehat{y}\to \tilde{y}\to R_{\widehat{t}},$$

(3)

where m denotes a raw NOTAM and $R_{\widehat{t}}$ denotes its ontology-grounded semantic representation.

5.2. Type-Aware Routing

Type-aware routing converts the complementary information in the Q-code and Item E into a control signal for ontology and schema activation. The Q-code provides a standardized but relatively coarse prior, whereas Item E supplies detailed yet highly abbreviated contextual evidence. NOTE integrates these channels using a bidirectional cross-attention fusion (BiCAF) model. As illustrated in Figure 4, BiCAF comprises a contextual encoder, two directed cross-attention paths, sequence pooling, and a type classifier.

Figure 4. Architecture of the BiCAF-based type-aware routing module.

The two input channels are first encoded as

$$H_q=\mathrm{Enc}\left(q\right),H_e=\mathrm{Enc}\left(e\right),$$

(4)

where $H_q$ and $H_e$ denote the contextual representations of the Q-code and Item E, respectively. BiCAF then models their interaction in both directions:

$$Z_{q\leftarrow e}=\mathrm{Attn}(H_q,H_e,H_e),Z_{e\leftarrow q}=\mathrm{Attn}(H_e,H_q,H_q),$$

(5)

where $Z_{q\leftarrow e}$ uses Item E to disambiguate the coded prior, while $Z_{e\leftarrow q}$ uses the Q-code to emphasize type-relevant textual evidence. After pooling and concatenation, the routing representation is classified as

$$r=\mathrm{Pool}\left(Z_{q\leftarrow e}\right)\parallel \mathrm{Pool}\left(Z_{e\leftarrow q}\right),\widehat{t}=\arg \underset{t\in \mathcal{T}}{\max }\mathrm{softmax}{(Wr+b)}_t.$$

(6)

The predicted type $\widehat{t}$ determines the semantic resources used in all subsequent stages.

5.3. Ontology-Aligned Schema Construction and Activation

For each type t, an ontology-aligned schema contract $S_t$ is projected from the shared semantic module and the corresponding type-specific sub-ontology:

$$S_t=\mathsf{\Pi }(O_{\mathrm{shared}}\cup O_t),$$

(7)

where $\mathsf{\Pi }(·)$ denotes the projection from ontology elements to a machine-checkable extraction contract. Ontology classes are mapped to structured objects or field groups, data properties to extractable fields, and object properties to relation slots. Datatype and operational constraints are converted into value formats, controlled vocabularies, required-field rules, nullability conditions, and cross-field dependencies.

Accordingly, each contract specifies admissible and required fields, value constraints, and relation slots. Each schema element also retains a predefined mapping to its target ontology class or property. The projection is performed during ontology design, and the resulting contracts are stored for runtime selection.

Let $\mathcal{O}=\{O_A,\dots ,O_G\}$ and $\mathcal{S}=\{S_A,\dots ,S_G\}$ denote the type-specific ontology modules and their corresponding schema contracts. Their association is defined as

$$\mathsf{\Gamma }:\mathcal{T}\to \mathcal{O}\times \mathcal{S},\mathsf{\Gamma }\left(t_i\right)=(O_i,S_i),$$

(8)

where $\mathsf{\Gamma }$ denotes the type–ontology–schema registry. Given $\widehat{t}$, the registry returns $(O_{\widehat{t}},S_{\widehat{t}})$. This operation selects predefined resources rather than generating a new ontology or contract. The activated contract governs extraction and validation, while the associated ontology module guides semantic instantiation.

5.4. Schema-Constrained Extraction and Validation

Under the activated contract, the structured extractor generates a candidate record, which is subsequently checked by the deterministic validator:

$$\widehat{y}=G(x,S_{\widehat{t}}),\tilde{y}=V(\widehat{y},S_{\widehat{t}}),$$

(9)

where $G(·)$ denotes the domain-adapted extraction model and $V(·)$ returns the validated or conservatively repaired record $\tilde{y}$. The processed input, field definitions, value constraints, and target JSON structure are organized into an instruction format that permits only fields defined by $S_{\widehat{t}}$.

Because the contract is aligned with $O_{\widehat{t}}$, it serves as both an extraction specification and a validation interface. Validation covers admissible keys, required fields, value formats, controlled values, nullability rules, and cross-field dependencies [53]. Conservative repair is limited to operations that do not introduce information unsupported by the source, including the removal of inadmissible fields, normalization of unambiguous values, and assignment of permitted null values. Outputs with unresolved violations are rejected and excluded from semantic instantiation.

5.5. Semantic Instantiation and RDF Materialization

Following the instance structure defined in Section 4.4, each validated record is mapped to the activated ontology module [54]. The mapping rules comprise class, data-property, and object-property mappings:

$$\mathcal{M}=\{{\mathcal{M}}_C,{\mathcal{M}}_D,{\mathcal{M}}_O\},$$

(10)

where ${\mathcal{M}}_C$ maps structured elements to ontology classes, ${\mathcal{M}}_D$ maps field values to data properties, and ${\mathcal{M}}_O$ maps instance pairs to object properties.

The mapping process creates a NOTAMNotice individual and an individual of the relevant OperationalEvent subclass. It then creates or links the affected aeronautical objects and instantiates supported parameters, constraints, reasons, and references. Identifiers, status descriptions, time expressions, and numerical values are assigned through data properties, while shared object properties connect the resulting individuals. Domain, range, and type-consistency checks are applied before RDF materialization.

Figure 5 provides an end-to-end input–output example for a Type-A runway-closure NOTAM. The input consists of the original ICAO-format NOTAM, including its Q-code and Item E text. NOTE predicts Type A, activates the corresponding schema contract and aerodrome–runway ontology module, and produces a validated structured record identifying Runway 05/23 as closed for maintenance, with an exception for emergency alternate operations. The final output is an ontology-grounded RDF graph in which the source NOTAM is linked to a runway status event, the affected runway and aerodrome, the operational reason, the restriction exception, and the applicable time constraint. The RDF materialization fragment at the bottom of the figure illustrates the resulting machine-readable representation.

Figure 5. End-to-end ontology-grounded processing of a Type-A runway-closure NOTAM.

NOTE consequently produces both a validated structured record and an ontology-grounded RDF graph, supporting semantic storage, retrieval, consistency checking, and integration within aeronautical information management systems.

6. Experimental Setup

This section describes the datasets, compared methods, evaluation metrics, and implementation settings used to evaluate NOTE. The experiments cover three successive stages: type-aware routing, schema-constrained structured extraction, and ontology mapping. The first two stages share an operational NOTAM corpus, whereas ontology mapping uses a separate expert-annotated set containing RDF-level reference annotations.

6.1. Datasets and Annotation

The routing and structured extraction experiments use the same corpus of 25,341 operational NOTAMs issued in 2024. The notices were randomly sampled from a historical operational repository maintained by the Aeronautical Information Service Center of the Air Traffic Management Bureau, Civil Aviation Administration of China (CAAC), which receives ICAO-format NOTAMs from different regions. The corpus covers all twelve months of 2024 and all seven semantic types, while retaining the imbalanced category distribution observed in operational data. Each notice is associated with a semantic type and a reference structured record containing the field–value pairs defined by the corresponding ontology-aligned schema contract.

The corpus was stratified by semantic type and divided into training, validation, and test sets using an approximately 6:2:2 ratio. The validation set was used for model selection, and the held-out test set was used for routing, structured extraction, and type-level evaluation. Table 5 presents the distribution of the seven semantic types.

Table 5. Distribution of the operational NOTAM corpus by semantic type and data split.

Type	Training	Validation	Test	Total
Type-A	2008	669	669	3346
Type-B	445	148	148	741
Type-C	2527	843	843	4213
Type-D	6264	2088	2088	10,440
Type-E	475	159	158	792
Type-F	1807	602	603	3012
Type-G	1678	559	560	2797
Total	15,204	5068	5069	25,341

The same partitions were used for all routing and structured extraction methods. In the deployable NOTE setting, the type predicted by BiCAF activates the corresponding ontology module and schema contract. Ground-truth type labels were used only in the Gold Type setting to estimate the oracle upper bound.

A separate balanced ontology-mapping set was constructed by selecting 200 notices from each semantic type, yielding 1400 samples. Three experienced airline dispatchers independently reviewed these notices using a shared annotation guideline. For each notice, they verified the operational objects, events, parameters, constraints, reasons, references, and semantic relations expressed in the source text. Inter-annotator agreement before adjudication was measured using Fleiss’ kappa [55] and reached 0.8192, indicating strong agreement among the three dispatchers. Disagreements were resolved through joint review, and the adjudicated annotations were retained as the reference standard.

The verified annotations were subsequently converted into gold slot assignments, instance-level object-property relations, and RDF instances according to the ontology representation rules defined in Section 4. The resulting human-annotated RDF instances served as the reference for ontology-mapping accuracy and semantic-richness evaluation. All ontology mapping schemes were evaluated using the same notices, reference annotations, mapping inputs, and scoring rules.

6.2. Compared Methods and Ablation Settings

The compared methods and controlled variants correspond to the three evaluation stages of NOTE.

For type-aware routing, SVM represents conventional machine learning; TextCNN, BiLSTM, and BiTransformer represent neural text encoders; and BERT-base and RoBERTa-base represent pretrained language models. RoBERTa serves as the contextual encoder of BiCAF [56]. The routing ablations include Single-Stream, which encodes an unseparated NOTAM; Q&E, which concatenates the Q-code and Item E; E-to-Q and Q-to-E, which retain one cross-attention direction; and BiCAF, which integrates both directions. All methods use the same data partitions and evaluation procedure.

For structured extraction, BiLSTM-CRF, BERT-CRF, and BiGRU-CRF represent sequence-labeling methods [35,36]. NuExtract with in-context learning [57] and GLiNER with deterministic record assembly [58] represent general-purpose extraction approaches. Qwen3 with guided decoding [59,60] and DeepSeek-V4 with schema prompting [61] serve as generative structured-output baselines. The Qwen3-Guided Decoding baseline uses the same LoRA-adapted Qwen3-4B checkpoint and adaptation setting as NOTE, providing a capacity- and adaptation-matched comparison. NOTE combines BiCAF-based type activation, ontology-aligned schema contracts, domain-adapted generation, and deterministic validation. NOTE (Gold Type) replaces predicted types with ground-truth labels and is included only as a non-deployable oracle upper bound.

Three controlled variants isolate the contributions of the principal NOTE components. The w/o Schema Contract setting removes the type-specific output contract. The w/o Type Routing setting replaces type-specific activation with a unified extraction structure, and the w/o Validation and Repair setting directly uses the generated records without deterministic checking or conservative repair. All remaining components are held constant within each comparison.

Existing ontology- and knowledge-graph-based NOTAM approaches generally use predefined concepts, properties, relations, and mapping rules within a unified semantic structure [14,15,17,19]. To represent this static modeling paradigm, the Basic Framework Ontology was constructed as a fixed-structure baseline containing 28 classes, four object properties, and eight data properties. It connects each NOTAM instance to operational event and object instances without type routing or sub-ontology activation.

The Static Merged Ontology was constructed as a scale-controlled baseline. It has the same mapping scope as the proposed Dynamic Semantic Ontology—48 classes, seven object properties, and 35 data properties—but combines all type-specific mapping paths into a single static rule set. The Dynamic Semantic Ontology instead activates only the module associated with the predicted type, while Human Annotation provides the reference RDF representation. All schemes use identical mapping inputs, annotations, and scoring procedures, enabling a controlled comparison among fixed semantic modeling, static ontology expansion, and type-specific activation.

6.3. Evaluation Metrics

The evaluation metrics correspond to type-aware routing, structured extraction, and ontology mapping.

Type-aware routing is evaluated using macro-averaged precision, recall, and $F_1$, together with accuracy. Macro-averaging assigns equal weight to all seven semantic types and is therefore appropriate for their imbalanced distribution.

Structured extraction is evaluated using field-level precision, recall, and $F_1$. A field–value pair is considered correct only when both its field and value match the gold record. Record-level reliability is measured using the schema conformance rate (SCR) and record materialization rate (RMR):

$$\mathrm{SCR}={\displaystyle \frac{N_{\mathrm{conf}}}{N}},\mathrm{RMR}={\displaystyle \frac{N_{\mathrm{mat}}}{N}},$$

(11)

where $N_{\mathrm{conf}}$ is the number of outputs satisfying the activated schema contract, $N_{\mathrm{mat}}$ is the number that can be successfully materialized as target records, and N is the total number of evaluated notices. SCR measures compliance with field, datatype, nullability, and dependency constraints, whereas RMR indicates whether an output can support subsequent ontology instantiation. These metrics are not applied to sequence-labeling baselines because they do not directly produce schema-valid records.

Ontology mapping is evaluated using slot-level $F_1$ ($F_{\mathrm{slot}}$), relation-level $F_1$ ($F_{\mathrm{rel}}$), and semantic richness (SR). The first two metrics compare predicted ontology-aligned slots and instance-level object-property relations with the corresponding gold annotations. SR measures the average number of valid semantic assertions instantiated per notice:

$$\mathrm{SR}={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}(E_i+A_i),\mathsf{\Delta }\mathrm{SR}={\mathrm{SR}}_{\mathrm{method}}-{\mathrm{SR}}_{\mathrm{human}},$$

(12)

where $E_i$ denotes the number of valid instance-level object-property edges generated for notice i, and $A_i$ denotes the number of non-empty data-property assertions. Schema-level relations, uninstantiated templates, null values, duplicate values, and default placeholders are excluded.

The human-reference SR is obtained by converting the verified annotations into RDF instances under the same counting rules. A negative $\mathsf{\Delta }\mathrm{SR}$ suggests insufficient semantic coverage, whereas a positive value may indicate redundant mapping. SR is therefore interpreted jointly with $F_{\mathrm{slot}}$ and $F_{\mathrm{rel}}$ rather than as a quantity to be maximized.

6.4. Implementation Details

All locally deployed experiments were conducted under a deployment-oriented computational budget using a single NVIDIA GeForce RTX 5060 Laptop GPU with approximately 8 GB of VRAM. The main implementation used Python 3.12, PyTorch 2.7.0 with CUDA 12.8, and Transformers 4.55.2. Parameter optimization was required only for type-aware routing and schema-constrained generation; schema activation, validation, repair, and ontology mapping were deterministic.

The routing model uses RoBERTa-base with a seven-class prediction head and a maximum input length of 256 tokens. It was trained for 20 epochs using AdamW with a batch size of 16, a learning rate of $2\times {10}^{-5}$, a weight decay of 0.01, linear learning-rate scheduling, and a warmup ratio of 0.1. FP16 mixed-precision computation was enabled, and the random seed was set to 42.

The structured extractor uses Qwen3-4B with low-rank adaptation (LoRA) [62] and a maximum sequence length of 4096 tokens. Training was performed for 20 epochs using an 8-bit AdamW optimizer, a learning rate of $2\times {10}^{-4}$, a weight decay of 0.001, cosine learning-rate scheduling, and 30 warmup steps. The LoRA rank r and scaling factor $\alpha$ were both set to 16. To accommodate the available GPU memory, the model was loaded using 4-bit quantization, while computation during training was performed in bfloat16. The per-device batch size was 1 with four gradient accumulation steps, and the random seed was set to 3407.

All compared methods used the same preprocessing pipeline, data partitions, gold annotations, and evaluation scripts. Model versions, decoding parameters, and external API configurations were fixed within each baseline. The dynamic semantic ontology was formalized in OWL, and deterministic procedures were used for ontology instantiation and RDF materialization. The three ontology mapping schemes were evaluated using identical inputs, reference annotations, and RDF-level scoring rules.

Computational efficiency was evaluated separately on the same GPU using 4-bit NF4 quantization with double quantization and float16 computation. The measured processing path comprised BiCAF-based type routing, Qwen-based structured extraction, and deterministic post-processing. Model loading and warm-up were excluded from the latency measurements, and CUDA operations were synchronized at the timing boundaries. Mean, standard deviation, median, and 95th-percentile latency were reported, while peak allocated GPU memory was measured using PyTorch CUDA statistics. The generation settings were fixed at a maximum of 1024 new tokens, a temperature of 0.2, a top-p value of 0.9, and a repetition penalty of 1.1.

7. Results and Discussion

This section reports the performance of NOTE across the semantic-processing pipeline. The evaluation covers type-aware routing, structured extraction, ontology mapping, and type-level behavior, thereby examining classification accuracy, extraction correctness, structural reliability, and semantic representation quality.

7.1. Type-Aware Routing Performance

Type-aware routing determines the ontology module and schema contract used by subsequent NOTE stages; routing errors may therefore propagate through extraction and semantic instantiation. Table 6 compares the proposed model with representative classification baselines using macro-averaged precision, recall, and $F_1$, together with accuracy.

Table 6. Performance comparison of methods for NOTAM type-aware routing.

Method	Configuration	p	R	${\mathit{F}}_1$	$\mathit{Acc}$
SVM	Conventional classifier	0.8967	0.9422	0.9154	0.9503
TextCNN	Convolutional encoder	0.9221	0.9223	0.9222	0.9515
BiLSTM	Sequential encoder	0.9018	0.9236	0.9099	0.9483
BiTransformer	Lightweight transformer	0.8827	0.8748	0.8674	0.9158
BERT-base	Pretrained transformer	0.9007	0.9201	0.9076	0.9428
RoBERTa-base	Pretrained transformer	0.9195	0.9466	0.9316	0.9621
RoBERTa-BiCAF	Bidirectional cross-attention fusion	0.9324	0.9535	0.9424	0.9741

RoBERTa-BiCAF achieved the best performance across all metrics, with a macro-$F_1$ of 0.9424 and an accuracy of 0.9741. Relative to RoBERTa-base, the strongest baseline, it improved macro-$F_1$ by 1.08 percentage points and accuracy by 1.20 percentage points. The simultaneous gains in precision and recall indicate that explicitly modeling the interaction between the Q-code and Item E provides a more balanced routing signal than single-stream contextual encoding.

Table 7 further examines the contributions of input separation, directional interaction, and bidirectional fusion.

Table 7. Ablation study of the BiCAF-based type-aware routing module.

Variant	Configuration	p	R	${\mathit{F}}_1$	$\mathit{Acc}$
Single-Stream	Unseparated NOTAM input	0.9073	0.9015	0.9031	0.9444
Q&E	Concatenated Q-code and Item E	0.9068	0.9102	0.9095	0.9468
E-to-Q	Unidirectional cross-attention fusion	0.9242	0.9187	0.9212	0.9531
Q-to-E	Unidirectional cross-attention fusion	0.9167	0.9336	0.9232	0.9536
BiCAF	Bidirectional cross-attention fusion	0.9324	0.9535	0.9424	0.9741

Separating the Q-code and Item E increased macro-$F_1$ from 0.9031 to 0.9095, while directional cross-attention produced further improvements. E-to-Q favored precision, whereas Q-to-E achieved higher recall, suggesting that the two directions capture complementary evidence. By integrating both interactions, BiCAF exceeded the strongest unidirectional variant by 1.92 percentage points in macro-$F_1$ and the Q&E variant by 3.29 percentage points. These results support bidirectional fusion as the most reliable routing configuration for ontology and schema activation.

To examine the routing errors behind the aggregate metrics, Figure 6 presents the row-normalized confusion matrix of RoBERTa-BiCAF. Most notices were assigned to the correct type, although several errors occurred between semantically related categories.

Figure 6. Row-normalized confusion matrix of BiCAF-based type-aware routing on the test set.

The main two-way confusion occurred between Types B and G, with 8.11% of Type B notices classified as Type G and 5.00% of Type G notices classified as Type B. This confusion may arise from their overlapping descriptions of operational facilities and status information. Type E was mainly confused with Types C and G, while errors between most other type pairs were limited. Overall, the routing errors were concentrated in a small number of semantically related categories.

7.2. Structured Extraction Performance

Following routing, NOTE converts each NOTAM into a schema-conformant structured record for ontology instantiation. Table 8 compares NOTE with sequence-labeling, general-purpose extraction, and LLM-based structured-output methods. NOTE (Gold Type) uses ground-truth labels for schema activation and is reported only as an oracle upper bound.

Table 8. Performance of structured extraction methods.

Method	Configuration	p	R	${\mathit{F}}_1$	SCR	RMR
BiLSTM-CRF	Bidirectional LSTM with CRF	0.6370	0.6570	0.6468	–	–
BERT-CRF	Pretrained encoder with CRF	0.5379	0.5360	0.5369	–	–
BiGRU-CRF	Bidirectional GRU with CRF	0.6090	0.5426	0.5739	–	–
NuExtract (ICL)	General extraction	0.4229	0.4255	0.4242	0.9860	0.6642
GLiNER-Record Assembly	Entity extraction and assembly	0.5537	0.4218	0.4788	0.9863	0.6094
Qwen3-Guided Decoding	Constrained generation	0.6515	0.6293	0.6402	0.9444	0.7986
DeepSeek-V4 (Schema)	Schema-guided generation	0.8797	0.8768	0.8783	0.9893	0.9507
NOTE (BiCAF)	Predicted-type activation	0.8990	0.9116	0.9053	0.9976	0.9737
NOTE (Gold Type)	Oracle type activation	0.9363	0.9371	0.9367	0.9995	0.9773

NOTE achieved the best non-oracle results, with an $F_1$ of 0.9053, an SCR of 0.9976, and an RMR of 0.9737. Because Qwen3-Guided Decoding and NOTE use the same LoRA-adapted Qwen3-4B checkpoint and adaptation setting, their performance difference reflects the contribution of NOTE’s framework-level mechanisms rather than differences in model capacity or task-specific adaptation. Compared with DeepSeek-V4 using schema prompting, the strongest external baseline, NOTE improved $F_1$ by 2.70 percentage points and RMR by 2.30 percentage points. Within this comparison, schema prompting alone did not provide the same level of type-dependent semantic and structural control as the coordinated use of type-aware activation, schema contracts, and deterministic validation.

The Gold Type setting increased $F_1$ to 0.9367, indicating that routing errors contribute to the remaining extraction gap. However, the differences between predicted- and gold-type activation were substantially smaller for SCR and RMR, showing that NOTE generally produces structurally valid and materializable records under deployable routing conditions. SCR and RMR are not reported for sequence-labeling baselines because these methods do not directly generate schema-valid records.

Table 9 evaluates the contributions of the three principal NOTE components.

Table 9. Ablation study of the principal NOTE components for structured extraction.

Configuration	p	R	${\mathit{F}}_1$	SCR	RMR
w/o Schema Contract	0.2662	0.2444	0.2549	0.1786	0.3212
w/o Type Routing	0.7042	0.7051	0.7047	0.9338	0.8308
w/o Validation and Repair	0.8784	0.8909	0.8846	0.8718	0.9201
NOTE	0.8990	0.9116	0.9053	0.9976	0.9737

All ablation variants retained the same underlying Qwen3-4B checkpoint and LoRA adaptation setting as NOTE, with only the indicated framework component removed. Removing the schema contract caused the largest degradation, reducing $F_1$ to 0.2549 and SCR to 0.1786. Replacing type-specific activation with a unified extraction structure reduced $F_1$ to 0.7047, confirming the importance of restricting extraction to the relevant semantic scope. Removing validation and repair had a smaller effect on field-level $F_1$ but reduced SCR from 0.9976 to 0.8718, indicating that this component primarily improves structural validity and record materializability. The results therefore show complementary roles: schema contracts define the extraction structure, type-aware routing limits cross-type field confusion, and deterministic validation supports reliable ontology instantiation.

7.3. Ontology Mapping Performance

This experiment evaluates the accuracy and semantic completeness of ontology mapping. The Basic Framework Ontology represents a fixed semantic structure, whereas the Static Merged Ontology contains the same classes, properties, and mapping scope as the proposed dynamic ontology but activates all mapping paths simultaneously. The latter controls for ontology scale and isolates the contribution of type-specific activation. Ontology size is reported as the numbers of classes, object properties, and data properties (C/OP/DP). Table 10 reports the resulting differences in mapping accuracy and semantic completeness among the three ontology schemes, with human annotation as the reference.

Table 10. Ontology-mapping performance under different semantic modeling schemes.

Mapping Scheme	Scale	Configuration	${\mathit{F}}_{\mathbf{slot}}$	${\mathit{F}}_{\mathbf{rel}}$	SR	$\mathsf{\Delta }\mathbf{SR}$
Human Annotation	–	Reference representation	–	–	19.97	–
Basic Framework Ontology	28/4/8	Fixed shared structure	0.6599	0.7377	13.74	$-6.23$
Static Merged Ontology	48/7/35	Unified mapping paths	0.9192	0.8529	21.45	$+1.48$
Dynamic Semantic Ontology	48/7/35	Type-specific activation	0.9472	0.9835	19.61	$-0.36$

The Dynamic Semantic Ontology achieved the highest slot- and relation-level $F_1$ scores of 0.9472 and 0.9835, respectively. Compared with the scale-matched Static Merged Ontology, type-specific activation improved $F_{\mathrm{slot}}$ by 2.80 percentage points and $F_{\mathrm{rel}}$ by 13.06 percentage points. The larger gain in relation mapping indicates that restricting the active semantic scope is particularly effective in reducing cross-type relation confusion, an issue that cannot be resolved by simply enlarging a static ontology.

Semantic richness is interpreted by its proximity to the human-annotated reference rather than as a quantity to be maximized. The Basic Framework Ontology provided insufficient semantic coverage, whereas the Static Merged Ontology produced more relations than the reference. Such excess is not inherently harmful, because limited redundancy may support corroboration or robustness in safety-relevant settings. However, when accompanied by lower relation-level accuracy, as observed for the Static Merged Ontology, it indicates potential over-generation, including duplicate or incorrect mappings. In contrast, the Dynamic Semantic Ontology achieved an SR of 19.61, only 0.36 below the reference value of 19.97, while retaining the highest mapping accuracy. This small deviation indicates quantitative closeness to the reference but does not by itself establish complete relation recovery. Accordingly, SR is interpreted jointly with slot- and relation-level accuracy. Under this combined evaluation, type-specific activation provides a more appropriate balance between semantic coverage and mapping precision.

7.4. Computational Efficiency

To assess the computational requirements of NOTE under the available hardware configuration, we measured its inference latency, throughput, and GPU memory usage under single-notice processing. Table 11 reports the latency of the main processing stages. The complete NOTE pipeline required an average of 12.620 s per notice, with a median latency of 9.172 s and a 95th-percentile latency of 33.739 s. The corresponding throughput was 0.0792 notices/s.

Table 11. Inference latency of NOTE under single-notice processing.

Processing Stage	Mean	SD	Median	P95
BiCAF-based Routing	10.20 ms	3.55 ms	9.07 ms	19.85 ms
Qwen-based Extraction	12.609 s	10.099 s	9.164 s	33.718 s
Deterministic Post-processing	0.054 ms	0.012 ms	0.051 ms	0.075 ms
Complete NOTE Pipeline	12.620 s	10.102 s	9.172 s	33.739 s

BiCAF-based routing required only 10.20 ms on average, whereas Qwen-based structured extraction required 12.609 s and accounted for more than 99.9% of the end-to-end latency. Deterministic post-processing added little computational overhead. The main processing bottleneck therefore lies in autoregressive structured generation rather than type routing or subsequent deterministic operations.

The difference between the mean and median latency was mainly associated with variations in input complexity and generated-output length. Across the seven types, the mean end-to-end latency ranged from 6.871 s for Type C to 23.962 s for Type F. Type F generated longer structured outputs and showed greater latency variation. These longer cases raised both the overall mean and the P95 value, while the median better reflects the processing time of a typical notice.

The average processing time of 12.620 s per notice indicates that NOTE can provide automated semantic processing at the second level, reducing the reliance on time-consuming manual review. This processing speed can support routine aeronautical information processing and near-real-time handling in general operational scenarios.

Peak allocated GPU memory was 3.786 GiB, including 2.987 GiB of model-resident allocated memory, within the 7.96 GiB capacity of the RTX 5060 Laptop GPU. These results show that NOTE can operate on a single consumer-grade laptop GPU and adapt to the heterogeneous computational resources commonly found in practical aviation environments. This configuration provides a feasible deployment option for basic scenarios with limited computational resources.

For more complex scenarios involving larger workloads or higher requirements for extraction quality and processing speed, NOTE can be deployed with higher-performance accelerators, batch processing, parallel inference, optimized inference engines, and larger or more capable extraction models. Such configurations may improve throughput and extraction performance, although larger models may also increase memory consumption and inference latency. Their practical effects require further experimental evaluation.

7.5. Type-Level Analysis

Aggregate results may conceal differences among NOTAM categories. Table 12 therefore reports type-level extraction accuracy and structural reliability.

Table 12. Structured extraction performance by NOTAM semantic type.

Type	p	R	${\mathit{F}}_1$	SCR	RMR
Type-A	0.9637	0.9610	0.9623	1.0000	0.9886
Type-B	0.9679	0.9564	0.9622	1.0000	0.9881
Type-C	0.9296	0.9495	0.9395	1.0000	0.9893
Type-D	0.9072	0.9190	0.9131	1.0000	0.9824
Type-E	0.7880	0.8081	0.7979	0.9894	0.9381
Type-F	0.9468	0.9603	0.9535	0.9948	0.9804
Type-G	0.8600	0.8687	0.8643	1.0000	0.9874
Overall	0.8990	0.9116	0.9053	0.9976	0.9737

Types A and B achieved the highest $F_1$ scores, while Types C and F also exceeded 0.93. These categories generally contain recurring identifiers and relatively regular status expressions that facilitate field recognition. Type E was the most challenging category, with an $F_1$ of 0.7979, reflecting the diversity of identifiers, transition segments, operational constraints, and references in procedure-related notices. Type G achieved a lower field-level $F_1$ but maintained an RMR of 0.9874, indicating that its records could generally be materialized despite less complete field recovery. The consistently high SCR values suggest that most type-level differences arise from semantic identification rather than output non-conformance.

Type E was the most challenging category, with an $F_1$ score of 0.7979 under predicted-type extraction. To determine whether this result mainly arose from routing errors or field extraction, we repeated the extraction experiment using the gold type labels. Under the Gold Type setting, Type E achieved a precision of 0.8176, a recall of 0.8381, and an $F_1$ score of 0.8277. Removing routing errors increased its $F_1$ score by 0.0298. This result is consistent with Figure 6, in which 148 of the 158 Type E notices were correctly routed. Routing errors therefore affected the downstream result, but accounted for only a limited part of the performance loss.

Manual examination of the incorrectly extracted Type E samples showed that the errors mainly occurred in flight-procedure-related notices. These notices often contained long and irregular Item E text with multiple procedure identifiers, parameter values, applicability conditions, and operational constraints. Some also included table-like content whose original alignment was not consistently preserved in plain text. The main errors involved incomplete recognition of procedure identifiers, incorrect separation of adjacent fields, and incorrect association of parameter values with the corresponding procedures or constraints. The lower performance of Type E was therefore mainly related to the complexity and semi-structured form of its extraction content, while type-routing errors made a smaller contribution.

Figure 7 examines whether the expert-defined taxonomy is also reflected in the learned representations and compares the semantic richness of the seven types.

Figure 7. Type-level representation and semantic richness of NOTAMs: (a) t-SNE projection of learned representations and (b) average semantic richness by semantic type.

The t-SNE projection [63] shows that samples assigned to the same expert-defined type generally form locally coherent clusters. The seven categories exhibit distinguishable distributions, although partial overlap remains between semantically related types. As t-SNE provides qualitative rather than conclusive evidence, the visualization should be interpreted together with the routing results in Section 7.1. Collectively, these results indicate that the expert-defined taxonomy is also reflected in the learned data representation and is empirically suitable for type-aware routing.

Semantic richness ranges from 15.65 for Type G to 28.95 for Type F, demonstrating substantial variation in ontology representation requirements. The high SR of Type F reflects its combination of operational observations, surface conditions, treatments, and reference information. However, its strong extraction performance shows that semantic richness alone does not determine extraction difficulty. Overall, the observed differences in representation distribution, extraction performance, and semantic richness support the use of type-specific ontology modules rather than a uniform semantic structure.

Taken together, the results show that NOTE’s performance is derived from the coordinated operation of its components rather than from any single model or constraint mechanism. BiCAF provides a reliable routing signal, ontology-aligned schema contracts restrict extraction to the relevant semantic scope, and deterministic validation improves record-level reliability before semantic instantiation. The scale-controlled ontology comparison further demonstrates that the mapping gains arise primarily from type-specific activation rather than from ontology expansion alone. At the same time, the gap between predicted- and gold-type activation and the lower performance of Type E indicate that routing ambiguity and semantically complex procedure notices remain the principal sources of error. Overall, NOTE provides a coherent connection between AI-based NOTAM interpretation, validated structured extraction, and ontology-grounded representation, supporting the integration of operational notices into aeronautical information management systems.

8. Conclusions

This study demonstrates that AI-driven NOTAM processing should not be formulated as a uniform information extraction task. Although NOTAMs follow a standardized message format, their operational semantics remain embedded mainly in abbreviated and heterogeneous Item E text and vary across semantic categories. NOTE addresses this challenge by using the identified NOTAM type to coordinate ontology-module activation, schema-constrained extraction, deterministic validation, and RDF instantiation. Its contribution therefore extends beyond field extraction by establishing a consistent semantic path from textual interpretation to formal, machine-interpretable AIM representation.

The experimental findings support three main conclusions. First, the Q-code and Item E provide complementary evidence, and their bidirectional interaction enables more reliable semantic routing than independent or unidirectional processing. Second, ontology-aligned schema contracts function as semantic constraints rather than merely output templates. They restrict the extraction scope, reduce cross-type field confusion, and provide explicit criteria for deterministic validation. Third, semantic representation quality depends more on activating an appropriate type-specific ontology scope than on simply increasing the number of classes and properties. This effect is particularly evident in relation mapping, where static ontology expansion increases coverage but also introduces redundant or type-inconsistent relations.

Structured extraction in NOTE consequently serves as a machine-checkable intermediate stage rather than the final output. By converting information embedded in Item E into explicit and traceable objects, events, states, constraints, and relations, NOTE can reduce repeated manual reading, interpretation, and structuring by airlines, airports, and AIM service providers. The resulting records support semantic retrieval, cross-message integration, consistency checking, and reuse by downstream systems. Schema constraints and deterministic validation further filter structurally invalid or unsupported outputs before RDF materialization, thereby reducing the potential for information omission and misinterpretation. These capabilities have the potential to alleviate the routine workload of front-line personnel, reduce manual processing costs, and support safer use of operational information. NOTE therefore follows a human–AI collaboration paradigm in which AI organizes and validates information, while qualified personnel retain responsibility for its review, interpretation, and operational use. Further evaluation in real-world AIM environments is required to quantify its effects on workload, cost, interpretation accuracy, and operational safety.

Limitations and Future Work. Although NOTE may be adapted to other operational message domains, its semantic type system, ontology modules, schema contracts, and mapping rules are specific to NOTAMs and would require expert redefinition before transfer. The evaluation is also limited to a single-year corpus and an offline ontology-mapping set. Although the corpus covers all twelve months of 2024 and includes ICAO-format NOTAMs received from different regions, the message-level random split is not equivalent to strict cross-year or provider-held-out evaluation. Future work should therefore validate NOTE across multiple years, information providers, regions, and operational environments.

The standardized ICAO NOTAM format and Q-code system limit substantial structural variation across regions. Nevertheless, changes in ICAO provisions, Q-code usage, local abbreviations, or reporting conventions may introduce temporal drift. New semantic fields would require corresponding updates to the ontology modules, schema contracts, and RDF mapping rules, while new or revised Q-codes would also require updates to the Q-code registry and type mappings. These resources should be versioned with explicit effective dates, and newly annotated samples could be used to update the BiCAF router and incrementally fine-tune the extraction model. Unregistered Q-codes, low-confidence predictions, and repeated validation failures should be directed to expert review, followed by regression testing on historical and newly collected notices.

Routing errors remain a source of downstream extraction error, particularly for procedure-related Type E notices with diverse identifiers, transitions, constraints, and references. Future work will investigate uncertainty-aware routing, confidence-based abstention, improved representation of complex procedure events, and expert review of low-confidence cases. Operational evaluation should additionally consider latency, traceability, interoperability, expert workload, and operational utility.

The computational-efficiency evaluation recorded a peak allocated GPU memory of 3.786 GiB for the 4-bit quantized Qwen3-4B model, including 2.987 GiB of model-resident memory, on an RTX 5060 Laptop GPU. This result indicates potential deployment on infrastructure equipped with a small discrete GPU, but does not establish feasibility for onboard computers or nodes with stricter memory, power, and thermal constraints. For such environments, the RoBERTa-based router could be distilled into a compact encoder such as TinyBERT, while Qwen3-4B could supervise a smaller generative extraction model. Future work will evaluate whether distilled models can reduce latency, memory, and energy consumption while maintaining the field-level accuracy, schema conformance, and RDF materializability required for safety-relevant deployment.