Construction and evolution method and system of double-layer knowledge graph for LED industry

Abstract

The application relates to the technical field of enterprise-level knowledge graph construction and operation and maintenance, and provides a double-layer knowledge graph construction and evolution method and system for the LED industry. The method records source trace information, versions, effective conditions and evidence states for each data point in the multi-source data collection stage by constructing an industry ontology unified entity type and naming specification, and performs automatic detection of four types of conflicts, namely value type, numerical difference, relationship conclusion and naming consistency. The detected conflicts are marked and pushed into a pending decision queue. After receiving the decision feedback, the confirmed data points are written into the official knowledge base of the industry general layer or the brand specialized layer. Based on the affected range, a re-calculation task of the affected downstream project snapshot is generated, the problems of insufficient multi-source data conflict detection, consideration of industry general and brand special data, and source trace are solved, automatic conflict identification, blocking of inconsistent data download and traceability are realized.

Description

Technical Field

[0001] This application relates to the field of enterprise-level knowledge graph construction and operation technology, and in particular to a method and system for constructing and evolving a two-layer knowledge graph for the LED industry. Background Technology

[0002] Knowledge in the LED display industry is scattered across dozens of manufacturers' product manuals, computer-aided design blocks, internal company forms, and industry standards. Specifications for the same product differ across sources, and conclusions regarding the same compatibility relationship may be contradictory. Each business module maintains its own independent copy of data, leading to inconsistencies. Some solutions attempt to establish a unified product database, but either remain completely neutral, failing to meet the branding needs of enterprise users, or are tied to specific brands, sacrificing platform neutrality. Knowledge updates primarily rely on manual input and review, resulting in long update cycles and low accuracy.

[0003] Due to the lack of a unified data architecture and automated conflict detection mechanism, value conflicts, type conflicts, relationship conflicts, and naming conflicts between multi-source data can only be identified and adjudicated manually. The coverage and efficiency of conflict identification cannot meet actual business needs. When erroneous data enters downstream business modules, it causes inconsistencies between drawings, lists, and quotations, and the data source cannot be traced, making it impossible to locate the source of the problem when errors occur. At the same time, there is a lack of effective isolation and coverage mechanisms between industry-wide data and brand-specific data, and the problem of brand data contaminating the industry-wide knowledge base occurs frequently. Summary of the Invention

[0004] Therefore, it is necessary to provide a method and system for constructing and evolving a two-layer knowledge graph for the LED industry to solve the problems of lack of automatic detection of multi-source data conflicts, inability to balance industry-wide and brand-specific data, and untraceable data sources in existing technologies.

[0005] Firstly, this paper provides a method for constructing and evolving a two-layer knowledge graph for the LED industry. The method includes: constructing a display industry ontology, defining core entity types, relationship types between these core entity types, attribute types of these core entity types, and entity naming conventions within the ontology; collecting raw data from multiple data sources, associating each collected data point with entity identifiers, attribute identifiers, data versions, effective time or conditions, units of measurement, source traceability information, evidence status, and data status, where the status includes one or more of the following: confirmed, pending review, conflicting, and obsolete; performing field mapping, unit conversion, and naming normalization on the raw data to obtain standardized data points; and performing multi-source conflict detection on the standardized data points, where multi-source conflict detection includes detecting whether the value type of the same data point is consistent across different data sources when the entity identifier, attribute, version, effective condition, and unit of measurement meet comparability conditions, and detecting whether the value type of the same data point is consistent across different data sources. The system checks whether the value difference exceeds a preset threshold, whether the conclusions of the same compatibility relationship are contradictory in different data sources, and whether the naming of the same entity is consistent in different data sources. For data points with different versions or effective conditions, it records them as version differences or condition differences rather than numerical conflicts. When a conflict is detected, the state of the data point is marked as conflicted. When there are data points marked as conflicted, the system receives the ruling feedback on the conflicted state and updates the state of the data point to confirmed or obsolete based on the ruling feedback. The data points with the confirmed state, along with their source traceability information, version, effective conditions, and evidence status, are written into the formal knowledge base of the industry general layer or brand specialization layer. When there are new data sources or changes in the state of data points in the formal knowledge base, the system re-executes data collection, standardized mapping, and multi-source conflict detection, and generates the impact scope and recalculation tasks of the affected knowledge entities and downstream project snapshots.

[0006] Secondly, a two-layer knowledge graph construction and evolution system for the LED industry is provided. The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the above-mentioned two-layer knowledge graph construction and evolution method for the LED industry.

[0007] Thirdly, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for constructing and evolving a two-layer knowledge graph for the LED industry.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described method for constructing and evolving a two-layer knowledge graph for the LED industry.

