A method for managing inventory data based on real estate unit number during decentralized registration period

Abstract

The application discloses a kind of inventory data management methods based on real estate unit number in dispersed registration period, it is related to real estate data processing and data management technical field, the method comprises: obtaining multi-source inventory data;Multi-source inventory data is executed multi-feature fusion matching operation, determines the inventory data set and its real estate unit number of belonging to same real estate unit, and the real estate unit number is associated with corresponding historical archive data, generates standardized initial data set;According to the formation time of each inventory data, determine target check rule library, and execute stratified check to standardized initial data set, generate inventory abnormal data list, and accordingly carry out data correction, obtain compliance standard data set.The application realizes the accurate association and legal code of multi-source inventory data, ensures that historical data is checked in compliance, and realizes the intelligent digestion of abnormal data, effectively solves the inventory data fragmentation and management compliance problem, improves the accuracy and efficiency of data management.

Description

Technical Field

[0001] This application relates to the field of real estate data processing and data management technology, and in particular to a method for managing existing data based on real estate unit numbers during the period of decentralized registration. Background Technology

[0002] Before the full implementation of the unified real estate registration system, the real estate registration field experienced a long period of decentralized registration with separate ownership of land and buildings. During this period, real estate such as houses and land were registered separately by different competent authorities, and historical data lacked a unified legal identity identifier. Current data governance methods mainly focus on incremental data after unified registration, using string matching based on single features (such as ownership certificate number and location address) for data association. This approach cannot accurately anchor the legal identity of data from the decentralized registration period, resulting in a break in the ownership association between land data, house data, historical registration data, and archive data corresponding to the same real estate, and failing to form a complete and compliant real estate ownership view.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method for managing existing real estate data based on real estate unit numbers during the period of decentralized registration. This method aims to solve the technical problem that the existing real estate data management system lacks the legal anchoring capability of real estate unit numbers, which leads to the inability to accurately link multi-source real estate data during the period of decentralized registration.

[0005] To achieve the above objectives, embodiments of this application provide a method for managing existing data based on real estate unit numbers during the decentralized registration period. This method includes: Acquire multi-source stock data, including land registration data, housing registration data, historical archive data, and property rights survey data; Perform multi-feature fusion matching operation on the multi-source stock data to determine the stock data set belonging to the same real estate unit and the real estate unit number corresponding to the real estate unit, and associate each real estate unit number with the corresponding historical archive data to generate a standardized initial dataset; Based on the formation time of each existing data in the standardized initial dataset, the target verification rule base of the corresponding version is determined; Perform hierarchical verification on the standardized initial dataset according to the target verification rule base to generate a list of existing abnormal data; Based on the existing list of abnormal data, a data correction operation is performed on the standardized initial dataset to obtain a compliant standard dataset.

[0006] In one embodiment, the multi-feature fusion matching operation includes exact matching. The step of performing the multi-feature fusion matching operation on the multi-source stock data to determine the set of stock data belonging to the same real estate unit and the real estate unit number corresponding to the real estate unit, and associating each real estate unit number with the corresponding historical archive data to generate a standardized initial dataset includes: Extract the land parcel code, building number, and household number from the multi-source stock data, and concatenate them to generate the first combined feature string; The first combined feature string is precisely matched with the compliant real estate unit coding library. If the match is successful, the original stock data providing the field values ​​in the first combined feature string is collected into the real estate unit corresponding to the matching result. Obtain the real estate unit number of the real estate unit corresponding to the matching result, and associate the real estate unit number with the corresponding historical archive data.

[0007] In one embodiment, the multi-feature fusion matching operation includes fuzzy matching combined with spatial verification. After the steps of obtaining the real estate unit number of the real estate unit corresponding to the matching result and associating the real estate unit number with the corresponding historical archive data, the method for managing existing data based on real estate unit numbers during the decentralized registration period further includes: Historical ownership certificate numbers, rights holder names, and location addresses are extracted from the multi-source stock data that has never been precisely matched, and then concatenated to generate a second combination feature string; The second combination of feature strings is fuzzy matched with the standard parcel spatial database. If the match is successful, the coordinates of the boundary point corresponding to the matched target parcel are obtained. Address parsing is performed on the location address in the second combined feature string to convert it into the corresponding spatial coordinate point. The similarity between the spatial coordinate point and the boundary point coordinates corresponding to the target land parcel is calculated. When the similarity is greater than or equal to the preset similarity threshold, the original stock data providing the field values ​​in the second combined feature string is collected into the real estate unit corresponding to the target land parcel. The real estate unit number corresponding to the target land parcel is generated according to the real estate unit coding rules, and the real estate unit number is associated with the corresponding historical archive data.

[0008] In one embodiment, the multi-feature fusion matching operation includes pure spatial matching. After the steps of generating the real estate unit number of the real estate unit corresponding to the target land parcel according to the real estate unit coding rules and associating the real estate unit number with the corresponding historical archive data, the method for managing existing data based on real estate unit numbers during the decentralized registration period further includes: The boundary point coordinates are extracted from the multi-source stock data that has never been obtained through the fuzzy matching combined with spatial verification, and a spatial vector graphic is generated based on the boundary point coordinates; The spatial vector graphics are spatially overlaid with the standard parcel spatial database to calculate the spatial overlap. When the spatial overlap is greater than or equal to a preset threshold, the original stock data providing the boundary point coordinates will be collected into the real estate unit determined by the spatial overlay analysis. The real estate unit number corresponding to the real estate unit is generated according to the real estate unit coding rules, and the real estate unit number is associated with the corresponding historical archive data.

[0009] In one embodiment, the step of determining the corresponding version of the target validation rule base based on the formation time of each existing data in the standardized initial dataset includes: Based on the correspondence between different historical periods and statutory registration standards, a corresponding verification rule base is constructed for each of the aforementioned historical periods; Based on the target historical period corresponding to the formation time of each piece of existing data, a verification rule base associated with the target historical period is selected as the target verification rule base.

[0010] In one embodiment, the step of performing hierarchical validation on the standardized initial dataset according to the target validation rule base to generate a list of existing abnormal data includes: The standardized initial dataset is subjected to field-level validation, ownership history-level validation, spatial boundary-level validation, and cross-departmental collaboration-level validation in sequence. In any verification level, if there is existing data that fails the verification rules of the corresponding level, the existing data that fails the verification is marked as abnormal data, and the abnormality type and the verification level to which the existing data that fails the verification belongs are recorded. All existing data marked as abnormal data are aggregated to generate the existing abnormal data list. The existing abnormal data list includes abnormal data identifier, original data content, abnormal type, abnormal location, violation rule number, legal basis for the corresponding historical period, and verification level information.

[0011] In one embodiment, the step of performing data correction operations on the standardized initial dataset based on the existing abnormal data list to obtain a compliant standard dataset includes: Based on the formation time corresponding to each abnormal data in the existing abnormal data list, determine the historical period to which the abnormal data belongs; Obtain a real estate ownership knowledge graph corresponding to the historical period. The real estate ownership knowledge graph includes core ontology and core relationships, as well as ontology reasoning rules configured based on the statutory registration norms of the corresponding historical period. Based on the real estate ownership knowledge graph, the preset weights of the relationships involved in the abnormal data are obtained, and the confidence level for automatically resolving the abnormal data is calculated according to the preset weights. When the confidence level is greater than or equal to the preset confidence threshold, the abnormal data is automatically resolved according to the ontology reasoning rules to generate corrected data records. The standardized initial dataset is updated based on the corrected data records to obtain the compliance standard dataset.

[0012] In one embodiment, after the steps of obtaining preset weights of the relationships involved in the abnormal data based on the real estate ownership knowledge graph, and calculating the confidence level for automatically resolving the abnormal data according to the preset weights, the method for managing existing data based on real estate unit numbers during the decentralized registration period further includes: When the confidence level is less than the preset confidence threshold, the abnormal data is pushed to the manual processing terminal, and the legal basis and similar case reference information of the corresponding historical period of the abnormal data are associated with it. The system receives corrected data returned by the manual processing terminal, updates the standardized initial dataset based on the corrected data, and obtains the compliance standard dataset.

[0013] In one embodiment, the step of updating the standardized initial dataset based on the corrected data records to obtain the compliance standard dataset includes: Based on the real estate unit number confirmation process record set, the existing compliance data list, the full verification process log, the repaired compliance dataset, and the anomaly handling process record set corresponding to each real estate unit, the full governance data corresponding to each real estate unit is determined. A hash algorithm is used to generate corresponding evidence hashes for the full governance data corresponding to each of the aforementioned real estate units; The evidence storage hash is bound to the real estate unit number of the corresponding real estate unit, and combined with the corresponding full governance data to form a standard data entry of the real estate unit carrying the evidence storage hash. All the standard data entries are summarized to form the compliance standard dataset. Extract key operational data from the compliance standard dataset and encapsulate the key operational data into on-chain transaction data. Perform on-chain evidence storage operation on the on-chain transaction data and upload it to the real estate consortium chain. The key operational data includes code matching results, code generation basis, verification rule base version number, anomaly resolution operation content and legal basis, and manual handling results. Receive a traceability query request initiated by the real estate unit number, obtain and return the corresponding evidence storage hash and on-chain evidence storage data based on the real estate unit number.

[0014] In one embodiment, after the steps of binding the evidence hash with the corresponding real estate unit number, combining it with the corresponding full governance data to form a standard data entry for the real estate unit carrying the evidence hash, and summarizing all the standard data entries to form the compliance standard dataset, the method for managing existing data based on real estate unit numbers during the decentralized registration period further includes: The compliance standard dataset is synchronized to the real estate registration business database, and a full back-check is performed on the compliance standard dataset within a first preset time after the compliance standard dataset is entered into the database to determine the residual anomalies detected during the verification. The step of performing data correction on the standardized initial dataset is re-executed for the residual anomalies until the residual anomaly rate is lower than the preset qualified threshold. The residual anomaly rate is the proportion of the number of residual anomalies detected by the full back-check to the total amount of stored data being checked. After the full back-check passes, incremental verification is performed on the business-related data newly added in the previous period according to a preset cycle, and the ownership status of the corresponding existing data is updated according to the verification results.

