Oil and gas reservoir characterization data reconstruction method fusing data blood relationship and knowledge graph

Abstract

The application discloses a method for reconstructing oil and gas reservoir characterization data by fusing data blood relationship and a knowledge graph, and the method comprises the following steps: acquiring a to-be-reconstructed object data set, normalizing the names of object records, unifying units, and unifying depth references and coordinate references to obtain a standardized object set; then constructing a knowledge graph and a data blood relationship graph, generating candidate object pairs, and calculating blood relationship compatibility scores to obtain a blood relationship compatible candidate set; subsequently performing semantic judgment based on local subgraph structures and object pair features to obtain classification results of objects that can be merged, need to be split and reconstructed, or have evolution relationships that need to be retained; for the candidate object pairs that need to be split and reconstructed, further tracing upstream processing chains, extracting a minimum conflict evidence set and locating a process branching point, performing reconstruction write-back, and generating reconstructed object data, object mapping relationships, and version relationships.

Description

Technical Field

[0001] This application relates to the field of knowledge graph technology, and more specifically, to a method for reconstructing oil and gas reservoir characterization data by integrating data lineage and knowledge graph. Background Technology

[0002] Oil and gas reservoir characterization data are usually stored in multiple operational systems such as well logging interpretation, seismic interpretation, core experiments, and comprehensive research results. The data sources are diverse, and there are differences in naming rules, unit systems, depth benchmarks, and coordinate benchmarks. Moreover, during long-term production, the data undergoes multiple rounds of interpretation, correction, revision, and version replacement, which can easily lead to situations where there are homonyms, homonyms, and multiple versions coexisting.

[0003] Existing processing methods primarily rely on name matching, field cleaning, manual sorting, or alignment based on local attributes. They fail to adequately utilize the processing steps, parameter configurations, time information, and manual revision records during object generation, making it difficult to accurately reflect the true source and evolutionary relationships between objects. In such cases, mismatches, overwriting, or version mixing can easily occur during data merging, thereby affecting stratigraphic attribution, well section comparison, result traceability, and subsequent research applications.

[0004] Therefore, it is necessary to propose a method that can simultaneously utilize data lineage information and semantic relationships of knowledge graphs to carry out unified reconstruction of oil and gas reservoir characterization objects. Summary of the Invention

[0005] This application provides a method for reconstructing oil and gas reservoir characterization data by integrating data lineage and knowledge graph, so as to at least solve some of the technical problems existing in the related technologies described above.

[0006] According to a first aspect of the embodiments of this application, a method for reconstructing oil and gas reservoir characterization data by integrating data lineage and knowledge graph is provided, comprising: acquiring a set of object data to be reconstructed; standardizing the names, unifying the units, and unifying the depth and coordinate references of the object records in the set of object data to be reconstructed to obtain a standardized object set; constructing a knowledge graph containing object instance nodes and semantic relationship edges based on the standardized object set, and constructing a data lineage graph based on the processing step records, parameter snapshots, and generation times corresponding to each object record; generating candidate object pairs according to object type, spatial location, depth range, and standard name, and calculating each candidate object pair based on the data lineage graph. The lineage compatibility of object pairs is scored to obtain a lineage-compatible candidate set. For each candidate object pair in the lineage-compatible candidate set, semantic judgment is performed based on the local subgraph structure and object pair features in the knowledge graph to obtain a classification result. The classification result includes whether the object pairs can be merged, need to be split and reconstructed, or retain evolutionary relationships. The retained evolutionary relationships include evolutionary relationships and substitution relationships. Based on the classification result, a reconstruction write-back is performed. For candidate object pairs that need to be split and reconstructed, the upstream processing chain is traced along the data lineage graph to extract the minimum conflict evidence set and locate the process bifurcation point. After the reconstruction write-back is performed, the reconstructed object data, object mapping relationships, and version relationships are generated.

[0007] As an optional approach, the object record includes at least the object number, object type, original name, source system identifier, spatial coordinates, depth start point, depth end point, version identifier, generation time, and original record pointer; the name standardization includes well number standardization, layer name mapping, and curve name normalization; after the depth benchmark and coordinate benchmark are unified, the original fields and unified fields are retained.

[0008] As an optional approach, the data lineage graph uses object instances and processing step instances as nodes, and input relationships, output relationships, parameterization relationships, and inheritance relationships as edges; each processing step instance records at least the step type, step order, parameter snapshot, execution time, and executor identifier; and generates a lineage signature for each object consisting of a source domain identifier, step sequence, key parameter summary, baseline type, and time identifier.

[0009] As an optional approach, generating candidate object pairs based on object type, spatial location, depth range, and standard name includes: generating a candidate set of the same type or a preset candidate set of different types according to object type, and generating candidate object pairs using the same hash symbol, similar spatial location, intersecting depth range, or matching standard name as retrieval conditions.

[0010] As an optional approach, the lineage compatibility score is calculated by weighting source domain consistency, baseline consistency, process continuity, temporal validity, and manual revision consistency. The lineage compatibility score is compared with a compatibility threshold, and candidate pairs with scores not lower than the compatibility threshold are retained as the lineage compatibility candidate set.

[0011] As an optional approach, the object pair features include standard name similarity features, spatial proximity features, depth interval overlap features, attribute difference features, version time difference features, and the lineage compatibility score. The local subgraph structure consists of the central node corresponding to the candidate object pair and its first-order and second-order neighbors.

[0012] As an optional approach, the semantic determination employs a relation-aware graph convolutional network model, which includes: a subgraph construction module, a node attribute encoding module, a relation-aware graph convolutional module, a pairwise feature fusion module, and a classification output module. The relation-aware graph convolutional module aggregates neighbor node information according to different semantic relationship edges, and the classification output module outputs the classification results for mergeable, reconstructable, and evolution-preserving nodes.