[0009] This application constructs an ontology for the display industry, providing a unified expression framework and naming convention for product specifications and data fields from different manufacturers. This enables knowledge scattered across heterogeneous documents from multiple sources to be compared and conflict identified within the same system. During the multi-source data acquisition phase, each data point is recorded with its source identifier, acquisition time, version, effective conditions, evidence status, and data status, ensuring traceability of the data's origin and evolution. When data issues arise, the source can be located along the source chain. Based on this, automatic detection of four types of conflicts is performed: value type conflicts, numerical difference conflicts, relational conflicts, and naming conflicts. For data points with different versions or effective conditions, they are recorded as version differences or conditional differences rather than numerical conflicts. Detected conflicting data is marked and pushed into a pending adjudication queue, preventing inconsistent data from propagating to downstream business modules at the source. By receiving adjudication feedback and writing data points into the formal knowledge base based on the adjudication results, a continuously evolving knowledge loop is formed, enabling industry-wide knowledge and brand-specific knowledge to be stored separately and collaboratively within the same knowledge base. These features work synergistically to reduce the burden of manual identification of multi-source data conflicts, while ensuring data traceability and providing a consistent knowledge foundation for downstream business modules. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] in: Figure 1 This is a flowchart illustrating the method for constructing and evolving a two-layer knowledge graph for the LED industry, as described in this application. Figure 2 This is a schematic diagram of the modules of the two-layer knowledge graph construction and evolution system for the LED industry in this application embodiment; Figure 3 This is a structural block diagram of the computer device in the embodiments of this application; Figure 4 This is a structural block diagram of the computer device in the embodiments of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] Please see Figure 1 As shown, Figure 1 A flowchart illustrating the method for constructing and evolving a two-layer knowledge graph for the LED industry, provided in this application embodiment, includes the following steps: Step 01: Construct the display industry ontology, defining core entity types, relationship types between core entity types, attribute types of core entity types, and entity naming conventions within the industry ontology; Step 02: Collect raw data from multiple data sources, and associate each collected data point with the entity identifier, attribute identifier, data version, effective time or effective conditions, unit of measurement, source traceability information, evidence status, and data status. The status includes one or more of the following: confirmed status, pending review status, conflict status, and obsolete status. Perform field mapping, unit conversion, and naming normalization on the raw data to obtain standardized data points. Step 03: Perform multi-source conflict detection on standardized data points. Multi-source conflict detection includes detecting whether the value type of the same data point is consistent in different data sources when the entity identifier, attribute, version, effective conditions, and unit of measurement meet the comparability conditions; detecting whether the numerical difference of the same data point in different data sources exceeds a preset threshold; detecting whether the conclusions of the same compatibility relationship are opposite in different data sources; and detecting whether the naming of the same entity is consistent in different data sources. For data points with different versions or effective conditions, record them as version differences or condition differences rather than numerical conflicts; when a conflict is detected, mark the status of the data point as conflict state. Step 04: When there is a data point marked as conflicting, receive the decision feedback on the conflicting state, and update the status of the data point to confirmed or discarded based on the decision feedback. Step 05: Write the data points with the confirmed status, along with the corresponding source traceability information, version, effective conditions, and evidence status, into the formal knowledge base of the industry general layer or brand-specific layer. Step 06: When there is a new data source or the status of data points that have been written into the formal knowledge base changes, re-execute the steps of collecting raw data from multiple data sources, standardizing mapping, and multi-source conflict detection, generate the impact range of the affected knowledge entities and downstream project snapshots, and generate the recalculation task of the affected downstream project snapshots based on the impact range.

[0014] Specifically, in step 01, entity types, relationship types, attribute types, and naming conventions for the display industry are defined. Entity types include product entities (such as modules, receiver cards, and power supplies), relationship entities (such as compatibility and peer substitution), and attribute entities (such as physical parameters, electrical parameters, and geometric parameters). Relationship types define the association methods between entities, including compatibility relationships between receiver cards and modules, peer substitution relationships between different brands of products with the same function, and hierarchical relationships between product categories. Attribute types define the parameter dimensions possessed by each entity; for example, the width, height, and thickness of a module are physical parameters, while operating voltage and power consumption are electrical parameters. Entity naming conventions are used to unify the naming methods of different manufacturers for the same product, ensuring that the same entity can be identified as the same object in different data sources. In one implementation, the module naming convention is a combination of pixel pitch value, scan mode value, width value multiplied by height value, i.e., P2.5-32s-320x160 represents a module specification with a pixel pitch of 2.5 mm, a scan mode of 32 scans, a width of 320 mm, and a height of 160 mm.

[0015] For display screen control systems, the industry body records the maximum total load, maximum width, maximum height, data groups, and interface types of the receiving card; the output port types and quantities of the transmitting or video processing equipment; the single port and overall load capacity boundaries; the chassis slots of the modular splicing equipment; the configurable input / output boards; the board interfaces and redundancy capabilities; and the connection relationships between ports, fiber optic transceivers, cables, and upstream and downstream equipment. Data points corresponding to different hardware versions, firmware versions, or effective conditions of the same model are recorded separately and are not unconditionally merged.

[0016] In step 02, raw data is collected from multiple data sources, including manufacturer product manuals in portable document format (PDF), industry standard documents, internal spreadsheets, computer-aided design (CAD) blocks, web pages, and application programming interfaces (APIs). After collection, the raw data undergoes field mapping, unit conversion, and naming normalization to obtain standardized data points. For each collected data point, source traceability information, version, effective conditions, evidence status, and data status are recorded. Source traceability information includes source identifier, collection time, and collector; status includes four types: confirmed, pending review, conflicting, and obsolete. In one implementation, a module thickness of 12 mm is collected from manufacturer A's product manual. The source identifier is recorded as manufacturer A's manual, the collection time as July 2026, and the initial status is set to pending review. When the same module thickness of 12 mm is collected from an industry standard document, this data point is associated with two source references, forming a multi-source evidence chain.

