A Method and System for Semantic Interoperability of Heterogeneous Models Based on Ontology Metamodel
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-16
- Publication Date
- 2026-08-11
AI Technical Summary
[0004]为了解决当前跨环节、跨软件模型数据转换和传递依赖人工、效率低下、误差累积的问题,本申请提供了一种基于本体元模型的异构模型语义互操作方法及系统,代替人工或定制化规则进行跨环节、跨软件模型数据的高效转换、精准传递,大幅度提升了多软件集成设计仿真的效率和准确性
1、本申请提出了领域本体元模型构建方法,该方法通过将领域本体知识和元模型相结合,可以同时表达领域对象概念语义内涵,以及表示符号的构成规则,为实现异构模型互操作奠定了底层语义基础。
Smart Images

Figure CN122549045A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of modeling and simulation technology, and in particular to a method and system for semantic interoperability of heterogeneous models based on ontology meta-models. Background Technology
[0002] Interoperability technology initially refers to the ability of two or more systems to exchange and use information in information sharing and integration. It is widely applied to the integrated operation of heterogeneous and complex systems distributed over a wide area, such as digital libraries, intelligent transportation, smart grids, smart healthcare, smart cities, and information systems, as well as the sharing of massive amounts of information. In the field of modeling and simulation, multiple different types of software often need to be used collaboratively. These different types of software have completely different technical approaches, syntax rules, and underlying logic definitions. Coupled with differences in user level and modeling skills, serious model data conversion and transfer problems arise when integrating and designing simulations with multiple software programs.
[0003] Currently, in the field of modeling and simulation, the integration and interoperability between different types of software are very low. From the requirements analysis stage to the system design stage, and then to the system functional performance simulation and verification stage, cross-stage model data transfer can only be carried out manually in document form, or customized data transfer rules are set for specific use cases to transfer partial model data. This leads to problems such as repetitive modeling and the accumulation of errors from manual transfer. At its core, this is due to the lack of a unified standard for model semantics in the field, as well as the technical means to support the automatic conversion and transfer of model data across stages and across software. Summary of the Invention
[0004] To address the current problems of reliance on manual labor, low efficiency, and error accumulation in cross-process and cross-software model data conversion and transfer, this application provides a heterogeneous model semantic interoperability method and system based on ontology meta-models. This method replaces manual labor or customized rules for efficient conversion and accurate transfer of cross-process and cross-software model data, significantly improving the efficiency and accuracy of multi-software integrated design simulation.
[0005] This application discloses a heterogeneous model semantic interoperability method based on ontology meta-model, which includes: Step 1: Collect conceptual terms for domain generic objects. Using these conceptual terms as a comparison benchmark, extract metamodel specifications from the software to be integrated. Filter the metamodel specifications to obtain all metamodel content corresponding to the domain generic objects. Based on the attribute items and relationships in all metamodel content, construct attribute tables and relationship tables. Based on the attribute tables and relationship tables, obtain the domain ontology metamodel. Step 2: Based on the global semantic mapping configuration, generate a query template for model instance data and construct a model rendering template; Step 3: Load the query template to query the model instance database, obtain triple data, query the mapping registry based on the triple data, and complete the explicit assignment of the memory instance; if the ontology metamodel corresponding to the successfully instantiated memory object has a corresponding mapping path, then mark the memory object with a reuse mapping tag. Step 4: Generate the corresponding target ID for the memory object instance with the reuse mapping tag, register the type URI and target ID of the memory object instance to the global identifier dictionary, extract the type URIs of the two memory object instances connected by the relationship of each memory object instance, i.e. the source object URI and the destination object URI, query the global identifier dictionary to obtain the corresponding target ID, and perform topological stitching of the code text of the two memory object instances based on the corresponding target ID to generate a model file usable by the target software.
[0006] Further, step 1 includes: Step 11: Collect conceptual terms for domain generic objects from relevant documents, including domain literature, product manuals, and textbooks. Using conceptual terms as a comparison benchmark, extract metamodel specifications from requirements management software, architecture design software, and functional performance simulation software. Calculate the semantic similarity between the metamodel specifications of each software and the names of the domain generic objects, extract all metamodels related to the domain generic objects, and then submit them to business personnel for review to obtain all metamodel content associated with the domain generic objects. Step 12: Abstract and summarize the attribute items and relationships of all metamodel content associated with the domain generic object; the abstraction and summarization of attribute items includes attribute name, English name, value type, value length, and description; the abstraction and summarization of relationships includes relationship type, source object name, and destination object name. Step 13: Based on attribute items and relationships, construct the domain ontology metamodel step by step according to relevant categories, around requirements analysis, architecture design and simulation. The final presentation of the domain metamodel is several attribute tables and relationship tables. The attribute table is used to record attribute name, value type and value length, and the relationship table is used to record relationship type, source object name and destination object name. Relevant categories include requirements, structure, behavior, parameters and relationships.
[0007] Furthermore, in step 2, the global semantic mapping configuration includes the mapping between the domain ontology metamodel and various software heterogeneous models, and the mapping between the ontology metamodel and heterogeneous model instance data. The mapping between the ontology metamodel and various software heterogeneous models is used to define the names and absolute paths of the ontology metamodel and various software heterogeneous models. The mapping between the ontology metamodel and heterogeneous model instance data refers to the mapping between the ontology metamodel and the instance data generated by each heterogeneous model, including three types: subject mapping, attribute mapping, and relation mapping.
[0008] Furthermore, the subject mapping maps the classes / subclasses of the domain ontology metamodel to the type URIs in the model instance data; the attribute mapping maps the attribute names of the domain ontology metamodel to the attribute predicates in the model instance data; and the relation mapping maps the relation names of the domain ontology metamodel to the relation predicates in the model instance data.
[0009] Furthermore, the query template for generating model instance data based on the global semantic mapping configuration includes: The root variable is set to refer to the instance to be queried. The type URI in the global semantic mapping configuration is read to generate type constraints. The extraction rules in the global semantic mapping configuration are traversed. The attribute relationship identifier and binding variable in the extraction rules are concatenated to obtain the attribute and relationship triple pattern. All binding variables defined in the global semantic mapping configuration are automatically extracted and put into the selected clause. The type constraints, attribute and relationship triple pattern are put into the condition limiting clause to obtain the query template of the model instance data.
[0010] Furthermore, the construction of the model rendering template includes: Code generation templates for heterogeneous model file formats in various software are determined. The code generation templates define the topological layout format of heterogeneous model files at the text level. The topological layout format of heterogeneous model files at the text level includes nested logic and hierarchical indentation, script whitespace rules, and dynamic placeholders for loading memory object instance attribute parameters.
[0011] Further, step 3 includes: Step 31: Load the query template to query the model instance database and obtain the required triplet data; Step 32: Parse the global semantic mapping configuration, extract all mapping relationships between the type URI in the model instance data and the class / subclass in the ontology metamodel, and write all mapping relationships into the mapping registry in memory using a hash table to complete the dynamic initialization of the mapping registry; Step 33: When processing the triplet data obtained in Step 31, first filter out declarative triplets whose predicates have preset values, extract the object of the triplet, i.e., the type URI, query the mapping registry to determine the class / subclass in the corresponding ontology metamodel; after successful type matching, allocate space in memory, dynamically create the corresponding memory instance according to the definition of the class / subclass in the ontology metamodel, use the memory instance as the subject to process other triplet data, query the mapping registry again according to the predicate of the triplet to locate the corresponding attribute name in the ontology metamodel, fill the attribute value in the triplet into the corresponding attribute in the memory instance, and complete the explicit assignment; Step 34: Complete all deserialization processes. For each successfully instantiated memory object, reverse the process by checking the mapping paths of various software heterogeneous models through its corresponding ontology metamodel. If a corresponding mapping path is found, then mark the memory object with a reuse mapping tag.
[0012] Furthermore, the completion of all deserialization processes includes: When processing unordered triple data streams, if the associated object data has not been parsed and instantiated, a temporary proxy object is created that only stores the corresponding type Uniform Resource Identifier and matches the corresponding object interface, and a temporary reference relationship between objects is established. After processing all triple data streams, all reference relationships in memory are traversed. Once a proxy object is found, its internal type URI is extracted to retrieve the real object. After a successful retrieval, the proxy object is replaced by the memory pointer of the real object. Thus, the entire deserialization process is completed.
[0013] Further, step 4 includes: Step 41: Iterate through each memory object instance in turn and check whether it has a reuse mapping tag. If it has a reuse mapping tag, it means that the ontology metamodel-various software heterogeneous model mapping has been configured and the target software model rendering begins; if it does not have a reuse mapping tag, skip it and continue iterating. Step 42: For memory object instances with reused mapping tags, call the code generation template in the target software model file format, read the attribute parameters in the memory object instance, and inject them into various placeholders pre-set in the template; Step 43: Initialize a global identifier dictionary in memory to maintain the mapping between the type URIs of memory object instances and the target software model identifiers or physical paths; Perform the first scan: Perform a complete scan of all memory object instances. For memory object instances with reuse mapping tags, generate a target ID according to the constraints of each software metamodel specification, and register <memory object instance type URI, target ID> in the global identifier dictionary; Perform the second scan: Scan only the relationships of all memory object instances. For the scanned relationships, extract the type URIs of the two memory object instances connected by the relationship, and denot them as the source object URI and the destination object URI, respectively. Query the global identifier dictionary with the source object URI and the destination object URI to obtain the corresponding target IDs, denoted as target ID_Source and target ID_Target; Follow the constraints of each software metamodel specification to perform topological stitching of the code text of two isolated memory object instances to generate a model file usable by the target software.
[0014] This application also discloses a heterogeneous model semantic interoperability system based on an ontology meta-model, which implements the above-described method and includes: The model building module is used to collect conceptual terms of domain generic objects, extract metamodel specifications from the software to be integrated using the conceptual terms as a comparison benchmark, filter all metamodel content corresponding to the domain generic objects from the metamodel specifications, construct attribute tables and relation tables based on the attribute items and relations in all metamodel content, and obtain the domain ontology metamodel based on the attribute tables and relation tables. The semantic mapping module is used to generate query templates for model instance data and construct model rendering templates based on the global semantic mapping configuration. The data processing module is used to load the query template query model instance database, obtain triple data, query the mapping registry based on the triple data, and complete the explicit assignment of the memory instance; if the ontology metamodel corresponding to the successfully instantiated memory object has a corresponding mapping path, then the memory object is tagged with a reuse mapping tag. The model file generation module is used to generate corresponding target IDs for memory object instances with reuse mapping tags, register the type URI and target ID of the memory object instance in the global identifier dictionary, extract the type URIs of the two memory object instances connected by the relationship of each memory object instance, namely the source object URI and the destination object URI, query the global identifier dictionary to obtain the corresponding target ID, and perform topological stitching of the code text of the two memory object instances based on the corresponding target ID to generate a model file usable by the target software.
[0015] Due to the adoption of the above technical solution, this application has the following advantages: 1. This application proposes a method for constructing a domain ontology metamodel. This method combines domain ontology knowledge with the metamodel, which can simultaneously express the semantic connotation of domain object concepts and the rules for the composition of representation symbols, laying the underlying semantic foundation for achieving interoperability of heterogeneous models.
[0016] 2. This application proposes a semantic mapping method based on ontology metamodel. This method allows engineers to build mapping rules for the entire project without having to deal with specific project data. When the target software model path or software syntax changes, engineers do not need to modify or recompile the underlying code, but only need to adjust the external configuration file.
[0017] 3. This application proposes a cross-software model data extraction and deserialization method, which realizes the crossing and conversion of loosely structured, mesh-like triple data to a strongly typed, tree-like data structure with strict parent-child hierarchy and reference constraints available in the model file.
[0018] 4. This application proposes a method for rendering and topology stitching of target software model files. This method "reduces the dimensionality" of high-dimensional memory object instances in memory into low-level code that the target software can directly execute, effectively reducing the workload of manual coding. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.
[0020] Figure 1 This is a flowchart illustrating a heterogeneous model semantic interoperability method based on an ontology meta-model, according to an embodiment of this application.
[0021] Figure 2 This is a flowchart of a domain ontology metamodel construction method according to an embodiment of this application.
[0022] Figure 3 This is a schematic diagram illustrating the semantic mapping technology based on ontology meta-model in an embodiment of this application.
[0023] Figure 4 This is a schematic diagram illustrating the principle of cross-software model data extraction and deserialization technology in an embodiment of this application.
[0024] Figure 5 This is a schematic diagram illustrating the target software model file rendering and topology stitching technology in an embodiment of this application.
[0025] Figure 6 This is a flowchart illustrating another heterogeneous model semantic interoperability method based on ontology meta-model, as an embodiment of this application. Detailed Implementation
[0026] The present application will be further described in conjunction with the accompanying drawings and embodiments. The described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of the present application.
[0027] See Figure 6 This application provides an embodiment of a heterogeneous model semantic interoperability method based on an ontology meta-model, which includes: Step 1: Collect conceptual terms for domain generic objects. Using these conceptual terms as a comparison benchmark, extract metamodel specifications from the software to be integrated. Filter the metamodel specifications to obtain all metamodel content corresponding to the domain generic objects. Based on the attribute items and relationships in all metamodel content, construct attribute tables and relationship tables. Based on the attribute tables and relationship tables, obtain the domain ontology metamodel. Step 2: Based on the global semantic mapping configuration, generate a query template for model instance data and construct a model rendering template; Step 3: Load the query template to query the model instance database, obtain triple data, query the mapping registry based on the triple data, and complete the explicit assignment of the memory instance; if the ontology metamodel corresponding to the successfully instantiated memory object has a corresponding mapping path, then mark the memory object with a reuse mapping tag. Step 4: Generate the corresponding target ID for the memory object instance with the reuse mapping tag, register the type URI and target ID of the memory object instance to the global identifier dictionary, extract the type URIs of the two memory object instances connected by the relationship of each memory object instance, i.e. the source object URI and the destination object URI, query the global identifier dictionary to obtain the corresponding target ID, and perform topological stitching of the code text of the two memory object instances based on the corresponding target ID to generate a model file usable by the target software.
[0028] Optionally, step 1 includes: Step 11: Collect conceptual terms for domain generic objects from relevant documents, including domain literature, product manuals, and textbooks. Using conceptual terms as a comparison benchmark, extract metamodel specifications from requirements management software, architecture design software, and functional performance simulation software. Calculate the semantic similarity between the metamodel specifications of each software and the names of the domain generic objects, extract all metamodels related to the domain generic objects, and then submit them to business personnel for review to obtain all metamodel content associated with the domain generic objects. Step 12: Abstract and summarize the attribute items and relationships of all metamodel content associated with the domain generic object; the abstraction and summarization of attribute items includes attribute name, English name, value type, value length, and description; the abstraction and summarization of relationships includes relationship type, source object name, and destination object name. Step 13: Based on attribute items and relationships, construct the domain ontology metamodel step by step according to relevant categories, around requirements analysis, architecture design and simulation. The final presentation of the domain metamodel is several attribute tables and relationship tables. The attribute table is used to record attribute name, value type and value length, and the relationship table is used to record relationship type, source object name and destination object name. Relevant categories include requirements, structure, behavior, parameters and relationships.
[0029] Optionally, in step 2, the global semantic mapping configuration includes the mapping between the domain ontology metamodel and various software heterogeneous models, and the mapping between the ontology metamodel and heterogeneous model instance data. The mapping between the ontology metamodel and various software heterogeneous models is used to define the names and absolute paths of the ontology metamodel and various software heterogeneous models. The mapping between the ontology metamodel and heterogeneous model instance data refers to the mapping between the ontology metamodel and the instance data generated by each heterogeneous model, including three types: subject mapping, attribute mapping, and relation mapping.
[0030] Optionally, the subject mapping maps the classes / subclasses of the domain ontology metamodel to the type URIs in the model instance data; the attribute mapping maps the attribute names of the domain ontology metamodel to the attribute predicates in the model instance data; and the relation mapping maps the relation names of the domain ontology metamodel to the relation predicates in the model instance data.
[0031] Optionally, the step of generating a query template for model instance data based on the global semantic mapping configuration includes: The root variable is set to refer to the instance to be queried. The type URI in the global semantic mapping configuration is read to generate type constraints. The extraction rules in the global semantic mapping configuration are traversed. The attribute relationship identifier and binding variable in the extraction rules are concatenated to obtain the attribute and relationship triple pattern. All binding variables defined in the global semantic mapping configuration are automatically extracted and put into the selected clause. The type constraints, attribute and relationship triple pattern are put into the condition limiting clause to obtain the query template of the model instance data.
[0032] Optionally, the construction of the model rendering template includes: Code generation templates for heterogeneous model file formats in various software are determined. The code generation templates define the topological layout format of heterogeneous model files at the text level. The topological layout format of heterogeneous model files at the text level includes nested logic and hierarchical indentation, script whitespace rules, and dynamic placeholders for loading memory object instance attribute parameters.
[0033] Optionally, step 3 includes: Step 31: Load the query template to query the model instance database and obtain the required triplet data; Step 32: Parse the global semantic mapping configuration, extract all mapping relationships between the type URI in the model instance data and the class / subclass in the ontology metamodel, and write all mapping relationships into the mapping registry in memory using a hash table to complete the dynamic initialization of the mapping registry; Step 33: When processing the triplet data obtained in Step 31, first filter out declarative triplets whose predicates have preset values, extract the object of the triplet, i.e., the type URI, query the mapping registry to determine the class / subclass in the corresponding ontology metamodel; after successful type matching, allocate space in memory, dynamically create the corresponding memory instance according to the definition of the class / subclass in the ontology metamodel, use the memory instance as the subject to process other triplet data, query the mapping registry again according to the predicate of the triplet to locate the corresponding attribute name in the ontology metamodel, fill the attribute value in the triplet into the corresponding attribute in the memory instance, and complete the explicit assignment; Step 34: Complete all deserialization processes. For each successfully instantiated memory object, reverse the process by checking the mapping paths of various software heterogeneous models through its corresponding ontology metamodel. If a corresponding mapping path is found, then mark the memory object with a reuse mapping tag.
[0034] Optionally, completing all deserialization processes includes: When processing unordered triple data streams, if the associated object data has not been parsed and instantiated, a temporary proxy object is created that only stores the corresponding type Uniform Resource Identifier and matches the corresponding object interface, and a temporary reference relationship between objects is established. After processing all triple data streams, all reference relationships in memory are traversed. Once a proxy object is found, its internal type URI is extracted to retrieve the real object. After a successful retrieval, the proxy object is replaced by the memory pointer of the real object. Thus, the entire deserialization process is completed.
[0035] Optionally, step 4 includes: Step 41: Iterate through each memory object instance in turn and check whether it has a reuse mapping tag. If it has a reuse mapping tag, it means that the ontology metamodel-various software heterogeneous model mapping has been configured and the target software model rendering begins; if it does not have a reuse mapping tag, skip it and continue iterating. Step 42: For memory object instances with reused mapping tags, call the code generation template in the target software model file format, read the attribute parameters in the memory object instance, and inject them into various placeholders pre-set in the template; Step 43: Initialize a global identifier dictionary in memory to maintain the mapping between the type URIs of memory object instances and the target software model identifiers or physical paths; Perform the first scan: Perform a complete scan of all memory object instances. For memory object instances with reuse mapping tags, generate a target ID according to the constraints of each software metamodel specification, and register <memory object instance type URI, target ID> in the global identifier dictionary; Perform the second scan: Scan only the relationships of all memory object instances. For the scanned relationships, extract the type URIs of the two memory object instances connected by the relationship, and denot them as the source object URI and the destination object URI, respectively. Query the global identifier dictionary with the source object URI and the destination object URI to obtain the corresponding target IDs, denoted as target ID_Source and target ID_Target; Follow the constraints of each software metamodel specification to perform topological stitching of the code text of two isolated memory object instances to generate a model file usable by the target software.
[0036] This application also provides an embodiment of a heterogeneous model semantic interoperability system based on an ontology metamodel, which implements the methods described in the above embodiments, and includes: The model building module is used to collect conceptual terms of domain generic objects, extract metamodel specifications from the software to be integrated using the conceptual terms as a comparison benchmark, filter all metamodel content corresponding to the domain generic objects from the metamodel specifications, construct attribute tables and relation tables based on the attribute items and relations in all metamodel content, and obtain the domain ontology metamodel based on the attribute tables and relation tables. The semantic mapping module is used to generate query templates for model instance data and construct model rendering templates based on the global semantic mapping configuration. The data processing module is used to load the query template query model instance database, obtain triple data, query the mapping registry based on the triple data, and complete the explicit assignment of the memory instance; if the ontology metamodel corresponding to the successfully instantiated memory object has a corresponding mapping path, then the memory object is tagged with a reuse mapping tag. The model file generation module is used to generate corresponding target IDs for memory object instances with reuse mapping tags, register the type URI and target ID of the memory object instance in the global identifier dictionary, extract the type URIs of the two memory object instances connected by the relationship of each memory object instance, namely the source object URI and the destination object URI, query the global identifier dictionary to obtain the corresponding target ID, and perform topological stitching of the code text of the two memory object instances based on the corresponding target ID to generate a model file usable by the target software.
[0037] For ease of understanding, this application provides a more specific embodiment: Reference Figure 1 The method described in this application is described in detail.
[0038] Step 1: Construct the domain ontology metamodel.
[0039] Reference Figure 2 This paper provides a further detailed description of the domain ontology metamodel construction method of this application.
[0040] Step 1.1: Collection of conceptual terms for general objects in the field. Conceptual terms for general objects in the field are collected from sources such as literature, product manuals, and textbooks. Taking the aircraft manufacturing field as an example, the conceptual terms for general objects in this field include classification dimensions such as aircraft platform, sensing system, communication system, navigation system, atmospheric environment, electromagnetic environment, functional performance indicators, behavior, and operation. The collection of conceptual terms is a long-term and continuous process, and can be flexibly adjusted according to other classification dimensions without affecting subsequent steps at the implementation level. This application only lists one collection dimension.
[0041] Step 1.2, Extraction of Software Metamodel Specifications. For each software to be integrated (including requirements management software, architecture design software, and functional performance simulation software in this application), the metamodel specifications for each software are extracted according to the results of the domain-specific object concept terminology collection in Step 1.1. For example, for a communication system, metamodel specifications are extracted simultaneously from the requirements management software, architecture design software, and functional performance simulation software to obtain a full-dimensional representation of the communication system in each software. Since the metamodels used by the requirements management software, architecture design software, and functional performance simulation software are different, and their object definitions and syntax rules are also different, this step first uses semantic similarity calculation to perform semantic similarity calculation between the documentation of each software metamodel specification and the specific name of the communication system, extracting all metamodels related to the communication system, and then submitting them to business personnel for review to obtain all metamodel content associated with the communication system.
[0042] Step 1.3, Domain Ontology Abstraction and Summarization. After obtaining all the metamodel content of the domain generic object in Step 1.2, the attribute items and relations of the generic object are abstracted and summarized respectively. The abstraction and summarization of attribute items includes attribute name, English name, value type, value length, and description; the abstraction and summarization of relations includes relation type, source object name, and destination object name. In this step, if the same attribute item of the same object has different names, value types, value lengths, etc. (this is because different software technical routes, syntax rules, and underlying logic definitions vary, and their metamodels cannot be completely consistent), then the business personnel will provide a standardized definition for the attribute item name and value type, while the value length will be the maximum value among the metamodels.
[0043] Step 1.4, Domain Ontology Metamodel Construction. The abstraction and summarization results of attribute items and relationships in Step 1.3 are further refined and integrated. Focusing on the stages of requirements analysis, architecture design, and simulation, the domain ontology metamodel is constructed hierarchically according to five categories: requirements, structure, behavior, parameters, and relationships. The final presentation of the domain metamodel consists of several attribute tables and relationship tables. Taking the requirements ontology metamodel as an example, this category is further refined into subcategories such as purpose, capability, system requirements, system design requirements, and product design requirements. The "system design requirements" category includes five attribute tables: system functional requirements, system performance requirements, system interface requirements, general quality characteristic requirements, and test verification requirements. The system functional requirements attribute table and the system performance requirements attribute table are shown in Table 1 and Table 2, respectively.
[0044] Table 1 System Functional Requirements Attribute Table
[0045] Table 2 System Performance Requirements Attribute Table
[0046] Meanwhile, taking the capabilities, system requirements, system design requirements, and product design requirements within the demand-type ontology metamodel as examples, their relationship table is shown in Table 3.
[0047] Table 3 Relationship Table
[0048] Step 2, semantic mapping based on ontology meta-model.
[0049] Reference Figure 3 This paper provides a further detailed description of the semantic mapping method based on ontology meta-model in this application.
[0050] Step 2.1, Global Semantic Mapping Configuration Definition. The global semantic mapping configuration definition includes two aspects: ontology metamodel-various software heterogeneous model mapping, and ontology metamodel-heterogeneous model instance data mapping.
[0051] The ontology metamodel-various software heterogeneous model mapping mainly defines the names and absolute paths of the ontology metamodel and various software heterogeneous models. For example, a certain element in the ontology metamodel maps to which model names in the requirements management software, architecture design software, and functional performance simulation software, as well as the model paths in these software (such as the .jl library path in the functional performance simulation software).
[0052] Ontology metamodel-heterogeneous model instance data mapping refers to the mapping between the ontology metamodel and the instance data generated by various heterogeneous models, including three types: subject mapping, attribute mapping, and relationship mapping.
[0053] Subject Mapping: Maps classes / subclasses in the ontology metamodel (named TargetEClass in the global semantic mapping configuration) to type URIs in the model instance data (named RDFTypeURI in the global semantic mapping configuration). For example, mapping "weather radar" in the ontology metamodel (assigned RadarNode in the global semantic mapping configuration) to <RDF resource interface address of weather radar> in the instance data; Attribute mapping: Maps attribute names in the ontology metamodel (named TargetAttribute in the global semantic mapping configuration) to attribute predicates in the model instance data (named RDFPredicate in the global semantic mapping configuration). For example, mapping "working frequency" in the ontology metamodel (assigned the value frequency in the global semantic mapping configuration) to <RDF resource interface address of working frequency> in the instance data; Relation Mapping: Maps relation names in the ontology metamodel (named TargetReference in the global semantic mapping configuration) to relation predicates in the model instance data (named RDFPredicate in the global semantic mapping configuration). For example, mapping the "control relation" in the ontology metamodel (assigned the value controlledBy in the global semantic mapping configuration) to the <RDF resource interface address of the control relation> in the instance data.
[0054] The following is an example of an ontology metamodel-heterogeneous model instance data mapping fragment.
[0055] ComponentMapping: TargetEClass: "RadarNode" RDFTypeURI: "<RDF resource interface address of weather radar>" Extraction Rules: - TargetAttribute: "frequency" RDFPredicate: "<RDF resource interface address for operating frequency>" BindVariable: "?freq" - TargetReference: "controlledBy" RDFPredicate: "<RDF resource interface address of the control relationship>" BindVariable: "?ctrlNode Step 2.2, Dynamic Generation of Query Templates. This step dynamically generates query templates for model instance data based on the global semantic mapping configuration in Step 2.1. First, a root variable (e.g., ?s) is automatically generated to represent the instance to be queried; then, the RDFTypeURI in the global semantic mapping configuration is read to generate type constraints, i.e., ?sa<RDF resource interface address of the weather radar>; second, the ExtractionRules in the global semantic mapping configuration are traversed, and the RDFPredicate and BindVariable are used to concatenate the attribute and relation triplet schema, i.e.: ?s<RDF resource interface address at operating frequency>?freq. ?s<RDF resource interface address of the control relationship>?ctrlNode. Finally, all BindVariables defined in the global semantic mapping configuration are automatically extracted and placed into the SELECT clause; at the same time, the parsed type constraints, attribute and relation triplet patterns are placed into the WHERE clause, completing the dynamic assembly of the graph pattern query template.
[0056] The dynamically generated graph pattern matching query template in this step is shown below.
[0057] PREFIX rdf: <URL of the query template interface> SELECT ?s ?freq ?ctrlNode WHERE { # Type filtering: Precisely locate the instance to be queried ?sa<RDF resource interface address of weather radar>. # Attribute extraction pattern matching OPTIONAL { ?s<RDF resource interface address at operating frequency>?freq .} # Relationship Pattern Matching OPTIONAL { ?s<RDF resource interface address of the control relationship>?ctrlNode .} } Step 2.3, Model Rendering Template Development. Code generation templates are pre-written for heterogeneous model file formats in various software applications. These templates define in detail the topological layout format of heterogeneous model files at the text level, mainly including three settings: nesting logic and hierarchical indentation settings, special script whitespace rules settings, and dynamic placeholder settings for injected data (such as coordinates, state parameters, etc.).
[0058] Step 3: Cross-software model data extraction and deserialization.
[0059] Reference Figure 4 This paper provides a further detailed description of the cross-software model data extraction and deserialization method of this application.
[0060] Step 3.1, Precise Slicing Based on Graph Pattern Matching. The graph pattern matching query template obtained in Step 2.2 is loaded, and a query is initiated against the model instance database. Since the model instance database is a network-like database, the query process does not concern itself with the data hierarchy. Instead, graph pattern matching is used to find the "subgraphs" that match the template's preset values. Triples in the vast model instance database that do not match the template are directly filtered out. This step accurately obtains the required triplet data.
[0061] Step 3.2, Dynamic Initialization of the Mapping Registry. Before processing the triplet data obtained in Step 3.1, the global semantic mapping configuration in Step 2.1 is first parsed to extract all mapping relationships between the type URIs in the model instance data and the classes / subclasses in the ontology metamodel. These mapping relationships are then written into the mapping registry in memory using a hash table, thus completing the dynamic initialization of the mapping registry.
[0062] Step 3.3, Type Matching and Memory Instance Construction. When processing the triple data stream obtained in Step 3.1, declarative triples with the predicate "a" are first filtered out. The object (i.e., the type URI) of the triple is extracted, and the mapping registry from Step 3.2 is queried to determine the corresponding class / subclass in the ontology metamodel. After successful type matching, space is allocated in memory, and the corresponding memory instance is dynamically created according to the definition of the class / subclass in the ontology metamodel. However, at this time, the attribute values of these memory instances are temporarily in the default state of null or 0. Subsequently, the memory instance is used as the subject to process other triple data. Based on the predicate of the triple, the resource mapping registry is queried again to locate the corresponding TargetAttribute (i.e., the attribute name in the ontology metamodel). The attribute values in the triple are filled into the corresponding attributes in the memory instance, completing the explicit assignment.
[0063] Step 3.4, closing the parsing loop based on the proxy object. Since triple data often arrives out of order when processing triple data streams, if data from object A arrives first, but a declaration in A connects to the type URI of object B, and object B's data hasn't been parsed and instantiated yet, a problem arises where a memory pointer cannot be established. Step 3.4 addresses this issue. The solution is to temporarily create a proxy object for object B in memory. This proxy object superficially implements object B's interface but internally only stores object B's type URI, maintaining the integrity of the data structure and ensuring that the reference relationship between object A and object B can be established even if object B's data is missing. For example, if object A is a ranging radar that needs to reference a laser ranging module (object B), a temporary reference relationship between the ranging radar and the laser ranging module can be established even before the actual data of the laser ranging module has been parsed and injected. After processing all triplet data streams, the system iterates through all reference relationships in memory. Upon finding a proxy object, its internal type URI is extracted for real object retrieval. If the retrieval is successful, the proxy object is replaced by the memory pointer of the real object, thus completing the entire deserialization process. Finally, for each successfully instantiated memory object, the system checks the mapping paths of various software heterogeneous models through its corresponding ontology metamodel. If a corresponding mapping path is found, the memory object is tagged with "reusable mapping".
[0064] Step 4: Rendering and topology stitching of the target software model file.
[0065] Reference Figure 5 The present application provides a further detailed description of the target software model file rendering and topology stitching method.
[0066] Step 4.1, Depth-first traversal and tag filtering. After step 3, each memory object instance will be traversed sequentially to check if it has the "reuse mapping" tag. If the tag is present, it means that the ontology metamodel-various software heterogeneous model mapping has been configured in step 2.1, and the target software model rendering will begin immediately; if the tag is absent, it will be skipped, and the traversal will continue downward.
[0067] Step 4.2, Template Parameter Semantic Instantiation. After step 4.1, for memory object instances with the "Reuse Mapping" tag, the code generation template in the target software model file format from step 2.3 is called to read the attribute parameters in the memory object instance and inject them into various placeholders pre-set in the template.
[0068] Step 4.3, Topological stitching based on global multi-pass scanning. Step 4.2 essentially renders and generates isolated code text segments, i.e., only the attribute values of memory object instances, but the relationships between memory objects have not yet been "filled" into the target software model file (this relationship is reflected in the target software model file as the connection logic between isolated code, such as sequential execution, subordinate relationships, hierarchical nesting, etc.). This step is divided into two scans. First, a global identifier dictionary is initialized in memory to maintain the mapping relationship between the type URI of memory object instances and the target software model identifier or physical path. In the first scan, all memory object instances obtained in Step 3 are fully scanned. For memory object instances with the "reuse mapping" tag, following the software metamodel specification constraints in Step 1.2 (specifically referring to the naming conventions in the target software), a target ID is generated for it, and <memory object instance type URI, target ID> is registered in the global identifier dictionary. The second scan only scans the relationships between all memory object instances. For each relationship, the type URIs of the two memory object instances connected by the relationship are extracted and denoted as Source_EObject_URI and Target_EObject_URI, respectively. The global identifier dictionary is then queried using Source_EObject_URI and Target_EObject_URI to obtain the corresponding target IDs, denoted as TargetID_Source and TargetID_Target. Finally, following the constraints of the software metamodel specifications (specifically the code logic specifications in the target software, such as ifelse and if then specifications), the isolated code text of the two memory object instances is topologically stitched together to generate a model file usable by the target software.
[0069] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of the claims of this application.
Claims
1. A method for semantic interoperability of heterogeneous models based on ontology meta-models, characterized in that, include: Step 1: Collect conceptual terms for domain generic objects. Using these conceptual terms as a comparison benchmark, extract metamodel specifications from the software to be integrated. Filter the metamodel specifications to obtain all metamodel content corresponding to the domain generic objects. Based on the attribute items and relationships in all metamodel content, construct attribute tables and relationship tables. Based on the attribute tables and relationship tables, obtain the domain ontology metamodel. Step 2: Based on the global semantic mapping configuration, generate a query template for model instance data and construct a model rendering template; Step 3: Load the query template to query the model instance database, obtain triple data, query the mapping registry based on the triple data, and complete the explicit assignment of the memory instance; if the ontology metamodel corresponding to the successfully instantiated memory object has a corresponding mapping path, then mark the memory object with a reuse mapping tag. Step 4: Generate the corresponding target ID for the memory object instance with the reuse mapping tag, register the type URI and target ID of the memory object instance to the global identifier dictionary, extract the type URIs of the two memory object instances connected by the relationship of each memory object instance, i.e. the source object URI and the destination object URI, query the global identifier dictionary to obtain the corresponding target ID, and perform topological stitching of the code text of the two memory object instances based on the corresponding target ID to generate a model file usable by the target software.
2. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 1, characterized in that, Step 1 includes: Step 11: Collect conceptual terms for domain generic objects from relevant documents, including domain literature, product manuals, and textbooks. Using conceptual terms as a comparison benchmark, extract metamodel specifications from requirements management software, architecture design software, and functional performance simulation software. Calculate the semantic similarity between the metamodel specifications of each software and the names of the domain generic objects, extract all metamodels related to the domain generic objects, and then submit them to business personnel for review to obtain all metamodel content associated with the domain generic objects. Step 12: Abstract and summarize the attribute items and relationships of all metamodel content associated with the domain generic object; the abstraction and summarization of attribute items includes attribute name, English name, value type, value length, and description; the abstraction and summarization of relationships includes relationship type, source object name, and destination object name. Step 13: Based on attribute items and relationships, construct the domain ontology metamodel step by step according to relevant categories, around requirements analysis, architecture design and simulation. The final presentation of the domain metamodel is several attribute tables and relationship tables. The attribute table is used to record attribute name, value type and value length, and the relationship table is used to record relationship type, source object name and destination object name. Relevant categories include requirements, structure, behavior, parameters and relationships.
3. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 2, characterized in that, In step 2, the global semantic mapping configuration includes the mapping between the domain ontology metamodel and various software heterogeneous models, and the mapping between the ontology metamodel and heterogeneous model instance data. The mapping between the ontology metamodel and various software heterogeneous models is used to define the names and absolute paths of the ontology metamodel and various software heterogeneous models. The mapping between the ontology metamodel and heterogeneous model instance data refers to the mapping between the ontology metamodel and the instance data generated by each heterogeneous model, including three types: subject mapping, attribute mapping, and relation mapping.
4. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 3, characterized in that, The subject mapping maps classes / subclasses in the domain ontology metamodel to type URIs in the model instance data; the attribute mapping maps attribute names in the domain ontology metamodel to attribute predicates in the model instance data; and the relation mapping maps relation names in the domain ontology metamodel to relation predicates in the model instance data.
5. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 1, characterized in that, The query template for generating model instance data based on the global semantic mapping configuration includes: The root variable is set to refer to the instance to be queried. The type URI in the global semantic mapping configuration is read to generate type constraints. The extraction rules in the global semantic mapping configuration are traversed. The attribute relationship identifier and binding variable in the extraction rules are concatenated to obtain the attribute and relationship triple pattern. All binding variables defined in the global semantic mapping configuration are automatically extracted and put into the selected clause. The type constraints, attribute and relationship triple pattern are put into the condition limiting clause to obtain the query template of the model instance data.
6. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 1, characterized in that, The construction of the model rendering template includes: Code generation templates for heterogeneous model file formats in various software are determined. The code generation templates define the topological layout format of heterogeneous model files at the text level. The topological layout format of heterogeneous model files at the text level includes nested logic and hierarchical indentation, script whitespace rules, and dynamic placeholders for loading memory object instance attribute parameters.
7. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 1, characterized in that, Step 3 includes: Step 31: Load the query template to query the model instance database and obtain the required triplet data; Step 32: Parse the global semantic mapping configuration, extract all mapping relationships between the type URI in the model instance data and the class / subclass in the ontology metamodel, and write all mapping relationships into the mapping registry in memory using a hash table to complete the dynamic initialization of the mapping registry; Step 33: When processing the triplet data obtained in Step 31, first filter out declarative triplets whose predicates have preset values, extract the object of the triplet, i.e., the type URI, query the mapping registry to determine the class / subclass in the corresponding ontology metamodel; after successful type matching, allocate space in memory, dynamically create the corresponding memory instance according to the definition of the class / subclass in the ontology metamodel, use the memory instance as the subject to process other triplet data, query the mapping registry again according to the predicate of the triplet to locate the corresponding attribute name in the ontology metamodel, fill the attribute value in the triplet into the corresponding attribute in the memory instance, and complete the explicit assignment; Step 34: Complete all deserialization processes. For each successfully instantiated memory object, reverse the process by checking the mapping paths of various software heterogeneous models through its corresponding ontology metamodel. If a corresponding mapping path is found, then mark the memory object with a reuse mapping tag.
8. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 7, characterized in that, The completion of all deserialization processes includes: When processing unordered triple data streams, if the associated object data has not been parsed and instantiated, a temporary proxy object is created that only stores the corresponding type Uniform Resource Identifier and matches the corresponding object interface, and a temporary reference relationship between objects is established. After processing all triple data streams, all reference relationships in memory are traversed. Once a proxy object is found, its internal type URI is extracted to retrieve the real object. After a successful retrieval, the proxy object is replaced by the memory pointer of the real object. Thus, the entire deserialization process is completed.
9. The heterogeneous model semantic interoperability method based on ontology meta-model according to claim 1, characterized in that, Step 4 includes: Step 41: Iterate through each memory object instance in turn and check whether it has a reuse mapping tag. If it has a reuse mapping tag, it means that the ontology metamodel-various software heterogeneous model mapping has been configured and the target software model rendering begins; if it does not have a reuse mapping tag, skip it and continue iterating. Step 42: For memory object instances with reused mapping tags, call the code generation template in the target software model file format, read the attribute parameters in the memory object instance, and inject them into various placeholders pre-set in the template; Step 43: Initialize a global identifier dictionary in memory to maintain the mapping between the type URIs of memory object instances and the target software model identifiers or physical paths; Perform the first scan: Perform a complete scan of all memory object instances. For memory object instances with reuse mapping tags, generate a target ID according to the constraints of each software metamodel specification, and register <memory object instance type URI, target ID> in the global identifier dictionary; Perform the second scan: Scan only the relationships of all memory object instances. For the scanned relationships, extract the type URIs of the two memory object instances connected by the relationship, and denot them as the source object URI and the destination object URI, respectively. Query the global identifier dictionary with the source object URI and the destination object URI to obtain the corresponding target IDs, denoted as target ID_Source and target ID_Target; Follow the constraints of each software metamodel specification to perform topological stitching of the code text of two isolated memory object instances to generate a model file usable by the target software.
10. A heterogeneous model semantic interoperability system based on an ontology meta-model, implementing the method described in any one of claims 1-9, characterized in that, include: The model building module is used to collect conceptual terms of domain generic objects, extract metamodel specifications from the software to be integrated using the conceptual terms as a comparison benchmark, filter all metamodel content corresponding to the domain generic objects from the metamodel specifications, construct attribute tables and relation tables based on the attribute items and relations in all metamodel content, and obtain the domain ontology metamodel based on the attribute tables and relation tables. The semantic mapping module is used to generate query templates for model instance data and construct model rendering templates based on the global semantic mapping configuration. The data processing module is used to load the query template query model instance database, obtain triple data, query the mapping registry based on the triple data, and complete the explicit assignment of memory instances. If the ontology metamodel corresponding to the successfully instantiated memory object has a corresponding mapping path, then the memory object is tagged with a reuse mapping tag. The model file generation module is used to generate corresponding target IDs for memory object instances with reuse mapping tags, register the type URI and target ID of the memory object instance in the global identifier dictionary, extract the type URIs of the two memory object instances connected by the relationship of each memory object instance, namely the source object URI and the destination object URI, query the global identifier dictionary to obtain the corresponding target ID, and perform topological stitching of the code text of the two memory object instances based on the corresponding target ID to generate a model file usable by the target software.