[0013] As an optional approach, the minimum conflict evidence set is obtained by comparing the two upstream processing chains corresponding to the candidate objects that need to be split and reconstructed. Specifically, it includes: determining the common prefix step sequence of the two upstream processing chains, determining the first difference step after the end of the common prefix step sequence as the candidate process bifurcation position, and extracting the minimum difference items that support the decision that cannot be merged in the order of step difference, parameter snapshot difference, benchmark difference and manual revision difference, as the minimum conflict evidence set.

[0014] As an optional approach, the reconstructing and writing back based on the classification results includes: for candidate object pairs that can be merged, determining the main object and registering the original business identifier and original name of the merged object; for candidate object pairs that need to be split and reconstructed, generating multiple new object versions based on the minimum conflict evidence set and process bifurcation point and attaching them to the corresponding subsequent processing chains; and for candidate object pairs that retain evolutionary relationships, establishing evolutionary relationships or substitution relationships in the knowledge graph.

[0015] According to a second aspect of the embodiments of this application, a system for reconstructing oil and gas reservoir characterization data by integrating data lineage and knowledge graph is also provided, comprising: a data acquisition and standardization module, configured to acquire a set of object data to be reconstructed, and to standardize the names, unify the units, and unify the depth and coordinate references of the object records in the set of object data to be reconstructed, thereby obtaining a standardized object set; a graph construction module, configured to construct a knowledge graph containing object instance nodes and semantic relationship edges based on the standardized object set, and to construct a data lineage graph based on the processing step records, parameter snapshots, and generation times corresponding to each object record; and a candidate generation and filtering module, configured to generate candidate object pairs based on object type, spatial location, depth range, and standard name, and to filter the data based on the data... The lineage compatibility score of each candidate object pair is calculated based on the lineage graph, and a lineage compatible candidate set is obtained. The semantic determination module is configured to perform semantic determination on each candidate object pair in the lineage compatible candidate set based on the local subgraph structure and object pair features in the knowledge graph to obtain a classification result. The classification result includes mergeable, split-and-reconstruct, or evolutionary relationship preserved. The evolutionary relationship preserved includes evolutionary relationship and substitution relationship. The reconstruction write-back module is configured to perform reconstruction write-back based on the classification result. Specifically, for candidate object pairs that need to be split and reconstructed, the upstream processing chain is traced along the data lineage graph to extract the minimum conflict evidence set and locate the process bifurcation point. After the reconstruction write-back is performed, the reconstructed object data, object mapping relationship, and version relationship are generated.

[0016] Compared to existing data reconstruction methods that primarily rely on name matching, attribute similarity, or manual organization, this invention combines data lineage information with semantic relationships in a knowledge graph. Candidate objects are first screened for lineage compatibility, then semantically judged. When conflicts exist, the minimum conflict evidence set is extracted, process bifurcation points are located, and corresponding reconstruction write-backs are performed. Using this invention, in multi-source heterogeneous oil and gas reservoir characterization data with coexisting historical versions, it is possible to more accurately distinguish between mergeable objects, objects that need to be split, and objects whose evolutionary relationships should be preserved, reducing erroneous object merging, erroneous splitting, and version mixing. Simultaneously, the reconstruction results retain the source chain, object mapping relationships, and version relationships, facilitating subsequent querying, tracing, and continuous maintenance. Therefore, it is more suitable for application scenarios involving long-term accumulation, multiple rounds of interpretation, and repeated revisions of oil and gas reservoir characterization data.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Furthermore, no embodiment in this disclosure is required to achieve all the effects described above. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0019] Figure 1 A schematic diagram of a method for reconstructing oil and gas reservoir characterization data by fusing data lineage and knowledge graphs, provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of the bloodline compatibility candidate set screening process provided in the embodiments of this disclosure; Figure 3 This is a schematic diagram of the semantic determination process provided in the embodiments of this disclosure; Figure 4 This is a schematic diagram of the semantic determination model structure provided in the embodiments of this disclosure; Figure 5 This is a schematic diagram of the refactoring and write-back process provided in the embodiments of this disclosure; Figure 6 A schematic diagram of the structure of an oil and gas reservoir characterization data reconstruction system that integrates data lineage and knowledge graph provided in this embodiment of the disclosure; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0021] This implementation method is applicable to oil and gas field exploration and development data platforms. The executing entity can be a data reconstruction program on a server or a processing node composed of a relational database, a graph database, and a model inference service. Input data includes at least the following object records: well, well section, stratigraphic level, sub-layer, logging curve version, interpretation result version, core sample, and experimental conclusions; as well as the corresponding processing step records, parameter snapshots, generation time, manual revision records, and original record pointers. All source data has been collected and stored in the source database before the execution process, retaining traceable source identifiers. The reconstruction task can be triggered by adding a new interpretation batch, migrating historical results, version updates, or manual task submission.

[0022] In practice, the implementing entity can first establish a task context, which includes a source system list, an object type list, a standard terminology list, a benchmark transformation rule table, a relation type table, a lineage extraction rule table, a model parameter table, and a write-back rule table. The source system list provides access points to the well logging database, seismic interpretation database, core experiment database, interpretation results database, and historical file repository. The object type list limits the object categories that can be processed in this task. The standard terminology list stores the standardized expressions for well numbers, layers, sublayers, curve names, and interpretation result names. The benchmark transformation rule table specifies the conversion methods between depth benchmarks and coordinate reference systems. The relation type table and the lineage extraction rule table are used for map construction and lineage extraction, respectively. The model parameter table stores the network structure parameters, training parameters, and threshold parameters of the semantic judgment model. The write-back rule table specifies the rules for determining the primary object, version generation, alias registration, and consistency verification.

[0023] The implementation process of the method described in this application will be described in detail below with reference to specific embodiments. It should be noted that this embodiment is only used to explain this application and is not intended to limit the scope of protection of this application. Conventional adjustments or substitutions of each step by those skilled in the art without departing from the concept of this application should be included in the scope of protection of this application.

[0024] Please see Figure 1 , Figure 1 This is a flowchart of a method for reconstructing hydrocarbon reservoir characterization data by fusing data lineage and knowledge graphs according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes steps S1-S5: In step S1, a set of object data to be reconstructed is obtained, and the object records in the set of object data to be reconstructed are standardized in name, unit, depth reference and coordinate reference to obtain a standardized object set.

