Ontology-to-probe intermediate representation compilation and family arrangement method and system

Abstract

The invention discloses an ontology-to-probe intermediate representation compilation and family arrangement method and system, and the method comprises the steps: collecting multi-source metadata data of a preset mass spectrum, and carrying out the preprocessing of the multi-source metadata data; inputting the multi-source metadata into an OWL parser to extract core elements, and performing classification field mapping on the multi-source metadata according to a context matching rule to obtain a mapping relation; generating a probe intermediate representation for the metadata logic field based on the mapping relation and the ontology constraint, and clustering the probe intermediate representation according to an instrument model, an experimental method and an application scene to obtain a familiarized probe packet; establishing bidirectional mapping between the ontology and the familial probe packet, and when the ontology is changed, performing incremental compiling on the probe intermediate representation according to the bidirectional mapping to obtain an arrangement result; the change comprises a new field and a modification constraint.

Description

Technical Field

[0001] This invention relates to the field of mass spectrometry data parsing and semantic modeling, and in particular to a method and system for compiling and arranging intermediate representations from ontology to probes. Background Technology

[0002] In multi-source mass spectrometry metadata parsing scenarios, it is typically necessary to write a large number of parsing scripts for raw files from different instrument manufacturers, different open formats, and different experimental management systems. As application scenarios increase and ontology models evolve, the maintenance cost of these parsing scripts rises sharply.

[0003] Although existing research has attempted to model metadata in a unified manner using domain ontology, there is still a significant semantic-implementation gap between ontology objects and executable rules. This gap is mainly manifested in the following ways: classes and attributes in the ontology are difficult to automatically convert into executable parsing rules; different combinations and priorities of parsing rules are often required for different instrument models, method types and application scenarios, but there is a lack of a systematic probe family management mechanism; and the ontology version cannot automatically drive the synchronous evolution of parsing rules when it is updated.

[0004] Therefore, there is an urgent need for a technical solution that can automatically compile mass spectrometry ontology into probe intermediate representations and support multi-source, multi-scenario analysis through family-based arrangement. Summary of the Invention

[0005] The purpose of this invention is to provide a method for compiling and family-arranging intermediate representations from ontology to probe.

[0006] To achieve the above objectives, the present invention is implemented according to the following technical solution: This invention includes the following steps: Collect multi-source metadata data from a preset mass spectrometer, and preprocess the multi-source metadata; the multi-source metadata includes manufacturer original files, open format files, and experimental management system data; The multi-source metadata is input into the OWL parser to extract core elements, and the multi-source metadata is classified and mapped according to the context matching rules to obtain the mapping relationship; the core elements include metadata logical fields, candidate data source paths, constraints, and context labels; Based on the mapping relationship and ontology constraints, a probe intermediate representation is generated for the metadata logical fields. The probe intermediate representation is then clustered according to the instrument model, experimental method, and application scenario to obtain a family of probe packages. The probe intermediate representation includes probe type, operator, priority, and license label. A bidirectional mapping is established between the ontology and the family of probe packages. When the ontology changes, the intermediate representation of the probes is incrementally compiled according to the bidirectional mapping to obtain the arrangement result. The changes include adding fields and modifying constraints.

[0007] Furthermore, the method for obtaining mapping relationships by classifying the multi-source metadata according to context matching rules includes: The data source type of multi-source metadata is identified by file header keywords or API response headers. The data source paths of multi-source metadata are sorted based on the multi-source path priority mechanism. The mapping template is automatically called according to the instrument model, experimental method and data source type. The multi-source path priority mechanism sorts the data source paths according to the dual dimensions of reliability and scenario matching when the same logical field has multiple data source paths, and sets the priority. Filter fields related to the current data source based on metadata logical fields, and locate the physical storage location using path expressions in the template; Read the context tags of the metadata, filter out the mismatched paths, sort the remaining paths according to the priority mechanism, and keep the top 3 high priority paths; Based on whether the physical field exists and whether the data type matches the path, the mapping relationship corresponding to the matching path is used as the verification mapping relationship; Conversely, by inputting multi-source metadata into the multimodal anomaly detection model to obtain anomaly identification data, and by using the context labels extracted during the ontology parsing stage to dynamically adjust the verification strategy, the Big Language Model-A algorithm is used to locate invalid paths, and logical fields and data type knowledge graphs are used to locate data type conflicts. For invalid paths: Input the context label corresponding to the invalid path into the Big Prophet model to generate a new path. Use a landmark segmentation search strategy to decompose the long path into multiple sub-paths. Use the A algorithm to verify the validity of each sub-path one by one. Then, concatenate the sub-paths to obtain a complete and valid path. To address data type conflicts: For numeric fields, BoostClean's mean / median fill is used; for categorical fields, ontology-driven repair is performed using semantic similarity recommendation based on word-direction variables. When a constraint conflict is detected, the repair rules defined in the ontology are automatically invoked to obtain the repaired data type. Output the mapping relationship between the complete and valid path and the data type to be repaired, and the verification mapping relationship.

