A data processing method and system for dynamic knowledge graph

Abstract

The application discloses a kind of data processing method and system for dynamic knowledge graph, is specifically related to knowledge graph data processing technical field, for solving the problem of consistency of multiple-source data in park;The application faces park, and the system record is specified as park event frame carrying object identification, event type and time information, is associated by uniform object identification set, according to event type query subgraph template, object node is positioned and is expanded according to template path, limit affected subgraph, only in range incremental update is executed, for record write effective time, invalid time and source event identification, construct time version chain, and current state is generated in combination with the conflict detection of preset time window and source priority decision, build current view and historical view, additional time filtering condition is added to query, realize the time sequence retrieval of equipment operation, lease change etc. Scene, improve the updating efficiency and data consistency of park knowledge graph.

Description

Technical Field

[0001] This invention relates to the field of knowledge graph data processing technology, and more specifically, to a data processing method and system for dynamic knowledge graphs. Background Technology

[0002] In the field of smart park operation and management, information systems such as property management systems, access control systems, parking management systems, energy consumption monitoring systems, and park portal systems have been widely deployed. These systems aggregate business records to the park data platform through database synchronization, interface subscription, and periodic extraction. Some solutions further build static or semi-static park knowledge graphs on this basis to realize functions such as enterprise profiling, equipment ledgers, leasing relationships, parking space occupancy, and energy consumption statistics. Such solutions typically extract data in batches based on the current table in the business database, generate entities and relationships through rule matching, and periodically rebuild or refresh the graph structure on a large scale. The technical implementation focuses on the accuracy of field mapping, entity alignment, and relationship extraction to support unified query and operation dashboard display.

[0003] However, multi-source business systems generate logs independently in the form of log recordings and state snapshots, lacking fine-grained event frame modeling based on unified event time and unified object identification. Differences between different systems in terms of time base, coding system, and state meaning are difficult to resolve in a timely manner, causing graph updates to often rely on batch overlay or global reconstruction, resulting in delayed updates and high computational overhead. On the other hand, existing graphs are mostly based on current state extraction, lacking time version chains and conflict resolution mechanisms for the same object or relationship. Conflicting states from multiple source systems such as property management, access control, and energy consumption within the same time period are difficult to explicitly record and uniformly adjudicate. Graph queries also have difficulty flexibly switching between current and historical views, and cannot accurately answer questions about equipment status, leasing relationships, and parking space occupancy at a specific point in time or time interval, thus weakening the support capabilities of dynamic knowledge graphs in refined operational analysis, accountability, and strategy optimization. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a data processing method and system for dynamic knowledge graphs to solve the problem of consistency of multi-source data in the above-mentioned background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A data processing method for dynamic knowledge graphs includes the following steps:

[0007] S1. Construct a park event frame model, unify the format, map fields and align time for property, access control, parking, energy consumption and park portal business records, and generate an event frame sequence carrying object identifier, event type and timestamp;

[0008] S2, establish an index table from event type to subgraph template, locate the basic object node in the knowledge graph according to the index for each event frame, call the corresponding subgraph template, and expand from the basic object node according to the template path to obtain the affected subgraph range;

[0009] S3 performs local incremental updates within the affected subgraph according to the update rules associated with the event type, appends writes to newly added nodes and edges, writes the expiration time to replaced relationships, writes the effective time and source event identifier to newly added and changed records, and generates a time version chain in object and time order;

[0010] S4. Before the local incremental update, perform conflict detection on the candidate states of the same object within the preset time window, select the current state based on the source priority and event time order and write it into the time version chain, and attach conflict labels to the unselected states.

[0011] S5: During the graph query phase, construct the current view and the historical view based on the time version chain, attach time filtering conditions to the query request, return only the non-expired state in the current view, and return the subgraph that matches the time condition in the historical view.

[0012] In a preferred embodiment, the park event frame model in step S1 includes six types of fields: event type identifier, main object identifier, associated object identifier set, event occurrence time, source system identifier, and original business record identifier. The normalization process includes uniformly naming the field names from different business systems, uniformly converting the measurement units, calibrating the time field according to a unified time benchmark, and uniformly encoding and mapping the internal codes of each system.

[0013] The generated event frames are arranged in chronological order to form a time-ordered sequence of event frames, and the correspondence between the source system identifier and the original business record identifier is retained in the event frames.

[0014] In a preferred embodiment, the object identifier mapping and matching rules in step S2 achieve unified object positioning by constructing a unified object identifier set. The unified object identifier is formed by combining the object category identifier, object code field, object name field, spatial location information field, and device or room type field.

[0015] When receiving an event frame, the corresponding unified object identifier is first queried in the pre-established encoding mapping table based on the object encoding field. If there is no matching entry in the encoding mapping table, the candidate unified object identifier is matched based on the combination similarity of the object name field, spatial location information field and type field.

[0016] For objects that are successfully matched, the corresponding node is located in the knowledge graph. For objects that are not matched, a new object node is created in the knowledge graph and a unified object identifier is written.

[0017] In a preferred embodiment, the event type to subgraph template index table in step S2 uses the event type identifier as the index key and the subgraph template identifier as the index value. The subgraph template includes at least the template start node type, the template path node type sequence, and the template path relationship type sequence.

[0018] The template path node type sequence is used to specify the types of nodes that are passed sequentially from the template starting node, and the template path relationship type sequence is used to specify the types of relationships between adjacent nodes;

[0019] When processing event frames, the corresponding subgraph template is selected from the index table according to the event type identifier, and the basic object node located in the knowledge graph is used as the template starting node.