[0025] After reading the source database data, the executing entity first forms an object raw record set. Each record in the object raw record set is mapped to an instance of an object to be processed and includes at least the object number, object type, original name, source system identifier, spatial coordinates, depth start point, depth end point, version identifier, generation time, and original record pointer. For semi-structured output files, the executing entity extracts corresponding fields according to predefined field templates and label rules; for processing logs and revision records, the executing entity extracts the step name, step order, parameter key-value pairs, execution time, and executor identifier. This forms unified object records and step records for subsequent standardized processing and graph structure construction.

[0026] After the object records are established, the executing entity first performs name standardization and benchmark unification. Specifically, well number standardization is based on the well area prefix, well sequence number, and branch number, which are then split and reorganized. Layer name mapping is based on the layer, group, segment, and sub-layer entries in the standard terminology table, and is performed in the order of full name mapping, abbreviation mapping, and layer correction. Curve name unification is based on the curve type dictionary. If the same name cannot be mapped to a unique standard item at once, the executing entity performs a secondary determination based on the object type and related fields in the same record. For example, layer objects are preferentially referenced to the layer dictionary, and curve objects are preferentially referenced to the curve name table. After standardization, the system retains both the original name and the standard name.

[0027] For depth and coordinate references, the execution entity uses a combination of unified and original fields. If the source record contains both depth sounding and vertical depth, the system designates one as the unified depth field based on the task settings, while the other remains the original depth field. If only one depth expression exists, a depth reference type field is added to the object record, and the other depth value is not calculated in reverse. Coordinates are handled similarly: the system reads the coordinate reference system corresponding to the source system, performs coordinate transformation according to the reference transformation rule table, writes the transformation result into the unified coordinate field, and retains the original coordinate field and coordinate reference type. For numerical fields such as porosity, permeability, and thickness, a unified unit conversion is performed.

[0028] In some embodiments, the basic data structure employs the following four core record categories. Specifically, the first category is object records, which, in addition to the aforementioned basic fields, may also include a unified name, unified coordinates, a unified depth range, a current state flag, and extended attributes. The second category is relation records, which record the starting object number, the target object number, the relation type, the basis for relation establishment, and a timestamp. The third category is lineage records, which record the source object number, the step number, the target object number, the step order, parameter snapshots, and the generation time. The fourth category is candidate object pair records, which record the first object number, the second object number, the basis for candidate generation, lineage compatibility score, classification results, and subsequent reconstruction actions.

[0029] In step S2, a knowledge graph containing object instance nodes and semantic relationship edges is constructed based on the standardized object set, and a data lineage graph is constructed based on the processing step records, parameter snapshots and generation times corresponding to each object record.

[0030] In some embodiments, a knowledge graph is constructed based on a standardized set of objects as nodes. Wells, well sections, stratigraphic levels, sub-layers, logging curve versions, interpretation result versions, core samples, and experimental conclusions are stored as different node types, and relational edges are generated line by line according to a relational type table. For example, if the depth range of a well section object is within the depth range of a stratigraphic object and the well numbers are the same, the system establishes a membership relationship between them; if a logging curve version is referenced in an interpretation result record, an interpretation-self relationship is established; if the result record has been manually revised, the system establishes a processing step node for the revision action and then connects it through a revision-to-relationship. Each relational edge is written with a basis for its establishment, which can be a trigger rule name or an original record number. This allows for tracing the formation basis of each relational edge, and any relation in the graph can be traced back to the original evidence that formed that relation.

[0031] Data lineage graphs and knowledge graphs can be built in parallel, but data lineage graphs focus on object source chains rather than semantic adjacencies. Specifically, the executing entity uses object instances and processing step instances as nodes, and input relationships, output relationships, parameterization relationships, and inheritance relationships as edges. For each object, the system reads its corresponding processing step record and creates processing step instances in sequence. Each processing step instance includes at least the step type, step order, parameter snapshot, execution time, and executor identifier. If an object is formed by multiple source objects, such as when interpretation results simultaneously reference well logging curve versions and stratigraphic results, the system establishes input relationships for each source object and then connects them to the target object through step instances. Parameter snapshots are saved in key-value pair format and may include correction parameters, smoothing parameters, template versions, or manual revision notes.

[0032] In one embodiment, for rapid subsequent filtering, the executing entity generates a lineage signature for each object. The lineage signature is formed by concatenating a source domain identifier, a step sequence, a key parameter summary, a baseline type, and a time identifier in a fixed order. The source domain identifier reflects which category the object originates from: well logging, seismic, experimental, or comprehensive interpretation domain. The step sequence records the types of processing steps the object undergoes from the source object to the current object and their sequential relationship. The key parameter summary filters and encodes fields that have a significant impact on object determination from parameter snapshots. The baseline type corresponds to the baseline used for the unified depth field and the unified coordinate field. The time identifier is mapped from the generation time. For parameters in the key parameter summary, the system first calculates the correlation between each parameter and the final determination result based on historical manual determination samples. Then, parameters with a correlation higher than the filtering threshold are included in the key parameter set. The filtering threshold can be determined based on the correlation ranking of each parameter in the historical manual determination samples to the final determination result. Preferably, the top N parameters in the correlation ranking are retained, where N is preset by the model parameter table in the task context; or parameters with a correlation score not lower than the filtering threshold are retained. The filtering threshold is determined by offline calibration of historical manual determination samples.

[0033] In step S3, candidate object pairs are generated based on object type, spatial location, depth range, and standard name. Based on the data lineage map, the lineage compatibility score of each candidate object pair is calculated, and a lineage compatible candidate set is obtained by filtering.

[0034] Please see Figure 2 , Figure 2 A schematic diagram illustrating the bloodline compatibility candidate set screening process provided in an embodiment of this disclosure is shown. Figure 2 As shown, in step S201, candidate object pairs are generated based on object type, spatial location, depth range, and standard name.

