A mine drilling account multi-role template field matching and checking method

Abstract

The application discloses a kind of mining drilling station account multi-role template field matching and checking method, comprising: constructing multi-role standard field and constraint reference;Front state verification: distinguish basic data role and supplementary data role, whether there is compliance basic drilling record before supplementary role upload is verified;Template feature extraction and candidate field locking;Build field attribute relationship diagram: mine and establish including co-occurrence, adjacent group, arithmetic dependence, function dependence, containing dependence, multi-class business relationship edge in role state;Learn field relationship context vector: adopt relationship perception graph convolution model hierarchical iteration, field neighborhood business, numerical, structural association information is fused to generate context representation vector;Multi-dimensional dynamic weighted matching scoring;Hierarchical automatic matching and man-machine collaborative confirmation;Error-prone data checking;Effectively reduce manual operation cost, matching accuracy continues to optimize with system use, it is convenient for coal mine gas control, drilling acceptance integrated supervision traceability.

Description

Technical Field

[0001] This invention belongs to the field of mining ledger management, specifically involving a method for matching and validating multi-role template fields in mining borehole ledgers. Background Technology

[0002] In coal mines, drilling, extraction monitoring, and on-site acceptance are carried out collaboratively by multiple departments, including the construction team, the outburst prevention department, and the video monitoring room. The borehole log is the core record of data throughout the entire borehole lifecycle, requiring different roles to fill in specific fields. Traditional log data import systems generally use a fixed data table template with forced matching, only supporting files with identical header names and column order. However, in underground site management, template versions are frequently adjusted, and different work teams have varying filling habits, often resulting in issues such as abbreviated headers, merged headers, reversed column order, inconsistent unit notation, and added / deleted / lined field names. The fixed template matching mechanism is prone to field matching failures, requiring manual mapping of numerous log files column by column, leading to extremely low data import efficiency and a high risk of data mismatch due to human error.

[0003] Existing ledger field matching technologies rely solely on the text similarity of field names for comparison, failing to distinguish the boundaries of field responsibilities for different business roles and lacking a role-based permission constraint mechanism. This makes it highly susceptible to confusion in cross-role fields such as drilling depth, anti-outburst extraction concentration, and video acceptance meterage. Furthermore, existing algorithms only compare individual header texts in isolation, failing to explore the business relationships between fields, the logic of numerical calculations, and the context of the table. They are insufficient in distinguishing between abbreviated fields, synonymous fields, and fields with similar names but completely different business meanings. Relying solely on text similarity easily leads to a large number of false matches, significantly increasing the workload of subsequent data verification.

[0004] The existing data verification mechanism for mining borehole ledgers has defects in timing and business logic. Data uploads from multiple roles lack prior status verification logic, and supplementary data for anti-outburst and video acceptance can be uploaded independently without constraints. This results in dirty data issues, such as entering extraction and acceptance data when there are no basic construction borehole records. Furthermore, the verification is only performed on the format and numerical range of a single column of data, without utilizing the inherent numerical linkage relationships in the borehole ledger (such as total meters = number of drill rods × length of a single rod, and grouting volume related to cement bag weight) to build cross-field consistency verification. This makes it impossible to automatically identify abnormal data that violates business arithmetic logic and functional dependencies, resulting in weak data quality control capabilities.

[0005] In addition, existing similar systems lack a self-optimization and iteration mechanism for matching results. Manually corrected field mappings, added aliases, and mismatched cases cannot be accumulated and reused. Matching errors repeatedly occur in similar mines, work groups, and similar templates, and the matching accuracy cannot be continuously improved with use. At the same time, data uploaded by multiple roles is stored independently, and there is a lack of an automatic merging mechanism for ledgers based on common identification fields such as borehole number and shift. Drilling construction, extraction monitoring, and video acceptance data are stored in a fragmented manner, making it impossible to form a complete and unified ledger for the entire life cycle of drilling, which is not conducive to the integrated supervision of underground gas control and borehole acceptance in coal mines. Summary of the Invention

[0006] To address the problems or deficiencies in existing technologies, this invention aims to solve the issues of variable template styles, lack of role boundary constraints leading to errors in field matching, and high manual workload when multiple roles fill in borehole ledgers in coal mines. Simultaneously, it addresses the pain points of data management such as lack of pre-validation for multi-role data, lack of business logic validation, data fragmentation, and the inability to autonomously optimize matching rules.

[0007] This invention provides a method for matching and validating fields in a multi-role template of a mining borehole ledger, comprising the following steps: S1. Construct multi-role standard fields and constraint benchmarks: Pre-establish a multi-role standard field library and field responsibility matrix, divide common identification fields and role-specific fields, and limit the boundaries of fields that can be matched for each role; S2. Pre-processing status verification: Distinguish between basic data roles and supplementary data roles. Before uploading, supplementary data roles must verify whether there are compliant basic drilling records. If not, the process will be terminated and an error will be reported. S3. Template Feature Extraction and Candidate Field Locking: Extract structural features of the uploaded template, normalize and parse the multi-dimensional structural features of the uploaded ledger header, limit the matching candidate field set based on the current role from the responsibility matrix, and block cross-role matching. S4. Construct a field attribute relationship graph: Using uploaded fields and standard fields as nodes, mine and establish multiple types of business relationship edges, including co-occurrence, adjacent grouping, arithmetic dependency, functional dependency, containment dependency, and role status. S5. Learning Field Relationship Context Vectors: Employing a hierarchical iterative relation-aware graph convolutional model to integrate field neighborhood business, numerical, and structural association information to generate context representation vectors; S6. Multi-dimensional dynamic weighted matching score: Normalized calculation includes multiple matching indicators such as semantic similarity of field names, consistency of units, consistency of data types, similarity of relational context, consistency of role and permission, and historical credibility. Combined with dynamic correction factors, a comprehensive matching score is obtained. S7. Hierarchical automatic matching and human-machine collaborative confirmation: Automatic mapping or manual review is performed based on matching thresholds and scenarios, and the results of manual operations are stored in the historical correction database. S8. Error-prone data validation: Perform single-column format, value, and time sequence validation according to role-specific rules, and conduct cross-field consistency validation based on relationship diagram constraints.