[0015] This application embodiment also provides a data management device for existing data based on real estate unit number during the decentralized registration period. The data management device for existing data based on real estate unit number during the decentralized registration period includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the data management method for existing data based on real estate unit number during the decentralized registration period as described above.

[0016] This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program on the storage medium. When the computer program is executed by a processor, it implements the steps of the stock data management method based on real estate unit number during the decentralized registration period as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application addresses the problem of insufficient association of ownership information in existing data by acquiring multi-source existing data and performing multi-feature fusion matching operations. It links land, housing, archives, and spatial data lacking unified identification during the period of decentralized registration to the same real estate unit and assigns them a legal real estate unit number. Furthermore, by determining the target verification rule base for the corresponding version based on the formation time of each piece of existing data, the verification operation applies to data that conforms to the legally valid registration standards at the time of registration, avoiding the problem of misjudging historical data using current rules. Finally, by performing hierarchical verification to generate an abnormal data list and performing data correction operations based on this list, a compliance standard dataset is obtained. This achieves accurate location and compliance correction of abnormal data, thereby improving the accuracy and standardization of real estate existing data governance during the period of decentralized registration. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an embodiment of the method for managing existing data based on real estate unit numbers during the decentralized registration period of this application. Figure 2 This is a schematic diagram of the three-level priority multi-feature fusion matching operation process provided in Implementation Example 1 of the method for managing existing data based on real estate unit number during the decentralized registration period of this application. Figure 3 This is a schematic diagram of the hierarchical verification process of the existing data governance method provided in Implementation Example 1 of the method for governing existing data based on real estate unit number during the decentralized registration period of this application. Figure 4 This is a schematic diagram of the intelligent resolution process for abnormal data provided in Implementation Example 1 of the method for managing existing data based on real estate unit numbers during the decentralized registration period of this application. Figure 5 This is a flowchart illustrating the second embodiment of the method for managing existing data based on real estate unit numbers during the decentralized registration period of this application. Figure 6 This is a schematic diagram of the full-link legal evidence preservation and traceability process provided in Implementation Example 2 of the method for managing existing data based on real estate unit numbers during the decentralized registration period of this application; Figure 7 This is a flowchart illustrating the third embodiment of the method for managing existing data based on real estate unit numbers during the decentralized registration period of this application. Figure 8 This is a schematic diagram of the closed-loop back-checking and model iteration optimization process provided in Implementation Example 3 of the method for managing existing data based on real estate unit numbers during the decentralized registration period of this application; Figure 9 This is a simplified flowchart illustrating the third embodiment of the method for managing existing data based on real estate unit numbers during the decentralized registration period of this application. Figure 10This is a schematic diagram of the hardware operating environment of the data governance device for the data governance method based on real estate unit number during the decentralized registration period, as described in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] Before the full implementation of the unified real estate registration system, the real estate registration field experienced a long period of decentralized registration with separate ownership of land and buildings. During this period, real estate such as houses and land were registered separately by different competent authorities, and historical data lacked a unified legal identity identifier. Current data governance methods mainly focus on incremental data after unified registration, using string matching based on single features (such as ownership certificate number and location address) for data association. This approach cannot accurately anchor the legal identity of data from the decentralized registration period, resulting in a break in the ownership association between land data, house data, historical registration data, and archive data corresponding to the same real estate, and failing to form a complete and compliant real estate ownership view.

[0023] In view of the above problems, this application proposes a method for managing existing data based on real estate unit numbers during the decentralized registration period. This method involves acquiring multi-source existing data, including land registration data, housing registration data, historical archive data, and cadastral survey data; performing multi-feature fusion matching on the multi-source existing data to determine the set of existing data belonging to the same real estate unit and the corresponding real estate unit number; associating each real estate unit number with the corresponding historical archive data to generate a standardized initial dataset; determining a target verification rule base for the corresponding version based on the formation time of each piece of existing data in the standardized initial dataset; performing hierarchical verification on the standardized initial dataset according to the target verification rule base to generate a list of abnormal existing data; and performing data correction operations on the standardized initial dataset based on the list of abnormal existing data to obtain a compliant standard dataset.

[0024] This application provides a solution that, by acquiring multi-source existing data and performing multi-feature fusion matching operations, associates land, housing, archives, and spatial data lacking unified identification during the period of decentralized registration to the same real estate unit and assigns them a legal real estate unit number, thus solving the problem of the lack of effective association of ownership information in existing data. By determining the target verification rule base corresponding to the formation time of each piece of existing data, the verification operation applies to the legally valid registration standards at the time of formation, avoiding the problem of misjudging historical data with current rules. By performing hierarchical verification to generate an abnormal data list, and performing data correction operations based on the abnormal data list, a compliance standard dataset is obtained, realizing the accurate location and compliance correction of abnormal data, thereby improving the accuracy and standardization of real estate existing data governance during the period of decentralized registration.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a computer, server, or cloud computing platform, or an electronic device, distributed computing system, or existing data governance system or device based on real estate unit number during the decentralized registration period capable of realizing the above functions. The following description uses an existing data governance system based on real estate unit number during the decentralized registration period as an example to illustrate this embodiment and the subsequent embodiments.

[0026] The first embodiment of this application proposes a method for managing existing data based on real estate unit numbers during the decentralized registration period. Please refer to [link / reference]. Figure 1 The method includes steps S10 to S50: Step S10: Obtain multi-source stock data, which includes land registration data, housing registration data, historical archive data, and property rights survey data.

[0027] In this embodiment, multi-source existing data refers to a collection of historical registration data generated by different competent authorities and stored in multiple independent business systems during the period of decentralized registration. Multi-source existing data includes land registration data, housing registration data, historical archive data, land ownership survey data, housing and construction transaction filing data, tax payment data, and court judicial investigation and control data. During the period of decentralized registration, these multi-source existing data belonged to different registration management systems, each following independent coding rules and data standards, lacking a unified association identifier. This resulted in the fragmented storage of ownership information for the same real estate, leading to a fragmented data state.

[0028] Under the premise of compliance and obtaining relevant data source authorization, when acquiring multi-source existing data, a standardized data exchange interface is first built based on the GB / T39477-2020 standard, using JSON as the data exchange format and employing the SM2 asymmetric encryption algorithm to encrypt and protect the transmitted data. Then, based on this data exchange interface, data is collected from the data sources of the multi-source existing data.

[0029] After completing the integration with the aforementioned data sources, subsequent data synchronization can employ a strategy combining daily off-peak incremental synchronization with monthly full synchronization. For example, incremental synchronization can be performed in the early morning of each day to obtain information on any additions or changes to the previous day's real estate inventory data; full synchronization can be performed at the beginning of each month to ensure the integrity and consistency of the real estate inventory data.

[0030] During data synchronization, a breakpoint resume mechanism can be enabled. When data transmission is unexpectedly interrupted due to network fluctuations or other reasons, the system can automatically resume transmission from the breakpoint without retransmitting the completed portion, thereby effectively improving the reliability and efficiency of large-scale data transmission.

[0031] After data collection is completed, the acquired multi-source existing data undergoes further standardization preprocessing. This preprocessing aims to unify the format and encoding of heterogeneous data from different systems. Specifically, this may include unifying the date representation format, the spatial reference system, and the special character encoding method, thereby ensuring that the existing data from different sources have structural semantic consistency in subsequent governance stages and avoiding matching failures, verification misjudgments, or broken associations due to format differences.

[0032] As an example, for date fields, different systems may use various formats, such as year-month-day, year / month / day, or year-month-day in Chinese. Converting these to a standardized date format provides accurate time information for subsequent rule version matching based on the creation time. For spatial coordinate information, data from different surveying periods or sources may use different coordinate reference systems, such as CGCS2000 or local independent coordinate systems. A coordinate transformation model can be used to uniformly convert these to the legal spatial reference system, ensuring accurate overlay and comparison of the spatial locations of land parcels and buildings. For text encoding, different systems may use different character encoding methods, leading to garbled characters or display anomalies in some key fields. A unified encoding conversion ensures accurate identification and matching of key text information such as the rights holder's name and address.

[0033] Step S20: Perform multi-feature fusion matching operation on the multi-source stock data to determine the stock data set belonging to the same real estate unit and the real estate unit number corresponding to the real estate unit, and associate each real estate unit number with the corresponding historical archive data to generate a standardized initial dataset.

[0034] In this embodiment, the multi-feature fusion matching operation refers to the operation of comprehensively utilizing the feature information of different types of fields in multi-source existing data, and gradually realizing the accurate association between existing data and real estate units through a multi-level matching strategy. The core of this operation is that it does not pre-distinguish data types, but extracts matching feature information from existing data from different sources, combines the matching feature information from at least two different sources into a feature tuple, and uses this feature tuple to match with an existing real estate unit coding library or standard parcel spatial database. If the match is successful, it can be determined that the original existing data corresponding to the values ​​of each field involved in the combination belong to the same real estate unit.

[0035] The multi-feature fusion matching operation includes three levels of priority matching: precise matching, fuzzy matching combined with spatial verification, and pure spatial matching are performed on multi-source existing data in descending order of priority. Each level of matching processes data that failed to match in the previous level. Higher priority matching has higher accuracy, while lower priority matching has wider coverage. Through the progressive three-level matching, the matching coverage can be maximized while ensuring matching accuracy, allowing as much existing data as possible to be aggregated to the corresponding real estate units.

[0036] In this embodiment, the standardized initial dataset refers to a dataset where, after multi-feature fusion and matching, each piece of existing data has been assigned to a specific real estate unit, and a corresponding real estate unit number has been obtained or generated. Furthermore, it has been associated with the corresponding historical archive data. This standardized initial dataset provides a unified data foundation for subsequent data governance processes.