[0035] The executing entity first divides the candidate sets according to object type, forming candidate sets of the same type for each of the following: well-to-well, well-section-to-well-section, layer-to-layer, sub-layer-to-sub-layer, logging curve version-to-logging curve version, and interpretation result version-to-interpretation result version. If a specific cross-type mapping is preset in the task context, such as an auxiliary mapping between well sections and interpretation results, the system establishes a separate cross-type candidate set, but this set is not mixed with the candidate sets of the same type. After the division is completed, the system establishes a multi-dimensional retrieval index for each set, with index fields including standard name, well number, unified coordinates, unified depth range, and version time.

[0036] During the candidate retrieval phase, the executing entity employs different retrieval conditions for different types of objects. Specifically, for stratigraphic objects, the system uses consistent well numbers or similar structural locations as prerequisites, and consistent standard stratigraphic names or name similarity reaching the retrieval lower limit as supplementary conditions. For well logging curve versions, consistent well numbers and consistent curve categories are prerequisites, while similar version times and approximate parameter summaries are supplementary conditions. For interpretation result versions, consistent well numbers, consistent object types, and intersecting depth intervals are prerequisites, while matching standard names or similar spatial locations are supplementary conditions. Spatial proximity is preferably determined by a unified coordinate distance not exceeding a preset spatial distance threshold, and depth interval intersection includes at least the presence of a non-zero overlap length or an overlap ratio not less than a preset threshold. The retrieval lower limit, spatial distance threshold, and overlap ratio threshold are preset by the model parameter table in the task context and can be adjusted offline based on historical manual judgment samples.

[0037] In step S202, the bloodline compatibility score of each candidate object pair is calculated based on the data bloodline map.

[0038] The executing entity extracts sub-indicators from object records and data lineage maps, namely source domain consistency, baseline consistency, process continuity, temporal validity, and manual revision consistency. Source domain consistency reflects whether two objects originate from the same data domain or whether a pre-defined legal mapping relationship exists. If both objects originate from the well logging interpretation domain, this indicator takes a high value; if the two objects originate from the well logging interpretation domain and the seismic inversion domain respectively, and the task configuration does not allow direct comparison, this indicator takes a low value. Baseline consistency is evaluated based on the depth baseline type corresponding to the unified depth field and the coordinate baseline type corresponding to the unified coordinate field. Process continuity is obtained by comparing the step sequence and key parameter summary in the lineage signatures of two objects; if one step chain is a prefix extension of another step chain, or if there is a clear inheritance relationship between the two, the process continuity is high. Temporal validity is determined based on the similarity of generation time, effective time, and batch. Manual revision consistency compares the revision type, revision batch, reviser, and revision description summary in the manual revision record.

[0039] The implementing entity will weight and combine the above indicators to form a bloodline compatibility score: In the formula, Indicates bloodline compatibility score; to These represent source domain consistency, baseline consistency, process continuity, temporal validity, and manual revision consistency, respectively, with each index normalized to the range of 0-1. to To ensure the corresponding weighting coefficients are equal to 1, the sum of all coefficients must be equal to 1. Each weighting coefficient can be preset, and the system can recalibrate it during the offline update cycle after accumulating sufficient samples. Homologous objects and homologous objects often share similar names and spatial attributes; relying solely on surface features will broaden the range of misjudgments. Through the above processing, by introducing source chain information, the system first narrows down the set of objects to be compared at the process and benchmark levels.

[0040] In step S203, a candidate set of bloodline compatibility is selected based on a compatibility threshold. The executing entity compares the bloodline compatibility score with the compatibility threshold, which can be denoted as: This indicates the minimum score required for a candidate object to enter the semantic evaluation process. It can be obtained through offline calibration of the verification sample.

[0041] Specifically, the system calculates the false merging rate, false negative rate, and comprehensive evaluation index under multiple threshold conditions, and selects the threshold with the false merging rate not exceeding the task configuration limit and the optimal comprehensive evaluation index as the threshold. If the bloodline compatibility score of a candidate pair is lower than... The system marks the object pair as a bloodline incompatible object pair and will not proceed to subsequent semantic judgment; if the score is not lower than If so, it is written into the bloodline compatible candidate set.

[0042] In step S4, for each candidate object pair in the bloodline compatible candidate set, semantic determination is performed based on the local subgraph structure and object pair features in the knowledge graph to obtain the classification result. The classification result includes whether the object can be merged, needs to be split and reconstructed, or retains the evolutionary relationship.

[0043] Please see Figure 3 , Figure 3 A schematic diagram of the semantic determination process provided in an embodiment of this disclosure is shown. For example... Figure 3 As shown, in step S301, for each pair of bloodline compatible candidate objects, the execution entity extracts a local subgraph from the knowledge graph.

[0044] The local subgraph uses two candidate objects as central nodes, expands outwards to first-order and second-order neighbors, and retains relation edges related to the central nodes. Relation edge types include one or more of the following: belonging to relation, corresponding relation, covering relation, interpreting from relation, generating from relation, and revising from relation.

[0045] Optionally, if the local subgraph is too large, the system prunes it according to the priority of relation edges and the credibility of the basis for their establishment. The credibility of the basis for establishment is derived from the evidence source field in the relation record; for example, relations formed directly by citing the original results have higher credibility than relations formed solely by rule inference. During pruning, nodes and edges that are closer in connection level to the central node and have higher evidence credibility are prioritized. After this processing, the local subgraph can centrally reflect the semantic neighborhood structure of candidate objects without being disturbed by irrelevant distant neighbors.

[0046] In step S302, node attribute vectors and object pair features are generated. Nodes in each local subgraph need to be converted to numerical representations. The execution entity constructs attribute vectors for each node. These attribute vectors consist of object type encoding, standard name segmentation vectors, unified coordinate vectors, unified depth interval vectors, version time vectors, and source system encoding. Object type encoding is generated using a discrete mapping method; the standard name segmentation vector is formed based on segmentation from an oil and gas terminology list; the unified coordinate vector and unified depth interval vector are directly derived from the standardized object set; and the version time vector is mapped from the generation time. If a node type lacks a certain field (e.g., a core sample lacks a curve name field), the corresponding position is filled with zero values ​​to ensure consistent model input dimensions.