[0008] Furthermore, in step S1, the method for pre-establishing a multi-role standard field library includes: The system pre-maintains standard template libraries for three roles: construction team, gas outburst prevention department, and video room. These standard template libraries do not require uploaded files to be completely unchanged; instead, they define the standard field sets, common aliases, units, data types, required attributes, value ranges, relationships between adjacent fields, computable relationships, and ledger status rules for each role. The construction team's standard field set includes borehole number, shift, designed borehole depth, elevation angle, borehole diameter, drilling location, and actual borehole depth. The gas outburst prevention department's standard field set includes network sampling, 24-hour sampling concentration, 7-10 day sampling concentration, and whether the borehole has passed acceptance. The video room's standard field set includes reported borehole depth, accepted borehole depth, acceptance personnel, total number of drill rods, total meters, cement bags, and grouting volume. For each standard field, the system records its field name, historical aliases, unit expression, data type, sample value distribution, business grouping, possible arithmetic relationships, and dependencies with other fields. The field responsibility matrix records the following field constraint attributes: the responsibility role corresponding to the standard field, whether it is a public identification field, whether it is required, standard data type, standard value unit, value range, and whether the field is allowed to be updated later; the matrix constraints prevent template columns of non-responsibility roles from being mismatched with exclusive business fields.

[0009] Furthermore, the pre-state verification in step S2 specifically includes: When the current uploading role is the construction team, it is allowed to create a brand new borehole foundation record through public identification fields; When the current uploading role is the Anti-outburst Section or Video Room, the system searches for the basic drilling records that have been verified by the construction team by combination of borehole number, working face, roadway, and drilling batch. If no matching record is found, a status pre-error feedback is generated, and the subsequent field matching process is terminated. If a matching record is found, the process is allowed to proceed to the template structure feature extraction step.

[0010] Furthermore, in step S3, the method for extracting the structural features of the uploaded template and normalizing the multi-dimensional structural features of the uploaded ledger header includes: Read the worksheet name, header row, table header, merged cells, unit sub-row, column sorting order, cell comments, and the first N rows of sample data from the data table template; Standardize the header text by removing spaces, line breaks, parentheses, full-width / half-width special characters, and end-of-page unit suffixes. Each candidate field is encapsulated into a six-dimensional feature: field name feature, unit feature, data type feature, sample value distribution feature, adjacent column structure feature, and worksheet affiliation feature; Based on the above multidimensional features, candidate column identification is completed in scenarios such as header abbreviation, multi-row merged headers, disordered column order, and unit variants.

[0011] Furthermore, step S3, which limits the matching candidate field set based on the current role from the responsibility matrix and blocks cross-role matching, includes: extracting the standard field set corresponding to the currently logged-in role from the field responsibility matrix and adding it to the common identification field set to form a candidate matching range. Candidate columns are only allowed to match within this candidate matching range; cross-role matching is not permitted.

[0012] Furthermore, the rules for constructing each business relationship edge in step S4 are as follows: 1) Co-occurrence relationship edge co-occurs-with: When two fields are in the same worksheet, the same merge header, and the same business group, an undirected co-occurrence edge is established; 2) Adjacent grouped edges: When two table columns are adjacent or required to be matched by business logic, an undirected grouped edge is established; 3) Arithmetic-dependency: Traverse the binary / ternary combinations of numerical fields, verify that addition, subtraction, multiplication, and division operations are valid in sample rows exceeding the threshold proportion, and create directed edges from the operation source node to the result node. The edge attributes store the operator and operation confidence. 4) Functional dependency edges: Discover the smallest nontrivial functional dependency X→A, and establish directed edges pointing all field nodes in X to node A; the combination of common identification fields is uniquely bound to the borehole record through this type of edge; 5) Inclusion-dependency: If a high percentage of the unique value set of field A is contained in the unique value set of field B, a directed edge is established from A to B to verify whether the supplementary role public field matches the construction basic record. 6) Role-state relationship edge: binds fields to corresponding operation roles and ledger stage status constraints; operation roles can only operate on the fields bound to them; for example, the construction team can only operate on the construction team role. After the construction team uploads, the ledger status is "[Drilling and sealing completed]"; when the data verification of the outburst prevention department passes, the ledger status is updated to "[Drilling and extraction acceptance completed]"; when the data verification of the video room passes, the ledger status is updated to "[Video acceptance completed]".

[0013] Further, the specific method of step S5 is as follows: after the attribute relationship graph is constructed, a relationship graph convolutional network or an equivalent relationship-aware message passing model is used to learn the structured context representation of each field node; for different types of edges, the model learns different transformation parameters so that relationships such as co-occurs-with, group-neighbor, arithmetic-dependency, functional-dependency, inclusion-dependency, and role-state play different roles in information propagation; after L-layer iterations, each node obtains a relationship context vector V_context, which integrates the field structure, business combination, arithmetic relationship, dependency relationship, and role state information in its L-hop neighborhood.

[0014] Furthermore, the specific method in step S6 is as follows: Multiple matching metrics are defined as follows: 1) Semantic similarity of field names: After standardizing the field names, a semantic vector is generated. Cosine similarity is used to calculate the similarity to adapt to scenarios such as field abbreviation, synonym replacement, and alias. 2) Unit consistency: 1 for units that are completely consistent or have no units; 0.8 for units that are convertible and have the same dimensions; 0 for units that conflict or have no label. 3) Data type consistency: Stratified sampling is used to extract column samples, identify numeric / date / enumeration / text types, and compare them with standard field types to output a normalized consistency score; 4) Relational context similarity: Cosine similarity of multi-level context vectors of candidate column nodes and standard field nodes; 5) Role-based permission consistency: 1 for roles with responsibility or common fields; 0 for non-responsibility roles. 6) Historical correction reliability: initial value 0.5, equal to the number of correct matches / (number of correct matches + number of manually confirmed matches + number of manually confirmed non-standard fields); The comprehensive matching score is calculated as follows: Score = α1 × field name semantic similarity + α2 × unit consistency + α3 × data type consistency + α4 × relationship context similarity + α5 × role permission consistency + α6 × historical correction credibility; where the initial base weights are α1 = 0.3, α2 = 0.1, α3 = 0.1, α4 = 0.2, α5 = 0.2, and α6 = 0.1, and all dimension scores and corrected weights are normalized to the [0,1] interval; The adjustment rule for the dynamic correction factor is as follows: 1) For scenarios where field names are too short / abbreviated: use an α1 correction factor of 0.8 to reduce the weight of name similarity; 2) Strong unit constraint fields and complete unit annotation scenarios: α2 correction factor 1.2, to improve unit consistency weight; 3) Scenarios with sufficient sample size and stable data format: α3 correction factor 1.1, to increase the weight of data type consistency; 4) The current role does not have the corresponding field operation permission: α5 correction factor 0, this dimension does not participate in the score calculation; 5) Scenarios with many historical manual confirmations and few false matches: α6 correction factor 1.2, to increase the weight of historical correction credibility; All dimension weights are corrected and then renormalized to ensure that the sum of the corrected weights is 1.