[0008] Furthermore, the method for generating probe intermediate representations for the metadata logical fields based on the mapping relationship and ontology constraints includes: The mapping relationship and ontology constraints are preprocessed and parameters are initialized. The three highest priority data source paths are selected from the mapping relationship, and operators are matched for each path based on data type and path characteristics to generate extraction logic description and execution priority, thus obtaining extraction probes. Among them, text / numeric fields are selected by taking the first valid value and the average value of multiple sources, and enumeration fields are selected by precisely matching the preset enumeration value. Based on ontology constraints, basic verification rules are generated, supplemented with domain knowledge verification, and verification probes are generated by configuring anomaly handling strategies. Anomaly detection is triggered when fields marked as deprecated in the ontology or fields with mutual exclusion relationships are combined. Negative probes are generated by defining prohibition modes and configuring response actions. Weights are assigned based on contextualized labels. Multiple probes for the same logical field are sorted as extraction probes, verification probes, and negative probes. When the extracted values ​​from different paths are inconsistent, a conflict resolution strategy is activated. The conflict resolution strategy includes prioritizing high-reliability paths and arbitrating domain rules. The extraction probe is at level three, the verification probe at level four, and the negative probe at level five. Duplicate probes are merged, with the number of single-field probes limited to 5 or less. A two-layer verification mechanism is used to verify the final probe and output it as an intermediate probe representation. The multi-layer verification mechanism includes rule verification and scenario simulation. The intermediate probe representation includes basic information, probe type and function, data source path list, operators and parameters, constraint rule set, context label and priority.

[0009] Furthermore, a method for clustering the intermediate representations of the probes according to instrument model, experimental method, and application scenario to obtain family-based probe packages includes: The context labels are layered according to instrument attributes, experimental characteristics, and scenario requirements to form feature vectors, resulting in a three-level label structure. The importance of the context labels is calculated using the entropy weight method. The first clustering is performed based on the first-level labels to generate a manufacturer-model-specific basic family; the basic family is then clustered a second time based on the second-level and third-level labels, and differential probes are added. A priority-ordering communication learning algorithm is introduced to transform probe rule conflicts into a priority decision problem. Each probe is defined with 5-dimensional priority features, including ontology constraint strength, data reliability, and scene specificity. By simulating learning and training a priority model, the probe feature vector is input into the priority model to obtain real-time priority ranking. Clustering is continuously optimized until the rule conflicts that the priority mechanism has not resolved are less than or equal to the conflict threshold, the probe coverage of the family package in the target scene is greater than or equal to the coverage threshold, and the reuse rate of the basic family probe in the incremental scene is greater than or equal to the reuse threshold. When a new field is added to the ontology or the experimental method is changed, incremental clustering is performed on the changed probes, and the priority of the conflict rules is recalculated through the priority model to generate a new incremental version package.

[0010] Furthermore, the method for establishing a bidirectional mapping between the ontology and the family of probe packages includes: Establish a precise correspondence between ontology logical fields and probe intermediate representations, bind ontology constraints to probe validation rules, and automatically synchronize the data type and value range attributes of the corresponding probe when the data type and value range constraints in the ontology change. Monitor the ontology version control system, identify ontology changes, associate ontology applicable scenarios with probe families through context tags, and classify ontology changes into core changes and non-core changes. Only core changes trigger probe system updates; core changes include adding / deleting fields and modifying key constraints; non-core changes include adjusting descriptive text and supplementing examples. Based on the feature mapping table, the affected probe families, probe IDs and specific attributes are calculated, the affected probes are compiled, and preset rules are automatically applied to resolve conflicts. Based on the feature mapping relationship, the system automatically identifies the affected probe families and specific probes, sorts the affected probes into core field probes, scenario-specific probes, and general probes, prioritizes the compilation of probes for key scenarios, and shortens the update window period. When probe rule conflicts are caused by ontology changes, basic conflict rules are defined. For conflicts that cannot be resolved automatically, a conflict report is generated and the conflict type, involved probe IDs, and suggested solutions are marked. After the conflict is resolved, the probe behavior is first verified in 10% of the test dataset. Only after it passes the verification is the full deployment completed.