[0037] However, the massive historical data accumulated during the period of decentralized registration lacks a unified real estate unit number as a linking identifier. Different periods and different competent authorities adopted independent coding systems, resulting in land registration information, housing registration information, historical archives, and spatial information corresponding to the same real estate unit being stored fragmented in different business systems, lacking effective links between them. This data fragmentation and broken ownership links directly affect the integrity and accuracy of real estate registration information, the compliance of data submission, and the traceability of registration information in subsequent business applications. Therefore, assigning a unified real estate unit number to the historical data accumulated during the decentralized registration period and establishing links between data from different sources is a crucial prerequisite for achieving compliant governance of existing data.

[0038] Specifically, step S20 includes steps S211 to S213: Step S211: Extract the land parcel code, building number and household number from the multi-source stock data, and concatenate them to generate the first combination feature string.

[0039] Step S212: The first combined feature string is precisely matched with the compliant real estate unit coding library. If the match is successful, the original stock data providing the field values ​​of the first combined feature string is collected into the real estate unit corresponding to the matching result.

[0040] Step S213: Obtain the real estate unit number of the real estate unit corresponding to the matching result, and associate the real estate unit number with the corresponding historical archive data.

[0041] In this embodiment, a first-level precise matching is performed. This precise matching operation extracts field values ​​such as land parcel code, building number, and household number from multi-source existing data, and concatenates these field values ​​to generate a first combined feature string. Since the land parcel code, building number, and household number used in precise matching have unique pointers in their encoding rules, the first combined feature string can be precisely compared with records in the existing compliant real estate unit coding library.

[0042] If the first set of feature strings is completely identical to the coding information of a record in the compliant real estate unit coding database, then the match is successful. Upon successful matching, it can be determined that the original stock data providing the field values ​​in the first set of feature strings all belong to the real estate unit corresponding to the matching result, thus aggregating these stock data, originally scattered across different business systems, under the same real estate unit. After aggregation, the real estate unit number corresponding to this real estate unit is obtained, and this real estate unit number is associated with the corresponding historical archive data, completing the real estate unit number anchoring and archive association operation for this part of the stock data.

[0043] After determining the real estate unit to which a piece of existing data belongs, the corresponding historical archive data can be located through the archive number carried by the existing data itself. By establishing a correspondence between this archive number and the real estate unit number of the real estate unit to which the existing data belongs, the association between the real estate unit number and the historical archive data can be realized. Through the above operations, this part of the existing data has completed the assignment of legal codes and the linking of original evidence materials at the identification level, providing a complete association basis for subsequent tracing of ownership evolution and anomaly verification.

[0044] Furthermore, step S213 is followed by steps S221 to S224: Step S221: Extract the historical ownership certificate number, right holder's name, and location address from the multi-source stock data that has never passed the precise matching, and concatenate them to generate a second combination feature string.

[0045] Step S222: Perform fuzzy matching between the second combined feature string and the standard parcel spatial database. If the match is successful, obtain the coordinates of the boundary point corresponding to the matched target parcel.

[0046] Step S223: Perform address parsing on the location address in the second combined feature string, convert it into the corresponding spatial coordinate point, and calculate the similarity between the spatial coordinate point and the boundary point coordinates corresponding to the target land parcel. When the similarity is greater than or equal to a preset similarity threshold, collect the original stock data that provides the field values ​​in the second combined feature string into the real estate unit corresponding to the target land parcel.

[0047] Step S224: Generate the real estate unit number of the real estate unit corresponding to the target land parcel according to the real estate unit coding rules, and associate the real estate unit number with the corresponding historical archive data.

[0048] In this embodiment, for multi-source existing data that failed the first-level precise matching operation, a second-level fuzzy matching combined with spatial verification is further performed. This fuzzy matching combined with spatial verification operation extracts field values ​​such as historical ownership certificate number, right holder name, and address from the existing data that failed precise matching, and concatenates these field values ​​to generate a second combined feature string. Since the reason for the failure of precise matching is that precise identifier fields such as land parcel code, building number, and household number are missing, non-standard, or cannot be precisely matched with the compliant real estate unit coding library, the second-level matching adopts a fuzzy string matching method, using text information such as historical ownership certificate number, right holder name, and address as the matching basis to expand the matching coverage.

[0049] The second set of feature strings is fuzzily matched against the standard land parcel spatial database. If a match is successful, the coordinates of the boundary point corresponding to the matched target land parcel are obtained. After obtaining the boundary point coordinates of the target land parcel, address parsing is performed on the location address in the second set of feature strings to convert it into corresponding spatial coordinates. Then, similarity calculation or distance deviation verification is performed between the spatial coordinates and the boundary point coordinates. The accuracy of the text matching result is verified through spatial dimension verification. When the similarity between the location address and the boundary point coordinates is greater than or equal to a preset similarity threshold, the text matching result can be confirmed as reasonable and reliable at the spatial level. At this time, the original stock data providing the values ​​of each field in the second set of feature strings is collected into the real estate unit corresponding to the target land parcel.

[0050] It should be noted that fuzzy matching matches the parcel level rather than the complete real estate unit. This is because during the period of decentralized registration, although some existing data can be linked to specific parcels through text information such as ownership certificate number and location address, complete identification information of the fixed parts is lacking, so it is temporarily impossible to directly locate the complete real estate unit.

[0051] After data aggregation is completed, corresponding real estate unit numbers are generated for the real estate units aggregated from the successfully matched second-level data. Since the fuzzy matching stage matches land parcel information, which only corresponds to the land parcel code portion of the real estate unit number and does not yet include the fixture feature code and fixture unit number, it is necessary to supplement the fixture part with a code based on the land parcel code of the target land parcel according to the real estate unit coding rules, thereby generating a complete real estate unit number. After generating the real estate unit number, it is associated with the corresponding historical archive data, thus completing the assignment of real estate unit numbers and the association with archives for the unmatched portion of the first-level data. Through the second-level fuzzy matching combined with spatial verification, even when precise identification fields are missing, more accurate associations between existing data and real estate units can be achieved through dual verification of textual and spatial information.

[0052] Furthermore, step S224 is followed by steps S231 to S234: Step S231: Extract the boundary point coordinates from the multi-source existing data that has not passed the fuzzy matching and spatial verification, and generate a spatial vector graphic based on the boundary point coordinates.

[0053] Step S232: Perform spatial overlay analysis between the spatial vector graphics and the standard parcel spatial database to calculate the spatial overlap.

[0054] Step S233: When the spatial overlap is greater than or equal to a preset threshold, the original stock data providing the boundary point coordinates is collected into the real estate unit determined by the spatial overlay analysis.

[0055] Step S234: Generate the real estate unit number corresponding to the real estate unit according to the real estate unit coding rule, and associate the real estate unit number with the corresponding historical archive data.

[0056] In this embodiment, for multi-source existing data where the first two matching operations have failed, a third-level pure spatial matching is further performed. This level of pure spatial matching is for existing data that cannot be directly matched using precise identifier fields, nor can it be fuzzily matched with the land parcel spatial database using text information and complete spatial verification. It is the matching level with the broadest coverage but relatively low accuracy among the three-level matching strategies.

[0057] For multi-source stock data entering the third-level matching stage, boundary point coordinates are extracted, and spatial vector graphics are generated based on these coordinates. After obtaining the spatial vector graphics, spatial overlay analysis is performed between the vector graphics and the standard parcel spatial database to calculate the spatial overlap between the spatial extent represented by the vector graphics and the spatial extent of each parcel in the standard parcel spatial database. When the spatial overlap is greater than or equal to a preset threshold, it indicates that the spatial location described by the stock data highly matches the spatial extent of a parcel in the database. In this case, the original stock data providing the boundary point coordinates can be aggregated into the real estate unit corresponding to the parcel determined by the spatial overlay analysis.

[0058] It should be noted that although the second-level matching also involves the verification of spatial coordinates, the second level is based on the text fuzzy matching that has already found candidate parcels, and then uses coordinate information to verify the matching result; while the third-level matching does not rely on any text matching results, but directly starts from the boundary point coordinates carried by the existing data itself to generate vector graphics that can participate in spatial analysis and calculation.

[0059] After the data is collected, corresponding real estate unit numbers need to be generated for these existing data. Similar to the second-level matching, the third-level pure spatial matching determines the ownership at the parcel level through spatial overlay analysis, but does not yet involve the coding of the fixtures. Therefore, according to the real estate unit coding rules, it is necessary to supplement the determined parcel codes with fixture feature codes and fixture unit numbers to generate complete real estate unit numbers.

[0060] After generating the property unit number, this property unit number is associated with the corresponding historical archive data, thus completing the assignment of property unit numbers and association with archives for the portion of existing data that failed to match in the first two levels. Through the third level of pure spatial matching, in cases where text information is missing or cannot be effectively matched, the remaining existing data can be aggregated to the corresponding property unit to the greatest extent possible by relying on direct comparison of spatial location relationships, thereby achieving full coverage of the three-level matching strategy.

[0061] In addition, steps S241 to S243 are included after step S234: Step S241: Obtain the uncollected existing data that failed to match in the multi-feature fusion matching operation.

[0062] Step S242: Mark the uncollected stock data as pending manual confirmation of rights and assign a pending confirmation file number to the uncollected stock data.

[0063] Step S243: Generate a list of files to be confirmed based on the file number to be confirmed and the corresponding uncollected inventory data.

[0064] After the three-level matching process described above, some existing data may still fail to be aggregated to any real estate unit. This is because the quality of historical data from the period of decentralized registration varies greatly, with some data having severely missing or incorrect text fields, incomplete or insufficient spatial coordinate information, resulting in failure to meet matching conditions at all three levels: exact matching, fuzzy matching combined with spatial verification, and pure spatial matching. For this portion of existing data that cannot be aggregated through automated matching methods, it needs to be transferred to the manual rights confirmation process, where professionals make the final determination using the original archival materials.

[0065] Specifically, for uncollected existing data that fails to match in all multi-feature fusion matching operations, it is first removed from the matching queue to form an uncollected dataset to be processed. These uncollected existing data are marked as awaiting manual ownership confirmation to distinguish them from successfully collected data in subsequent processing. Simultaneously, the original archive number information from the data record is extracted for each uncollected existing data entry, serving as the archive number to be confirmed. This number is a unique retrieval identifier for the original historical archive corresponding to the existing data in the historical archive OCR digitization system, guiding the ownership confirmation personnel to accurately locate the original registration archive materials related to the existing data within the historical archive OCR digitization system.