[0015] Furthermore, the method for step S7, hierarchical automatic matching and human-machine collaborative confirmation, is as follows: When the scores of both candidate column i and standard field j are greater than or equal to the preset threshold: Unique matching: If only one candidate column field meets the threshold condition, a one-to-one mapping relationship is directly established, and the mapping type is marked as "unique matching". The attribute relationship graph is updated synchronously, and the number of correct matches is incremented by 1.

[0016] Multiple candidate matching: If two or more candidate column fields meet the threshold condition, another filtering condition is triggered. The field with the highest overall matching score is selected as the primary matching candidate. If the difference between the primary matching candidate and the secondary matching candidate is ≥0.1, a one-to-one mapping relationship is established between the primary matching field and the standard field, and the mapping type is marked as "multiple candidate matching". If there are multiple candidate fields with a difference ≥0.1 between the primary matching candidate and the secondary matching candidate, they are sorted in descending order of score, and the top-ranked field is selected as the final compliant matching item, and the number of correct matches is incremented by 1.

[0017] For source fields where the highest overall matching score is less than a preset threshold, the system initiates a manual review mechanism: Low-confidence candidate field confirmation: If an uploaded column does not meet the matching threshold in the current role's standard field set, the system will submit the source field to the business personnel corresponding to the current upload role for confirmation. The business personnel can confirm the standard field recommended by the system, or they can reselect a standard field from the current role's allowed field set. The number of manual confirmation matches will be incremented by 1.

[0018] Non-standard field confirmation: If manually confirmed, the field is marked as an unknown field or a non-standard field of this template, and the feedback file prompts the user to confirm whether the column is a newly added field, a temporary memo field, or a template entry error. If manually confirmed, it is a newly added standard field, and the system can add it to the standard field library, historical alias library, or business grouping relationship as a basis for subsequent template identification and correction. At the same time, the number of manual confirmations for non-standard fields is increased by 1.

[0019] Further, step S8 includes: after field matching is completed, the system performs role-based and relational verification on the matched standard field data: the construction team data focuses on verifying whether the values ​​including design hole depth, actual hole depth, sealing depth, sealing section length, actual pipe length, screen pipe length, and lower pipe length are valid; verifying whether the data including elevation angle, hole diameter, drilling position, and opening height are within the range; and verifying the time sequence of hole formation date, sealing date, and grouting date. The anti-outburst department data focuses on verifying whether the data including 24-hour extraction concentration (%), 7-10 day extraction concentration (%), and 30-day extraction concentration (%) are qualified. The video room data verifies whether the numerical segments including reported hole depth, acceptance hole depth, acceptance personnel, drilling team (group) leader, sealing time, grouting time, total number, and total meters are logically consistent. For high-confidence arithmetic dependencies and functional dependencies found in the attribute relationship graph, the system also performs consistency verification. If the sample data violates the corresponding dependency relationship, an anomaly prompt is generated.

[0020] Furthermore, it also includes S9, multi-role ledger aggregation and status control: multi-role data is merged through common identification fields to form a complete drilling ledger, the ledger stage status is updated according to the verification results, and conflicting data is handled according to permissions and time sequence.

[0021] Within this system, each operator role can only operate on the fields bound to them; for example, a construction team can only operate on the construction team role. After the construction team uploads the data, the ledger status will be "[Drilling and Sealing Completed]". Once the data verification of the outburst prevention department is passed, the ledger status will be updated to "[Drilling Extraction Acceptance Completed]". Once the data verification of the video room is passed, the ledger status will be updated to "[Video Acceptance Completed]".

[0022] Furthermore, it also includes S10, process feedback and iterative self-learning: outputting full-process anomaly feedback, continuously updating field matching rules and relationship confidence based on the historical correction library, and optimizing subsequent matching accuracy.

[0023] Iterative self-learning process: 1) Summarize all error types in the process: status precondition error, permission matching error, format error, numerical logic error, cross-field dependency error, unmatched ambiguous field, and generate standardized feedback files; 2) Enter the manual matching mapping, newly added standard fields, manual mismatch markers, and newly added aliases into the historical correction library; 3) Iteratively update based on the historical correction library: field alias mapping table, sample profile of each field, confidence of each edge of the attribute relationship graph, and historical correction credibility index to continuously improve the accuracy of automatic matching of templates of the same mine, the same work group, and the same type.

[0024] Compared with the prior art, the present invention has the following advantages: (1) The multi-role template field matching and verification method for mine borehole ledgers of the present invention uses a multi-dimensional matching mechanism through standardized extraction of multi-dimensional features of the table header, modeling of six types of field relationship diagrams, and fusion of relationship context vectors. It no longer relies on fixed template table headers, column order, and unit format, and can be compatible with common ledger deformations in the underground field such as field abbreviations, merged table headers, unit variants, and disordered column order. At the same time, it relies on the field responsibility matrix to define the exclusive matching range of roles, thereby eliminating cross-role field misidentification from the root. Compared with the traditional matching method that relies only on field text similarity, the automatic matching coverage is significantly improved, effectively reducing the operation cost of manual column-by-column calibration and manual mapping.

[0025] (2) The multi-role template field matching and verification method for mining borehole ledgers of the present invention adds a multi-role upload pre-state verification logic, which forces supplementary roles such as anti-outburst and video acceptance to upload data based on the compliance of the construction team, so as to avoid dirty data without construction source; at the same time, it integrates single column format / range / time sequence verification and attribute relationship graph driven arithmetic and functional dependency cross-field consistency verification, which can not only identify single field format abnormalities, but also automatically capture contradictory data that violate the numerical linkage logic of borehole business, realize automatic verification of full-link data compliance, and improve work efficiency.

[0026] (3) The multi-role template field matching and verification method of the present invention for mine borehole ledgers aggregates the scattered data of multiple roles such as construction, gas extraction monitoring and video acceptance based on common identification fields such as borehole number and shift. The ledger stage status is dynamically updated according to the verification results uploaded by role, and the information of the entire process of borehole construction, gas extraction and on-site acceptance is completely linked. Standardized handling rules are formulated for data conflicts of multiple roles in the same field, which solves the problem of data fragmentation of multiple departments and fragmented ledger information in traditional systems, and facilitates the integrated supervision and traceability of coal mine gas management and borehole acceptance.