[0011] Further, the method for incrementally compiling the intermediate representation of the probe according to the bidirectional mapping to obtain the orchestration result includes: A three-layer bidirectional mapping of version, feature, and probe is constructed between the ontology and the probe family. The version mapping is between the ontology version and the probe family version; the feature mapping is between the logical fields in the ontology and the IDs represented by the probe, and the field types and dependencies are labeled; the constraint mapping is between the ontology constraints and the probe operators. The version control system automatically monitors changes to the system and categorizes them into three types based on their impact: core changes, extended changes, and minor changes. Extended changes include adding context tags and supplementing data source paths; minor changes include correcting field description text and optimizing tag levels. Based on bidirectional mapping, probe resources that are rapidly located to reflect the impact of changes are used. Core changes trigger a full update of the intermediate representation of associated probes; extended changes trigger an update of incremental probes for related scenarios; and minor changes trigger an update of documentation. For probe intermediate representations with a defined impact range, targeted updates are performed, including extracting the probe update data source path, verifying the probe to modify the verification rules, and adding anomaly detection logic to negative probes. The compiled probe intermediate representations are clustered by scenario to generate the final orchestration result.

[0012] Secondly, the intermediate representation between the ontology and the probe is the compilation and family-based orchestration system, including: Data acquisition module: used to acquire multi-source metadata data of a preset mass spectrometer and preprocess the multi-source metadata; the multi-source metadata includes Feature extraction and field mapping module: This module is used to input the multi-source metadata into the OWL parser to extract core features, and to perform classification field mapping on the multi-source metadata according to context matching rules to obtain mapping relationships; the core features include metadata logical fields, candidate data source paths, constraints, and context labels; Intermediate representation generation and clustering module: used to generate probe intermediate representations for the metadata logical fields based on the mapping relationship and ontology constraints, and to cluster the probe intermediate representations according to instrument model, experimental method and application scenario to obtain family-based probe packages; the probe intermediate representation includes probe type, operator, priority and license label; Bidirectional mapping and incremental compilation module: used to establish a bidirectional mapping between the ontology and the family probe package. When the ontology changes, the intermediate representation of the probe is incrementally compiled according to the bidirectional mapping to obtain the arrangement result; the changes include adding fields and modifying constraints.

[0013] The beneficial effects of this invention are: This invention relates to a method and system for compiling and familiarizing representations from the ontology to the probe. Compared with existing technologies, this invention has the following technical advantages: This invention employs preprocessing, core element extraction, classification field mapping, probe intermediate representation generation, clustering, bidirectional mapping, and incremental compilation steps. Through family-based orchestration management of multi-scenario parsing rules, incremental compilation and synchronous updates can be performed when the ontology changes, reducing the maintenance cost of parsing scripts and improving the adaptability, reusability, and update efficiency of multi-source mass spectrometry metadata parsing. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating the steps of the method for compiling and familiarizing the representation between the ontology and the probe in this invention. Detailed Implementation

[0015] The present invention will be further described below through specific embodiments. The illustrative embodiments and descriptions herein are used to explain the present invention, but are not intended to limit the present invention.

[0016] The present invention provides a method and system for compiling and familiarizing representations from the ontology to the probe, comprising the following steps: like Figure 1 As shown, this embodiment includes the following steps: Collect multi-source metadata data from a preset mass spectrometer, and preprocess the multi-source metadata; the multi-source metadata includes manufacturer original files, open format files, and experimental management system data; In the actual evaluation, three types of preset mass spectrometry multi-source metadata were collected: RAW format raw files of a certain model of mass spectrometer from A11 Company, mzML open format files, and experimental management data exported from the laboratory LIMS system; in the preprocessing stage, damaged spectral data blocks in RAW files were removed, the encoding format of mzML files was standardized, and the date and numerical units of LIMS system data were standardized. The multi-source metadata is input into the OWL parser to extract core elements, and the multi-source metadata is classified and mapped according to the context matching rules to obtain the mapping relationship; the core elements include metadata logical fields, candidate data source paths, constraints, and context labels; In actual evaluation, for the core elements: establish a mapping table between logical fields and data source paths to obtain many-to-many relationships, and use a priority scoring mechanism to handle path conflicts; supplement the implicit constraints not defined in the ontology based on mass spectrometry domain knowledge, and introduce dual checks of syntax and consistency to improve extraction accuracy; reconstruct the flat labels into a three-level tree structure, where the first level is the manufacturer, the second level is the instrument model, and the third level is the experimental method. Based on the mapping relationship and ontology constraints, a probe intermediate representation is generated for the metadata logical fields. The probe intermediate representation is then clustered according to the instrument model, experimental method, and application scenario to obtain a family of probe packages. The probe intermediate representation includes probe type, operator, priority, and license label. A bidirectional mapping is established between the ontology and the family of probe packages. When the ontology changes, the intermediate representation of the probes is incrementally compiled according to the bidirectional mapping to obtain the arrangement result. The changes include adding fields and modifying constraints.