[0020] Path expansion is performed in the knowledge graph according to the template path node type sequence and the template path relation type sequence. The set of nodes and relations obtained from the path expansion is determined as the affected subgraph range corresponding to the event.

[0021] In a preferred embodiment, the local incremental update in step S3 is executed through an update rule set associated with the event type. The update rule set is divided into three categories according to the event type: new node rules, relationship update rules, and status record rules.

[0022] The new node rules are used to create work order nodes, alarm nodes, rental relationship nodes, or vehicle passage record nodes within the affected subgraph based on the main object identifier and associated object identifier in the event frame, and to establish associations with existing object nodes.

[0023] The relationship update rule is used to write the expiration time to the original object relationship record and add the currently valid relationship record according to the event status within the affected subgraph.

[0024] Status recording rules are used to add status records for the attributes of equipment operation status, rental status, and parking space occupancy status within the affected subgraph without deleting existing records;

[0025] Local incremental updates are limited to the affected subgraph obtained through the subgraph template and do not modify nodes and relationships outside the affected subgraph.

[0026] In a preferred embodiment, the time version chain in step S3 consists of state records arranged in chronological order for the same object or the same relationship, and each state record includes at least an effective time, an optional expiration time, a source event identifier, and a state value.

[0027] When performing a local incremental update, the newly added state record is inserted into the end of the time version chain of the corresponding object or relationship. The original state record that is replaced is written with the expiration time and kept in the time version chain without being deleted. The state records of the same object or relationship are grouped by object identifier or relationship identifier and sorted by effective time.

[0028] Adjacent state records are linked chronologically to form a time version chain structure that is traversed sequentially. The time version chain serves as the time index basis for the construction of the current view and the construction of the historical view.

[0029] In a preferred embodiment, the conflict detection in step S4 is determined using a preset time window, which includes a start time offset and an end time offset relative to the time the event occurred.

[0030] After receiving an event frame, retrieve candidate state records whose time falls within a preset time window from the time version chain based on the subject object identifier;

[0031] The set of records with inconsistent state values ​​in the candidate state records is determined as the conflict candidate set. When the number of state records in the conflict candidate set exceeds one, it is determined that the current object has a state conflict within the time window, and the conflict candidate set is submitted to the consistency decision process.

[0032] In a preferred embodiment, the consistency decision in step S4 is performed based on source priority and event time order, and for each state record in the conflict candidate set, the corresponding priority is searched in the preset source priority list according to the source system identifier;

[0033] Candidate state records are sorted from high to low according to source priority. If the source priorities are the same, they are sorted from the nearest to the oldest event occurrence time. The state record with the highest priority and the most recent time in the sorting results is selected as the current state, written into the time version chain, and marked as the current mark in the corresponding record.

[0034] Attach a conflict label field to unselected state records and keep them in the time version chain. The conflict label field records the reason for being overwritten and the type of difference from the current state.

[0035] In a preferred embodiment, the graph query in step S5 constructs the current view and the historical view through a time version chain and rewrites the time conditions of the query request.

[0036] When the current view is constructed, for each object or relationship, the state record with the latest effective time and no expiration time written in the corresponding time version chain is selected as the current state;

[0037] When constructing a historical view, the system filters the effective and ineffective times in the time version chain based on the time point or time interval carried in the query request. This filters out state records whose effective and ineffective times fall between the effective and ineffective times or whose time intervals intersect with the record's effective time interval. Before entering the graph query engine, the query request is automatically fitted with time filtering conditions based on the selection of the current view or historical view. This ensures that queries for the current view are executed only on the current state set, while queries for the historical view are executed on state records that meet the time filtering conditions and return the corresponding subgraph.

[0038] A data processing system for dynamic knowledge graphs, used to implement the aforementioned data processing method for dynamic knowledge graphs, includes:

[0039] The event frame construction module is used to build a park event frame model, unify the format, map fields and align time for property, access control, parking, energy consumption and park portal business records, and generate an event frame sequence carrying object identifier, event type and timestamp;

[0040] The subgraph determination module is used to establish an index table from event types to subgraph templates. For each event frame, the basic object node is located in the knowledge graph according to the index, the corresponding subgraph template is called, and the affected subgraph range is obtained by expanding from the basic object node according to the template path.

[0041] The rule update module is used to perform local incremental updates within the affected subgraph according to the update rules associated with the event type. It appends writes to newly added nodes and edges, writes the expiration time to replaced relationships, writes the effective time and source event identifier to newly added and changed records, and generates a time version chain in object and time order.

[0042] The conflict detection module is used to perform conflict detection on candidate states of the same object within a preset time window before local incremental updates. It selects the current state based on source priority and event time order and writes it into the time version chain, and adds conflict tags to the unselected states.

[0043] The view determination module is used to construct the current view and historical view based on the time version chain during the graph query phase, attach time filtering conditions to the query request, return only the non-expired state in the current view, and return the subgraph that matches the time conditions in the historical view.

[0044] The technical effects and advantages of this invention are as follows:

[0045] This invention introduces a park event frame model, a unified object identifier set, and an indexing mechanism from event type to subgraph template. It standardizes multi-source business records such as property management, access control, parking, energy consumption, and park portal into time-ordered event frames. It also locates the affected subgraph range in the knowledge graph according to the subgraph template and performs local incremental updates only on relevant nodes and relationships, avoiding the high overhead and insufficient timeliness caused by traditional full reconstruction.

