Data weaving semantic integration method based on semantic web and knowledge graph

Abstract

The application relates to the technical field of data governance, in particular to a data weaving semantic integration method based on a semantic network and a knowledge graph, which comprises the following steps: obtaining multi-source heterogeneous data and preprocessing the multi-source heterogeneous data to obtain standardized data, wherein the multi-source heterogeneous data comprises structured data, semi-structured data and unstructured data from different business scenes; performing rule injection on the standardized data to generate semantic network ontology data; extracting entities and attribute values in the standardized data to generate structured knowledge graph data at an instance layer; and establishing a semantic association mapping network of the semantic network ontology data and the structured knowledge graph data to generate a semantic integration result of data weaving. The application eliminates the basic differences of multi-source data in aspects such as formats and encodings, provides a unified semantic standard, and reduces conflicts caused by non-uniform semantics.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a data weaving semantic integration method based on semantic web and knowledge graph. Background Technology

[0002] As enterprises accelerate their digital transformation, business scenarios are expanding in multiple dimensions. In different business processes such as customer service, supply chain management, and product development, structured data (such as relational database table data), semi-structured data (such as JSON data returned by API interfaces), and unstructured data (such as business report documents and user consultation texts) are continuously generated. To break down data barriers between different business scenarios and achieve collaborative analysis and value mining of multi-source data, effective semantic integration of these heterogeneous data sources is crucial. Ensuring consistency in semantic understanding and logical association has become a key requirement in enterprise data governance and business decision support.

[0003] In existing technologies, semantic integration of multi-source heterogeneous data typically involves first performing data cleaning and format conversion on structured, semi-structured, and unstructured data respectively to meet basic integration conditions; then, building separate data association models for each type of data based on their local features to achieve semantic association within the same type of data; and finally, merging the data in different data association models using preset simple field matching rules to form a preliminary integration result.

[0004] However, the existing solutions mentioned above lack a globally unified semantic constraint mechanism for multi-source data during the semantic integration process. The association model built solely based on local data features is difficult to cover the deep semantic associations in complex business scenarios. Furthermore, simple field matching rules cannot resolve semantic ambiguities between different data models, resulting in semantic conflicts and broken association logic in the integrated data. This makes it impossible to provide high-quality semantically consistent data support for data analysis and decision-making across business scenarios. Summary of the Invention

[0005] Therefore, it is necessary for the present invention to provide a data weaving semantic integration method based on semantic web and knowledge graph to solve at least one of the above-mentioned technical problems.

[0006] To achieve the above objectives, a data weaving semantic integration method based on Semantic Web and knowledge graph includes the following steps: Step S1: Acquire multi-source heterogeneous data and preprocess it to obtain standardized data, wherein the multi-source heterogeneous data includes structured data, semi-structured data, and unstructured data from different business scenarios; Step S2: Inject rules into the standardized data to generate Semantic Web ontology data; Step S3: Extract entities and their attribute values ​​from the standardized data to generate structured knowledge graph data at the instance layer; Step S4: Establish a semantic association mapping network between the Semantic Web ontology data and the structured knowledge graph data to generate the semantic integration result of data weaving.

[0007] The data weaving semantic integration method based on semantic web and knowledge graph provided by this invention can achieve the following targeted technical benefits, which are described in detail below:

[0008] 1. Step S1 performs unified preprocessing on structured, semi-structured, and unstructured data from different business scenarios to obtain standardized data. This process is not the traditional "processing separately by type". Instead, it eliminates the differences in format, encoding, and basic semantic description of multi-source data through unified preprocessing logic (such as data format regularization and semantic annotation foundation construction). This provides a consistent data foundation for subsequent global semantic rule injection and entity extraction, reducing semantic conflicts caused by "inconsistent data foundation" from the source and laying the premise for semantic consistency in subsequent integration.

[0009] 2. Step S2 injects rules into the standardized data and generates semantic web ontology data. This semantic web ontology data can serve as a "global semantic framework" for multi-source data integration. It contains unified concept definitions and attribute constraint rules (such as domain-wide common concepts and hierarchical relationships between concepts), and can provide a consistent semantic standard for all data to be integrated. Compared with the traditional method of no global constraints and data being associated according to local features, this method can ensure that multi-source data always follows a unified semantic logic during the integration process, greatly reducing the probability of conflicts caused by inconsistent semantic standards and improving the semantic synergy of multi-source data.

[0010] 3. Step S3 extracts entities and their attribute values ​​from standardized data and generates structured knowledge graph data at the instance layer. Structured knowledge graph data is centered on "entities" and can intuitively present the business relationships between entities (such as the relationship link between entity-attribute-entity), rather than the traditional solution that only captures "local field feature relationships". This entity-centered structured presentation can more comprehensively cover the deep semantic relationships of data in complex business scenarios (such as the cross-business link relationship between customer-order-product). Compared with the traditional local relationship model, the data relationship is more comprehensive and can reduce the integration logic break caused by incomplete relationships.

[0011] 4. Step S4 establishes a semantic association mapping network between Semantic Web ontology data and structured knowledge graph data. This mapping network is not a traditional "one-to-one field matching", but a deep mapping based on the "global semantic framework (Semantic Web ontology data)" and the "instance association link (structured knowledge graph data)". On the one hand, Semantic Web ontology data ensures the semantic standard of the mapping is unified, and on the other hand, structured knowledge graph data ensures the accuracy of instance association in the mapping. It can effectively identify and resolve semantic ambiguities between different data models (such as semantic alignment of different expressions of the same entity), avoid the problem of "superficial matching but semantic misalignment" caused by traditional field matching, and finally generate a semantic integration result with high semantic consistency, which can better meet the needs of cross-business scenario data analysis and decision-making for high-quality data. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating the steps of a data weaving semantic integration method based on semantic web and knowledge graph according to the present invention. Detailed Implementation

[0013] To achieve the above objectives, please refer to Figure 1 This invention provides a data weaving semantic integration method based on Semantic Web and Knowledge Graph. The method includes the following steps: Step S1: Acquire multi-source heterogeneous data and preprocess it to obtain standardized data, wherein the multi-source heterogeneous data includes structured data, semi-structured data and unstructured data from different business scenarios; Step S2: Inject rules into the standardized data to generate Semantic Web ontology data; Step S3: Extract entities and their attribute values ​​from the standardized data to generate structured knowledge graph data at the instance layer; Step S4: Establish a semantic association mapping network between the Semantic Web ontology data and the structured knowledge graph data to generate the semantic integration result of data weaving.

[0014] Optionally, step S1 specifically includes: Step 11, summarizing structured data, semi-structured data and unstructured data from different business scenarios in the same data factory through distributed crawling and interface adaptation to generate multi-source heterogeneous data containing data source identifiers; Step 12, performing predetermined standardization logic processing on the multi-source heterogeneous data containing data source identifiers to generate standardized data.

[0015] Preferably, the specific implementation process of step 11 is as follows: First, for the specific application scenario of "the same data factory" (the data factory aggregates data sources from business scenarios such as customer service, supply chain management, and product development, and each data source is stored in different nodes with different access methods), the data source sorting and positioning operation is performed with "data sources of various business scenarios within the same data factory" as the processing object. By traversing the metadata management system of the data factory, the storage location (e.g., unstructured data is stored in the distributed file system HDFS, structured data is stored in the relational database MySQL / PostgreSQL, and semi-structured data is stored in the document database MongoDB), data type (labeled as "customer service - unstructured", "supply chain management - structured", etc.) and access permission information of the data source under each business scenario are extracted. The above information is classified and organized according to business scenarios to obtain the "data source positioning list". The "data source positioning list" clarifies the specific goals of subsequent distributed crawling and interface adaptation, and provides accurate guidance for subsequent data collection.

[0016] Preferably, in the specific technical implementation of step 11, for "unstructured data" (such as user consultation text in customer service scenarios and design specification documents in product development scenarios), the "unstructured data sources marked in the data source location list" are used as the processing objects, and a scenario-based distributed crawler system is constructed: First, crawler nodes are configured according to the scenario characteristics of unstructured data (such as crawler nodes for customer service scenarios focusing on text document parsing, and crawler nodes for product development scenarios focusing on drawing-type file parsing). Each crawler node is equipped with a scenario-based parsing module (the customer service scenario module adopts text content extraction rules based on word segmentation dictionaries, and the product development scenario module adopts a scenario-based parsing module). The scene module adopts OCR-based drawing text recognition rules. Secondly, to avoid repeated crawling, an incremental crawling mechanism is introduced into the crawler system—by recording the file modification timestamp of each data source last crawled, crawling is only performed on files with timestamps later than the last crawled. Finally, for the crawled unstructured data, a temporary label of "crawling node ID" and "crawling time" is generated to produce "crawled unstructured data and temporary identifier". This "crawled unstructured data and temporary identifier" enables preliminary traceability of unstructured data, which is different from the problems of low parsing accuracy and high repeated crawling rate caused by traditional general crawlers ignoring scene characteristics.