[0017] In this embodiment, the method for obtaining mapping relationships by classifying the multi-source metadata fields according to context matching rules includes: The data source type of multi-source metadata is identified by file header keywords or API response headers. The data source paths of multi-source metadata are sorted based on the multi-source path priority mechanism. The mapping template is automatically called according to the instrument model, experimental method and data source type. The multi-source path priority mechanism sorts the data source paths according to the dual dimensions of reliability and scenario matching when the same logical field has multiple data source paths, and sets the priority. Filter fields related to the current data source based on metadata logical fields, and locate the physical storage location using path expressions in the template; Read the context tags of the metadata, filter out the mismatched paths, sort the remaining paths according to the priority mechanism, and keep the top 3 high priority paths; Based on whether the physical field exists and whether the data type matches the path, the mapping relationship corresponding to the matching path is used as the verification mapping relationship; Conversely, by inputting multi-source metadata into the multimodal anomaly detection model to obtain anomaly identification data, and by using the context labels extracted during the ontology parsing stage to dynamically adjust the verification strategy, the Big Language Model-A algorithm is used to locate invalid paths, and logical fields and data type knowledge graphs are used to locate data type conflicts. For invalid paths: Input the context label corresponding to the invalid path into the Big Prophet model to generate a new path. Use a landmark segmentation search strategy to decompose the long path into multiple sub-paths. Use the A algorithm to verify the validity of each sub-path one by one. Then, concatenate the sub-paths to obtain a complete and valid path. To address data type conflicts: For numeric fields, BoostClean's mean / median fill is used; for categorical fields, ontology-driven repair is performed using semantic similarity recommendation based on word-direction variables. When a constraint conflict is detected, the repair rules defined in the ontology are automatically invoked to obtain the repaired data type. Output the mapping relationship between the complete and valid path and the data type to be repaired, and the verification mapping relationship as a mapping relationship; In actual evaluation, semantic qualifiers are added to distinguish fields with the same name but different meanings to achieve fuzzy validation; Input the multi-source metadata into the OWL parser to extract the core elements: the logical fields are collision energy and ion source type, and there are 3 candidate data source paths (RAW: / Instrument / CollisionEnergy, mzML: / spectrum / param[@name="Collision Energy"], LIMS: / Experiment / Params / Collision_Energy), with the constraint that the collision energy is 30-400℃ and the context label is A11-QE-HF-quantitative analysis; The data source type is identified by the keywords in the file header. The A11-QE-HF exclusive mapping template is called to filter relevant fields and locate the physical storage location. After filtering out mismatched paths, the top 3 high-priority paths are retained. Upon inspection, the collision energy field in the LIMS data is found to be of string data type. BoostClean mean filling is used for repair, and finally 3 valid mapping relationships are output.