[0017] In step 03, multi-source conflict detection is performed on standardized data points, covering four types of conflicts. The first is value type conflict, detecting whether the value type of the same data point is consistent across different data sources. For example, the same field might be a numeric type in one source but a string type in another. The second is value conflict, detecting whether the numerical difference of the same data point in different data sources exceeds a preset threshold when the entity identifier, attribute, version, effective conditions, and unit of measurement are consistent. For example, if the thickness of the same module is 12 mm and 11.5 mm in two sources, the difference rate is 4.2%, exceeding the preset threshold of 2%, resulting in a conflict. The third is relation conflict, detecting whether the conclusions of the same compatibility relationship are contradictory in different data sources. For example, one source claims that receiver card A is compatible with module B, while another source claims they are incompatible. The fourth is naming conflict, detecting whether the naming of the same entity is consistent across different data sources. For example, if the same specification module is named P2.5-320x160 in one source and P2.5-32s-320x160 in another, a naming conflict occurs when the same entity is determined to be the same entity after naming normalization but the naming is inconsistent. When any type of conflict is detected, the state of the data point is marked as conflicted and pushed into the pending adjudication queue to await manual or automated rule processing.

[0018] In step 04, when a data point marked as conflicting is detected, a decision feedback for that conflicting state is received. The decision feedback comes from manual operation by the auditor or from preset automatic decision rules. Based on the decision feedback, the data point's state is updated to either confirmed or obsolete. In one implementation, both Manufacturer A and the industry standard provide a thickness of 12 mm, while Distributor B provides a thickness of 11.5 mm. The auditor adopts the 12 mm thickness consistent with the majority of sources, and the data point's state is updated to confirmed. In another implementation, the auditor determines that data from a certain source contains an error and updates the data point's state to obsolete. After the decision feedback processing is complete, the conflict entries in the pending decision queue are cleared, and all data points obtain their final states.

[0019] In step 05, data points with a confirmed status, along with their corresponding source traceability information, version, effectiveness conditions, and evidence status, are written into the formal knowledge base of the industry general layer or brand-specific layer, forming an authoritative data source that can be used by downstream business modules. When writing to the formal knowledge base, the actual value, source identifier list, data version, effectiveness conditions, evidence status, level, collection time, collector, confirmation time, and reviewer information for each confirmed data point are completely stored. In one implementation, the 12mm thickness of the P2.5-32s-320x160 module is written into the industry general layer, simultaneously recording the source as both Manufacturer A's manual and industry standard document, along with the data version, effectiveness conditions, evidence status, confirmation time, and reviewer; brand-specific parameters are written into the corresponding brand-specific layer.

[0020] In step 06, changes in data sources and the status of data points already written to the formal knowledge base are continuously monitored. When a new data source is added, the steps of collecting raw data from multiple data sources, standardization mapping, and multi-source conflict detection are re-executed. When the status of data points already written to the formal knowledge base changes, for example, due to a newly discovered conflict causing a confirmed data point to be re-declared as obsolete, the data collection, standardization mapping, and multi-source conflict detection steps are re-executed to obtain and verify other data points affected by this status change. In one implementation, a confirmed module is marked as conflicted because a new data source provides specification data with higher confidence; after the decision, it is updated to obsolete. The data collection, standardization mapping, and multi-source conflict detection steps are automatically re-executed, generating a recalculation task for snapshots of affected downstream projects, ensuring that subsequent calculations no longer use obsolete data points, and that delivered versions maintain the traceability of their historical knowledge base versions.

[0021] like Figure 2 As shown, this application also provides a two-layer knowledge graph construction and evolution system for the LED industry, including an ontology management module, a two-layer data storage module, a multi-source data acquisition module, a standardized mapping module, a conflict detection module, a manual review closed-loop module, a quality report module, a knowledge graph query module, a cross-business module routing module, a source traceability module, a computer-aided design block alignment module, and an LED engineering business category extension support module.

[0022] The ontology management module is used to define entity types, relationship types, and attribute types in the display industry, and to manage the version of the industry ontology.

[0023] The dual-layer data storage module is used to store industry-wide general-purpose layers and brand-specific layers. The industry-wide general-purpose layer stores product specifications, industry standards, and naming conventions shared across manufacturers, while the brand-specific layer stores the model, series, and special parameters of the manufacturer's brand. When querying across layers, an override mechanism is executed.

[0024] The multi-source data acquisition module is used to acquire raw data from data sources in various formats, including JavaScript Object Notation (JSON), comma-separated values ​​(CSV), spreadsheets, portable document format (PDF) files, web pages, and emails.

[0025] The standardization mapping module is used to perform field mapping, unit conversion, and naming standardization on the collected raw data.

[0026] The conflict detection module is used to perform four types of conflict detection on the standardized mapped data: value type conflict, value conflict, relation conflict, and naming conflict. When a conflict is detected, a conflict flag is generated and the conflict data is pushed into the pending queue. Numerical difference conflict detection is performed only when the version, effective conditions, and units of measurement meet the comparability conditions.

[0027] The manual review closed-loop module is used to perform a dry run on sandbox data before new rules or fields are added to the database and generate an impact scope report. It generates a checklist containing fields to be confirmed, conflicts to be adjudicated, and data to be supplemented. It receives confirmation, modification, or abandonment of the checklist from the reviewers, writes the data points that pass the review into the formal knowledge base, and generates a recalculation task for the snapshots of affected downstream projects based on the impact scope.

[0028] The quality report module is used to generate quality reports that include coverage statistics for each product category, missing rate statistics for required fields, conflict item statistics, and a list of known gaps.

[0029] The knowledge graph query module is used to perform exact matching queries by entity identifier, conditional filtering queries by field conditions, and relational expansion queries by relation type on the formal knowledge base. It also performs multi-hop path reasoning based on entity relationships and generates cross-brand candidate alternative relationships with source evidence, applicable conditions, and pending confirmation status based on interface compatibility conditions, load capacity similarity conditions, and data group matching conditions. These relationships are then used by the equipment selection module to make the final selection in conjunction with project constraints, inventory, and cost.