[0046] Based on a time version chain constructed from effective time, expiration time, and source event identifier, the state evolution of the same object or relationship at different times is fully traceable. Combined with conflict detection under a preset time window and consistency decision driven by source priority, the system effectively resolves state contradictions caused by parallel reporting from multiple systems, significantly improving data consistency and reliability. On this basis, the system can build current and historical views as needed and rewrite queries through time filtering conditions, supporting time-series retrieval for scenarios such as equipment operation, lease changes, and parking space occupancy, balancing query performance and result accuracy. This enhances the park's business platform's unified profiling capabilities and refined operational support capabilities under a dynamic knowledge graph. Attached Figure Description

[0047] Figure 1 This is a flowchart of a data processing method for dynamic knowledge graphs according to the present invention.

[0048] Figure 2 This is a schematic diagram of the structure of a data processing system for dynamic knowledge graphs according to the present invention. Detailed Implementation

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

[0050] Example 1: As Figure 1 As shown, a data processing method for dynamic knowledge graphs includes the following steps:

[0051] S1. Construct a park event frame model, unify the format, map fields and align time for property, access control, parking, energy consumption and park portal business records, and generate an event frame sequence carrying object identifier, event type and timestamp;

[0052] S2, establish an index table from event type to subgraph template, locate the basic object node in the knowledge graph according to the index for each event frame, call the corresponding subgraph template, and expand from the basic object node according to the template path to obtain the affected subgraph range;

[0053] S3 performs local incremental updates within the affected subgraph according to the update rules associated with the event type, appends writes to newly added nodes and edges, writes the expiration time to replaced relationships, writes the effective time and source event identifier to newly added and changed records, and generates a time version chain in object and time order;

[0054] S4. Before the local incremental update, perform conflict detection on the candidate states of the same object within the preset time window, select the current state based on the source priority and event time order and write it into the time version chain, and attach conflict labels to the unselected states.

[0055] S5: During the graph query phase, construct the current view and the historical view based on the time version chain, attach time filtering conditions to the query request, return only the non-expired state in the current view, and return the subgraph that matches the time condition in the historical view.

[0056] S1. Construct a park event frame model, standardize the format, map fields, and align time for property management, access control, parking, energy consumption, and park portal business records, and generate an event frame sequence carrying object identifiers, event types, and timestamps. Specific implementation steps include:

[0057] Before executing the data processing method of dynamic knowledge graph, a unified data access configuration is first established for the property management system, access control system, parking management system, energy consumption monitoring system and park portal system already deployed in the park. Each business system corresponds to a business record format description, which is used to list the original field names, field types, field meanings and the original time base of the time field output by the business system.

[0058] During operation, the system retrieves business records such as repair requests, inspection records, and fee records from the property management system; personnel access records from the access control system; vehicle entry and exit records and parking fee records from the parking management system; data collection records from various energy consumption meters from the energy consumption monitoring system; and enterprise entry information, visitor appointment information, and event announcement information from the park portal system. After each original business record is accessed, it is parsed according to the format description of the corresponding business system, and the original name of each field is mapped to the internal standard field name.

[0059] In this embodiment, the basic structure of the park event frame model is defined. The park event frame model includes at least six types of fields: event type identifier, subject object identifier, associated object identifier set, event occurrence time, source system identifier, and original business record identifier. The event type identifier is used to indicate the category of the business record, the subject object identifier is used to indicate the park object directly affected by the business record, the associated object identifier set is used to indicate other park objects that have business relationships with the subject object, the event occurrence time is used to indicate the time when the business event occurs in the business system, the source system identifier is used to mark which business system the event originates from, and the original business record identifier is used to mark the internal record number of the business system corresponding to the event.

[0060] During event frame generation, the original field names from different business systems are uniformly named, mapping fields representing the same meaning to a unified standard field. For example, the repair time field in the property management system, the card swipe time field in the access control system, and the entry time field in the parking management system are uniformly named the event occurrence time field through a field mapping table; the room number field in the property management system, the meter location field in the energy consumption monitoring system, and the building number field in the park portal system are uniformly named the main object identifier or associated object identifier field through a field mapping table.

[0061] For the measurement values ​​involved in each business record, such as energy consumption readings, parking time, and fee amount, the system performs a unified conversion of measurement units according to the preset measurement unit configuration, converting the units used by different systems into a unified base unit. For example, when one system uses kilowatt-hours and another system uses watt-hours, the proportional relationship between the two units is obtained by looking up the measurement unit configuration table, and then the conversion is performed by repeated accumulation or group accumulation, so that all energy consumption fields are internally represented by the same base unit.

[0062] In the time processing section, we first analyze the time base used by the time fields of each business system. For example, some use local time and some use Coordinated Universal Time. Then, by using the configured time zone offset or time offset parameters, we perform addition or subtraction operations on the original time value and the corresponding offset to obtain the event occurrence time field under a unified time base, thereby realizing the calibration of the time field according to the unified time base.

[0063] To achieve coding uniformity, the system pre-establishes a coding mapping table for building codes, room codes, equipment codes, etc. used within each business system. The coding mapping table records the correspondence between the internal codes of each business system and the unified code.

[0064] When constructing an event frame, the system queries the encoding mapping table based on the original encoding field in the business record, obtains the unified encoding, and writes it into the main object identifier or associated object identifier. When a certain original encoding does not exist in the encoding mapping table, the system registers the original encoding as a code to be processed according to a preset strategy and temporarily fills the main object identifier or associated object identifier field with the original encoding. At the same time, this situation is recorded in the background for subsequent supplementation of the encoding mapping table.