[0018] In this embodiment, the method for generating an intermediate probe representation for the metadata logical field based on the mapping relationship and ontology constraints includes: The mapping relationship and ontology constraints are preprocessed and parameters are initialized. The three highest priority data source paths are selected from the mapping relationship, and operators are matched for each path based on data type and path characteristics to generate extraction logic description and execution priority, thus obtaining extraction probes. Among them, text / numeric fields are selected by taking the first valid value and the average value of multiple sources, and enumeration fields are selected by precisely matching the preset enumeration value. Based on ontology constraints, basic verification rules are generated, supplemented with domain knowledge verification, and verification probes are generated by configuring anomaly handling strategies. Anomaly detection is triggered when fields marked as deprecated in the ontology or fields with mutual exclusion relationships are combined. Negative probes are generated by defining prohibition modes and configuring response actions. Weights are assigned based on contextualized labels. Multiple probes for the same logical field are sorted as extraction probes, verification probes, and negative probes. When the extracted values ​​from different paths are inconsistent, a conflict resolution strategy is activated. The conflict resolution strategy includes prioritizing high-reliability paths and arbitrating domain rules. The extraction probe is at level three, the verification probe at level four, and the negative probe at level five. Duplicate probes are merged, with the number of single-field probes limited to no more than 5. A two-layer verification mechanism is used to verify the final probe and output it as an intermediate probe representation. The multi-layer verification mechanism includes rule verification and scenario simulation. The intermediate probe representation includes basic information, probe type and function, data source path list, operators and parameters, constraint rule set, context label and priority. In actual evaluation, the field mapping relationship consists of a many-to-many association between logical fields and data source paths, including path expressions, data source types, and context matching rules; the ontology constraints are a set of rules extracted from the mass spectrometry domain ontology, including data types, value ranges, mutual exclusion relationships, and version tags; Preprocessing and parameter initialization: Invalid paths are removed, path reliability scores are assigned, multi-source paths with the same logical field are prioritized, and constraints described in natural language are transformed into machine-readable rules; constraints include data type constraints, value range constraints, and related field constraints. Data type constraint validation rules: Must be integers, non-numeric characters are prohibited; exception handling strategy is alarm + marking invalid values; value range constraint validation rules: 30-400℃; 50-400℃ for APCI source; exception handling strategy is to take the nearest boundary value when out of range; related field constraint validation rules: Validated in conjunction with ion source type field; exception handling strategy is to mark as requiring manual review when not linked. Logical field collision energy extraction probe generation: The logical field is the collision energy; the candidate path is 1.RAW: / Instrument / CollisionEnerg 2.mzML: / spectrum / param[@name="CollisionEnergy"]; operator is first_valid; context label is Thermo-QE-HF-quantitative; Basic information includes probe ID, logical fields, generation time, and version number; probe type and function are clearly marked as extraction / verification / negative probes and their core role; data source path list includes path expression, priority, and reliability score; operators and parameters are described in detail with operational logic; constraint rule set is listed in bullet points with constraints such as data type and value range; context label and priority three-level label and execution priority; Select three data source paths with the highest priority to generate probes for the collision energy field: Extraction probe: Match the first valid value operator, priority level 3; Verification probe: Generate verification rules based on the constraint 30-400℃, priority level 4; Negative probe: Define a prohibition mode that triggers an alarm when the collision energy is greater than 400℃, priority level 5. After merging duplicate probes, a two-layer verification process involving rule validation and scenario simulation is used to output an intermediate representation of the probes, which includes information such as a list of data source paths, operator parameters, and context labels.

[0019] In this embodiment, the method for clustering the intermediate representations of the probes according to the instrument model, experimental method, and application scenario to obtain a family of probe packages includes: The context labels are layered according to instrument attributes, experimental characteristics, and scenario requirements to form feature vectors, resulting in a three-level label structure. The importance of the context labels is calculated using the entropy weight method. The first clustering is performed based on the first-level labels to generate a manufacturer-model-specific basic family; the basic family is then clustered a second time based on the second-level and third-level labels, and differential probes are added. A priority-ordering communication learning algorithm is introduced to transform probe rule conflicts into a priority decision problem. Each probe is defined with 5-dimensional priority features, including ontology constraint strength, data reliability, and scene specificity. By simulating learning and training a priority model, the probe feature vector is input into the priority model to obtain real-time priority ranking. Clustering is continuously optimized until the rule conflicts that the priority mechanism has not resolved are less than or equal to the conflict threshold, the probe coverage of the family package in the target scene is greater than or equal to the coverage threshold, and the reuse rate of the basic family probe in the incremental scene is greater than or equal to the reuse threshold. When a new field is added to the ontology or the experimental method is changed, incremental clustering is performed on the changed probes, the priority of conflict rules is recalculated through the priority model, and a new incremental version package is generated. In actual assessment, the three-level label structure consists of a first-level label, a second-level label, and a third-level label. The first-level label is the instrument attribute, the second-level label is the experimental characteristics, and the third-level label is the scenario requirements. The first-level label includes the manufacturer, model, and hardware configuration; the second-level label includes the analyte type, separation mode, and data acquisition mode; and the third-level label includes accuracy requirements, data volume, and compliance requirements. The conflict threshold is 0.5%, and the coverage threshold is 95%. The three-level label structure is used to hierarchically define context labels: Level 1 (instrument attribute: A11-QE-HF), Level 2 (experimental characteristics: quantitative analysis), and Level 3 (scenario requirements: drug detection). Based on the Level 1 label, a basic family of A11-QE-HF is generated. Then, secondary clustering is performed according to the Level 2 and Level 3 labels to add differentiated probes for drug detection scenarios. Rule conflicts are handled by a priority-ordering communication learning algorithm. After the priority model trained by simulation learning is sorted, the conflict rate is reduced to 0.3%, which is less than 0.5%; the probe coverage reaches 96%, which is greater than or equal to 95%, and the A11-QE-HF-drug quantification family probe package is generated.