[0017] Preferably, in a specific implementation of step 11 in a scenario, for "structured data and semi-structured data" (such as order tables in an ERP system in a supply chain management scenario, and JSON data of user information in a CRM system in a customer service scenario), a multi-protocol interface adaptation layer is constructed, taking the "structured / semi-structured data sources marked in the data source location list" as the processing objects: First, the interface protocol type of each data source is identified (such as REST API used by the ERP system, SOAP API used by the CRM system, and WebSocket used by the logistics management system), and the corresponding protocol parsing module is integrated into the adaptation layer; Second, to unify the basic format of the data returned by the interface, data conversion rules are configured for each protocol (such as converting XML format data returned by SOAP API to JSON format, and converting REST API to JSON format, and converting XML format data returned by SOAP API to JSON format, and converting REST API to JSON format, and converting JSON format data ... The nested JSON data returned by the API is flattened into a flat structure. Simultaneously, to handle API call failures, an exception retry mechanism is designed—when the API returns an error code (such as a 500 series server error or a 403 permission error), a differentiated retry strategy is executed based on the error type (exponential backoff retries are executed for server errors, and permission re-verification is triggered for permission errors). After a successful API call, the returned structured / semi-structured data is temporarily labeled with "API protocol type" and "call time," generating "adapted structured / semi-structured data and temporary identifiers." This "adapted structured / semi-structured data and temporary identifiers" solves the problem of data collection interruption caused by traditional single-API adaptation only supporting fixed protocols and lacking exception handling, ensuring stable collection of structured and semi-structured data.

[0018] Preferably, in the specific implementation of step 11, the "unstructured data and temporary identifiers after crawling" and "structured / semi-structured data and temporary identifiers after adaptation" are the processing objects, and the generation and association operation of data source identifiers is performed: First, the composition rules of the data source identifier are designed—the identifier consists of "business scenario code (e.g., customer service is CS, supply chain management is SC, product development is RD) + data source type code (unstructured is U, structured is S, semi-structured is SS) + collection timestamp (format is YYYYMMDDHHMMSS) + unique sequence code (6 random numbers)", for example, "CS-U-20240520143000-123456" represents the customer service scenario unstructured data collected at 14:30 on May 20, 2024. First, the data is processed. Second, a distributed association algorithm is used to associate the generated unique data source identifier with the corresponding "crawled unstructured data" and "adapted structured / semi-structured data" at the field level (a "data_source_id" field is added to the data's metadata field to store this identifier). Finally, a unique identifier verification is performed on all associated data—by comparing the "data_source_id" field, data corresponding to duplicate identifiers are eliminated, ensuring that each piece of data has a unique and traceable source identifier, generating "data to be summarized with temporary identifiers." This "data to be summarized with temporary identifiers" provides a key basis for source tracing analysis in the subsequent data preprocessing stage, avoiding the problem of unclear data ownership caused by the lack of clear source identifiers in traditional data summarization.

[0019] Preferably, in the specific technical implementation of step 11, the "data to be summarized with temporary identifiers" is taken as the processing object, and distributed data summarization and integrity verification are performed: First, the "data to be summarized with temporary identifiers" distributed among various crawler nodes and interface adaptation nodes are uniformly summarized to the distributed data warehouse (such as Hive) of the data factory. During the summarization process, a partitioned storage strategy is adopted - the storage partition is divided according to "business scenario code + collection date" (e.g., the data of CS scenario 20240520 is stored under the path " / data / cs / 20240520"); Second, data integrity verification is performed - by comparing the expected data volume of each data source in the "data source location list" with the actual summarized data volume. If the deviation rate exceeds a preset threshold (e.g., 5%, which can be adjusted according to the data integrity requirements of the business scenario; for example, the threshold is set to 3% for supply chain management scenarios and 8% for customer service scenarios), the corresponding supplementary data collection mechanism is triggered (if the crawler node does not reach the required amount, incremental crawling is re-executed; if the interface adaptation node does not reach the required amount, the interface is re-called). After the actual aggregated data volume of all data sources meets the integrity requirements, "multi-source heterogeneous data containing data source identifiers" is obtained. This process ensures the organization and total integrity of the aggregated data through partitioned storage and integrity verification, which is different from the low efficiency and data missing problems caused by traditional aggregation that simply merges data without partitioning and verification.

[0020] Optionally, step S12 specifically includes: step 121, performing hierarchical cleaning on multi-source heterogeneous data containing data source identifiers to generate cleaned data; step 122, unifying the data format, measurement unit, and field naming rules of the cleaned data through a preset domain data dictionary to generate standardized intermediate data with semantic annotations; step 123, performing cross-modal semantic association on the standardized intermediate data based on knowledge embedding rules to extract semantic features pointing to the same business entity in different types of data to generate standardized data.

[0021] Preferably, the specific implementation process of step 121 is as follows: First, taking "multi-source heterogeneous data containing data source identifiers" as the processing object (this data contains the "data source identifiers" generated in step 11, which contain information such as "business scenario code" and "data source type code"), a data classification operation is performed—extracting the "data source type code" of each data (the coding rule is U for unstructured, S for structured, and SS for semi-structured), and dividing the data into three categories according to the code: "unstructured data to be cleaned", "structured data to be cleaned", and "semi-structured data to be cleaned"; at the same time, to preserve the scenario association for subsequent targeted cleaning, the "business scenario code" (such as CS for customer service and SC for supply chain management) is bound to the corresponding category of data to be cleaned, resulting in a "set of data to be cleaned that is bound to the classification scenario"; this operation solves the problem that traditional cleaning ignores the differences in data types and scenarios and uses a general process that leads to insufficient targeting, and provides a classification basis for subsequent hierarchical cleaning.

[0022] Preferably, in the specific technical implementation of step 121, for the "structured data to be cleaned" (such as order table data in the supply chain scenario and user information table data in the customer service scenario), a two-level cleaning process of "basic cleaning - business verification" is performed: The first-level basic cleaning takes the "structured data to be cleaned in the data set to be cleaned in the category-bound scenario" as the processing object. First, the missing fields (such as the "order number" and "amount" fields in the order table) are identified by the null value detection algorithm. For non-critical missing fields (such as "remarks"), "scenario-based default value filling" is used ("no remarks" is filled in the customer service scenario, and "not filled" is filled in the supply chain scenario). The critical missing fields (such as "order number") are marked as "to be completed" and recorded in the "missing field list". Then, the duplicate data is identified by the hash value comparison method (the field hash value of each data is calculated and redundant data with duplicate hash values ​​are deleted) to obtain the "structured data after basic cleaning". The second level of business verification takes the "basic cleaned structured data" as the processing object. It combines the "business scenario code" bound to it to call the business rule base of the corresponding scenario (such as the CS scenario rule base containing "user age > 0 and < 150" and "phone number format conforms to 11 digits", and the SC scenario rule base containing "order amount ≥ 0" and "inventory quantity ≥ 0"). It performs rule verification on each data field one by one, and marks abnormal data that does not meet the rules (such as "order amount = -100" in the SC scenario) as "to be corrected" and records it in the "abnormal data list". For the data in the "missing field list" and "abnormal data list", it obtains the correct data by calling the data source interface of the corresponding business scenario (such as calling the ERP system interface to complete the missing order fields in the SC scenario, and calling the CRM system interface to correct the abnormal user phone number in the CS scenario). After replacing the content to be completed and corrected, the "structured cleaned data" is obtained.

[0023] Preferably, in a scenario, when step 121 is specifically implemented, for "unstructured data to be cleaned" (such as user consultation text in customer service scenarios, design specification documents in product development scenarios), a two-level cleaning process of "noise filtering - content regularization" is performed: The first-level noise filtering takes "unstructured data to be cleaned in the data set to be cleaned in the category-bound scenario" as the processing object, and loads a scenario-based noise dictionary (CS scenario dictionary contains "system prompt: your consultation has been transferred" "invalid characters: ###, ***", RD scenario dictionary contains "draft mark: [unreviewed], [temporary version]"), and identifies and deletes noise content through a text matching algorithm; at the same time, for image-type unstructured data (such as RD... The first level of content regularization uses image denoising algorithms (such as median filtering) to remove scanning noise and watermark interference, resulting in "noise-filtered unstructured data". The second level of content regularization takes the "noise-filtered unstructured data" as the processing object, unifying the encoding format (converting to UTF-8) and newline character format (unified to "\n") for text data, and unifying the resolution (1920×1080 for CS scene customer service screenshots and 300dpi for RD scene drawings) and storage format (unified to PNG) for image data, resulting in "unstructured cleaned data". This second-level cleaning is different from the traditional unstructured data that only performs simple deduplication, and improves data usability through scene-based noise filtering and format regularization.

[0024] Preferably, in the specific implementation of step 121, for "semi-structured data to be cleaned" (such as user feedback JSON data in the CS scenario and logistics information XML data in the SC scenario), a two-level cleaning process of "format repair - field completion" is performed: The first-level format repair takes "semi-structured data to be cleaned in the data set to be cleaned in the category binding scenario" as the processing object, calls the corresponding parser (JSON parser, XML parser) according to the data format type (JSON / XML), detects format errors (such as unclosed quotes in JSON and mismatched tags in XML), and automatically corrects errors (such as completing missing quotes and closing unmatched tags) through the format repair module built into the parser; for serious format errors that cannot be automatically repaired... Errors (such as disordered JSON nesting) are marked as "awaiting manual correction" and recorded in the "Format Error List". The system prompts manual intervention to correct them, resulting in "format-corrected semi-structured data". The second-level field completion uses the "format-corrected semi-structured data" as the processing object. It combines the "business scenario code" it is bound to with the preset "semi-structured field template" (such as the CS scenario user feedback template containing "user ID", "feedback content" and "feedback time", and the SC scenario logistics template containing "waybill number", "recipient address" and "logistics status"). It identifies missing fields and completes them by associating them with structured data (such as in the CS scenario, "user ID" is completed by associating "user mobile number" with the user information table), resulting in "semi-structured cleaned data".

[0025] Preferably, in the specific technical implementation of step 121, the processing objects are "structured cleaned data," "unstructured cleaned data," and "semi-structured cleaned data," and the cleaning results are summarized and the integrity is verified: First, the three types of cleaned data are re-associated according to the "data source identifier" (ensuring that the source identifier of each data is not lost, facilitating subsequent traceability), forming "summarized cleaned data to be verified"; Second, the "cleaning completion rate" of each type of data is calculated (cleaning completion rate = amount of cleaned data of this type / amount of data to be cleaned after classification of this type), and the scenario completion rate threshold is matched with the bound "business scenario code" (e.g., CS scenario due to data). For large datasets, the threshold is set at 95%; for SC scenarios involving transaction data, the threshold is set at 98%. If the cleaning completion rate of a certain type of data is lower than the corresponding threshold, the records that have not been cleaned in that type of data are extracted (obtained from the "Missing Fields List", "Abnormal Data List", and "Format Error List"), and the corresponding secondary cleaning process for that type of data is re-executed. After the cleaning completion rate of all categories reaches the scenario-specific threshold requirements, the three types of cleaned data are integrated into a unified dataset to obtain "cleaned data". This summary and verification process ensures that no cleaning is missed, avoiding the problem of some data not being cleaned due to traditional cleaning focusing only on a single type of data and ignoring the overall integrity.

[0026] Preferably, the specific implementation process of step 122 is as follows: First, in response to the core requirement of "data standardization for multiple business scenarios within the same data factory", a "scenario-based domain data dictionary" is constructed. This dictionary is designed in layers according to "business scenario coding" (e.g., CS represents customer service, SC represents supply chain management, and RD represents product development). Each layer contains four core modules: "field naming convention table", "data format definition table", "measurement unit comparison table", and "semantic description tag library". Among them, the "field naming convention table" clarifies the standard names of core fields in each scenario (e.g., "user contact phone" in the CS scenario is uniformly "user_contact_phone", and "order total amount" in the SC scenario is uniformly "order_total_amount"). The "data format definition table" specifies the field format (e.g., "date" is uniformly "YYY"). Y-MM-DD, where "phone number" is uniformly represented as an "11-digit numeric string"; a "unit of measurement lookup table" maps scenario-based units to standard units (e.g., in the SC scenario, "kilogram" and "gram" are uniformly represented as "kilogram", and in the RD scenario, "millimeter" and "centimeter" are uniformly represented as "meter"); and a "semantic description tag library" matches fields with business semantic tags (e.g., in the CS scenario, "user_contact_phone" is tagged as "user's core contact information", and in the SC scenario, "order_total_amount" is tagged as "order's core financial indicator"). After construction, the "scenario-based domain data dictionary" is stored in a distributed dictionary service (e.g., Redis), generating a "callable scenario-based domain data dictionary" to provide a unified basis for subsequent standardization, which is different from the problem of poor standardization adaptability caused by traditional general-purpose dictionaries ignoring scenario differences.

[0027] Preferably, in the specific technical implementation of step 122, for the "structured cleaned data" (generated in step 121, containing "business scenario code" binding information), a three-dimensional standardization of "field-format-unit" is performed: the first dimension of field standardization takes the "structured cleaned data" as the processing object, extracts its bound "business scenario code", calls the "field naming convention table" of the corresponding scenario in the "callable scenario-based domain data dictionary", and generates a "scenario-based field mapping table" (e.g., in the CS scenario, "user phone number" is mapped to "user_contact_phone", "customer name" to "user_contact_phone"). The first dimension maps "2024.05.20" to "user_name"; non-standard fields in the data are identified using a fuzzy matching algorithm (such as similarity matching based on edit distance), and replaced with standard field names according to the "scenario-based field mapping table" to obtain "structured data after field standardization"; the second dimension, format standardization, takes the "structured data after field standardization" as the processing object, calls the "data format definition table" of the corresponding scenario, and performs format validation and conversion on each standard field (such as converting "2024.05.20" and "2024 / 05 / 20" to "2024-05-20", and converting "138" to "user_name"). The process involves converting "1234 5678" to "13812345678", marking any data that cannot be converted (such as "2024-13-01") as "format anomaly" and recording it in the "standardized anomaly list", resulting in "format-standardized structured data". The third dimension, unit standardization, uses this "format-standardized structured data" as its processing object. It calls the corresponding scenario's "measurement unit lookup table", extracts unit information from the fields (such as "order_total_amount: 5000 grams"), converts it to standard units (to "5 kilograms") according to the lookup table, and updates the field values, resulting in "unit-standardized structured data". Finally, it matches this data with scenario-based semantic tags from the "semantic description tag library" (such as adding the "order funds core indicator" tag to "order_total_amount"), generating "structured standardized intermediate data with semantic annotations".

[0028] Preferably, in a scenario, when step 122 is specifically implemented, for the "semi-structured cleaned data" (generated in step 121, such as JSON / XML format, containing "business scenario code" binding information), a "tag-format-semantic" collaborative standardization is performed: The first dimension, tag standardization, takes the "semi-structured cleaned data" as the processing object, extracts its data tags (such as "key" in JSON, "tag" in XML) and the bound "business scenario code", calls the "field naming convention table" of the corresponding scenario in the "callable scenario-based domain data dictionary", replaces non-standard tags (such as "user mobile phone number" in CS scenario JSON) with standard tags ("user_contact_phone"), and deletes redundant tags (such as "temporary tag" and "invalid note") to obtain "tag-standardized semi-structured data"; the second dimension, format standardization, takes the "tag-standardized semi-structured data" as the processing object. The process involves unifying the data storage format (converting XML to JSON, ensuring consistent nesting levels, e.g., flattening "user.address.city" into "user_address_city"), and standardizing field formats according to the corresponding scenario's "data format definition table" (e.g., unifying "user_birthday" to "YYYY-MM-DD") to obtain "format-standardized semi-structured data." The third dimension, semantic annotation, uses this "format-standardized semi-structured data" as its processing object, calling the corresponding scenario's "semantic description tag library" to add semantic tags to each standard tag (e.g., adding the "order product quantity index" tag to "order_quantity" in the SC scenario), generating "semantically annotated semi-structured standardized intermediate data." This process solves the problem of traditional semi-structured data only undergoing format conversion while ignoring tag standardization and semantic association, thus improving data semantic consistency.

[0029] Preferably, in the specific implementation of step 122, for the "unstructured cleaned data" (generated in step 121, such as text and images, containing "business scenario coding" binding information), "format unification - semantic anchoring" standardization is performed: the first dimension of format unification takes the "unstructured cleaned data" as the processing object, and performs format conversion according to its type (text / image) and the bound "business scenario coding"—text data is uniformly encoded as UTF-8, uniformly uses "\n" as the line break character, and uniformly uses the font style (such as customer service dialogue text in CS scenario is uniformly "SimSun-12pt", and design document text in RD scenario is uniformly "Microsoft YaHei-14pt"), resulting in "format-unstructured text data"; image data is uniformly resolved (such as customer service screenshots in CS scenario are uniformly 1920×1080, and design drawings in RD scenario are uniformly 300dpi). The unified storage format is PNG, and the unified compression quality (compression ratio is set according to the scenario, 80% for CS scenario and 90% for RD scenario) to obtain "unstructured image data with unified format". The second dimension, semantic anchoring, takes "unstructured text data with unified format" and "unstructured image data with unified format" as the processing objects. For text data, a keyword matching algorithm is used to extract keywords such as "user ID" and "order number", and semantic tags are added by associating with the "semantic description tag library" of the corresponding scenario (such as adding the "user identification information" tag to text containing "user ID:1001"). For image data, OCR recognition is used to extract text information (such as "part number:PD-001" in RD scenario drawings), and semantic tags are also associated (adding the "part identification information" tag), finally generating "unstructured standardized intermediate data with semantic annotation".

[0030] Preferably, in the specific technical implementation of step 122, the processing objects are "structured and standardized intermediate data with semantic annotation," "semi-structured and standardized intermediate data with semantic annotation," and "unstructured and standardized intermediate data with semantic annotation," and standardization consistency verification and summarization are performed: First, the "business scenario code" and "semantic description tag" of the three types of data are extracted, and a "scenario-semantic verification matrix" is constructed—the rows of the matrix represent the "business scenario code" (CS / SC / RD), the columns represent the "semantic description tag" (such as "user identification information" and "order core indicators"), and the elements at the intersection of the rows and columns represent the number of fields of the tag in the corresponding scenario; through The verification matrix detects "duplication of semantic labels within a scenario" (e.g., multiple fields corresponding to the same "user identification information" label in the CS scenario) and "conflict of semantic labels across scenarios" (e.g., semantic confusion between the "order amount" label in the SC scenario and the "project amount" label in the RD scenario). For conflicting data, the semantic labels are corrected by calling the "callable scenario-based domain data dictionary". After the verification is passed, the three types of data are partitioned and stored in a distributed data warehouse according to "business scenario encoding" and "data type" (structured / semi-structured / unstructured), generating "standardized intermediate data with semantic annotation". This summary verification process ensures the standardization consistency of data of different types and different scenarios.

[0031] Preferably, the specific implementation process of step 123 is as follows: First, in response to the core requirement of "semantic association of cross-modal data in multiple business scenarios", a "scenario-based knowledge embedding rule base" is constructed. This rule base is divided into two dimensions: "business entity type" (such as core business entities such as users, orders, products, and parts) and "data modality combination" (structured-semi-structured, structured-unstructured, and semi-structured-unstructured). Each cell contains three types of rules: entity feature mapping rules (defining the correspondence of core features of the same entity in different modalities, such as the structured "user_" of the "user entity"). The rule base is stored in Extensible Markup Language (XML) format. Each rule contains fields such as "id", "applicable entity type", "applicable modality combination", "rule content", and "scenario code". This generates a "callable scenario-based knowledge embedding rule base", providing a clear basis for cross-modal association, which is different from the problem of low association accuracy caused by ignoring the differences between entity types and scenarios in traditional general association rules.

[0032] Preferably, in the specific technical implementation of step 123, the "standardized intermediate data with semantic annotation" (generated in step 122, containing three types of data: structured, semi-structured, and unstructured, all with "business scenario encoding" and "semantic description tags") is used as the processing object, and "intramodal semantic feature extraction" is performed: For structured data, its standard field values ​​(such as "user_id=1001" and "order_id=OD202405") and corresponding "semantic description tags" are extracted to construct "structured semantic feature groups" (each group contains a triplet of "feature name-feature value-semantic tag"); for semi-structured data with semantic annotation (such as JSON format), the values ​​corresponding to the standard tags (such as "user_contact_phone:13812345678") and semantic tags are extracted to construct "semi-structured semantic feature groups"; for unstructured data with semantic annotation, text is processed through named entity recognition (Named... The Entity Recognition (NER) model extracts entity features (e.g., extracting "User ID=1001" and "Order ID=OD202405" from "User 1001 consulted order OD202405 on 2024-05-20"). For image types, text features are extracted using Optical Character Recognition (OCR) before entity features are extracted (e.g., "Part Number PD001" in product drawings). These features are then combined with semantic tags to construct "unstructured semantic feature groups". The three feature groups are classified according to "business scenario coding" to generate "classified scenario-based intra-modal semantic feature sets", providing a feature foundation for subsequent cross-modal association.

[0033] Preferably, in a scenario, when step 123 is specifically implemented, based on the "classified scenario-based semantic feature set" and the "callable scenario-based knowledge embedding rule base", "cross-modal semantic feature association modeling" is performed: First, for the "structured semantic feature group" and "semi-structured semantic feature group" under the same business scenario, the "entity feature mapping rule" of the "structured-semi-structured" modal combination in the rule base is called to generate a "feature mapping lookup table" (such as "user_id" mapping "user identifier" and "user_contact_phone" mapping "contact phone number" in the CS scenario); by calculating the matching degree of feature values ​​(exact matching is counted as 1, and fuzzy matching is weighted according to the "semantic association strength rule" of the rule base), a "structured-semi-structured feature association matrix" is constructed - the rows of the matrix represent the features in the structured feature group, the columns represent the features in the semi-structured feature group, and the elements at the intersection are the matching degree weights of the two; feature pairs in the matrix with weight values ​​greater than the scenario association threshold (such as 0.6 in the CS scenario and 0.7 in the SC scenario) are selected and marked as "high confidence structured-semi-structured association pairs".

[0034] Preferably, in the specific implementation of step 123, for the "structured / semi-structured semantic feature group" and the "unstructured semantic feature group", cross-modal deep association is performed: Rules for the "structured-unstructured" and "semi-structured-unstructured" modal combinations in the rule base are called. First, potential related features are located through "entity feature mapping rules" (e.g., in the SC scenario, both the structured "order_id" and the unstructured text "order OD202405" point to the "order entity"); then, "contextual semantic similarity" calculation is introduced—for unstructured text, a pre-trained language model (e.g., bidirectional encoder representations from the converter) is used. BERT (BioTransformers) generates text vectors, generates label vectors for semantic labels of structured / semi-structured features, calculates the cosine similarity between the two types of vectors, and combines the weights in the "semantic association strength rule" of the rule base to obtain the "comprehensive association score". A scenario-based score threshold is set (e.g., 0.5 for RD scenario due to the high rigor of technical documents, and 0.4 for CS scenario due to the high flexibility of user text), and feature pairs with comprehensive association scores exceeding the threshold are selected and marked as "high-confidence structured / semi-structured-unstructured association pairs". This process differs from traditional cross-modal association based solely on keyword matching, and improves the semantic depth of association by fusing vector similarity and rule weights.

[0035] Preferably, in the specific technical implementation of step 123, the "high-confidence structured-semi-structured association pairs" and "high-confidence structured / semi-structured-unstructured association pairs" are taken as the processing objects, and "association conflict resolution and entity feature integration" are performed: First, a "business entity association network" is constructed—network nodes are extracted business entities (such as user 1001, order OD202405), edges are cross-modal association pairs, and the weight of the edges is the comprehensive association score; conflicting associations in the network are detected (such as the same "order OD202405" having an amount of "500 yuan" in structured data, but being mistakenly written as "5000 yuan" in unstructured text), and the rule base "scenario priority rule" is called (such as the structured order in the SC scenario). First, single data has higher priority than unstructured text, high-priority feature values ​​are retained, and low-priority conflicting features are marked as "to be verified". Second, all cross-modal features pointing to the same business entity in the network (such as the structured "user_id", semi-structured "user identifier", and unstructured "user1001" for user 1001) are integrated into a "unified entity feature set" (including feature name, multimodal feature value, source modality, and association confidence). Finally, a unique "temporary entity identifier" (formatted as "entity type code + scenario code + random sequence", such as "U-CS-789" for user entity CS scenario) is assigned to each "unified entity feature set" to generate "cross-modal integrated feature data with entity identifier".

[0036] Preferably, in the specific implementation of step 123, the "cross-modal integrated feature data with entity identifiers" is used as the processing object, and association integrity verification and standardized data generation are performed: First, the "modal coverage" of each business entity is calculated (number of covered modal types / total number of modal types, with a total of 3 modal types), and the scenario coverage threshold is matched with the "business scenario code" (e.g., the order entity in the SC scenario needs to cover all 3 modalities, and the threshold is set to 1; the user entity in the CS scenario only needs to cover 2 modalities, and the threshold is set to 0.67); for entities that do not reach the threshold (e.g., a user entity only covers structured and semi-structured modalities), the "semantic feature set within the classification scenario modality" is returned to re-execute cross-modal association to supplement the missing modal features; after the verification is passed, the "cross-modal integrated feature data with entity identifiers" is aggregated according to the "temporary entity identifier", and the data source identifier (generated in step 11) and semantic description label are retained to form "standardized data" - in this data, the multimodal semantic features of the same business entity are uniformly associated, and different entities are distinguished by the "temporary entity identifier".

[0037] Optionally, step S2 specifically includes: step 21, extracting core domain terms from standardized data to construct ontology structure data; step 22, forming a rule-injected ontology and injecting the rule-injected ontology into the ontology structure data to generate semantic web ontology data.

[0038] Optionally, step S21 specifically includes: step 211, extracting core domain terms from standardized data, and clustering synonyms / near-synonyms through bidirectional semantic similarity calculation to generate concept layer data; step 212, designing hierarchical relationships, equivalence relationships, and associated attributes between concepts based on the domain knowledge system, defining the domain, value range, and data type constraint rules of the attributes, so as to construct ontology structure data for the concept layer data.

[0039] Preferably, the specific implementation process of step 211 is as follows: First, taking "standardized data" (generated in step S1, containing structured, semi-structured, and unstructured data, and associated with "business scenario coding," "entity temporary identifiers," and "semantic description tags") as the processing object, perform "preliminary extraction of multimodal domain terms"—for structured data, extract the "feature names" (such as "user_id," "order_total_amount") and high-frequency attribute values ​​(such as "user," "order," and other words that appear repeatedly in the attribute description) from its "unified entity feature set"; for semi-structured data (such as JSON), extract the standard tag names (such as "user_contact_phone") and core words (such as "phone number," "contact phone number") from the tag values; for unstructured data, adopt a domain-adaptive term extraction model (such as one based on Conditional Random Fields). Field, CRF (a model pre-trained with enterprise business corpus), extracts noun phrases (such as "customer service work order" and "supply chain logistics node") and professional terms (such as "product R&D BOM list") from text or OCR recognition results; summarizes the terms extracted from the three types of data, retains the terms containing the core entities in the "semantic description tags" (such as "user", "order", and "product"), and generates an "initial domain term set"; this process is different from traditional single-modal term extraction, and ensures the comprehensiveness of term coverage through multimodal collaboration.

[0040] Preferably, in the specific technical implementation of step 211, the "initial domain terminology set" is used as the processing object, and "terminology cleaning and scenario-based filtering" are performed: In the first stage of terminology cleaning, non-terminology characters (such as special symbols "@#" and meaningless prefixes "tmp_") are removed using regular expressions, and the terminology is standardized in format (such as unifying capitalization, converting "UserID" to "user_id"; unifying abbreviations, "cust"...). The process begins with expanding the term "customer" to generate a "cleaned term set." The second stage involves scenario-based filtering, extracting the associated "business scenario code" (e.g., CS, SC, RD) for each term, and constructing a "scenario-term frequency matrix"—rows representing business scenarios, columns representing cleaned terms, and the intersection element representing the frequency of the term in the corresponding scenario. A threshold for core terms in each scenario is set (e.g., a term's frequency percentage in a scenario is ≥30%, percentage = frequency within the scenario / total frequency). Terms meeting at least one scenario threshold are retained (e.g., "order_id" has a 45% frequency percentage in the SC scenario, and "user_complaint" has a 50% frequency percentage in the CS scenario), while terms with low frequency across scenarios (e.g., "temporary tag") are removed, generating a "domain core candidate term set." This filtering process ensures a strong correlation between terms and business scenarios, avoiding the term redundancy problem caused by traditional general filtering.

[0041] Preferably, in a scenario, when step 211 is specifically implemented, a "scenario-based bidirectional semantic vector model" is constructed using the "domain core candidate term set" as the processing object: First, historical corpora from multiple business scenarios of the enterprise are collected (such as customer service dialogue records in the CS scenario, order management documents in the SC scenario, and product design manuals in the RD scenario) to construct a "domain scenario corpus"; based on a pre-trained language model (such as Bidirectional Encoder Representations from Transformers, BERT), the "domain scenario corpus" is used for fine-tuning to obtain a "scenario-adapted BERT model"—this model, compared to the general BERT, has a semantic understanding of domain terms that is more in line with business scenarios (such as "work order" specifically referring to "customer service work order" in the CS scenario and "logistics scheduling work order" in the SC scenario); each term in the "domain core candidate term set" is input into the "scenario-adapted BERT model" to generate a corresponding "scenario-based semantic vector" (the vector dimension is a preset fixed value, such as 768 dimensions, and the value of each dimension represents the feature strength of the term in a specific semantic dimension), and a "term-scenario-based semantic vector lookup table" is generated.

[0042] Preferably, in the specific implementation of step 211, based on the "term-scenario semantic vector lookup table", "bidirectional semantic similarity calculation" is performed: for any two terms (denoted as term A and term B) in the "domain core candidate term set", firstly, the semantic similarity from term A to term B (Sim(A→B)) is calculated – the semantic vector of term A in the scenario to which term B belongs is generated through the "scenario-adaptive BERT model", and the cosine similarity is calculated with the "scenario-based semantic vector" of term B; then, the semantic similarity from term B to term A is calculated (Sim(B→A)) – the semantic vector of term B in the scenario to which term A belongs is generated. The cosine similarity is calculated with the "contextualized semantic vector" of term A; the average of the two is taken as the "bidirectional semantic similarity" (Sim(A,B)=(Sim(A→B)+Sim(B→A)) / 2), resulting in a "bidirectional semantic similarity matrix"—the rows and columns of the matrix are terms in the "domain core candidate term set", and the elements at the intersection are the bidirectional semantic similarity of the corresponding two terms; this bidirectional calculation method is different from the traditional one-way similarity calculation, and solves the problem of low one-way similarity of cross-context terms due to contextual differences (such as the bidirectional similarity of "customer" in CS context and "user" in SC context can better reflect their synonymy).

[0043] Preferably, in the specific technical implementation of step 211, the "bidirectional semantic similarity matrix" is used as the processing object, and "synonymous / near-synonymous term contextual clustering" is performed: an improved density-based spatial clustering algorithm is adopted. Noise (DBSCAN) is used, where the terms in the "Domain Core Candidate Term Set" are the clustering objects, and "Bidirectional Semantic Similarity" is the distance metric (distance = 1 - similarity). The clustering parameters are dynamically adjusted according to the "Business Scenario Encoding"—the core point threshold (MinPts) is set according to the number of terms in the scenario (5 for scenarios with a large number of terms, such as CS, and 3 for scenarios with a small number of terms, such as RD), and the neighborhood radius (Eps) is the similarity threshold (e.g., the threshold for customer-related terms in the CS scenario is set to 0.7, and the threshold for order-related terms in the SC scenario is set to 0.75). During the clustering process, terms with similarity exceeding the threshold in the same business scenario are prioritized to be clustered into one category (e.g., "user", "customer", "consumer" in the same scenario), and then terms that cross scenarios but have a bidirectional semantic similarity exceeding the global threshold (e.g., 0.65) are merged (e.g., "service work order" in the CS scenario and "scheduling work order" in the SC scenario are clustered into one category because they both contain the core semantic meaning of "work order"), generating the "initial term clustering result". This clustering process ensures that the semantic consistency of terms of the same category is more in line with the actual business by adjusting the scenario-based parameters.

[0044] Preferably, in the specific implementation of step 211, the "initial term clustering results" are used as the processing object, and "clustering quality verification and concept layer data generation" are performed: the "intra-cluster average bidirectional semantic similarity" (the average bidirectional similarity of all term pairs within the same cluster) is calculated for each class of terms, which must be no less than the clustering threshold of the main scenario to which the class belongs (e.g., if a class mainly belongs to the CS scenario, the intra-cluster similarity must be ≥0.7); at the same time, the "inter-cluster minimum bidirectional semantic similarity" (the minimum bidirectional similarity of term pairs between different classes) is calculated, which must be lower than the global threshold (e.g., <0.65); for classes that do not meet the verification conditions (e.g., the intra-cluster similarity is too low). After splitting, the clusters are re-clustered; after verification, each clustering result is assigned a "concept identifier" (format: "concept type-scenario main class-serial number", such as "C-USR-CS-001" for the user-related concept CS scenario as the main class). The term with the highest frequency of occurrence and the strongest cross-scenario universality in the class is selected as the "core concept term" (such as "user" as the core term for the "user", "customer" and "consumer" clusters), and "concept layer data" is generated - each record of this data contains "concept identifier", "core concept term", "synonym / near-synonym term list", "main scenario", and "average similarity within the class".

[0045] Preferably, the specific implementation process of step 212 is as follows: First, taking the "concept layer data" (generated in step 211, containing information such as "concept identifier," "core concept terminology," and "main associated scenario") as the processing object, and combining it with the "enterprise domain knowledge system" (such as being constructed according to a three-level architecture of "business domain - business entity - entity attribute," where the business domain includes customer service domain, supply chain domain, product development domain, etc.), the "concept scenario-based classification and top-level framework construction" is performed: extract the "main associated scenario" of each concept in the "concept layer data" and map it to the corresponding business domain (such as CS scenario). Concepts are mapped to the customer service domain, and SC scenario concepts are mapped to the supply chain domain; cross-scenario concepts (such as "time" and "amount") are categorized into the "common business domain"; based on the hierarchical relationship of business domains (such as the "supply chain domain" including "procurement subdomain", "warehousing subdomain", and "logistics subdomain"), a "top-level concept classification framework" is built. Each node in the framework corresponds to a business domain or subdomain, and the concepts of that domain are attached to the nodes, generating a "scenario-based concept classification framework"; this framework provides a structured foundation for subsequent relationship design, which is different from the traditional concept framework without scenario division, making the ontology more in line with actual business.

[0046] Preferably, in the specific technical implementation of step 212, based on the "scenario-based concept classification framework," a "hyper-lower relationship between concepts" is designed: First, for concepts within the same business subdomain, a preliminary candidate hyper-lower relationship is determined through the "domain expert rule base" (containing hierarchical definitions within the business domain, such as "raw material purchase order" belonging to "purchase order" in the "purchasing subdomain," and "purchase order" belonging to "order"); then, combined with the "intra-class average similarity" and "bidirectional semantic similarity matrix" (generated in step 211) in the "concept layer data," the semantic inclusion degree of the hyper-level concept and the hypo-level concept in the candidate relationship (such as the semantic inclusion degree of "order" to "purchase order") is calculated. Inclusion degree = bidirectional semantic similarity of the core terms of the two concepts × 0.8 + domain rule matching degree × 0.2); set a semantic inclusion degree threshold (such as a threshold of 0.7 within the same subdomain and a threshold of 0.6 across subdomains), and filter candidate relations that exceed the threshold as valid superior-subordinate relations (such as "order" being the superior concept of "purchase order"); for concepts across business domains, only "common business domain concepts" are allowed as superior concepts of other domain concepts (such as "time" being the superior concept of "order creation time"), generating an "initial set of superior-subordinate relations"; this process combines rules and semantics to avoid the lack of flexibility caused by relying solely on expert rules in the traditional way.

[0047] Preferably, in a scenario, when implementing step 212, for concepts in the "concept layer data" that cross scenarios or subdomains, an "equivalence relation between concepts" is designed: First, concepts with overlap in the "synonymous / near-synonymous term lists" of the "concept layer data" (e.g., the term lists of "customer" in the CS scenario and "user" in the SC scenario both contain "consumer") are extracted as equivalent candidate concept pairs; the "scenario-adapted BERT model" (generated in step 211) is called to calculate the "cross-scenario bidirectional semantic similarity" between the two concepts in the candidate pair (the method is the same as the bidirectional calculation in step 211, with the weight tilted 0.5 towards each scenario); combined with the "domain" The equivalence rules in the "knowledge system" (such as "the 'customer' in the customer service domain and the 'user' in the supply chain domain are equivalent in the transaction scenario") generate an "equivalence relation confidence score" (= cross-scenario bidirectional semantic similarity × 0.6 + rule matching score × 0.4); set an equivalence relation threshold (such as 0.75, which is higher than the hierarchical relation threshold to ensure equivalence), filter candidate pairs that exceed the threshold as valid equivalence relations, add an "applicable scenario description" (such as "customer ≡ user (transaction-related scenario)") to each equivalence relation, and generate an "equivalence relation set"; this design differs from traditional unconditional equivalence relations by improving the accuracy of equivalence through scenario constraints.

[0048] Preferably, in the specific implementation of step 212, based on the "scenario-based concept classification framework" and hierarchical and equivalence relationships, "concept association attributes" are designed: First, for concept pairs with business interactions (such as "user" and "order", "order" and "logistics node"), high-frequency association features (such as the association features of "user" and "order" being "order time" and "order amount") are extracted from the "unified feature set of entities" in the "standardized data" (generated in step 123) as candidate names for association attributes; for each candidate attribute, an "association direction" is defined (such as the attribute of "user" → "order" being "created", and the attribute of "order" → "user" being "created"); based on the attribute definition rules in the "domain knowledge system" (such as the association attribute of "user" and "work order" in the customer service domain being "submitted"), attribute names are filtered and standardized to generate a "candidate set of association attributes"; this process ensures that association attributes originate from actual data association and avoids abstract definitions that deviate from business.

[0049] Preferably, in the specific technical implementation of step 212, for each attribute in the "candidate set of associated attributes", "attribute constraint rules" are defined: First, domain constraint - clarifying the source concept to which the attribute belongs (e.g., the domain of "order time" is "user"); Second, value range constraint - clarifying the target concept to which the attribute points (e.g., the value range of "order time" is "time"); Third, data type constraint - based on the type of the corresponding feature in the "standardized data" (generated in step 122), the data type of the attribute is defined (e.g., "order time" is "date and time type", "order amount" is "numeric type (retain two decimal places)"); Fourth, scenario-based value constraint - combined with business scenario rules, the value range of the attribute is defined (e.g., in the CS scenario, the value range of the "user rating" attribute is "integers from 1 to 5", and in the SC scenario, the value range of the "order amount" attribute is "numerical value ≥ 0"); these constraint rules are bound to the attributes to generate a "set of associated attributes with constraints"; this constraint design takes into account both general types and specific scenario requirements, which is different from the traditional simple constraints that only define basic types.

[0050] Preferably, in the specific implementation of step 212, the "scenario-based concept classification framework," "initial set of hierarchical relationships," "set of equivalence relationships," and "set of constrained association attributes" are used as processing objects to perform "ontology structure integration and conflict verification": First, concepts, relationships, and attributes are classified according to the "Resource Description Framework." The ontology is organized in the form of triplets (subject-attribute-object) using the Framework (RDF) to generate "initial ontology structure data". Then, a "relationship conflict detection matrix" is constructed - the rows and columns of the matrix are concepts, and the elements at the intersection record the relationship type between concepts (hyper-hyper / equivalence / association), detecting conflicting relationships (such as the simultaneous existence of hyper-hyper and equivalence relationships, and the cyclical hyper-hyper relationship "concept A→concept B→concept A"). For conflicting relationships, priority is determined by the "domain expert rule base" (equivalence relationships have higher priority than hyper-hyper relationships, and explicitly defined relationships have higher priority than semantically inferred relationships) for correction. At the same time, the consistency of attribute constraints is verified (such as whether the domain of "order amount" is always the concept of "order", and whether the value range conforms to the data type constraints). After correction, "ontology structure data" is generated - this data contains the concept hierarchy, the relationships between concepts, and the associated attributes with constraints, and each element is associated with the "main scene" identifier, providing a structured ontology foundation for rule injection in the subsequent step 221.

[0051] Optionally, step S22 specifically includes: step 221, using ontology semantic encoding of concept reasoning rules, attribute constraint rules and relation derivation rules to form a rule-injected ontology model, and injecting the rules into the ontology structure data to generate rule-injected data;

[0052] Step 222: The ontology reasoning engine is used to perform conceptual-level iterative reinforcement, attribute constraint conflict elimination, and rule logic contradiction correction on the injected data to generate semantic web ontology data.

[0053] Preferably, the specific implementation process of step 221 is as follows: First, based on the "ontology structure data" (generated in step 212, including scenario-based concepts, relationships, and constrained associated attributes), a "rule requirement scenario-based analysis framework" is constructed. This framework is divided into two dimensions: "business scenario coding" (such as CS, SC, RD) and "rule application objects" (concepts / attributes / relationships). Each cell corresponds to specific rule requirements (such as the "user" concept in the CS scenario needing to support the reasoning of "complaining user → key user", and the "order amount" attribute in the SC scenario needing to restrict "pre-sale order amount ≤ actual paid order amount"). By parsing the business process records in the "standardized data" (such as order status transitions and user service work order processing trajectories), high-frequency rule trigger scenarios are extracted (such as automatically associating logistics orders after order payment), forming a "scenario-rule requirement list". This framework provides a targeted basis for subsequent rule design, which is different from the adaptation problem caused by ignoring scenario differences in traditional general rule design.

[0054] Preferably, in the specific technical implementation of step 221, based on the "scenario-rule requirement list," "concept reasoning rules" are designed and ontology semantic encoding is performed: For the hierarchical and equivalence relationships in the "concept layer data" (generated in step 212), combined with scenario-based reasoning requirements, three types of reasoning rules are defined: First, hierarchical transfer rules (e.g., "If concept A is a subordinate concept of concept B, and concept B is a subordinate concept of concept C, then concept A is a subordinate concept of concept C," and limited to "valid within the same business domain"); Second, equivalence extension rules (e.g., "If concept A is equivalent to concept B (applicable to scenario S), then the attributes of concept A can be mapped to concept B (within scenario S)"); Third, scenario-based derivation rules (e.g., in the CS scenario, "users with multiple complaints" is derivation into "users of key concern," with the rule condition being "the number of complaints ≥ 3 times and within 30 days"); the rule exchange format of Web Ontology Language (OWL) is adopted. The rules are encoded using Format (RIF), with each rule containing fields such as "Rule ID", "Preconditions (Scenario Constraints + Conceptual Relationships)", "Inference Conclusion", and "Applicable Scenario", generating an "Ontology Semantic Encoded Conceptual Reasoning Rule Set".

[0055] Preferably, in a specific implementation of step 221 in a scenario, for the "constrained set of associated attributes" (generated in step 212), "attribute constraint rules" are designed and scenario-based dynamic constraints are strengthened: Based on the basic constraints (domain, value range, data type) in step 212, three new types of scenario-based rules are added—first, dynamic value constraints (e.g., for the "order discount rate" attribute in the SC scenario, the value range is "0.5-0.9" in the "promotion scenario" and "0.95-1.0" in the "regular scenario"); second, multi-source consistency constraints (e.g., for the same "user mobile phone number" attribute, the value range is "0.5-0.9" in the CRM system (Customer Relationship Management, Customer...). Data from RelationshipManagement has higher priority than crawled data; in case of conflict, the higher priority data prevails. Third, time-dependent constraints (such as the "product version number" attribute in the RD scenario, which is "Vx.yz-beta" before release and "Vx.yz" after release) also use RIF format encoding. The "constraint conditions" in the rules are associated with the "business scenario encoding" and the "timestamp range" to generate an "attribute constraint rule set with ontology semantic encoding". This rule set is different from traditional static constraints and improves the scenario adaptability of attribute constraints through dynamic conditions.

[0056] Preferably, in the specific implementation of step 221, based on the "set of relationships between concepts" (generated in step 212), "relationship deduction rules" are designed and cross-scenario associations are implemented: For the association attributes between concepts, two types of deduction rules are defined—first, relationship transfer rules (such as "user A submits work order B, work order B is associated with product C, then user A uses product C", and marked "valid in CS scenario"); second, scenario cross-deduction rules (such as "order A contains product B" in SC scenario and "product B belongs to series C" in RD scenario, deducing "order A is associated with series C", the rule premise must satisfy "the series to which product B belongs is defined consistently in the two scenarios"); when encoding the rules, a "relationship confidence" parameter is introduced (based on the accuracy of relationship deduction in historical data, such as setting the confidence of order-product association deduction in SC scenario to 0.9, and cross-scenario deduction to 0.7), generating an "ontology semantically encoded set of relationship deduction rules"; this design fills the limitations of single-scenario relationships through cross-scenario rules, and at the same time uses confidence to quantify the reliability of deduction.

[0057] Preferably, in the specific technical implementation of step 221, the “conceptual reasoning rule set,” “attribute constraint rule set,” and “relationship derivation rule set” of ontology semantic encoding are used as processing objects to construct a “rule-injection ontology model.” First, a “rule-ontology element association index” is established for the three types of rules—each rule is associated with the corresponding element in the “ontology structure data” through “applicable scenario” and “object ID” (such as concept identifier and attribute identifier) ​​(such as the “user” concept associated with the “key user” reasoning rule); then, a rule priority mechanism is designed, which sorts the rules according to “rule type” (attribute constraint rule > concept reasoning rule > relational derivation rule) and “scenario specificity” (scenario-specific rule > cross-scenario general rule) to avoid execution chaos when rules conflict; finally, the rule set, association index, and priority mechanism are encapsulated into a unified model, which uses Resource Description Framework (RDF) triple storage (rule-association-ontology element) to generate the “rule-injection ontology model.”

[0058] Preferably, in the specific implementation of step 221, the "rule injection ontology model" is injected into the "ontology structure data" to generate "rule injection data": through the "rule-ontology element association index", each rule in the rule set is bound to the corresponding concept, attribute or relationship in the ontology structure (such as binding the "order amount ≥ 0" constraint rule to the "amount" attribute of the "order" concept); for cross-scenario rules, rule mapping nodes are established in the "common business domain" concept layer of the ontology structure (such as associating the "time" concept with the "time format unification" rule across scenarios); after injection, a four-dimensional data structure containing "concept hierarchy + relationship network + attribute constraint + rule set" is generated, namely "rule injection data"; in this data, the rules and ontology elements form an organic whole, rather than being independently attached, ensuring that the subsequent inference engine can directly call the rules based on the ontology structure.

[0059] Preferably, the specific implementation process of step 222 is as follows: Taking the "rule injection data" (generated in step 221, including the scenario-based ontology structure, three types of rule sets, and rule-ontology association index) as the processing object, the ontology reasoning engine is first configured in a scenario-based manner—loading the "rule priority mechanism" (attribute constraint rules > concept reasoning rules > relation derivation rules) and "scenario-rule requirement list" from step 221, splitting the engine reasoning modules according to "business scenario codes" (CS, SC, RD), with each module only loading the rules of the corresponding scenario (e.g., the CS module loads "user complaint derived rules", and the SC module loads "order amount constraint rules"), while retaining the "public business domain rule call interface" (only allowing cross-module calls of common concept rules such as "time" and "amount"), generating a "scenario-based configuration ontology reasoning engine"; this configuration differs from the traditional general reasoning engine, avoiding reasoning deviations caused by cross-scenario rule interference through scenario isolation and targeted rule loading, providing an adaptable engine foundation for the subsequent three-step optimization.

[0060] Preferably, in the specific technical implementation of step 222, "concept hierarchical loop reinforcement" is performed through the "scenario-based configuration ontology reasoning engine": First, the engine starts the "hierarchical loop detection algorithm" for the "scenario-based concept classification framework" (generated in step 212) in the "rule injection data"—traversing the hierarchical relationship of concepts within each business domain (the "initial hierarchical relationship set" generated in step 212), and constructing a "concept hierarchical directed graph" (nodes in the graph are concepts, and directed edges are "superior → subordinate" relationships); through depth-first search (Depth-First... Search (DFS) detects cyclic paths (such as "concept A → concept B → concept A") in the graph and marks them as "hierarchical cyclic concept groups". For cyclic groups within the same business domain, combining the "intra-class average similarity" of "concept layer data" and the "domain expert rule base", the concept with a broader semantic coverage is retained as the superior concept (such as when "purchase order" and "order" cycle, "order" is retained as the superior concept), and reverse edges are deleted. For cycles across business domains (which may only involve common business domain concepts), the superior status of common concepts is forcibly retained (such as when "time" and "order time" cycle, "time" is retained as the superior). After correction, a "non-cyclic concept hierarchy graph" is regenerated, and the hierarchy transitivity of all concepts is verified by the engine (such as "concept A → B → C" must satisfy the implicit superior relationship of "A → C"), generating a "reinforced concept hierarchy structure". This process improves the stability and semantic coherence of the concept hierarchy through cycle detection and scenario-based correction, avoiding the hierarchical breakage caused by simply deleting cyclic edges in the traditional method.

[0061] Preferably, in a scenario, when step 222 is specifically implemented, based on the "enhanced concept hierarchy structure," "attribute constraint conflict elimination" is performed: The engine first extracts the "constrained associated attribute set" (generated in step 212) from the "rule injection data," and for each attribute's constraint rule (the "attribute constraint rule set" in step 221), it traverses all instances of that attribute in the "rule injection data" (e.g., all order concept instances of the "order amount" attribute in the SC scenario); it starts "constraint conflict scanning"—comparing instance attribute values ​​with rule constraints (e.g., "order amount ≥ 0" "pre-sale order amount ≤ actual payment order amount"), marking instances that do not meet the constraints as "attribute conflict instances," and recording the conflict type (e.g., "numerical limit exceeded" "multi-source data contradiction"); for "numerical limit exceeded" conflicts (e.g., "order amount = -50" in the SC scenario), the engine calls the corresponding The scenario's "data traceability interface" (the "data source identifier" generated in step 11) traces back to the original data source (such as the ERP system order table) and obtains the corrected values ​​to replace conflicting values. For "multi-source data contradictions" (such as the same user's mobile phone number being "138XXXX" in the CS scenario and "139XXXX" in the SC scenario), according to the "multi-source consistency constraint rules" in step 221 (CRM system data has higher priority than crawler data), the attribute values ​​of the high-priority data source are retained. After all conflicts are corrected, the engine re-verifies the attribute constraint satisfaction to ensure that the conflict elimination rate reaches the scenario-specific threshold (such as the transaction-related attribute conflict elimination rate ≥98% in the SC scenario and the non-core attribute ≥90% in the CS scenario), generating an "attribute-free conflict ontology structure". This process avoids data loss caused by simply deleting conflicting data in the traditional way by combining traceability and rules to resolve conflicts.

[0062] Preferably, in the specific implementation of step 222, based on the "attribute-free conflict ontology structure," "rule logic contradiction correction" is performed: the engine first loads the three types of rule sets (conceptual reasoning, attribute constraints, and relation derivation) from the "rule injection data," and constructs a "rule logic dependency graph" (nodes in the graph are rules, and directed edges are the dependency relationships of "the conclusion of rule A → the premise of rule B"); the "contradiction detection module" is started, focusing on detecting two types of contradictions: First, rule premise conflicts (such as the conceptual reasoning rule "3 complaints → key user" and the attribute constraint rule "key user must meet 'user level ≥ 2'," which has a premise contradiction of "3 complaints but level = 1"); Second, rule conclusion conflicts (such as the relation derivation rule "order A → logistics B" and another derivation rule "order A → logistics C"); for premise conflicts, the engine combines the "rule logic dependency graph" with the "rule logic dependency graph." Then, the engine uses "priority" and "scenario-based value constraints" to correct the preconditions of low-priority rules (e.g., changing "3 complaints → key user" to "3 complaints and user level ≥ 2 → key user"). For conflicting conclusions, based on the "relationship confidence" parameter in step 221 (e.g., "order → logistics B" confidence 0.9, "order → logistics C" confidence 0.6), high-confidence rules are retained, and low-confidence rules are deleted or corrected (e.g., changing "order → logistics C" to "order → logistics C (only applicable to pre-sale orders)"). After the contradiction is corrected, the engine performs "rule linkage test" (inputting typical scenario data to verify that there are no contradictions in multi-rule collaborative reasoning), ensuring the consistency of rule logic and generating "rule-free contradiction ontology data". This correction process solves the problem of linkage contradictions that are difficult to detect by traditional isolated rule detection through dependency analysis and confidence ranking.

[0063] Preferably, in the specific technical implementation of step 222, the "uncontradictory ontology data" is taken as the processing object, and "overall consistency verification and semantic web ontology data generation" are performed: First, the "scenario-based configuration ontology reasoning engine" performs full-scenario linkage verification on the data—inputting typical entity instances of "standardized data" in each business scenario module (such as "complaint user instance" in CS scenario, "pre-sale order instance" in SC scenario) to verify the collaborative effectiveness of concept hierarchy, attribute constraints, and rule reasoning (such as "complaint user instance" can be correctly derived into "key user" and meets the attribute constraints of "key user"); after the verification is passed, the "enhanced concept hierarchy structure", "unconflicted attribute ontology structure", and "uncontradictory ontology data" are integrated, and the "rule-ontology association index" and "data source identifier mapping" (associating ontology elements with the original data source) are supplemented to form three-dimensional ontology data containing "scenario-based concept system + constraint attribute network + consistent rule set"; finally, according to the ontology network language (Web Ontology) The data is stored in the standard OWL (Semantic Web Language) format, with fields including "concept ID-scenario code-attribute constraint-rule ID-associated instance identifier", generating "semantic web ontology data". This data can directly provide concept definitions and attribute constraints for entity extraction in step S3, and provide a unified concept layer foundation for semantic mapping in step S4. Its scenario-based and consistent design significantly improves the semantic synergy of subsequent integration.

[0064] Optionally, step S3 specifically includes: Step 31: Based on the conceptual definition and attribute constraints of the semantic web ontology data, extract entities and their attribute values ​​from the standardized data through the named entity recognition model, and generate entity attribute data with traceability information by combining the data source identifier; Step 32: Based on the entity attribute data with traceability information, generate instance-layer structured knowledge graph data with semantic annotation.

[0065] Preferably, the specific implementation process of step 31 is as follows: First, based on the "semantic web ontology data" (generated in step 222, including the scenario-based concept system, constraint attribute network, and consistent rule set), extract the "scenario-based concept-attribute constraint lookup table"—classified by "business scenario code" (such as CS, SC, RD). Each record contains "concept identifier," "core concept terminology," "associated attribute list" (including attribute domain, value domain, and data type constraints), and "rule ID association" (corresponding to the attribute constraint rules in step 221). For example, in the SC scenario, the lookup table record for the concept of "order" is "Concept identifier: C-ORD-SC-001; Core terminology: order; Associated attributes: order ID (string, length 10-20), amount (numerical, ≥0); Rule ID: R-ATTR-SC-005 (amount constraint)". This lookup table provides clear ontology guidance for entity extraction, avoiding the problem of traditional entity recognition being disconnected from ontology concepts.

[0066] Preferably, in the specific technical implementation of step 31, the "standardized data" (generated in step S1, including multimodal data, temporary entity identifiers, and data source identifiers) undergoes "scenario-modal classification preprocessing": the standardized data is split into scenario-specific datasets according to "business scenario coding" (such as the CS scenario dataset containing user complaint text, customer service work orders, etc.); within each scenario dataset, it is further classified according to data modality (structured, semi-structured, unstructured). Structured data retains the field-value pairs of the "unified entity feature set" (generated in steps 123), semi-structured data extracts tagged content (such as JSON key-value pairs), and unstructured data retains the text or OCR conversion results and the corresponding "semantic description tags"; a "scenario-modal entity extraction data source" is generated to ensure that subsequent entity recognition is processed in a scenario- and modality-specific manner.

[0067] Preferably, in a scenario, when implementing step 31, an "ontology-adapted named entity recognition model" is constructed: based on a pre-trained named entity recognition (NER) model (such as a bidirectional long short-term memory network-conditional random field). The Field, BiLSTM-CRF, is fine-tuned using labeled samples (including temporary entity identifiers and corresponding concepts) from the "Scene-Modal Entity Extraction Data Source" and the "Scene-based Concept-Attribute Constraint Lookup Table." A "Concept Matching Validation Module" is added to the model output layer to compare the identified entity candidates with the core terms and synonym / near-synonym list of the corresponding scene's concepts (generated in step 211). Only candidates with a matching degree exceeding the scene threshold (e.g., matching degree of user-related entities ≥ 0.75 in CS scene, and order-related entities ≥ 0.8 in SC scene) are retained. At the same time, for entities in unstructured text, "contextual semantic features" (e.g., "order" often co-occurs with "amount" and "date") are combined to improve recognition accuracy. A "Scene-based Adapted NER Model Set" (one model for each scene) is generated, which, unlike the general NER model, has a higher consistency between its recognition results and ontology concepts.

[0068] Preferably, in the specific implementation of step 31, the "scenario-adapted NER model set" is used to extract entities: for each scenario data in the "scenario-modal entity extraction data source", the corresponding scenario's NER model is called - for structured data, the fields in the "unified entity feature set" are directly matched with core conceptual terms (such as the "user_id" field matching the "user" concept), and the field values ​​are extracted as entity candidates; for unstructured text, the model identifies noun phrases and associates them with corresponding concepts (such as "May 2024 orders" being identified as the "order" concept entity); the extracted entity candidates are classified according to "concept identifiers", and the entity text descriptions (such as "order OD202405" and "user 1001") and the "temporary entity identifiers" of the data in which they are located are recorded (generated in steps 123), generating the "initial entity recognition result", the result containing the fields "scenario code - concept identifier - entity text - temporary identifier".

[0069] Preferably, in the specific technical implementation of step 31, based on the "scenario-concept-attribute constraint lookup table", entity attribute values ​​are extracted from the "initial entity recognition results" and constraint verification is performed: for each entity, its associated attribute features are extracted from the "scenario-modal entity extraction data source" (such as "amount = 500 yuan" and "creation time = 2024-05-20" associated with "order OD202405"); the attribute constraint rules in the lookup table are called (such as "amount ≥ 0" and "time format is YYYY-MM-DD") to verify whether the attribute values ​​meet the constraints—for attribute values ​​of structured data, the data type and value range are directly compared (such as "amount = -100" does not meet the "≥ 0" constraint); for attribute values ​​extracted from unstructured data (such as "order amount is about 500 yuan" in the text), they are converted to the standard format ("500 yuan") and then verified; attribute values ​​that do not meet the constraints are marked as "to be corrected" and the reasons for the conflict are recorded (such as "value exceeds the limit" and "format error"), and "attribute value constraint verification results" are generated.

[0070] Preferably, in the specific implementation of step 31, the attribute values ​​to be corrected in the "Attribute Value Constraint Verification Result" are modified according to the scenario: for "Format Error" (such as time "2024 / 5 / 20"), the data type constraint is converted to the standard format ("2024-05-20") according to the reference table; for "Value Exceeds Limit" (such as order amount = -100), the "Data Source Identifier" (generated in step 11) is called to trace back to the original data source. If the original data is correct, it is retained and marked as "Outlier (Reliable Source)". If the original data is incorrect, a reasonable value is filled based on the attribute distribution of the same type of entity in the same scenario (such as the average order amount of 300 yuan in the SC scenario) and marked as "Corrected Value (Unreliable Source)". After correction, the data is re-verified to ensure that the proportion of attribute values ​​that meet the constraints reaches the scenario requirements (such as core attributes ≥95% in the SC scenario and ≥90% in the CS scenario), and "Constraint Compliant Entity Attribute Data" is generated.

[0071] Preferably, in the specific technical implementation of step 31, the "constrained compliant entity attribute data" is associated with the "data source identifier" to generate "entity attribute data with traceability information": "Source chain" information is added to each entity and its attribute value—including the original data source identifier (e.g., "ERP system - order table - 202405"), data preprocessing records (e.g., "step 121 cleaning - step 123 cross-modal association"), entity recognition model identifier (e.g., "NER-SC-001 model"), and attribute value correction records (e.g., "no correction / format correction / numerical correction and reason"); the data format adopts a triplet extended form (entity-attribute-attribute value-traceability information), for example, "(order OD202405, amount, 500 yuan, Source: ERP system; Identification model: NER-SC-001; Uncorrected); This data contains both semantic information of entities and attributes and retains a complete traceability link, providing a reliable instance layer foundation for generating knowledge graph data in step 32, deeply integrating ontology constraint verification and full-link traceability, and improving the reliability and semantic consistency of entity attribute data.

[0072] Optionally, step S32 specifically includes: step 321, fusing entity type features, contextual semantic features, and ontology attribute rules into entity attribute data with traceability information to generate entity relationship data with confidence scores; step 322, constructing an entity association graph based on entity attribute similarity and contextual co-occurrence features to map different representations of the same entity to a unique entity identifier according to the entity relationship data, so as to generate semantically labeled instance-layer structured knowledge graph data.

[0073] Preferably, the specific implementation process of step 321 is as follows: First, taking "entity attribute data with traceability information" (generated in step 31, including entities, attribute values, traceability information, and associated concept identifiers) as the processing object, extract "entity type features"—by associating with the "scenario-based concept classification framework" in the "semantic web ontology data" (generated in step 222), obtain the "concept identifier," "main scenario," and "concept hierarchy relationship" of each entity (e.g., "complaint work order" belongs to the subordinate concept of "work order," and the scenario is CS); construct a "type feature vector" for each entity, with the vector dimension corresponding to the concept category in the ontology (e.g., user class, order class, work order class, etc.), and the element value being the confidence score of the entity belonging to the corresponding category (determined based on the matching degree between the entity and the concept in step 31, e.g., the confidence score of "user 1001" belonging to the "user" class is 0.95); generate an "entity type feature set," which provides a conceptual-level type basis for subsequent relationship judgment, which is different from the traditional type judgment that only relies on the entity name and is more in line with the semantic category defined by the ontology.

[0074] Preferably, in the specific technical implementation of step 321, for "entity attribute data with traceability information", "contextual semantic features" are extracted: for entities in structured data, the associated field values ​​of the record in which they are located are extracted (such as "User ID=1001" and "Logistics ID=LOG300" in the record in which "Order OD202405" is located) as structured context; for entities in unstructured text, text fragments of a preset length before and after the entity are extracted (such as "User 1001's Order OD202405 has been shipped" in "User 1001's Order OD202405 has been shipped" in the context of "User 1001's Order OD202405 ... (The following text includes "submitted" and "shipped"); The "scene-adapted BERT model" in step 211 is used to convert the context text into a "context semantic vector". The vector dimension is consistent with the model output (e.g., 768 dimensions). The value of each dimension represents the feature strength of the context in a specific semantic dimension. At the same time, the frequency of co-occurrence of entity pairs in the same context is counted (e.g., "user1001" and "order OD202405" co-occur 5 times) as co-occurrence feature value; and the "context semantic feature set" is generated by integrating the data, which includes the fields "entity pair - context vector - co-occurrence frequency" to provide semantic context support for relation extraction.

[0075] Preferably, in a scenario, when implementing step 321, the "constrained set of related attributes" (generated in step 212) and the "relationship derivation rule set" (generated in step 221) in the "semantic web ontology data" are called to construct an "ontology attribute rule matching library": rules are stored according to "business scenario encoding", each rule contains a "source concept-related attribute-target concept" triple (such as "user-submission-work order" in CS scenario, "order-containment-product" in SC scenario) and "rule confidence" (set in step 221, such as 0.9); for entity pairs in the "entity type feature set" (such as entity A belonging to "user"), the matching library is constructed. For entity B belonging to the "work order" class, retrieve the associated attributes (such as "submit") of the corresponding scenario from the matching library, and record the matching rule ID and rule confidence. For entity pairs that are not directly matched (such as "user" and "product"), perform indirect rule matching through the concept hierarchy relationship in the ontology (such as "user-purchase-order-contains-product"), and calculate the transitive confidence (such as 0.9×0.8=0.72). Generate "ontology rule matching result", which includes the fields "entity pair-matching rule-rule confidence". Introduce the relation rules defined in the ontology into entity relation extraction, avoiding the limitations of traditional relation extraction that are detached from domain knowledge.

[0076] Preferably, in the specific implementation of step 321, the "entity type feature set," "contextual semantic feature set," and "ontology rule matching results" are integrated to generate a "candidate set of entity relationships": First, entity pairs that satisfy "entity type matching" are selected—the type feature vector of entity A matches the domain concept of the associated attribute, and the type feature vector of entity B matches the value domain concept (e.g., the domain of the "user" type matches the domain of the "submit" attribute, and the value domain of the "work order" type matches the value domain), retaining entity pairs whose matching degree exceeds the scenario threshold (e.g., CS scenario ≥ 0.7, SC scenario ≥ 0.75); Second, for the selected entity pairs, the "contextual semantic similarity" is calculated—the weighted sum of the cosine similarity of the contextual semantic vectors of the entity pairs and the normalized value of the co-occurrence frequency (e.g., frequency / maximum frequency) (each weighted at 0.5); Finally, combined with the rule confidence in the "ontology rule matching results," a "comprehensive score for candidate relationships" (type matching degree × 0.3 + contextual semantic similarity × 0.3 + ...) is generated. Rule confidence is multiplied by 0.4. Entity pairs with a comprehensive score exceeding the global threshold (e.g., 0.6) are retained, and associated attributes are marked as candidate relationships (e.g., “User1001-Submit-Work OrderWO500”), generating an “Entity Relationship Candidate Set”.

[0077] Preferably, in the specific technical implementation of step 321, "multi-source tracing cross-validation" is performed on the "entity relationship candidate set" to generate "entity relationship data with confidence scores": "tracing information" of entity pairs in the candidate relationships is extracted (generated in step 31, including data source identifiers and correction records), and a "tracing consistency matrix" is constructed - the rows and columns of the matrix are the data sources of the entity pairs, and the elements at the intersection are the number of times the entity relationship appears in different data sources; the "tracing consistency score" (number of consistent occurrences / total number of occurrences) is calculated. If the score is ≥ the scenario tracing threshold (e.g., transaction relationship in SC scenario ≥ 0.8, service relationship in CS scenario ≥ 0.7), the comprehensive score of the candidate relationship is increased (e.g., by 0.1); if there are conflicting data sources (e.g., source A displays "user 1001- If a work order WO500 is submitted (source B has no such record), then the impact of low-priority conflicts is reduced based on the "data source priority" (set in step 221, such as CRM system > crawler data) (e.g., only retained when there is no conflict in high-priority sources). Finally, the "candidate relationship comprehensive score" and "source consistency score" are weighted and fused (weights 0.8 and 0.2) as the final confidence score of the entity relationship, generating "entity relationship data with confidence score". Each record contains "entity A - relationship - entity B - confidence - source verification result". This data provides a reliable relationship foundation for the entity association graph construction in step 322. Through multi-dimensional fusion of type, context, ontology rules and source verification, the semantic accuracy and credibility of entity relationships are significantly improved.

[0078] Preferably, the specific implementation process of step 322 is as follows: First, taking "entity attribute data with traceability information" (generated in step 31, including entity text description, key attribute values, and scenario coding) as the processing object, perform "entity key attribute extraction and standardization": For entity types in different business scenarios (such as "user" in the CS scenario, "order" in the SC scenario, and "part" in the RD scenario), call the "constrained association attribute set" in the "semantic web ontology data" (generated in step 222) to determine the "scenario-specific key attributes" of each type of entity (such as "phone number" and "user ID" for "user" in the CS scenario, "order number" and "transaction serial number" for "order" in the SC scenario, and "part number" and "model" for "part" in the RD scenario); perform format standardization on the extracted key attribute values ​​(such as "phone number" being standardized to an 11-digit numeric string, and "order number" being standardized to the format of "scenario prefix + date + serial number") to generate "entity standardized key attribute set"; this set provides a unified attribute basis for subsequent similarity calculation, which is different from the traditional attribute selection without scenario differences and improves the targeting of similarity calculation.

[0079] Preferably, in the specific technical implementation of step 322, based on the "standardized key attribute set of entities," the "entity attribute similarity" is calculated: a "scenario-based attribute similarity calculation model" is constructed, and the attribute weights are dynamically adjusted according to the entity type and scenario code (e.g., in the CS scenario, the weight of "phone number" for "user" is set to 0.6, and the weight of "user ID" is set to 0.4; in the SC scenario, the weight of "order number" for "order" is set to 0.8, and the weight of "transaction serial number" is set to 0.2); for any two entities (denoted as entity A and entity B), if they belong to the same entity type and have the same scenario code or have an equivalence relationship (e.g., "user" in the CS scenario is equivalent to "user" in the SC scenario), then the similarity is calculated for each type of key attribute (edit distance similarity is used for string types, relative error similarity is used for numerical types, and exact matching similarity is used for enumerated types); the "comprehensive entity attribute similarity" is obtained by weighted summation (e.g., the attribute similarity between entity A and entity B = "phone number" similarity × 0.6 + ... (User ID similarity × 0.4); generate an "Entity Attribute Similarity Matrix"—the rows and columns of the matrix are all entities in the "Entity Standardized Key Attribute Set", and the elements at the intersection are the comprehensive attribute similarity of the corresponding two entities; this matrix provides a quantitative basis for entity association and avoids the similarity bias caused by relying on a single attribute in the traditional way.

[0080] Preferably, in a scenario, when implementing step 322, a "co-occurrence matrix" is constructed by combining the "contextual co-occurrence features" in the "entity relationship data with confidence scores" (generated in step 321): Contextual co-occurrence information of entity pairs in "standardized data" (generated in step S1) is extracted—the co-occurrence frequency of two entities in the same text fragment, the same data record, or the same business process is statistically analyzed (e.g., "User 1001" and "Customer 1001" co-occur 20 times in a customer service dialogue in a CS scenario), and the "co-occurrence frequency normalization value" is calculated (normalized to the 0-1 range; a higher value indicates more frequent co-occurrence). Simultaneously, the "scenario-adapted BERT model" (generated in step 211) is called to calculate the "semantic relevance" (cosine similarity of context vectors) of the contextual text of the two entities; and the result is weighted and fused (co-occurrence frequency normalization value × 0.5 + ...). The semantic relevance is multiplied by 0.5 to obtain the "entity co-occurrence association strength"; an "entity co-occurrence association matrix" is generated - the rows and columns of the matrix are all entities, and the elements at the intersection are the co-occurrence association strength of the corresponding two entities; this matrix supplements the entity association evidence from the context level, forming a two-dimensional association basis with the "entity attribute similarity matrix".

[0081] Preferably, in the specific implementation of step 322, the "entity attribute similarity matrix" and the "entity co-occurrence association matrix" are integrated to construct an "entity association graph": Entities in the "entity standardized key attribute set" are used as graph nodes, and node attributes include entity text description, scene encoding, and standardized key attribute values; the weighted sum of "entity attribute comprehensive similarity" and "entity co-occurrence association strength" (each with a weight of 0.5) is used as the "association strength threshold" for edges between nodes, and a scene-specific association strength threshold is set (e.g., the user association threshold for the CS scene is set to 0.7, and the order association threshold for the SC scene is set to 0.7). The value is set to 0.8, and the threshold for associating parts in the RD scene is set to 0.85; edges with association strength exceeding the threshold are retained, and the "attribute similarity contribution value" and "co-occurrence association contribution value" of the edges are labeled; at the same time, the entity relationships in the "entity relationship data with confidence scores" (such as "user-submission-work order") are used as "semantic relationship edges" of the graph, and the confidence scores of the edges are labeled with the corresponding ontology association attributes (such as the "submission" attribute); an "initial entity association graph" is generated; this graph contains both attribute associations and semantic relationships, which is different from the traditional simple graph that only contains relationships, and the association dimensions are richer.

[0082] Preferably, in the specific technical implementation of step 322, "entity representation normalization and unique identifier mapping" is performed on the "initial entity association graph": an improved density-based spatial clustering (Density-Based Spatial Clustering of Applications with Noise, DBSCAN) algorithm is used to cluster the graph nodes—with entities as the clustering objects, and the fusion value of "entity attribute comprehensive similarity" and "co-occurrence association strength" as the distance metric (distance = 1 - fusion value). The clustering parameters are adjusted according to the scenario encoding (e.g., in the CS scenario, the "neighborhood radius Eps" for user clustering is set to 0.3, and the "core point threshold MinPts" is set to 3; in the SC scenario, the Eps for order clustering is set to 0.2, and the MinPts is set to 2). Each clustering result represents different representations of the same entity, and a "unique entity identifier" is assigned to each cluster. The format is "Entity Type Code - Scene Master Code - Cluster Sequence Number", such as "ENT-USR-CS-001" for the CS scene user cluster identifier. The textual descriptions of all entities within the cluster are mapped to this unique identifier. The standardized key attribute values ​​of entities within the cluster (retaining the attribute values ​​with the highest confidence or the highest source priority) and semantic relationship edges (merging the confidence scores of the same relationship and taking the average) are merged to generate a "normalized entity association graph". This process achieves a unified identifier for different descriptions of the same entity, avoiding the association break caused by the chaotic entity descriptions in traditional graphs.

[0083] Preferably, in the specific implementation of step 322, semantic annotations are added to the "normalized entity association graph" and "semantically annotated instance-layer structured knowledge graph data" is generated: The "scenario-based concept classification framework" and "concept identifiers" in the "semantic web ontology data" are called to annotate each "unique entity identifier" in the graph with the corresponding "ontology concept identifier" (e.g., "ENT-USR-CS-001" is annotated as "C-USR-CS-001") and "concept core term" (e.g., "user"); the semantic relationship edges are annotated with the corresponding "ontology association attribute identifier" (e.g., "submission" relationship is annotated as "ATTR-SUBMIT-CS-001") and "attribute constraint rules" (e.g., "submission time ≥ creation time"); simultaneously, the traceability information in the "entity attribute data with traceability information" is associated, and "data source identifier" and "preprocessing record" are added to each node and edge; according to the resource description framework (ResourceDescription)... The framework (RDF) triple format (unique entity identifier - ontology association attribute - associated entity unique identifier - semantic annotation - traceability information) is used to store and generate "semantically annotated instance-layer structured knowledge graph data". This data contains both instance-layer entity associations and ontology-layer semantic definitions. Through scenario-based clustering and ontology semantic annotation, a deep association between instance-layer data and concept-layer ontology is achieved, improving the semantic consistency of the knowledge graph.

[0084] Optionally, step S4 specifically includes: Step 41, constructing a semantic mapping candidate space to analyze the concept-entity semantic similarity between the semantic web ontology data and the structured knowledge graph data, and selecting concept-entity association pairs with similarity greater than a set similarity threshold from the concept-level features of the semantic web ontology data and the entity association features of the structured knowledge graph data to form an initial mapping candidate set; Step 42, constructing a dynamic mapping rule engine based on the initial mapping candidate set to perform cross-level semantic association modeling and generate a semantic association mapping network accordingly; Step 43, performing knowledge distillation-style rule optimization and adversarial conflict resolution on the semantic association mapping network to obtain an optimized semantic association mapping network; Step 44, performing incremental data real-time alignment and causal reasoning verification processing on the optimized semantic association mapping network to generate a data-woven semantic integration result.

[0085] Preferably, the specific implementation process of step 41 is as follows: First, taking "semantic web ontology data" (generated in step 222, including scenario-based concept system, concept hierarchy relationship, and attribute constraint rules) and "semantically labeled instance-layer structured knowledge graph data" (generated in step 322, including unique entity identifiers, entity association relationships, and ontology concept annotations) as processing objects, a "concept-entity feature extraction framework" is constructed—the processing units are divided according to "business scenario encoding" (such as CS, SC, RD), and concept features and entity features are extracted in each unit respectively; for the semantic web ontology data, the focus is on "concept hierarchy features"... The framework incorporates "characteristics" (e.g., "user" is a sub-concept of "natural person," and "complaining user" is a sub-concept of "user") and "conceptual attribute features" (e.g., "user" includes attributes such as "phone number" and "registration time"). For knowledge graph data, it focuses on "entity association features" (e.g., the entity "user1001" and "order OD2024" have a "submission" relationship) and "entity attribute features" (e.g., "user1001" has "phone number = 138XXXX"). This framework provides a contextualized feature foundation for subsequent similarity calculations, differing from traditional general feature extraction that ignores contextual differences, thus improving feature targeting.

[0086] Preferably, in the specific technical implementation of step 41, based on the "concept-entity feature extraction framework," "concept-level feature vectors" and "entity association feature vectors" are generated: For concept-level features, a "hierarchical path encoding method" is adopted—a hierarchical path (e.g., "business entity → natural person → user → complaining user") is constructed from the top-level concept (e.g., "business entity → natural person → user → complaining user") to itself, and the "concept identifier" of each concept in the path is converted into one-hot encoding. Encoding is used to construct a "concept-level feature vector" by concatenating elements in hierarchical order. The length of the vector is the total number of concepts in the domain, and an element value of 1 indicates that the path contains the concept, while 0 indicates that it does not. For entity association features, the "association relationship encoding method" is used—taking the entity as the center, extracting the directly associated entity types (such as "user 1001" associating with "order" and "work order" types) and the "ontology association attribute identifiers" of the association relationship (such as "submit" and "complaint"), which are also converted into one-hot encoding and concatenated to form an "entity association feature vector". The length of the vector is the total number of association attributes in the domain, and an element value of 1 indicates that the association exists, while 0 indicates that it does not exist. A "concept-entity feature vector set" is generated to provide a structured numerical basis for similarity calculation.

[0087] Preferably, in a scenario, when implementing step 41, the "concept-entity semantic similarity" is parsed, and a "multi-dimensional similarity matrix" is constructed: a "scenario-based weighted similarity calculation model" is designed, which includes three dimensions—first, term matching similarity: calculating the text similarity between the "core conceptual terms" of the concept (generated in step 212) and the "semantically labeled core conceptual terms" of the entity (generated in step 322) (using cosine similarity, based on word vectors generated by the "scenario-adapted BERT model" in step 211); second, attribute feature similarity: comparing the "associated attribute list" of the concept (generated in step 212) with the "standardized key attribute set" of the entity (generated in step 322), and counting the proportion of matched attributes (such as the "phone number" attribute of the "user" concept and the "phone number" of the entity "user1001"). "Attribute matching is counted as 1); Third, hierarchy-association feature similarity: calculate the cosine similarity between the "concept hierarchy feature vector" and the "entity association feature vector" to reflect the structural matching degree between the concept hierarchy and the entity association; assign scenario-based weights to the three dimensions (e.g., CS scenario term matching weight 0.4, attribute feature weight 0.3, hierarchy-association weight 0.3; SC scenario term matching weight 0.3, attribute feature weight 0.5, hierarchy-association weight 0.2), and sum them up to obtain the "concept-entity comprehensive semantic similarity"; generate a "multi-dimensional similarity matrix" - the matrix rows represent concepts in the semantic web ontology data, the columns represent entities in the knowledge graph data, and the elements at the intersection are the comprehensive semantic similarity of the corresponding concept-entity pairs; this matrix comprehensively quantifies the semantic association between concepts and entities, avoiding the one-sidedness of traditional single-dimensional similarity calculation.

[0088] Preferably, in the specific implementation of step 41, a "semantic mapping candidate space" is constructed: based on the "multi-dimensional similarity matrix", all possible "concept-entity association pairs" (each row and column intersection point in the matrix) are included, and the "scene matching information" (whether the scene to which the concept belongs and the scene to which the entity belongs are consistent or have an equivalent mapping, such as the "user" concept in the CS scene and the "buying user" entity scene in the SC scene are equivalent) and "feature contribution details" (single similarity values ​​of term matching, attribute features, and hierarchical-association features) of the association pairs are supplemented; for cross-scene association pairs (such as the "part" concept in the RD scene and the "product component" entity in the SC scene), an additional "scene mapping rule ID" (associated with the cross-scene relationship derivation rule in step 221) is marked; the generated "semantic mapping candidate space" covers all potential mapping relationships and supporting information, providing a complete candidate pool for subsequent screening, and enhancing the interpretability of candidate relationships through scene matching information and feature details.

[0089] Preferably, in the specific technical implementation of step 41, the "initial mapping candidate set" is selected from the "semantic mapping candidate space": a "scenario-based similarity threshold" is set—the threshold for concept-entity pairs within the same scenario is higher than that across scenarios (e.g., the threshold within a CS scenario is set to 0.7, and the threshold across scenarios is set to 0.6), and the threshold for core concepts (e.g., "order" and "user") is higher than that for non-core concepts (e.g., "order status tag" and "user preference"); the "multi-dimensional similarity matrix" is traversed, and "concept-entity association pairs" with a comprehensive semantic similarity greater than the corresponding threshold are selected; for cases where the same entity matches multiple concepts or the same concept matches multiple entities, the top N similarity rankings are retained. (N is set according to the amount of scenario data, such as N=3 for SC scenario and N=5 for CS scenario) to avoid information loss caused by a single mapping; add "similarity composition tags" (such as "high term matching" and "high attribute matching") and "scenario matching tags" (such as "same scenario" and "cross-scenario-equivalent") to the selected association pairs; generate an "initial mapping candidate set" containing the fields of "concept identifier - entity unique identifier - comprehensive semantic similarity - similarity composition tags - scenario matching tags"; this candidate set provides the initial input for the dynamic mapping rule engine in step 42, and its scenario-based threshold setting and multi-mapping retention mechanism balance the mapping accuracy and coverage.

[0090] Preferably, the specific implementation process of step 42 is as follows: Taking the "initial mapping candidate set" (generated in step 41, including concept-entity association pairs, comprehensive semantic similarity, scene matching tags, etc.) as the core input, firstly extract the "dynamic rule element set"—parse the "conceptual hierarchy path" (the hierarchical relationship of concepts generated in step 222, such as "business entity → user → complaining user"), "entity association network fragment" (the relationship between entities generated in step 322, such as "user 1001 - submit - work order WO500"), "similarity composition tag" (such as "high attribute matching" and "cross-scene - equivalence") and "scene encoding" of each association pair from the candidate set; classify these elements according to "concept type - entity type - scene combination", for example, "complaining user (concept) - CS scene user entity - same scene" is one category, and "product (concept) - SC scene commodity entity - cross-scene equivalence" is another category; the generated "dynamic rule element set" provides a scenario-based and type-based construction foundation for the rule engine. Unlike traditional general rule elements, its classification method is directly related to the core features of the mapping scene.

[0091] Preferably, in the specific technical implementation of step 42, a "dynamic mapping rule engine" is constructed based on the "dynamic rule element set": the engine includes three core components: a "rule template library," a "scenario adaptation module," and a "hierarchical association processor." The "rule template library" predefines three types of basic templates—direct mapping templates within the same scenario (suitable for highly similar association pairs within the same scenario, such as "concept core term = entity semantic annotation term"), cross-scenario equivalent mapping templates (suitable for cross-scenario equivalent association pairs, such as "concept A is equivalent to concept B → entity A maps to concept B"), and hierarchical transfer mapping templates (suitable for hierarchical relationships between concepts, such as "concept A is a subordinate of concept B → entity A is automatically associated with B when mapped to A"); the "scenario adaptation module" assigns scenario-based parameters to each template according to the scenario encoding of the "dynamic rule element set." (For example, the trigger threshold for the same scene template in the CS scene is set to 0.75, and that in the SC scene is set to 0.8), and the "relationship inference rule set" of the corresponding scene (generated in step 221) is loaded as a supplementary constraint; the "hierarchical association processor" is specifically designed to handle the interaction between concept hierarchy and entity association. For example, when concept A is the superior of concept B, it automatically adds a "potential association label" with B to the entity mapped to A; the generated "dynamic mapping rule engine" can dynamically select and adjust rules according to the scene and hierarchical features of the input elements, avoiding the insufficient adaptability of traditional static rule engines to complex scenes.

[0092] Preferably, in a scenario, when step 42 is specifically implemented, "cross-level semantic association modeling" is performed through the "dynamic mapping rule engine": First, the association pairs in the "initial mapping candidate set" are grouped into layers according to "conceptual level depth" (the path length from the top-level concept to the current concept, such as "user" having a depth of 2 and "complaint user" having a depth of 3) and "entity association density" (the ratio of the number of entity association edges to the total number of entities, such as the order entity having a higher association density); for the association pairs within each layer group, the corresponding rule template of the engine is called—the top-level / middle-level concepts with a depth of 1-2 preferentially use the "hierarchical transitive mapping template" to establish transitive associations with the lower-level concept entities with a depth of 3-4 (such as "business entity" indirectly associating "user 100" through "user"). 1) High-density groups with entity association density ≥ 0.6 prioritize the use of "direct mapping template in the same scenario" to strengthen the matching of direct relationships between entities and conceptual attributes (e.g., mapping the "inclusion" relationship between order entities to the "inclusion" attribute of the "order" concept); cross-scenario association pairs uniformly use "cross-scenario equivalence mapping template" and verify the consistency of cross-scenario rules through the "scenario adaptation module" (e.g., whether the equivalence rules of "parts" in RD scenario and "components" in SC scenario are valid in the association pair); during the modeling process, add "hierarchical transmission path" (e.g., "business entity → user → user 1001") and "rule matching identifier" (e.g., "hierarchical transmission template - R-TIER-002") to each newly generated association to generate "intermediate results of cross-hierarchical association".

[0093] Preferably, in the specific implementation of step 42, the "intermediate results of cross-level association" undergo "association strength quantification and network topology construction": based on the output of the "dynamic mapping rule engine," the "comprehensive association strength" of each cross-level association is calculated—integrating the "comprehensive semantic similarity" of the initial mapping (weight 0.5), the "matching confidence" of the rule template (e.g., the transmission confidence of the hierarchical transmission template = the product of the similarities of each level, weight 0.3), and the "scenario consistency score" (1 for the same scenario, 0.8 for cross-scenario equivalence, weight 0.2); for example, the association strength of "complaining user (concept) - user 1001 (entity)" = 0.85 (similarity) × 0.5 + 0.9 (hierarchical transmission confidence) × 0.3 + 1 (same scenario) × 0.2 = 0.87; Using the concepts of the semantic web ontology data as upper-level nodes and the entities of the knowledge graph data as lower-level nodes, and using "comprehensive association strength" as the edge weight, a "multi-level association topology graph" is constructed; in the graph, concept hierarchical relationship edges are retained between upper-level nodes (weight is the semantic similarity between concepts), entity association relationship edges are retained between lower-level nodes (weight is the relationship confidence in step 321), and cross-level association edges are between upper and lower-level nodes (weight is the comprehensive association strength); the generated "multi-level association topology graph" initially presents the cross-level association structure of the semantic web and the knowledge graph.

[0094] Preferably, in the specific technical implementation of step 42, the rule logic of the "multi-level association topology graph" and the "dynamic mapping rule engine" is integrated to generate a "semantic association mapping network": "rule basis label" (e.g., "direct mapping within the same scenario - rule R-DIR-001") and "scenario encoding identifier" (e.g., "CS-SC" indicating cross-CS and SC scenarios) are added to each edge in the topology graph; for upper-level concept nodes, their "concept attribute constraint rules" are associated (generated in step 222); for lower-level entity nodes, their "entity traceability information" is associated (generated in step 31); a "network dynamic update interface" is set to record the parameter adjustment logs of the rule engine (e.g., field...). (Scene threshold modification, template addition) so that it can be called when subsequent incremental data is accessed; the final generated "semantic association mapping network" contains a three-dimensional structure of "concept layer - entity layer - cross-level association", and each association is accompanied by intensity quantification value, rule basis and scene information. It not only realizes the structured association between semantic web ontology data and knowledge graph data, but also retains the dynamic interpretability of mapping rules. This network provides a complete association structure and rule foundation for rule optimization in step 43. Through the combination of dynamic rule engine and cross-level topology modeling, it breaks through the traditional static mapping network's neglect of hierarchical relationships and scene differences, making semantic association more in line with the actual semantic logic of business data.

[0095] Preferably, the specific implementation process of step 43 is as follows: Taking the "semantic association mapping network" (generated in step 42, including concept layer nodes, entity layer nodes, cross-level association edges and rule basis) as the processing object, firstly, "rule extraction and structured representation" is executed: traverse the cross-level association edges in the network, extract the "dynamic mapping rule engine" rule corresponding to each edge (such as "direct mapping rule in the same scene R-DIR-001" and "hierarchical transfer rule R-TIER-002"), and record the "triggering condition" (such as "comprehensive semantic similarity ≥ 0.75") and "association" of the rule. The rules are categorized into "strength calculation logic" (such as weight allocation formula) and "scenario applicability" (such as CS scenario, cross-SC-RD scenario); these rules are classified according to "rule type - scenario code" to generate an "original rule set". Each rule is accompanied by "number of covered associated edges" (the total number of associated edges triggered by the rule in the network) and "average association strength" (the average strength of associated edges triggered by the rule); this set provides complete initial rule material for subsequent rule optimization. Unlike traditional rule sets that rely solely on manually defined rules, its rules are directly derived from the actual mapping network and are more in line with the semantic features of the data.

[0096] Preferably, in the specific technical implementation of step 43, "knowledge distillation-style rule optimization" is performed on the "original rule set": a "rule importance scoring model" is constructed to quantify the value of rules from three dimensions—first, rule coverage (the proportion of covered associated edges to the total number of network edges, weight 0.4); second, association strength contribution (the average strength of associated edges triggered by the rule, weight 0.3); third, scenario necessity (the degree to which a rule is irreplaceable in its scenario; if no other rule covers the associated pairs in the scenario, the score is high, weight 0.3); for example, the "direct mapping rule R-DIR-001 in the same scenario" has a coverage of 0.6, an average strength of 0.8, and a necessity of 0.9 in the CS scenario, then the importance score = 0.6 × 0.4 + 0.8 × 0.3 + 0.9 × 0.3 = 0.75; Sort by score from high to low, and retain the top M% (M is set according to the scene complexity, 30% for core scenes such as SC, and 50% for non-core scenes such as RD) as "core rules"; For the remaining rules, if they are logically equivalent to the core rules (e.g., the trigger conditions and results of "cross-scene equivalent mapping rule A" and "cross-scene equivalent mapping rule B" are consistent), they are merged into "merged rules" (retaining the parameters with higher average strength); Generate a "distilled core rule set" containing the fields "rule ID - trigger condition - optimized parameters - covered scene - importance score"; This process filters core rules by quantitative scoring, avoiding excessive network complexity caused by redundant rules in traditional rule optimization.

[0097] Preferably, in a scenario, when step 43 is specifically implemented, the association edges of the "semantic association mapping network" are optimized based on the "distilled core rule set": First, the association edges triggered by the "core rules" in the network are retained. For the association edges triggered by the "merging rules", their "rule basis label" is updated to the merged rule ID, and the association strength is recalculated using the parameters of the merged rules. Second, low-importance association edges triggered by "non-core and unmerged rules" (association strength is lower than the minimum threshold of the scenario, such as 0.5 in the CS scenario) are deleted. For the retained association edges, the "comprehensive association strength" is recalculated based on the optimized parameters of the core rules (such as the adjusted weight allocation) to ensure that the strength value is consistent with the rule optimization result. At the same time, "core rule association labels" (such as "association core rule R-DIR-001") are added to the concept layer nodes and entity layer nodes in the network to record the number of times the node is covered by the core rule. A "rule-optimized association network" is generated, which reduces redundancy while retaining the core semantic association, and the rule basis of the association edges is more concentrated.

[0098] Preferably, in the specific implementation of step 43, the "conflict identification and classification" of the "rule-optimized association network" is performed: a "multi-dimensional conflict detection model" is designed to identify three typical conflicts—first, concept-entity mapping conflict (the same entity is mapped to two semantically contradictory concepts simultaneously, such as the entity "user1001" being mapped to both "complaining user" and "VIP user", and the two concepts are mutually exclusive in the ontology); second, logical conflict of association strength (the association strength of parent and child concepts to the same entity violates the hierarchical transmission rule, such as the strength of the "user" concept and entity being 0.6, while the strength of its subordinate concept "complaining user" with that entity is 0). 5. Violation of the rule that "the strength of the subordinate concept should be greater than or equal to the strength of the superior concept"); Third, cross-scenario rule conflict (the mapping results of the same association pair are contradictory in different scenarios, such as entity A mapping to concept X in the SC scenario and entity A mapping to concept Y in the RD scenario, and X and Y have no equivalent relationship); For the detected conflict, record "conflict type - ID of the associated edge - identifier of the associated concept / entity - source of conflict evidence" (such as ontology mutual exclusion rules, hierarchical transmission rules) to generate a "conflict identification result set"; This model improves the targeting of conflict identification by combining ontology rules and network structure features, and avoids the missed detection of conflicts that rely solely on a single feature in the traditional way.

[0099] Preferably, in the specific technical implementation of step 43, an "adversarial conflict resolution mechanism" is used to process the "conflict identification result set": a "conflict resolution adversarial network" is constructed, which includes two modules: "evidence extractor" and "decision arbitrator". The "Evidence Extractor" extracts multi-source evidence for conflict-related edges—"conceptual relationship evidence" at the ontology level (e.g., whether two concepts are mutually exclusive or have a hierarchical relationship), "entity attribute evidence" at the knowledge graph level (e.g., whether entity attribute values ​​better conform to the attribute constraints of a certain concept), and "data source reliability evidence" at the tracing level (e.g., the data source priority of the entity involved in the related edge, generated in step 31). The "Decision Arbitrator" converts this evidence into a "support vector" (the vector dimension corresponds to each candidate mapping in the conflict, and the element value is the support of the evidence for the candidate mapping, ranging from 0 to 1). The optimal mapping is determined through adversarial training (simulating the game between different pieces of evidence). For example, for the mapping conflict of "User 1001", if the entity attribute evidence supports "complaining user" (support 0.8), the data source evidence is unbiased (support 0.5), and the ontology mutual exclusion rule excludes simultaneous mapping, then the arbitration result selects "complaining user". After resolution, the related edges of the optimal mapping are retained, and the conflict edges are deleted or weakened (the strength is reduced to below the scenario conflict threshold, such as 0.3), and the "resolution basis - evidence support - strength after resolution" is recorded; a "conflict resolution related network" is generated.

[0100] Preferably, in the specific implementation of step 43, the processing results of the "rule-optimized association network" and the "conflict-resolved association network" are integrated to generate an "optimized semantic association mapping network": the core association edges after rule optimization and the effective association edges after conflict resolution are retained, and duplicate concept-entity mappings are merged (retaining the association edges with the highest strength); an "optimization log" is added to the network to record the IDs of redundant rules deleted, the types and number of conflicts resolved, and changes in the coverage of core rules; the network's "dynamic update interface" parameters are updated, the distilled core rules are set as the default trigger rules, and the conflict resolution strategy is set as an automatic invocation item; the final "optimized semantic association mapping network" has higher semantic consistency (reduced conflict rate) and structural simplicity (reduced redundant edges), while retaining the integrity of key semantic associations; this network provides an optimized basic structure for incremental data processing in step 44, combining rule simplification from knowledge distillation with adversarial conflict resolution, which not only improves network efficiency but also ensures semantic accuracy through multi-source evidence arbitration, breaking through the traditional single optimization method's problem of balancing efficiency and consistency.

[0101] Preferably, the specific implementation process of step 44 is as follows: First, for the real-time data generation characteristics of multiple business scenarios in the "same data factory" (such as real-time generation of user consultation entities in the CS scenario and real-time generation of order entities in the SC scenario), based on the "optimized semantic association mapping network" (generated in step 43, including core rules and simplified association edges), an "incremental data real-time access framework" is constructed: This framework integrates a streaming data processing engine (such as Apache Flink, an open-source streaming processing framework), and receives incremental data through preset "scenario-based data access interfaces" (CS scenario connects to the real-time API of the customer service system, SC scenario connects to the Kafka queue of the order system, and RD scenario connects to the real-time logs of the design tool); the interface automatically parses the data format according to the data modality (structured, semi-structured, unstructured), extracts the "entity text description", "key attribute value", "data source identifier" and "scenario code" in the incremental data, and performs lightweight preprocessing consistent with step S1 (such as format standardization, core attribute extraction, avoiding repeated full preprocessing), and generates an "incremental entity feature set"; this framework realizes low-latency access of incremental data, which is different from the problem that traditional batch processing cannot cope with real-time data, and provides a real-time data source for subsequent real-time alignment.

[0102] Preferably, in the specific technical implementation of step 44, based on the "distilled core rule set" (generated in step 43) of the "incremental entity feature set" and the "optimized semantic association mapping network", "real-time alignment of incremental data" is performed: First, the core rules of the corresponding scenario are matched for the incremental entity (such as matching the incremental order entity of the SC scenario with the "direct mapping rule R-DIR-001 of the same scenario"), the "key attribute features" (such as order number and amount) and "scenario code" of the incremental entity are extracted, and the "real-time semantic similarity" is calculated with the concept nodes of the same scenario in the network (such as the concept of "order") (the multi-dimensional similarity calculation model of step 41 is reused, and non-core dimensions are simplified to improve speed); if the similarity is greater than the scene real-time alignment threshold (slightly lower than the batch threshold, such as the batch threshold of 0.8 for the SC scenario, the actual...), the real-time alignment is performed. If the threshold is 0.7, then "incremental association candidate edges" are generated (one end of the edge is the incremental entity, and the other end is the matching concept node, with the weight being the real-time semantic similarity); for incremental entities that already have an association (such as repeatedly accessed order entities), the "real-time update timestamp" and "association strength" of the association edge are updated (if the new similarity is higher than the original strength, it is replaced; otherwise, the original strength is retained); for incremental entities without a matching concept (such as new product entities), they are marked as "incremental entities to be labeled" and the manual assisted labeling process is triggered (only triggered in core scenarios, such as RD scenarios); the "incremental association candidate edges" and "labels to be labeled" are added to the "optimized semantic association mapping network" to generate the "real-time aligned association network"; this process ensures a balance between the real-time performance and accuracy of the alignment by reusing core rules and simplifying calculations.

[0103] Preferably, in a scenario, when step 44 is specifically implemented, a "scenario-based causal reasoning verification model" is constructed to verify the causal logic of the "real-time aligned association network": First, based on the "relationship derivation rule set" of the "semantic web ontology data" (generated in step 221) and the causal process of the business scenario (such as "user complaint → generate work order → work order processing → processing completed" in the CS scenario, and "user place order → payment → order confirmation → logistics delivery"), a "scenario causal template library" is constructed. Each template contains a "causal relationship chain" (such as "entity A - action X → entity B - action Y → entity C"), "causal direction constraints" (such as "payment" must be before "order confirmation"), and a "causal confidence threshold" (such as the causal chain confidence in the SC scenario must be ≥0.85); for example, the "order causal template" in the SC scenario is "user entity - place order → order entity - payment → order entity - confirmation → logistics entity - delivery". The process involves: 1) matching the edges of the "real-time aligned association network" to the corresponding causal template according to the scenario encoding; 2) extracting the "entity-relationship" subgraphs (e.g., subgraphs containing user, order, and logistics entities); 3) using a causal path search algorithm (e.g., breadth-first search) to check whether the subgraph conforms to the causal relationship chain and direction constraints of the template—if there is a "causal reversal" (e.g., "order confirmation" before "payment") or a "causal break" (e.g., no "order confirmation" after "payment"), it is marked as a "causal conflict subgraph"; 4) extracting the involved association edges (e.g., reverse association edges of "order confirmation → payment"), reducing their association strength (e.g., multiplying by a conflict coefficient of 0.5), and recording the "conflict reason" (e.g., "causal reversal - violation of SC scenario order process"); 5) generating a "causal verification post-association network," which filters abnormal associations through business causal logic, avoiding the problem of traditional semantic matching ignoring business processes.

[0104] Preferably, in the specific implementation of step 44, a "final verification of association consistency" is performed on the "causal verification-post-association network": the verification dimensions include three aspects—first, semantic consistency (the semantic matching degree between the concept and entity of the association edge still meets the scenario threshold, and there are no edges with excessively low strength due to causal adjustments); second, rule consistency (the rule basis of the association edge still belongs to the "distilled core rule set", and there are no associations caused by the failure of core rules); third, data consistency (the attribute values ​​of the incremental entity do not conflict with the attribute constraints of the association concept, such as the order amount still satisfying "≥0"); for association edges that do not meet the verification, they are marked as The "final pending edge" is identified, and corresponding processing is triggered based on the conflict type (delete if semantically inconsistent, rematch the core rules if rules are inconsistent, and trace back the data source to correct if data is inconsistent). After verification, all valid association edges, entity nodes, concept nodes, and tracing information (entity tracing in step 31, rule tracing in step 43, and real-time update tracing in step 44) of the "causal verification post-association network" are integrated to generate the "final semantic association mapping network". This network fully preserves the core associations, real-time incremental associations, and causal verification results between the semantic network and the knowledge graph, providing the final structural foundation for the generation of the integration results.

[0105] Preferably, in the specific technical implementation of step 44, the "semantic integration result of data weaving" is generated based on the "final semantic association mapping network": First, the integration result is organized according to the "Resource Description Framework (RDF)" triple format. The triple types include "concept-association-entity" (e.g., "order concept-mapping-order OD202405 entity"), "entity-relationship-entity" (e.g., "user 1001 entity-submission-work order WO500 entity"), and "concept-attribute-constraint" (e.g., "order concept-amount attribute-≥0 constraint"). Each triple is accompanied by "association strength", "rule basis", "scenario code", and "source information summary" (e.g., "data source: ERP system; update time: 20240520"). Second, "scenario-based integration result subsets" (e.g., CS scenario subsets) are generated according to business scenarios. The system comprises SC scenario subsets, each containing all triples for that scenario and "core association statistics" (such as the number of associated edges, average strength, and conflict rate). Finally, it provides an "integration result query interface" that supports queries by concept, entity, scenario, association strength, and other dimensions (e.g., querying "all entities associated with the SC scenario order concept"). The generated "semantic integration result of data weaving" achieves unified semantic association of multi-source data while retaining complete interpretability and traceability. It deeply integrates real-time incremental processing with business causal verification, breaking through the limitations of traditional static integration in dealing with dynamic data and process logic, and meeting the real-time and reliability requirements of enterprises for cross-scenario data analysis and decision-making.

Claims

1. A data weaving semantic integration method based on semantic web and knowledge graph, characterized in that, Includes the following steps: Step S1: Acquire multi-source heterogeneous data and preprocess it to obtain standardized data. The multi-source heterogeneous data includes structured data, semi-structured data and unstructured data from different business scenarios. The unstructured data includes user consultation texts from customer service scenarios and design specification documents from product development scenarios. Step S2: Inject rules into the standardized data to generate semantic web ontology data; Step S3: Extract entities and their attribute values ​​from the standardized data to generate structured knowledge graph data for the instance layer; Step S4: Establish a semantic association mapping network between semantic web ontology data and structured knowledge graph data, and generate semantic integration results of data weaving; Step S4 specifically involves: Step 41, constructing a semantic mapping candidate space to analyze the concept-entity semantic similarity between semantic web ontology data and structured knowledge graph data, and selecting concept-entity association pairs with similarity greater than a set similarity threshold from the concept-level features of semantic web ontology data and the entity association features of structured knowledge graph data to form an initial mapping candidate set. Step 42: Construct a dynamic mapping rule engine based on the initial mapping candidate set to perform cross-level semantic association modeling and generate a semantic association mapping network accordingly; Step 43: Perform knowledge distillation-based rule optimization and adversarial conflict resolution on the semantic association mapping network to obtain the optimized semantic association mapping network; Step 44: Perform incremental data real-time alignment and causal reasoning verification on the optimized semantic association mapping network to generate semantic integration results of data weaving.

2. The method of claim 1, wherein, Step S1 is as follows: Step 11: For structured data, semi-structured data and unstructured data from different business scenarios in the same data factory, aggregate them through distributed crawling and interface adaptation to generate multi-source heterogeneous data containing data source identifiers. Step 12: Perform predetermined standardization logic processing on the multi-source heterogeneous data containing data source identifiers to generate standardized data.

3. The method of claim 2, wherein, Step S12 is as follows: Step 121: Perform hierarchical cleaning on multi-source heterogeneous data containing data source identifiers to generate cleaned data; Step 122: After cleaning, the data format, measurement units and field naming rules are unified through a preset domain data dictionary to generate standardized intermediate data with semantic annotations; Step 123: Based on knowledge embedding rules, perform cross-modal semantic association on standardized intermediate data to extract semantic features pointing to the same business entity in different types of data, so as to generate standardized data.

4. The method of claim 1, wherein, Step S2 is as follows: Step 21: Extract core domain terms from standardized data to construct ontology structure data; Step 22: Form the rule injection ontology and inject the rule injection ontology into the ontology structure data to generate semantic web ontology data.

5. The method of claim 4, wherein, Step S21 is as follows: Step 211: Extract core domain terms from standardized data, and cluster synonyms / near-synonyms using bidirectional semantic similarity calculation to generate conceptual layer data; Step 212: Based on the domain knowledge system, design the hierarchical relationships, equivalence relationships and related attributes between concepts, define the domain, value range and data type constraint rules of the attributes, and construct ontology structure data for the concept layer data.

6. The method according to claim 4, characterized in that, Step S22 is as follows: Step 221: Use ontology semantic encoding concept reasoning rules, attribute constraint rules and relation derivation rules to form a rule injection ontology model, and inject the rules into the ontology structure data to generate rule injection data; Step 222: The ontology reasoning engine is used to perform conceptual-level iterative reinforcement, attribute constraint conflict elimination, and rule logic contradiction correction on the injected data to generate semantic web ontology data.

7. The method of claim 1, wherein, Step S3 is as follows: Step 31: Based on the conceptual definitions and attribute constraints of the semantic web ontology data, extract entities and their attribute values ​​from the standardized data through the named entity recognition model, and generate entity attribute data with traceability information by combining the data source identifier; Step 32: Based on the entity attribute data with traceability information, generate semantically labeled instance-layer structured knowledge graph data.

8. The method of claim 7, wherein, Step S32 is as follows: Step 321: Integrate entity type features, contextual semantic features, and ontology attribute rules into entity attribute data with traceability information to generate entity relationship data with confidence scores; Step 322: Construct an entity association graph based on entity attribute similarity and context co-occurrence features, so as to map different representations of the same entity to a unique entity identifier according to entity relationship data, in order to generate semantically labeled instance-layer structured knowledge graph data.

Images