[0066] After completing the status marking and file number allocation, a list of files awaiting ownership confirmation is generated based on the file numbers and corresponding uncollected existing data. This list comprehensively lists all existing data requiring manual intervention for ownership confirmation and their corresponding file clues, allowing confirmation personnel to retrieve the original files one by one for ownership verification and confirmation. This supplementary manual confirmation process ensures that every piece of historical existing data from a period of dispersed registration ultimately receives a clear determination of ownership, thereby guaranteeing the integrity and comprehensiveness of the entire existing data governance work.

[0067] For example, to help understand the implementation process of the stock data governance method based on real estate unit number during the decentralized registration period in this embodiment, please refer to... Figure 2 , Figure 2 A schematic diagram of a three-level priority multi-feature fusion and matching operation flow for a stock data governance method based on real estate unit number during the decentralized registration period is provided. Specifically: After completing the cross-departmental standardized data collection, the first level of precise matching is performed. Land parcel codes, building numbers, and household numbers are extracted from multi-source existing data, and concatenated to generate a first combination feature string. This first combination feature string is then precisely matched against the existing real estate unit coding database. If a match is successful, the corresponding real estate unit number is directly obtained from the matching result and associated with the corresponding historical archive data.

[0068] If the first-level exact match fails, a second-level fuzzy match combined with spatial verification is performed. The ownership certificate number, owner's name, and address are extracted from the existing data that failed the exact match. These are then concatenated to generate a second combined feature string, which is then fuzzily matched against the standard land parcel spatial database. If a match is successful, the coordinates of the boundary point corresponding to the target land parcel are obtained. The cosine similarity between the address in the second combined feature string and the boundary point coordinates is calculated. When the cosine similarity is greater than or equal to a preset similarity threshold, the match is confirmed as successful, a corresponding real estate unit number is generated, and it is associated with historical archive data.

[0069] If the second-level fuzzy matching combined with spatial verification still fails, the third-level pure spatial matching is executed. Boundary point coordinates are extracted from the existing data that failed the first two levels of matching, and a spatial vector graphic is generated. This spatial vector graphic is then spatially overlaid with the standard parcel spatial database to calculate the spatial overlap. When the spatial overlap is greater than or equal to a preset threshold, the matching is confirmed as successful, a corresponding real estate unit number is generated, and it is associated with historical archive data.

[0070] If none of the above three-level matching is successful, the existing data is marked as pending manual confirmation, a pending confirmation list is generated, and the final confirmation is conducted manually. Through the above three-level priority multi-feature fusion matching process, the maximum correlation and matching between existing data and real estate units can be achieved under different data quality conditions.

[0071] As a feasible implementation method, after generating the list of properties to be confirmed, full-link metadata tags can be added to the existing data with identified real estate unit numbers and associated historical archive data in each of the above matching stages. This operation aims to add key descriptive information covering the entire process from collection, matching, coding to warehousing to each piece of existing data, in order to support subsequent traceability, auditing, and compliance verification needs.

[0072] Specifically, a multi-dimensional metadata tag is attached to each piece of existing data. The tag content includes: a data source system identifier, used to record which business system the existing data originally came from; a data formation timestamp, used to record the time the existing data was registered or modified in the original business system; a corresponding historical archive number, used to establish an index association between the existing data and the original archive; a data collection timestamp, used to record the time the existing data was collected and entered into the data governance process; a data batch number, used to identify the collection batch to which the existing data belongs, facilitating tracking and backtracking by collection batch; a coding matching and / or reassignment basis, used to record whether the real estate unit number corresponding to the existing data was obtained through matching or regeneration, and the matching or coding rule information used; and a digital signature of the person responsible for the operation, used to identify the responsible entity that performed the final processing operation on the existing data. After attaching, the above multi-dimensional metadata tags are bound to the corresponding existing data and stored uniformly in a standardized initial dataset. By attaching full-link metadata tags, each piece of existing data has a complete traceable record throughout the entire governance process from collection and matching to coding, providing reliable data support for subsequent compliance reviews, issue retrospectives, and information tracing.

[0073] Step S30: Determine the target verification rule base of the corresponding version based on the formation time of each existing data in the standardized initial dataset.

[0074] In this embodiment, the verification rule base refers to the set of verification rules corresponding to the legally valid registration standards within a specific historical period. Since the registration standards implemented during different historical stages of the decentralized registration period differ—for example, from 1995 to 2008, the main standards were the "Land Registration Rules" and the "Urban Housing Ownership Registration Management Measures," while from 2008 to 2016, the main standards were the "Housing Registration Measures" and the "Land Registration Measures"—it is necessary to construct corresponding verification rule bases for different historical periods. The verification rules in each rule base are strictly formulated according to the legally valid registration standards implemented within that historical period.

[0075] Specifically, step S30 includes steps S31 to S32: Step S31: Based on the correspondence between different historical periods and statutory registration standards, construct a corresponding verification rule base for each historical period.

[0076] Step S32: Based on the target historical period corresponding to the formation time of each piece of existing data, select the verification rule base associated with the target historical period as the target verification rule base.

[0077] First, based on the correspondence between multiple historical periods and statutory registration standards, a corresponding verification rule base is pre-built for each historical period. For example, two independent verification rule bases are pre-built for the versions from 1995 to 2008 and the versions from 2008 to 2016.

[0078] Next, the formation time of each piece of existing data in the standardized initial dataset is obtained. Based on the formation time, the historical time period to which the existing data belongs is determined. Then, the version of the verification rule library corresponding to the historical time period is loaded from multiple pre-built verification rule libraries and used as the target verification rule library for the existing data.

[0079] As an example, for existing data generated between 1995 and 2008, a verification rule base constructed based on the "Land Registration Rules" and the "Urban Housing Ownership Registration Management Measures" is loaded; for existing data generated between 2008 and 2016, a verification rule base constructed based on the "Housing Registration Measures" and the "Land Registration Measures" is loaded, thus strictly adhering to the principle of non-retroactivity of laws.

[0080] Step S40: Perform hierarchical verification on the standardized initial dataset according to the target verification rule base to generate a list of existing abnormal data.

[0081] In this embodiment, hierarchical verification refers to the operation of sequentially performing compliance checks on each piece of existing data in the standardized initial dataset according to multiple pre-defined verification levels, from different dimensions and depths. This hierarchical verification includes field-level verification, ownership history-level verification, spatial boundary-level verification, and cross-departmental collaborative-level verification.

[0082] Specifically, step S40 includes steps S41 to S43: Step S41: Perform field-level validation, ownership history-level validation, spatial boundary-level validation, and cross-departmental collaboration-level validation sequentially on the standardized initial dataset.

[0083] Step S42: In any verification level, if there is existing data that fails the verification rules of the corresponding level, the existing data that fails the verification is marked as abnormal data, and the abnormality type and the verification level to which the existing data that fails the verification belongs are recorded.

[0084] Step S43: Summarize all existing data marked as abnormal data and generate the existing abnormal data list. The existing abnormal data list includes abnormal data identifier, original data content, abnormal type, abnormal location, violation rule number, legal basis for the corresponding historical period, and verification level information.

[0085] First, the standardized initial dataset undergoes field-level validation, ownership history-level validation, spatial boundary-level validation, and cross-departmental collaborative validation in sequence. Field-level validation checks the data's integrity, format compliance, and value range validity, including verification of required fields not being empty, historical ownership certificate number format, national standard value range, and real estate unit number coding standard. Ownership history-level validation checks the logical consistency of ownership relationships, the continuity of business timelines, and the legality of ownership sources, including logical verification of land and housing ownership connections during the period of separate land and housing ownership, continuity of the entire historical business timeline, legality of ownership source documents, logical consistency of changes in rights status, and one-to-one correspondence between historical ownership certificates and registration transactions. Spatial boundary-level validation checks the topological correctness, coordinate consistency, and rationality of spatial extent, including verification of the matching degree between land parcel and building spatial extents (allowing for reasonable errors due to historical measurement limitations); it also includes verification of boundary point coordinate closure, verification of non-overlapping spatial extents, and verification of consistency between historical cadastral data and current spatial data. Cross-departmental collaborative verification is used to check the consistency between registration data and cross-departmental data, including the consistency verification between transfer registration and the housing and construction transaction filing data of the same period, the matching verification between registration data and the tax payment data of the same period, the completeness verification of statutory pre-requisites, and the consistency verification between seizure registration and the judicial documents of the court of the same period. Specifically, it can verify whether the real estate unit that is seized or unseized is consistent with the record in the judicial document, whether there are multiple seizure documents on the same real estate unit, and whether the chronological order of the corresponding documents is correct.

[0086] As a feasible implementation method, a distributed parallel computing architecture can be used to achieve efficient verification of massive amounts of data when performing hierarchical verification. For example, a distributed parallel computing architecture with one master node and multiple slave nodes can be used. Specifically, the standardized initial dataset is divided into multiple data shards using the real estate unit number as the sharding key, and these shards are evenly distributed to each computing node for parallel verification. During the verification process, for the existing data corresponding to each real estate unit number, the aforementioned verifications are executed sequentially according to the pre-set verification levels in the target verification rule base.

[0087] In any verification level, if any existing data fails the corresponding level's verification rules, it is marked as anomalous data. The anomaly type, location, rule number, legal basis for the corresponding historical period, and verification level are automatically recorded. Finally, all marked anomalous data is aggregated to generate a list of anomalous existing data. This list includes the anomalous data identifier, original data content, anomaly type, location, rule number, legal basis for the corresponding historical period, and verification level information.

[0088] For example, to help understand the implementation process of the stock data governance method based on real estate unit number during the decentralized registration period in this embodiment, please refer to... Figure 3 , Figure 3 A schematic diagram of a hierarchical verification process for a method of managing existing data based on real estate unit numbers during the decentralized registration period is provided, specifically: After generating the standardized initial dataset, distributed parallel computing task scheduling is performed first. Using the real estate unit number as the sharding key, the standardized initial dataset is divided into multiple data shards and allocated to multiple computing nodes for parallel verification, thereby improving the verification efficiency of massive real estate stock data.