[0027] (4) The multi-role template field matching and verification method for mine drilling ledgers of the present invention builds a historical correction library to store operation records such as manual matching, adding fields, and mismatch marking, and continuously iterates and updates field alias mapping, sample profile, relationship edge confidence and matching credibility index. The historical correction experience can be reused for the same mine, the same shift and the same type of modified template. The matching accuracy is continuously optimized with the use of the system. The frequency of manual intervention gradually decreases under long-term use, and it has the ability to adapt to changes in on-site ledger management. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the overall process of a preferred embodiment of the present invention; Figure 2 This is the overall logic control diagram of a preferred embodiment of the present invention; Figure 3 This is one of the interface diagrams of a preferred embodiment of the present invention (taking the drilling data table interface as an example); Figure 4 This is a second interface diagram of a preferred embodiment of the present invention (taking borehole data import as an example); Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0030] Please refer to Figure 1 , Figure 2 The embodiments of the present invention relate to a method for matching and validating fields of a multi-role template in a mining borehole ledger, comprising the following steps: Step 1: Establish the standard template library and standard field set: The standard template library and standard field sets are established by pre-maintaining standard template libraries for three roles: construction team, gas outburst prevention department, and video room. The standard template library does not require uploaded files to remain completely unchanged; rather, it defines the standard field sets, common aliases, units, data types, required attributes, value ranges, relationships between adjacent fields, computable relationships, and ledger status rules for each role. The construction team's standard field set includes borehole number, shift, designed borehole depth, elevation angle, borehole diameter, drilling location, and actual borehole depth; the gas outburst prevention department's standard field set includes network sampling, 24-hour sampling concentration, 7-10 day sampling concentration, and whether the borehole has passed acceptance; the video room's standard field set includes reported borehole depth, accepted borehole depth, acceptance personnel, total number of drill rods, total meters, cement bags, and grouting volume. For each standard field, the system records its field name, historical aliases, unit expression, data type, sample value distribution, business grouping, applicable arithmetic relationships, and dependencies with other fields.

[0031] Step 2, Field Responsibility Matrix Establishment: Establish a field responsibility matrix to record the correspondence between standard fields and responsible roles, and record whether a field is a common identification field, whether it is required, its data type, unit, value range, and whether it can be updated. Common identification fields are borehole number + date or shift, used to locate records of the same borehole; business fields are maintained separately according to responsible roles. The field responsibility matrix ensures that the construction team, the anti-outburst department, and the video room can only match and upload fields that are the responsibility of their respective roles, preventing anti-outburst department fields from being misidentified as construction team fields, or video room acceptance fields from being mistakenly written into construction data.

[0032] Step 3, Pre-upload Status Verification: The system determines whether the upload is creating a basic borehole record or supplementing an existing one based on the uploading role. If the current role is the construction team, they are allowed to create a basic borehole record based on information such as borehole number + date or shift. If the current role is the outburst prevention department or video control room, the system must first check whether a basic record uploaded and verified by the construction team already exists, based on identity information such as borehole number, working face or roadway, and borehole batch. If no basic record exists for the construction team, the system will not continue with template field matching and data entry, but will generate a pre-upload error feedback prompting the system to add the construction team data first. If a basic record exists for the construction team, subsequent template matching, relationship diagram construction, and data verification will continue.

[0033] Step 4, Upload Template Structure Feature Extraction: After uploading the current data table template, the system reads the logged-in role and parses the uploaded file's worksheet name, header row, table header row, merged cells, unit row, column order, comments, first N rows of sample values, and adjacent column relationships to form the uploaded template structure features. The system standardizes spaces, line breaks, parentheses, full-width and half-width symbols, and unit suffixes in the table header and represents each candidate column as field name features, unit features, data type features, sample value distribution features, adjacent column features, and worksheet features. Even if the template field order changes, or if the table header contains abbreviations, merged headers, unit conversions, or multi-row headers, the system can still extract candidate columns for matching through structural features.

[0034] Step 5: Determining the candidate field set based on role scope: Based on the currently logged-in role, extract the standard field set corresponding to that role from the field responsibility matrix and add it to the common identification field set to form a candidate matching range. Candidate columns are only allowed to match within their designated match range; cross-role matching is not permitted. For example, columns in files uploaded by the construction team can only match fields related to construction, borehole sealing, grouting, and concentration measurement that the construction team is responsible for; columns in files uploaded by the outburst prevention department can only match fields related to networked extraction, extraction concentration, and data comparison that the outburst prevention department is responsible for; columns in files uploaded by the video room can only match fields related to video acceptance that the video room is responsible for. For roles that do not meet the preconditions, the system directly blocks subsequent automatic matching to prevent supplementary data from deviating from the basic borehole record.

[0035] Step 6, Construction of the Attribute Relationship Graph for Mining Borehole Ledgers: Construct an attribute relationship graph G=(V, E) using candidate columns and standard fields as nodes. Each node v∈V corresponds to an uploaded field or standard field. The initial features of the node are the field's basic vector, recording the field name, unit, data type, sample statistical characteristics, etc. Edges E are used to represent business associations, structural associations, or data dependencies between fields, including at least co-occurrence relationship edges, adjacent group relationship edges, arithmetic dependency relationship edges, functional dependency relationship edges, containment dependency relationship edges, and role-state relationship edges. By explicitly modeling the relationships between fields, the system not only compares whether field names are similar, but also determines whether the contextual position and logical function of the field in the borehole ledger are similar.

[0036] Step 7: Establish co-occurrence and adjacent group relationships: If two fields appear in the same uploaded file, the same worksheet, the same merged header area, or the same business group, then establish a co-occurrence relationship edge between the corresponding nodes, with the edge type marked as co-occurs-with. If two fields are adjacent in column order or should appear together in business contexts, for example, the construction team field group includes design hole depth, elevation angle, azimuth angle, hole diameter, drilling location, actual hole depth, etc.; the anti-outburst department field group includes network sampling, 24-hour sampling concentration, 7-10 day sampling concentration, whether the borehole has passed acceptance, etc.; the video room field group includes reporting hole depth, acceptance hole depth, acceptance personnel, total number of drill rods, total meters, number of cement bags, grouting volume, etc., then establish an adjacent group relationship edge, with the edge type marked as group-neighbor. This type of edge is used to solve the difficulty of identification when a single field name is too short or has many abbreviations.

[0037] Step 8, Arithmetic Dependency Establishment: Automated arithmetic relation discovery for numeric fields. First, identify all candidate columns whose data type is integer or floating-point based on the content profile. Then, traverse possible numeric column pairs or triples (col_A, col_B, col_C); where col_A and col_B are the input field columns participating in the operation, and col_C is the output field column for the operation result. For each basic arithmetic operator op∈{+, -, ×, / }, check whether col_A[i]op col_B[i]=col_C[i] holds true in the majority of sample rows i. Here, col_A[i], col_B[i], and col_C[i] represent the values ​​corresponding to columns A, B, and C in the i-th row, respectively. The proportion of rows satisfying this hypothesis to the total number of valid sample rows is calculated as the relation confidence score. When the confidence score exceeds a preset threshold, directed edges are created from node A to node C and from node B to node C, with the edge type marked as arithmetic-dependency, and the operator op and confidence score are used as edge attributes. For mining borehole ledgers, this algorithm can be used to verify the linkage relationships between numerical fields such as total pipe length = actual pipe length + screen pipe length, total meters of video acceptance = total number of pipes × borehole single rod length × wear coefficient, and grouting volume = cement bag × single bag cement weight.