[0020] In this embodiment, the method for establishing a bidirectional mapping between the ontology and the family of probe packages includes: Establish a precise correspondence between ontology logical fields and probe intermediate representations, bind ontology constraints to probe validation rules, and automatically synchronize the data type and value range attributes of the corresponding probe when the data type and value range constraints in the ontology change. Monitor the ontology version control system, identify ontology changes, associate ontology applicable scenarios with probe families through context tags, and classify ontology changes into core changes and non-core changes. Only core changes trigger probe system updates; core changes include adding / deleting fields and modifying key constraints; non-core changes include adjusting descriptive text and supplementing examples. Based on the feature mapping table, the affected probe families, probe IDs and specific attributes are calculated, the affected probes are compiled, and preset rules are automatically applied to resolve conflicts. Based on the feature mapping relationship, the system automatically identifies the affected probe families and specific probes, sorts the affected probes into core field probes, scenario-specific probes, and general probes, prioritizes the compilation of probes for key scenarios, and shortens the update window period. When probe rule conflicts are caused by ontology changes, basic conflict rules are defined. For conflicts that cannot be resolved automatically, a conflict report is generated and the conflict type, involved probe IDs, and suggested solutions are marked. After the conflict is resolved, the probe behavior is first verified in 10% of the test dataset. After passing the verification, the probe is then fully deployed. In actual evaluation, the conflicts that cannot be resolved automatically are: the same field is defined with contradictory constraints in different ontology branches; Establish a three-layer bidirectional mapping between the ontology and the family probe package: version mapping, feature mapping, and constraint mapping. The version mapping is the probe package V2.0 corresponding to ontology V2.0, the feature mapping is the logical field collision energy binding probe ID: P001, and the constraint mapping is the value constraint association verification operator.

[0021] In this embodiment, the method for incrementally compiling the intermediate representation of the probe according to the bidirectional mapping to obtain the orchestration result includes: A three-layer bidirectional mapping of version, feature, and probe is constructed between the ontology and the probe family. The version mapping is between the ontology version and the probe family version; the feature mapping is between the logical fields in the ontology and the IDs represented by the probe, and the field types and dependencies are labeled; the constraint mapping is between the ontology constraints and the probe operators. The version control system automatically monitors changes to the system and categorizes them into three types based on their impact: core changes, extended changes, and minor changes. Extended changes include adding context tags and supplementing data source paths; minor changes include correcting field description text and optimizing tag levels. Based on bidirectional mapping, probe resources that are rapidly located to reflect the impact of changes are used. Core changes trigger a full update of the intermediate representation of associated probes; extended changes trigger an update of incremental probes for related scenarios; and minor changes trigger an update of documentation. For probe intermediate representations with a defined impact range, targeted updates are performed, including extracting the probe update data source path, verifying the probe to modify the verification rules, and adding anomaly detection logic to negative probes; the compiled probe intermediate representations are clustered by scenario to generate the final orchestration result. In actual evaluation, the final orchestration results include version number updates, conflict resolution, and canary release markers. Version number updates follow the major version, minor version, and revision number rules; conflict resolution uses a priority mechanism to handle rule conflicts in multiple scenarios; and canary release markers label high-risk changes with canary test tags. When the ontology adds the constraint of collision energy - APCI source exclusive range 50-400℃, the affected probe P001 is located through bidirectional mapping, the verification rules of the verification probe are modified, the family probe package is updated to V2.1 after incremental compilation, and full deployment is carried out after verification on 10% of the test dataset; among them, the collision energy - APCI source exclusive range 50-400℃ constraint is the core change.

[0022] Secondly, the intermediate representation between the ontology and the probe is the compilation and family-based orchestration system, including: Data acquisition module: used to acquire multi-source metadata data of a preset mass spectrometer and preprocess the multi-source metadata; the multi-source metadata includes Feature extraction and field mapping module: This module is used to input the multi-source metadata into the OWL parser to extract core features, and to perform classification field mapping on the multi-source metadata according to context matching rules to obtain mapping relationships; the core features include metadata logical fields, candidate data source paths, constraints, and context labels; Intermediate representation generation and clustering module: used to generate probe intermediate representations for the metadata logical fields based on the mapping relationship and ontology constraints, and to cluster the probe intermediate representations according to instrument model, experimental method and application scenario to obtain family-based probe packages; the probe intermediate representation includes probe type, operator, priority and license label; Bidirectional mapping and incremental compilation module: used to establish a bidirectional mapping between the ontology and the family probe package. When the ontology changes, the intermediate representation of the probe is incrementally compiled according to the bidirectional mapping to obtain the arrangement result; the changes include adding fields and modifying constraints.