[0047] In addition to node attribute vectors, the execution entity also generates paired features for candidate objects. These paired features include standard name similarity features, spatial proximity features, depth interval overlap features, attribute difference features, version time difference features, and lineage compatibility scores. Standard name similarity features can be constructed from edit distance and word segmentation intersection-union ratio; spatial proximity features are represented by uniform coordinate distance; depth interval overlap features are represented by the overlap ratio of the depth intervals of two objects; attribute difference features are represented by the difference or segmented difference of the main attribute fields, where the main attribute fields at least include key business attributes, statistical attributes, or experimental attributes corresponding to the object type; and version time difference features are represented by the generation time difference. If an object does not have a corresponding attribute field, the difference item is recorded as a preset default value, and a missing marker is added to the feature.

[0048] In step S303, based on the local subgraph structure and object pair features in the knowledge graph, semantic determination is performed through a relation-aware graph convolutional network model to obtain the classification result.

[0049] In some embodiments, a relation-aware graph convolutional network model is used as the semantic determination model. See also Figure 4 , Figure 4 A schematic diagram of the semantic determination model structure provided in an embodiment of this disclosure is shown. For example... Figure 4As shown, the model sequentially includes a subgraph construction module, a node attribute encoding module, a relation-aware graph convolution module, a pairwise feature fusion module, and a classification output module. The subgraph construction module receives the local subgraph structure and node indices; the node attribute encoding module receives the node attributes in the local subgraph and outputs the initial representation vector of each node; the relation-aware graph convolution module consists of two relation-aware graph convolutional layers, each aggregating neighbor node information according to the relation edge type and retaining the representation of the central node itself; the pairwise feature fusion module concatenates the structural representations of the two central nodes with the object's pairwise features and maps them to a unified decision space; the classification output module contains a hidden layer and a classification layer, outputting three types of results, corresponding to mergeable, split-and-reconstructed, and evolutionary relationship-preserving results.

[0050] In the relation-aware graph convolutional module, each type of relation edge corresponds to a set of independent transformation matrices. For a given node, its representation in the next layer is obtained by summing the transformed representations of its adjacent nodes under each relation type, and then superimposing these representations on the node's own representation. Specifically, the single-layer update method can be represented by the following formula: in, Indicates the first Layer nodes The representation vector; Represents a set of relation types; Indicates the relationship With nodes The set of connected neighboring nodes; Normalization factor; For relationship In the The transformation matrix of the layer; The node self-loop transformation matrix; The activation function is nonlinear. After two layers of graph convolution processing, the system obtains structural representations of two central nodes. Compared with graph convolution methods that do not distinguish between relation types, this model structure can retain the influence of membership relation, interpretation relation, and revision relation on node semantics, making it more suitable for scenarios where the neighborhood structure of oil and gas reservoir characterization objects is heterogeneous and the origin of relations is complex.

[0051] In one embodiment, model training can be performed offline. Specifically, the execution entity extracts manually verified object pair samples from historical reconstruction tasks and labels the samples into three classes. For each object pair sample, a local subgraph, node attribute vectors, and object pair features are constructed and input into a relation-aware graph convolutional network model. During training, the node attribute encoding module first maps discrete features into vector representations, the relation-aware graph convolutional module performs two layers of neighbor aggregation, the pair feature fusion module outputs a joint representation, and the classification output module provides the probabilities of the three classes. The system updates model parameters based on classification error. After multiple training epochs, the optimal model parameters are selected and fixed based on validation samples. The classification confidence threshold can be determined by comparing the false merging rate, false splitting rate, and macro-average F1 score under different threshold conditions on validation samples. If the maximum classification probability of a candidate object pair is lower than this threshold, the system retains it as an evolutionary relationship and does not directly trigger merging or splitting. This setting controls the impact of low-confidence samples on subsequent reconstruction actions.

[0052] In one embodiment, after semantic determination, the executing entity performs consistency correction on the results. Specifically, if an object is determined to be mergeable with multiple objects simultaneously, the system sorts them according to classification probability, lineage compatibility score, and version time difference, retaining only the best-ranked pair of objects in the merging queue, while the remaining pairs are moved to the evolutionary relationship queue. If a candidate pair of objects is determined to be mergeable, but there is a clear mutual exclusion relationship in its local subgraph, such as belonging to two mutually exclusive layers in the same temporal state, the system reclassifies the pair as needing to be split and reconstructed. This post-processing step ensures that the model output is consistent with the graph constraints, preventing local determination results from directly destroying the global semantic structure.

[0053] In step S5, for the candidate object pairs that need to be split and reconstructed, the upstream processing chain is traced along the data lineage graph to extract the minimum conflict evidence set and locate the process bifurcation point. Based on the classification result, the minimum conflict evidence set and the process bifurcation point, the reconstruction write-back is performed to generate the reconstructed object data, object mapping relationship and version relationship.

[0054] Please see Figure 5 , Figure 5 A schematic diagram of the refactoring and write-back process provided in an embodiment of this disclosure is shown. For example... Figure 5 As shown, in step S501, for the candidate object pairs that need to be split and reconstructed, the upstream processing chain is traced along the data lineage graph to extract the minimum conflict evidence set and locate the process bifurcation point.

[0055] For object pairs requiring splitting and reconstruction, the executing entity traces two processing chains upstream along the data lineage graph. The tracing starts at the two objects to be processed, and the tracing direction unfolds in reverse along the input and inheritance relationships until the source object node is reached or the tracing boundary set by the task is reached. After the system forms two upstream processing chains, it first compares the step types, step order, and key parameter summaries of the two processing chains to find the common prefix step sequence. The common prefix step sequence refers to a continuous segment of steps that remains consistent from the source end in terms of step type and key parameter summary. The first differing step after the end of this sequence is recorded as the candidate process bifurcation position.