[0065] After completing the unified naming of field names, the unified conversion of measurement units, the calibration of time fields according to a unified time benchmark, and the unified mapping of internal codes, the system generates an event frame for each original business record based on the park event frame model. The parsed and converted event type identifier, subject object identifier, set of associated object identifiers, event occurrence time, source system identifier, and original business record identifier are written into the event frame.

[0066] The determination of event type identifiers is based on pre-configured event classification rules. For example, property repair orders are classified as maintenance events, access control records are classified as access events, parking entry and exit records are classified as parking events, energy consumption anomaly records are classified as energy consumption anomaly events, and enterprise entry and exit records are classified as lease change events.

[0067] The main object identifier and associated object identifier sets are populated based on the primary key field and associated field in the business record. For example, for a repair order record, the main object identifier corresponds to the faulty equipment or room, and the associated object identifier set includes the initiator, responsible person, and related enterprise; for a parking record, the main object identifier corresponds to the vehicle or license plate number, and the associated object identifier set includes the parking space, parking area, and related enterprise or visitor. The source system identifier and the original business record identifier are fixedly assigned by the system during the configuration phase. The source system identifier uniquely identifies one of the property management system, access control system, parking management system, energy consumption monitoring system, and park portal system, while the original business record identifier directly references the primary key number or log sequence number of the business system record.

[0068] The generated event frames are sorted according to the event occurrence time field to form a time-ordered sequence of event frames. At the same time, the correspondence between the source system identifier and the original business record identifier is retained in the event frames, so that any event frame in the subsequent processing can be traced back to the original record in the corresponding business system, realizing a closed-loop association from the dynamic knowledge graph back to the business system.

[0069] S2, establish an index table from event types to subgraph templates, locate the basic object node in the knowledge graph for each event frame according to the index, call the corresponding subgraph template, and expand from the basic object node according to the template path to obtain the affected subgraph range. The specific implementation steps include:

[0070] After completing the construction of the park event frame model, in order to enable each event frame to be accurately located in the knowledge graph to the corresponding basic object node and to determine the scope that needs to be updated later, a unified object identifier set and an index table of event types to subgraph templates are first established in the deployment phase.

[0071] Specifically, the unified object identifier set adopts a structured storage method. Each unified object identifier is composed of an object category identifier, an object code field, an object name field, a spatial location information field, and a device or room type field. The object category identifier is used to distinguish different categories such as enterprises, buildings, rooms, equipment, parking spaces, and personnel. The object code field is used to record the code of the object in the unified coding system. The object name field is used to record the name displayed to the user. The spatial location information field is used to record location information such as building, floor, specific room, or geographical coordinates. The device or room type field is used to record the device type or room purpose.

[0072] The index table from event type to subgraph template uses the event type identifier as the index key and the subgraph template identifier as the index value. Each subgraph template identifier is associated with a subgraph template record. The subgraph template record contains at least the template starting node type, the template path node type sequence, and the template path relationship type sequence. The template path node type sequence is used to specify the types of nodes that are passed sequentially from the template starting node, and the template path relationship type sequence is used to specify the relationship type between adjacent nodes. The two correspond one-to-one in the same order in the structure.

[0073] During operation, when the system receives a park event frame, it first reads the object code field, object name field, spatial location information field, and equipment or room type field contained in the main object identifier and associated object identifier set from the event frame. Then, it searches for the corresponding unified object identifier in the unified object identifier set through a pre-established encoding mapping table and object matching rules.

[0074] Specifically, a lookup is first performed in the encoding mapping table using the object encoding field as the key. If a matching entry exists in the encoding mapping table, the unified object identifier corresponding to the entry is directly obtained, and the corresponding object node is located in the knowledge graph using the unified object identifier as the index.

[0075] If no matching entry exists in the encoding mapping table, a combined matching process based on the object name field, spatial location information field, and device or room type field is initiated. This process sequentially checks whether the object name field is completely identical to the object name field in an existing unified object identifier record, whether the spatial location information field falls within the same building and floor, and whether the device or room type field belongs to the same type. When all three conditions are met, the existing unified object identifier record is considered a candidate unified object identifier record, and further, based on business rules, it is determined whether to accept this candidate unified object identifier as the matching result. For example, it can be stipulated that within the same building and floor, identical object name fields and identical device or room type fields indicate the same object.

[0076] If there are multiple candidate unified object identifier records, one will be selected as the final unified object identifier according to the priority of the source system or the order of addition time.

[0077] If no matching record is found, a new unified object identifier record is created in the unified object identifier set. The object category identifier, object code field, object name field, spatial location information field, and device or room type field from the event frame are directly written into this record, and the corresponding object node is created synchronously in the knowledge graph so that subsequent events can continue to reference this unified object identifier.

[0078] After successfully obtaining the unified object identifiers of the main object and related objects, the system maps these unified object identifiers to the basic object nodes in the knowledge graph, and searches for the corresponding subgraph template identifier in the index table from event type to subgraph template according to the event type identifier in the event frame, and then loads the subgraph template corresponding to the subgraph template identifier.

[0079] Using the base object node corresponding to the main object as the template starting node, the type of the template starting node is compared with the node category of the base object node. Path expansion is only performed if they match. If the template path node type sequence length is several steps, the system starts from the template starting node and expands step-by-step according to the order of node types in the template path node type sequence and relation types in the template path relation type sequence.

[0080] In the first step, starting from the template starting node, all adjacent nodes connected through the first relation type in the template path relation type sequence are searched in the knowledge graph, and nodes whose node categories are consistent with the first type of node category in the template path node type sequence are selected as the first layer of extended nodes.