[0038] Step 9 integrates the functional dependency discovery algorithm into the graph construction process. For the set of fields in the uploaded table, the system can use a functional dependency discovery method based on attribute set grids and partition pruning strategies to find the smallest non-trivial functional dependency X->A. For example, a combination of borehole number, date, or shift can uniquely identify the same borehole record. Data uploaded by the construction team, the outburst prevention department, and the video room are all associated with existing borehole ledger records through this common identification field combination. For each functional dependency X->A, the system creates directed edges from each attribute node in X to node A, with the edge type marked as functional-dependency. The system also calculates the inclusion relationship between the sets of field values. If the unique value set S_A of field A is included in the unique value set S_B of field B by a preset proportion, then an inclusion dependency edge is established from A to B, with the edge type marked as inclusion-dependency. This inclusion dependency is used to determine whether the common identification field set such as borehole number, date, or shift uploaded by the outburst prevention department or the video room belongs to the corresponding field set of the basic record already created by the construction team, thus cooperating with step 3 to achieve state pre-verification.

[0039] Step 10, Relational Context Vector Learning: After the attribute relationship graph is constructed, a relational graph convolutional network or an equivalent relation-aware message passing model is used to learn the structured context representation of each field node. For different types of edges, the model learns different transformation parameters, so that relationships such as co-occurs-with, group-neighbor, arithmetic-dependency, functional-dependency, inclusion-dependency, and role-state play different roles in information propagation. After L layers of iteration, each node obtains a relational context vector V_context, which integrates the field structure, business combination, arithmetic relationship, dependency relationship, and role state information within its L-hop neighborhood. For example, when the actual hole depth node has a stable relationship with nodes such as design hole depth, sealing depth, and total pipe length, the representation of the actual hole depth will be integrated into the context of the "construction depth field"; when a candidate field is only similar in name but not in the same business relationship, its relational context similarity will decrease.

[0040] In some preferred embodiments, differentiated transformation weights can be assigned to multiple types of relationship edges, and context vectors can be generated by iteratively fusing field neighborhood business, numerical, and role constraint information over multiple layers; two types of fields, "similar in name but unrelated in business" and "different in name but compatible in business," can be distinguished to further reduce the probability of mismatched abbreviation fields. The specific method is as follows: 1) Define the basic representation of the attribute relationship graph nodes and edges: Let the attribute relationship graph be... ,in For a collection of field nodes, for example, Representing the One upload candidate column node, Representing the One standard field node; It is the set of edges representing relationships between nodes; There are six types of relation edges, corresponding to co-occurrence, adjacent grouping, arithmetic dependency, functional dependency, containment dependency, and role-state relation, respectively; for any relation edge , The relationship type to which this edge belongs; 2) Construction of initial feature vectors for nodes: For any field node The initial features of a node are obtained by concatenating the semantic vector of field names, the unit feature vector, the data type statistical vector, and the sample profile vector. , The initial feature vector dimension, It is a d-dimensional real vector space; 3) Multi-layer relation-aware message-passing iterative computation, the first... The formula for updating the features of layer nodes is: ; Explanation of each parameter in the formula: :node After the first The updated feature vector after layer message passing; :node No. The input feature vector of the layer; : No. The layer node's own feature transformation weight matrix is ​​used to update the node's basic attributes; : No. Layers based on relation types A dedicated, differentiated transformation weight matrix allows for independent weight configuration for different relational edges, distinguishing the information transmission intensity of different business associations such as co-occurrence, arithmetic dependency, and role constraints; After the previous iteration, the neighboring nodes eigenvectors, It is any adjacent field node in the neighborhood set; :node All through relation types A set of connected neighboring nodes; Relationship type Next node The total number of neighboring nodes is used for neighborhood feature mean normalization. : Non-linear activation function, using the ReLU function, introduces non-linear expressive power; 4) Generate the final relation context vector: after pre-setting... After layer-by-layer iterative propagation, retrieve the node. Output features As a relational context vector that integrates neighborhood business combinations, numerical arithmetic associations, and role-based permission constraints; 5) Context similarity determination: Calculate the upload candidate column nodes respectively. Standard field node context vector , The cosine similarity is used as the context similarity of the relationship. This similarity is used to distinguish two types of field scenarios: First, fields with similar literal names but completely unrelated neighboring business fields, numerical dependencies, and role permissions have extremely low context similarity, which suppresses false matching; Second, fields with abbreviations or simplified names but consistent neighboring supporting fields, arithmetic linkages, and belonging roles have high context similarity, which improves the matching accuracy of short and abbreviated fields. Step 11: For each candidate column in the uploaded template and each standard field within the candidate matching range, generate a field name semantic vector, a unit vector, a data type vector, and a sample content profile vector. The field name semantic vector represents the similarity relationship between names such as "hole depth," "drilling depth," and "actual hole depth"; the unit vector represents the consistency or convertibility of units such as m, meter, mm, MPa, and percentage; the data type vector represents types such as integers, floating-point numbers, dates, enumerated values, and text notes; and the sample content profile vector represents the value range, missing rate, number of unique values, format pattern, and outlier ratio of the first N rows of samples.

[0041] Score = α1 * Semantic similarity of field names + α2 * Unit consistency + α3 * Data type consistency + α4 * Relationship context similarity + α5 * Role and permission consistency + α6 * Historical correction reliability To ensure that different types of indicators can participate in the unified weighted calculation, the system normalizes the semantic similarity of field names, unit consistency, data type consistency, relational context similarity, role and permission consistency, and historical correction credibility to the range of [0,1]. All of the above indicators are dimensionless evaluation values. The closer the value is to 1, the more consistent or credible the candidate column is with the standard field in the corresponding dimension; the closer the value is to 0, the greater the difference or the lower the matching credibility. Therefore, when the dynamic weights α1 to α6 are normalized and the sum of the weights is 1, the comprehensive similarity score Score also ranges from [0,1].

[0042] Field Name Semantic Similarity: For each candidate column in the uploaded template and each standard field within the candidate matching range, the system generates a field name semantic vector and calculates the similarity. The system first normalizes the candidate column field names and standard field names, including removing spaces, newlines, parentheses, unit suffixes, special symbols, and unifying full-width and half-width characters, and mapping common abbreviations, historical aliases, and synonyms to standard expressions; then, it generates candidate column field name vector E_name_i and standard field name vector E_name_j respectively. The system calculates the field name semantic similarity based on their cosine similarity.