[0030] The cross-business module routing module is used to distribute the formal knowledge base as a common data source to the computer-aided design (CAD) module, bill of materials (BOM) module, selection calculator module, quotation module, solution module and compliance module, and trigger each module to re-acquire the data when any data is modified.

[0031] The Provenance module is used to record and query the source identifier, collection time, collector, and confidence level of each data point, forming a complete traceability chain from data value to source identifier to collector to collection time.

[0032] The Computer-Aided Design Block Alignment Module is used to associate entities in the formal knowledge base with computer-aided design block resources, record block identifiers, block file paths, and block availability status, and generate gap reports when an entity is missing block resources.

[0033] The LED Engineering Business Category Extension Module is used to set parent entities and extended fields in the industry ontology, enabling new LED engineering business categories to extend the existing industry ontology by inheriting parent entities and adding extended fields, and performing entity alignment to map similar entities in the new business category to the corresponding entity types in the industry ontology.

[0034] The following describes the method for constructing and evolving a two-layer knowledge graph for the LED industry provided in this application, using specific embodiments: In some implementations, the method further includes the step of performing normalization mapping: The raw data collected from various data sources is processed by field mapping, unit conversion, and naming normalization to obtain standardized data points; Field mapping is used to map fields with different names but the same meaning from different data sources to the same standard field name; Unit conversion is used to convert values ​​with different units of measurement from different data sources into values ​​under the same measurement standard. Naming standardization is used to convert different naming methods for the same entity from different data sources into a standardized name format.

[0035] Specifically, the standardization mapping step is performed before collision detection to convert the raw data obtained from the multi-source acquisition step into a unified format, enabling subsequent collision detection to compare data from different sources under the same standard.

[0036] Field mapping resolves the issue of inconsistent field names across different data sources. Different manufacturers' product manuals and internal company forms may name the same parameter differently. For example, module width might be named "module width" in manufacturer A's manual, "module_width_mm" in manufacturer B's manual, and "moduleWidth" in another source. Field mapping unifies these different names to the same standard field name, "width value" or "width (mm)," enabling the same parameter to be accurately identified and compared across different data sources.

[0037] Unit conversion addresses the issue of inconsistent units of measurement between different data sources. Different manufacturers and industry standards may use different units of measurement; for example, one source might record a module thickness of 12 millimeters, another 1.2 centimeters, and yet another 0.012 meters. Unit conversion unifies these values ​​using different units of measurement to values ​​under the same measurement standard. In one implementation, 1.2 centimeters and 0.012 meters are both converted to 12 millimeters, allowing values ​​from the three sources to be compared using the same unit.

[0038] Naming standardization addresses the issue of inconsistent naming of the same entity across different data sources. Different manufacturers may use different naming conventions for the same product specification; for example, one manufacturer might name it "P2.5 Module 320×160," another "Indoor P2.5-320x160," and yet another "P2.5-32s-320x160." Naming standardization unifies these different names into a standardized format. In one implementation, the standardized naming format for the module entity is a combination of the pixel pitch value, the scanning method value, the width value multiplied by the height value, i.e., P2.5-32s-320x160.

[0039] In some implementations, the formal knowledge base has a two-tier data architecture, comprising an industry-wide common layer and a brand-specific layer: The industry-specific layer stores product specifications, industry standards, and naming conventions shared across manufacturers, while the brand-specific layer stores model numbers, series, and proprietary parameters for each manufacturer's brand. Data in the brand-specific layer is prohibited from being written to the industry-specific layer. The industry-specific layer serves as the primary index, and the brand-specific layer serves as the covering layer. In cross-layer queries, the brand-specific layer overwrites the query results from the industry-specific layer.

[0040] Specifically, the core constraint of the two-tier data architecture is that the brand-specific layer must not contaminate the industry-general layer. The industry-general layer, as the primary index, stores standardized data shared across manufacturers, representing fundamental knowledge shared by all tenants. The brand-specific layer, as an overlay layer, only takes effect after the enterprise version tenant binds the brand, version, and activation conditions match, storing the brand-specific models, series, and dedicated parameters. The two layers achieve query result overlay through an override mechanism; that is, the brand-specific layer only overrides the corresponding fields of the same data in the industry-general layer, without modifying the data itself stored in the industry-general layer.

[0041] The two-tier data architecture returns different results depending on the tenant's query scenario. When a default tenant, without a brand, queries, only the data from the industry-specific layer is returned. For example, if a module thickness is 12 mm, the tile path in the industry-specific layer is a general tile. When an enterprise tenant, after binding a brand, queries the same data, the data from the industry-specific layer is returned, overlaid with the overriding fields from the brand-specific layer. For example, in the brand-specific layer, the module thickness is overridden to 12.5 mm, and the tile path is overridden to a brand-specific tile path. The overridden result only takes effect in the query response of that specific tenant; the data in the industry-specific layer remains unaffected.

[0042] In one implementation, the industry-standard layer stores one matching object, containing the common name P2.5-32s-320x160, pixel pitch 2.5 mm, width 320 mm, height 160 mm, and thickness 12 mm, with the source marked as an industry-standard source. The brand-specific layer stores one matching object, containing the brand name, brand model, corresponding common specification identifier, and an overlay field (thickness 12.5 mm). Default tenant queries return a thickness of 12 mm, while enterprise version tenants bound to a brand return a thickness of 12.5 mm. Through this architecture, the platform maintains neutrality while meeting the branding output needs of enterprise users, and the data in the brand-specific layer is never written back to the industry-standard layer, preventing brand data from polluting industry-standard knowledge.