[0081] In the second step, starting from the first-level extended node, we continue to search for adjacent nodes connected by the second relationship type in the template path relationship type sequence, and filter out nodes whose node category is consistent with the second node category in the template path node type sequence. This process continues until the template path node type sequence and the template path relationship type sequence have been traversed, or until there are no longer any adjacent nodes that meet the conditions in a certain step.

[0082] During the path expansion process, all visited nodes and relationships are recorded in the affected subgraph range set, and the actual node and relationship categories traversed during the path expansion process are compared with the template path node type sequence and template path relationship type sequence to ensure that the affected subgraph range only contains nodes and relationships that satisfy the template structure constraints.

[0083] For an event frame that needs to consider both the main object and related objects, the above path expansion is performed with the main object node and the related object node as template starting nodes respectively. The union of the nodes and relationships obtained from each starting node is determined as the affected subgraph range corresponding to the event frame, providing a clear target set for subsequent local incremental updates within the affected subgraph range.

[0084] S3, within the affected subgraph, performs local incremental updates according to the update rules associated with the event type. This includes appending writes to newly added nodes and edges, writing expiration times to replaced relationships, writing effective times and source event identifiers to newly added and changed records, and generating a time version chain in object and time order. Specific implementation steps include:

[0085] After obtaining the affected subgraph range through the index table from event type to subgraph template, the system performs local incremental updates according to the update rules associated with the event type;

[0086] The update rules associated with event types are configured according to event type. Each event type must be associated with at least three types of rules: new node rules, relationship update rules, and status record rules.

[0087] The rules for adding new nodes are used to determine the business nodes that need to be added within the affected subgraph and the association relationships that need to be established with existing object nodes. For example, for maintenance events, add work order nodes within the affected subgraph; for alarm events, add alarm nodes; for lease change events, add lease relationship nodes; and for parking events, add vehicle access record nodes. These nodes are then connected to the corresponding main object nodes and associated object nodes through predefined relationship types.

[0088] Relationship update rules are used to determine which existing object relationships need to be replaced within the affected subgraph, as well as the content and structure of the new relationship records. For example, in a lease change event, the expiration time is written to the existing relationship record between the enterprise and the room that is in a rented state, and a new relationship record is added to indicate the lease termination state; in an equipment repair event, the expiration time is written to the normal state relationship between the equipment and the operating state, and a new relationship record is added to indicate the fault state.

[0089] State recording rules are used to add records to the attribute states of objects within the affected subgraph range. For example, new state records can be added to the equipment operation state, rental state, and parking space occupancy state without deleting the original state records, so that the state of the same object at different times can be continuously saved.

[0090] During the execution of local incremental updates, the system first traverses the main object nodes and associated object nodes within the affected subgraph according to the rules for adding new nodes. For each event type requiring a new business node, a node corresponding to the specific business meaning is created based on the main object identifier and associated object identifier in the event frame. Examples include work order nodes, alarm nodes, rental relationship nodes, and vehicle passage record nodes. After creation, the system establishes relationship edges between the new node and the corresponding object node within the affected subgraph according to the pre-configured relationship types. For example, a work order node is associated with a faulty equipment node, a rental relationship node is associated with a rental company and a rental room, respectively, and a vehicle passage record node is associated with a vehicle node and a parking space, respectively, for passage records and parking space occupancy.

[0091] In the relationship update section, the system locates the original relationship records that need to be replaced within the affected subgraph range according to the relationship update rules. These records may include old lease relationship records or old equipment status relationship records. The system writes an expiration time field to these original relationship records, setting the expiration time field to the event occurrence time in the current event frame or a time value determined according to a preset delay strategy, to indicate that the relationship is no longer valid after that time point. At the same time, the system creates new relationship records according to the relationship update rules, connects the new relationship records to the same object nodes, and writes a status value that represents the current business meaning into the new relationship records. For example, the status value may be set to the current lease status or the current equipment operating status.

[0092] In the time stamp and time version chain generation process, for all newly added nodes, newly added relationship records, and new state records corresponding to replaced relationships, an effective time field and a source event identifier field are uniformly added when writing to the knowledge graph;

[0093] The effective time field records the time when the node or relationship record becomes effective, typically set to the event occurrence time in the corresponding event frame. The source event identifier field records the event frame identifier that triggered the addition or change, allowing each record to be traced back to the business event that caused it. For existing relationship records that are replaced, only the expiration time field is written; the original effective time field and source event identifier field are not modified, and the record is not deleted from the knowledge graph. Subsequently, the system sorts all status records of the same object or relationship by the effective time field, using the object identifier or relationship identifier as the grouping key. It then establishes predecessor and successor links between adjacent status records in the sorting result, starting from the earliest status record and sequentially pointing to subsequent status records, forming a time version chain structure that can be traversed sequentially.

[0094] In the time-version chain, the state record with the earliest effective time and no predecessor link is the chain head, and the state record with the latest effective time and an empty expiration time field or no expiration time set is the chain tail, representing the current latest state. In this way, within the affected subgraph, local incremental updates not only complete the writing of new nodes and new relationships and the expiration marking of existing relationships, but also generate a time-version chain covering the entire lifecycle at the object or relationship level, thus providing a complete time index foundation for building the current view and historical views.

[0095] S4, before the local incremental update, performs conflict detection on candidate states of the same object within a preset time window, selects the current state based on source priority and event time order and writes it into the time version chain, and adds conflict tags to the unselected states. The specific implementation steps include:

[0096] Before performing a local incremental update on the affected subgraph range corresponding to the event frame, the system predefines a preset time window for each main object to limit the range of state records that need to participate in conflict detection on the time version chain.

[0097] The preset time window consists of two parameters: a start time offset and an end time offset. The start time offset represents the forward offset on the timeline relative to the event occurrence time in the current event frame, while the end time offset represents the backward offset on the timeline relative to the event occurrence time. Upon receiving an event frame, the system first reads the subject object identifier and the event occurrence time from the event frame. Using the subject object identifier, the system locates the corresponding time version chain for that subject object in the time version chain. Then, it searches for state records in that time version chain whose effective and ineffective times fall within the time period determined by the start and end time offsets. This set of retrieved state records is used as candidate state records for conflict detection and consistency decision-making.

[0098] During conflict detection, the system iterates through the state value field of each state record in the candidate state records, comparing each state value pairwise. When records with different state values ​​are found, all candidate state records with different state values ​​are grouped into a conflict candidate set. The conflict candidate set only contains state records that identify the same subject object, fall within the same preset time window, and have inconsistent state values. When the number of state records in the conflict candidate set exceeds one, it is determined that the subject object has a state conflict within the current preset time window.

[0099] For example, in the time version chain of equipment operation status, if the energy consumption monitoring system reports the equipment as being in an abnormal state multiple times within a certain time window, while the property management system records the equipment as being in a normal state through work orders within the same time window, then the candidate status records for that equipment will contain at least one abnormal status record and one normal status record. In this case, these records will be included in the conflict candidate set, and the conflict candidate set will be submitted to the consistency decision process. No one of them will be directly written into the current status position of the time version chain.

[0100] During the consistency decision-making process, the source system identifier field of each status record in the conflict candidate set is read, and the corresponding source priority is searched in the pre-configured source priority list. The source priority list is determined by the system administrator during the deployment phase based on the reliability and business positioning of each business system. For example, manually confirmed work order systems can be set as high priority, and automatically collected monitoring systems can be set as secondary priority. First, the status records in the conflict candidate set are sorted from high to low according to the source priority. Among the status records with the same source priority, they are then sorted from the most recent to the earliest according to the event occurrence time field. After sorting, the status record with the highest source priority and the most recent event occurrence time in the sorted results is selected as the current status. This status record is written as a new status record to the end of the time version chain, or it is marked as the current mark at the end of the existing chain.

[0101] For the remaining state records in the conflict candidate set that were not selected as the current state, the system does not delete these state records. Instead, it adds a conflict label field to each state record. The conflict label field records at least the reason why the state record was not selected as the current state and the type of difference between it and the current state record. For example, it records that the source system priority of the record is lower than the source system priority of the current state record, or that the state value is inconsistent with the state value of the current state record.

[0102] The time-version chain retains all conflict state records while writing the current state, and explicitly marks conflict information through the conflict tag field, so that when conducting historical tracing or manual review, it is possible to clearly understand the time range of the conflict, the state records involved in the conflict, and the basis for selecting the current state.

[0103] S5: During the graph query phase, construct the current view and historical view based on the time version chain, attach time filtering conditions to the query request, return only the non-expired state in the current view, and return the subgraph that matches the time condition in the historical view. Specific implementation steps include:

[0104] After completing the construction of the time version chain, when a query request for the dynamic knowledge graph is received, the system first determines whether the query is a current view query or a historical view query based on whether the query request contains time point or time interval parameters.

[0105] When a query request does not include any time conditions, or explicitly specifies that the query is for the current park operation status, the query is classified as a current view query. When a query request carries a specific time point, time interval, or expresses the need for historical time periods in natural language, the query is classified as a historical view query. Internally, a view type tag is added to the query request to indicate whether the current view or the historical view should be built based on the time version chain during subsequent query processing, and different time filtering conditions are added to these two views respectively.

[0106] During the current view construction process, for each object and each relationship in the knowledge graph, the system reads all the state records in the corresponding time version chain, sorts them from earliest to latest according to the effective time, and selects the state record with the latest effective time and no expiration time field written in the sorting result as the current state record.

[0107] For state records with an expiration time field, if the expiration time is earlier than the current system time, the state record will not be included in the state set corresponding to the current view. In this way, the system determines a unique current state for each object and each relationship, and combines these current states into the current view on the graph structure.

[0108] For queries belonging to the current view, a time filter condition is automatically applied to the request before it enters the graph query processing. This time filter condition limits the traversal and matching to only the state set within the current view, ignoring state records in the time version chain that have already been written with expiration times and are only effective in the past. For example, when a park manager queries all devices currently in a fault state and their associated work orders in the backend interface, the current view only returns device nodes at the end of the time version chain that are still in a fault state and do not have an expiration time mark. Then, it traces back along the relationship between these device nodes and work order nodes to find the work order nodes that are not yet closed, forming query results that conform to the meaning of the current time.

[0109] During the construction of the historical view, based on the time point or time interval carried in the query request, status records that meet the time conditions are filtered in the corresponding time version chain for each object and each relationship. When the query request provides a single time point, it is determined whether the time point of each status record falls between the effective time and the expiration time of the status record. If the status record does not have an expiration time field set, the status record is considered to be valid since the effective time. When making the determination, it is only necessary to verify that the time point is not earlier than the effective time.

[0110] When the query request provides a time range, the valid time range of the status record is understood to be from the effective time to the expiration time. If the expiration time is not set, the valid time range extends from the effective time to the current system time or the preset expiration time. Then, it is determined whether there is an intersection between the valid time range of each status record in the time version chain and the time range provided by the query request. Status records with an intersection are considered to be valid within that time range.