[0043] Unit consistency: If the unit of a candidate column is exactly the same as the unit of the standard field, or if it is unitless text, the unit consistency value is 1; if the units are different but belong to the same unit of measurement and can be converted, the unit consistency value is determined based on the unit conversion relationship and conversion reliability, with a value range of 0.8; if the candidate column does not explicitly indicate the unit, the unit of the candidate column is inconsistent with the unit of the standard field, or cannot be converted, the unit consistency value is 0. This unit consistency is used to prevent fields with similar names but different unit meanings from being mismatched.

[0044] Data type consistency: For each candidate column and each standard field within the candidate matching range in the uploaded template, the system identifies its data type based on the candidate column sample values ​​and compares it with the preset data type of the standard field to calculate data type consistency. Before calculation, the system first uses statistical sampling to determine the sample set for identification. Let N be the total number of non-empty samples in the candidate column. When N ≤ N_max, all non-empty samples are selected; when N > N_max, the system divides the non-empty samples in the candidate column into K stratified intervals according to the data row position, and randomly or equidistantly selects samples from each stratified interval to form the final sample set. The system identifies the data type of the candidate column based on the final sample set, including numeric, date, time, percentage, enumeration, and text types. The ratio of the number of valid samples to the total number of samples is calculated.

[0045] Relational context similarity: For candidate column node i and standard field node j in the uploaded template, the system obtains the relational context vectors V_context_i and V_context_j obtained after passing through the L-layer relational awareness message, and calculates their cosine similarity as the relational context similarity.

[0046] Role-based permission consistency: The system determines whether a candidate column is allowed to match the corresponding standard field based on the currently uploaded role and the field responsibility matrix. If the currently uploaded role belongs to the set of allowed roles for the standard field, or if the standard field belongs to a common identification field such as hole number, date, or shift, the value is 1; if the currently uploaded role does not belong to the set of allowed roles for the standard field, the value is 0. This role-based permission consistency is used to prevent cross-role mismatches of fields between the construction team, the emergency response department, and the video room.

[0047] Historical Correction Reliability: The system reads historical records of candidate field names, field aliases, associated roles, template sources, and standard field mappings from the historical correction database. It then counts the number of times the candidate field was directly and correctly matched to the target standard field, the number of times a match was manually confirmed, and the number of times it was marked as a non-standard field. The initial value is 0.5. After historical records are established, Historical Correction Reliability = Number of Correct Matches / (Number of Correct Matches + Number of Matches Manually Confirmed + Number of Manual Confirmations for Non-Standard Fields).

[0048] The dynamic weight calculation uses basic weights: field name semantic similarity weight α1 is 0.3, unit consistency weight α2 is 0.1, data type consistency weight α3 is 0.1, relation context similarity weight α4 is 0.2, role permission consistency weight α5 is 0.2, and historical correction credibility weight α6 is 0.1. The initial values ​​are determined through statistical analysis of domain expert experience and historical matching data.

[0049] For the calculation of the dynamic weight of the final comprehensive matching degree, a correction factor is introduced during the weighted fusion process. When the field name is too short or an abbreviation is used, the weight is reduced (correction factor is 0.8). For fields with clear units and strong unit constraints, the weight of unit consistency is increased (correction factor is 1.2). For cases where the number of samples is sufficient and the data format is stable, the weight of data type consistency is increased (correction factor is 1.1). When the role permission matrix is ​​clear, the role permission consistency weight remains unchanged. When the current role has no permissions, the role permission consistency weight is not included in the calculation (correction factor is 0). For cases with a large number of historical confirmations and few false matches, the weight of historical correction credibility is increased (correction factor is 1.2).

[0050] The corrected weights need to be normalized to ensure that the sum of all dynamic weights is 1.

[0051] Step 12: Automatic matching and manual confirmation When the scores of both candidate column i and standard field j are greater than or equal to the preset threshold: Unique matching: If only one candidate column field meets the threshold condition, a one-to-one mapping relationship is directly established, and the mapping type is marked as "unique matching". The attribute relationship graph is updated synchronously, and the number of correct matches is incremented by 1.

[0052] Multiple candidate matching: If two or more candidate column fields meet the threshold condition, another filtering condition is triggered. The field with the highest overall matching score is selected as the primary matching candidate. If the difference between the primary matching candidate and the secondary matching candidate is ≥0.1, a one-to-one mapping relationship is established between the primary matching field and the standard field, and the mapping type is marked as "multiple candidate matching". If there are multiple candidate fields with a difference ≥0.1 between the primary matching candidate and the secondary matching candidate, they are sorted in descending order of score, and the top-ranked field is selected as the final compliant matching item, and the number of correct matches is incremented by 1.

[0053] For source fields where the highest overall matching score is less than a preset threshold, the system initiates a manual review mechanism: Low-confidence candidate field confirmation: If an uploaded column does not meet the matching threshold in the current role's standard field set, the system will submit the source field to the business personnel corresponding to the current upload role for confirmation. The business personnel can confirm the standard field recommended by the system, or they can reselect a standard field from the current role's allowed field set. The number of manual confirmation matches will be incremented by 1.

[0054] Non-standard field confirmation: If manually confirmed, the field is marked as an unknown field or a non-standard field of this template, and the feedback file prompts the user to confirm whether the column is a newly added field, a temporary memo field, or a template entry error. If manually confirmed, it is a newly added standard field, and the system can add it to the standard field library, historical alias library, or business grouping relationship as a basis for subsequent template identification and correction. At the same time, the number of manual confirmations for non-standard fields is increased by 1.

[0055] Step 13 Error-prone Data Validation: After field matching is completed, the system performs role-based and relational validation on the matched standard field data. For construction team data, the system focuses on validating values ​​such as design hole depth, actual hole depth, sealing depth, sealing section length, actual pipe length, screen pipe length, and lower pipe length; verifying that elevation angle, hole diameter, drilling location, and opening height are within acceptable ranges; and verifying the chronological order of hole formation date, sealing date, and grouting date. For outburst prevention department data, the system focuses on validating data such as 24-hour extraction concentration (%), 7-10 day extraction concentration (%), and 30-day extraction concentration (%). For video room data, the system verifies the logical consistency of fields such as reported hole depth, acceptance hole depth, acceptance personnel, drilling team (group) leader, sealing time, grouting time, total number, and total meters. For high-confidence arithmetic and functional dependencies found in the attribute relationship graph, the system also performs consistency checks; if sample data violates the corresponding dependency relationship, an exception message is generated.