[0089] Then, the historical version rules are dynamically loaded. The formation time of each data point in the standardized initial dataset is traversed, the historical period to which the data belongs is automatically identified, and the corresponding version of the validation rule library is loaded.

[0090] After the version rules are loaded, four layers of parallel validation are performed sequentially on the standardized initial dataset. The first layer is field-level validation, including validation of required fields for non-empty fields, validation of historical ownership certificate number format, validation of national standard value range, and validation of real estate unit number coding standards, used to check the integrity, format compliance, and value range legality of the data. The second layer is ownership evolution-level validation, including validation of the logical connection between land and building ownership during the period of separate land and building ownership, validation of the continuity of the entire historical business timeline, validation of the legality of ownership source documents, and validation of the logical consistency of changes in ownership status, used to check the logical consistency, temporal continuity, and legality of ownership source. The third layer is spatial boundary-level validation, including validation of the matching degree of land parcel and building spatial range, validation of boundary point coordinate closure, and validation of non-overlapping spatial ranges, used to check the topological correctness, coordinate consistency, and rationality of the spatial range. The fourth layer is cross-departmental collaborative verification, including verification of the consistency between transfer registration and concurrent housing and construction transaction filing data, verification of the matching between registration data and concurrent tax payment data, and verification of the consistency between seizure registration and concurrent court judicial documents. These are used to check the consistency between registration data and cross-departmental data.

[0091] After the four-layer parallel verification is completed, the abnormal data detected by the verification is automatically marked with the abnormal type, abnormal location, violation rule number and corresponding legal basis of the historical period, etc., and a structured list of existing abnormal data is generated, providing a clear target basis for subsequent abnormal resolution.

[0092] Step S50: Based on the existing abnormal data list, perform data correction operations on the standardized initial dataset to obtain a compliant standard dataset.

[0093] In this embodiment, when performing correction operations on existing data marked as anomalous in the standardized initial dataset, the core basis is the legal registration regulations applicable to the historical period when the anomalous data was formed. This ensures that the correction results comply with the legal requirements of the corresponding historical period in both substance and procedure, strictly adhering to the legal principle of non-retroactivity. To achieve this, a real estate ownership knowledge graph is introduced as the core reasoning engine. Through semantic classification, historical rule matching, root cause tracing, and confidence calculation of anomalous data, accurate identification and graded handling of anomalous data are achieved.

[0094] Specifically, step S50 includes steps S51 to S55: Step S51: Determine the historical period to which the abnormal data belongs based on the formation time corresponding to each abnormal data in the list of existing abnormal data.

[0095] Step S52: Obtain the real estate ownership knowledge graph corresponding to the historical period. The real estate ownership knowledge graph includes core ontology and core relationships, as well as ontology reasoning rules configured based on the statutory registration norms of the corresponding historical period.

[0096] Step S53: Based on the real estate ownership knowledge graph, obtain the preset weights of the relationships involved in the abnormal data, and calculate the confidence level for automatically resolving the abnormal data according to the preset weights.

[0097] Step S54: When the confidence level is greater than or equal to the preset confidence threshold, perform an automatic resolution operation on the abnormal data according to the ontology reasoning rules to generate corrected data records.

[0098] Step S55: Update the standardized initial dataset based on the corrected data records to obtain the compliance standard dataset.

[0099] The real estate ownership knowledge graph is a semantic network built on existing historical data. With real estate units as the core nodes, the graph integrates core ontological information such as historical rights holders, historical ownership certificates, historical registration business, geospatial entities, historical archive data, and cross-departmental collaborative data. It defines core relationships such as ownership holding relationships, historical business chronological relationships, ownership evolution links, spatial matching relationships, archive association relationships, and requirement matching relationships. Based on the statutory registration norms of the corresponding historical period, it configures ontological reasoning rules to support the semantic classification, root cause reasoning, and intelligent resolution of abnormal data.

[0100] First, based on the formation time of each abnormal data item in the existing abnormal data list, the historical period to which the abnormal data belongs is determined. Then, a pre-constructed real estate ownership knowledge graph corresponding to the historical period is obtained. This real estate ownership knowledge graph contains at least the above seven core ontology types and six core relationship types, as well as ontology reasoning rules configured based on the statutory registration norms of the corresponding historical period. Finally, intelligent resolution analysis is performed based on this real estate ownership knowledge graph.

[0101] As an example, based on the legal registration documents of the corresponding historical period, the ontology reasoning rule for that historical period is configured as "the transfer registration of house ownership from 1995 to 2008 does not require the association of land use right transfer registration".

[0102] Intelligent resolution analysis includes the following process: First, the abnormal data is semantically classified. The semantic reasoning capabilities of the knowledge graph are used to classify the abnormal data into corresponding abnormal categories, such as missing or incorrect codes, missing or incorrect field formats, broken ownership history, disconnected historical archives, mismatched real estate data, duplicate filings, or inconsistencies across departments. Then, based on the formation time of the abnormal data, the ontology reasoning rules for the corresponding historical period are matched from the real estate ownership knowledge graph, and the root cause of the abnormal data is traced based on the core relationships involved in the abnormal data. Finally, based on the core relationships involved in the abnormal data and combined with the preset relationship weights, the confidence level for automatically resolving the abnormal data is calculated.

[0103] When the confidence level is greater than or equal to a preset confidence threshold, the anomalous data is automatically resolved according to ontology inference rules, generating corrected data records. When the confidence level is less than the preset confidence threshold, the anomalous data is pushed to the manual processing end, and the legal basis and similar case reference information corresponding to the historical period of the anomalous data are associated with it. The corrected data returned by the manual processing end is received. Finally, the standardized initial dataset is updated using the corrected data records and / or the corrected data returned by the manual processing end, ultimately obtaining the compliance standard dataset.

[0104] Automatic resolution refers to the differentiated automatic correction processing performed on abnormal data of different anomaly categories based on the reasoning results of the real estate ownership knowledge graph. Specifically: First, the resolution method is determined based on the semantic classification results (i.e., anomaly categories) of the abnormal data. For anomalies of missing or incorrect codes, the real estate unit number is automatically completed or corrected based on the coding information of other related data under the same real estate unit in the knowledge graph and the coding rules of the real estate unit. For anomalies of missing or incorrect field formats, the corresponding field values ​​from other sources under the same real estate unit are extracted from the knowledge graph for filling, or the field format is automatically converted according to the statutory registration specifications of the corresponding historical period. For anomalies of mismatched land and housing data, land registration data and housing registration data are automatically associated and matched based on the spatial matching relationship and ownership evolution link relationship in the knowledge graph. For anomalies of broken ownership evolution... For anomalies, based on the historical business sequence relationships and ownership holding relationships in the knowledge graph, missing ownership transfer links are automatically filled in to form a complete ownership evolution chain; for anomalies related to disconnected historical archives, existing data is automatically linked with corresponding historical archive data according to the archive association relationships in the knowledge graph; for anomalies related to duplicate filing, duplicate records are identified and automatically merged through entity alignment and relationship reasoning in the knowledge graph, retaining only the unique and valid real estate unit record; for anomalies related to cross-departmental data inconsistency, differences between data from different sources are automatically coordinated based on the element matching relationships in the knowledge graph and in accordance with statutory registration standards.

[0105] All the aforementioned resolution operations are constrained by the ontology reasoning rules corresponding to the historical period in the real estate ownership knowledge graph, ensuring that the automatic correction operations strictly adhere to the legal principle of non-retroactivity. After resolution is completed, the system automatically generates a structured resolution log, recording information such as the anomaly category, resolution method, the ontology reasoning rules used, and the operation time, for subsequent traceability and auditing.

[0106] For example, to help understand the implementation process of the stock data governance method based on real estate unit number during the decentralized registration period in this embodiment, please refer to... Figure 4 , Figure 4 A schematic diagram of an intelligent anomaly resolution process for a method of managing existing data based on real estate unit numbers during the decentralized registration period is provided. Specifically: After obtaining the list of existing abnormal data, the historical period to which each abnormal data belongs is first determined according to the formation time of each abnormal data, and a pre-constructed real estate ownership knowledge graph corresponding to that historical period is obtained. This real estate ownership knowledge graph includes core ontology, core relationships, and ontology reasoning rules configured based on the statutory registration norms of the corresponding historical period.

[0107] Next, anomaly semantic classification is performed. Based on the semantic reasoning capabilities of the knowledge graph, the abnormal data is divided into corresponding anomaly categories, such as missing or incorrect codes, missing or incorrect field formats, broken ownership history, disconnected historical archives, mismatched real estate data, duplicate filing, or inconsistent cross-departmental data.

[0108] Then, historical rule matching and anomaly root cause localization are performed. Based on the formation time of the anomaly data, ontology reasoning rules corresponding to the historical period are matched from the knowledge graph, and the root cause of the anomaly data is traced based on the core relationships in the knowledge graph. On this basis, the confidence level for automatically correcting the anomaly data is calculated by combining preset relationship weights.

[0109] After obtaining the confidence level, it is compared with a preset threshold. If the confidence level reaches the preset threshold, automatic resolution is performed, including automatic completion, correction, matching, and fusion, generating corrected data records. If the confidence level does not reach the preset threshold, the abnormal data is pushed to the manual processing end, and is associated with the corresponding historical legal registration regulations and similar case reference information for final judgment and correction by humans. After intelligent resolution is completed, a structured resolution log with legal basis is generated, and the corrected data records are updated to the standardized initial dataset.