[0023] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for compiling and familiarizing representations between the ontology and probe, characterized in that: Includes the following steps: Collect multi-source metadata data from a preset mass spectrometer, and preprocess the multi-source metadata; the multi-source metadata includes manufacturer original files, open format files, and experimental management system data; The multi-source metadata is input into the OWL parser to extract core elements, and the multi-source metadata is classified and mapped according to the context matching rules to obtain the mapping relationship; the core elements include metadata logical fields, candidate data source paths, constraints, and context labels; Based on the mapping relationship and ontology constraints, a probe intermediate representation is generated for the metadata logical fields. The probe intermediate representation is then clustered according to the instrument model, experimental method, and application scenario to obtain a family of probe packages. The probe intermediate representation includes probe type, operator, priority, and license label. A bidirectional mapping is established between the ontology and the family of probe packages. When the ontology changes, the intermediate representation of the probes is incrementally compiled according to the bidirectional mapping to obtain the arrangement result. The changes include adding fields and modifying constraints.

2. The ontology-to-probe intermediate representation compilation and family arrangement method according to claim 1, characterized in that, A method for obtaining mapping relationships by classifying fields of the multi-source metadata according to context matching rules includes: The data source type of multi-source metadata is identified by file header keywords or API response headers. The data source paths of multi-source metadata are sorted based on the multi-source path priority mechanism. The mapping template is automatically called according to the instrument model, experimental method and data source type. The multi-source path priority mechanism sorts the data source paths according to the dual dimensions of reliability and scenario matching when the same logical field has multiple data source paths, and sets the priority. Filter fields related to the current data source based on metadata logical fields, and locate the physical storage location using path expressions in the template; Read the context tags of the metadata, filter out the mismatched paths, sort the remaining paths according to the priority mechanism, and keep the top 3 high priority paths; Based on whether the physical field exists and whether the data type matches the path, the mapping relationship corresponding to the matching path is used as the verification mapping relationship; Conversely, by inputting multi-source metadata into the multimodal anomaly detection model to obtain anomaly identification data, and by using the context labels extracted during the ontology parsing stage to dynamically adjust the verification strategy, the Big Language Model-A algorithm is used to locate invalid paths, and logical fields and data type knowledge graphs are used to locate data type conflicts. For invalid paths: Input the context label corresponding to the invalid path into the Big Prophet model to generate a new path. Use a landmark segmentation search strategy to decompose the long path into multiple sub-paths. Use the A algorithm to verify the validity of each sub-path one by one. Then, concatenate the sub-paths to obtain a complete and valid path. To address data type conflicts: For numeric fields, BoostClean's mean / median fill is used; for categorical fields, ontology-driven repair is performed using semantic similarity recommendation based on word-direction variables. When a constraint conflict is detected, the repair rules defined in the ontology are automatically invoked to obtain the repaired data type. Output the mapping relationship between the complete and valid path and the data type to be repaired, and the verification mapping relationship.

3. The ontology-to-probe intermediate representation compilation and family arrangement method according to claim 1, characterized in that, A method for generating probe intermediate representations for the metadata logical fields based on the mapping relationship and ontology constraints includes: The mapping relationship and ontology constraints are preprocessed and parameters are initialized. The three highest priority data source paths are selected from the mapping relationship, and operators are matched for each path based on data type and path characteristics to generate extraction logic description and execution priority, thus obtaining extraction probes. Among them, text / numeric fields are selected by taking the first valid value and the average value of multiple sources, and enumeration fields are selected by precisely matching the preset enumeration value. Based on ontology constraints, basic verification rules are generated, supplemented with domain knowledge verification, and verification probes are generated by configuring anomaly handling strategies. Anomaly detection is triggered when fields marked as deprecated in the ontology or fields with mutual exclusion relationships are combined. Negative probes are generated by defining prohibition modes and configuring response actions. Weights are assigned based on contextualized labels. Multiple probes for the same logical field are sorted as extraction probes, verification probes, and negative probes. When the extracted values ​​from different paths are inconsistent, a conflict resolution strategy is activated. The conflict resolution strategy includes prioritizing high-reliability paths and arbitrating domain rules. The extraction probe is at level three, the verification probe at level four, and the negative probe at level five. Duplicate probes are merged, with the number of single-field probes limited to 5 or less. A two-layer verification mechanism is used to verify the final probe and output it as an intermediate probe representation. The multi-layer verification mechanism includes rule verification and scenario simulation. The intermediate probe representation includes basic information, probe type and function, data source path list, operators and parameters, constraint rule set, context label and priority.