[0056] After determining the bifurcation points of candidate processes, the system sequentially compares differences in steps, parameter snapshots, baselines, and manual revisions. If a difference in a step is sufficient to support the conclusion that processes cannot be merged (e.g., one processing chain undergoes manual layer shifting while another does not), the system directly adds that step difference to the minimum conflict evidence set. If the step types are the same but the parameter snapshots differ substantially, the parameter difference is added to the minimum conflict evidence set. If the first two types of differences are insufficient to distinguish them, the system continues to compare depth baselines, coordinate baselines, and manual revision records. The minimum conflict evidence set refers to the evidence set containing the fewest number of differences that can support the conclusion that processes cannot be merged. Through this process, the system compresses the conflict explanation to the minimum necessary evidence, providing a concise basis for subsequent write-backs and manual review.

[0057] In step S502, the executing entity determines the subsequent reconfiguration actions based on the classification results, the minimum conflict evidence set, and the process bifurcation point.

[0058] If a candidate object is determined to be mergeable, the merging process begins; if it is determined to require splitting and reconstruction, the splitting process begins; if it is determined to preserve the evolutionary relationship, the evolutionary relationship write-back process begins. For objects requiring splitting and reconstruction, the process fork point serves two purposes: first, it identifies the boundary between the common semantic basis and the source of differences; second, it provides a demarcation position for attaching the new object version to the subsequent processing chain.

[0059] In step S503, subsequent reconstruction actions are determined based on the classification results; for candidate object pairs that need to be split and reconstructed, the split write-back content is determined by combining the minimum conflict evidence set and the process bifurcation point.

[0060] After entering the merging process, the executing entity first determines the primary object, which is determined based on a combination of the source system level, generation time, and number of downstream references. For example, objects with higher source system levels are preferred; if the source system levels are the same, objects with later generation times are preferred; if the first two are the same, objects with more downstream references are preferred. Here, the source system level is given by the source system list in the task context; the generation time is directly derived from the object record; and the number of downstream references is obtained by counting the number of relationship edges originating from that object in the knowledge graph.

[0061] After identifying the master object, the system registers the original business identifier, original name, and version identifier of the objects to be merged in the alias table and source table of the master object. During attribute merging, the master object retains core fields such as standard name, unified coordinates, unified depth range, and current status flag; for non-conflicting extended attributes, the system writes them to the extended attribute area; for differing extended attributes, the system registers the source of the conflict while retaining the field values ​​of the master object. Duplicate relationship edges in the graph database are merged according to relationship type and target node, while all source chains in the data lineage graph are retained and converged to the master object. In this way, the merged object maintains a unique current representation while also retaining multiple source chains.

[0062] After entering the splitting process, the executing entity first extracts the shared semantic part based on the common prefix step sequence and generates multiple new object skeletons accordingly. The shared semantic part includes the object type, unified name, hash symbol, and consistent attributes corresponding to the common prefix. Starting from the process fork point, the system attaches the step nodes, parameter snapshots, and subsequent results of the two processing chains after the fork point to different new object skeletons, forming multiple new object versions. If the original object is already referenced by other objects, the system reassigns downstream references to the corresponding new object version based on the reference occurrence time, dependency relationship, and object type.

[0063] After the split, the original objects are marked as historical summary objects and no longer participate in subsequent queries as currently valid objects. Some objects retain their names, but their generation process and semantic boundaries have changed. If a single object continues to represent all sources, it will lead to confusion in downstream references. After splitting by process fork point, subsequent results from different source chains can be assigned to the new version objects respectively. For object pairs that retain evolutionary relationships, evolutionary or replacement relationships are established in the knowledge graph, without performing object overwriting or semantic splitting.

[0064] If the processing chain of a subsequent object contains the processing chain of a preceding object, and the subsequent object was generated later than the preceding object, then an evolutionary relationship is established. If the subsequent object replaces the preceding object as the current object in a specific task time, then a substitution relationship is established. The substitution relationship is one of the specific relationship types of evolutionary relationships. In addition to the relationship type, the relationship edge also includes the effective time period, the basis for its establishment, and a confidence value. The confidence value can be obtained by combining the classification probability and the lineage compatibility score. in, A confidence value representing an evolutionary relationship; This represents the probability of the corresponding category in the classification output; Indicates bloodline compatibility score; and These are weighting coefficients, ranging from 0 to 1, and their sum is 1. If the task configuration is primarily based on the model output, then... The value should be relatively high; if the task configuration emphasizes source chain consistency, then... The value is relatively high. This confidence value is mainly written to the relation record for sorting and verification purposes, and does not participate in the re-determination of the current object category.

[0065] In one embodiment, after the reconstruction and write-back are completed, the executing entity also performs a consistency check, which includes at least the following three categories: Uniqueness check of currently valid objects (i.e., only one currently valid object is allowed under the same standard name, the same well number, and the same valid temporal state); Uniqueness check of layer affiliation (i.e., the same well segment is not allowed to be simultaneously assigned to two mutually exclusive layers under the same temporal state); and Lineage traceability check (i.e., any currently valid object must be traced back to at least one source object node along the data lineage graph). If an object fails the consistency check, the system sends the object back to the minimum conflict evidence set extraction stage, re-executing evidence extraction and write-back only for the object and its related local structures, without reprocessing the entire batch of objects, thus maintaining the stability of the processing scope.

[0066] In some embodiments, the executing entity writes the final result to two storage layers. The graph database stores knowledge graph nodes, semantic relationship edges, processing step nodes, and lineage relationship edges for subsequent retrieval and visualization analysis. The relational database stores an object master table, an object alias table, a version relationship table, a conflict evidence table, and a task execution log. The object master table records the main object number, unified name, unified coordinates, unified depth range, current valid status, and source summary; the object alias table records the correspondence between the main object and the original business identifier and original name; the version relationship table records the evolutionary and substitution relationships between objects; the conflict evidence table records the components of the minimum conflict evidence set, the evidence source, and the establishment time; and the task execution log records the model version, threshold configuration, and write-back result for this task. Thus, the subsequent system can access the reconstruction result from three perspectives: semantic relationship, source chain, and historical version.