[0043] In some implementations, the method further includes the step of performing an audit closure: Before new rules or fields are added to the database, a pre-launch simulation is performed on the sandbox data and an impact scope report is generated. The impact scope report shows the scope of the impact of the new rules or fields on the existing data. Generate a verification table, which contains fields to be confirmed, conflicts to be adjudicated, and data to be supplemented; Receive confirmation, modification, or scrapping actions from auditors on the verification table, and update the status of data points based on the auditors' actions; The approved data points are written into the formal knowledge base, and a recalculation task is generated based on the scope of impact to capture snapshots of affected downstream projects. Generate a quality report, which includes coverage statistics for each product category, missing rate statistics for required fields, conflict item statistics, and a list of known gaps.

[0044] Specifically, a dry run is performed before new rules or fields are added to the database, using sandbox data to simulate the impact of the new rules or fields on existing data. The dry run process does not modify the data in the official knowledge base and runs only in an isolated sandbox environment.

[0045] The verification table contains three categories of entries: fields to be confirmed, conflicts to be adjudicated, and data to be supplemented. In one implementation, both Manufacturer A and the industry standard provide a module thickness of 12 mm, while Distributor B provides 11.5 mm. This entry in the verification table is recorded as a conflict to be adjudicated, and the three sets of values ​​are displayed side-by-side for the auditor to choose from. For each conflict to be adjudicated, the auditor selects to confirm a value, modify it to another value, or mark it as obsolete in the spreadsheet. For fields to be confirmed, the auditor enters the confirmed or modified new value; for data to be supplemented, the auditor enters the missing information. After the auditor completes all entries, the system reads the verification table and updates the status of the corresponding data points to either confirmed or obsolete based on the auditor's actions. Values ​​modified by the auditor are overwritten and written to the formal knowledge base.

[0046] After the approved data points are written into the formal knowledge base, a recalculation task is generated. In one implementation, a certain receiving card model is marked as obsolete in the knowledge base. The system identifies the project snapshots using the knowledge entity of the receiving card based on the scope of impact and generates a recalculation task. After confirmation by the user or auditor, the CAD, bill of materials, quotation, and selection modules calculate new project snapshots based on the new knowledge base version. Delivered projects retain the original version and its source evidence.

[0047] The quality report includes coverage statistics for each product category, missing field statistics, conflict entry statistics, and a known gap list. The coverage statistics show the proportion of covered products in each product category out of all known products. The missing field statistics show the proportion of data points in each product category where required fields are empty out of all data points in that category. The conflict entry statistics show the total number of conflicts in the current adjudication queue and the distribution of each type of conflict. The known gap list lists the product categories that are not yet covered and the data sources that have not yet been collected, serving as a priority for the next round of review and data collection. In one implementation, the quality report drives the initiation of the next review cycle, forming a continuously evolving closed loop.

[0048] In some implementations, the method further includes the steps of performing queries and inferences based on a formal knowledge base: Perform exact match queries by entity identifier, perform conditional filtering queries by field conditions, and perform relationship expansion queries by relationship type; Perform multi-hop path reasoning based on entity relationships in a formal knowledge base; Based on interface compatibility conditions, load capacity similarity conditions, and data group matching conditions, cross-brand equivalent substitution relationships are automatically derived, and cross-brand candidate substitution relationships with source evidence, applicable conditions, and pending confirmation status are generated for the equipment selection module to make a final selection in combination with project constraints, inventory, and cost.

[0049] Specifically, exact match queries by entity identifier use the unique identifier number corresponding to each entity in the knowledge base for direct lookup. Conditional filtering queries by field conditions filter based on combinations of values ​​from one or more fields; for example, querying all module entities with a pixel pitch of 2.5 mm and a width of 320 mm. Relationship expansion queries by relation type start from a known entity and search for adjacent entities along a specific relation type; for example, querying all module entities that are compatible with a certain receiving card.

[0050] Multi-hop path reasoning starts from a starting entity and proceeds along multiple relational edges, passing through intermediate entities to reach the target entity. In one implementation, starting from the "Carlette E120 Receiver Card" node, the system searches for compatible module nodes along compatibility relations, and then searches for project nodes using the module along applicable project relations. After two hops, the system obtains the set of "projects applicable to Carlette E120 Receiver Card".

[0051] A candidate replacement relationship is formed when the interface, port, data group, load boundary, firmware, or switching conditions of the candidate receiver card and the receiver card to be replaced meet the comparable or compatible conditions in the audited product specification data. The candidate replacement relationship is associated with the source evidence, version, effective conditions, and pending confirmation status of each field in the record; candidate replacement relationships of the same brand can be assigned priority, but the final equipment selection is determined by the selection module in combination with the load sub-region, inventory, cost, and manual confirmation results of the specific project.

[0052] When generating candidate control links, the knowledge graph only provides confirmed entity attributes, connection relationships, and applicable conditions; the selection module combines the module rows and columns, resolution, load sub-region direction, input signal, transmission distance, and redundancy requirements of the specific screen to verify fixed processing equipment links and modular chassis board links respectively, and does not directly regard the two types of links as equivalent substitutes just because the total pixels meet the requirements.

[0053] In some implementations, the method further includes the step of using a formal knowledge base as a common data source for multiple downstream business modules: Each downstream business module obtains data from the official knowledge base. When any data in the official knowledge base is modified, a recalculation task for the affected downstream project snapshot is generated according to the scope of impact. After the recalculation task is confirmed by the user or auditor, each downstream business module obtains data based on the new knowledge base version. Multiple downstream business modules include computer-aided design module, bill of materials module, selection calculator module, quotation module, solution module and compliance module. The output of each downstream business module carries a source identifier, which is used to trace back to the corresponding entity in the formal knowledge base.