[0111] The status records filtered through the above criteria are used as the status set of the historical view. Based on these status sets, a historical view corresponding to a specified time point or time interval is constructed on the graph structure. Appropriate time filtering conditions are added before the query request enters the graph query processing, ensuring that the historical view query only traverses and matches status records that meet the time conditions. For example, when park operators want to analyze the leasing changes of all companies in a building over a period of time, they can specify the time interval in the query request. Based on the time version chain of the leasing relationship between each company and room, records whose leasing status changed from being leased to being terminated within that time interval are filtered out. These records, forming company nodes, room nodes, and leasing relationship edges, are combined into a subgraph in the historical view, thus obtaining the leasing structure that actually existed within that time interval, unaffected by the current latest leasing status.

[0112] This invention introduces a park event frame model, a unified object identifier set, and an indexing mechanism from event type to subgraph template. It standardizes multi-source business records such as property management, access control, parking, energy consumption, and park portal into time-ordered event frames. It also locates the affected subgraph range in the knowledge graph according to the subgraph template and performs local incremental updates only on relevant nodes and relationships, avoiding the high overhead and insufficient timeliness caused by traditional full reconstruction.

[0113] Based on a time version chain constructed from effective time, expiration time, and source event identifier, the state evolution of the same object or relationship at different times is fully traceable. Combined with conflict detection under a preset time window and consistency decision driven by source priority, the system effectively resolves state contradictions caused by parallel reporting from multiple systems, significantly improving data consistency and reliability. On this basis, the system can build current and historical views as needed and rewrite queries through time filtering conditions, supporting time-series retrieval for scenarios such as equipment operation, lease changes, and parking space occupancy, balancing query performance and result accuracy. This enhances the park's business platform's unified profiling capabilities and refined operational support capabilities under a dynamic knowledge graph.

[0114] Example 2: A data processing system for dynamic knowledge graphs, such as Figure 2 As shown, it specifically includes:

[0115] The event frame construction module is used to build a park event frame model, unify the format, map fields and align time for property, access control, parking, energy consumption and park portal business records, and generate an event frame sequence carrying object identifier, event type and timestamp;

[0116] The subgraph determination module is used to establish an index table from event types to subgraph templates. For each event frame, the basic object node is located in the knowledge graph according to the index, the corresponding subgraph template is called, and the affected subgraph range is obtained by expanding from the basic object node according to the template path.

[0117] The rule update module is used to perform local incremental updates within the affected subgraph according to the update rules associated with the event type. It appends writes to newly added nodes and edges, writes the expiration time to replaced relationships, writes the effective time and source event identifier to newly added and changed records, and generates a time version chain in object and time order.

[0118] The conflict detection module is used to perform conflict detection on candidate states of the same object within a preset time window before local incremental updates. It selects the current state based on source priority and event time order and writes it into the time version chain, and adds conflict tags to the unselected states.

[0119] The view determination module is used to construct the current view and historical view based on the time version chain during the graph query phase, attach time filtering conditions to the query request, return only the non-expired state in the current view, and return the subgraph that matches the time conditions in the historical view.

[0120] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, ATA hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state ATA hard disk.

[0121] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0122] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0123] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0124] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0125] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0126] 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.

Claims

1. A data processing method for dynamic knowledge graphs, characterized in that, Includes the following steps: S1. Construct a park event frame model, unify the format, map fields and align time for property, access control, parking, energy consumption and park portal business records, and generate an event frame sequence carrying object identifier, event type and timestamp; S2, establish an index table from event type to subgraph template, locate the basic object node in the knowledge graph according to the index for each event frame, call the corresponding subgraph template, and expand from the basic object node according to the template path to obtain the affected subgraph range; S3 performs local incremental updates within the affected subgraph according to the update rules associated with the event type, appends writes to newly added nodes and edges, writes the expiration time to replaced relationships, writes the effective time and source event identifier to newly added and changed records, and generates a time version chain in object and time order; S4. Before the local incremental update, perform conflict detection on the candidate states of the same object within the preset time window, select the current state based on the source priority and event time order and write it into the time version chain, and attach conflict labels to the unselected states. S5: During the graph query phase, construct the current view and the historical view based on the time version chain, attach time filtering conditions to the query request, return only the non-expired state in the current view, and return the subgraph that matches the time conditions in the historical view. In step S2, the event type to subgraph template index table uses the event type identifier as the index key and the subgraph template identifier as the index value. The subgraph template includes at least the template start node type, the template path node type sequence, and the template path relationship type sequence. The template path node type sequence is used to specify the types of nodes that are passed sequentially from the template starting node, and the template path relationship type sequence is used to specify the types of relationships between adjacent nodes; When processing event frames, the corresponding subgraph template is selected from the index table according to the event type identifier, and the basic object node located in the knowledge graph is used as the template starting node. Path expansion is performed in the knowledge graph according to the template path node type sequence and the template path relation type sequence. The set of nodes and relations obtained by the path expansion is determined as the range of the affected subgraph corresponding to the event. The local incremental update in step S3 is executed through the update rule set associated with the event type. The update rule set is divided into three categories according to the event type: new node rules, relationship update rules, and status record rules. The new node rules are used to create work order nodes, alarm nodes, rental relationship nodes, or vehicle passage record nodes within the affected subgraph based on the main object identifier and associated object identifier in the event frame, and to establish associations with existing object nodes. The relationship update rule is used to write the expiration time to the original object relationship record and add the currently valid relationship record according to the event status within the affected subgraph. Status recording rules are used to add status records for the attributes of equipment operation status, rental status, and parking space occupancy status within the affected subgraph without deleting existing records; Local incremental updates are limited to the affected subgraph obtained through the subgraph template and do not modify nodes and relationships outside the affected subgraph.