[0067] As a concrete example, if a well and a certain layer have interpretation results with the same name in two interpretation batches, after system standardization, the two results will have the same standard name, the same well number, and similar depth ranges, and will therefore be generated into the candidate object pair set. During lineage compatibility scoring, if one object undergoes manual translation revision after environmental correction, while the other object only goes through the automatic interpretation process, the consistency of manual revision will decrease, and the overall score will drop accordingly. If the score is still higher than the compatibility threshold, both objects will continue to enter the semantic judgment model; the revision-to-relationship, generation-to-relationship, and downstream reference relationships in the local subgraph will further reflect the differences between the two. If the classification result indicates that splitting and reconstruction are required, the system, after tracing along two processing chains, can identify the manual translation revision record as a component of the minimum conflict evidence set, and generate two version objects accordingly, while attaching their respective subsequent results to the corresponding version objects. Thus, objects with the same name but different source chains will not be directly merged.

[0068] In summary, this invention utilizes both object source chains and graph structure information during object reconstruction to distinguish between objects with similar names but different source chains, and objects with different names but continuous source chains. Simultaneously, the system solidifies the minimum necessary differences as conflict evidence and writes the merging, splitting, and evolutionary relationships back to the storage layer, thereby maintaining consistency between the current object representation, historical source records, and version relationship records.

[0069] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a hydrocarbon reservoir characterization data reconstruction system that integrates data lineage and knowledge graph, as provided in an embodiment of this application. Figure 6As shown, the system includes: a data acquisition and standardization module 601, configured to acquire a set of object data to be reconstructed, and to standardize the names, units, depth benchmarks, and coordinate benchmarks of the object records in the set of object data to be reconstructed, thereby obtaining a standardized object set; a graph construction module 602, configured to construct a knowledge graph containing object instance nodes and semantic relationship edges based on the standardized object set, and to construct a data lineage graph based on the processing step records, parameter snapshots, and generation times corresponding to each object record; a candidate generation and filtering module 603, configured to generate candidate object pairs according to object type, spatial location, depth range, and standard name, calculate the lineage compatibility score of each candidate object pair based on the data lineage graph, and filter to obtain a lineage-compatible candidate set; and a semantic determination module 604, configured to determine the semantic relationship of each candidate object pair in the lineage-compatible candidate set based on the knowledge graph. The system performs semantic judgment on the local subgraph structure and object pair features of the knowledge graph to obtain classification results. The classification results include mergeable, split-and-reconstructable, or evolutionary relationships that need to be retained. The retained evolutionary relationships include evolutionary relationships and substitution relationships. The semantic judgment module 604 is configured to perform semantic judgment on each candidate object pair in the lineage compatible candidate set based on the local subgraph structure and object pair features of the knowledge graph to obtain classification results. The classification results include mergeable, split-and-reconstructable, or evolutionary relationships that need to be retained. The retained evolutionary relationships include evolutionary relationships and substitution relationships. The reconstruction and write-back module 605 is configured to trace the upstream processing chain along the data lineage graph for candidate object pairs that need to be split and reconstructed, extract the minimum conflict evidence set and locate the process bifurcation point, and perform reconstruction and write-back based on the classification results, the minimum conflict evidence set and the process bifurcation point to generate reconstructed object data, object mapping relationships and version relationships.

[0070] Each processing unit and / or module in the embodiments of this application can be implemented by an analog circuit that implements the functions described in the embodiments of this application, or by software that executes the functions described in the embodiments of this application.

[0071] Based on the same inventive concept, this application also provides an electronic device, the method corresponding to which can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. For example... Figure 7 As shown, Figure 7 This is a schematic diagram of an electronic device structure provided in an embodiment of the present disclosure. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the methods and / or technical solutions of the foregoing embodiments of the present application.

[0072] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by a processor, it performs the functions defined in the methods of this application.

[0073] Another embodiment of this application provides a storage medium storing computer program instructions thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application.

[0074] In the above embodiments, the descriptions of each embodiment have different focuses. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The above descriptions are merely preferred embodiments of this application and explanations of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to the technical solutions formed by specific combinations of the above technical features, but should also cover other technical solutions formed by arbitrary combinations of the above technical features or their equivalent features without departing from the inventive concept.

Claims

1. A method for reconstructing hydrocarbon reservoir characterization data by integrating data lineage and knowledge graphs, characterized in that, include: A set of object data to be reconstructed is obtained. The object records in this set are standardized in name, unit, depth, and coordinate references to obtain a standardized object set. A knowledge graph containing object instance nodes and semantic relationship edges is constructed based on this standardized object set. A data lineage graph is also constructed based on the processing step records, parameter snapshots, and generation times corresponding to each object record. Candidate object pairs are generated according to object type, spatial location, depth range, and standard name. Lineage compatibility scores for each candidate object pair are calculated based on the data lineage graph, and a lineage-compatible candidate set is obtained. The lineage compatibility score is calculated based on a weighted average of source domain consistency, reference consistency, process continuity, temporal validity, and manual revision consistency. Source domain consistency reflects whether two objects come from the same data domain or whether a pre-defined legal mapping relationship exists. If both objects come from the well logging interpretation domain, the source domain consistency is relatively high. If the two objects come from the well logging interpretation domain and the seismic inversion domain respectively, and the task configuration does not allow direct comparison, the source domain consistency is relatively low. The reference consistency is based on a unified depth field pair. The corresponding depth benchmark type and the coordinate benchmark type corresponding to the unified coordinate field are evaluated; the process continuity is obtained by comparing the step sequence and key parameter summary in the lineage signature of two objects. If one step chain is a prefix extension of another step chain, or if there is a clear inheritance relationship between the two, the process continuity takes the relatively high value; the temporal validity is determined based on the similarity of the generation time, effective time and the batch to which they belong; the consistency of manual revision is determined by comparing the revision type, revision batch, reviser and revision description summary in the manual revision record; for each candidate object pair in the lineage compatible candidate set, semantic judgment is performed based on the local subgraph structure and object pair features in the knowledge graph to obtain the classification result. The classification result includes mergeable, split and reconstructed, or evolutionary relationship retained. The evolutionary relationship retained includes evolutionary relationship and substitution relationship; the reconstruction write-back is performed based on the classification result; wherein, for the candidate object pair that needs to be split and reconstructed, the upstream processing chain is traced along the data lineage graph, the minimum conflict evidence set is extracted and the process bifurcation point is located; after the reconstruction write-back is performed, the reconstructed object data, object mapping relationship and version relationship are generated.