[0054] Specifically, each downstream business module reads data from the official knowledge base without maintaining its own independent data copy. The computer-aided design module reads the physical dimensions and installation methods of the modules from the official knowledge base to generate engineering drawings; the bill of materials module reads the quantity of modules, power supplies, and receiver cards from the official knowledge base to generate a bill of materials; the selection calculator module reads product specifications and compatibility relationships from the official knowledge base to perform selection calculations; the quotation module reads the bill of materials from the official knowledge base to generate a quotation; the solution module reads the case library and specification library from the official knowledge base to generate a solution document; and the compliance module reads the rule library from the official knowledge base to perform compliance verification.

[0055] When data in any official knowledge base is modified, such as when a certain receiving card model is marked as obsolete, the status field of that entity in the knowledge base changes. The system identifies the affected project snapshots based on the scope of impact and generates a task to be recalculated. After confirmation by the user or auditor, the computer-aided design, bill of materials, selection, quotation, solution and compliance modules generate new project snapshots based on the new knowledge base version. Delivered versions retain the original knowledge base version and its source evidence.

[0056] Each downstream business module's output carries a source identifier, which points to the corresponding entity identifier in the formal knowledge base. In one implementation, each item in the bill of materials output by the bill of materials module carries a corresponding entity identifier. Clicking this identifier allows users to trace back to the complete information of that entity in the formal knowledge base. During audits of bidding projects, auditors use the source identifier to trace the data's origin, verifying that each product model in the bill of materials is verifiable and meets compliance review requirements.

[0057] In some implementations, the method further includes the step of associating entities in a formal knowledge base with computer-aided design tile resources: Record the corresponding computer-aided design block identifier, block file path, and block availability status for each entity; When an entity is missing a corresponding tile resource, a gap report is generated, which contains a list of entities with missing tiles. When generating drawings using computer-aided design, the entity identifiers, block resource identifiers, and availability status of associated entities are provided to the drawing module; the specific geometry generation is performed by the drawing module.

[0058] Specifically, each entity corresponds to three computer-aided design tile fields in the formal knowledge base. The tile identifier is a unique number assigned to each tile, used to establish a precise correspondence between the knowledge base and the tile library. The tile file path is the storage location of the tile, pointing to the specific available tile resource file. The tile availability status indicates whether the tile is currently available for drawing, including available status, in-process status, and missing status.

[0059] When an entity lacks a tile resource, such as when a tile identifier in a module entity record is empty or the tile availability status is marked as missing, the system adds the entity to the missing tile entity list and generates a gap report. The report includes the entity name, entity identifier, and recommended tile production priority for the missing tile, driving the tile production team to schedule production according to priority. In one implementation, if a newly entered receiver card model has not yet had a corresponding tile produced, the receiver card entity is added to the gap report, and the tile production team schedules production based on the report.

[0060] When generating drawings using computer-aided design (CAD), only entities with a block availability status of "available" are used. In one implementation, if a module entity in the design task is associated with a block file path and its status is "available," the module generates a drawing normally. If another module entity lacks block resources, the module does not generate a drawing, and the CAD module marks "block missing" at the corresponding location on the drawing. The designer identifies the entity type of the missing block based on the mark, creates the missing block, and then re-generates the drawing. Through these constraints, temporary graphics cannot be used to replace missing blocks during CAD drawing, ensuring consistency between the drawings and the actual object.

[0061] In some implementations, the method further includes a knowledge extension step for new business categories in LED engineering: In the industry ontology, a parent entity and extended fields are set. The new LED engineering business category is extended by inheriting the parent entity and adding extended fields to extend the industry ontology. Perform entity alignment for newly added business categories, mapping similar entities in the newly added business categories to the corresponding entity types in the industry ontology.

[0062] Specifically, the mechanism of parent entities and extended fields enables existing industry ontologies to support knowledge extensions for new LED engineering business categories. Parent entities represent the general definition of a certain type of product; for example, "distribution cabinet" as a parent entity includes general fields such as rated power, input voltage, and output voltage. Adding a new LED engineering business category does not require redefining these general fields; it can directly inherit the parent entity to obtain all general field definitions, and then add industry-specific extended fields to complete the ontology adaptation. In one implementation, the LED display rental business reuses the distribution cabinet parent entity, inheriting fields such as rated power, input voltage, and output voltage, and adding the extended field "temporary power supply circuit identifier." When the wire parent entity is reused, it inherits fields such as wire diameter and length, and adds the extended field "rented wire turnover identifier." When the steel structure regular entity is reused, it inherits fields such as load-bearing capacity, and adds the extended field "temporary installation structural constraints."

[0063] The new business category entity alignment maps similar entities in different LED engineering business categories to corresponding entity types in the existing industry ontology. In one implementation, modules, enclosures, control equipment, and power supply entities in LED engineering business categories such as indoor displays, outdoor projects, and rental displays can be mapped to corresponding parent or child classes in the industry ontology; after entity alignment, the bill of materials, selection, and computer-aided design modules can read applicable fields through the same entity identifier.