[0110] In summary, this embodiment addresses the issue of accessing and processing heterogeneous data from multiple departments during the decentralized registration period by acquiring multi-source stock data, including land registration data, housing registration data, historical archive data, and cadastral survey data. This provides a complete data foundation for subsequent data association and governance. By performing multi-feature fusion matching operations and utilizing a three-level priority matching strategy to gradually expand the matching coverage, land registration data, housing registration data, historical archive data, and spatial data, originally scattered across different competent authorities and lacking unified identification, are associated with the same real estate unit and assigned a legal real estate unit number. This solves the data fragmentation and ownership link breakage problems caused by the lack of unified national standard coding during the decentralized registration period, achieving legally unified association of historical data throughout the entire lifecycle of the same real estate unit. By dynamically loading the corresponding historical version of the verification rule library based on the formation time of each stock data entry, the verification of historical data strictly adheres to the legal registration standards valid at the time of data formation. This avoids misjudgments caused by using current unified rules to verify historical data, solving the problems of high false positive rates in anomaly detection and large workload in handling invalid data. By performing layered parallel verification, the compliance of data is thoroughly examined layer by layer from the field level to the cross-departmental collaborative level, generating a structured list of abnormal data, providing a clear target basis for subsequent precise resolution. Furthermore, intelligent resolution is performed based on a real estate ownership knowledge graph divided by historical versions. Semantic classification, root cause location, and confidence calculation are performed according to the statutory registration specifications of the historical period to which the abnormal data belongs. High-confidence anomalies are automatically resolved, while low-confidence anomalies are pushed for manual handling with accompanying statutory rule references. This ensures that the correction operation strictly adheres to the principle of non-retroactivity of laws, solving the compliance problem of regulatory flaws in the governance results. This application's method, through the organic connection of each link, forms a complete governance chain from data collection, statutory anchoring, version-based verification to compliance resolution, achieving full compliance governance of existing data from the decentralized registration period.

[0111] Based on the above embodiments of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 In the method for managing existing data based on real estate unit numbers during the decentralized registration period, step S55 includes steps S551 to S555: Step S551: Based on the real estate unit number confirmation process record set, existing compliance data list, full verification process log, repaired compliance dataset and anomaly handling process record set corresponding to each real estate unit, determine the full governance data corresponding to each real estate unit.

[0112] Step S552: Using a hash algorithm, generate corresponding evidence hashes for the full governance data corresponding to each of the real estate units.

[0113] Step S553: ​​Bind the evidence storage hash to the real estate unit number of the corresponding real estate unit, combine it with the corresponding full governance data to form a standard data entry of the real estate unit carrying the evidence storage hash, and summarize all the standard data entries to form the compliance standard dataset.

[0114] Step S554: Extract key operational data from the compliance standard dataset, encapsulate the key operational data into on-chain transaction data, perform on-chain evidence storage operation on the on-chain transaction data, and upload it to the real estate consortium chain. The key operational data includes encoding matching results, encoding generation basis, verification rule base version number, anomaly resolution operation content and legal basis, and manual handling results.

[0115] Step S555: Receive a traceability query request initiated by the real estate unit number, obtain and return the corresponding evidence storage hash and on-chain evidence storage data based on the real estate unit number.

[0116] In this embodiment, key operational data refers to the core record information generated in the entire process of real estate multi-source stock data governance, which can reflect the execution status and compliance basis of each governance link. Its content includes code matching results, code generation basis, verification rule base version number, anomaly resolution operation content and legal basis, and manual handling results.

[0117] The data includes several sections: **Code Matching Results:** Records the existing real estate unit numbers obtained directly from the compliant real estate unit code library after successful precise matching of each data item. These codes existed before matching and are directly referenced during aggregation. **Code Generation Basis:** Records the generation process and basis for the newly compiled real estate unit numbers based on the matched land parcel information and real estate unit coding rules after successful fuzzy matching combined with spatial verification or pure spatial matching of each data item. These codes did not exist before matching and need to be compiled after matching based on land parcel information and fixture information. **Verification Rule Library Version Number:** Records the historical version rule library identifier loaded during the verification process of each data item, used to prove that the verification operation corresponds to the applicable statutory registration standards at the time of data formation. **Anomaly Resolution Operation Content and Legal Basis:** Records the corrective actions performed on each abnormal data item during intelligent resolution, as well as the corresponding historical statutory registration standard provisions or statutory registration documents supporting these corrective actions. **Manual Processing Results:** Records the final corrective results returned after manual confirmation of rights for abnormal data with low confidence levels. The aforementioned key operational data covers core operational information in the entire governance chain, from coding and assignment, hierarchical verification to anomaly resolution and manual handling, providing a complete data foundation for subsequent evidence preservation, traceability, and liability determination.

[0118] This embodiment uses a consortium blockchain-based notarization and hash binding method to solidify and preserve key operational data throughout the governance process, ensuring traceability and immutability. Specifically, firstly, based on the notarized process record set, existing compliance data list, full verification process log, post-repair compliance dataset, and anomaly handling process record set corresponding to each real estate unit, the full governance data for each real estate unit is determined. A hash algorithm is used to generate a corresponding notarized hash for the full governance data of each real estate unit. This notarized hash value is unique and corresponds to the governance data content of that real estate unit; any change in data content will result in a change in the hash value. This notarized hash is bound to the corresponding real estate unit number and stored in the metadata of the compliance standard dataset, forming a mapping relationship between the notarized hash and the real estate unit number. Then, combined with the corresponding full governance data, standard data entries for real estate units carrying the notarized hash are formed. All standard data entries are then aggregated to form the compliance standard dataset.

[0119] Then, key operational data is extracted from the compliance standard dataset, including code matching results, code generation basis, verification rule base version number, anomaly resolution operation content and legal basis, and manual handling results. The extracted key operational data is encapsulated according to a preset transaction data structure to generate on-chain transaction data. This on-chain transaction data structure includes fields such as transaction identifier, real estate unit number, operation type, operation content, legal basis, operator's digital signature, operation timestamp, and evidence hash.

[0120] After encapsulation, the on-chain transaction data is submitted to the real estate consortium blockchain. Multiple nodes in the real estate consortium blockchain verify and confirm the on-chain transaction data through the PBFT consensus mechanism. After confirmation, the on-chain transaction data is packaged into a block and appended to the real estate consortium blockchain, completing the on-chain notarization operation. This real estate consortium blockchain is composed of multiple legal institution nodes, each of which independently stores a complete copy of the on-chain data. Data modifications on a single node do not affect the data consistency of other nodes, thus ensuring that the notarized data cannot be unilaterally tampered with and can be verified across institutions.

[0121] When a traceability query request initiated via a real estate unit number is received, the corresponding evidence storage hash value is retrieved from the metadata of the compliance standard dataset based on the real estate unit number. Then, using the evidence storage hash value as an index, the corresponding on-chain evidence storage data is obtained from the real estate consortium blockchain. The retrieved evidence storage hash and on-chain evidence storage data are returned as the query result. In this way, every key operation in the governance process is solidified and stored in the real estate consortium blockchain and associated with a specific real estate unit. Subsequently, the complete governance process of any real estate unit can be traced and verified through the real estate unit number.

[0122] For example, to help understand the implementation process of the decentralized registration period-based stock data governance method obtained by combining the above embodiments, please refer to... Figure 6 , Figure 6 A schematic diagram of the entire-chain legal evidence preservation and traceability process for a method of managing existing data based on real estate unit numbers during the decentralized registration period is provided, specifically: First, a full governance data determination and hash binding process is executed. Based on the real estate unit number confirmation process record set, the existing compliance data list, the full verification process log, the post-repair compliance dataset, and the exception handling process record set corresponding to each real estate unit, the full governance data for each real estate unit is determined. A hash algorithm is used to generate a corresponding evidence hash value for the full governance data of each real estate unit. This evidence hash value is unique and corresponds to the governance data content of that real estate unit; any change in the data content will cause a change in the hash value. This evidence hash value is bound to the corresponding real estate unit number and stored in the metadata of the compliance standard dataset, forming a mapping relationship between the evidence hash and the real estate unit number. Then, combined with the corresponding full governance data, standard data entries for the real estate unit carrying the evidence hash are formed. All standard data entries are then aggregated to form the compliance standard dataset.

[0123] After the compliance standard dataset is formed, a process for storing key operational data on the blockchain is executed. Key operational data is extracted from the compliance standard dataset, including code matching results or code generation basis, verification rule base version number, anomaly resolution operation content and legal basis, and manual handling results. The extracted key operational data is encapsulated according to a predetermined transaction data structure to generate on-chain transaction data. This on-chain transaction data includes fields such as transaction identifier, real estate unit number, operation type, operation content, legal basis, operator's digital signature, operation timestamp, and storage hash. After encapsulation, the on-chain transaction data is submitted to the real estate consortium blockchain. Multiple nodes in the real estate consortium blockchain verify and confirm the transaction data through the PBFT consensus mechanism. After confirmation, the transaction data is packaged into a block and appended to the real estate consortium blockchain, completing the on-chain storage operation.

[0124] Finally, the traceability query process is executed. When a traceability query request initiated via the real estate unit number is received, the corresponding evidence storage hash value is retrieved from the metadata of the compliance standard dataset based on the real estate unit number. Then, using the evidence storage hash value as an index, the corresponding on-chain evidence storage data is obtained from the real estate consortium blockchain. The retrieved evidence storage hash and on-chain evidence storage data are returned as the query result. Through the above end-to-end legal evidence storage and traceability process, each key operation in the governance process is solidified and stored in the real estate consortium blockchain and associated with a specific real estate unit. Subsequently, the complete governance process of any real estate unit can be traced and verified through the real estate unit number.

[0125] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Building upon the completion of existing data collection, three-level priority multi-feature fusion matching, hierarchical verification, intelligent resolution, and on-chain evidence storage in the foregoing embodiments, this embodiment further introduces a closed-loop back-checking and model iteration optimization mechanism to ensure the long-term stability of the governance effect and continuously improve the accuracy and recall rate of the governance model. Please refer to... Figure 7 Following step S553, the method for managing existing data based on real estate unit numbers during the decentralized registration period further includes steps S5531 to S5533: Step S5531: Synchronize the compliance standard dataset to the real estate registration business database, and perform a full back-check on the compliance standard dataset within a first preset time after the compliance standard dataset is entered into the database to determine the residual anomalies detected by the verification.