4. The ontology-to-probe intermediate representation compilation and family arrangement method according to claim 1, characterized in that, A method for clustering the intermediate representations of probes according to instrument model, experimental method, and application scenario to obtain family-based probe packages includes: The context labels are layered according to instrument attributes, experimental characteristics, and scenario requirements to form feature vectors, resulting in a three-level label structure. The importance of the context labels is calculated using the entropy weight method. The first clustering is performed based on the primary labels to generate a manufacturer-model-specific basic family; the basic family is then clustered a second time based on the secondary and tertiary labels, and differential probes are added. A priority-ordering communication learning algorithm is introduced to transform probe rule conflicts into a priority decision problem. Each probe is defined with 5-dimensional priority features, including ontology constraint strength, data reliability, and scene specificity. By simulating learning and training a priority model, the probe feature vector is input into the priority model to obtain real-time priority ranking. Clustering is continuously optimized until the rule conflicts that the priority mechanism has not resolved are less than or equal to the conflict threshold, the probe coverage of the family package in the target scene is greater than or equal to the coverage threshold, and the reuse rate of the basic family probe in the incremental scene is greater than or equal to the reuse threshold. When a new field is added to the ontology or the experimental method is changed, incremental clustering is performed on the changed probes, and the priority of the conflict rules is recalculated through the priority model to generate a new incremental version package.

5. The method for compiling and family-based arrangement of intermediate representations from ontology to probe according to claim 1, characterized in that, A method for establishing a bidirectional mapping between the ontology and the family of probe packages includes: Establish a precise correspondence between ontology logical fields and probe intermediate representations, bind ontology constraints to probe validation rules, and automatically synchronize the data type and value range attributes of the corresponding probe when the data type and value range constraints in the ontology change. Monitor the ontology version control system, identify ontology changes, associate ontology applicable scenarios with probe families through context tags, and classify ontology changes into core changes and non-core changes. Only core changes trigger probe system updates; core changes include adding / deleting fields and modifying key constraints; non-core changes include adjusting descriptive text and supplementing examples. Based on the feature mapping table, the affected probe families, probe IDs and specific attributes are calculated, the affected probes are compiled, and preset rules are automatically applied to resolve conflicts. Based on the feature mapping relationship, the system automatically identifies the affected probe families and specific probes, sorts the affected probes into core field probes, scenario-specific probes, and general probes, prioritizes the compilation of probes for key scenarios, and shortens the update window period. When probe rule conflicts are caused by ontology changes, basic conflict rules are defined. For conflicts that cannot be resolved automatically, a conflict report is generated and the conflict type, involved probe IDs, and suggested solutions are marked. After the conflict is resolved, the probe behavior is first verified in 10% of the test dataset. Only after it passes the verification is the full deployment completed.

6. The ontology-to-probe intermediate representation compilation and family arrangement method according to claim 1, characterized in that, A method for incrementally compiling the intermediate representation of the probe based on the bidirectional mapping to obtain an arrangement result includes: A three-layer bidirectional mapping of version, feature, and probe is constructed between the ontology and the probe family. The version mapping is between the ontology version and the probe family version; the feature mapping is between the logical fields in the ontology and the IDs represented by the probe, and the field types and dependencies are labeled; the constraint mapping is between the ontology constraints and the probe operators. The version control system automatically monitors changes to the system and categorizes them into three types based on their impact: core changes, extended changes, and minor changes. Extended changes include adding context tags and supplementing data source paths; minor changes include correcting field description text and optimizing tag levels. Based on bidirectional mapping, probe resources that are rapidly located to reflect the impact of changes are used. Core changes trigger a full update of the intermediate representation of associated probes; extended changes trigger an update of incremental probes for related scenarios; and minor changes trigger an update of documentation. For probe intermediate representations with a defined impact range, targeted updates are performed, including extracting the probe update data source path, verifying the probe to modify the verification rules, and adding anomaly detection logic to negative probes. The compiled probe intermediate representations are clustered by scenario to generate the final orchestration result.

7. An intermediate representation compilation and family-based orchestration system from the ontology to the probe, used to execute the method according to any one of claims 1-6, characterized in that, include: Data acquisition module: used to acquire multi-source metadata data of a preset mass spectrometer and preprocess the multi-source metadata data; The multi-source metadata includes Feature extraction and field mapping module: This module is used to input the multi-source metadata into the OWL parser to extract core features, and to perform classification field mapping on the multi-source metadata according to context matching rules to obtain mapping relationships; the core features include metadata logical fields, candidate data source paths, constraints, and context labels; Intermediate representation generation and clustering module: used to generate probe intermediate representations for the metadata logical fields based on the mapping relationship and ontology constraints, and to cluster the probe intermediate representations according to instrument model, experimental method and application scenario to obtain family-based probe packages; the probe intermediate representation includes probe type, operator, priority and license label; Bidirectional mapping and incremental compilation module: used to establish a bidirectional mapping between the ontology and the family probe package. When the ontology changes, the intermediate representation of the probe is incrementally compiled according to the bidirectional mapping to obtain the arrangement result; the changes include adding fields and modifying constraints.

Images