[0064] In some implementations, constructing a display industry ontology includes: Define the following as core entity types: module entity, enclosure entity, receiver card entity, transmitting device entity, video processing device entity, modular splicing device chassis entity, input board entity, output board entity, transmission port entity, fiber optic transceiver entity, power supply entity, power distribution cabinet entity, magnet entity, wire entity, redundancy strategy entity, and steel structure rule entity. Define compatibility relationship, interoperability relationship, peer substitution relationship, hierarchical relationship, board and slot assembly relationship, port connection relationship, upstream and downstream load relationship, primary and backup relationship, and source evidence relationship as relationship types; Define physical parameters, electrical parameters, geometric parameters, protocol parameters, and service availability parameters as attribute types; Set the naming convention for module entities to a combination of pixel pitch value, scan mode value, width value, and height value.

[0065] Specifically, the module entity includes pixel pitch, physical dimensions, and interface type. The enclosure entity includes dimensions, material, and mounting holes. The receiver card entity includes the number of pixels it can support, the number of ports, and data group definitions. The transmitting device entity and video processing device entity include input interfaces, output ports, maximum load capacity, supported resolutions, and firmware versions. The modular splicing equipment chassis entity includes the number of slots, backplane bandwidth, and types of boards that can be mounted. The input board entity and output board entity include interface type, number of channels, single-channel bandwidth, supported resolutions, and slot occupancy information. The transmission port entity and fiber optic transceiver entity include interface type, transmission medium, transmission distance, and bandwidth. The power supply entity includes rated power, output voltage, and input voltage range. The power distribution cabinet entity includes total power capacity and number of circuits. The magnet entity includes magnetic strength and dimensions. The cable entity includes length, specifications, and interface type. The redundancy strategy entity includes primary link identifier, backup link identifier, switching conditions, and protection paths. The steel structure rule entity includes vertical pipe spacing, horizontal pipe spacing, steel type, and load-bearing standards.

[0066] The HUB75 interface establishes a compatibility relationship between the receiving card and the HUB75 interface module. Interoperability relationships express whether devices from different brands within the same project can communicate normally. Equivalent substitution relationships express that if one product is discontinued, another product with the same function and specifications can serve as a replacement. Hierarchical relationships express the inheritance relationship between product categories; both indoor and outdoor modules inherit from the module parent class. Board and slot assembly relationships express the assembly constraints between input or output boards and the modular splicing device chassis slots. Port connection relationships express the signal connection paths between device ports. Upstream and downstream load relationships express the load transfer between the transmitting device, receiving card, and the screen or module. Primary and backup relationships express the primary and backup devices in the control link and their switching conditions. Source evidence relationships express the reference relationship between a data point and its source.

[0067] Physical parameters include width, height, thickness, and weight. Electrical parameters include rated power, operating voltage, current, and power consumption. Geometric parameters include mounting hole positions, screw specifications, and tolerance range. Protocol parameters include communication protocol type, data group definition, and interface signal definition. Service availability parameters include whether it is currently on sale, whether it is discontinued, and whether it is a recommended selection.

[0068] The naming convention for module entities is the pixel pitch value plus the scan mode value plus the width value multiplied by the height value, i.e., P{pitch}-{scan}s-{width}x{height}. P2.5-32s-320x160 indicates a module specification with a pixel pitch of 2.5 mm, a scan mode of 32 scans, a width of 320 mm, and a height of 160 mm. Although P2.5-32s-320x160 and P2.5-16s-320x160 have the same pixel pitch and size, they differ in scan mode and are therefore identified as two different entities, corresponding to different driver IC configurations and LED packaging methods.

[0069] like Figure 3 As shown, in one embodiment, a computer device is provided, which can be a server. The computer device includes a processor, memory, network interface, and database connected via a system bus; when the computer program is executed by the processor, it implements the functions or steps of the server side of the aforementioned two-layer knowledge graph construction and evolution method for the LED industry.

[0070] like Figure 4 As shown, in one embodiment, a computer device is provided, which can be a client. The computer device includes a processor, memory, network interface, display screen, and input device connected via a system bus; when the computer program is executed by the processor, it implements the functions or steps of the aforementioned two-layer knowledge graph construction and evolution method for the LED industry on the client side.

[0071] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0072] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0073] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0074] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for constructing and evolving a two-layer knowledge graph for the LED industry, characterized in that, Includes the following steps: Construct a display screen industry ontology, and define core entity types, relationship types between core entity types, attribute types of core entity types, and entity naming conventions in the industry ontology; Raw data is collected from multiple data sources, and each collected data point is associated with an entity identifier, attribute identifier, data version, effective time or effective condition, unit of measurement, source traceability information, evidence status, and data status. The status includes one or more of the following: confirmed status, pending review status, conflict status, and obsolete status. Perform field mapping, unit conversion, and naming normalization on the original data to obtain standardized data points; Multi-source conflict detection is performed on the standardized data points. This multi-source conflict detection includes detecting whether the value type of the same data point is consistent across different data sources when the entity identifier, attribute, version, effective condition, and unit of measurement meet comparability conditions; detecting whether the numerical difference of the same data point in different data sources exceeds a preset threshold; detecting whether the conclusions of the same compatibility relationship are contradictory in different data sources; and detecting whether the naming of the same entity is consistent across different data sources. For data points with different versions or effective conditions, this is recorded as a version difference or condition difference rather than a numerical conflict. When a conflict is detected, the state of the data point is marked as a conflict state. When there is a data point marked as a conflict state, receive the decision feedback on the conflict state, and update the state of the data point to an acknowledged state or an abandoned state according to the decision feedback. Write the data points with the confirmed status, along with their corresponding source traceability information, version, effective conditions, and evidence status, into the formal knowledge base of the industry general layer or brand-specific layer. When there is a new data source or the status of data points already written to the formal knowledge base changes, the steps of collecting raw data from multiple data sources, standardizing mapping, and multi-source conflict detection are re-executed to generate the impact range of the affected knowledge entities and downstream project snapshots, and a recalculation task for the affected downstream project snapshots is generated based on the impact range.