[0126] Step S5532: Repeat the step of performing data correction operation on the standardized initial dataset for the residual anomalies until the residual anomaly rate is lower than the preset qualified threshold. The residual anomaly rate is the proportion of the number of residual anomalies detected by full re-check to the total amount of stored data being checked.

[0127] Step S5533: After the full return check passes, perform incremental verification on the business-related data newly added in the previous period according to the preset period, and update the ownership status of the corresponding existing data according to the verification results.

[0128] An initial full-scale backtest is performed on the compliance standard dataset. Within the first preset time after the compliance standard dataset is added to the database, a second full-scale verification is performed on the added data using the hierarchical verification rules to identify residual anomalies. For the residual anomalies detected, the anomaly classification, root cause location, confidence calculation, and graded handling (i.e., intelligent handling and manual handling) are performed again according to the intelligent resolution process described in the previous embodiment until the residual anomaly rate is lower than the preset qualified threshold. This residual anomaly rate refers to the proportion of residual anomalies detected in the second full-scale verification to the total amount of stored data being verified, and is used to measure the proportion of abnormal data that has not been discovered or correctly corrected after the initial treatment.

[0129] Optionally, after the first full-volume backtest passes, incremental verification is performed on the business-related data newly added in the previous period according to a preset cycle, and the ownership status of the corresponding existing data is updated according to the verification results.

[0130] As an example, after the initial full-scale review passes, a quarterly incremental review can be performed. That is, on the first day of the first month of each quarter, incremental verification is performed on business-related data that was added or changed in the previous quarter. For abnormal data detected in the incremental verification, it is corrected according to the intelligent resolution process in the aforementioned embodiment, and the ownership status of the corresponding existing data is updated according to the correction results, thereby ensuring that the ownership status of the existing data is kept synchronized with the continuous processing of real estate registration business.

[0131] While conducting the re-inspection, feedback data can be collected through multiple channels. This feedback data includes residual anomalies from the re-inspection, existing data issues discovered during business processing, manual handling results, and updates to statutory registration standards. Specifically, in collecting feedback through multiple channels, the existing data anomaly reporting module embedded in the real estate registration business system can be used to collect existing data issues reported by business personnel during business processing; the manual handling result feedback channel can be used to collect the correction results of low-confidence anomalies after manual handling; and the real estate registration objection handling channel can be used to collect ownership objection data raised by rights holders, while also collecting residual anomaly data detected in the initial full-scale re-inspection and the incremental re-inspection within a preset period.

[0132] After collecting feedback data from multiple channels, the collected feedback data is aggregated and used as incremental training samples. Based on these incremental training samples, a gradient descent algorithm can be used to incrementally update the preset weights of the verification rule thresholds and the core ontology and core relationships in the real estate ownership knowledge graph, enabling the governance model to adapt to the changing trends of business data. In addition, full training can be performed on the real estate ownership knowledge graph, and the verification rules can be updated to release a new version of the governance model, while all historical versions of the governance model are retained for future reference.

[0133] It should be noted that the governance model in this solution does not refer to a specific independent algorithm or software module, but rather to the overall governance process involved in the aforementioned embodiments, including matching rules, verification rules, anomaly classification and confidence determination logic, intelligent resolution and tiered handling strategies, etc. This governance model can be implemented procedurally based on a rule engine or workflow engine according to the aforementioned steps, or it can be parametrically trained and iteratively optimized using machine learning or other algorithmic models. Regardless of whether a procedural implementation or an algorithmic model implementation is used, as long as it includes the aforementioned data governance logic, it falls within the protection scope of this application.

[0134] As an example, in monthly incremental updates, all feedback data generated in the previous month is collected each month as incremental training samples. A gradient descent algorithm is used to incrementally update the judgment thresholds in the verification rules and the preset weights of the core ontology and core relationships in the real estate ownership knowledge graph. Based on this, all feedback data generated in the previous quarter is summarized each quarter, and a full-scale training is performed on the real estate ownership knowledge graph to update its core ontology, core relationships, and ontology inference rules. Simultaneously, the verification rule base is updated, a new version of the governance model is released, and all historical versions are retained for future reference, ensuring that the model update process is traceable and reversible. Through this dual-cycle model iteration mechanism, the verification accuracy and intelligent resolution capabilities of the governance model continuously improve with the accumulation of feedback data, thereby ensuring the long-term stability of the existing data governance effect.

[0135] For example, to help understand the implementation process of the decentralized registration period-based stock data governance method obtained by combining the above embodiments, please refer to... Figure 8 , Figure 8 A schematic diagram of a closed-loop backtesting and model iterative optimization process based on real estate unit number during the decentralized registration period is provided, specifically: After generating the compliance standard dataset, a two-level backtest is performed. The first full backtest is executed within a preset time after the compliance standard dataset is entered into the database. It calls the layered verification rule base to perform a second full verification on the entered data. The residual anomalies detected by the verification are then classified, root cause located, confidence calculated, and graded and handled again according to the intelligent resolution process until the residual anomaly rate is lower than the preset qualified threshold. The quarterly incremental backtest is executed according to a preset cycle. Incremental verification is performed on business-related data that has been added or changed in the previous cycle. The abnormal data items detected by the verification are corrected according to the intelligent resolution process, and the ownership status of the corresponding existing data is updated based on the correction results.

[0136] While completing the re-inspection, multi-channel feedback collection was implemented. This included collecting existing data issues reported by staff during the business processing through the embedded existing data anomaly reporting module in the real estate registration business system; collecting the correction results of low-confidence anomalies after manual processing through the manual processing feedback channel; collecting ownership objection data raised by rights holders through the real estate registration objection handling channel; and collecting residual anomaly data detected in the initial full re-inspection and quarterly incremental re-inspections. All the collected feedback data was then aggregated and used as training samples for model iteration.

[0137] After completing the feedback data collection, a two-cycle model iteration is executed. In the monthly incremental update, feedback data generated in the previous month is collected each month as incremental training samples. The gradient descent algorithm is used to incrementally update the judgment thresholds in the verification rules and the weights of ontology relationships in the real estate ownership knowledge graph. In the quarterly full update, all feedback data generated in the previous quarter is summarized each quarter. Full training is performed on the real estate ownership knowledge graph to update its ontology classification system, relationships, and inference rules. Simultaneously, the verification rule base is updated, a new version of the governance model is released, and all historical versions are retained for future reference.

[0138] Through the above closed-loop back-checking and model iteration optimization process, the verification accuracy and resolution capability of the governance model continue to improve with the accumulation of feedback data, thereby ensuring the long-term stability of the governance effect of existing data.

[0139] For example, to help understand the implementation process of the decentralized registration period-based stock data governance method obtained by combining the above embodiments, please refer to... Figure 9 , Figure 9 A simplified flowchart illustrating a method for managing existing data based on real estate unit numbers during the decentralized registration period is provided. Specifically: like Figure 9 As shown, this application proposes a method for governing existing data based on real estate unit numbers during the decentralized registration period. First, a multi-source data collection and legal anchoring stage is performed to obtain multi-source existing data during the decentralized registration period. Then, through a three-level priority multi-feature fusion matching operation, the real estate unit to which each piece of existing data belongs is determined and assigned a real estate unit number, generating a standardized initial dataset.

[0140] Then, the historical rule-based hierarchical verification stage is executed. Based on the formation time of each piece of existing data, the corresponding version of the verification rule library is dynamically loaded, and hierarchical verification is performed on the standardized initial dataset to generate a list of existing abnormal data.

[0141] Next, the historical rule adaptation and intelligent resolution stage is executed. Based on the real estate ownership knowledge graph of different historical versions, the abnormal data is semantically classified, the root cause is located and the confidence level is calculated. According to the confidence level, the abnormal data is automatically resolved or pushed to manual processing to generate a compliance standard dataset.

[0142] Subsequently, the full-chain legal evidence preservation and traceability stage is executed, which involves storing key operational data in the process of real estate stock data governance on the blockchain, generating evidence hashes and binding them with real estate unit numbers, and providing traceability query interfaces.

[0143] While advancing the governance process, feedback data such as residual anomalies discovered during back inspections, existing data issues reported during business processing, manual handling results, and updated registration standards are regularly used as training samples. The verification rule base and real estate ownership knowledge graph are subjected to dual-cycle iterative optimization with monthly incremental updates and quarterly full updates. This iterative optimization runs through both the intelligent resolution and back inspection iteration stages, continuously improving the verification accuracy and resolution capabilities of the governance model.

[0144] This application ultimately completes the entire governance loop through closed-loop back-checking and model iteration optimization stages, achieving long-term stability and continuous optimization of the governance effect of existing data.

[0145] This application provides a data management device for existing data based on real estate unit number during the decentralized registration period. The data management 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 execute the data management method for existing data based on real estate unit number during the decentralized registration period in the above embodiment 1.

[0146] The following is for reference. Figure 10 The diagram illustrates a structural schematic of a data management device suitable for implementing the decentralized registration period based on real estate unit number embodiments of this application. The decentralized registration period based on real estate unit number data management device in the embodiments of this application may include various hardware and software components for implementing the decentralized registration period based on real estate unit number data management method. Figure 10 The illustrated device for managing existing data based on real estate unit number during the decentralized registration period is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0147] like Figure 10As shown, the data management device for existing real estate unit numbers during the decentralized registration period may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the data management device for existing real estate unit numbers during the decentralized registration period. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the decentralized registration period data management equipment based on property unit numbers to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a decentralized registration period data management equipment based on property unit numbers with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0148] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, 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 flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0149] The decentralized registration period-based existing data governance device provided in this application, employing the decentralized registration period-based existing data governance method described in the above embodiments, can solve the technical problem that existing real estate data governance systems lack the legal anchoring capability of real estate unit numbers, resulting in the inability to accurately correlate multi-source existing real estate data during decentralized registration periods. Compared with the prior art, the beneficial effects of the decentralized registration period-based existing data governance device provided in this application are the same as those of the decentralized registration period-based existing data governance method provided in the above embodiments, and other technical features in this decentralized registration period-based existing data governance device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0150] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0151] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0152] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the stock data management method based on real estate unit number during the decentralized registration period in the above embodiments.