[0056] Step 14: Merging and Status Update of the Same Borehole Ledger: The system merges data uploaded by the construction team, the outburst prevention department, and the video room into the same borehole ledger record based on common identification fields such as borehole number, date, or shift. Each operating role can only operate on fields bound to them; for example, the construction team can only operate on the construction team role. After the construction team uploads data, the ledger status is "[Borehole Sealing Completed]". Once the outburst prevention department's data verification is passed, the ledger status is updated to "[Borehole Extraction Acceptance Completed]". Similarly, once the video room's data verification is passed, the ledger status is updated to "[Video Acceptance Completed]". If subsequent roles upload fields that conflict with existing fields, the system determines whether to overwrite, append, or revert based on the field responsibility matrix, the allowed update flag, the upload time, and the result of manual confirmation.

[0057] Step 15: Feedback Generation and Historical Correction Learning: The system writes matching results, unmatched fields, ambiguous fields, status preconditions, permission errors, data format errors, logical validation errors, and relation dependency errors into a feedback file. For manually confirmed field mappings, manually modified standard fields, manually marked mismatches, and newly added aliases, the system writes them into the historical correction database and updates field aliases, sample profiles, relation edge weights, and historical correction reliability, so that the accuracy of automatic matching for subsequent identical mines, teams, or similar templates gradually improves.

[0058] By employing the above method, this invention combines standard templates, field responsibility matrices, system status confirmation, attribute relationship diagrams, relationship context vectors, dynamic weight scoring, and field matching algorithms. This enables construction teams, emergency response teams, and video surveillance rooms to reliably match and validate data within their respective standard field ranges, even if templates are frequently adjusted. This method avoids the inability to import data when fixed templates change slightly, and prevents different role fields from mixing by limiting the range of role fields. Furthermore, it enhances field recognition capabilities by utilizing co-occurrence relationships, adjacent grouping relationships, arithmetic dependencies, functional dependencies, and inclusion dependencies. It can identify fields with slightly different names but consistent business relationships, and filter fields with similar names but inconsistent roles or contexts. This approach is suitable for scenarios where the same borehole log is filled out by multiple roles in stages and fields.

[0059] Please refer to Figure 3 , Figure 4 The method of this invention has been initially applied internally in the management of mine borehole ledgers and has achieved good results in improving quality and efficiency. It can be further promoted to relevant units in the future.

[0060] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for matching and validating fields in a multi-role template of a mining borehole ledger, characterized in that, Includes the following steps: S1. Construct multi-role standard fields and constraint benchmarks: Pre-establish a multi-role standard field library and field responsibility matrix, divide common identification fields and role-specific fields, and limit the boundaries of fields that can be matched for each role; S2. Pre-processing status verification: Distinguish between basic data roles and supplementary data roles. Before uploading, supplementary data roles must verify whether there are compliant basic drilling records. If not, the process will be terminated and an error will be reported. S3. Template Feature Extraction and Candidate Field Locking: Extract structural features of the uploaded template, normalize and parse the multi-dimensional structural features of the uploaded ledger header, limit the matching candidate field set based on the current role from the responsibility matrix, and block cross-role matching. S4. Construct a field attribute relationship graph: Using uploaded fields and standard fields as nodes, mine and establish multiple types of business relationship edges, including co-occurrence, adjacent grouping, arithmetic dependency, functional dependency, containment dependency, and role status. S5. Learning Field Relationship Context Vectors: Employing a hierarchical iterative relation-aware graph convolutional model to integrate field neighborhood business, numerical, and structural association information to generate context representation vectors; S6. Multi-dimensional dynamic weighted matching score: Normalized calculation includes multiple matching indicators such as semantic similarity of field names, consistency of units, consistency of data types, similarity of relational context, consistency of role and permission, and historical credibility. Combined with dynamic correction factors, a comprehensive matching score is obtained. S7. Hierarchical automatic matching and human-machine collaborative confirmation: Automatic mapping or manual review is performed based on matching thresholds and scenarios, and the results of manual operations are stored in the historical correction database. S8. Error-prone data validation: Perform single-column format, value, and time sequence validation according to role-specific rules, and conduct cross-field consistency validation based on relationship diagram constraints.

2. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 1, characterized in that, In step S1, the method for pre-establishing a multi-role standard field library includes: The system pre-maintains standard template libraries for three roles: construction team, gas outburst prevention department, and video room. These standard template libraries do not require uploaded files to remain completely unchanged; instead, they define the standard field sets, common aliases, units, data types, required attributes, value ranges, relationships between adjacent fields, computable relationships, and ledger status rules for each role. The construction team's standard field set includes borehole number, shift, designed borehole depth, elevation angle, borehole diameter, drilling location, and actual borehole depth. The gas outburst prevention department's standard field set includes networked sampling, 24-hour sampling concentration, 7-10 day sampling concentration, and whether the borehole has passed acceptance. The video room's standard field set includes reported borehole depth, accepted borehole depth, acceptance personnel, total number of drill rods, total meters, cement bags, and grouting volume. For each standard field, the system records its field name, historical aliases, unit expression, data type, sample value distribution, business grouping, applicable arithmetic relationships, and dependencies with other fields. The field responsibility matrix records the following field constraint attributes: the responsibility role corresponding to the standard field, whether it is a public identification field, whether it is required, standard data type, standard value unit, value range, and whether the field is allowed to be updated later; the matrix constraints prevent template columns of non-responsibility roles from being mismatched with exclusive business fields.

3. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 1, characterized in that, The pre-state verification in step S2 specifically includes: When the current uploading role is the construction team, it is allowed to create a brand new borehole foundation record through public identification fields; When the current uploading role is the Anti-outburst Section or Video Room, the system searches for the basic drilling records that have been verified by the construction team by combination of borehole number, working face, roadway, and drilling batch. If no matching record is found, a status pre-error feedback is generated, and the subsequent field matching process is terminated. If a matching record is found, the process is allowed to proceed to the template structure feature extraction step.

4. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 1, characterized in that, Step S3 involves extracting structural features from the uploaded template and normalizing the multi-dimensional structural features of the uploaded ledger header. The methods include: Read the worksheet name, header row, table header, merged cells, unit sub-row, column sorting order, cell comments, and the first N rows of sample data from the data table template; Standardize the header text by removing spaces, line breaks, parentheses, full-width / half-width special characters, and end-of-page unit suffixes. Each candidate field is encapsulated into a six-dimensional feature: field name feature, unit feature, data type feature, sample value distribution feature, adjacent column structure feature, and worksheet affiliation feature; Based on the above multidimensional features, candidate column identification is completed in scenarios such as header abbreviation, multi-row merged headers, disordered column order, and unit variants.

5. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 1, characterized in that, The method for limiting the matching candidate field set based on the current role from the responsibility matrix and blocking cross-role matching in step S3 includes: extracting the standard field set corresponding to the current logged-in role from the field responsibility matrix and adding it to the common identification field set to form a candidate matching range; the candidate column is only allowed to be matched within the candidate matching range and cross-role matching is not allowed.

6. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 1, characterized in that, The rules for constructing each business relationship edge in step S4 are as follows: 1) Co-occurrence relationship edge co-occurs-with: When two fields are in the same worksheet, the same merge header, and the same business group, an undirected co-occurrence edge is established; 2) Adjacent grouped edges: When two table columns are adjacent or required to be matched by business logic, an undirected grouped edge is established; 3) Arithmetic-dependency: Traverse the binary / ternary combinations of numerical fields, verify that addition, subtraction, multiplication, and division operations are valid in sample rows exceeding the threshold proportion, and create directed edges from the operation source node to the result node. The edge attributes store the operator and operation confidence. 4) Functional dependency edges: Discover the smallest nontrivial functional dependency X→A, and establish directed edges pointing all field nodes in X to node A; the combination of common identification fields is uniquely bound to the borehole record through this type of edge; 5) Inclusion-dependency: If a high percentage of the unique value set of field A is contained in the unique value set of field B, a directed edge is established from A to B to verify whether the supplementary role public field matches the construction basic record. 6) Role-state relationship edge: binds fields to corresponding operation roles and ledger stage state constraints. Operation roles can only operate on the fields bound to themselves.

7. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 6, characterized in that, The specific method of step S5 is as follows: After the attribute relationship graph is constructed, a relationship graph convolutional network or an equivalent relationship-aware message passing model is used to learn the structured context representation of each field node; for different types of edges, the model learns different transformation parameters so that relationships such as co-occurs-with, group-neighbor, arithmetic-dependency, functional-dependency, inclusion-dependency, and role-state play different roles in information propagation; after L-layer iterations, each node obtains a relationship context vector V_context, which integrates the field structure, business composition, arithmetic relationship, dependency relationship, and role state information in its L-hop neighborhood.

8. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 1, characterized in that, The specific method in step S6 is as follows: Multiple matching metrics are defined as follows: 1) Semantic similarity of field names: After standardizing the field names, a semantic vector is generated. Cosine similarity is used to calculate the similarity to adapt to scenarios such as field abbreviation, synonym replacement, and alias. 2) Unit consistency: 1 for units that are completely consistent or have no units; 0.8 for units that are convertible and have the same dimensions; 0 for units that conflict or have no label. 3) Data type consistency: Stratified sampling is used to extract column samples, identify numeric / date / enumeration / text types, and compare them with standard field types to output a normalized consistency score; 4) Relational context similarity: Cosine similarity of multi-level context vectors of candidate column nodes and standard field nodes; 5) Role-based permission consistency: 1 for roles with responsibility or common fields; 0 for non-responsibility roles. 6) Historical correction reliability: initial value 0.5, equal to the number of correct matches / (number of correct matches + number of manually confirmed matches + number of manually confirmed non-standard fields); The formula for calculating the overall matching score is: Score = α1 × field name semantic similarity + α2 × unit consistency + α3 × data type consistency + α4 × relationship context similarity + α5 × role and permission consistency + α6 × historical correction credibility; The initial base weights are α1=0.3, α2=0.1, α3=0.1, α4=0.2, α5=0.2, and α6=0.

1. All dimension scores and corrected weights are normalized to the [0,1] interval.

9. The method for multi-role template field matching and verification of mining borehole ledgers according to claim 1, characterized in that, The method for step S7, hierarchical automatic matching and human-machine collaborative confirmation, is as follows: When the scores of both candidate column i and standard field j are greater than or equal to the preset threshold: Unique matching: If only one candidate column field meets the threshold condition, a one-to-one mapping relationship is directly established, and the mapping type is marked as "unique matching". The attribute relationship graph is updated synchronously, and the number of correct matches is incremented by 1. Multiple candidate matching: If two or more candidate column fields meet the threshold condition, another filtering condition is triggered. The field with the highest overall matching score is taken as the primary matching candidate. If the difference between the primary matching candidate and the secondary matching candidate is ≥0.1, a one-to-one mapping relationship is established between the primary matching field and the standard field, and the mapping type is marked as "multiple candidate matching". If there are multiple candidate fields with a difference of ≥0.1 between the primary matching candidate and the secondary matching candidate, they are sorted in descending order of score, and the top 1 field is taken as the final compliant matching item. The number of correct matches is incremented by 1. For source fields where the highest overall matching score is less than a preset threshold, the system initiates a manual review mechanism: Low-confidence candidate field confirmation: If an uploaded column does not meet the matching threshold in the current role's standard field set, the system will submit the source field to the business personnel corresponding to the current upload role for confirmation. The business personnel can confirm the standard field recommended by the system, or reselect the standard field from the current role's allowed field set. The number of manual confirmation matches will be increased by 1. Non-standard field confirmation: If manually confirmed, it is marked as an unknown field or a non-standard field of this template, and a prompt is made in the feedback file to confirm whether the column is a newly added field, a temporary remark field, or a template filling error; If a field is confirmed by manual verification to be a newly added standard field, the system can add it to the standard field library, historical alias library, or business grouping relationship as the basis for subsequent template identification and correction. At the same time, the number of manual verifications for non-standard fields will be increased by 1.

10. The method for matching and validating fields of multi-role templates in mining borehole ledgers according to any one of claims 1-9, characterized in that, Step S8 includes: After field matching is completed, the system performs role-based and relational verification on the matched standard field data: The construction team data focuses on verifying whether the values ​​including the designed hole depth, actual hole depth, sealing depth, sealing section length, actual pipe length, screen pipe length, and lower pipe length are valid; verifying whether the data including the elevation angle, hole diameter, drilling position, and opening height are within the range; and verifying the time sequence of the hole-forming date, sealing date, and grouting date. The anti-outburst department data focuses on verifying whether the data including the 24-hour extraction concentration (%), 7-10 day extraction concentration (%), and 30-day extraction concentration (%) are qualified. The video room data verifies whether the numerical segments including the reported hole depth, acceptance hole depth, acceptance personnel, drilling team leader, sealing time, grouting time, total number, and total meters are logically consistent. For high-confidence arithmetic dependencies and functional dependencies found in the attribute relationship graph, the system also performs consistency verification. If the sample data violates the corresponding dependency relationship, an anomaly prompt is generated.

Images