2. The method according to claim 1, characterized in that, The method also includes the step of performing normalization mapping: The raw data collected from each of the aforementioned data sources is subjected to field mapping, unit conversion, and naming normalization to obtain standardized data points; The field mapping is used to map fields with different names but the same meaning from different data sources to the same standard field name; The unit conversion is used to convert values ​​with different units of measurement from different data sources into values ​​under the same measurement standard. The naming standardization is used to uniformly convert different naming methods for the same entity in different data sources into a standardized name format.

3. The method according to claim 1, characterized in that, The formal knowledge base has a two-tier data architecture, which includes an industry-wide general layer and a brand-specific layer: The industry-wide common layer is used to store product specifications, industry standards, and naming conventions shared across manufacturers. The brand-specific layer is used to store the model, series, and special parameters of the manufacturer's brand. Data in the brand-specific layer is prohibited from being written to the industry-wide common layer. The industry-wide common layer serves as the primary index, and the brand-specific layer serves as the covering layer. When performing cross-layer queries, the brand-specific layer covers the query results of the industry-wide common layer.

4. The method according to claim 1, characterized in that, The method also includes the step of performing an audit closed loop: Before a new rule or field is added to the database, a pre-run is performed on the sandbox data and an impact range report is generated. The impact range report shows the scope of the impact of the new rule or field on the existing data. Generate a verification table, which includes fields to be confirmed, conflicts to be adjudicated, and data to be supplemented; Receive confirmation, modification, or scrapping operations from the auditor on the verification table, and update the status of the data points according to the auditor's operations; The approved data points are written into the formal knowledge base, and a recalculation task for snapshots of affected downstream projects is generated based on the scope of impact. Generate a quality report, which includes coverage statistics for each product category, missing rate statistics for required fields, conflict item statistics, and a list of known gaps.

5. The method according to claim 1, characterized in that, The method also includes the step of performing queries and inferences based on the formal knowledge base: Perform exact match queries by entity identifier, perform conditional filtering queries by field conditions, and perform relationship expansion queries by relationship type; Perform multi-hop path reasoning based on the entity relationships in the formal knowledge base; Based on interface compatibility conditions, load capacity similarity conditions, and data group matching conditions, cross-brand equivalent substitution relationships are automatically derived, and cross-brand candidate substitution relationships with source evidence, applicable conditions, and pending confirmation status are generated for the equipment selection module to make a final selection in combination with project constraints, inventory, and cost. The multi-hop path reasoning also includes generating candidate control links based on the relationships between the screen or module, receiving card, transmitting device or video processing device, chassis and input / output boards of modular splicing device, transmission ports, cables and redundancy strategies, and using slot occupancy, port occupancy, load boundary, signal interface, transmission medium and master / slave relationship as applicable conditions for the candidate control links.

6. The method according to claim 1, characterized in that, The method also includes the step of using the formal knowledge base as a shared data source for multiple downstream business modules: Each of the downstream business modules obtains data from the formal knowledge base. When any data in the formal knowledge base is modified, a recalculation task for the snapshot of the affected downstream project is generated according to the scope of impact. After the recalculation task is confirmed by the user or the auditor, the corresponding business module re-obtains the data based on the new knowledge base version. The multiple downstream business modules include a computer-aided design module, a bill of materials module, a selection calculator module, a quotation module, a solution module, and a compliance module. The output of each of the downstream business modules carries a source identifier, which is used to trace back to the corresponding entity in the formal knowledge base.

7. The method according to claim 1, characterized in that, The method further includes the step of associating entities in the formal knowledge base with computer-aided design tile resources: Record the corresponding computer-aided design block identifier, block file path, and block availability status for each entity; When the entity is missing a corresponding tile resource, a gap report is generated, which contains a list of entities with missing tiles; When generating drawings using computer-aided design, the entity identifiers, block resource identifiers, and availability status of associated entities are provided to the drawing module; the specific geometry generation is performed by the drawing module.

8. The method according to claim 1, characterized in that, The method also includes a knowledge extension step for new business categories in LED engineering: In the industry ontology, a parent entity and extended fields are set. A new LED engineering business category is added by extending the industry ontology by inheriting the parent entity and adding the extended fields. Perform entity alignment for newly added business categories, mapping similar entities in the newly added business categories to the corresponding entity types in the industry ontology.

9. The method according to claim 1, characterized in that, The construction of the display industry ontology includes: Define the following core entity types: module entity, enclosure entity, receiver card entity, transmitting device entity, video processing device entity, modular splicing device chassis entity, input board entity, output board entity, transmission port entity, fiber optic transceiver entity, power supply entity, power distribution cabinet entity, magnet entity, wire entity, redundancy strategy entity, and steel structure rule entity. The following relationship types are defined: compatibility relationship, interoperability relationship, peer substitution relationship, hierarchical relationship, board and slot assembly relationship, port connection relationship, upstream and downstream load relationship, primary and backup relationship, and source evidence relationship. Define physical parameters, electrical parameters, geometric parameters, protocol parameters, and service availability parameters as the attribute types; The entity naming convention for the module entity is set to a combination of pixel pitch value, scan mode value, width value, and height value.

10. A two-layer knowledge graph construction and evolution system for the LED industry, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 9.

Images