[0153] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or apparatus. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0154] The aforementioned computer-readable storage medium may be included in the existing data management equipment based on real estate unit number during the decentralized registration period; or it may exist independently and not be assembled into the existing data management equipment based on real estate unit number during the decentralized registration period.

[0155] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the data governance device for existing data based on real estate unit numbers during the decentralized registration period, the data governance device for existing data based on real estate unit numbers during the decentralized registration period performs the following: acquires multi-source existing data, including land registration data, housing registration data, historical archive data, and cadastral survey data; performs multi-feature fusion matching operations on the multi-source existing data to determine the set of existing data belonging to the same real estate unit and the real estate unit number corresponding to the real estate unit, and associates each real estate unit number with the corresponding historical archive data to generate a standardized initial dataset; determines the target verification rule base for the corresponding version based on the formation time of each piece of existing data in the standardized initial dataset; performs hierarchical verification on the standardized initial dataset based on the target verification rule base to generate a list of abnormal existing data; and performs data correction operations on the standardized initial dataset based on the list of abnormal existing data to obtain a compliant standard dataset.

[0156] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0158] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0159] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described method for managing existing real estate data based on real estate unit numbers during the decentralized registration period. This solves the technical problem that existing real estate data management systems lack the legal anchoring capability of real estate unit numbers, resulting in the inability to accurately correlate multi-source real estate data during the decentralized registration period. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the method for managing existing real estate data based on real estate unit numbers during the decentralized registration period provided in the above embodiments, and will not be elaborated upon here.

[0160] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for managing existing data based on real estate unit numbers during the decentralized registration period.

[0161] The computer program product provided in this application can solve the technical problem that existing real estate data governance systems lack the legal anchoring capability of real estate unit numbers, resulting in the inability to accurately correlate multi-source real estate stock data during the period of decentralized registration. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the stock data governance method based on real estate unit numbers during the period of decentralized registration provided in the above embodiments, and will not be repeated here.

[0162] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

[0163] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0164] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0165] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for managing existing data based on real estate unit numbers during the decentralized registration period, characterized in that, The method for managing existing data based on real estate unit numbers during the decentralized registration period includes: Acquire multi-source stock data, including land registration data, housing registration data, historical archive data, and property rights survey data; Perform multi-feature fusion matching operation on the multi-source stock data to determine the stock data set belonging to the same real estate unit and the real estate unit number corresponding to the real estate unit, and associate each real estate unit number with the corresponding historical archive data to generate a standardized initial dataset; Based on the formation time of each existing data in the standardized initial dataset, the target verification rule base of the corresponding version is determined; Perform hierarchical verification on the standardized initial dataset according to the target verification rule base to generate a list of existing abnormal data; Based on the existing abnormal data list, data correction operations are performed on the standardized initial dataset to obtain a compliant standard dataset; The multi-feature fusion matching operation includes three matching stages executed sequentially: precise matching, fuzzy matching combined with spatial verification, and pure spatial matching. The steps for performing the multi-feature fusion matching operation on the multi-source existing data include: Extract the land parcel code, building number, and household number from the multi-source stock data, and concatenate them to generate the first combined feature string; The first combined feature string is precisely matched with the compliant real estate unit coding library. If the match is successful, the original stock data providing the field values ​​in the first combined feature string is collected into the real estate unit corresponding to the matching result. Obtain the real estate unit number corresponding to the matching result, and associate the real estate unit number with the corresponding historical archive data; Historical ownership certificate numbers, rights holder names, and location addresses are extracted from the multi-source stock data that has never been precisely matched, and then concatenated to generate a second combination feature string; The second combination of feature strings is fuzzy matched with the standard parcel spatial database. If the match is successful, the coordinates of the boundary point corresponding to the matched target parcel are obtained. Address parsing is performed on the location address in the second combined feature string to convert it into the corresponding spatial coordinate point. The similarity between the spatial coordinate point and the boundary point coordinates corresponding to the target land parcel is calculated. When the similarity is greater than or equal to the preset similarity threshold, the original stock data providing the field values ​​in the second combined feature string is collected into the real estate unit corresponding to the target land parcel. The real estate unit number corresponding to the target land parcel is generated according to the real estate unit coding rules, and the real estate unit number is associated with the corresponding historical archive data; The boundary point coordinates are extracted from the multi-source stock data that has never been obtained through the fuzzy matching combined with spatial verification, and a spatial vector graphic is generated based on the boundary point coordinates; The spatial vector graphics are spatially overlaid with the standard parcel spatial database to calculate the spatial overlap. When the spatial overlap is greater than or equal to a preset threshold, the original stock data providing the boundary point coordinates will be collected into the real estate unit determined by the spatial overlay analysis. The real estate unit number corresponding to the real estate unit is generated according to the real estate unit coding rules, and the real estate unit number is associated with the corresponding historical archive data.

2. The method for managing existing data based on real estate unit numbers during the decentralized registration period as described in claim 1, characterized in that, The step of determining the target validation rule base of the corresponding version based on the formation time of each existing data in the standardized initial dataset includes: Based on the correspondence between different historical periods and statutory registration standards, a corresponding verification rule base is constructed for each of the aforementioned historical periods; Based on the target historical period corresponding to the formation time of each piece of existing data, a verification rule base associated with the target historical period is selected as the target verification rule base.

3. The method for managing existing data based on real estate unit numbers during the decentralized registration period as described in claim 1, characterized in that, The step of performing hierarchical verification on the standardized initial dataset according to the target verification rule base to generate a list of existing abnormal data includes: The standardized initial dataset is subjected to field-level validation, ownership history-level validation, spatial boundary-level validation, and cross-departmental collaboration-level validation in sequence. In any verification level, if there is existing data that fails the verification rules of the corresponding level, the existing data that fails the verification is marked as abnormal data, and the abnormality type and the verification level to which the existing data that fails the verification belongs are recorded. All existing data marked as abnormal data are aggregated to generate the existing abnormal data list. The existing abnormal data list includes abnormal data identifier, original data content, abnormal type, abnormal location, violation rule number, legal basis for the corresponding historical period, and verification level information.

4. The method for managing existing data based on real estate unit numbers during the decentralized registration period as described in claim 1, characterized in that, The step of performing data correction operations on the standardized initial dataset based on the existing abnormal data list to obtain a compliant standard dataset includes: Based on the formation time corresponding to each abnormal data in the existing abnormal data list, determine the historical period to which the abnormal data belongs; Obtain a real estate ownership knowledge graph corresponding to the historical period. The real estate ownership knowledge graph includes core ontology and core relationships, as well as ontology reasoning rules configured based on the statutory registration norms of the corresponding historical period. Based on the real estate ownership knowledge graph, the preset weights of the relationships involved in the abnormal data are obtained, and the confidence level for automatically resolving the abnormal data is calculated according to the preset weights. When the confidence level is greater than or equal to the preset confidence threshold, the abnormal data is automatically resolved according to the ontology reasoning rules to generate corrected data records. The standardized initial dataset is updated based on the corrected data records to obtain the compliance standard dataset.

5. The method for managing existing data based on real estate unit numbers during the decentralized registration period as described in claim 4, characterized in that, After the steps of obtaining preset weights of the relationships involved in the abnormal data based on the real estate ownership knowledge graph, and calculating the confidence level for automatically resolving the abnormal data according to the preset weights, the method for managing existing data based on real estate unit numbers during the decentralized registration period further includes: When the confidence level is less than the preset confidence threshold, the abnormal data is pushed to the manual processing terminal, and the legal basis and similar case reference information of the corresponding historical period of the abnormal data are associated with it. The system receives corrected data returned by the manual processing terminal, updates the standardized initial dataset based on the corrected data, and obtains the compliance standard dataset.

6. The method for managing existing data based on real estate unit numbers during the decentralized registration period as described in claim 4, characterized in that, The step of updating the standardized initial dataset based on the corrected data records to obtain the compliance standard dataset includes: Based on the real estate unit number confirmation process record set, the existing compliance data list, the full verification process log, the repaired compliance dataset, and the anomaly handling process record set corresponding to each real estate unit, the full governance data corresponding to each real estate unit is determined. A hash algorithm is used to generate corresponding evidence hashes for the full governance data corresponding to each of the aforementioned real estate units; The evidence storage hash is bound to the real estate unit number of the corresponding real estate unit, and combined with the corresponding full governance data to form a standard data entry of the real estate unit carrying the evidence storage hash. All the standard data entries are summarized to form the compliance standard dataset. Extract key operational data from the compliance standard dataset and encapsulate the key operational data into on-chain transaction data. Perform on-chain evidence storage operation on the on-chain transaction data and upload it to the real estate consortium chain. The key operational data includes code matching results, code generation basis, verification rule base version number, anomaly resolution operation content and legal basis, and manual handling results. Receive a traceability query request initiated by the real estate unit number, obtain and return the corresponding evidence storage hash and on-chain evidence storage data based on the real estate unit number.

7. The method for managing existing data based on real estate unit numbers during the decentralized registration period as described in claim 6, characterized in that, After the steps of binding the evidence-stored hash with the corresponding real estate unit number, combining it with the corresponding full-volume governance data to form a standard data entry for the real estate unit carrying the evidence-stored hash, and summarizing all the standard data entries to form the compliance standard dataset, the method for managing existing data based on real estate unit numbers during the decentralized registration period further includes: The compliance standard dataset is synchronized to the real estate registration business database, and a full back-check is performed on the compliance standard dataset within a first preset time after the compliance standard dataset is entered into the database to determine the residual anomalies detected during the verification. The step of performing data correction on the standardized initial dataset is re-executed for the residual anomalies until the residual anomaly rate is lower than the preset qualified threshold. The residual anomaly rate is the proportion of the number of residual anomalies detected by the full back-check to the total amount of stored data being checked. After the full back-check passes, incremental verification is performed on the business-related data newly added in the previous period according to a preset cycle, and the ownership status of the corresponding existing data is updated according to the verification results.

Images