2. The data processing method for dynamic knowledge graphs according to claim 1, characterized in that: The park event frame model in step S1 includes six types of fields: event type identifier, main object identifier, set of associated object identifiers, event occurrence time, source system identifier, and original business record identifier. The normalization process includes uniform naming of field names from different business systems, uniform conversion of measurement units, calibration of time fields according to a unified time benchmark, and uniform encoding mapping of internal codes of each system. The generated event frames are arranged in chronological order to form a time-ordered sequence of event frames, and the correspondence between the source system identifier and the original business record identifier is retained in the event frames.

3. The data processing method for dynamic knowledge graphs according to claim 1, characterized in that: The object identifier mapping and matching rules in step S2 achieve unified object positioning by constructing a unified object identifier set. The unified object identifier is formed by combining the object category identifier, object code field, object name field, spatial location information field and device or room type field. When receiving an event frame, the corresponding unified object identifier is first queried in the pre-established encoding mapping table based on the object encoding field. If there is no matching entry in the encoding mapping table, the candidate unified object identifier is matched based on the combination similarity of the object name field, spatial location information field and type field. For objects that are successfully matched, the corresponding node is located in the knowledge graph. For objects that are not matched, a new object node is created in the knowledge graph and a unified object identifier is written.

4. The data processing method for dynamic knowledge graphs according to claim 3, characterized in that: The time version chain in step S3 consists of state records arranged in chronological order for the same object or relationship. Each state record includes at least an effective time, an optional expiration time, a source event identifier, and a state value. When performing a local incremental update, the newly added state record is inserted into the end of the time version chain of the corresponding object or relationship. The original state record that is replaced is written with the expiration time and kept in the time version chain without being deleted. The state records of the same object or relationship are grouped by object identifier or relationship identifier and sorted by effective time. Adjacent state records are linked chronologically to form a time version chain structure that is traversed sequentially. The time version chain serves as the time index basis for the construction of the current view and the construction of the historical view.

5. The data processing method for dynamic knowledge graphs according to claim 4, characterized in that: The conflict detection in step S4 is determined using a preset time window, which includes a start time offset and an end time offset relative to the time the event occurred. After receiving an event frame, retrieve candidate state records whose time falls within a preset time window from the time version chain based on the subject object identifier; The set of records with inconsistent state values ​​in the candidate state records is determined as the conflict candidate set. When the number of state records in the conflict candidate set exceeds one, it is determined that the current object has a state conflict within the time window, and the conflict candidate set is submitted to the consistency decision process.

6. The data processing method for dynamic knowledge graphs according to claim 5, characterized in that: The consistency decision in step S4 is performed based on source priority and event time order. For each state record in the conflict candidate set, the corresponding priority is searched in the preset source priority list according to the source system identifier. Candidate state records are sorted from high to low according to source priority. If the source priorities are the same, they are sorted from the nearest to the oldest event occurrence time. The state record with the highest priority and the most recent time in the sorting results is selected as the current state, written into the time version chain, and marked as the current mark in the corresponding record. Attach a conflict label field to unselected state records and keep them in the time version chain. The conflict label field records the reason for being overwritten and the type of difference from the current state.

7. A data processing method for dynamic knowledge graphs according to claim 6, characterized in that: In step S5, the graph query constructs the current view and the historical view through the time version chain and rewrites the time conditions of the query request. When the current view is constructed, for each object or relationship, the state record with the latest effective time and no expiration time written in the corresponding time version chain is selected as the current state; When constructing a historical view, the system filters the effective and ineffective times in the time version chain based on the time point or time interval carried in the query request. This filters out state records whose effective and ineffective times fall between the effective and ineffective times or whose time intervals intersect with the record's effective time interval. Before entering the graph query engine, the query request is automatically fitted with time filtering conditions based on the selection of the current view or historical view. This ensures that queries for the current view are executed only on the current state set, while queries for the historical view are executed on state records that meet the time filtering conditions and return the corresponding subgraph.

8. A data processing system for dynamic knowledge graphs, used to implement the data processing method for dynamic knowledge graphs according to any one of claims 1-7, characterized in that, include: The event frame construction module is used to build a park event frame model, unify the format, map fields and align time for property, access control, parking, energy consumption and park portal business records, and generate an event frame sequence carrying object identifier, event type and timestamp; The subgraph determination module is used to establish an index table from event types to subgraph templates. For each event frame, the basic object node is located in the knowledge graph according to the index, the corresponding subgraph template is called, and the affected subgraph range is obtained by expanding from the basic object node according to the template path. The rule update module is used to perform local incremental updates within the affected subgraph according to the update rules associated with the event type. It appends writes to newly added nodes and edges, writes the expiration time to replaced relationships, writes the effective time and source event identifier to newly added and changed records, and generates a time version chain in object and time order. The conflict detection module is used to perform conflict detection on candidate states of the same object within a preset time window before local incremental updates. It selects the current state based on source priority and event time order and writes it into the time version chain, and adds conflict tags to the unselected states. The view determination module is used to construct the current view and historical view based on the time version chain during the graph query phase, attach time filtering conditions to the query request, return only the non-expired state in the current view, and return the subgraph that matches the time conditions in the historical view.

Images