2. The method according to claim 1, characterized in that, The object record includes at least the object number, object type, original name, source system identifier, spatial coordinates, depth start point, depth end point, version identifier, generation time, and original record pointer; the name standardization includes well number standardization, layer name mapping, and curve name normalization; after the depth benchmark and coordinate benchmark are unified, the original fields and unified fields are retained.

3. The method according to claim 1, characterized in that, The data lineage graph uses object instances and processing step instances as nodes, and input relationships, output relationships, parameterization relationships, and inheritance relationships as edges. Each processing step instance records at least the step type, step order, parameter snapshot, execution time, and executor identifier. Furthermore, a lineage signature consisting of a source domain identifier, step sequence, key parameter summary, baseline type, and time identifier is generated for each object.

4. The method according to claim 1, characterized in that, The step of generating candidate object pairs based on object type, spatial location, depth range, and standard name includes: generating a candidate set of the same type or a preset candidate set of different types according to object type, and generating candidate object pairs using the same hash symbol, similar spatial location, intersecting depth range, or matching standard name as retrieval conditions.

5. The method according to claim 1, characterized in that, The bloodline compatibility score is compared with the compatibility threshold, and candidate pairs with scores not lower than the compatibility threshold are retained as the bloodline compatibility candidate set.

6. The method according to claim 1, characterized in that, The object pair features include standard name similarity features, spatial proximity features, depth interval overlap features, attribute difference features, version time difference features, and lineage compatibility score. The local subgraph structure consists of the central node corresponding to the candidate object pair and its first-order and second-order neighbors.

7. The method according to claim 1, characterized in that, The semantic determination adopts a relation-aware graph convolutional network model, which includes: a subgraph construction module, a node attribute encoding module, a relation-aware graph convolutional module, a pairwise feature fusion module, and a classification output module. The relation-aware graph convolutional module aggregates neighbor node information according to different semantic relation edges, and the classification output module outputs the classification results of mergeable, split-and-reconstruct, and evolutionary relation-preserving nodes.

8. The method according to claim 1, characterized in that, The minimum conflict evidence set is obtained by comparing the two upstream processing chains corresponding to the candidate objects that need to be split and reconstructed. Specifically, it includes: determining the common prefix step sequence of the two upstream processing chains, determining the first difference step after the end of the common prefix step sequence as the candidate process bifurcation position, and extracting the minimum difference items that support the decision that cannot be merged in the order of step difference, parameter snapshot difference, benchmark difference and manual revision difference, as the minimum conflict evidence set.

9. The method according to claim 1, characterized in that, The reconstructing and writing back based on the classification results includes: for candidate object pairs that can be merged, determining the main object and registering the original business identifier and original name of the merged object; for candidate object pairs that need to be split and reconstructed, generating multiple new object versions based on the minimum conflict evidence set and process bifurcation point and attaching them to the corresponding subsequent processing chains; and for candidate object pairs that retain evolutionary relationships, establishing evolutionary relationships or substitution relationships in the knowledge graph.

10. A system for reconstructing hydrocarbon reservoir characterization data by integrating data lineage and knowledge graphs, characterized in that, include: The data acquisition and standardization module is configured to acquire a set of object data to be reconstructed, and to standardize the names, units, depth benchmarks, and coordinate benchmarks of the object records in the set of object data to be reconstructed, thereby obtaining a standardized object set. The graph construction module is configured to construct a knowledge graph containing object instance nodes and semantic relationship edges based on the standardized object set, and to construct a data lineage graph based on the processing step records, parameter snapshots, and generation times corresponding to each object record. The candidate generation and filtering module is configured to generate candidate object pairs based on object type, spatial location, depth range, and standard name, and based on the... The data lineage map is used to calculate the lineage compatibility score of each candidate object pair, and a lineage compatible candidate set is obtained by filtering. The lineage compatibility score is calculated based on a weighted average of source domain consistency, baseline consistency, process continuity, temporal validity, and manual revision consistency. The source domain consistency reflects whether two objects come from the same data domain or whether a pre-defined legal mapping relationship exists. If both objects come from the well logging interpretation domain, the source domain consistency is set to a relatively high value; if the two objects come from the well logging interpretation domain and the seismic inversion domain respectively, and the task configuration does not allow direct comparison, the source domain consistency is set to a relatively low value. The baseline consistency... The evaluation is based on the depth reference type corresponding to the unified depth field and the coordinate reference type corresponding to the unified coordinate field; the process continuity is obtained by comparing the step sequence and key parameter summary in the lineage signatures of two objects. If one step chain is a prefix extension of another step chain, or if there is a clear inheritance relationship between the two, the process continuity takes the relatively higher value; the temporal validity is determined based on the similarity of the generation time, effective time, and batch; the consistency of manual revision is determined by comparing the revision type, revision batch, reviser, and revision description summary in the manual revision record; the semantic determination module is configured to evaluate the... For each candidate object pair in the lineage-compatible candidate set, semantic judgment is performed based on the local subgraph structure and object pair features in the knowledge graph to obtain a classification result. The classification result includes mergeable, split-and-reconstruction required, or evolutionary relationship preserved. The preserved evolutionary relationship includes evolutionary relationship and substitution relationship. The reconstruction write-back module is configured to perform reconstruction write-back based on the classification result. Specifically, for candidate object pairs that need to be split and reconstructed, the upstream processing chain is traced along the data lineage graph to extract the minimum conflict evidence set and locate the process bifurcation point. After performing reconstruction write-back, reconstructed object data, object mapping relationship, and version relationship are generated.

Images